The Quantum Countdown: A CISO’s Roadmap to Post-Quantum Cryptography

Why CISOs Need to Prepare for Post-Quantum Cryptography Now

For CISOs, uncertainty about the quantum timeline is not a reason to wait. It is a reason to prepare.

A sufficiently powerful quantum computer could one day break much of the public-key cryptography used to secure communications, authenticate identities, and verify digital signatures. That's why organizations are preparing to adopt post-quantum cryptography (PQC), a new generation of algorithms designed to withstand quantum attacks.

I’ve spent more than thirty years in enterprise security and lived through a few deadline moments. Y2K had a fixed date and still took years of inventory work. In 2007, when Estonia came under sustained cyber attack, what stayed with me was how much we depended on systems nobody had fully mapped. Quantum combines both problems: the dependency runs deeper than Y2K ever did, and there’s no date on the calendar.

The useful question for a CISO is how long it will take your organization to find, replace, test, and validate the cryptography your business depends on. For most enterprises, the answer is years.

Three Reasons PQC Migration Can't Wait

1. Sensitive data must stay confidential for decades. Health records, government and defense data, intellectual property, financial and legal archives, and identity data often carry confidentiality requirements of 10, 25, or even 50 years. If that protection depends on public-key cryptography that a future quantum computer can break, it has an expiry date you do not control.

2. Cryptography is everywhere, and migration is slow. It is embedded in applications, libraries, operating systems, network appliances, HSMs, smart cards, IoT and OT devices, certificates, protocols such as TLS, SSH and IPsec, supplier products, and archived backups. Much of it is invisible, hard-coded, or vendor-owned. Moving off SHA-1 and TLS 1.0 each took the industry the better part of a decade; PQC touches far more.

Privileged access infrastructure is part of that challenge, too. SSH keys, privileged connections, and the systems used to control access all need to be accounted for. Organizations should include their privileged access management infrastructure in the cryptographic inventory from the start.

3. Harvest now, decrypt later is a present-day risk. An adversary recording encrypted traffic today may be able to decrypt it in the future if the key-establishment exchange relies on public-key cryptography vulnerable to a sufficiently capable quantum computer. The risk depends on the protocol and key exchange used, but the confidentiality exposure starts today.

Nestor Cagnoli, Security & Innovation Manager at Segura™™, highlights why this matters for organizations protecting long-lived sensitive information:

“Although captured communications may lack immediate strategic value, high-value political, financial, or corporate intelligence retains long-term sensitivity. Encrypted data harvested today can be retroactively decrypted once quantum capabilities mature.”

How Quantum Computing Threatens Digital Signatures and Trust

A second, distinct risk is the future compromise of digital trust. Digital signatures underpin certificates, software integrity, authentication, and trusted communications.

A sufficiently capable quantum computer could undermine the mathematical security of widely deployed classical signature algorithms, including RSA, ECDSA, and EdDSA. Depending on the scheme and attack, this could enable attackers to recover signing keys, forge valid signatures, or impersonate trusted entities.

Unlike harvest-now-decrypt-later attacks, which create confidentiality exposure from communications captured today, quantum-enabled signature forgery primarily becomes actionable once the necessary quantum capabilities exist.

However, long-lived certificate authorities, code-signing infrastructure, firmware trust anchors, and identity systems may require years to replace. Organizations therefore need to prepare for both confidentiality and authenticity risks, while recognizing that they have different urgency and migration priorities.

For organizations managing large certificate estates, certificate discovery and lifecycle management can help establish the visibility and automation needed to support that transition.

So the board question is not “When will quantum computers break public-key cryptography?”  

It is, “How long will it take us to discover, prioritize, test, procure, deploy, and validate cryptographic replacements? And will we complete that migration before quantum capabilities put our existing protections at risk?”

What Is Post-Quantum Cryptography (PQC)?

Post-quantum cryptography (PQC) is a family of quantum-resistant algorithms that run on today’s classical computers but are designed to withstand attacks from both classical and quantum computers. It is software and standards, not quantum hardware: you do not need a quantum computer to deploy post-quantum cryptography.

