up:: Migration Architecture MOC

The Ceiling Question

The ceiling question is the one delegable question that finds every system in an estate that physically cannot hold a post-quantum signature. It goes to two named owners, the firmware owners and the PKI team, in these words: “what is the maximum signature size our firmware verifier and our certificate chain will accept?” The question asks for the maximum each system will accept, rather than the size in use today, because the migration swaps a roughly 64-byte ECDSA signature for a 3,309-byte ML-DSA-65 one, and whether the new artifact fits is decided by a ceiling most organizations have never had to write down.

The decision rule is fixed. Any answer under 3,309 bytes marks a system that physically cannot hold an ML-DSA-65 signature, the parameter set the market has settled on as the general-purpose default, and that system needs reengineering or replacement, never reconfiguration. The output is the list of everything in the estate that can’t hold the new signature, and that list is Phase 1 scope for the signature migration.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, Table 2, August 2024, FIPS 204 (the 3,309-byte figure; the general-purpose-default status is market practice rather than a NIST designation, since FIPS 204 recommends no parameter set).

The short version:

• The question, verbatim, to the firmware owners and the PKI team: “what is the maximum signature size our firmware verifier and our certificate chain will accept?” Ask for the maximum they will accept, rather than the size in use today.
• The threshold is 3,309 bytes, the signature size of ML-DSA-65 per FIPS 204, the parameter set most general-purpose signature migrations deploy first. A raw ECDSA P-256 signature is 64 bytes, so the replacement is roughly 50 times larger.
• Any answer under 3,309 bytes marks a system that physically cannot hold the new signature. Those systems need reengineering or replacement, never reconfiguration, and they carry the longest lead times in the migration.
• In most organizations nobody knows the ceiling, because it’s a hard-coded constant somebody chose a decade ago, sitting in a header file or a hardware spec nobody has opened since. The question does real work the moment it’s asked.
• The output is the list of systems that can’t accept the new signature, and that list is Phase 1 scope.

Think of buying a couch for an old building. The couch you own fits because, in effect, the room was furnished around it. Before you order the bigger one, the only measurement that matters is the narrowest doorway, stairwell, or elevator on the route in, and that number lives in a floor plan the building manager hasn’t opened in years. Measuring the narrowest passage before the delivery truck arrives is the whole discipline. The ceiling question is that measurement for signatures: the new artifact’s size is fixed and published, so the unknown worth chasing is the tightest opening it has to fit through.

What is the ceiling question?

The ceiling question is a named scoping tool with 4 fixed parts:

1. The wording. “What is the maximum signature size our firmware verifier and our certificate chain will accept?” Every word is load-bearing. “Maximum” and “will accept” point the respondent at the limit of the system rather than the size of today’s traffic, and naming both surfaces in one sentence keeps either owner from assuming the other has it covered.
2. The two respondents. The firmware owners, because a secure-boot or update verifier checks a signature against a field whose size was fixed when the platform shipped, and the PKI team, because certificate chains travel through parsers, trust stores, and TLS termination points that each carry their own limit. These are the two surfaces where fixed-size assumptions about signatures concentrate.
3. The decision rule. Any answer under 3,309 bytes, the ML-DSA-65 signature size from FIPS 204, is a system that physically cannot hold the general-purpose post-quantum signature. Reengineering or replacement is the remedy, never reconfiguration.
4. The output. The list of everything that can’t hold the new signature. That list is Phase 1 scope, because those systems carry the longest lead times in the entire program and the rest of the migration schedules around them.

The question applies to any estate planning its signature migration, and it’s deliberately delegable: it runs ahead of a complete inventory as a spot measurement, one email, two owners, no tooling. It’s a targeted deepening of The Four Questions, adding a per-row ceiling to the inventory’s algorithm-location map, and it scopes the deliberate signature lane of The Two-Lane Split. What the ceiling question does NOT do is rank, cost, or sequence the list it produces, and it says nothing about key establishment, whose size problem lives in the handshake path and is covered in PQC Performance and Size Overhead.

Why is the threshold 3,309 bytes?

Because 3,309 bytes is the exact signature size of ML-DSA-65, the middle parameter set of FIPS 204 and the common general-purpose starting default for post-quantum signing, with a public key of 1,952 bytes riding alongside it. A system whose ceiling sits under 3,309 bytes has no room for the signature most estates will actually deploy, which is what makes the number the right pass-fail line for scoping. The full parameter family, verbatim from FIPS 204 Tables 1 and 2:

Parameter set	Security category	Public key	Signature
ML-DSA-44	Category 2	1,312 bytes	2,420 bytes
ML-DSA-65	Category 3	1,952 bytes	3,309 bytes
ML-DSA-87	Category 5	2,592 bytes	4,627 bytes

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, Tables 1 and 2, August 2024, FIPS 204.

