up:: The Human & Organizational Side MOC
The Turned-Off Test
The turned-off test is a single question you can put to any post-quantum migration status report: what has been switched off? Every metric a migration program reports by default is additive. Endpoints enabled, percentage of traffic negotiating hybrid, systems inventoried, libraries upgraded. All of them climb, all of them are dominated by the easiest parts of the estate, and every one of them is compatible with a classical estate that has changed by nothing at all. Decommissioning is the measure that resists inflation, because a system that has been retired cannot quietly still be running.
The short version:
- Additive metrics can rise for years while the migration completes nothing, since a new path can sit alongside the old one indefinitely.
- The number that cannot be inflated is the count of classical paths, certificates, and systems that have been retired.
- The first real milestone is one protocol in one environment fully crossed with the classical side switched off, rather than a percentage across the whole estate.
- Turning something off requires knowing what depends on it, so the test doubles as a check on whether the inventory is real.
- Report both numbers. Additive progress shows activity, and the retirement count shows completion.
Think about a building replacing its locks. The facilities report says 400 new locks installed, which is true and sounds like progress. The question that tells you whether the building is more secure is how many of the old locks have been removed and how many of the old keys have been collected. Until that second number moves, every old key still opens a door, and the 400 new locks have changed the inventory rather than the risk.
Why do additive metrics keep climbing while nothing finishes?
Because adding a post-quantum path is cheap, reversible, and safe, and removing a classical one is none of those things.
Enabling hybrid key exchange on a service is a configuration change with a clean fallback. Nobody has to prove anything about who depends on the old path, no client breaks, and the number goes up. Switching the classical side off requires knowing every client, integration, embedded device, and forgotten batch job that still negotiates it, and being wrong is an outage. So programs accumulate the first kind of change and defer the second, and the reported percentage rises for years while the classical estate remains fully operational underneath it.
There is a second reason, and it is the one worth naming out loud. Additive numbers are dominated by the easiest 20% of the estate. The public web tier, the modern services, the systems with active teams and current libraries all move first and produce large percentages quickly. The payments path, the embedded fleet, the vendor appliance, and the 15 year old integration nobody owns contribute almost nothing to the count and carry most of the risk. A program reporting 60% coverage has usually finished the easy 20% twice over and touched none of the hard part.
What counts as genuinely turned off?
The classical path is gone rather than deprioritized, and something would break if it came back. Concretely:
| Additive metric | What it can hide | The turned-off equivalent |
|---|---|---|
| Endpoints with hybrid enabled | Every one of those endpoints still negotiates classical on request | Endpoints where the classical algorithm has been removed from the accepted set |
| Percentage of traffic negotiating post-quantum | Traffic follows client capability, so this measures other people’s browsers | Services that would reject a classical-only client |
| Systems inventoried | An inventory is a precondition and moves nothing | Systems whose classical keys have been destroyed under the normal ceremony |
| Certificates issued with new algorithms | The classical issuance path is usually still running beside it | The date classical-only issuance stopped, per Declaring Classical Cryptography End-of-Life |
| Libraries upgraded to a post-quantum capable version | Capability arriving is different from capability being used | Configuration where the classical option is unavailable rather than unused |
The strongest single milestone available to most programs is one protocol, in one environment, fully crossed, with the classical path decommissioned. It is worth far more than a percentage across everything, because it proves the organization can finish, and finishing is the thing nobody has evidence for.
Why does this test double as an inventory check?
Because retiring a path requires knowing everything that still depends on it, and that is exactly what an inventory is for.
The moment a team proposes retiring a classical path, the conversation turns into a list of questions the inventory should already answer: who still connects to this, which embedded clients cannot negotiate the new algorithm, what breaks at 3am, which vendor product is silently pinned to the old suite. If those questions cannot be answered from the CBOM, the inventory is a document rather than an operational asset, and that is a more useful finding than any coverage percentage.
This is why the test is worth running early even when the answer is zero. A retirement count of zero in month 9 is not a scolding, it is a diagnosis: either nothing has been finished, or nobody can prove what depends on what. Both are addressable, and neither is visible in a report full of rising numbers.
Why won’t your vendor report this number?
Because the additive metrics are the ones their product generates, and the retirement number is the one that would show the buyer how little has changed.
A discovery tool reports systems found. A certificate manager reports certificates issued. A library vendor reports capability shipped. Every one of those dashboards states plainly what it measures, and none of them measures completion, because completion happens in the customer’s estate through decisions the product does not make. Asking a vendor for a decommissioning count is a fair question and it usually surfaces the boundary of what the product can actually tell you, which is worth knowing before renewal.
The same caution applies to a consultant’s status report. A program that reports only rising numbers for 18 months is reporting activity, and activity is what an engagement produces most easily.
What do you actually do about it?
- Add one row to the existing status report. Classical paths retired this quarter, cumulative. No new tooling and no new process, and the shape of the program becomes visible within 2 reporting cycles.
- Pick the first retirement deliberately and make it small. One internal protocol in one environment, chosen because its dependents are knowable. The goal is a completed crossing rather than an impressive one.
- Treat a retirement as an event with a record. Cryptographic practice already retires key material with a witnessed, documented, two-person ceremony, so a retired classical path can be closed the same way rather than as a ticket. That makes the count auditable and gives the milestone a weight a dashboard cannot.
- Report both numbers side by side, permanently. Additive progress answers “is work happening” and the retirement count answers “is anything finished.” A board that sees only the first will read year 3 as failure, and a board that sees both can tell the difference between a slow crossing and a stalled one.
- Check the ratio when it looks wrong. A large additive number with a retirement count near zero for more than a year usually means the program has been optimizing the reportable estate, and the fix is a sequencing decision rather than more effort.
Common misconceptions
- “We can decommission at the end.” A migration that defers all retirement to a final phase has no evidence it can retire anything, and the final phase is where the hardest dependents live. The first retirement belongs at the start, on the easiest possible target, precisely because it is a rehearsal.
- “Percentage coverage is the industry standard measure.” It is the most commonly reported measure, and it is dominated by client capability and by the easy estate. Two organizations reporting the same percentage can be in completely different positions.
- “Turning things off increases risk.” Leaving a classical path negotiable is what preserves the exposure the migration exists to remove, and a hybrid endpoint that still accepts classical on request offers an attacker the old path. Retirement is where the risk reduction actually happens.
- “Our inventory is complete, so we know what to turn off.” An inventory that has never been used to answer a dependency question in anger is untested. The first retirement is the test.
- “This makes the numbers look worse.” It makes them accurate, and it protects the program later, because the alternative is a board that believed 70% coverage meant 70% done.
Questions people ask
What is a good retirement count in year 1? Something above zero, on a system whose dependents you could name in advance. The absolute number matters far less than whether the organization has completed the full cycle even once.
Our percentage is high and our retirement count is zero. Is the program failing? It is incomplete rather than failing, and it is in the most common position in the field. The work in front of you is a sequencing decision: pick one bounded path and take it all the way through, including the part where the old option stops being available.
How do we count a system we can never migrate? Separately, and deliberately. Parts of an embedded estate genuinely cannot be updated, and those belong in a documented residual-risk register with compensating controls rather than in either column. Counting them as pending forever quietly corrupts both numbers.
Does turning off classical break older clients? Sometimes, which is exactly why it is the real measure. The work of finding out, notifying, and providing a path is the migration. A number that avoids that work is measuring something else.
Is this the same as crypto-agility? They are adjacent. Crypto-agility is the capability to change algorithms cheaply, and the turned-off test measures whether you have exercised it end to end. An organization can claim agility for years without ever having removed anything.
Should this go to the board? Yes, and it is one of the few migration numbers a board reads correctly without translation. Retired means finished, and everyone understands that without a briefing.
Who should own the number? The accountable migration owner, per Cryptographic Ownership. It has to sit with someone who can decide to retire a system rather than with whoever compiles the report.
Go deeper
- Declaring Classical Cryptography End-of-Life: the dated statement of what is finished, which is what makes a retirement decision possible.
- Operating Through a Long Hybrid Period: why the additive phase runs for years, and how to govern it while it does.
- Cryptographic Bill of Materials (CBOM): the inventory this test quietly audits.
- The Three Numbers: the board-facing figures this one sits beside.
Everything here is the map, given freely. When your team needs the first retirement sequenced and the reporting rebuilt so completion is visible against your actual estate, that’s the work I do.
Last verified 2026-08-19 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.