Your CISO forwards a NIST report with a one-line message: "Are we ready for this?" Then the questions start in Slack. Does hybrid cryptography count as compliant? Who owns the inventory? What does the auditor want to see?
These questions arise in nearly every conversation about post-quantum cryptography (PQC) migration. Below are six of them, answered based on NIST's publications and the frameworks you're already audited against.
Is Hybrid Mandatory or Just an Option?
It's an option. NIST's report states that migration may start with hybrid solutions, using classical and quantum-resistant algorithms together, or multiple PQC algorithms with different mathematical mechanics. Hybrid deployment isn't required.
The rationale is defensive. A hybrid setup stays secure as long as one component remains safe, so a flaw in a new PQC algorithm or its implementation doesn't automatically expose you. It also helps sectors running legacy algorithms accommodate PQC.
For your policy, don't write "we will deploy hybrid." Instead, define decision criteria: where hybrid is allowed, who approves it, and what triggers the move to PQC-only.
Does Hybrid Make Us Twice as Secure?
No, and this misconception needs correcting early. NIST states that hybrid solutions add complexity to implementations and architectures, increasing security risks and costs during the transition.
More moving parts mean more configuration surface, more key material to manage, and more places for an implementation bug. A misconfigured hybrid deployment can be weaker than a clean classical one.
Treat hybrid as a risk you're accepting in exchange for resilience, and document that trade-off in your risk register. If you're running ISO/IEC 27001, include this in your risk assessment under Clause 6.1.2 with a documented Risk Treatment Plan under Clause 6.1.3.
Which Systems Should We Prioritize?
Start with data that must remain confidential for a long time and crosses networks you don't control. NIST identifies four use cases that benefit from quantum-resistant protection:
- Code signing in software development
- Asymmetric key user sign-in
- Data transmission over public networks via TLS or VPNs
- Email and document signing and encryption
NIST also distinguishes between user-machine authentication, which can wait until cryptographically relevant quantum computers exist, and transport-layer encryption, which needs attention now due to "harvest now, decrypt later" attacks.
Prioritize based on confidentiality lifetime and exposure to interception. Long-lived sensitive data over public networks should be addressed first.
What Are the Key Dates for Our Roadmap?
Three dates anchor the planning:
- Late 2030: The Office of Management and Budget ordered federal agencies to migrate "as much quantum risk as feasible" by the end of 2030.
- After 2030: NIST will deprecate all quantum-vulnerable digital signature algorithms. Deprecated means data owners assess their own risk and decide whether to transition.
- After 2035: These algorithms are disallowed under NIST standards and guidelines.
Even if you're not a federal agency, these dates matter. NIST's guidance serves as a blueprint for critical infrastructure operators, and your customers' security questionnaires will start echoing it. Historically, the path from algorithm standardization to full integration can take 10 to 20 years, so a 2030 deadline leaves little room.
How Do We Handle This in a SOC 2 or ISO/IEC 27001 Audit?
Neither framework names post-quantum algorithms, so there's no PQC checkbox. But the obligations are already there.
Under ISO/IEC 27001:2022 Annex A, control 8.24 (use of cryptography) expects defined rules for the effective use of cryptography, including key management. Control 5.9 (inventory of information and other associated assets) is where a cryptographic inventory logically lives. For SOC 2, the Trust Services Criteria around logical access and system operations (CC6 and CC7) are where an assessor will probe encryption in transit and change management for cryptographic components.
An auditor wants to see a governed process: an inventory of where quantum-vulnerable algorithms are used, a documented decision about hybrid versus PQC-only, and evidence you're tracking the standards that apply to you. Where you rely on FIPS-Validated Cryptography, confirm with your vendors how and when validated PQC modules will arrive, because you can't deploy what isn't validated yet.
Should We Trust Vendors Claiming They're "Quantum-Ready"?
No. Ask for specifics: which algorithms, in what mode (hybrid or PQC-only), and on what timeline. NIST has approved one family of quantum-resistant key-establishment algorithms, Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). It selected a second KEM algorithm as an alternative in 2025, but that pick is still going through formal approval and documentation. A vendor claiming to support an algorithm that isn't finalized is telling you something about their risk tolerance.
Fold this into supplier governance. ISO/IEC 27036 gives you the structure for information security in supplier relationships, and under SOC 2 your vendor management criteria (CC9.2) already require you to assess third parties. Add cryptographic agility to the assessment: can the vendor swap algorithms without a re-architecture?
Interoperability is the practical trap. NIST expects quantum-vulnerable and quantum-resistant algorithms to run side by side in many systems to facilitate interoperability. If your vendor and your integration partner land on different hybrid constructions, they may not communicate effectively.
What Does the Second Transition Mean for Our Budget?
This is the question finance will ask, and NIST's wording matters here. Hybrid solutions are typically expected to be temporary, leading to a second transition to tools that use only PQC algorithms.
That means a hybrid deployment can be a two-migration project. You pay to implement it, then pay again to retire it. Plan for that explicitly. Ask whether a given system will be touched twice, and weigh the resilience hybrid buys against the cost of the extra migration. For some systems, going straight to PQC-only where your vendors support it may be cheaper than a hybrid detour.
Whichever you choose, record it as a decision in your Risk Treatment Plan with an owner and a review date, so the second transition doesn't arrive as a surprise.
Where to Go for More
Start with NIST's migration report itself and the underlying standards for ML-KEM and the signature algorithm families. Then map what you find to your existing controls: ISO/IEC 27001 Annex A 8.24 and 5.9, ISO/IEC 27003 for implementation guidance, and your SOC 2 system description for where cryptography is in scope.
Build the cryptographic inventory first. Every other question on this list gets easier once you know what you're running.
