up:: Migration Architecture MOC

The Exit Question

The exit question is the question asked of the architects before signing off on any hybrid rollout, in these words: “who owns turning the classical algorithm off, and on what date is that scheduled?” The subject of the question is the switch-off of the old algorithm, rather than the switch-on of the new one, because a hybrid deployment stands the post-quantum algorithm up beside the classical one and the classical one is still there when the applause ends. An owner and a date on the record at approval time converts a program with a start and no defined end into a program with a deadline someone is accountable for, and asking costs one sentence in the approval meeting.

The component that rides inside the question is the definition of done it enforces: migrated means the classical algorithm is off, and “hybrid is deployed” describes a milestone in the middle of the job.

The short version:

• Ask it before approving any hybrid rollout, in these words: who owns turning the classical algorithm off, and on what date is that scheduled?
• The question targets the off switch. Turning post-quantum on is the fast half everyone does; retiring the classical algorithm is the slow half almost nobody schedules, and it’s the half that ends the exposure.
• Hybrid moves the deadline by zero days. CNSA 2.0 is explicit that even where hybrid is used for interoperability, the classical algorithm on its own stops being approved on the same mandatory date it always had.
• Asked at approval, the answer goes into the same document that authorizes the spend, so the removal work inherits a budget, an owner, and an audit trail. Asked after go-live, it’s a new program nobody funded.
• Where a hard date would be dishonest, the form is a scheduled review date with named criteria and the owner intact, stated as exactly that.

Think of the sidewalk scaffolding that goes up around a building for a facade repair. It exists to protect people during the transition, it’s the right call, and it was always meant to come down when the work finished. Walk through any large city and you’ll pass scaffolding that has stood for years after its permit’s purpose ended, because putting it up was a funded project with a completion party and taking it down was a line item nobody owned. Hybrid cryptography is scaffolding. The organizations that end up living under it for a decade are the ones that approved the erection without scheduling the removal.

What is the exit question?

The exit question is a named decision-support tool with two required outputs and a definition of done riding inside it. It’s asked once, at a specific moment: when a hybrid rollout plan is in front of whoever signs it, before the signature lands. The wording is deliberate, and it’s worth using verbatim, because every softer phrasing gets answered with the go-live date.

1. The owner. A named role, on the record, accountable for retiring the classical algorithm from the surfaces this rollout covers. A role rather than an individual, so a reorg reassigns the duty instead of orphaning it.
2. The date. A calendar date, or where a hard date would be dishonest, a scheduled review date with named criteria (covered below in where the question breaks down). Either way it’s written into the approval record, with the reasoning attached.

The definition of done that the question enforces comes from the mechanics of hybrid itself. A hybrid key exchange runs the classical and post-quantum algorithms together and derives the key from both, so the connection holds if either half survives. That design is the right call during the transition, and the classical half is the exact thing a cryptographically relevant quantum computer breaks, so the migration’s endpoint is the classical component retiring and the post-quantum algorithm standing alone. You are migrated when the classical algorithm is off, rather than when the new one comes on. That principle has its own full treatment in Deprecation, Not Deployment; the exit question is the tool that installs it into a program at the only moment installation is cheap.

The question applies to any approval that puts a hybrid mechanism into production: a TLS edge rollout, a VPN estate moving to hybrid IKEv2, an SSH fleet, a vendor product with a hybrid mode. It does something useful even outside hybrid proper, since any dual-stack period where old and new cryptography run side by side has the same missing-ending failure mode. It has nothing to ask on a system going straight to standalone post-quantum algorithms, because there’s no classical half to retire, and nothing to ask on symmetric-only surfaces, where the transition is a key-length and hash-choice story rather than an algorithm swap.

Why does hybrid buy zero time?

“Hybrid buys us time” is the belief the exit question exists to catch, and it fails on both of the clocks a program answers to. The precise mechanics matter, because the claim sounds plausible in a meeting and each half of it dissolves under one paragraph of scrutiny.

