PQC migration: build the ability to change cryptography

Make the next cryptographic change manageable

A useful post-quantum cryptography program produces an owned inventory, a ranked migration backlog, and evidence that selected systems can change algorithms without losing their essential function. This guide is for security leaders, architects, and service owners building that program. Start with access to application inventories, network and certificate observations, software dependencies, and the people who can approve changes.

Crypto agility means preserving security and operation while adapting cryptography. NIST's current crypto-agility guidance describes work across protocols, applications, software, hardware, and infrastructure. Certificate automation supplies part of this capability; migration can still require application changes, new trust anchors, or replacement hardware. The architecture below is a recommended operating model, not a claim that one product makes every transition automatic.

Separate the cryptographic jobs

NIST finalized FIPS 203, 204, and 205 in August 2024. They define algorithms for different jobs. An application supporting one of these standards does not automatically support the others, their certificate formats, or the necessary protocol integration.

Rank exposure before selecting a pilot

The joint CISA, NSA, and NIST quantum-readiness guidance identifies the risk of recording encrypted information for later decryption. For planning, ask how long information must remain confidential and how long its systems will take to migrate. A future quantum attack date is uncertain; data sensitivity and equipment replacement lead times are things you can investigate now.

Separate confidentiality exposure from future signature forgery. A captured connection, an encrypted archive, and a firmware verifier have different dependencies. Renewing a certificate does not retroactively protect captured traffic. For archives, examine data encryption, key wrapping, key custody, retained copies, and restore procedures before choosing a re-encryption strategy. Changing an archive today cannot recall a copy already taken.

Give priority to sensitive data paths and systems with difficult upgrade paths. Record the business consequence, accountable owner, supported lifetime, external dependencies, and migration blocker. Use these records to explain why a device family or a specific partner connection precedes a more convenient laboratory demonstration.

Apply the right timetable to the right systems

Executive Order 14412 directs federal high-value assets and high-impact systems, excluding National Security Systems, toward PQC key establishment by 31 December 2030 and digital signatures by 31 December 2031. It also directs contractor rulemaking. Check resulting rules and actual contract terms before treating a procurement target as an obligation.

National Security Systems have a separate CNSA 2.0 transition. NSA's FAQ covers new acquisitions from January 2027. Equipment and services unable to support CNSA 2.0 face phaseout by 31 December 2030; mandated algorithm use follows by 31 December 2031, with stated exceptions and validation requirements. These scopes do not create one universal commercial deadline.

Public TLS lifetime reductions create nearer operational milestones. Use that renewal work to improve discovery, ownership, and deployment, while keeping each PQC workstream's compatibility and security acceptance criteria explicit.

Close the gaps a library upgrade leaves behind

• Incomplete discovery: certificate scans omit cryptography inside application code, VPNs, storage systems, firmware, and supplier components. Combine observations with dependency records and owner review; document blind spots.
• Unmapped consumers: the issuer or signer supports a new algorithm, but an appliance, client library, bootloader, or partner cannot process it. Maintain a consumer compatibility matrix.
• Unproven deployment: a replacement credential exists in a management tool but never reaches the running service. Verify from the consumer's side.
• Unmanaged trust updates: key rotation works, but distributing a new trust anchor or changing a verification policy has no tested procedure.
• Supplier uncertainty: a roadmap says PQC without naming versions, profiles, validation status, delivery dates, or unsupported products. Turn each gap into a tracked dependency.

Connect six operating capabilities

A cryptographic bill of materials records cryptographic components and dependencies. Connect supplier disclosures to observed assets and implementation versions, so a library update or end-of-support notice reaches the right migration owner.

These capabilities may span several teams and services. Define who resolves a failure across the application, automation system, certificate authority, and supplier. Evaluate integration and accountability directly; common ownership alone does not prove reliability or portability.

Use pilots to expose the migration cost

For TLS, choose a representative path with known clients and intermediaries. Record negotiated groups, failed connections, latency, and fallback behavior. Verify the origin connection separately when a proxy terminates TLS. TLS 1.3 alone does not establish that a post-quantum mechanism was negotiated.

For signatures, start where the team can update both producer and consumer. RFC 9881 specifies ML-DSA identifiers for X.509, but a private CA issuing an ML-DSA certificate does not prove universal interoperability. Exercise chain validation, revocation handling, artifact formats, key storage, and older verifiers. Treat pre-standard Dilithium implementations as a compatibility investigation.

Software signing pilots must include installers, deployment agents, operating systems, and device boot or update verification where relevant. Owning the build pipeline does not imply control of every verifier. Approve production expansion only after the full supported consumer set and recovery path pass.

Fund a roadmap with evidence gates

Set dates from your actual dependencies and applicable obligations. Avoid a universal sequence such as archives first or public TLS last: the first useful migration is the highest-priority path that can meet its acceptance criteria.

1. Establish ownership and scope. Name the executive sponsor, technical lead, participating service owners, and decision process for exceptions.
2. Baseline exposure. Inventory priority systems, identify long-lived information and hard-to-update products, and request supplier evidence. Publish known coverage gaps.
3. Run representative pilots. Test one confidentiality path and one signature path where appropriate. Capture integration work and performance constraints before estimating the wider rollout.
4. Migrate approved cohorts. Group systems by shared dependencies and support requirements. Expand after observed acceptance, then retire transitional settings deliberately.
5. Sustain the capability. Refresh inventory after releases, review standards and implementation notices, rehearse recovery, and revisit the backlog when supplier support changes.

Assess readiness through observable evidence

Use this ladder as a discussion aid. Report inventory coverage, priority paths protected, blocked dependencies, and time to complete a tested change. A declining classical-certificate count alone can conceal unchanged key establishment, unsupported verifiers, or an incomplete trust chain.

Questions to take back to your team

• Which information must remain confidential longest, and which system takes longest to change?
• What exact algorithm, protocol profile, implementation version, and validation evidence does the supplier support?
• Which consumers fail when a new key, signature, certificate chain, or trust anchor is introduced?
• Can we observe successful deployment and detect unexpected fallback on every priority path?
• Who owns recovery when a migration crosses application, PKI, network, and supplier boundaries?
• What evidence must pass before the next cohort moves into production?

Sources & further reading

1. NIST FIPS 203: ML-KEMKey-encapsulation standard; review the publication's current errata when selecting implementations.
2. NIST FIPS 204: ML-DSADigital-signature standard, including current implementation notices.
3. NIST FIPS 205: SLH-DSAStateless hash-based digital signatures.
4. IETF RFC 10024: hybrid key agreement for TLS 1.3Published August 2026; specifies three ECDHE and ML-KEM hybrid groups.
5. IETF RFC 9881: ML-DSA in X.509Algorithm identifiers and encoding rules do not establish support in every relying application.
6. NIST CSWP 39, updated: considerations for crypto agilityCurrent version includes updates through 29 June 2026.
7. CISA, NIST, and NSA: preparing for PQCJoint recommendations on inventory, supplier engagement, and migration priorities.
8. Executive Order 14412: advanced cryptographic attacksSections 4 and 6 distinguish federal priority-system dates from contractor rulemaking.
9. NSA CNSA 2.0 FAQ, version 2.1National Security System acquisition, equipment, algorithm-use, and validation requirements.
10. CA/Browser Forum TLS Baseline RequirementsPublic TLS validity and validation-reuse schedule; distinct from PQC deployment requirements.