Post-quantum cryptography readiness is an operating decision, not a request to install a fashionable library. A credible plan connects the business information worth protecting, its confidentiality and trust lifetime, the protocols and products that use public-key cryptography, and the people who can authorize a change. It also preserves a recovery path when a peer, certificate profile, hardware module, archive, or customer integration cannot accept the new representation.
NIST has finalized ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for stateless hash-based signatures. Readiness work should not treat those names as a migration plan. The practical first step is an evidence-backed inventory and a bounded pilot that can reveal algorithm use, data lifetime, format size, interoperability, performance, fallback, and ownership. Unknowns should stay visible rather than being turned into a fixed procurement promise.
Set the cryptographic risk and outcome
Begin with a service, data flow, or trust decision that matters to the organization. Ask whether the concern is long-lived confidentiality, authentication of software and identities, signed records, device enrollment, customer connectivity, or a combination. Identify the information owner and the action the system must continue to support. A migration that changes algorithms but breaks a regulated archive, partner handshake, or emergency recovery path is not ready.
Agree on evidence before choosing a vendor. A useful record names the current algorithm and purpose, protocol, implementation, key location, peer population, data lifetime, dependency owner, target outcome, acceptable performance change, and rollback authority. Teams planning the sequence can use the PQC migration guide for ML-KEM, ML-DSA, and SLH-DSA as a companion, but the decision record must remain specific to the service being changed.
| Question | Evidence | Accountable role |
|---|---|---|
| What must remain confidential? | Data class, retention period, exposure window, and archive path | Information owner |
| What must be authenticated? | Signer, verifier, certificate chain, device, or software release | Identity or product security owner |
| Where is public-key cryptography used? | Protocol, library, product, hardware module, configuration, and peer | Platform architect |
| What can change safely? | Compatibility boundary, test fixture, fallback, and rollback condition | Service owner |
| What proves completion? | Interoperability, performance, audit, recovery, and approval evidence | Risk and release owner |
Build a cryptographic inventory that can drive action
A spreadsheet of certificates is too narrow. Trace cryptographic use through source code, service configuration, certificates, key-management systems, endpoints, message formats, backups, signing pipelines, embedded devices, and supplier products. Record both direct use and inherited use: a service may not name an algorithm because a TLS library, identity provider, database driver, or hardware appliance chooses it. Capture the version and evidence date so an owner can distinguish a verified dependency from an assumption.
A cryptographic bill of materials becomes useful when each entry has a purpose, consumer, owner, data or trust lifetime, dependency relationship, change path, and test status. Link the record to an interface or asset rather than storing a loose product name. Mark unknowns, prioritize them, and set a date for resolution. Inventory quality matters more than the appearance of completeness.
| Inventory field | Why it matters | Example evidence |
|---|---|---|
| Purpose and primitive | Separates key establishment, encryption, signing, hashing, and authentication decisions | Protocol specification, code path, or configuration |
| Implementation and version | Shows where updates, validation, and performance constraints reside | Library, provider, firmware, module, or managed service record |
| Peer and format | Exposes interoperability and message-size boundaries | Certificate profile, handshake, envelope, API, or partner contract |
| Lifetime and exposure | Prioritizes data that must remain confidential or signatures that must remain trusted | Retention policy, archive, key rotation, and threat assessment |
| Owner and recovery | Makes migration and incident response possible after the pilot | Named team, rollback procedure, backup, and approval record |
Prioritize by data lifetime and trust lifetime
Do not rank systems only by whether they are internet-facing. A low-volume archive can deserve earlier attention if information must remain confidential for decades. A signing system may deserve a different path because future verification must distinguish an authentic historical artifact from a changed record. Consider capture risk, confidentiality duration, credential or certificate lifetime, replacement lead time, customer dependency, and the cost of testing a new representation.
Use tiers to sequence discovery and migration, not to declare a system safe. High-priority candidates often combine long-lived sensitive data with a public-key boundary that is hard to replace quickly. Medium-priority candidates may have shorter retention but many partners or embedded implementations. Lower-priority candidates still need an owner and an expiry date for the decision. Revisit the ranking when data retention, suppliers, protocols, or standards change.
| Priority band | Typical signal | First action |
|---|---|---|
| Immediate discovery | Long-lived sensitive data, public exposure, or replacement lead time is high | Confirm inventory, owner, peer constraints, and a bounded migration experiment |
| Planned migration | Known vulnerable use with manageable retention or a stable partner set | Add an interface change, test matrix, supplier commitment, and target window |
| Monitor and prepare | Lower exposure or replaceable component, but dependency is not yet verified | Record the use, test crypto-agility hooks, and review at a defined date |
| Out of scope with reason | No relevant public-key use or data has been appropriately de-identified | Document the evidence, decision owner, and conditions that reopen scope |
Separate key establishment from signatures
ML-KEM and digital-signature standards solve different problems. FIPS 203 specifies ML-KEM as a key-encapsulation mechanism used to establish a shared secret over a public channel; it is not a drop-in replacement for a signature. FIPS 204 specifies ML-DSA for generating and verifying signatures, while FIPS 205 specifies SLH-DSA, another signature approach with different implementation and size trade-offs. Map each current use to the right function before comparing products.
This distinction changes the test plan. A secure-channel pilot needs handshake, certificate, key-derivation, peer, and session-recovery checks. A signing pilot needs key custody, signature size, verification libraries, canonicalization, timestamping, archival validation, and revocation or replacement procedures. Do not accept a vendor claim that one supported algorithm proves every cryptographic boundary is migration-ready.
Design for crypto agility before the migration wave
Crypto agility is the ability to change an algorithm, parameter, key, or implementation without redesigning the entire service. Put algorithm choice behind a versioned interface, make supported suites explicit, separate policy from code, and record the selected suite with each durable artifact where verification depends on it. Keep independent controls for key generation, storage, rotation, authorization, and destruction. An abstraction that hides the suite but cannot expose its version is not sufficient for investigation or recovery.
Test the uncomfortable cases: a peer supports only the previous suite, a message becomes larger, a middlebox rejects an extension, a certificate chain is too large, a hardware module lacks the implementation, or a rollback leaves mixed versions in flight. The crypto-agility testing guide can support the test design. Every fallback must be bounded, observable, approved, and protected against downgrade.
Sequence a bounded migration instead of a big-bang cutover
Choose one representative path with a cooperative peer and a reversible change. Establish a baseline for handshake time, CPU, memory, message size, connection failure, signature verification, archive access, and support effort. Introduce the new suite behind an explicit policy, first in a test environment, then with a small production cohort or non-critical interface. Preserve a way to compare old and new outcomes without sending sensitive data into an uncontrolled test service.
Use staged gates: inventory verified, implementation reviewed, interoperability passed, performance budget accepted, downgrade resistance tested, observability enabled, rollback rehearsed, and owner sign-off recorded. Coordinate with vendors and customers early because a migration may require firmware, operating-system, browser, certificate, protocol, or contract changes outside the service team. A roadmap that has no external dependency dates is an aspiration rather than a delivery plan.
Test interoperability, archives, and recovery under real constraints
Build a matrix of implementations, parameters, peers, transport versions, certificate chains, message sizes, device classes, and failure responses. Exercise normal negotiation, unsupported-suite handling, malformed input, timeouts, retransmission, key rotation, certificate renewal, and partial rollout. Validate both sides of the boundary: a client accepting a new handshake does not prove the server, gateway, monitoring, or support tooling can operate it.
For signed records, verify that a future operator can identify the signer, validate the signature, resolve the algorithm identifier, retrieve the right public key, and detect tampering after migration. For encrypted data, verify restoration, rekeying, key destruction, and access during an incident. Record whether a fallback preserves confidentiality and authentication or merely keeps traffic moving. A recovery path that loses audit meaning is not a safe fallback.
Govern rollout, supplier evidence, and ongoing review
Make the inventory, risk tier, chosen standard, implementation version, test result, exception, owner, and target date reviewable. Ask suppliers for supported algorithms, parameter sets, validation status, upgrade path, interoperability evidence, key-management boundaries, telemetry, incident response, and end-of-support dates. Treat a roadmap or marketing statement as an input to verification, not as evidence that the customer path works.
Track coverage of known cryptographic uses, unresolved high-priority records, tested peer combinations, failed or downgraded negotiations, signature verification failures, recovery-test results, and exceptions past their review date. NIST’s current project guidance says organizations should begin migration while the standardization process continues; that does not remove the need for local risk acceptance, version tracking, and reassessment as standards and implementations evolve.
Key takeaways
- Start with data lifetime, trust lifetime, exposure, and replacement lead time.
- Inventory algorithms by purpose, implementation, peer, format, owner, and recovery path.
- Keep ML-KEM key establishment distinct from ML-DSA and SLH-DSA signatures.
- Build crypto agility before a migration wave and test every fallback for downgrade risk.
- Pilot one bounded path with real peers, size limits, archives, hardware, and support controls.
- Treat supplier roadmaps, interoperability, evidence, and review dates as delivery work.
Frequently asked questions
What does post-quantum cryptography readiness mean?
It means an organization knows where relevant public-key cryptography is used, which data or trust relationships are exposed, what change is appropriate, how peers will interoperate, and how the service will recover. It is a service-specific evidence state, not a blanket certification.
Is ML-KEM a replacement for digital signatures?
No. ML-KEM is a key-encapsulation mechanism for establishing a shared secret. Digital-signature use cases require a signature standard such as ML-DSA or SLH-DSA, selected with the right verification, size, lifecycle, and archive requirements.
Should every system switch to a post-quantum suite at once?
No. Sequence by risk and dependency readiness. A bounded pilot with cooperative peers, clear rollback, and measurable evidence exposes compatibility and operational work before a broader rollout. Any hybrid or fallback mode must be explicitly governed and tested against downgrade.
Is a certificate inventory enough?
No. Readiness also requires libraries, protocols, code paths, hardware, signed artifacts, archives, suppliers, peers, keys, parameters, data lifetime, and recovery ownership. A certificate list can be one input to a broader cryptographic inventory.
Conclusion
A practical post-quantum cryptography readiness program makes uncertainty visible and turns it into sequenced evidence. Inventory real use, prioritize by lifetime and exposure, separate key establishment from signatures, build crypto agility, test real peers and archives, and govern every exception. The result is a migration path that can be reviewed and recovered, not a one-time algorithm announcement.