On the compliance clock, the mandate text closes the door. CNSA 2.0 does not require hybrid for national security systems, expresses confidence in the standalone post-quantum algorithms, and allows hybrid mainly for interoperability. It then closes the obvious escape route: even where a hybrid deployment is allowed or required for interoperability, CNSA 2.0 becomes mandatory to select at the stated date, and choosing a classical CNSA 1.0 algorithm on its own stops being approved. Hybrid keeps you interoperable on the way to the deadline, and the deadline stays exactly where it was. The civilian schedule reads the same way: NIST IR 8547 deprecates the 112-bit-strength classical public-key algorithms after 2030 and disallows classical RSA, ECC, and Diffie-Hellman schemes after 2035, dates that measure when the classical algorithm is gone rather than when a post-quantum one appeared beside it. Those dates are draft and can shift; the shape of the requirement is removal either way.

Source: NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ,” CSI_CNSA_2.0_FAQ.

Source: NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” November 2024, §4.

On the threat clock, the classical half was never the thing defending you. The hedge in a hybrid points the other way: hybrid exists to protect against a flaw in the young post-quantum algorithm, with the battle-tested classical algorithm standing behind it. Against the quantum adversary the roles reverse completely, because on the day a capable machine exists the classical component of every hybrid connection contributes nothing, and the post-quantum half is doing all the work alone. The IETF design goal says it precisely: the hybrid secret “remains secure as long as one of the component key exchange mechanisms remains unbroken,” and against a quantum attacker the unbroken component is the post-quantum one. So a hybrid session is exactly as quantum-safe as its post-quantum half, and running the classical half beside it adds zero days to any timeline the quantum threat sets.

Source: Stebila, Fluhrer, Gueron, “Hybrid key exchange in TLS 1.3,” IETF, draft-ietf-tls-hybrid-design, published as RFC 9954 in July 2026.

And the recorded-traffic story sets the stakes on finishing. Deploying hybrid genuinely closes the harvest-now-decrypt-later window on new sessions, which is the real and immediate value of doing it. It changes nothing about the two exposures that remain. Traffic recorded before the rollout, under classical-only key exchange, sits in the adversary’s archive in its original ciphertext, and hybrid can’t reach backward to it. And for as long as the classical path stays reachable after the rollout, some fraction of connections keeps falling back to classical-only, because a peer that can’t carry the hybrid group negotiates the old one and the connection succeeds, quietly feeding the same archive. Turning the classical algorithm off is what shuts the recording off, which is why the exit is the security event and the deployment is the preparation for it.

Why ask at approval rather than after the rollout?

Because approval is the only moment when the answer costs a sentence, and every month after go-live it costs more. The mechanics of that price curve are concrete.

1. The approval document is the one artifact with leverage. The memo that authorizes the spend is read by finance, audit, and every successor who inherits the program. A sentence in it, “classical key exchange retired from these surfaces by this date, owner named,” makes the removal part of what was approved, so the budget cycles that follow carry it by default. After go-live, the same ask is a new program competing for new money against projects with visible upside.
2. Go-live is where rollout plans end, by design. The plan terminates at the milestone that demos well and closes the ticket, the team disperses to the next project, and the institutional memory of “we still have to turn the old one off” walks out with it. The retirement of the classical algorithm, the actual finish line, is left with no owner and no date, which means the program has a start and no defined end. That’s the mechanism behind organizations sitting in dual-stack for a decade, and it’s a scheduling failure rather than a technical one. Why Post-Quantum Migrations Stall covers the general pattern; the exit question is the one-sentence inoculation against this instance of it.
3. The classical tail only grows while you wait. Every quarter of dual-stack operation adds integrations built against endpoints that still offer classical negotiation, partners who onboarded during the window, and contracts renewed without a post-quantum clause. Each addition is a future conversation with a team or a vendor who would rather skip it. Asking at approval freezes the size of that list on the cheapest day it will ever have.

The asymmetry is the whole mechanic: settling the exit now costs a sentence, and discovering later that nobody settled it costs years. There is no equivalent moment after approval where the question regains that price.

What happens with and without the exit on record?

Run the same generic rollout forward both ways. A mid-size company approves hybrid TLS at its edge in 2026: X25519MLKEM768 on the load balancers and public endpoints, the standard move, executed competently in both branches. The only difference between the branches is one sentence in the approval memo.

Without the exit on record:

