up:: The Human & Organizational Side MOC

Declaring Classical Cryptography End-of-Life

A cryptographic end-of-life declaration is a dated, signed statement that names which cryptographic practices are finished, which continue unchanged, and when each takes effect. Almost no migration program has one, and its absence explains the most common failure in the field: a roadmap that everyone approved, a budget that was allocated, and a year later nothing has moved. The organization was asked to adopt something new before anyone in authority said the old thing was over.

The short version:

• A migration is two acts, giving something up and taking something on, and the second one cannot happen first.
• The undone act is rarely held by engineers. It sits wherever someone still believes classical cryptography is permanent infrastructure, which is usually the level that controls budget.
• When nobody says what is finished, people decide privately, and the results are predictable: they carry old and new at once, they each keep different things, or they throw out good practice along with the algorithms.
• The declaration has two halves, and the second half does most of the work. What is over, and what specifically is not.
• Naming what continues is how you prevent the discipline being discarded alongside the primitives.

Think about a hospital replacing a drug that has been standard care for 30 years. The pharmacology is settled and the new protocol is written. What actually determines whether wards change practice is whether the chief of medicine has stated, on a date, that the old protocol is withdrawn, and stated equally clearly which parts of the surrounding practice are unchanged. Without both halves, half the wards run both protocols and the other half quietly abandon procedures nobody asked them to abandon.

What is a cryptographic end-of-life declaration?

A short governance document, signed at the level that can actually retire things, that converts a general sense of “we should migrate eventually” into a dated fact about your own estate. It is not a roadmap and it is not an architecture decision. Those describe what you are building. This describes what you are stopping.

It answers three questions in writing, per named system rather than in general:

The half	What it names	Why it has to be explicit
What is over	Issuing classical-only certificates past a stated date, shipping new services without algorithm agility, treating key length as the strength axis	Until a date exists, every team can defer indefinitely without ever refusing anything
What is not over	Defense in depth, key management discipline, two-person integrity, chain of custody, threat modeling, the named classical paths that keep running until a stated date	Prevents the discarding of practice that was never the problem
Who signed it	One accountable owner with the authority to retire systems, per Cryptographic Ownership	An unsigned statement is a suggestion, and suggestions lose to delivery work

The document is usually one page. Its value is entirely in being dated and signed, because that is what a team can point to when the migration competes with the work they are measured on.

Why does a migration stall before anyone resists it?

Because a beginning depends on an ending, and the ending is a decision nobody scheduled.

William Bridges made the structural version of this argument in Managing Transitions: a change is situational and happens on a date you set, while the transition to it is internal and runs on its own clock. His central claim is that transitions start with an ending rather than a beginning, and that leading with the new thing extends the old one, because people who have not been permitted to let go hear the announcement as an instruction that their loss is not on the agenda.

The cryptographic version is sharper than his corporate cases, and worse, for a reason that is easy to miss. In an ordinary reorganization the ending is forced by the situation, since the old structure is dissolved whether anyone accepts it or not. Classical cryptography is dissolved by nothing. RSA and ECC keep working perfectly, by every measure an operations team can observe, on the morning after the roadmap is approved and on every morning after that. So the ending has to be made deliberately, by people whose daily experience contradicts the need for it.

That is why the stall so often looks like a resourcing problem. The budget appears and goes underspent, the inventory runs 18 months long, the pilot stays perpetually next quarter, and none of it presents as opposition, because nobody is opposing anything.

Where does the unmade ending actually sit?

Not with the engineers, which is where programs usually go looking.

The engineers can see the estate and generally accept that the primitives have a service life. The belief that has not been given up is the one that makes deferral feel safe, and it lives wherever the budget is set. As long as the person funding the program privately holds that cryptography is settled infrastructure that could reasonably be revisited next year, the migration competes every quarter against the option of waiting, and it loses every time, because waiting has no attributable cost and acting does.

The diagnostic is uncomfortable and quick. Ask whoever funds the program to state, in one sentence and with a date, what is now finished. If the answer is a target architecture or a compliance obligation, the ending has not been made. Those describe what is being built and what is being required, and neither of them retires anything.

Why won’t your vendor tell you about this?

Because their product is the beginning, and the ending is the part with no line item.

A vendor sells discovery, inventory, a certificate manager, or a library. Every one of those is something added, and every one can be deployed on top of an organization that has never conceded anything, which is why they can be sold into a stalled program without the stall being mentioned. Naming the ending would also mean telling a buyer that the constraint sits above the buying decision, in a room the vendor is not in, and that no product will move it.

The same incentive runs through most advisory work in this field. A roadmap is a deliverable that can be produced without asking anyone to give anything up, and it survives a slide review. A statement of what is now over has to be argued for, signed, and defended when a team invokes it against a delivery deadline.

What are the three ways an unnamed ending shows up?

