Post-quantum cryptography readiness services for enterprise teams should produce an executable migration capability, not a list of algorithms. The enterprise first needs to know where public-key cryptography is used, which information must remain confidential for years, which signatures must remain trustworthy, and which products can actually change. Only then can teams select NIST-standardized mechanisms, test protocol and performance effects, coordinate suppliers, and move workloads without interrupting business services. This checklist turns that work into accountable gates with evidence.
The standards position in July 2026 is concrete but still evolving. NIST finalized FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA in August 2024. NIST finalized SP 800-227 for secure KEM use in September 2025 and updated its crypto-agility guidance in June 2026. Other candidates and application protocols continue to develop. Readiness therefore means deploying approved combinations where the surrounding product and protocol support them, while retaining the ability to change. It does not mean inventing cryptography, renaming a classical control “quantum safe,” or waiting for every standard to stop moving.
1. Establish the migration authority and scope
Name an accountable executive, a cryptographic migration lead, and owners from security architecture, identity, network, application, data, infrastructure, procurement, legal and business continuity. Define which decisions the group can make: approved algorithms and libraries, exception acceptance, supplier deadlines, production pilots and retirement of vulnerable mechanisms. Link the program to the enterprise PQC scope and delivery plan so discovery and remediation draw from the same boundary.
Write a policy that distinguishes key establishment, encryption, digital signatures, certificates and symmetric cryptography. Quantum risk does not affect every mechanism in the same way. Public-key schemes such as RSA and elliptic-curve systems are the immediate migration focus; symmetric algorithms and hashes require separate strength and lifecycle analysis rather than automatic replacement. Record regulatory, customer and national-security constraints. If a system must use validated cryptographic modules, confirm the available validation path instead of assuming that an algorithm name alone makes an implementation acceptable.
2. Build an evidence-backed cryptographic inventory
Discover cryptography from several directions. Scan source and configuration, inspect certificates and protocol negotiation, query key-management systems, review load balancers and network appliances, inspect firmware and signing pipelines, and ask vendors for machine-readable inventories. Include outsourced SaaS, managed file transfer, partner APIs, code signing, document signing, backups, archives, authentication tokens, database drivers, VPNs, SSH, TLS, email security, hardware security modules and operational technology. A dependency can contain vulnerable cryptography even when the application team never calls a cryptographic API directly.
Each record needs the business service, technical owner, data protected, purpose, algorithm, key size, library or module, protocol, certificate authority, key location, dependency, environment, replacement method and observed evidence. Add confidence and last-seen dates. Do not confuse a certificate inventory with a cryptographic inventory: certificates show important uses, but not hard-coded keys, application signatures, library defaults or encrypted archives. Reconcile automated discovery with architecture records and sampled traffic, then route unknown findings to an owner.
| Use | Evidence to capture | Migration question |
|---|---|---|
| TLS and service links | Negotiated suites, certificates, libraries and peers | Do both endpoints support an approved transition path? |
| Code and firmware signing | Signer, verifier population, algorithm and trust store | How long must old signatures verify? |
| Stored encrypted data | Data lifetime, wrapping keys and restore path | Must data be re-encrypted or only keys rewrapped? |
| Identity and access | Token, federation, device and certificate dependencies | Can every relying party accept the new signature size? |
| Supplier product | Version, roadmap, module status and contract | Will support arrive before the risk deadline? |
3. Prioritize by exposure, lifetime and replaceability
Rank systems using more than asset criticality. Confidential information with a long remaining secrecy period deserves early attention because an adversary can collect encrypted traffic now and attempt decryption later. Long-lived signatures present a different problem: software, firmware, legal records or identity assertions may need verification after classical signing algorithms are retired. Add internet exposure, number of external peers, safety consequence, key concentration, supplier dependency, maintenance window and expected system retirement. A low-traffic archival gateway can outrank a busy public website if it protects information for decades and cannot be upgraded easily.
Create migration waves. Wave zero covers experiments and test infrastructure. Early production waves should combine meaningful risk with bounded blast radius and capable vendors. Later waves include highly coupled protocols, constrained devices and systems approaching retirement. Do not spend heavily retrofitting an asset that will be decommissioned before its risk deadline; put a funded retirement control against it. Conversely, a planned replacement is not a control until budget, owner, date and dependency exit are credible.
4. Select standards in their real protocol context
Use FIPS 203 ML-KEM for standardized key encapsulation where an applicable protocol and implementation support it. Use FIPS 204 ML-DSA or FIPS 205 SLH-DSA only after matching signature size, performance, assurance and relying-party constraints to the use case. These standards are primitives, not drop-in enterprise architectures. SP 800-227 explains important KEM properties and secure use. Prefer maintained implementations from qualified platform or cryptographic providers; do not implement lattice mathematics in application code.
Decide whether a protocol calls for a pure post-quantum or hybrid transition based on applicable standards, interoperability, policy and threat model. A hybrid can reduce dependence on one component during transition, but it also adds negotiation, implementation and downgrade complexity. Document exactly how secrets are combined and how failure is handled. Never construct an improvised hybrid from two libraries. Track standards status explicitly: selection for future standardization is not equivalent to a final standard, and a draft timeline is not a binding universal deadline.
| Gate | Required proof | Stop condition |
|---|---|---|
| Algorithm | Final standard and approved enterprise profile | Draft-only or invented construction |
| Implementation | Maintained library, provenance and test vectors | Unknown source or divergent output |
| Protocol | Negotiation, downgrade and peer behavior tested | Silent fallback or incompatible endpoint |
| Performance | Handshake, CPU, memory, packet and queue results | Material SLO or capacity breach |
| Operations | Keys, monitoring, rollback and incident runbook | Operators cannot detect or recover failure |
5. Test interoperability, performance and failure
Build a representative lab with real certificate chains, proxies, libraries, hardware modules, constrained links and representative client versions. Test positive exchanges and malformed ciphertexts, invalid signatures, key rotation, certificate renewal, clock problems, partial upgrades, downgrade attempts and disaster recovery. Measure handshake latency, CPU, memory, bandwidth, packet fragmentation, connection establishment, signer throughput, verification throughput and artifact size. Larger keys or signatures can expose limits in message formats, MTUs, databases, logs and hardware that functional happy-path tests miss.
Pilot one end-to-end service, not an isolated library benchmark. Confirm that observability can identify the negotiated mechanism, failures and classical fallback without logging secrets. Exercise rollback only where it does not reintroduce unacceptable exposure. For stored data, restore a real backup and prove key access. For signing, verify a new artifact across the oldest supported clients and verify how previously signed artifacts behave. Preserve test vectors, versions, decisions and defects as reusable evidence for later waves.
6. Make suppliers and procurement part of migration
Ask suppliers where quantum-vulnerable cryptography exists, which product versions support NIST standards, which protocols and parameter sets they use, whether validated modules are available where required, and how keys, upgrades and fallback are managed. Request dates with dependencies rather than a generic “PQC ready” statement. Include firmware signers, certificate services, identity providers, network appliances, payment services, document platforms and SaaS exports. Record end-of-support dates and the enterprise's exit route if delivery slips.
Update procurement templates so new technology exposes cryptographic dependencies, supports inventory, separates algorithms from business logic, permits controlled replacement and supplies security updates for the contracted lifetime. Require notification when a cryptographic component or roadmap changes. Contract language cannot create unavailable engineering capability, but it can prevent another generation of opaque dependencies. Treat acquisition evidence as inventory input and review it at renewal, not only during initial purchase.
7. Roll out in waves and sustain crypto agility
- Approve the use case, standards profile, owners and rollback boundary.
- Verify libraries, modules, protocol support and supplier dependencies in the lab.
- Deploy to internal or low-consequence endpoints and watch negotiation and error telemetry.
- Expand by client, region or service cohort with explicit stop conditions.
- Remove unintended fallback and retire classical keys only after dependent verification.
- Update inventory, diagrams, recovery material and support documentation.
- Re-run discovery to prove the vulnerable use has disappeared and find regressions.
Crypto agility is the durable outcome. NIST describes it as the capability to replace and adapt algorithms across protocols, software, hardware, firmware and infrastructure while preserving security and operations. Centralize approved profiles and discovery, but keep service owners accountable for their use. Track inventory coverage, high-risk uses without plans, peer compatibility, pilot defects, supplier milestones, fallback events and retired vulnerable mechanisms. Counting installed “PQC certificates” is not a useful enterprise outcome if critical signatures, archives and partner links remain unknown.
Key takeaways
- Begin with cryptographic uses and protected-data lifetimes, not algorithm shopping.
- Treat FIPS 203, 204 and 205 as primitives that require secure protocol integration.
- Prioritize harvest-now-decrypt-later exposure, long-lived signatures and hard-to-replace assets.
- Test peer compatibility, message size, failure and recovery before production scale.
- Build inventory, supplier evidence and replaceability into normal technology governance.
Frequently asked questions
Does every enterprise need to deploy PQC immediately?
Every enterprise should begin discovery and prioritization now. Deployment timing depends on data lifetime, threat, protocol readiness, regulatory requirements, suppliers and system retirement. Long-lived confidential data and slow-changing infrastructure usually justify earlier action than short-lived, easily replaceable uses.
Is ML-KEM an encryption algorithm?
No. ML-KEM is a key-encapsulation mechanism used to establish a shared secret. A protocol then uses appropriate symmetric cryptography for encryption and authentication. The protocol construction and implementation are essential to security.
Should teams wait for all vendors and standards?
No. Inventory, data-lifetime analysis, procurement changes, laboratory work and crypto-agility improvements are useful now. Production use should follow final applicable standards and supported implementations, with any draft dependency labeled and isolated from unsupported claims.
Conclusion
Enterprise post-quantum readiness is achieved when the organization can find a vulnerable cryptographic use, explain its risk, select an approved transition, prove interoperability and operational safety, coordinate every relying party and remove the old path with evidence. The 2024–2026 NIST publications make practical work possible today. Use them to create a governed migration factory that can absorb later standards without another emergency inventory.