1. 2026, the rollout is approved on a plan that ends at go-live. Hybrid ships, the dashboard turns green, and the board hears “post-quantum is deployed at the edge.”
2. 2027, the project team is reassigned. Classical groups are still in every supported_groups list, because removing them was never in scope, and some slice of traffic quietly negotiates classical-only with older peers. Nobody is measuring which slice.
3. 2028 through 2030, new partner integrations onboard against endpoints that offer classical negotiation, and vendor contracts renew without a retirement clause. The classical tail grows in the dark.
4. 2030, the NIST IR 8547 deprecation line arrives. Someone asks who owns removing the classical groups, and the answer is that the org chart has no such box. Standing the removal program up now means new budget, an inventory rebuilt from scratch, and partner conversations that start years late, against a countdown.
5. The years after, the company is in dual-stack purgatory: paying to run, patch, monitor, and audit both algorithm families, with the 2035 disallowance date approaching and the hardest conversations still unopened.

With the exit on record:

1. 2026, the same rollout is approved, and the memo carries one added sentence: classical key exchange retired from the edge by a stated date inside the mandate window, owner, the network security lead role, with the removal work assigned a budget year.
2. 2027, hybrid ships identically. The difference is that the owner now runs a standing count of classical-only negotiations from the edge telemetry, because the exit criterion is a wire fact (Wire Over Config).
3. 2028 through 2029, the fallback share shrinks deliberately: laggard partners get dated notice tied to contract renewals, procurement adds the retirement clause to everything that renews, and the last classical dependencies get names and plans instead of staying anonymous.
4. On the scheduled date, classical groups come out of the configuration, the wire count confirms zero classical negotiations, and the change closes against the same approval record the auditors already hold.
5. The program ends. That’s the entire difference: it was built with an ending, so it reached one.

Program property	Without the exit on record	With an owner and a date
Where the plan ends	Go-live, the milestone that demos well	Classical algorithm off, confirmed on the wire
Owner of classical retirement	Nobody, discovered years later	A named role, from day one
Board reporting	”Post-quantum deployed,” overstating the state	Deployment reported as a milestone, exit date reported beside it
Budget for removal	Unfunded future ask, competing as a new program	Carried in the original approval, inherited by budget cycles
The classical tail	Grows unmeasured until a mandate forces the count	Measured continuously, shrunk deliberately
Mandate dates (NIST IR 8547, CNSA 2.0)	Arrive as a crisis	Arrive as a formality the program already met
End state	Dual-stack purgatory, both stacks paid for indefinitely	A finished migration, one stack

Common misconceptions

• “Hybrid is the destination.” Hybrid is the vehicle, and the mandates name the destination as standalone post-quantum cryptography with the classical algorithms removed. CNSA 2.0 expresses confidence in the standalone algorithms and treats hybrid as an interoperability accommodation, and the IR 8547 schedule is written in terms of classical algorithms exiting. A hybrid estate in 2036 is an unfinished migration, whatever the dashboard says.
• “We deployed hybrid, so we’re migrated.” Migrated means the classical algorithm is off. Hybrid-on is the fast half of the job, and reporting it as completion describes the easy half while hiding the hard one. The full case for measuring by removal lives in Deprecation, Not Deployment.
• “The exit date is engineering’s problem.” A large share of the classical tail lives in contracts rather than configurations: vendor appliances whose off switch ships in a future firmware, managed services whose roadmap you can only influence at renewal, partner integrations governed by agreements. For those surfaces the exit date is set at the negotiating table, so it belongs on procurement’s calendar as much as in engineering’s backlog, and an exit plan that never looped procurement in has silently excluded the slowest half of the estate.
• “Hybrid buys us time.” It buys scrutiny time for the young post-quantum algorithm, which is real, and it buys zero time against either clock that matters: the mandate dates hold regardless, and the quantum threat only ever engages the post-quantum half. Treating hybrid as breathing room is how a program donates its first 2 years.
• “We’ll set the exit once the rollout stabilizes.” The leverage lives in the approval document, and it expires when the signature lands. After stabilization the ask is a new program, the team that held the context is gone, and the classical tail has been growing the whole time. Later is precisely the moment the question was designed to avoid.
• “One exit date covers the estate.” Exits are per surface. An edge TLS estate you control can carry a hard date; a vendor appliance exits on a renewal cycle; the signature plane exits on the slower composite-certificate track. One honest date per surface beats one impressive date for the estate, because the single date is always either dishonest for the slow surfaces or slack for the fast ones.
• “Asking the exit question means we’re against hybrid.” The question assumes hybrid is being approved, and deploying it is the right call for exactly the reasons in Hybrid Cryptography. The question is how hybrid ends well. The people most invested in hybrid’s success should want the exit on record most, because a hybrid that never ends is the failure mode that discredits the whole approach.

