Post-Quantum Cryptography Migration Readiness: The CISO Decisions to Make Before 2027

Executive summary

Post-quantum cryptography migration belongs in the CISO’s investment and risk agenda, not just the cryptography team’s backlog. NIST released its first three final PQC standards in August 2024. The joint CISA, NSA and NIST migration factsheet recommends roadmaps, cryptographic inventories, risk assessment and vendor engagement.[1] [2]

The decision before 2027 is not whether to replace every cryptographic component immediately. It is whether the organisation can identify its exposed dependencies, explain what matters most, and fund a controlled transition.

Start with long-lived sensitive data and critical trust functions. Assign accountable owners, challenge supplier claims, and run prioritised pilots with explicit acceptance criteria. Report demonstrated coverage and unresolved gaps separately. A procurement label is not evidence that an entire service has migrated.

Define the scope without overstating the threat

This article does not predict when a cryptographically relevant quantum computer will exist. Current encryption is not universally broken, and not all encryption is at issue. CISA’s PQC Initiative describes preparation for future threats to widely used encryption and digital signature algorithms, rather than a present failure of all cryptography.[3]

The immediate migration focus is quantum-vulnerable public-key key establishment and digital signatures. These functions establish shared secrets or support authenticity and integrity. Symmetric encryption and hashing belong in the wider cryptographic inventory, but should not be treated as if they have the same migration problem.[4]

NIST’s August 2024 standards separate these functions: FIPS 203 specifies ML-KEM, a key-encapsulation mechanism; FIPS 204 specifies ML-DSA for digital signatures; and FIPS 205 specifies SLH-DSA, another digital signature scheme.[1] ML-KEM is not a blanket replacement for the symmetric algorithm encrypting application data.

This distinction changes the questions a CISO should ask. A service might establish a session secret using PQC while continuing to authenticate certificates through traditional signatures. CISA’s January 2026 product-category guidance explicitly notes that most listed widely available categories have implemented PQC for key encapsulation or agreement, but not widely for signatures and authentication.[4]

Therefore, define the target by service and cryptographic function. “Protect this confidential transfer path” is an actionable objective. “Make the enterprise quantum-safe” is too vague to support architecture approval or reliable reporting.

Put governance ahead of an enterprise rollout

Name one executive sponsor and one programme owner. Security architecture should lead technical policy, but cannot decide data sensitivity, replace unsupported equipment or renegotiate contracts alone. Include data owners, infrastructure, application engineering, procurement, legal and operational technology teams where relevant. The joint migration factsheet recommends a project management team and involvement from procurement and risk managers.[2]

Agree decision rights before tools arrive. Who approves algorithm and protocol profiles? Who accepts a temporary compatibility exception? Who funds replacement when a supplier cannot support the required transition? Who can stop a pilot that threatens service availability?

Use a single risk register with service-level entries. Each entry should connect a cryptographic dependency to a business consequence, accountable owner, treatment option and review date. Keep an uncertainty field. Unknown embedded cryptography is a discovery gap, not a reason to mark a system compliant or automatically declare it unsafe.

Separate enterprise policy from external obligations. Before treating any government timetable as binding, legal and compliance leaders should confirm its applicability to the organisation and its contracts. The readiness case here rests on risk and implementation lead time, not an invented universal deadline.

Authorise discovery and testing as a defined first investment. Do not request an enterprise replacement budget based on a guessed device count. Set a review gate at which evidence determines the next funding decision.

Discover cryptographic dependencies, not just certificates

An asset inventory is a starting point, not a cryptographic inventory. The joint factsheet recommends discovery across network protocols, endpoints, servers, application libraries, firmware and software updates, and development pipelines. It also warns that tools may not identify cryptography embedded inside products.[2]

Use several evidence sources. Review certificate records and network observations alongside application dependencies, configuration exports and supplier disclosures. Reconcile them to business services. A scanner finding that cannot be connected to an owner or data flow is not yet a migration decision.

For each priority service, record the cryptographic function, algorithm or scheme, implementation version, protocol profile, trust dependency, supplier and configuration. Add the data classification, required protection lifetime, replacement route and confidence in the evidence. Record where encryption terminates and resumes, rather than assuming an encrypted connection protects every subsequent hop.

For example, review a hypothetical sensitive research transfer from client to gateway, gateway to application, and application to storage. Establish which component negotiates keys, which verifies identity, and which signs updates. A successful test on the external connection says nothing about the other paths unless those paths were assessed too.

Discovery must also cover dormant dependencies: recovery environments, infrequently used integrations and retained equipment. Schedule approved observation windows for less visible services. In safety-sensitive environments, agree non-disruptive collection methods with operations before scanning.

NCCoE’s Bill Newhouse explained the visibility problem in the June 2024 migration webinar:

