Imagine a classified government file, encrypted today with RSA-2048, containing diplomatic communications that will remain sensitive for the next 20 years. A sophisticated nation-state actor exfiltrates a copy of the encrypted file tonight. They cannot read it. Not yet. But they store it, and they wait.

In 2034, they operate a quantum computer capable of running Shor's algorithm against RSA. The file, encrypted in 2026, is decrypted in hours.

This attack pattern – "harvest now, decrypt later" (HNDL) – is not theoretical. Intelligence agencies in multiple countries are actively warning that adversaries are already exfiltrating encrypted data at scale, banking on quantum decryption capability arriving within a decade. The encryption protecting data stolen in today's breach may not survive the decade.

This is why the migration to post-quantum cryptography cannot wait until quantum computers exist. For any data with confidentiality requirements extending beyond approximately 2032-2035, the protection decision must be made now.

NIST made that decision easier on August 14, 2024, when it finalized the first three post-quantum cryptographic standards – the first approved alternatives to RSA and ECC in authentication and encryption. The compliance clock is running. By January 1, 2027, all new US National Security System acquisitions must be compliant with CNSA 2.0, the NSA's post-quantum algorithm suite. Full mandatory compliance across most NSS system types is required by 2033.

This guide is for the engineers, architects, and CISOs who need to understand what these standards mean for authentication specifically – not just for encrypted storage – and how to build a migration plan that is actionable in 2026.

What Quantum Computers Actually Threaten (And What They Do Not)

The term "quantum computing threat to security" is frequently used imprecisely. It is worth being specific about which algorithms are vulnerable and which are not, because the migration priority and urgency differ.

The Vulnerable Algorithms: Asymmetric Cryptography

The threat comes from Shor's algorithm, which runs efficiently on a sufficiently large quantum computer and can factor large integers and solve discrete logarithm problems in polynomial time. This breaks:

• RSA: RSA-2048 and RSA-4096 encryption and digital signatures
• ECC (Elliptic Curve Cryptography): ECDSA, ECDH, Ed25519 – the signature schemes used in TLS, certificates, and passkeys
• Diffie-Hellman key exchange: Including the DHE and ECDHE handshakes used in TLS sessions

The authentication impact is substantial. Every certificate authority signature, every JWT or SAML assertion signed with RSA or ECDSA, every TLS handshake that establishes a secure channel, every FIDO2 passkey built on P-256 or Ed25519 – all are mathematically vulnerable to a sufficiently powerful quantum computer.

The Relatively Safe Algorithms: Symmetric Cryptography

Grover's algorithm provides a quadratic speedup against symmetric encryption. For AES-128, this effectively reduces security to AES-64 in a quantum attack model – which is not acceptable. For AES-256, the quadratic speedup reduces effective security to AES-128, which remains computationally infeasible to brute-force even with quantum acceleration.

The practical guidance: AES-256 is safe for the foreseeable quantum future. AES-128 should be deprecated in favor of AES-256 for any data with long-term confidentiality requirements. SHA-384 is preferred over SHA-256 for similarly conservative long-term use.

This means the migration scope is specifically asymmetric cryptography: key exchange, digital signatures, and public key encryption. Your AES-256 encrypted data stores are not the primary concern.

The NIST PQC Standards: What Is Final, What to Deploy Now

NIST's post-quantum cryptography standardization process began in 2016 and has evaluated 82 candidate algorithms from 25 countries through multiple rounds. On August 13-14, 2024, NIST published the first three finalized post-quantum standards, effective immediately for US federal use.

The three finalized NIST PQC standards (August 14, 2024):ML-KEM (FIPS 203) – Key Encapsulation Mechanism for secure key exchange, replaces RSA/ECDH in TLS and VPNsML-DSA (FIPS 204) – Digital Signature Algorithm for general-purpose signing, replaces ECDSA in certificates and authentication tokensSLH-DSA (FIPS 205) – Stateless Hash-Based Digital Signature, conservative hash-based backup with larger signatures but simpler security assumptions

These standards are ready for deployment today. NIST's own guidance: "There is no need to wait for future standards. Go ahead and start using these three."