The threshold generalizes cleanly: it is the signature size of the parameter set a surface will actually deploy. An estate standardizing a high-assurance surface on ML-DSA-87 tests that surface against 4,627 bytes, and a firmware root of trust heading toward the hash-based schemes tests against their sizes instead (PQC in Firmware and Code Signing covers that choice). For the general-purpose default that most certificate and signing surfaces migrate to first, 3,309 bytes is the line, and a ceiling that clears it with margin usually clears the siblings’ too.

Why ask for the maximum instead of the size in use today?

Because the size in use today measures the classical world, and it will always come back fine. Every answer would read 64 bytes, or 256 for RSA-2048, and teach nothing about fit. The maximum is the property the migration actually tests, and it’s a number with a strange status inside most organizations: it exists, it’s exact, and nobody knows it. It’s a hard-coded constant somebody chose a decade ago, sitting in a header file or a hardware spec that nobody has opened since, because until now there was never a reason to.

That’s why the question does work the moment it’s asked. It sends the firmware team into the verifier source and the platform documentation, and the PKI team into parser limits, trust-store behavior, and termination-point buffers, looking for a number they’ve never had to produce. Some of those numbers come back under 3,309 bytes, and every system where that’s true is a system that cannot accept the general-purpose post-quantum signature no matter how it’s configured. Finding those systems by asking a question costs an email; finding them during rollout costs an incident and a re-plan.

How much bigger are post-quantum signatures than the ones they replace?

The size gap is the entire reason a ceiling anyone chose in the classical era is now a migration variable. Every figure below traces to its defining standard:

Artifact	Classical size	Post-quantum replacement	Growth
Signature	ECDSA P-256, 64 bytes raw	ML-DSA-65 signature, 3,309 bytes	~50x
Signature	RSA-2048, 256 bytes	ML-DSA-65 signature, 3,309 bytes	~13x
Signature public key	ECDSA P-256 point, ~64 bytes	ML-DSA-65 public key, 1,952 bytes	~30x
Key-exchange public key	X25519, 32 bytes	ML-KEM-768 encapsulation key, 1,184 bytes	~37x

Sources: NIST FIPS 186-5 (a P-256 signature is the pair r and s at 32 bytes each), FIPS 186-5; RFC 8017 (an RSA signature matches the modulus length), RFC 8017; RFC 7748 (X25519 keys are 32 bytes), RFC 7748; NIST FIPS 203 Table 3 and FIPS 204 Table 2, FIPS 203, FIPS 204.

Read these as SIZE ratios and nothing else. They say nothing about speed, and on modern hardware the lattice schemes verify at competitive or better speed than the classical code they replace; an ML-DSA verification often finishes faster than an RSA one. Reading “50 times bigger” as “50 times slower” gets the engineering exactly backwards: the compute is the part that got easier, and the bytes are the part that got harder. The full production story, middleboxes, handshake growth, and all, lives in PQC Performance and Size Overhead, and the embedded end of it in Constrained-Device PQC.

Source: D. J. Bernstein and T. Lange, “eBACS: ECRYPT Benchmarking of Cryptographic Systems,” SUPERCOP, bench.cr.yp.to.

What is the raw-versus-DER trap?

The trap is quoting the wrong classical baseline for the context, because an ECDSA signature has two sizes depending on where it lives. The raw signature is the pair of integers r and s, 32 bytes each for P-256, so 64 bytes total, which is the form a firmware verifier checking a bare signature block typically consumes. Inside an X.509 certificate, the same signature is DER-encoded as an ASN.1 SEQUENCE of two INTEGERs, and the wrapping brings it to roughly 70 to 72 bytes depending on leading bytes.

Source: NIST FIPS 186-5 §6.4 (the signature is the pair r and s), FIPS 186-5; RFC 3279 §2.2.3 (the Ecdsa-Sig-Value SEQUENCE encoding used in X.509), RFC 3279.

The practical rule: use 64 bytes when the context is a raw verifier, and roughly 70 to 72 when the context is a certificate. In a reference this precise the distinction matters, because quoting 64 bytes for a certificate context hands a pedant a correction, and in an audit-grade document that’s the kind of crack credibility leaks through. For the ceiling question’s decision rule, though, the trap is cosmetic: both figures sit so far under 3,309 bytes that the pass-fail line survives either encoding, and the ~50x ratio holds within a rounding error either way.

How do you run the ceiling question across a real estate?

You run it as one delegated email to the two owners, then sort what comes back. The estate below is generic and its numbers are illustrative; the shape of the answers is what recurs. The firmware owners take the question to every verifier in the boot and update path: the secure-boot chain on the device fleet, the update-validation code, the hardware roots of trust. The PKI team takes it across the certificate chain’s route: the CA stack, trust stores, TLS termination points and load balancers, and the embedded TLS stacks riding inside appliances. Vendor-controlled rows go out as vendor inquiries, which is its own discipline (Vendor-Controlled Crypto Surfaces).