Pro tips

• Put the exit in the same approval document, never a separate ticket. A ticket can be closed, deprioritized, or orphaned by a reorg, and its disappearance is silent. The approval memo is permanent, discoverable, and read by auditors and successors, so the exit clause survives every personnel change the program will see. If the exit lives anywhere other than the document that authorized the rollout, assume it lives nowhere.
• Name a role and attach a budget year. An owner without removal budget is a well-wisher. The sentence that works names the role, the date, and the budget year the removal work lands in, which is also the tell when the question is answered evasively: a date nobody can place in a budget year is a wish wearing a calendar entry.
• Where a hard date would be dishonest, tie the exit to a trigger with named criteria. For surfaces gated on an ecosystem, write the exit as a condition plus a review cadence: for example, classical-only negotiation below a stated share of connections for 2 consecutive quarters, reviewed quarterly by the owner, with the mandate date as the outer bound. That’s a real exit plan stated honestly, and it keeps the owner and the record while admitting the date is conditional.
• Define “off” as a wire fact. The exit criterion is the classical group absent from negotiated-traffic counts over a stated window, per Wire Over Config, because a config flag says what’s permitted and the wire says what happened. A retirement confirmed only in configuration is a claim; the capture is the receipt.
• Set the date against both clocks. The mandate date is the outer bound, and for surfaces carrying long-lived confidential data the exit sits earlier, because the harvest exposure runs until the classical path closes. The Two-Clock Test is the instrument for stating both dates side by side before you pick the exit.
• Ask the follow-up when the first answer is the go-live date. It will be, reliably, because go-live is the date the plan contains. Restate the question: the date post-quantum turns on is already in the plan, and the question names the date the classical algorithm turns off. The second answer, or the silence where it should be, is the actual finding.

Where does the exit question break down?

The question assumes someone in the room can schedule the off switch, and there are surfaces where nobody can, honestly. The tool’s integrity depends on saying so plainly rather than extracting a fake date.

Long-tail client ecosystems. A public-facing TLS surface serving old clients can’t hard-date classical removal without deciding to strand every peer that can’t negotiate the hybrid group, and for a business that’s a revenue decision rather than a cryptographic one. The form of the exit there is the trigger-and-review structure: named criteria (fallback share thresholds, mandate movement, client-population data), a review cadence, an owner, and the mandate date as the outer bound. A scheduled review date with criteria is a real answer. A confident hard date that everyone privately knows will slip is worse than the version, because the first silent slip teaches the organization that exit dates are decorative.

Vendor-sealed surfaces. Where the classical algorithm lives inside a product only the vendor can change, the off switch is theirs, and the exit question transforms into procurement language: on what date does the product retire classical negotiation, written into the renewal, with support-window consequences attached. The owner is still yours to name; the date arrives by contract rather than by change window.

Planes where the replacement path is still maturing. Hybrid key exchange is deployed at internet scale, and the signature plane runs years behind it: composite certificates and the post-quantum PKI around them are still working through standardization and validation. Scheduling a hard date to retire classical signatures before the replacement path is standardized, validated, and supported by your issuers would be fiction. The exit for that plane is staged behind named ecosystem milestones, reviewed on a cadence, which is the same honest structure as the long-tail case.

And the boundary of the tool itself. The question has no work to do where there’s no classical half to retire: a green-field system going straight to standalone ML-KEM, or a symmetric-only surface. Asking it there is ceremony, and spending the question’s credibility on ceremony makes it easier to wave off where it bites.

How do you use the exit question in a boardroom?