ML-KEM (FIPS 203): The Key Exchange Replacement

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the primary replacement for the key exchange mechanisms used in TLS handshakes – specifically the RSA key exchange and the ECDH (Elliptic Curve Diffie-Hellman) that secure the channel before encrypted data is transmitted.

Three parameter sets provide a security-performance tradeoff: ML-KEM-512 (fastest, equivalent to AES-128 security level), ML-KEM-768 (recommended default, equivalent to AES-192), and ML-KEM-1024 (strongest, equivalent to AES-256 for environments requiring maximum security or with very long data retention requirements).

Akamai began deploying hybrid ML-KEM + X25519 key exchange for browser-to-Akamai connections as a limited availability feature in September 2025, with plans to make it default for all customers in February 2026. This means that if your applications are behind Akamai, TLS key exchange PQC protection is becoming default infrastructure shortly.

ML-DSA (FIPS 204): The Signature Standard for Authentication

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the most relevant standard for authentication systems specifically. It is the direct replacement for ECDSA and RSA signature schemes used in:

• JWT tokens (the signatures that make JWTs tamper-evident)
• SAML assertions (the signatures that make federation trust chains work)
• X.509 certificates (including TLS certificates and CA-signed authentication certificates)
• OAuth tokens and similar authorization artifacts

ML-DSA provides three security parameter sets. The middle tier (ML-DSA-65) is the recommended default for most authentication use cases, balancing security, signature size, and computational performance. For authentication systems where bandwidth is not constrained and long-term signature validity is important, ML-DSA-87 provides higher security margins.

SLH-DSA (FIPS 205): The Conservative Backup

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) takes a different mathematical approach from ML-DSA. Rather than lattice problems (the mathematical basis of ML-KEM and ML-DSA), SLH-DSA's security is based on the properties of hash functions – one of the most well-understood and battle-tested constructs in cryptography.

The tradeoff: SLH-DSA signatures are larger than ML-DSA signatures (ranging from 8KB to 49KB depending on parameter set, versus a few hundred bytes for ML-DSA). For applications where signature bandwidth matters, this is significant. For applications where long-term cryptographic resilience matters more than performance, SLH-DSA is the more conservative choice.

The security argument for SLH-DSA: if a fundamental weakness is discovered in lattice-based cryptography (unlikely but not impossible), ML-KEM and ML-DSA deployments would be simultaneously vulnerable. SLH-DSA's hash-based security provides a backup with independent security assumptions.

What Is Coming Next

Two additional standards are in the pipeline that will matter for authentication:

FN-DSA / FALCON (draft FIPS 206): Compact signatures suitable for bandwidth-constrained environments. FALCON produces signatures significantly smaller than ML-DSA, making it valuable for high-volume authentication token scenarios. It is progressing through the NIST standardization pipeline and organizations should design their cryptographic infrastructure to support it when finalized.

HQC: Selected for standardization in March 2025 as a code-based KEM backup to ML-KEM. Expected finalization 2026-2027. Provides algorithm diversity for organizations that want to hedge against potential ML-KEM weaknesses.

The Compliance Timeline: When Organizations Must Act

Who NSS Requirements Apply To

National Security System (NSS) requirements under CNSA 2.0 apply directly to US federal agencies and their contractors building systems that process classified information. However, the supply chain pressure is much broader: federal contractors, defense suppliers, and companies with significant federal contracts face procurement requirements that effectively extend the CNSA 2.0 timeline to their authentication infrastructure.

What Commercial Organizations Should Do

Commercial organizations outside the federal contractor sphere have no hard PQC deadline today. But the HNDL threat does not care about regulatory deadlines. Any organization encrypting or signing data with multi-year confidentiality requirements – healthcare records, financial data, intellectual property, authentication logs – has a practical deadline determined by when quantum computers become capable, not when a regulator issues guidance.

The Boston Consulting Group 2025 assessment: "starting in 2030 will already be too late" for organizations with sensitive long-retention data. Factor your organization's specific data retention and sensitivity profile into your migration timeline, not just regulatory deadlines.

Authentication-Specific PQC: What Needs to Change

Most PQC discussion focuses on encrypted data in transit and at rest. Authentication systems have an equally urgent but distinct set of vulnerabilities that receive less attention.

Digital Certificates and PKI