The threat is specific. Shor’s algorithm, run on a large enough fault-tolerant quantum computer, would efficiently solve the factoring and discrete-logarithm problems behind RSA, Diffie-Hellman, and elliptic-curve cryptography (ECDH, ECDSA, EdDSA). Those algorithms provide key establishment and digital signatures almost everywhere: TLS, SSH, VPNs, PKI, code and document signing, smart-card authentication, and FIDO-style public-key credentials.

Two cautions matter here. First, AES-256 does not make an application quantum-safe on its own. The key establishment, key wrapping, authentication, and signatures around it must be assessed separately. Second, PQC migration is primarily about protecting confidentiality and digital trust through quantum-resistant key establishment and digital signatures. That's exactly where PKI and identity come into play.

What Post-Quantum Cryptography Doesn't Solve

Quantum-resistant algorithms replace vulnerable mathematics; they do not fix the ways security usually fails. PQC does not stop phishing, credential theft, endpoint compromise, malicious insiders, misconfigured access, or implementation flaws such as side channels and coding bugs. A perfectly quantum-safe TLS session still delivers data to a compromised endpoint. PQC belongs inside your security program, not in place of it.

How to Prioritize Quantum Risk Across Your Data

Quantum risk is not spread evenly across your data. It depends on where data is when an adversary can get it, how its protection works, and what it would cost if it were exposed years from now.

Data in Transit: The Harvest-Now-Decrypt-Later Risk

Data in transit represents one of the most immediate post-quantum confidentiality risks. Protocols such as TLS, SSH, IPsec, and VPN technologies frequently rely on classical public-key cryptography, including elliptic-curve Diffie-Hellman (ECDH), to establish shared session keys.

An adversary who captures encrypted communications and the associated key-establishment information today may be able to recover those session keys in the future using a sufficiently capable quantum computer. This is the basis of the harvest-now-decrypt-later threat.

Importantly, classical forward secrecy does not eliminate this risk. While ephemeral key exchange protects historical sessions against the later compromise of long-term private keys, it does not necessarily protect recorded exchanges against future quantum cryptanalysis.

This makes quantum-resistant or appropriately implemented hybrid key establishment an early priority for exposed communications carrying long-lived sensitive information.

Data at Rest: Protecting Encryption Keys and Long-Lived Information

Data at rest is commonly protected using symmetric encryption, such as AES, which remains comparatively resilient to known quantum attacks, particularly when using AES-256.

However, the broader cryptographic architecture may still depend on quantum-vulnerable public-key algorithms. Examples include RSA-based key wrapping, public-key-encrypted archives, encrypted email, backup systems, and cryptographic key distribution.

Organizations should assess not only how stored data is encrypted, but also how encryption keys are generated, protected, exchanged, recovered, and retained. 

Where appropriate, migrating to quantum-resistant key protection may involve rewrapping existing data-encryption keys or re-encrypting stored information. The correct approach depends on the underlying architecture and whether key material has already been exposed.

Critically, rewrapping or re-encrypting data today cannot retroactively protect copies that an adversary has already captured together with vulnerable key-protection material.

How to Prioritize Data for PQC Migration

Some information cannot be meaningfully changed after exposure. Biometrics, genetic information, historical medical records, and certain identity attributes keep their sensitivity for a person’s whole life, which makes their long-term confidentiality particularly important. Passwords, API keys, tokens, certificates, and IP addresses, by contrast, can be rotated or reissued.

But immutability alone does not determine quantum risk. A date of birth is immutable yet often not confidential. A stolen password database can enable extensive compromise, depending on how passwords are stored, which accounts they unlock, and what other defenses exist. Rotation also has limits. It reduces the future usefulness of a captured credential, but it cannot reverse information already exposed or actions already performed using that credential. A password, SSH key, or service secret that is never rotated may remain exploitable for years, creating a persistent security risk.

A better model scores each data set or use case on six factors:

PQC migration won't have the same urgency for every organization. As Nestor Cagnoli, Security & Innovation Manager at Segura™™, explains,

“Priority depends on enterprise risk profiles and asset sensitivity. For organizations whose core value resides in proprietary data, PQC migration should rank among the top strategic initiatives alongside artificial intelligence governance.”