“Not very many organizations have a complete picture” of their dependency on public-key cryptography.[6]

Treat the inventory as maintained evidence. Add a refresh trigger for significant releases, acquisitions and configuration changes. Otherwise, a carefully assembled baseline becomes historical documentation before the migration programme can use it.

Prioritise by sensitivity lifetime and replacement difficulty

“Harvest now, decrypt later” describes the possibility that an adversary collects protected data today for later decryption. The joint factsheet makes long secrecy lifetime a reason for early preparation and recommends correlating cryptographic use with sensitive datasets and their required protection periods.[2]

Ask business owners a concrete question: how long would disclosure still cause material harm? Retention periods alone do not answer it. Research, negotiations or personal information can have different confidentiality needs even when stored in the same platform. Record the rationale and uncertainty rather than assigning a standard lifetime to every dataset.

Newhouse’s first-hand NCCoE discussion similarly asks whether intercepted data would remain sensitive years later.[6] The useful management lesson is to compare the protection need with migration lead time, without pretending to know a quantum-computer arrival date.

Assess signature-dependent processes separately. Firmware verification, software distribution and certificate infrastructure concern trust and integrity, not only future disclosure. The joint factsheet includes digital signature creation and validation, including software and firmware updates, in discovery and prioritisation.[2]

Start with services combining material consequences, long protection needs and difficult replacement. Identify renewal dates and maintenance windows that could make change easier. Keep risk rank separate from pilot suitability: a low-impact service may be a good test environment without being the most urgent migration target.

Do not defer every difficult dependency until suppliers improve. Assign a treatment path now: supported upgrade, architectural change, replacement, or documented temporary risk acceptance with a review date.

Make vendor claims specific and contractual

CISA’s 2026 product guidance is useful for framing procurement conversations. It distinguishes categories with widely available PQC-capable products from categories where implementation and testing are encouraged. Its lists are not exhaustive, and automated cryptographic discovery tools and non-traditional IT categories such as OT and IoT are outside their scope.[4]

PQC capable is not the same as full coverage or certification. The guidance also notes that a procured PQC-supporting product may still use non-PQC algorithms for interoperability.[4] Ask for evidence of what is deployed and active, not merely what is present in a library.

Keep the questionnaire focused:

• Which released product version, cryptographic functions and protocol profiles support the required standards? What remains traditional?
• Is support enabled in our deployment model, regions and configuration? Which dependencies or counterparties constrain it?
• How are negotiation, fallback, monitoring and rollback handled? Can we prove which scheme a connection actually used?
• What validation or certification is claimed, and what exact implementation, module version and operating environment does the evidence cover?
• What changes are needed for updates, recovery, administration and integrations? What are the upgrade costs and support commitments?

The joint factsheet recommends engaging suppliers on migration roadmaps and planning changes to existing and future contracts, including updates, costs and delivery expectations.[2] Translate answers into acceptance evidence, support responsibilities and milestone reviews. Distinguish a shipping capability from a roadmap commitment.

For cloud services, define the boundary of the claim. Does it cover the client connection, internal service traffic, application interfaces, or key management? Ask what remains the customer’s responsibility and how deployment changes will be communicated.

There are no vendor endorsements here. Product assurance must be validated for the actual configuration and use case. Procurement should make that validation possible through access to documentation, supported test environments and clear escalation arrangements.

Build agility and test complete service paths

NIST defines crypto agility as the capability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.[5] That is a stronger objective than supporting one additional algorithm.

Translate it into architecture criteria. Avoid unnecessary algorithm hard-coding. Use maintained cryptographic interfaces, controlled configuration and documented dependencies. Preserve visibility into active choices. Flexibility without policy control can create a larger set of insecure or unsupported combinations.

NIST’s guidance warns that negotiation needs integrity protection against downgrade attacks. It also explains that PQC public keys, signatures and key-encapsulation ciphertext can be much larger than current equivalents.[5] Performance and interoperability therefore require evidence from the intended service path, not assumptions based on a successful algorithm demonstration.

The NCCoE migration project separates discovery from interoperability testing and describes resolving compatibility issues in controlled, non-production environments.[7] Start there. Reproduce representative clients, gateways, certificate chains and partner endpoints before considering deployment.

Set acceptance criteria before running tests. Measure handshake completion, tail latency, CPU and memory use, message sizes and behaviour under constrained bandwidth or packet loss. Check observability, recovery and approved rollback. A fast average can conceal failures affecting older clients or less common integrations.

A hybrid scheme combining traditional and PQC components may be appropriate in some transitions, but it is not automatically simpler or sufficient. NIST notes both its potential security value and added protocol complexity.[5] Require a supported profile and review its security properties rather than designing an ad hoc combination.

