The Risk is Already Here: Why Post-Quantum Cryptography Cannot Wait

The most dangerous breach your organization will ever face may have already happened, and you will not know it for years. Adversaries do not need a quantum computer to begin the attack. They are intercepting and archiving encrypted data today, using classical infrastructure, with one goal: decrypt it later, when the technology to do so exists. The encryption protecting your data today remains effective against current threats, but for information that must stay confidential for years or decades, it may only postpone the moment of exposure.

This is the reality that post-quantum cryptography was built to address. In August 2024, NIST finalized the first three post-quantum cryptographic standards after eight years of global evaluation. The algorithms are ready. The regulatory mandates are in force. What this blog examines is the other side of that progress: the specific, compounding risks facing organizations that have not yet begun to move, and why some of the damage that comes from waiting cannot be reversed by any future action.

This blog walks through what PQC is, how quantum computing breaks the systems organizations depend on today, the real risks of staying behind, and a strategy for making the transition before the window closes.

Understanding PQC

PQC, also referred to as quantum-resistant or quantum-safe cryptography, refers to cryptographic algorithms specifically designed to run on classical computers while remaining secure against attacks from both classical and quantum computers.

NIST evaluated 69 initial submissions over eight years before finalizing the first three standards in August 2024. A parallel track for additional signature diversity, launched in September 2022, advanced nine more candidates to Round 3 in May 2026 (NIST IR 8610). The current standardized and in-progress algorithms are:

Standard	Algorithm	Type	Primary Use Case	Security Category	Status
FIPS 203	ML-KEM (Kyber)	Lattice-based	Key exchange	1, 3, 5	Finalized Aug 2024
FIPS 204	ML-DSA (Dilithium)	Lattice-based	Digital signatures	2, 3, 5	Finalized Aug 2024
FIPS 205	SLH-DSA (SPHINCS+)	Hash-based	Long-term / high-assurance signatures	1, 3, 5	Finalized Aug 2024
FIPS 206	FN-DSA (FALCON)	Lattice-based	Compact signatures	TBD	Draft
HQC	HQC	Code-based	Backup KEM	TBD	Selected Mar 2025
Additional Signatures (IR 8610)	FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, UOV	Mixed	Non-lattice signature diversity	TBD	Round 3 (May 2026)

Note: NIST IR 8610 (May 2026) documents the advancement of nine additional signature candidates to Round 3 of a separate standardization track, launched specifically to broaden the portfolio with non-lattice general-purpose signatures and with schemes offering shorter signatures or faster verification than SPHINCS+. None of these algorithms is yet standardized. Organizations should adopt finalized FIPS standards now and monitor this track for future algorithm diversity options.

Because quantum computers change how we measure security, NIST does not use a simple bit-strength scale for PQC. Instead, it defines five security categories, each benchmarked against a specific, well-understood reference problem:

• Category 1: equivalent to the cost of breaking AES-128 with a quantum computer (Grover’s Algorithm). Suitable for most general-purpose use cases.
• Category 2: equivalent to SHA-256 collision resistance. Higher assurance than Category 1.
• Category 3: equivalent to AES-192. Recommended for sensitive data with longer confidentiality requirements.
• Category 4: equivalent to SHA-384 collision resistance.
• Category 5: equivalent to AES-256. The highest level; used where long-term, high-assurance security is required, including government systems, national security, and critical infrastructure.

For a detailed breakdown of all five categories, see NIST PQC Security Levels: A Guide to Categories 1–5.

Why PQC is Needed

PQC’s immediate purpose is straightforward: to replace the algorithms that quantum computers will break and to do so before those computers can be used against us. But the deeper purpose is less about a single migration and more about what that migration forces organizations to confront.

The objective of PQC is to future-proof data and systems against a world in which large-scale quantum computers are operational without disrupting or replacing the infrastructure already in place. Specifically, PQC is designed to:

• Protect long-term data confidentiality: Data that needs to stay confidential for years, including health records, financial transactions, legal documents, and national security communications which must be protected against attackers who are collecting encrypted traffic now to decrypt later. This is the Harvest Now, Decrypt Later (HNDL) threat. Adversaries do not need a quantum computer today to begin exploiting it. They are actively collecting and storing encrypted data now, with the intent of decrypting it once a capable quantum computer is available. That makes PQC adoption a present-tense requirement, not a future one.
• Preserve digital identity and trust: Digital signatures are the foundation of trust in modern systems. They verify that a certificate belongs to its claimed owner, that the software came from the publisher shown, and that the document has not been altered. If those signatures can be forged, digital trust collapses. PQC signatures are designed to remain forgery-resistant in a post-quantum world.
• Modernize existing PKI and protocol-level cryptography: PQC algorithms are being introduced into existing protocols through hybrid extensions. For TLS 1.3, the IETF has standardized a hybrid key exchange construction that combines classical elliptic-curve Diffie-Hellman with post-quantum KEMs such as ML-KEM. Similar integration work is underway for SSH, X.509 certificates, and existing PKI frameworks. Organizations do not need to replace their infrastructure; they need to update the cryptographic layer operating within it, and the transition has been designed to work with what organizations already have in place.
• Meet regulatory and compliance requirements: Federal mandates from NSA, CISA, and executive orders require quantum-safe cryptography across federal systems, with hard deadlines already in force. NIST’s finalized standards define the technical baseline that those mandates require. For organizations operating in regulated environments, PQC adoption is not optional. It is a mandated requirement, and the deadlines are already in effect.

A critical design goal running through all of this is crypto-agility, i.e., the ability to swap out cryptographic algorithms without rebuilding the systems that use them. NIST formally defines crypto-agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, and firmware while preserving security and ongoing operations. This matters because the migration to PQC will not be the last cryptographic transition. ML-KEM and ML-DSA are not permanent either.

Cryptographic history makes this clear. DES was replaced by AES, SHA-1 by SHA-2, and RSA key sizes have been increased repeatedly as computing power advanced. Each transition required significant organizational effort, and each one was, at the time, unexpected by those who had not planned for it. The same forces that drove those transitions remain active today. Building systems that can adapt to future algorithm changes is what separates a resilient cryptographic posture from a one-time fix.

How Quantum Computing Threatens Modern Cryptography

Now that we understand what PQC is and what it is designed to do, it helps to look closely at what we are protecting against, specifically, how quantum computers threaten the systems organizations rely on every day.

The security of RSA and ECC rests on mathematical problems that classical computers cannot solve efficiently enough to make attacks practical. For RSA, the best-known classical algorithm, the General Number Field Sieve (GNFS), runs in sub-exponential time, meaning that factoring large RSA keys remains computationally infeasible within any practical timeframe. For ECC, the underlying discrete logarithm problem is harder still classically, with the best-known attacks running in fully exponential time. In both cases, mathematics holds, not because the problems are theoretically unsolvable, but because solving them at the key sizes used in practice would take classical computers longer than is operationally meaningful.

Quantum computers change this picture entirely. Shor’s Algorithm solves both integer factorization and discrete logarithm problems in polynomial time on quantum hardware, collapsing the security assumptions that underpin RSA, Diffie-Hellman, and every ECC variant in a single algorithmic stroke. These are not marginal improvements in attack efficiency. They are fundamental breaks. Once a cryptographically relevant quantum computer (CRQC) exists, the algorithms securing most internet traffic today do not become weaker. They become broken.

Symmetric cryptography is more resilient. Grover’s Algorithm provides a quantum speedup, but it only reduces the effective security level by half. Doubling key lengths (AES-256 instead of AES-128) is considered an adequate response.

The critical exposure lies with asymmetric, public-key cryptography. Unlike symmetric algorithms, asymmetric systems derive their security from mathematical problems, specifically integer factorization and discrete logarithms, that Shor’s Algorithm can solve exponentially faster than any classical computer. This is not a marginal weakening; it is a fundamental break. No key-length adjustment addresses it, because the underlying mathematical assumption fails entirely. A sufficiently powerful quantum computer running Shor’s Algorithm would not weaken RSA, Diffie-Hellman, and ECC. It would break them.

This is why PQC focuses almost exclusively on replacing asymmetric algorithms.

1. Harvest Now, Decrypt Later (HNDL)