The answers come back in 4 kinds, and each kind has a next move:

1. A tested number at or above 3,309 bytes. The system clears. Record the number, the date, and how it was established anyway, because the ceiling belongs in the inventory as a permanent column, next to the answers The Four Questions already collects in the CBOM.
2. A number under 3,309 bytes. Phase 1 scope. An update verifier with a fixed 1,024-byte signature field, a smartcard profile with a 2,048-byte credential budget: whatever the specifics, the system physically cannot hold the new signature, and its remedy is reengineering or replacement on the longest lead time in the program.
3. “Unlimited” or “no hard limit.” Treat as unverified. This answer usually means unmeasured, and the follow-up in the pro tips below separates a genuinely elastic path from one nobody has ever stressed.
4. “We don’t know.” The most common answer. The work it triggers is the point of the exercise: opening the header file, pulling the hardware spec, filing the vendor ticket. A “we don’t know” that converts to a number in a week is worth more than a guess that survives until rollout.

What you walk out with is the list from kind 2, plus every kind-3 and kind-4 row still being converted. That list is Phase 1 scope, and it’s the part of the migration money can’t compress, because a fixed-size field yields to engineering and to nothing else.

Why does a system under the ceiling need reengineering instead of reconfiguration?

Because the ceiling is a structural property of the system, and configuration only changes values inside structures that already exist. A signature field sized at design time lives in the flash layout a bootloader was built around, the parser limit a library compiled in, the record buffer an appliance allocated, or the slot a hardware spec etched into silicon. Turning a knob adjusts what flows through the structure; the structure itself, the thing that’s too small, only changes when someone rebuilds it. That’s why the decision rule says reengineering or replacement, never reconfiguration: for these systems the options are a new firmware image and provisioning cycle, a component swap, or retiring the platform.

No algorithm choice rescues the classical-sized slot either. The smallest finalized post-quantum signature, ML-DSA-44 at 2,420 bytes, overflows it by an order of magnitude, and even FN-DSA-512, the most compact standardization-track option at 666 bytes and still in draft, is roughly 10 times a raw ECDSA signature. A ceiling sized for 64-byte artifacts fails for every option in the portfolio, which is exactly why the systems under it define the program’s critical path. The surface where this bites hardest, firmware and secure boot, has its own full treatment in PQC in Firmware and Code Signing, including why that world often reaches for the hash-based schemes.

Source: NIST FIPS 204 Table 2, FIPS 204; FALCON specification, key and signature sizes, falcon-sign.info.

How do you use the ceiling question in the boardroom?

One level up, the ceiling question converts an abstract migration into an itemized scope, which is the conversion a board actually funds. The deployment is a single move: “We asked our firmware owners and our PKI team one question, the maximum signature size our systems will accept. N systems came back under the 3,309-byte size of the new NIST standard’s signature. Those systems physically cannot accept post-quantum signatures and need reengineering or replacement; their lead time is the critical path of the program, so Phase 1 funds them first.” Every clause in it is a verifiable fact drawn from the estate’s own answers, which is what makes it hard to argue with and easy to minute.

The same list does two more boardroom jobs. It defends the budget line, because “N named systems require reengineering” survives scrutiny in a way “the migration is large” never does. And it sharpens vendor accountability, because every vendor-controlled system on the list turns into a contract question with a date on it: when does the product accept a 3,309-byte signature, and what does the roadmap commit to in writing.

Common misconceptions

1. “The 50x ratio tells you which systems will break.” The ratio compares artifact sizes and says nothing about any particular system. A 3,309-byte signature is a non-event in a system with headroom and fatal in one whose ceiling is lower, and only the per-system ceiling decides which is which. The ratio explains why the question exists; the answers are the scope.
2. “We’ll drop to a smaller parameter set so it fits.” ML-DSA-44 is 2,420 bytes, still roughly 38 times a raw ECDSA signature, so it clears almost none of the ceilings that ML-DSA-65 fails. The parameter set is a security-category decision, and shrinking the category to dodge a buffer inverts the design: the buffer serves the security level, never the reverse.
3. “The datasheet gives a maximum, so we have our answer.” The spec maximum is a promise about the design; the tested maximum is a fact about the shipped system. Parsers, buffer chains, and middleware between the spec and production have their own limits, so the answer that counts is the largest signature actually pushed through end to end.
4. “The ceiling belongs to the certificate alone.” A chain travels through TLS record handling, proxies and load balancers, parser limits, and hardware-module interfaces before any certificate logic runs, and the effective ceiling is the minimum across every hop. Intermediate buffers bite first in practice, which is the same lesson the handshake side keeps teaching in PQC Performance and Size Overhead.
5. “We deployed a post-quantum key exchange, so the system is migrated.” Key establishment protects the conversation’s confidentiality; signatures protect the authenticity of everything the system trusts. A post-quantum handshake wrapped around a classical certificate chain still fails the signature side of the migration, and the signature side is where the ceilings live.
6. “The question waits for the full inventory.” It runs ahead of the inventory as a spot measurement, one email with no tooling, and its answers backfill the CBOM as a column when the inventory catches up. The systems it finds carry the longest lead times in the program, and long-lead work is exactly what starts before the map is complete.