Keep key-establishment and signature results separate. Pilot success means a defined configuration met defined criteria. It does not establish enterprise-wide coverage, product certification or permission to skip change control.

Give the board a decision pack, not a completion percentage

A board needs enough evidence to choose investment, sequencing and risk acceptance. Use a concise pack for the highest-priority services, with supporting technical records available outside the board paper.

Avoid a single “percentage migrated” unless the denominator and coverage definition are explicit. Report inventory confidence, priority-service test evidence, supplier gaps and outstanding exceptions. Separate planned, enabled, tested and approved states.

Ask for a specific next decision. Funding two bounded pilots is a different choice from approving replacements or accepting an unsupported dependency. Keeping those choices distinct makes oversight more useful.

A decision-oriented 90-day plan

The first 90 days should produce a defensible starting sequence, not a claim that migration is complete. Adapt the scope to staffing and service complexity.

Days 1–30: Set ownership and establish the baseline

Appoint the sponsor and programme owner. Agree scope, evidence standards and exception authority. Select an initial group of services based on business impact and data protection lifetime. Combine available discovery records with owner interviews and supplier disclosures.

Decision gate: Approve the baseline’s limitations and fund the most consequential discovery gaps. Require a named owner and next action for every material unknown. Do not imply completeness merely because automated collection has finished.

Days 31–60: Choose pilots and obtain supplier evidence

Rank migration priorities separately from test candidates. Select a manageable key-establishment pilot on a sensitive transfer path and, where feasible, a separate signature-focused pilot. Confirm released support, dependency readiness and a safe non-production environment.

Have procurement turn supplier responses into a gap assessment. Agree measurable acceptance criteria with operations, including compatibility, performance, failure handling and rollback.

Decision gate: Authorise only pilots with a supported technical path, accountable engineers and realistic success criteria. Where no credible route exists, choose a replacement investigation or a dated exception instead.

Days 61–90: Test and decide the next investment

Execute approved tests and document the exact versions, configurations and counterparties. Record failures and unresolved questions as carefully as successful results. Review evidence with service owners, architecture and risk leadership.

Decision gate: Present the board pack. Recommend bounded progression, remediation or deferral for each pilot. Assign the next funding requirement, owner and review date. Carry remaining traditional functions into the risk register rather than hiding them behind the pilot’s success.

Frequently asked questions

Must every cryptographic component change immediately?

No. Start by distinguishing public-key key establishment and signatures from wider cryptography. Use discovery, sensitivity lifetime and operational impact to prioritise changes. CISA’s migration factsheet recommends that risk-based preparation.[2]

Does a PQC-capable purchase complete migration?

No. Capability may cover only selected functions and may remain inactive or use traditional algorithms for compatibility. CISA explicitly identifies these limitations.[4] Validate actual configuration, coverage and applicable assurance evidence.

What if a critical supplier has no supported route?

Document the dependency and consequence. Seek a dated, testable roadmap, assess alternatives and require accountable risk acceptance where migration must wait. A promise without scope or acceptance evidence should not count as completed treatment.

Conclusion: Make readiness an accountable decision

Before 2027, the CISO should be able to identify priority cryptographic dependencies, explain why their order matters, and show who owns the next decision. That is a more credible starting point than a broad assurance of quantum readiness.

The work is specific: discover the cryptography behind important services, establish sensitivity lifetimes, secure usable supplier evidence and test supported configurations. Build agility so subsequent changes do not require another programme from scratch.

Post-quantum cryptography migration needs neither an arrival-date prediction nor an indiscriminate replacement campaign. It needs evidence that supports controlled investment, operationally sound changes and honest reporting of what remains unresolved.

Related resources

When preparing the decision pack, the CISO board report template offers a structure for translating technical findings into business risk, accountable actions and a clear executive choice.

The CISO Toolkit provides broader risk-register and vendor-assessment resources that can support programme governance. Adapt them to cryptographic functions and evidence requirements rather than treating them as PQC certification checklists.

For a board briefing or leadership workshop requiring a defined audience and decision objective, the Executive Enquiry page provides the existing engagement route.

References

1. NIST Releases First 3 Finalized Post-Quantum Encryption Standards
2. Quantum-Readiness: Migration to Post-Quantum Cryptography
3. CISA Post-Quantum Cryptography Initiative
4. Product Categories for Technologies That Use Post-Quantum Cryptography Standards
5. Considerations for Achieving Crypto Agility: Strategies and Practices
6. Staying Ahead of the Curve: Planning for the Migration to Post Quantum Cryptography, CSIAC webinar featuring NIST NCCoE’s Bill Newhouse, June 18, 2024
7. NIST NCCoE Migration to Post-Quantum Cryptography