The CNSA 2.0 Timeline
The National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) establishes a concrete timeline for the deprecation of classical cryptographic algorithms and the mandatory adoption of post-quantum alternatives. This is not a recommendation. It is a directive for national security systems, and it establishes the standard of care that will apply across the commercial sector.
The key dates are unambiguous. By 2030, RSA and Diffie-Hellman key exchange must be deprecated in favor of ML-KEM (FIPS 203). By 2030, RSA and ECDSA digital signatures must be deprecated in favor of ML-DSA (FIPS 204). By 2035, all cryptographic operations must use exclusively post-quantum algorithms. The transition period for hybrid implementations (using both classical and post-quantum algorithms simultaneously) ends in 2035.
For the insurance industry, these dates have immediate implications. A cyber insurance policy written in 2026 for an organization using RSA-2048 key exchange is underwriting an organization whose cryptography will be officially classified as deprecated within four years. Data encrypted under that policy period using RSA-protected channels is vulnerable to harvest-now-decrypt-later attacks that may materialize during or after the policy period. The underwriter is accepting risk on cryptographic infrastructure that has a government-mandated expiration date.
Harvest-Now-Decrypt-Later Explained
Harvest-now-decrypt-later (HNDL) is not a theoretical attack. It is an active intelligence collection strategy documented by multiple government agencies. The concept is simple: an adversary intercepts and stores encrypted network traffic today, with the intention of decrypting it when a sufficiently powerful quantum computer becomes available. The encrypted data has value as long as the underlying information remains sensitive — which for many categories of data (health records, financial records, trade secrets, national security information) is measured in decades.
The timeline for quantum computing capability is uncertain, but the consensus has narrowed. NIST, the NSA, and leading quantum computing researchers estimate that cryptographically relevant quantum computers (CRQCs) capable of breaking RSA-2048 will be available between 2030 and 2040. Some estimates are more aggressive. The Chinese government has published research suggesting significant progress. Google, IBM, and other major quantum computing programs are advancing rapidly.
The insurance implication is straightforward: if an organization's data is intercepted today using RSA-encrypted channels, and a CRQC becomes available in 2035, the data can be decrypted in 2035. If that data includes health records protected under HIPAA, financial records protected under GLBA, or personal information protected under GDPR, the breach materializes in 2035 — nine years after the policy period when the interception occurred. The notification obligations, regulatory fines, litigation exposure, and remediation costs all materialize at that future date.
This is the long-tail liability that makes HNDL the asbestos of cyber insurance. The exposure is accumulating silently in every policy written for organizations using classical cryptography. The claims will materialize years after the policies expire. The actuarial models are not designed for this time horizon. The carriers writing these policies today may not exist when the claims arrive.
How Post-Quantum Readiness Affects Underwriting
Forward-thinking underwriters are beginning to ask about cryptographic architecture. The questions are appearing on supplemental questionnaires and specialty cyber applications. They ask about key exchange algorithms, signature schemes, TLS versions, and migration plans. The answers directly affect risk assessment.
An organization using ML-KEM for key exchange presents a fundamentally different HNDL risk profile than an organization using RSA-2048 or ECDH P-256. The ML-KEM organization's traffic, if intercepted, cannot be decrypted by a quantum computer because ML-KEM is based on lattice problems that are resistant to Shor's algorithm. The RSA organization's traffic can be decrypted. The difference in long-tail exposure is not incremental — it is binary. One organization has HNDL exposure. The other does not.
For underwriters modeling this risk, the questions that should appear on every cyber insurance application by 2027 include:
- What key exchange algorithms are currently deployed for external-facing TLS connections? (RSA, ECDH, ML-KEM, hybrid)
- What digital signature algorithms are used for code signing, document signing, and API authentication? (RSA, ECDSA, ML-DSA, hybrid)
- Has the organization completed a cryptographic inventory identifying all systems using quantum-vulnerable algorithms?
- Does the organization have a post-quantum migration plan with defined milestones and timelines?
- Are any data categories with long-term sensitivity (health records, financial records, trade secrets) transmitted or stored using quantum-vulnerable encryption?
- Has the organization deployed or evaluated NIST-standardized post-quantum algorithms (FIPS 203, FIPS 204)?
The answers to these questions should directly affect premium calculation. An organization with ML-KEM deployed across all external-facing connections has eliminated its HNDL exposure. An organization still using exclusively RSA carries the full HNDL liability. The premium difference should reflect the difference in long-tail expected loss.
The Standard of Care Argument
CISA's determination that post-quantum cryptographic products are "widely available" in certain categories establishes a legal standard of care that will affect both insurance underwriting and claims adjudication. When a technology is widely available and a government agency has recommended its adoption, failure to adopt becomes legally significant. An organization that suffers a quantum-enabled breach after CISA's determination may face the argument that they failed to adopt a widely available protection — which constitutes negligence under established legal frameworks.
For insurers, this standard of care argument cuts both ways. On the underwriting side, carriers that continue to insure organizations using exclusively classical cryptography without pricing the HNDL risk are potentially underpricing a known exposure. On the claims side, carriers that denied coverage for quantum-enabled breaches may face arguments that they should have required PQ migration as a condition of coverage — just as they required MFA.
The parallel to MFA is instructive. In 2022, most carriers began requiring MFA as a condition of coverage. Organizations that did not have MFA could not obtain cyber insurance at any price. This mandate drove more MFA adoption than a decade of NIST guidelines. The same dynamic will play out with post-quantum cryptography. Carriers will begin requiring PQ readiness as a condition of coverage. The timeline will accelerate as CNSA 2.0 deprecation dates approach. Organizations that adopt early will have coverage continuity. Organizations that wait will face coverage gaps.
The Quantum Readiness Assessment
Assessing an organization's quantum readiness requires evaluating four dimensions: cryptographic inventory, migration readiness, implementation quality, and operational validation.
Cryptographic inventory identifies every system, application, and protocol that uses quantum-vulnerable algorithms. This includes TLS configurations on web servers, VPN concentrators, email servers, API gateways, and internal services. It includes key management systems, certificate authorities, code signing infrastructure, and document signing workflows. It includes database encryption, file encryption, and backup encryption. The inventory must be comprehensive because a single unprotected channel creates HNDL exposure for all data traversing that channel.
Migration readiness assesses the organization's ability to transition from classical to post-quantum algorithms. This includes software compatibility (do the organization's systems support FIPS 203/204?), hardware capability (can the organization's servers and network equipment handle the larger key sizes and different computational characteristics of PQ algorithms?), and operational procedures (are the organization's key management processes updated for PQ key lifecycle management?).
Implementation quality evaluates whether the PQ algorithms are implemented correctly. Incorrect implementation of cryptographic algorithms can create vulnerabilities that defeat the algorithm's security properties. Implementation quality assessment includes parameter selection review, random number generator quality, side-channel resistance, and compliance with NIST's implementation guidance.
Operational validation confirms that the PQ implementation works correctly in production. This includes interoperability testing (does the PQ-enabled server successfully handshake with all client types?), performance validation (does PQ key exchange add unacceptable latency?), and monitoring (are PQ connections being logged and audited?).
The H33 Quantum Readiness Assessment tool evaluates all four dimensions and produces a structured readiness report that can be shared with carriers and underwriters. The assessment identifies specific gaps, quantifies the HNDL exposure, and provides a prioritized migration roadmap.
How HATS Attestations Are Already Post-Quantum Signed
Every attestation produced by the HATS system is signed using post-quantum digital signature algorithms. The system supports three PQ signature schemes, each with different performance and security characteristics:
ML-DSA-65 (FIPS 204, CRYSTALS-Dilithium): The primary signature algorithm for HATS attestations. ML-DSA-65 provides NIST Security Level 3, offering 128 bits of post-quantum security. Signature generation time: under 1 millisecond. Signature verification time: under 0.5 milliseconds. Signature size: 3,293 bytes. This is the NIST-standardized algorithm that will become the default for digital signatures across the federal government and, by extension, across regulated industries.
FALCON-512: An alternative lattice-based signature scheme selected by NIST for applications requiring smaller signatures. FALCON-512 produces 666-byte signatures — approximately 5x smaller than ML-DSA-65 — which is advantageous for bandwidth-constrained applications. HATS uses FALCON-512 as a secondary signature for environments where signature size is a constraint.
SLH-DSA (SPHINCS+): A hash-based signature scheme that provides a fundamentally different security foundation than lattice-based schemes. While ML-DSA and FALCON are both lattice-based (and therefore share a common mathematical foundation), SLH-DSA is based on hash functions — the most conservative and best-understood cryptographic primitive. HATS supports SLH-DSA as a defense-in-depth option for organizations that want signature security independent of lattice hardness assumptions.
The practical significance for insurance is this: every HATS attestation is cryptographically signed with an algorithm that cannot be broken by a quantum computer. The attestation that records your MFA coverage at 95% on April 28, 2026, will be verifiable and tamper-evident in 2030, in 2040, and in 2050. The signature cannot be forged by a future quantum computer. The evidence chain is quantum-proof.
This means that claims adjudication based on HATS attestations is not vulnerable to the signature forgery concern that will affect classical digital signatures. If an attestation is signed with RSA-2048 today, a quantum computer in 2035 could potentially forge a different attestation with the same signature — undermining the evidentiary value of the entire attestation chain. With ML-DSA-65, that forgery is computationally infeasible even with a quantum computer. The evidence holds.
What Insurers Should Ask About Cryptography Now
The cyber insurance application of 2027 should include a cryptographic architecture section. Here is what that section should cover, and why each question matters for risk assessment:
TLS configuration: Does the organization support TLS 1.3 with hybrid PQ key exchange (ML-KEM + ECDH)? This determines whether the organization's web traffic is protected against HNDL interception. Organizations using exclusively TLS 1.2 with RSA key exchange have full HNDL exposure for all web-facing data.
VPN configuration: Does the organization's VPN infrastructure support PQ key exchange? Remote access VPNs carry the most sensitive data — internal network traffic, database connections, application access. If the VPN uses RSA key exchange, all remote work traffic is subject to HNDL interception.
Email encryption: Does the organization use PQ-protected email encryption for sensitive communications? Email is a primary channel for sensitive business communications and frequently contains information subject to legal privilege, trade secret protection, or regulatory requirements. HNDL interception of email traffic could expose years of privileged communications.
Data-at-rest encryption: Does the organization's data-at-rest encryption use quantum-resistant key management? AES-256 is quantum-resistant for symmetric encryption, but the key exchange and key management operations that protect the AES keys may not be. If AES keys are distributed using RSA-encrypted channels, the keys are vulnerable to HNDL capture.
Digital signatures: Does the organization use PQ digital signatures for code signing, document signing, and API authentication? Classical signatures (RSA, ECDSA) can be forged by a quantum computer. Code signed with RSA today could be replaced with malicious code signed with a forged RSA signature in the future. PQ signatures prevent this attack.
The Migration Path
Post-quantum migration does not require replacing the entire cryptographic infrastructure overnight. The recommended approach is hybrid deployment: running classical and post-quantum algorithms simultaneously during a transition period. This provides backward compatibility with systems that do not yet support PQ algorithms while adding PQ protection for forward secrecy.
For TLS, hybrid deployment means configuring servers to support both ECDH and ML-KEM key exchange. Clients that support ML-KEM negotiate a PQ-protected session. Clients that do not fall back to ECDH. The transition is transparent to users. The implementation requires a server-side software update — not a hardware change. Major web servers (nginx, Apache, Caddy) and cloud providers (AWS, Azure, Cloudflare) already support hybrid PQ TLS.
For digital signatures, hybrid deployment means dual-signing with both classical and PQ algorithms. A document signed with both ECDSA and ML-DSA can be verified using either algorithm. Systems that support ML-DSA use the PQ signature. Systems that do not use the classical signature. Over time, as all systems are updated, the classical signature becomes unnecessary.
The cost of post-quantum migration is a fraction of the HNDL exposure it eliminates. H33's PQ-ready API handles the complexity — ML-KEM key exchange, ML-DSA signatures, hybrid negotiation — through a single integration. Organizations do not need to implement post-quantum algorithms from scratch. They need an API call.
The Insurance Timeline
Based on the trajectory of MFA mandates (2022–2024), the PQ cryptography mandate in cyber insurance will likely follow this timeline:
2026–2027: Leading carriers add PQ-related questions to applications. Organizations with PQ deployment receive minor premium credits. Awareness building. Early adopters benefit from preferred pricing.
2027–2028: CNSA 2.0 compliance becomes a significant underwriting factor. Carriers offer measurable premium reductions (10–20%) for organizations with deployed PQ cryptography. Organizations without PQ plans face surcharges or coverage restrictions for long-tail data exposure categories.
2029–2030: PQ cryptography becomes a condition of coverage for new policies and renewals, similar to the MFA mandate. Organizations that have not migrated face coverage gaps. The market reprices around PQ as the baseline. CNSA 2.0 deprecation dates arrive, establishing clear negligence standards for organizations still using classical-only cryptography.
The organizations that start migration now will have a four-year head start. They will have operational PQ deployments, tested and validated, when their competitors are scrambling to implement before coverage deadlines. The insurance benefit is clear: continuous coverage, preferred pricing, and eliminated HNDL exposure. The business benefit extends beyond insurance: compliance with government mandates, protection of customer trust, and competitive differentiation in security-conscious markets.
The Bottom Line
Post-quantum cryptography is not a future consideration. It is a present requirement. CNSA 2.0 has set the deprecation timeline. NIST has standardized the algorithms. CISA has determined that PQ products are widely available. Harvest-now-decrypt-later is happening now. Insurers are beginning to ask about cryptographic architecture. The organizations that can demonstrate PQ readiness — with HATS attestations signed using ML-DSA-65, FALCON-512, and SLH-DSA — will maintain coverage, receive preferred pricing, and eliminate the long-tail HNDL exposure that is the single largest unpriced risk in the current cyber insurance market.
Assess your readiness: Quantum Readiness Assessment | PQC Architecture | HNDL Protection | Get Started