Bridges identified three responses to an ending that leadership never articulated, and each one leaves a visible mark in the work itself. All three are common in migration programs now, and all three are routinely misdiagnosed as resourcing or discipline problems.

1. Carrying both. Nobody dares stop doing anything, so hybrid paths are stood up and classical paths run indefinitely because no one was told which is retired or when. This one hides inside the word hybrid, which makes running both sound like architecture rather than avoidance. The tell is that decommissioning counts stay at zero while endpoint counts climb.
2. Everyone deciding privately. Each team picks its own answer, so one runs hybrid, one goes straight to ML-KEM, one waits for a vendor, and one does nothing. In cryptography this produces genuine interoperability failures rather than merely uneven adoption, which makes it more expensive here than in the organizational cases Bridges was writing about.
3. Discarding good practice with the algorithms. The opposite failure, and the reason the second half of the declaration exists. Teams strip out classical paths prematurely, drop layered defenses, or abandon operational rigor because nobody said which parts were still required.

Source: William Bridges with Susan Bridges, Managing Transitions: Making the Most of Change, chapter 3.

What do you actually do about it?

Write the declaration before the next roadmap revision, and keep it to one page.

• Name a date, per system, for what stops. Certificate issuance policy is the highest-value place to start, because an issuance system still writing long-lived classical certificates contradicts every statement of urgency the program has made, and everyone technical can see it.
• Write the second half with more care than the first. What carries forward is the operational discipline: key ceremony rigor, two-person integrity, rotation cadence, witnessed destruction, chain of custody. None of it is algorithm-specific, and all of it is scarcer than cryptographic knowledge.
• Say out loud that the old algorithms held for decades. The natural rhetoric of change is that the old way was bad, and in a room of senior practitioners that reads as a verdict on their careers. RSA was the right choice in 1995 for the same reason it is the wrong one now, which is that primitives are chosen on the best available public analysis and are always understood to have a service life.
• Mark the retirement with the ceremony this profession already has. Cryptographic practice is unusual in owning a respected, non-embarrassing ritual for endings, because key destruction is already witnessed, documented, two-person, and signed. A retired root or a final classical-only issuance can be closed the same way rather than as a ticket, and nobody would call that soft.
• Get it signed by the person who funds it, not by the security function, because the ending you need is the budget-holder’s.

Common misconceptions

• “We approved the roadmap, so the decision is made.” A roadmap commits to building something. It says nothing about what stops, which is why teams can approve one and change nothing.
• “The deadline in the regulation is the ending.” A compliance date is an external obligation. It creates urgency and it does not tell anyone in your organization which of your systems is finished, so it produces reporting rather than retirement.
• “Announcing the target architecture covers this.” Announcing the new thing to people who have not been told the old thing is over is the sequence that reliably produces a stall.
• “This is a soft, cultural exercise.” It is a dated governance artifact with named systems and a signature. The soft version, an all-hands about embracing change, is the thing that does not work.
• “Declaring an ending means ripping out classical crypto.” The declaration exists to prevent exactly that. The half that names what continues is what keeps hybrid paths and layered defenses in place on purpose rather than by accident.

Questions people ask

Who signs this? The person who controls the budget for the migration, ideally alongside the accountable executive owner. A signature from the security function alone reproduces the ownership gap, because security usually owns the risk without owning the engineers or the contracts.

Is one page really enough? Yes, and the brevity is functional. The document has to be readable by a team lead deciding whether migration work outranks a delivery commitment this week. A 40 page policy cannot do that job.

What if we cannot commit to dates yet? Then commit to the dates you can and name the rest as undated with a review point. An honest partial declaration outperforms a complete one nobody signs, and the parts you can date are usually issuance policy and new-service requirements, which are the two that change behavior fastest.

Does this apply if our migration is going well? Programs that are moving usually have an informal version already, held by one senior person who has been saying it in meetings for a year. Writing it down protects the program from that person leaving.

How is this different from a policy update? A policy states a rule going forward. This states that something specific is finished, on a date, and names what survives it. Most policy updates only do the first half, which is what produces the discarding failure above.

What if leadership refuses to sign? That refusal is the most useful diagnostic in the whole program, because it tells you the ending has not been made and that no amount of roadmap revision will produce motion. The work in front of you is the concession, not the architecture.

Does the declaration expire? It should carry a review date like any other governance artifact, particularly the parts naming classical paths that continue, since those are the entries most likely to be quietly extended forever.

Go deeper

• Cryptographic Ownership: who holds the authority to sign a declaration like this, and why the seat is usually empty.
• Why Post-Quantum Migrations Stall: the wider anatomy of a stall and the 80/20 that explains it.
• Change Management for Cryptographic Migration: what happens after the ending is made, and the reversible first moves that get people acting.
• Operating Through a Long Hybrid Period: the decade between the ending and any arrival, and how to make it survivable.

---

Everything here is the map, given freely. When your team needs the declaration written, argued, and signed against your actual estate, that’s the work I do.

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