PQC readiness: the first five actions

Start with decisions you can verify

These five actions are a recommended starting sequence, not a report of what every enterprise is doing. Name a technical lead and bring service owners, PKI operators, software teams, and procurement into the work. The first inventory determines which pilots make sense; supplier engagement can begin alongside discovery.

NIST's initial PQC standards are final, but an algorithm standard is one part of an operational system. Use the migration guide for detailed architecture and the trust calendar for scoped dates. Your first milestone is evidence that a selected change works, with an owner for what remains blocked.

1. Build an inventory that reaches beyond certificates

Combine certificate discovery, application and library records, network observations, device documentation, and supplier disclosures. Include VPNs, storage and key-management services, signing systems, firmware verification, and partner connections. Record algorithm and parameters, implementation version, purpose, owner, location, dependent consumers, evidence date, and replacement constraints.

Identify information with long confidentiality requirements and products that cannot easily receive new cryptography. Record uncertainty instead of interpreting a scan's silence as proof that no cryptography exists.

2. Test hybrid key establishment on a priority TLS path

Select a path carrying sensitive information whose clients and intermediaries you can test. Enable a supported TLS 1.3 hybrid group through the platform's documented configuration. RFC 10024, published in August 2026, specifies groups including X25519MLKEM768. Confirm the exact negotiated group; TLS 1.3 by itself is not evidence of post-quantum key establishment.

Measure failures, latency, and fallback. Check each TLS segment when a proxy terminates the connection. Hybrid key establishment addresses future decryption risk for protected sessions; it does not convert certificate signatures or recover the confidentiality of previously captured traffic.

3. Run a controlled ML-DSA private-PKI pilot

Choose a use case with a documented certificate profile and known relying applications. Verify support for final ML-DSA, required encodings, key protection, and certificate-chain processing before issuing pilot credentials. RFC 9881 defines ML-DSA identifiers for X.509; support must still be proven in your applications.

Exercise issuance, deployment, renewal, revocation handling, and trust updates in an isolated cohort. Investigate pre-standard Dilithium credentials separately. A CA's ability to issue a certificate does not establish universal interoperability or public browser trust.

4. Rehearse a software-signing transition

Select an internal artifact with an identified signer and verifier. Test a supported PQC signature format across signing infrastructure, artifact storage, deployment tools, and final verification. Include installers, operating-system policy, bootloaders, or update agents if they participate. The build team may control only part of this chain.

Practice key rotation, invalid-signature rejection, and recovery from a bad release. If evaluating stateful hash-based signatures, review NIST SP 800-208 and its state-management constraints; they require more than choosing an algorithm name.

5. Put cryptographic change into supplier requirements

Translate the backlog into procurement requirements with named versions and measurable acceptance criteria. Ask for algorithm-update support across the product lifetime, cryptographic dependency disclosure on material changes, deprecation notice, and a supported migration route. Require delivery milestones and evidence instead of a general PQC-ready label.

Have procurement and counsel turn the requirements into appropriate terms, including support, cost, and remedies. A roadmap can inform planning; track the actual commitment against the systems that depend on it.

Review evidence before expanding

At the next program review, show the owned inventory, observed pilot results, remaining compatibility gaps, and supplier commitments. Select the next cohort from risk and readiness together. Shared certificate automation helps, while each protocol, signature, and product transition retains its own acceptance gate.

Questions to take back to your team

• Which first pilot reduces a documented exposure and has consumers we can test?
• What observation would show that the intended protection is absent despite a successful connection?
• Which supplier or verifier determines the earliest feasible production migration?

Sources & further reading

1. CISA, NIST, and NSA: preparing for PQCInventory, roadmap, supplier engagement, and prioritization recommendations.
2. IETF RFC 10024: hybrid key agreement for TLS 1.3Standardized hybrid groups, including X25519MLKEM768.
3. NIST FIPS 204: ML-DSAFinal digital-signature standard and current implementation notices.
4. IETF RFC 9881: ML-DSA in X.509Certificate algorithm identifiers, encodings, and key usage.
5. NIST SP 800-208: stateful hash-based signaturesSpecial operational requirements for stateful signature schemes.