Executive Summary
Every enterprise runs on cryptography, whether the board sees it or not. TLS sessions, VPN tunnels, digital certificates, code signing, identity federation, document signatures, encrypted archives, and regulated records all depend on public-key algorithms, mainly RSA and elliptic-curve cryptography. A sufficiently capable quantum computer would break those algorithms.
No one can say precisely when a cryptographically relevant quantum computer (CRQC) will exist. That uncertainty is not a reason to wait. It is the risk. Data encrypted today can be harvested now and decrypted later. Trust anchors, root certificates, and signing keys deployed today will still be in service a decade from now.
The standards question, at least, is settled. In August 2024, NIST finalized its first post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). Agencies such as CISA and the UK NCSC now tell organizations to begin migration planning today, not when a quantum computer is announced.
The migration will take years, touch nearly every system and vendor, and require sustained funding, governance, and evidence. That makes post-quantum readiness a governance, risk, and compliance program with cryptography inside it, rather than a cryptography project that happens to need some paperwork.
Why GRC Leaders Should Care
This is enterprise risk, expressed in cryptographic terms.
Confidentiality risk. “Harvest now, decrypt later” is simple. An adversary intercepts and stores your encrypted traffic or exfiltrated data today, then decrypts it once a CRQC exists. If your data must remain confidential for 10 to 25 years, think health records, financial data, intellectual property, regulated records, or M&A material, then the exposure window has already opened. The question for the risk committee is not “when will quantum computers arrive?” but “how long must this data stay secret, and does that period overlap with plausible quantum capability?”
Integrity and trust risk. Digital signatures underpin identity, software updates, firmware, contracts, and PKI trust chains. A CRQC could forge signatures and impersonate legitimate key holders. Long-lived trust anchors such as root CAs, code-signing keys, and device identity certificates baked into hardware deserve attention well before a CRQC exists, because they cannot be rotated quickly.
Compliance exposure. Regulators and supervisory bodies are beginning to reference quantum readiness in operational resilience, financial services, and critical infrastructure expectations. Organizations subject to long data-retention mandates carry compounding exposure, because the retention obligation guarantees the data still exists when the threat matures.
Third-party risk. Most of your cryptography is implemented by someone else: cloud providers, SaaS platforms, network vendors, payment processors. Their migration timelines become your risk. Vendor post-quantum readiness belongs in your third-party risk questionnaires today.
Business continuity. A rushed, unplanned migration under regulatory or threat pressure would be an operational event in its own right, with certificate outages, broken integrations, and failed authentications. A governed, multi-year migration is far cheaper than an emergency one.
Current Standards and Guidance
The standards foundation is now in place.
- FIPS 203 (ML-KEM): module-lattice-based key encapsulation, the general-purpose replacement for classical key exchange.
- FIPS 204 (ML-DSA): module-lattice-based digital signatures for general-purpose use.
- FIPS 205 (SLH-DSA): stateless hash-based signatures, well suited to firmware and software signing where robustness matters more than speed.
NIST has signaled that classical public-key algorithms will be phased out over the coming decade. Its draft transition guidance (NIST IR 8547) points toward deprecating quantum-vulnerable algorithms around 2030 and disallowing them around 2035. Treat those dates cautiously, since they remain in draft, but plan against them.
CISA, NSA, and NIST jointly published Quantum-Readiness: Migration to Post-Quantum Cryptography, which anchors the practical starting point: build a cryptographic inventory, engage vendors, and develop a migration roadmap. The UK NCSC guidance recommends beginning migration planning now, favoring implementations based on the final standards, and treating hybrid classical/PQC schemes as an interim step inside an architecture designed to reach a PQC-only end state. NCSC has also published indicative national timelines targeting completed migration by the mid-2030s.
One theme runs through all of this guidance. Crypto agility, the ability to identify, replace, and govern cryptographic algorithms without re-architecting systems, should become a formal control objective in your security policy. The next algorithm transition will not be the last.
Reference Architecture for PQC Readiness
A post-quantum program needs an architecture, not a tool list. The five-layer model below gives GRC and architecture teams a shared structure.
Figure 1. PQC readiness reference architecture. Crypto agility spans the control layers; evidence spans the full stack and flows up to the governance dashboard.
Business layer. Business services mapped to the data they process, its sensitivity, and its required confidentiality lifetime. This layer answers what must stay secret, for how long, and what breaks if trust fails. It is the input to all prioritizations.
Governance layer. The PQC program office and steering committee, cryptographic policy and standards, the exception and risk-acceptance register, and the governance dashboard that reports migration status, coverage, and residual risk to the risk committee. This layer owns crypto agility as a control objective.
Cryptographic control layer. The enterprise cryptographic capabilities run as managed services: certificate lifecycle management, PKI and trust services, key management and HSMs, a crypto-agility orchestration capability that can deploy, rotate, and retire algorithms across the estate, and the cryptographic inventory (a cryptographic bill of materials) kept current through automated discovery.
Application and infrastructure layer. Where cryptography is actually consumed: TLS termination points, VPN and remote-access gateways, identity and access management (federation, tokens, MFA, PKI-based authentication), code signing and the software supply chain, databases, backup and long-term archival encryption, and embedded or OT devices with long hardware lifecycles.
Third-party and ecosystem layer. Cloud and SaaS providers, managed service providers, hardware and network vendors, and interconnection partners, each with a readiness attestation, contractual expectations, and a place in the migration sequence.
The monitoring and evidence bar matters as much as the layers. Every discovery scan, certificate renewal, algorithm change, and vendor attestation should generate logged, auditable evidence. If it is not evidenced, it is not governed.
A Real-World Example: A Regional Bank's Staged Migration
Consider a mid-sized regulated bank with a 10-year retention obligation on customer records, a customer-facing digital banking platform, and roughly 200 third-party integrations.
Business drivers. Supervisory questions about quantum readiness in its operational resilience review. Recognition that customer financial data retained until 2036 already sits inside the harvest-now-decrypt-later window. A scheduled PKI refresh in 18 months that creates a natural migration vehicle.
Approach. The CISO frames post-quantum readiness as a board-level risk program with the CRO as co-sponsor. Quarter one goes to automated cryptographic discovery across networks, applications, certificates, and code repositories, producing a cryptographic inventory of about 40,000 certificates and several hundred distinct algorithm usages. Classification then maps each usage to data sensitivity and lifetime.
Prioritization. Three tiers emerge. First, external TLS and VPN concentrators protecting long-lived customer data. Second, the internal PKI, code-signing infrastructure, and identity federation. Third, internal systems handling short-lived data. The bank pilots hybrid key establishment, classical ECDH combined with ML-KEM following emerging TLS standards, on a non-critical external service, measuring handshake latency, middlebox compatibility, and certificate-size impacts.
Hybrid deployment and governance. Hybrid TLS rolls out across tier-one systems over two quarters. The PKI refresh is redesigned so the new certificate management platform is algorithm-agnostic, and the new root CA is established with a documented path to post-quantum signing. Vendors receive a standard readiness questionnaire, and laggards are logged in the exception register with risk acceptances signed by business owners and given review dates. Progress, coverage percentages, and exceptions are reported quarterly to the risk committee. The end state is explicit: hybrid is an interim posture, with full PQC targeted as protocol standards and vendor support mature.
Nothing in this story requires exotic technology. It requires inventory, sequencing, governance, and persistence. Those are GRC disciplines.
Migration Roadmap
- Discover. Automated and manual cryptographic discovery across networks, applications, certificates, keys, code, and vendors. Output: the cryptographic inventory.
- Classify. Map each cryptographic dependency to data sensitivity, confidentiality lifetime, and business criticality.
- Prioritize. Rank by exposure. Long-lived data, long-lived trust anchors, external interfaces, and regulated systems come first.
- Pilot. Test PQC and hybrid configurations in controlled environments. Measure performance, compatibility, and operational impact.
- Hybrid deploy. Roll out hybrid classical/PQC key establishment where standards and vendor support allow, as an interim measure.
- Replace. Move to PQC-only algorithms as protocol standards, implementations, and assurance mature.
- Govern. Maintain policy, exceptions, vendor obligations, and dashboard reporting throughout.
- Verify. Independently test and audit that migrated systems actually negotiate PQC and that legacy algorithms are not silently still in use.
- Retire. Formally deprecate and disable quantum-vulnerable algorithms, with evidence of removal
GRC Controls and Evidence Checklist
| PQC Readiness Control Area | GRC Evidence to Collect |
|---|---|
| Cryptographic discovery | Crypto inventory / cryptographic bill of materials, discovery scan logs |
| Certificate & key management | Certificate lifecycle reports, key rotation records, CA and HSM configuration baselines |
| Migration governance | Approved migration roadmap, program charter, steering-committee minutes |
| Exceptions & risk | Exception register, risk-acceptance documentation with owners and review dates |
| Third-party risk | Vendor readiness attestations, contract clauses, assessment results |
| Technical validation | Pilot and regression testing results, protocol negotiation evidence |
| Policy & standards | Updated cryptographic policy naming approved algorithms and crypto-agility requirements |
| Change control | Approval records for algorithm and PKI changes |
| Assurance | Internal audit reports, dashboard snapshots, retirement and decommission evidence |
Five Board-Ready Talking Points
- Why this matters. Our business runs on cryptography that a future quantum computer will break, and the replacement standards are already final. This is a known, plannable transition.
- What is at risk. Data we must keep confidential for years is already exposed to harvest-now-decrypt-later collection, and the trust infrastructure behind our identities, software, and transactions has a long replacement lead time.
- What we must do now. Fund a multi-year program. Complete a cryptographic inventory, embed PQC into technology refreshes and vendor contracts, and make crypto agility a standing control.
- What success looks like. A current inventory, prioritized migration with measurable coverage, hybrid protection on our most exposed systems, vendors under contractual obligation, and audit-ready evidence.
- What happens if we wait. We convert a manageable program into an emergency migration, with regulatory exposure, higher cost, operational outages, and data already lost to collection we cannot undo.
Common Mistakes to Avoid
- Treating PQC as a future problem. The confidentiality clock started when your long-lived data was first transmitted.
- Waiting for “perfect” standards. FIPS 203, 204, and 205 are final. Protocol details will keep evolving, but inventory, governance, and vendor engagement do not need to wait.
- Ignoring certificates and code signing. Signatures and trust anchors are often harder and slower to migrate than TLS.
- Forgetting third parties. Your migration is capped by your slowest critical vendor unless you manage them deliberately.
- Migrating without an inventory. You cannot prioritize, sequence, or evidence what you have not discovered.
- Buying tools before defining governance. Tooling without ownership, policy, and reporting produces shelfware, not risk reduction.
How ServQual Helps
ServQual supports post-quantum readiness as part of a broader enterprise cybersecurity and GRC program. That program spans security governance, risk management, compliance, audit, IAM, cloud security, network and email security, DevSecOps, SOC, and incident response, and it follows a Secure by Design and Privacy by Design approach.
In practice, ServQual fits across the program lifecycle:
- Quantum-risk and crypto-agility assessments, cryptographic discovery support, and gap analysis against NIST, CISA, and NCSC guidance.
- Roadmap definition. A prioritized, business-aligned migration roadmap with governance structures, funding cases, and board reporting built in.
- Control mapping and unified compliance. Through SUSAN, ServQual AI-driven cybersecurity, privacy, and GRC platform, PQC controls are mapped once and reused as evidence across multiple frameworks, which avoids duplicated audit effort as regulatory expectations mature.
- Evidence collection and continuous assurance. SUSAN centralizes crypto inventories, certificate lifecycle reports, vendor attestations, exception registers, and approval records, keeping the organization audit-ready throughout a multi-year migration.
- Migration execution. Architecture, PKI and certificate management modernization, IAM and cloud security integration, and DevSecOps pipeline updates for post-quantum code signing, supported by managed security services where needed.
PQC readiness then sits inside your existing governance machinery rather than running as a disconnected side project.
Conclusion
The quantum threat is uncertain in timing but certain in direction. The response is fully specified: the standards are final, government guidance is explicit, and the migration playbook is a familiar one of inventory, prioritization, staged deployment, and evidence. What is scarce is time. Cryptographic transitions have historically taken a decade, and your long-lived data and trust anchors are exposed today.
GRC leaders are well placed to make this succeed, because the hard parts are governance parts: ownership, funding, vendor accountability, exceptions, and proof. Start the inventory this quarter. Put PQC on the risk register with a named owner. Ask your top vendors for their timelines. Organizations that treat post-quantum readiness as a strategic risk program now will complete it on their own terms. The rest will complete it on someone else.
"Post-quantum readiness is not a future cryptography project. It is today’s enterprise risk program."
Sairaj Pawar
Cyber Security Solution Consultant | ServQual
FAQ
Most frequent questions and answers
No authoritative body has committed to a date; NIST describes such machines as potentially years or decades away. Planning should be driven by your data confidentiality lifetime and system replacement cycles, not by predictions.
Hybrid classical/PQC key establishment is a pragmatic interim step where it is supported, particularly for external interfaces. NCSC guidance recommends treating hybrid as temporary, inside an architecture designed to reach PQC-only.
Broadly, no. Symmetric algorithms such as AES with adequate key sizes, and hash functions such as SHA-256, are not significantly affected, per NIST PQC guidance. The urgent work is in public-key cryptography: key establishment and digital signatures.
Cryptographic inventory and vendor engagement, the first steps in the CISA/NSA/NIST quantum-readiness roadmap. Both are inexpensive relative to their value, and everything else depends on them.
Build a Post-Quantum Readiness Roadmap
Post-quantum cryptography migration will affect certificates, PKI, TLS, VPNs, identity systems, code signing, vendor platforms, cloud services and long-lived regulated data.
ServQual helps organizations assess quantum risk, build cryptographic inventories, define crypto-agility controls, engage vendors, prioritize migration and maintain audit-ready evidence. Explore SUSAN or contact ServQual to connect cryptographic resilience, vendor readiness, exception tracking, control evidence and Continuous Assurance into one structured GRC view.