Pro tips

1. Ask for the TESTED maximum, never the datasheet’s. The follow-up wording: “what’s the largest signature this verifier has actually accepted in a test?” A spec sheet describes intent; the number that scopes a migration is one somebody has watched work.
2. When the answer is “unlimited,” ask the second question. “What’s the largest signature anyone has pushed through this end to end?” Genuinely elastic paths exist, and so do paths nobody has ever stressed past a classical payload; the follow-up sorts one from the other in a sentence.
3. Measure the path, per verifier, never per product. A vendor answers for a component; the signature transits a route. The effective ceiling is the minimum across every hop, so the unit of measurement is the full path a signature travels, from the wire to the verifying code.
4. Test the chain payload, since certificates stack. A chain carries several signatures and public keys at once, roughly 5 kilobytes per certificate at ML-DSA-65’s sizes, so a buffer that clears one signature can still choke on the chain. For chain-carrying surfaces, run the test with a realistic full chain.
5. Give the ceiling a permanent home. Record each answer as a dated, evidence-graded column in the inventory next to The Four Questions, because the number is stable, expensive to rediscover, and the first thing the rollout plan asks for.

Where does the ceiling question break?

It breaks on systems with no signature verification in the path, because there the question has nothing to measure. A pre-shared-key OT link, a sensor network authenticating with symmetric MACs, a device that ingests unauthenticated data by design: put the question to those systems and it returns empty, and an empty answer is honest rather than reassuring. Those systems still carry quantum exposure, just through different doors, and they get triaged by the tools built for them, chiefly the key-establishment and monitor lanes of The Two-Lane Split.

The adjacent boundary is key establishment on systems that do verify signatures. The question’s wording deliberately stops at signatures, so the 1,184-byte ML-KEM-768 key in a handshake, and the middleboxes it upsets, stay outside its scope; that size problem has its own diagnostics in PQC Performance and Size Overhead. Run the ceiling question for what it is, a signature-fit instrument, and pair it rather than stretch it.

Questions people ask

Who exactly gets the ceiling question? The firmware owners and the PKI team, by name. In practice that’s whoever owns the secure-boot and update verifiers on the device side, and whoever owns the CA stack, trust stores, and TLS termination on the certificate side. Sending it to both in one email keeps either from assuming the other surface is covered.

Where does the 3,309-byte number come from? It’s the exact signature size of ML-DSA-65, the middle parameter set of NIST’s FIPS 204 standard, per Table 2. ⚠️ The general-purpose-default status is market practice, not a NIST designation: FIPS 204 recommends no parameter set and the phrase “general-purpose” appears nowhere in it. The matching public key is 1,952 bytes.

What if we plan to deploy ML-DSA-87 or SLH-DSA on some surfaces? Then those surfaces test against the larger sizes: 4,627 bytes for ML-DSA-87, and 7,856 bytes and up for the SLH-DSA family. The threshold is always the signature size of the parameter set a surface will actually deploy; 3,309 bytes is the floor for the general-purpose default.

Does the ceiling question cover key exchange too? Its wording covers signatures only. Key establishment has its own size problem, the kilobyte-scale ML-KEM-768 key share in the handshake, with its own failure modes and its own diagnostics, covered in PQC Performance and Size Overhead.

What counts as a passing answer? A tested number at or above the threshold, with evidence of how it was established, recorded in the inventory with a date. “The spec says it’s fine” is a lead worth confirming rather than a pass.

What do we do with the systems on the list? They become Phase 1 scope: reengineering or replacement planning, vendor tickets with dates, and a budget line. They go first because their lead times are the longest in the program, and everything else schedules around them.

Can we compress or split the signature to fit? A signature verifies only as a complete artifact, and its bytes are effectively random, so compression gains nothing and splitting only relocates the buffering problem to reassembly, inside the same memory the ceiling already describes. Systems under the ceiling need the field itself changed.

How long does the exercise take? Asking costs one email. Answering ranges from an afternoon, when the ceiling is a constant in a header file someone can open, to a vendor support cycle, when the number lives behind a contract. The spread in those response times is itself useful data about who controls the estate’s cryptography.

---

Everything here is the map, given freely. When your team needs the ceilings measured across your own estate and the systems under them sequenced into a funded Phase 1, that’s a working session with your team.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.