The most immediate threat does not require a CRQC to exist today. Nation-state adversaries and well-resourced attackers are already collecting and storing encrypted data with the intent to decrypt it once quantum capability arrives. This is the Harvest Now, Decrypt Later (HNDL) attack, and it is not theoretical; it is operationally rational and actively occurring.

For any organization transmitting data with long-term sensitivity requirements, including health records, financial transactions, government communications, intellectual property, and legal contracts, the effective breach window may have already opened. Adversaries do not need a quantum computer to begin the attack. They are intercepting and archiving encrypted data today, using classical infrastructure, with the intent to decrypt it once a capable quantum computer becomes available. The encryption protecting that data right now offers no guarantee of confidentiality in a post-quantum world. It only delays the moment of exposure. By the time a quantum computer arrives, the data is already in adversarial hands.

2. PKI and Certificate Infrastructure

Most PKI deployments are built entirely on the algorithms that quantum computers can break. Certificate authorities, TLS certificates, S/MIME, device certificates, and identity tokens all rely on RSA or ECC. When a CRQC breaks those algorithms, the entire trust chain PKI provides fails with them.

An attacker with a CRQC could:

• Forge certificates and impersonate any trusted server, device, or identity
• Retroactively decrypt archived TLS session recordings
• Bypass mutual TLS authentication in zero-trust architectures
• Invalidate the chain of trust for root and intermediate certificate authorities

PKI migration is not a simple software update. It means reissuing certificates across the entire infrastructure, updating root and intermediate CAs, validating compatibility with every dependent application, and managing the transition without service disruption. That process takes years under ideal conditions.

3. Code Signing

Code signing is the mechanism that guarantees software is genuine: that it came from the claimed publisher and has not been tampered with. Most code-signing infrastructure today uses RSA or ECDSA. A quantum computer that can forge these signatures creates a direct path for malware distribution at scale.

The consequences are concrete:

• Malware can be packaged with a valid-looking forged signature and distributed through official software update channels, bypassing endpoint detection tools entirely
• Firmware for critical infrastructure can be replaced with malicious versions that pass signature verification.
• Previously signed software packages become untrustworthy, since historical signatures are retroactively forgeable.

CISA’s October 2024 Post-Quantum Considerations for Operational Technology guidance explicitly identifies firmware integrity and secure boot compromise as primary risks for connected OT and IoT systems.

4. Other Affected Systems

Quantum vulnerability extends to any system using asymmetric cryptography:

System	Risk
VPNs and IPsec	Diffie-Hellman key exchange becomes breakable, allowing attackers to decrypt captured VPN sessions.
SSH	RSA and ECDSA host keys become vulnerable to impersonation, enabling man-in-the-middle attacks on remote access sessions.
Blockchain and cryptocurrency	ECC-based wallet key pairs can have private keys derived from public keys, enabling theft and transaction forgery without ever accessing the user’s device.
IoT and OT devices	Embedded systems using RSA or ECC for device authentication often cannot be updated in the field, meaning hardware replacement may be the only remediation path.
Email security	S/MIME and PGP-encrypted emails are subject to HNDL collection; signed emails become forgeable once RSA or ECDSA signatures can be broken.

Risks of Not Transitioning to PQC

Understanding the threat is one thing. Understanding what inaction costs an organization, operationally, financially, and reputationally, is another matter entirely. The following are the primary risks facing organizations that delay or avoid PQC adoption.

1. Data Breaches and Loss of Confidentiality

Once a CRQC is operational, any data protected by RSA or ECC encryption becomes decryptable, including databases, archived emails, past transactions, and communications. But due to HNDL, the timeline for this risk has already started. Organizations in the following sectors with long data retention requirements face the highest exposure:

• Personally identifiable information (PII), protected health records, and financial data become accessible retroactively.
• Trade secrets, research data, and intellectual property can be exposed from historical data stores.
• Government and legal communications that were encrypted years ago may be decryptable before classification periods expire.

2. Loss of Trust in Digital Systems

Digital trust depends on the assumption that signatures are genuine and certificates correctly identify who issued them. When RSA and ECC signature schemes fail, that assumption collapses across the entire ecosystem:

• Code-signing certificate forgeries enable malware to be distributed through legitimate update channels with no visible warning to end users or endpoint security tools.
• TLS certificate impersonation allows adversaries to intercept communications from users who believe they are connected to a trusted service.
• Certificate-based device identity becomes unreliable, allowing unauthorized devices to pass authentication checks.
• Identity verification systems using digital certificates (smart cards, FIDO tokens, device certificates) are directly undermined.

The reputational and operational damage from a compromise of certificate infrastructure extends far beyond the technical failure itself.

3. Regulatory and Compliance Risks

PQC compliance requirements are no longer hypothetical. Binding mandates are already in force:

Mandate	Details
NSM-10	Requires federal agencies to inventory quantum-vulnerable systems and migrate to PQC with the goal of mitigating as much quantum risk as feasible by 2035. Agencies are required to submit annual cryptographic inventories to both CISA and the Office of the National Cyber Director (ONCD), with the first submission deadline having passed in May 2023.
NSA CNSA 2.0	Mandates PQC adoption for National Security Systems on a phased, system-type-specific timeline. Network equipment such as VPNs and routers must exclusively use CNSA 2.0 by 2030; operating systems, cloud services, applications, and legacy systems must complete transition by 2033; full migration across all NSS is targeted by 2035.
Executive Order 14306	Requires federal agencies to acquire only PQC-capable products in categories where quantum-safe alternatives are widely available. CISA, in coordination with NSA, published the initial product category list on January 23, 2026, and will update it regularly.
Department of War CIO Memorandum	Requires all DoW components to inventory all cryptographic systems across every system type including national security systems, weapons systems, cloud capabilities, mobile devices, IoT, and operational technology; designate component-level PQC migration leads; and phase out pre-shared key and symmetric key distribution protocols, replacing them with NIST-approved PQC algorithms no later than December 31, 2030. The memorandum also prohibits testing, procurement, or use of quantum key distribution for security purposes.

For organizations outside the direct federal scope, sector-specific requirements are moving in the same direction, though at varying stages of formalization. A proposed HIPAA Security Rule update published in January 2025 would make encryption of all electronic protected health information mandatory, and organizations implementing only classical encryption today will face a second, more disruptive migration when quantum-safe encryption becomes the regulatory baseline. PCI DSS 4.0 already requires organizations to maintain a cryptographic inventory and a migration plan for deprecated algorithms. Financial institutions and critical infrastructure operators should expect explicit PQC requirements to follow as frameworks continue to evolve. Organizations that delay migration expose themselves to a range of compounding consequences, including the following:

• Disqualification from federal procurement contracts as PQC capability becomes a vendor requirement.
• Fines and enforcement actions as data protection regulations are updated to require quantum-safe encryption.
• Audit findings that flag continued use of deprecated algorithms as a material vulnerability.

4. Operational and Migration Cost Escalation

NIST has consistently emphasized in SP 1800-38 and CSWP 39 that most current systems were not designed with crypto agility in mind, meaning algorithm replacement typically requires significant re-engineering rather than a straightforward update. The longer organizations wait, the more that problem compounds:

• Systems grow more deeply embedded, interdependent, and resistant to change over time.
• Legacy devices in OT, ICS, and healthcare environments may require hardware replacement rather than software updates.
• Organizations approaching regulatory deadlines without preparation face compressed timelines that force rushed, high-risk migrations.
• A reactive migration under deadline pressure is significantly more expensive and disruptive than a phased, planned transition begun well in advance.

The organizations moving early have an advantage that compounds with time. Every month of preparation now reduces cost, risk, and disruption later.

5. Supply Chain and Third-Party Risk

Even a fully migrated internal environment remains exposed if critical vendors, software suppliers, or managed service providers continue to rely on quantum-vulnerable algorithms. Firmware signing, PKI infrastructure, hardware security modules, and software update mechanisms operated by third parties are all potential attack surfaces, and most organizations have limited visibility into which of their suppliers are quantum-ready.

• Software vendors whose update packages are signed with RSA or ECDSA present a code-signing risk that extends into every customer environment they serve.
• Managed service providers and cloud platforms that handle encrypted data or manage cryptographic keys on behalf of customers inherit and extend any quantum vulnerability present in the underlying infrastructure on which they operate.
• Hardware suppliers such as HSM vendors, TPM manufacturers, and network equipment providers may require firmware updates or hardware replacement to support PQC; procurement timelines for these components can run 12–24 months.
• Third-party libraries and open-source dependencies embedded in applications often contain hardcoded cryptographic implementations that are invisible to standard software inventories and resistant to rapid patching.