Every X.509 certificate used in HTTPS, authentication, and code signing is signed with RSA or ECDSA. The entire PKI trust chain – root CA, intermediate CA, leaf certificate – is vulnerable to quantum attack. An attacker with a quantum computer who could forge or extract a CA's private key would be able to sign arbitrary certificates, enabling undetectable impersonation of any authenticated service.

Certificate authorities (CAs) are actively working on PQC certificate issuance roadmaps. Let's Encrypt, DigiCert, and other major CAs have published timelines for PQC certificate support. Organizations should monitor their CA's roadmap and plan certificate migration cycles accordingly. The typical certificate renewal cycle (1-2 years) provides natural migration windows.

JWT and SAML Token Signing

Every JSON Web Token (JWT) is signed with RSA or ECDSA. When an application validates a JWT, it verifies the cryptographic signature to ensure the token has not been tampered with and was issued by a trusted authority. RSA-2048 JWT signatures are among the most widespread cryptographic operations in modern web applications.

SAML assertions – the basis of enterprise SSO federation – use RSA-SHA256 or RSA-SHA512 signatures. Every SAML-based SSO exchange depends on the unforgeable property of RSA, which a quantum computer with sufficient qubits would undermine.

Migration path: update JWT signing libraries to support ML-DSA signing when RFC or IETF standards for PQC JWT emerge (active work is underway in IETF working groups). Design systems with algorithm agility so the signing algorithm can be updated without application rewrites.

TLS Handshakes

Every HTTPS session begins with a TLS handshake that uses key exchange (ECDH or RSA) to establish the session encryption keys. ML-KEM directly replaces this function. The hybrid approach – ML-KEM + X25519 – is the deployment-ready interim strategy: use both algorithms simultaneously, providing classical security through X25519 and quantum protection through ML-KEM.

The hybrid approach is permitted by NIST and is validatable under FIPS 140-3 as long as the PQC component (ML-KEM) is NIST-approved. EU authorities including ANSSI and BSI actively recommend hybrid TLS deployments now.

Passkeys and FIDO2 Authentication

Current FIDO2 passkey implementations use P-256 (NIST P-256, an elliptic curve) or Ed25519 for the assertion signature – the cryptographic proof that the authenticating device holds the passkey private key. Both are ECC-based and therefore vulnerable to Shor's algorithm.

The path forward for post-quantum passkeys: IANA added post-quantum cryptographic algorithms to the COSE (CBOR Object Signing and Encryption) codelist in April 2025. COSE governs how WebAuthn credentials are encoded, which is the technical foundation that will eventually allow FIDO2 authenticators to use PQC signature schemes.

This does not mean post-quantum passkeys are deployable today – it means the standards groundwork exists. Organizations should design their passkey infrastructure for algorithm agility, expecting PQC passkey standards to emerge within the next 2-3 years. MojoAuth has stated its commitment to building toward post-quantum authentication support as these standards mature.

The Harvest Now Decrypt Later Threat: Why Action Cannot Wait

HNDL is the argument that changes organizational migration timelines from "eventually" to "now for long-retention data."

The logic is straightforward:

• A quantum computer capable of breaking RSA-2048 does not exist today, but security researchers project it could exist within a decade
• Encrypted data stolen today will still exist in 2034
• If the data was encrypted with RSA-2048 and has value in 2034 (healthcare records, financial transaction history, classified communications, intellectual property), a 2034 quantum computer can retroactively decrypt it

This is not a hypothetical. The NSA's public advisory materials explicitly warn that some categories of sensitive data should be treated as already at risk. Nation-state threat actors – particularly those with significant investments in quantum computing research – are assessed to be collecting encrypted data today for future quantum decryption.

Which Data Is at Risk

Not all data has the same HNDL exposure. The calculation depends on: how long the data retains value (sensitivity horizon) versus how long until quantum computers can break the encryption (crypto-break horizon).

High HNDL risk (act now):

• Healthcare records (30+ year retention, high ongoing sensitivity)
• Financial transaction records (7+ year regulatory retention, high value for fraud)
• Intellectual property and trade secrets (indefinite value)
• Government classified communications
• Authentication logs that could retroactively prove identity assertions

Moderate HNDL risk (plan now, implement 2027-2028):