Deploy it whenever hybrid progress is offered as migration completion, which in an executive setting happens on a schedule: the quarterly deck that says “post-quantum deployed,” the vendor pitch that says “we support hybrid,” the program update where the green milestones are all deployment milestones. The wield-upward form is the question verbatim, one level up: “who owns turning the classical algorithm off, and on what date is that scheduled?”

The answers sort the room cleanly. A program that produces an owner and a date, or an owner and an honest trigger-with-review, is a migration with an ending, and the board can track it like any other dated commitment. A program that answers with the go-live date, or with “that’s phase 2,” has just told the board it’s running an open-ended dual-stack commitment with no one accountable for closing it, and that the number it reports as progress measures the algorithm that was added rather than the exposure that remains.

There’s a governance edge to this beyond program hygiene. Board minutes that record hybrid deployment as “migration complete” become representations, the kind regulators, auditors, and counterparties later read back, and the mandates those representations will be measured against define completion as the classical algorithm being gone. Directors who ask the exit question are protecting the accuracy of the record they’re personally attached to, which is why the question belongs to them and travels up as naturally as it travels down.

Questions people ask

Is the exit question an argument against deploying hybrid? The opposite. Hybrid is the right call for the two reasons that made it the internet’s default, insurance against a flaw in the young post-quantum algorithms and compatibility with peers that upgrade on their own schedule. The question takes the deployment as given and secures the one thing the deployment plan reliably omits, which is its ending.

What date should the exit actually be? Per surface, the latest defensible anchor is the mandate that binds you, with NIST IR 8547’s draft 2030 deprecation and 2035 disallowance as the civilian shape and CNSA 2.0’s staged exclusivity dates for national security systems. Surfaces carrying long-lived confidential data earn an earlier date, because their harvest exposure runs until the classical path closes. The defensible answer is a per-surface date with its reasoning attached rather than one estate-wide year.

Who should own the exit? A role with authority over the negotiation policy of the surface in question, network security for an edge estate, the platform owner for internal services, procurement for vendor-controlled surfaces. The test is whether the role can actually cause the classical path to close, because an owner without that authority is a reporting arrangement rather than an accountability.

What if the architects can’t give a date? That answer is the finding, and it’s a valuable one to get before signing rather than after. It usually means the exit depends on something unowned, a vendor, a partner population, a budget that was never requested. Convert it on the spot to the form: an owner, named criteria for what would make a date settable, and a scheduled review, all in the approval record.

Doesn’t the mandate deadline already function as our exit date? A mandate binds you to a date; it staffs and funds nothing. Every organization subject to the 2035 disallowance is equally bound, and the ones that will meet it are the ones where a specific role has owned the removal work for years by then. The exit question is how the mandate date gets an owner inside your walls.

How do we verify the classical algorithm is actually off? On the wire. The exit closes when the negotiated-traffic counts from your termination points show the classical groups at zero over a stated window, which is a packet-level fact rather than a configuration claim. Wire Over Config specifies the pull, and it’s the same instrument that measures the fallback share shrinking while the exit approaches.

Does the exit question apply to signatures and PKI too? Yes, as its own question with its own, later date. Key exchange and authentication migrate on separate tracks, and the signature plane’s exit waits on composite certificates and post-quantum PKI maturing, so its honest form today is usually the trigger-and-review structure. A plan that quotes one exit date for both planes has averaged two very different timelines into a number that’s wrong for each.

What does dual-stack actually cost while it runs? Both algorithm families stay deployed, patched, monitored, and audited, handshakes carry both key shares, every compliance cycle inventories both, and the fallback path remains a live exposure feeding the harvest archive. Each cost is tolerable in any given quarter, which is exactly why an unscheduled dual-stack period extends itself indefinitely: no single quarter ever forces the ending the approval never set.

Does one sentence at approval really change the outcome? The sentence changes what the program is. With it, removal is part of the approved scope, carried by the same budget and audit machinery as the rollout itself. Without it, removal is a future proposal with no sponsor. Organizations reliably finish what the approval document says they started, and the exit question’s entire mechanism is making the finish line part of what got started.

---

Everything here is the map, given freely. The question costs a sentence, and answering it across a real estate, every surface mapped, every classical dependency dated, every owner named, is the work I do. When your rollout is waiting on that answer, see how engagements are scoped.

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