Data that cannot be changed isn't automatically the highest priority. Focus on sensitive information that must remain confidential for years, could be captured by an adversary, and cannot be protected retroactively once exposed. Health, genetic, biometric, and identity records frequently fit that profile; rotatable secrets with genuinely enforced rotation usually do not.

Phase 2 of the roadmap below turns these factors into a risk matrix.

NIST Post-Quantum Cryptography Standards CISOs Should Know

Three NIST post-quantum cryptography standards are final and available for implementation today. NIST published FIPS 203, 204, and 205 in August 2024 after an eight-year public process. FN-DSA is being developed as FIPS 206, while HQC has been selected for future standardization as an additional key-encapsulation mechanism. 

CISOs do not need the mathematics, but they do need to know which algorithm does which job.

ML-KEM vs. ML-DSA vs. SLH-DSA: What's the Difference?

• ML-KEM is a post-quantum key-encapsulation mechanism that enables parties to establish shared secret key material. That material is used to derive symmetric encryption keys for protecting communications; ML-KEM does not directly encrypt application data. It comes in three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-KEM-768 is widely used in hybrid TLS deployments, while certain government security profiles require ML-KEM-1024. Select the parameter set according to applicable requirements, interoperability, and risk.
  
• ML-DSA protects authenticity and integrity: it provides evidence of who signed something and that it was not altered. It is designed for general-purpose digital signatures and is expected to support many common use cases.
  
• SLH-DSA also signs, but relies only on hash functions, which offers diversity from lattice-based schemes. Its signatures are much larger and slower to produce, so whether it suits a certificate authority or firmware depends on PKI and device support, performance, and policy; it is not part of CNSA 2.0, for example.

Hybrid post-quantum cryptography combines classical and quantum-resistant algorithms during migration. For example, TLS 1.3 can use X25519 alongside ML-KEM-768 for key establishment. This approach is already being deployed, and the IETF has standardized hybrid key agreement for TLS 1.3. It provides a practical transition path while organizations work toward broader PQC support.

Why PQC Standards Keep Evolving

PQC has moved from research to deployed standards in about a decade, but both the defenses and attack research are still changing. Hybrid post-quantum key exchange is already being deployed by major browsers, messaging platforms, CDNs, and OpenSSH.

But the research continues. NIST selected HQC as a backup key-encapsulation mechanism in March 2025, providing mathematical diversity if lattice-based schemes weaken. In July 2026, the HAWK post-quantum signature candidate was withdrawn from NIST's additional digital signatures standardization process following the discovery of a mathematical vulnerability using an Anthropic AI model. The finding did not compromise the finalized ML-KEM or ML-DSA standards.

Researchers have also published lower estimates of the quantum computing resources needed to break RSA-2048 and 256-bit elliptic-curve cryptography. These estimates are not predictions of when cryptography will break. Different studies assume different hardware architectures, error rates, error-correction schemes, and attack durations. No quantum computer today can break RSA-2048 or a 256-bit elliptic curve.

The direction is clear: more standards and parameter guidance will emerge, hybrid deployments will continue to support migration, and digital signatures will require careful planning because of larger sizes and long-lived trust chains.

Cryptography will need to be managed like identity or vulnerability management: inventoried, owned, and continuously maintained. That's the strongest argument for crypto-agility over a hard-coded replacement.

Government PQC Guidance and Migration Deadlines

Governments broadly agree on the direction: prepare now, prioritize high-risk systems, and plan for major migration milestones between 2030 and 2035. The specific dates, requirements, and organizations covered vary by jurisdiction.

These policies differ in scope and legal force. Some requirements are binding on government agencies, others may apply to suppliers through procurement, and many are guidance for the private sector. That guidance can also influence expectations for regulated industries, critical infrastructure, and public-sector suppliers.

Where Government PQC Guidance Agrees

1. Start with discovery - a cryptographic inventory and a quantum risk assessment.
   
2. Prioritize by risk - long-lived sensitive data, critical infrastructure, and roots of trust first.
   
3. Protect data in transit early - harvest now, decrypt later makes exposed key establishment a high priority.
   
4. Build crypto-agility - NIST's updated crypto-agility guidance explains how organizations can prepare to replace algorithms across their systems. PQC will not be the last cryptographic transition.
   
