Marin Ivezic
The lesson SHA-1 already taught
NIST’s 2011 transition guidance, SP 800-131A, set SHA-1 as disallowed for digital signature generation after 2013, while verification of existing signatures and some MAC and KDF uses remained allowed. In December 2022 the agency set a final retirement date of December 31, 2030, close to two decades after the first serious warnings about the algorithm. SHA-1 did not last that long on cryptographic merit. It lasted because it was embedded in protocols, appliances, signed firmware images and partner integrations that no single team owned and no single team could change alone.
That history is the honest baseline for post-quantum planning. Crypto-agility, as the term is normally used, means the ability to replace one cryptographic algorithm with another quickly and cleanly. Most enterprise estates have never demonstrated that ability once.
Why the swap model breaks
Cryptography is distributed across TLS stacks, hardware roots of trust, key management systems, signed firmware, certificate hierarchies and the systems of counterparties you don’t control. Upgrading a cipher suite on your side achieves nothing if the other endpoint cannot negotiate it.
Three constraints appear in almost every architecture review:
- Counterparty coordination. A handshake takes two implementations. Payment networks, EDI links and B2B APIs move at the speed of the slowest participant.
- Legacy operational technology. Industrial controllers and metering devices often run cryptography compiled into firmware, on hardware with a twenty-year service life and no field-upgradable image.
- Immutable trust anchors. A trust anchor is the key or certificate a device treats as authoritative by construction. Burn an RSA-2048 public key into a device’s ROM and no software update will teach that device to validate a post-quantum signature.
Engineering teams have tried the plug-in route before. Efforts to make platform TLS stacks accept drop-in algorithm modules produced defects, performance regressions and interoperability failures rather than agility. Cryptographic primitives differ in key size, message size, failure modes and timing behaviour, and the surrounding protocol usually assumes the old ones.
Detection, decision, deployment
There is a more useful capability than swap speed. Call it the speed at which cryptographic weakness gets found, assessed and reduced, using whatever control is available. That reframing raises the bar on what an architect is accountable for, and it produces work that can start this quarter.
Continuous detection
You can’t mitigate what you haven’t found. The artefact here is a cryptography bill of materials, or CBOM: an inventory recording which algorithms and key lengths are in use, in which system, protecting which data, with which owner and which upgrade path.
Regulators reached this conclusion first. OMB memorandum M-23-02 required United States federal agencies to submit prioritized inventories of cryptographic systems before it asked them to migrate anything.
A workable inventory pulls from several sources at once: network and TLS telemetry, source and binary scanning, certificate management systems, hardware security module configurations, and reconciliation against the configuration management database. Expect the first pass to be incomplete. Hard-coded keys in application code, cryptography inside purchased appliances, and anything a vendor treats as a black box are the usual blind spots, and they are worth logging as open items rather than leaving out.
Decision under constraint
Discovery produces a queue, and the queue is longer than the migration budget. Triage runs on four questions. How long does this data need to stay confidential? Is the traffic reachable from outside? Can the algorithm be replaced without a counterparty agreeing? What breaks if the change goes wrong?
The first question is the one architects tend to skip. Harvest now, decrypt later describes an adversary recording encrypted traffic today and decrypting it once a cryptographically relevant quantum computer exists. Data with a fifteen-year confidentiality requirement on an internet-facing link is exposed to that pattern now. The same algorithm on an internal batch job between two hosts in one rack is not exposed in the same way, and can wait.
Public timelines give the outer bound. NIST IR 8547, released as an initial public draft in November 2024, proposes deprecating RSA-2048 and 256-bit elliptic curve cryptography after 2030 and disallowing them after 2035. Anything that cannot be migrated by then needs a compensating control designed now, not a note in a risk register.
Tooling helps with the correlation work. Matching a CBOM against asset criticality, data retention schedules and threat intelligence is exactly the kind of join that analysis software does faster than a working group. Treat the output as a ranked candidate list for human review. Cryptographic controls in production are not a good place for automated change without an approval step.
Mitigations that deploy without a rewrite
Four patterns reduce risk while replacement remains out of reach. They combine, and none of them is a substitute for eventual migration.
Hybrid key establishment
Hybrid key establishment derives a session key from two independent key exchanges and mixes both results, so the session stays secure while either one holds. In practice that means pairing a classical elliptic-curve exchange with a post-quantum key encapsulation mechanism, most commonly ML-KEM, standardized by NIST from the scheme formerly called CRYSTALS-Kyber. Hybrid key exchange combining X25519 with ML-KEM-768 is already carried by mainstream browsers and content delivery networks, which makes this the least exotic item on the list.
Overlay encryption
When the inner system cannot change, wrap the link. A quantum-resistant tunnel between two network appliances protects everything inside it, including a legacy protocol negotiating an algorithm you would rather not run. Endpoints see no difference. Two limits are worth stating plainly to stakeholders: the overlay protects data in transit only, and the inner weakness remains for anyone already inside the tunnel.
Segmentation and policy enforcement
Where neither replacement nor an overlay is available, contain the exposure. Put the device in a segment with tight access control and monitoring, and enforce cryptographic policy at the proxies and firewalls around it, blocking any negotiation that falls back to a disallowed suite. This fixes nothing cryptographically. It shrinks the set of parties who can reach the weakness.
Trust-anchor bridging
A cryptographic gateway speaks the new algorithm on one side and the old one on the other. It terminates a post-quantum TLS session externally and re-encrypts to the legacy controller in the cipher that controller understands. Cross-signing a new issuing CA with an existing trusted root does something similar for devices with a fixed trust anchor, giving them an alternate chain up to a key they already accept. The cost is architectural and should be recorded as such: the gateway sees plaintext, so it becomes a high-value target and inherits the assurance requirements of everything behind it.
Governance and the skills to run it
None of this survives as a project. Cryptographic risk needs a line in the risk register, a named owner, a review cadence, and contract language obliging vendors to publish a post-quantum roadmap with dates.
It also needs architects who can interrogate what they’re sold. Vendor claims about “quantum-safe” products are uneven, and the difference between a product that negotiates ML-KEM and a product that mentions it in a datasheet is a question of engineering detail. Reading that difference is now part of the architect’s job, and we treat it as core material rather than an advanced elective.
Building the capability
We treat the post-quantum transition as the first real test of continuous cryptographic risk management, and it won’t be the last. The measure that counts is whether a cryptographic weakness announced on a Tuesday can be located in your estate, assessed against business impact, and reduced by a deployable control within days. A target date for removing RSA everywhere is a weaker measure, because it says nothing about the algorithm after that one.
For migration methodology and the underlying frameworks, see pqcframework.org. For deeper technical background on the argument behind this piece, see the original analysis on PostQuantum.com.
Quantum Academy’s post-quantum programs are built for architects who own these decisions: cryptographic inventory and CBOM construction, hybrid deployment patterns, and the governance structures that keep the work running after the first migration wave. You can review the current programs and enroll at quantumacademy.com/.