• Authentication tokens (typically short-lived, but some session persistence)
• Application certificates and signing keys (replace on renewal cycle)
• Employee identity data

Lower HNDL risk (plan now, implement by 2033):

• Short-lived session data
• Public-facing non-sensitive communications

The Six-Step Enterprise PQC Migration Roadmap

Step 1: Cryptographic Asset Inventory

You cannot migrate what you cannot find. The foundational step is discovering every place in your infrastructure that uses asymmetric cryptography:

• All TLS certificates (internal and external), including expiration dates and algorithm
• JWT signing keys and their configuration
• SAML signing certificates
• Code signing certificates (software release pipeline)
• SSH keys and authentication keys
• API authentication mechanisms using asymmetric signatures
• Database and storage encryption keys that use RSA key wrapping
• Passkey/FIDO2 infrastructure configuration

Tools: most certificate management platforms have discovery features. For application-level cryptography (JWT, SAML), this requires code audits or static analysis tooling. Start with the highest-exposure systems: externally facing services, systems processing regulated data, authentication infrastructure.

Step 2: Establish Crypto Agility in All New Systems

Before touching existing systems, set a standard for new systems: no hardcoded cryptographic algorithms. Every new authentication service, every new application component that signs or encrypts, must implement a cryptographic abstraction layer that allows algorithm swapping without code changes.

This is the NIST SP 800-131A guidance applied architecturally. A system built in 2026 with hardcoded RSA-2048 will require a code rewrite for migration. A system built in 2026 with algorithm-agile design (algorithm and key configuration are external to the business logic) can migrate by updating configuration.

In practice: Use cryptographic libraries that support algorithm negotiation and configuration. Abstract signing and key exchange operations behind interfaces that can be swapped. Define a configuration standard that includes algorithm selection as an explicit, version-controlled parameter.

Step 3: Hybrid Deployment for High-Priority Systems

Begin PQC migration with hybrid deployments on your highest-priority systems. The hybrid approach runs classical and post-quantum algorithms in parallel: a session is protected by both ECDH and ML-KEM simultaneously. An attacker would need to break both algorithms to compromise the session. This provides quantum protection while maintaining compatibility with classical systems that do not yet support PQC.

For TLS: Hybrid ML-KEM-768 + X25519 key exchange. Start with your external-facing services and customer authentication endpoints.

For authentication tokens: Hybrid signing with both ECDSA and ML-DSA. Token validators that understand only ECDSA will continue to work (they verify the classical signature). Token validators updated for PQC will verify both.

This hybrid period is a bridge. The target state is full PQC – operating both algorithms adds computational overhead and complexity. But the hybrid approach allows migration without breaking compatibility.

Step 4: Certificate and PKI Migration

Work with your Certificate Authority on their PQC certificate issuance timeline. Key decisions:

• When your CA supports PQC, migrate to PQC-signed certificates on the next renewal cycle for externally facing systems
• For internal PKI (if you operate your own Certificate Authority), plan the migration of root CA, intermediate CAs, and the leaf certificates they sign
• Verify that your hardware security modules (HSMs) support PQC algorithm operations – not all HSMs support ML-KEM or ML-DSA yet. SEALSQ and other HSM vendors are targeting 2025-2026 for NIST-approved PQC algorithm integration into secure elements.
• Update certificate validation logic in applications to support PQC certificate chains

Step 5: Authentication System Updates

Prioritize in this order based on attack surface exposure:

TLS handshake protection (highest priority): Directly affects every user connection. The hybrid ML-KEM approach described above applies here. This also addresses HNDL attacks on authentication session establishment.

Token signing (JWT, SAML): Update signing to ML-DSA as JWT and SAML PQC signing standards are finalized in IETF working groups. Monitor IETF progress on RFC standards for PQC JWT.

Code signing: NSA guidance explicitly recommends adopting NIST SP 800-208 (LMS/XMSS hash-based signatures) for software and firmware update signing immediately, ahead of other authentication migrations. This protects the software supply chain.

Passkey/FIDO2: Monitor FIDO Alliance and IANA for post-quantum passkey standard progression. Design passkey infrastructure with algorithm agility so migration is configuration-based when standards are finalized.

Step 6: Vendor Assessment and Ongoing Monitoring