5. Use procurement as the lever and standardized algorithms - not proprietary “quantum-safe” schemes.

Where National PQC Guidance Differs

Migration timelines, algorithm requirements, and hybrid deployment policies vary by jurisdiction. Australia emphasizes post-quantum readiness around 2030 under applicable government controls, while the UK, Canada, and the EU have published migration roadmaps extending toward 2035.

European agencies such as Germany's BSI and France's ANSSI favor hybrid approaches, while the NSA's CNSA 2.0 framework specifies post-quantum algorithms. The UK's NCSC supports both hybrid and pure post-quantum configurations where appropriate.

CNSA 2.0 and applicable ASD guidance emphasize ML-KEM-1024 and ML-DSA-87, while many commercial hybrid TLS deployments currently use ML-KEM-768.

How CISOs Should Apply Government Guidance

• Map every jurisdiction you operate in and, where practical, adopt the strictest applicable requirement for shared infrastructure.
  
• Separate obligations from guidance in your board reporting: what binds you, what binds your customers, and what is recommended.
  
• Follow your regulators, not just your government. Financial, health, energy, and telecom supervisors may establish additional sector expectations.
  
• Re-check requirements at least annually. US federal policy alone changed materially twice between 2025 and 2026.

Why Post-Quantum Cryptography Is an Identity Security Challenge

Identity is where I believe many organizations will underestimate the complexity of PQC migration.

We're no longer dealing only with employees signing into applications. We have workloads, service accounts, devices, APIs, and AI agents establishing trust with each other, often automatically and at enormous scale.

Many of those relationships depend on certificates, signing keys, and authentication mechanisms that will eventually need to change. For machine identity security, the challenge is knowing which identities rely on vulnerable cryptography, who owns them, and how to update those trust relationships without disrupting the services they support.

Two Identity Risks: Confidentiality and Authenticity

That creates two distinct challenges. The first is confidentiality: protecting identity-related communications and data from adversaries who capture them today. The second is authenticity: public-key signatures underpin certificates, software integrity, authentication protocols, and machine-to-machine trust.

An attacker able to derive a private signing key through a quantum attack could impersonate the legitimate signer and forge signatures accepted by relying parties, within the scope of that key's trusted authority.

Where Quantum-Vulnerable Cryptography Lives in Identity Systems

Where the dependencies sit varies by technology, so precision matters:

• PKI and certificates - TLS, device, and workload certificates help authenticate machine identities. A compromised CA key would let an attacker issue identities trusted across that CA’s entire scope.
  
• Non-human identities - Service accounts, workloads, APIs, devices, and increasingly autonomous AI agents authenticate with certificates, SSH keys, and signed tokens. Many run continuously, have unclear ownership, or sit on technology with long replacement cycles.
  
• Privileged access - SSH keys, jump hosts, and privileged session infrastructure rely on public-key cryptography for some of the most powerful access in the enterprise.
  
• Federation - SAML and OIDC assertions and tokens are signed, but deployments vary in algorithm and configuration. Inventory what each identity provider and relying party actually uses.
  
• Kerberos - Standard Kerberos uses symmetric cryptography; public-key dependencies arise where PKINIT (smart-card or certificate logon) is used.
  
• Passwords - Password authentication does not become quantum-vulnerable just because public-key cryptography is threatened, although the channels and stores that protect passwords may depend on it.
  
• Strong authenticators - Smart cards, PIV, FIDO2, and passkeys use public-key credentials and will need PQC-capable authentication ecosystems. Some hardware authenticators may require replacement over long lifecycle periods.

Certificate discovery and lifecycle automation do not themselves replace vulnerable algorithms. They do, however, provide the visibility and control needed to manage certificate changes. That's why certificate lifecycle management should be part of the broader migration plan, alongside PQC-capable CAs, HSMs, and clients.

For CISOs, the objective is not simply to swap algorithms. It is to preserve confidence in who or what is requesting access, what it is authorized to do, and whether the underlying trust relationship remains sound. That requires visibility, ownership, automation, least privilege, and the ability to update trust mechanisms without disrupting the business. Connect the cryptographic inventory to identity discovery, certificate lifecycle management, privileged access management, and machine identity governance.