NIST SP 1800-38 specifically calls out third-party and supply chain readiness as a migration prerequisite. PQC capability should be assessed and required in vendor contracts, RFPs, and procurement criteria.

How to Prepare for PQC

NIST, CISA, and the NSA each recommend a structured migration approach grounded in NIST SP 1800-38 and CISA’s Quantum-Readiness guidance. The following steps reflect that framework:

Step 1: Build a Cryptographic Inventory

Before anything else, organizations need to know where cryptography lives. A Cryptographic Bill of Materials (CBOM) is the foundational artifact for this inventory. It should document: every certificate and its issuing algorithm; all key management systems and key exchange mechanisms; every application and service implementing TLS, SSH, S/MIME, or other cryptographic protocols; embedded and OT/IoT devices that use cryptography; and third-party dependencies and vendor-supplied systems. NIST SP 1800-38 identifies this inventory as the prerequisite for every subsequent migration decision.

Step 2: Prioritize Based on Risk

Not everything needs to migrate at once. Prioritization should be based on data sensitivity, how long the data must remain confidential, and HNDL exposure. Systems protecting long-lived sensitive data should migrate first. NIST recommends a risk management methodology that weighs both data criticality and the technical difficulty of migrating each system.

Step 3: Establish a Phased Migration Roadmap

A structured roadmap should specify: target algorithms (ML-KEM for key exchange, ML-DSA for signatures in most cases, SLH-DSA where long-term or high-assurance signing is needed), protocol migration paths for TLS, SSH, PKI, and other affected systems, and timelines tied to regulatory deadlines. Where systems cannot be migrated immediately, hybrid cryptography running both classical and PQC algorithms simultaneously maintains interoperability during the transition period.

Step 4: Assess Vendor and Supply Chain Readiness

The NIST SP 1800-38 series, CISA’s Quantum-Readiness guidance, and broader federal PQC migration frameworks all emphasize that quantum readiness cannot stop at an organization’s own perimeter. Organizations should engage technology vendors early, requesting clear quantum-readiness roadmaps and incorporating PQC capability into vendor assessments and procurement decisions. A fully migrated internal environment remains exposed if a critical vendor’s firmware signing, PKI infrastructure, or hardware security modules remain quantum vulnerable. PQC capability should therefore become a standard procurement criterion, and the CISA product category list published under Executive Order 14306 provides a practical reference for identifying product categories where quantum-safe alternatives are already widely available.

Step 5: Build In Crypto-Agility

The transition to ML-KEM and ML-DSA is necessary, but it is not the endpoint. NIST is still finalizing FIPS 206 (FN-DSA) and is progressing the standardization of HQC. Future algorithm updates are inevitable as cryptography will keep evolving. Crypto-agility means avoiding hardcoded algorithm dependencies, centralizing cryptographic policy enforcement, and investing in tooling that provides continuous visibility into your cryptographic posture. The goal is to make the next transition orderly rather than disruptive.

Achieving crypto-agility in practice requires deliberate architectural decisions. Organizations should abstract cryptographic functions into centralized libraries or services rather than embedding algorithm-specific logic across individual applications. Key management systems, certificate authorities, and TLS configurations should be designed to support algorithm negotiation and rapid substitution without requiring application-level changes. Automated cryptographic discovery tooling ensures that the inventory built in Step 1 does not go stale as systems evolve. Together, these capabilities mean that when the next algorithm change arrives, whether driven by a new standard, a deprecation, or an unforeseen vulnerability, the organization is positioned to respond in weeks, not years.

These five steps represent the migration framework that leading organizations are executing today. The challenge for most is not understanding what needs to be done, but having the expertise, tooling, and bandwidth to do it. That is where Encryption Consulting helps organizations move from framework to execution.

How Can Encryption Consulting Help

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise. Our PQC Advisory Services are built to guide you through every phase of your post-quantum transformation.

Cryptographic Discovery and Inventory