Every security vendor in your stack has a PQC migration timeline that affects you. Key assessments:

• Cloud providers: AWS, Azure, and GCP all have PQC TLS migration roadmaps. Understand when PQC becomes available and default in your cloud infrastructure.
• CIAM and identity platforms: For a review of enterprise CIAM platforms and their PQC readiness, see the top 5 enterprise CIAM platforms 2026 comparison. MojoAuth, covered in the fast-growing CIAM providers guide, is actively building post-quantum authentication support following the IANA COSE codelist update.
• HSM vendors: Confirm post-quantum algorithm support timelines for your hardware
• Certificate authorities: Confirm PQC certificate issuance timelines for your CA of record

Algorithm Selection Quick Reference

Frequently Asked Questions

What are ML-KEM, ML-DSA, and SLH-DSA?

ML-KEM (FIPS 203) is a Key Encapsulation Mechanism – it establishes shared secrets for encrypted communication, replacing RSA and ECDH key exchange in TLS. ML-DSA (FIPS 204) is a digital signature algorithm, replacing ECDSA and RSA for signing tokens, certificates, and authentication artifacts. SLH-DSA (FIPS 205) is a hash-based digital signature algorithm with more conservative security assumptions than ML-DSA, providing a safety net if lattice cryptography weaknesses are discovered. All three were finalized by NIST on August 14, 2024.

Do I need to replace AES-256 or SHA-256?

AES-256 remains secure in the quantum model – Grover's algorithm reduces its effective security to AES-128 levels, which is still computationally infeasible to brute-force. AES-128 should be upgraded to AES-256 for data with long retention periods. SHA-256 has some quantum vulnerability to collision attacks; SHA-384 is the conservative choice for long-term signature verification. Your primary migration focus is asymmetric cryptography: RSA, ECC, Diffie-Hellman.

Are passkeys post-quantum safe?

Current passkey implementations using P-256 or Ed25519 are not post-quantum safe. IANA added PQC algorithm support to the COSE codelist in April 2025, creating the standards foundation for post-quantum passkeys. Finalized standards and deployable post-quantum passkeys are expected to emerge within 2-3 years. Design your passkey infrastructure with crypto agility now to prepare.

What is CNSA 2.0 and who must comply?

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) was released by the NSA in September 2022 and establishes the post-quantum baseline for National Security Systems. Mandatory compliance timelines: new NSS acquisitions must be CNSA 2.0 compliant from January 1, 2027, with full compliance for most NSS types by 2033. CNSA 2.0 directly applies to US federal agencies and national security contractors. Commercial organizations are not directly required to comply but face supply-chain pressure from federal contract requirements and should treat the timeline as industry guidance.

How long does a PQC migration typically take?

Organizations with mature cryptographic asset inventories and crypto-agile architectures: 2-3 years for a comprehensive migration. Organizations with hardcoded cryptography in legacy applications: 4-6 years or more. The migration effort is front-loaded in the discovery and architecture phases. This is why starting now, even if production deployments are a year away, is critical.

What to Read Next

• Passkeys Enterprise Deployment Playbook 2026 – Understanding current passkey cryptography before planning the post-quantum transition
• Future of Authentication 2026-2030 – How PQC convergence with passkeys and decentralized identity shapes the 2030 authentication landscape
• Top 5 Enterprise CIAM Platforms 2026 – Evaluating CIAM platform PQC readiness as part of platform selection
• 5 Fast-Growing CIAM Providers 2026 – Including MojoAuth's post-quantum authentication roadmap
• What Is Zero Trust Security? – Why cryptographic integrity is foundational to Zero Trust architecture

Deepak Gupta is the Co-founder and CEO of GrackerAI and an AI and Cybersecurity expert with 15+ years in digital identity and enterprise security. He scaled a CIAM platform to serve over one billion users globally. He writes about cybersecurity, AI, and B2B SaaS at guptadeepak.com.

*** This is a Security Bloggers Network syndicated blog from Deepak Gupta | AI & Cybersecurity Innovation Leader | Founder's Journey from Code to Scale authored by Deepak Gupta - Tech Entrepreneur, Cybersecurity Author. Read the original post at: https://guptadeepak.com/post-quantum-cryptography-for-authentication-the-enterprise-migration-guide-2026/