PQC Identity Migration Checklist for CISOs

• PKI: inventory root and issuing CAs, certificate profiles and validity periods; plan PQC-capable hierarchies and HSMs
  
• SSH: Inventory host and user keys, securely manage private keys, enforce appropriate rotation, and adopt PQC key exchange as supported
  
• Privileged access: confirm PAM, vault, and session-broker supplier roadmaps; remove static and hard-coded secrets
  
• Identity providers and federation: record signing algorithms and key lifetimes for SAML, OIDC and token services
  
• Machine identities: assign an owner to every service account, workload identity, and API credential; use secrets management to help secure and rotate application credentials
  
• AI agents: register agents as identities with scoped, short-lived credentials and an accountable owner
  
• Hardware authenticators: map smart-card, PIV and FIDO2 estates and replacement cycles against PQC support

What CISOs Should Do in the First 90 Days

Before the full roadmap, here is what a CISO can achieve in a single quarter. These are suggested planning milestones, not regulatory deadlines.

1. Days 1–30: Establish ownership. Name an executive sponsor and program lead, determine which requirements apply to you, and identify your long-lived sensitive information.
   
2. Days 31–60: Discover dependencies. Start cryptographic discovery across critical applications, certificates, network services, identity infrastructure, and major suppliers.
   
3. Days 61–90: Validate priorities. Produce a risk-ranked migration backlog, pick candidate pilots, request supplier roadmaps, and prepare an initial investment proposal.

These first 90 days establish the foundation. The five-phase roadmap below explains how to turn that initial work into a long-term migration program.

A Five-Phase CISO Roadmap for PQC Migration

The difficult part of PQC migration isn't necessarily choosing an algorithm. It's discovering how many systems depend on cryptography that nobody has thought about in years.

Some will be straightforward software updates. Others will involve suppliers, hardware that cannot be upgraded, or applications where changing a certificate or cryptographic library could cause an outage.

That's why I would approach PQC migration as a series of overlapping activities rather than a traditional project with a fixed beginning and end. A good post-quantum migration strategy needs to account for those dependencies from the start.

Phase 1: Establish Ownership and Governance

PQC fails when it is treated as an IT ticket. It succeeds when it has an executive owner, a budget line, and board visibility.

• Appoint an accountable owner. Usually the CISO, supported by a named program lead and a cross-functional steering group that includes enterprise architecture, infrastructure, application owners, PKI and identity teams, procurement, legal, compliance, and risk.
  
• Write a short quantum risk statement for the board. Explain harvest-now-decrypt-later risk and the regulatory dates that apply to your organization.
  
• Classify data by confidentiality lifetime. Ask every data owner one question: How many years must this stay secret? Data that must remain confidential beyond 2035 is in scope now.
  
• Set policy. Add PQC and crypto-agility requirements to your cryptographic standards, architecture principles, and secure development lifecycle. Ban new hard-coded algorithms.
  
• Align with existing frameworks. Map the program to ISO 27001, NIST CSF 2.0, DORA, NIS2, and applicable sector rules so it is audited like any other risk.

Phase 2: Inventory Cryptography and Prioritize Risk

Ask an organization how many servers it has, and you'll probably get an answer. Ask how many certificates, cryptographic libraries, signing keys, and hard-coded algorithms it depends on, and the answer becomes much less certain. 

That visibility gap is one of the first problems CISOs need to solve. A cryptographic inventory is the starting point for any credible PQC migration plan. You need to know where cryptography is being used, who owns it, and what breaks when it changes.

NIST's post-quantum cryptography migration guidance also covers cryptographic inventory and the dependencies organizations need to identify before migration.

Nestor Cagnoli, Security & Innovation Manager at Segura™™, reinforces the importance of that discovery work:

“Organizations must mandate post-quantum compliance in prospective software procurement while establishing comprehensive visibility over data transit routes. Identifying data flows and software dependencies enables systematic migration, ensuring that security leaders maintain operational oversight and prevent data exposure.”

Distinguish discovery from observability. Knowing which algorithms are configured is not the same as knowing which are actually negotiated in production. A server may support hybrid ML-KEM while most clients still fall back to classical key exchange.