We scan certificates, keys, algorithms, libraries, and protocols across your entire IT environment, including endpoints, applications, APIs, network devices, databases, and embedded systems. We identify all on-prem, cloud, and hybrid systems using cryptography and gather key metadata such as algorithm types, key sizes, expiration dates, and certificate chains. The result is a detailed inventory database that serves as the baseline for risk assessment and migration planning.

PQC Assessment

We assess your environment for quantum vulnerability through stakeholder interviews and analysis of cryptographic elements, particularly those relying on RSA, ECC, and other at-risk algorithms. We evaluate PKI and HSM configurations for post-quantum readiness and flag applications with hardcoded cryptographic dependencies. The engagement concludes with a report covering vulnerable asset inventory, risk severity ratings, and a prioritized migration plan.

PQC Strategy & Roadmap

We develop a custom, phased migration strategy aligned to your business, technical, and regulatory requirements, reflecting your risk appetite, NIST standards, and NSA CNSA 2.0 recommendations. Deliverables include updated security policies, key management procedures, and a step-by-step roadmap with short-, medium-, and long-term milestones across pilot, hybrid deployment, and full implementation phases.

Vendor Evaluation & Proof of Concept

We help you identify and validate the right tools and partners for your post-quantum goals, defining RFI/RFP requirements, shortlisting PQC-capable vendors, and running PoC tests in isolated environments. You receive a vendor comparison matrix and recommendation report based on real-world findings.

Pilot Testing & Scaling

We validate the migration through controlled pilots, testing new cryptographic models in sandbox environments, confirming interoperability with existing and legacy systems, and incorporating feedback from IT, security, and business teams. Once validated, we support a phased, scalable rollout with ongoing monitoring and optimization.

PQC Implementation

We execute the full-scale migration, deploying hybrid classical and quantum-safe models for backward compatibility, rolling out PQC across PKI, applications, infrastructure, cloud services, and APIs, and providing hands-on training and technical documentation. We establish monitoring and lifecycle management processes to track cryptographic health and support future upgrades.

Transitioning to quantum-safe cryptography is a big step, but you do not have to take it alone. A successful migration begins with understanding where cryptography exists across your environment and identifying the assets that may be vulnerable to quantum-era threats.

CBOM Secure

Our CBOM Secure helps solve this challenge by continuously discovering and inventorying cryptographic assets across your enterprise. Instead of relying on manual tracking and spreadsheets, security teams gain a centralized view of keys, certificates, algorithms, cryptographic libraries, protocols, and dependencies throughout their environment. 

With this visibility, organizations can quickly identify quantum-vulnerable algorithms, locate systems that may require remediation, and prioritize migration efforts based on risk and business impact. Our CBOM Secure also helps uncover hidden cryptographic dependencies that could otherwise delay post-quantum initiatives or create unexpected operational challenges during migration. 

Beyond quantum readiness, our CBOM Secure improves overall cryptographic governance by helping teams maintain accurate inventories, monitor cryptographic changes, and support compliance and security assessments. Continuous discovery ensures that inventories remain current as infrastructure, applications, and cloud resources change over time. 

With Encryption Consulting by your side, you will have the right guidance and expertise needed to build a resilient, future-ready security posture. Reach out to us at [email protected] and let us build a customized roadmap that aligns with your organization’s specific needs.

Conclusion

Quantum computing is not the problem. It is the proof that cryptography changes, and that everything built on top of it must be designed to change with it.

PQC exists because standards, governments, and the global security community recognized this reality early enough to act on it. The primary algorithms are standardized. The migration guidance is published. The regulatory deadlines are in place. After eight years of exhaustive global evaluation, cryptographic groundwork has been laid. The standards exist, and the path is clear. What remains for organizations is to begin.

The risks of inaction are not abstract. Data is being harvested today for future decryption. PKI and code-signing infrastructure built on RSA and ECC will fail when a CRQC arrives. Compliance mandates are already binding for federal systems, and sector-specific requirements are following suit. The longer organizations wait, the more risk accumulates. Migration costs rise, regulatory timelines become tighter, and larger volumes of previously transmitted data remain vulnerable to future decryption.

Organizations that act now retain control of the process with the time to inventory assets thoroughly, transition systems systematically, and build crypto-agility. That is the posture Encryption Consulting helps organizations reach.