Where to Find Cryptographic Dependencies

Build the inventory from several sources, because no single tool sees everything:

1. Network and protocol observation of TLS, SSH, IPsec, and VPN traffic and the cipher suites actually negotiated
2. Certificate and key discovery across public and private PKI, HSMs, key management systems, cloud KMS, and secrets vaults
3. Code and binary analysis for cryptographic libraries, hard-coded algorithms, and embedded keys, linked to your SBOMs and CBOMs
4. Endpoint and OT/IoT discovery for long-lifecycle devices with fixed firmware
5. Supplier questionnaires for SaaS, managed services, and appliances you cannot scan
6. Data-at-rest review of archives and backups whose keys are wrapped with RSA or ECC

For each entry, record the system, owner, algorithm and key size, protocol, library and version, what it protects (confidentiality, signatures, or both), the data or trust lifetime, exposure, supplier dependency, and migration complexity. Treat it as a living asset, refreshed continuously.

Quantum Risk Matrix: Confidentiality vs. Digital Trust

Confidentiality and digital trust fail differently, so score them separately. A long-lived code-signing root may protect no secrets at all, yet a forged signature could compromise every device that trusts it.

The priorities and dates below are illustrative planning targets. Actual migration schedules should reflect applicable requirements, data sensitivity, exposure, supplier readiness, and organizational risk.

Track A: Long-Lived Confidentiality (Harvest Now, Decrypt Later)

Track B: Long-Lived Digital Trust (Trust Now, Forge Later)

The authenticity risk concerns signing keys and trust relationships that may still be relied upon when cryptographically relevant quantum computers become available.

In both tracks, anything crossing the public internet, partner links, or radio and satellite links moves up a level.

Phase 3: Evaluate Algorithms, Suppliers, and Crypto-Agility

This phase answers two questions: What cryptographic standards will we adopt, and which suppliers will help us get there?

Choose PQC Algorithms

Set target algorithms in policy rather than per project. Common choices are ML-KEM for key establishment (ML-KEM-768 is widely deployed; ML-KEM-1024 where CNSA 2.0, ASD, or your own risk appetite requires it), ML-DSA for general signatures, and SLH-DSA where hash-based diversity is wanted and the ecosystem supports it. Use hybrid modes during transition where your regulators allow it. Use AES-256 for long-lived confidentiality, and choose hash lengths by the security property needed.

PQC Vendor Readiness: Questions to Ask Suppliers

Most of your cryptography is inside products you buy. Ask every critical vendor:

• Which NIST PQC algorithms do you support today, and in which product versions?
• What is your dated roadmap for ML-KEM, ML-DSA, and SLH-DSA, including hybrid modes?
• Will the change come as a configuration change, a software update, or a hardware replacement?
• Does the product use a FIPS 140-3-validated cryptographic module for the relevant functions, or is validation planned? Which algorithms and configurations are covered?
• Can you provide a CBOM or SBOM showing cryptographic dependencies?
• How do you handle algorithm changes without breaking interoperability?
• What happens to devices or data that cannot be upgraded?

Write these questions into RFPs, contract renewals, and third-party risk assessments now. A contract signed in 2026 for a five-year service will still be running in 2031.

Build Crypto-Agility

Crypto-agility is the ability to change algorithms, keys, and certificates quickly, minimizing the need to rewrite applications.

In practice, it means abstracting cryptography behind central libraries or services, managing keys and certificates through automated lifecycle platforms, avoiding hard-coded algorithms, and being able to roll out changes through configuration.

It is the real deliverable of a PQC program, because PQC will not be the last cryptographic transition.

Phase 4: Run Controlled PQC Pilot Programs

Pilots turn assumptions into evidence. One of the biggest post-quantum cryptography implementation challenges is compatibility. Some post-quantum keys, signatures, and protocol messages are substantially larger than their classical counterparts. That can create problems with packet fragmentation, middleboxes, certificate size limits, constrained devices, and HSM capacity.

A good PQC pilot includes:

• A clear scope. Two or three representative use cases, for example, external TLS on a web service, an internal VPN, and code signing.
• Hybrid configurations tested against real clients, load balancers, WAFs, proxies, and monitoring tools.
• Performance baselines for latency, handshake size, CPU, and throughput before and after.
• Interoperability tests with partners and suppliers on the other end of the connection.
• Rollback plans proven to work, so a pilot can be reversed in minutes.
• Operational readiness: monitoring, logging, incident response, and key-management procedures updated for new algorithms.
• A written lessons-learned report that feeds cost and effort estimates into Phase 5.

Phase 5: Fund, Schedule, and Measure PQC Migration

The final phase converts evidence into a multi-year program with money attached. Sequence migration waves by the risk matrix, align them to existing refresh cycles to reduce cost, and set exit criteria for each wave.

PQC Migration Budget Framework

There is no reliable per-employee figure for PQC migration cost. Cost is driven by the size of your cryptographic estate, how much is vendor-managed, and how much legacy and embedded technology you run. Present the budget to the board in these categories:

Frame it as a modernization investment. Much of the spend — certificate automation, HSM refresh, legacy retirement, better asset inventory — pays back in reduced outage risk and audit effort long before a quantum computer appears.

A Practical PQC Migration Timeline

For organizations beginning their post-quantum cryptography programs in 2026, a practical planning objective is to prioritize high-risk systems for migration around 2030–2031, with broader migration extending toward 2035 where applicable government guidance and organizational risk assessments support those milestones.

These dates are planning targets, not guarantees. Actual schedules depend on regulatory obligations, supplier readiness, interoperability, hardware replacement cycles, and existing cryptographic dependencies. Phases overlap, and migration dates should come from the risk matrix and normal refresh cycles.

For systems protecting information that must remain confidential for decades, waiting until 2030 to begin deployment may already be too late. Organizations with heavy OT, embedded, or medical-device estates should start vendor engagement immediately. Hardware replacement cycles of 10 to 15 years mean 2035 is effectively today's procurement decision.

How CISOs Should Measure PQC Readiness

Measure PQC readiness by how much of your high-risk cryptography you can see, change, and have already changed, not by how many systems “support PQC.” Tie each metric to an accountable team and report the trend quarterly.

A simple maturity scale helps executives see progress: Unaware (no inventory, no owner), Aware (owner and policy, partial inventory), Prepared (inventory of critical systems, pilots done, vendor roadmaps known), Migrating (Priority 1 systems moving, budget approved), and Agile (changes delivered by configuration and measured continuously).

The Real Countdown Is Your Migration Timeline

The quantum countdown is not a race to a single date; it is a race against your own migration time. The organizations that will be ready are not the ones that guess the arrival of a quantum computer correctly. They are the ones that know where their cryptography lives, have classified how long their data and trust must last, and can change algorithms without rebuilding their systems.

Start with governance and an inventory. Use the risk matrix to protect long-lived data and roots of trust first. Make suppliers commit to dated roadmaps. Prove the change in pilots, then fund a multi-year program that leaves you crypto-agile. Do that, and post-quantum cryptography becomes what it should be: a well-managed modernization program, not a crisis.

Know Who Has Access to Your Critical Systems

As you prepare for new cryptographic standards, don't lose sight of privileged access. Segura™™ helps you discover privileged identities, secure credentials, and control access across human and machine accounts.

Frequently Asked Questions

What is post-quantum cryptography?

Post-quantum cryptography (PQC) uses quantum-resistant algorithms that run on today's computers. These algorithms are designed to replace public-key cryptography vulnerable to quantum attacks, including RSA and elliptic-curve algorithms used for key establishment and digital signatures.

Why should CISOs prepare for PQC now?

Migration takes years, some data must stay confidential for decades, recorded traffic can be decrypted later, and governments have established migration milestones beginning in 2026.

Which algorithms are included in NIST's PQC standards?

ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) are finalized standards. FN-DSA is being developed as FIPS 206, while HQC has been selected for future standardization as an additional key-encapsulation mechanism.

What is crypto-agility?

The ability to replace algorithms, keys, and certificates quickly while minimizing the need for application rewrites.

How much does PQC migration cost?

There is no standard figure. It depends on the size of your cryptographic estate, supplier dependencies, and legacy, OT, and embedded technology. Aligning migration with normal refresh cycles can reduce costs.