CNSA 2.0 Beyond NSS: Why Financial Services Is Adopting It Anyway

Introduction

Let me be direct about what this article is not: a claim that financial institutions are legally required to comply with CNSA 2.0. They are not. No U.S. financial regulator has issued a binding post-quantum cryptography mandate for private-sector entities as of mid-2026, and no European financial supervisory authority has published a PQC compliance deadline with enforcement teeth. The Basel Committee, the G7 Cyber Expert Group, FINRA, the OCC, and DORA’s implementing standards have all addressed quantum risk in various ways. None has produced the kind of hard procurement gate that CNSA 2.0 creates for National Security Systems.

What is happening, and why it matters, is more subtle. CNSA 2.0’s algorithm choices, specifically ML-KEM-1024 and ML-DSA-87, the highest NIST parameter levels, are becoming the reference standard for high-assurance cryptography in contexts far beyond classified government networks. I am seeing CNSA 2.0 referenced in bank procurement documents, in insurance underwriting questionnaires about cyber resilience, in counterparty risk assessments between financial institutions, and in board-level discussions about quantum readiness. The standard is migrating from a government mandate into a commercial benchmark, driven not by regulation but by the practical need for a concrete, credible answer to the question “what does quantum-ready actually mean?”

This article examines why that migration is happening, what financial institutions should take from CNSA 2.0 (and what they should not), and how the financial sector’s quantum readiness picture is evolving.

Where the Pressure Actually Comes From

Financial institutions are not facing a PQC mandate. They are facing a convergence of pressures that makes PQC migration increasingly difficult to defer. Understanding which pressures are binding and which are advisory is essential for calibrating the response.

The G7 Cyber Expert Group

On January 13, 2026, the G7 Cyber Expert Group released a financial sector PQC roadmap, co-chaired by the U.S. Treasury and the Bank of England. The roadmap targets critical financial systems for migration by 2030-2032 and full transition by 2035. This is guidance, not regulation. But the G7 Cyber Expert Group carries significant influence over national financial supervisors, and its recommendations tend to propagate into supervisory expectations within one to two budget cycles.

For a CISO at a large bank, the G7 roadmap changes the conversation from “should we be thinking about PQC?” to “our supervisors’ supervisors have set a timeline; when is our board going to ask about our plan?”

DORA and NIS2

In Europe, the Digital Operational Resilience Act (DORA) entered full application in January 2025. DORA’s ICT risk management Regulatory Technical Standards explicitly expect financial entities to monitor cryptographic threats “including threats from quantum advancements” and to update cryptographic technology accordingly. This is not a PQC mandate. It is a supervisory expectation that PQC risk is on the risk register and that the institution has a position on it.

As I analyzed in my coverage of the NIS2/DORA/PQC intersection, the proposed NIS2 amendment published in January 2026 would add an explicit PQC transition requirement to the directive text for the first time. When that amendment is adopted (and the political direction is clear even if the legislative timeline is uncertain), financial institutions subject to NIS2 will have a regulatory obligation to align with the EU’s coordinated PQC roadmap, which targets critical infrastructure PQC transition by end of 2030.

The HNDL Risk for Financial Data

The Harvest Now, Decrypt Later threat is particularly acute for financial services because of the long confidentiality horizons involved. Regulatory retention requirements for financial records run 7 to 10 years. Litigation holds can extend 30 years or more. Trade secrets, M&A communications, and strategic intelligence may be sensitive indefinitely.

Data intercepted and stored today by a state-level adversary could be decrypted once a cryptanalytically relevant quantum computer becomes operational. The question for financial institutions is whether data encrypted in 2026 needs to remain confidential in 2036 or 2046. For most major financial institutions, the answer is obviously yes for at least some categories of data. The CEPS Task Force, in its December 2025 assessment, warned explicitly that capable quantum computers pose systemic risk to financial systems and urged institutions to start inventorying cryptographic assets now.

The HNDL threat does not wait for a regulatory mandate. It operates on the timeline of quantum computing progress, not the timeline of financial regulation. An institution that defers PQC migration until a binding mandate arrives may discover that the data it needed to protect was already harvested before the mandate existed.

Counterparty and Supply Chain Pressure

The most immediate practical pressure on many financial institutions comes not from regulators but from counterparties, clients, and vendors. Large banks are beginning to include post-quantum readiness questions in vendor risk assessments. Insurance underwriters are adding quantum-related questions to cyber policy renewals. Asset managers conducting due diligence on custodians are asking about PQC roadmaps.

This pressure is informal, fragmented, and inconsistent. But it is growing, and CNSA 2.0 provides a convenient reference point. When a procurement team writes “cryptographic implementations should align with CNSA 2.0 algorithm recommendations” into an RFP, they are not claiming that CNSA 2.0 legally applies to the procurement. They are using CNSA 2.0 as a shorthand for “use the strongest available post-quantum algorithms at the highest parameter levels, as validated by the organization with the most at stake.”

SEC and Investor Disclosure

In the U.S., the SEC has begun signaling PQC expectations in specific contexts. Proposed regulatory frameworks for digital asset custody reference NIST PQC algorithms and CNSA 2.0 compatibility as security considerations. More broadly, several recent S-1 registration statements from companies pursuing IPOs now explicitly disclose their use of hybrid encryption schemes combining PQC algorithms with classical cryptography.

This is a subtle but significant development. When quantum readiness begins appearing in public company disclosures, it shifts from a technical operations concern to a material risk disclosure question. A financial institution that has no PQC roadmap may eventually face the question of whether that absence should have been disclosed as a risk factor.

What Financial Services Should Take from CNSA 2.0

CNSA 2.0 was designed for National Security Systems, and some of its choices reflect that specific context. Financial institutions adopting CNSA 2.0 as a benchmark should understand which elements translate directly and which require adaptation.

What Translates Directly

Algorithm selection. ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures are the strongest parameter levels of the most thoroughly vetted post-quantum algorithms available. Financial institutions that adopt these algorithm choices are building on the same technical foundation that NSA considers appropriate for protecting national secrets. There is no financial services use case that requires weaker algorithm choices than what CNSA 2.0 specifies.

Firmware and software signing priorities. CNSA 2.0’s emphasis on quantum-resistant firmware roots of trust translates directly to financial infrastructure. ATM firmware, payment terminal software, HSM firmware, and core banking system updates all rely on signature verification to ensure integrity. Building quantum-resistant signing into these update mechanisms early avoids the same retrofit problem that drives CNSA 2.0’s urgency in the defense context.

The timeline structure. While financial services does not have a January 2027 procurement gate, CNSA 2.0’s staggered timeline by system category offers a useful template. Web-facing services (online banking, customer portals) map to CNSA 2.0’s “web browsers/servers and cloud services” category. Internal network infrastructure maps to “traditional networking equipment.” Core banking platforms map to “operating systems.” The relative priority ordering: protect network traffic first (highest HNDL exposure), then web services, then operating systems, then legacy. That priority ordering is applicable to financial environments with minor adaptation.

What Requires Adaptation

Parameter level flexibility. CNSA 2.0 mandates Level 5 parameters exclusively (ML-KEM-1024, ML-DSA-87). For financial services, Level 3 parameters (ML-KEM-768, ML-DSA-65) may be acceptable for some applications, particularly those with constrained environments or high-throughput requirements. The UK’s NCSC, for example, considers Level 3 acceptable for most use cases. Financial institutions should evaluate whether the performance impact of Level 5 is justified for each application rather than adopting it uniformly.

Hybrid deployment. CNSA 2.0 targets pure PQC by the exclusive-use dates, treating hybrid as transitional. For financial services, the European position (BSI, ANSSI, ECCG) of maintaining hybrid deployments indefinitely may be more appropriate. Combining a classical algorithm with a post-quantum algorithm provides defense-in-depth: even if the PQC algorithm contains an undiscovered weakness, the classical algorithm provides a security floor. Given that financial institutions are not under pressure to eliminate classical algorithms by a specific date, the hybrid approach offers insurance at a manageable cost.

As I detail in the global PQC requirements comparison, the hybrid question is one of the sharpest divergences between national authorities. Financial institutions operating across jurisdictions should plan for hybrid as the default and treat pure PQC as a future option rather than a near-term target.

SLH-DSA inclusion. CNSA 2.0 excludes SLH-DSA. For financial services, there is no reason to follow this exclusion. SLH-DSA provides a non-lattice signature option that offers insurance against potential lattice weaknesses. Including SLH-DSA in a financial institution’s approved algorithm list adds resilience without conflicting with any applicable regulation. BSI, ANSSI, and the ECCG all recommend SLH-DSA; there is a strong European regulatory expectation that organizations will support it.

The Algorithm Is Not the Hard Part

For financial services, the choice of algorithm is relatively simple: ML-KEM-1024 (or ML-KEM-768 where Level 5 overhead is prohibitive), ML-DSA-87, and SLH-DSA as a backup, with AES-256 and SHA-384/512 for symmetric operations. The standards are published, reference implementations exist, and major cryptographic libraries already include support.

The hard part is everything around the algorithm: the cryptographic inventory, the certificate infrastructure, the HSM upgrade cycle, the vendor coordination, and the testing at scale.

Cryptographic inventory is the first bottleneck and the one most organizations underestimate. A large bank may have thousands of applications, each using cryptography in ways that are documented inconsistently or not at all: TLS termination points, API gateways, HSMs, key management systems, payment processing pipelines, SWIFT connections, inter-bank communication channels, code-signing infrastructure, customer-facing authentication systems. All of these use cryptographic algorithms that must be identified, catalogued, and assessed for quantum vulnerability. The PQC Migration Framework provides a structured methodology for this inventory that applies regardless of industry.

HSM readiness is the second bottleneck. Financial institutions rely heavily on hardware security modules for key management, transaction signing, and PIN processing. HSM firmware upgrades to support PQC algorithms are becoming available from major vendors, but the upgrade cycle in a financial institution is measured in months (for testing and validation) to years (for regulatory approval of modified cryptographic infrastructure). The earlier an institution begins HSM testing with PQC algorithms, the sooner it can validate that production workloads perform acceptably with larger key sizes and different computational characteristics.

PKI migration is the third and hardest challenge. Financial services PKI is enormous, heavily embedded, and highly regulated. Certificate authorities, registration authorities, online certificate status responders, certificate revocation lists, and cross-certification relationships all need to be evaluated for PQC compatibility. The hybrid certificate approaches I discuss in the 2027 procurement gate article — composite signatures, catalyst certificates, and cross-signing, are directly relevant to financial services PKI migration.

A Realistic Timeline for Financial Services

No binding deadline exists for financial services PQC migration today. That will change. The EU’s coordinated roadmap targets critical financial infrastructure for PQC transition by end of 2030. The G7 Cyber Expert Group targets critical systems by 2030-2032. DORA’s ICT risk management expectations will likely tighten as supervisors develop more specific guidance. National financial regulators will follow the pattern established by the OCC, FINRA, and the SEC: advisory guidance first, supervisory expectations next, binding requirements eventually.

A realistic timeline for a major financial institution:

2026: Complete cryptographic inventory across high-priority systems. Establish governance (executive sponsor, PQC program lead, cross-functional steering committee). Begin HSM vendor engagement and firmware testing. Pilot hybrid TLS on edge systems (load balancers, CDN endpoints). Evaluate hybrid certificate approaches.

2027-2028: Deploy hybrid PQC for external-facing TLS connections. Begin migrating internal VPN and inter-datacenter links. Start PKI hybrid certificate pilots for internal CA hierarchies. Integrate PQC algorithm requirements into vendor procurement.

2029-2030: Complete migration of high-risk and customer-facing systems to hybrid PQC. Begin addressing core banking systems, payment infrastructure, and SWIFT connections. Align with the EU 2030 critical infrastructure target and the G7 roadmap.

2031-2035: Complete migration of remaining systems. Address legacy applications and constrained environments. Evaluate transition from hybrid to pure PQC based on regulatory guidance and confidence in algorithm security.

This timeline is tight but achievable for institutions that start now. For institutions that defer to 2028 or later, the later milestones become structurally difficult to meet, particularly the PKI migration, which is the longest lead-time work item.

Why CNSA 2.0, Specifically

Readers may ask: why reference CNSA 2.0 rather than NIST’s standards directly? After all, NIST published the algorithms, and NIST’s guidance is broader and more flexible than CNSA 2.0’s narrow selections.

The answer is practical, not philosophical. CNSA 2.0 provides three things that NIST’s standards alone do not.

First, it makes specific choices. NIST standardized ML-KEM at three parameter levels and ML-DSA at three parameter levels. For a security team presenting a migration proposal to a board, “we will use the same algorithms and parameter levels that the NSA requires for classified systems” is a cleaner message than “we selected parameter level 768 based on our assessment of the performance-security tradeoff, which we believe is adequate for our risk profile.” The specificity of CNSA 2.0 provides an external authority for the algorithm choices, reducing the burden on the institution’s own cryptographic expertise.

Second, it sets a timeline precedent. The CNSA 2.0 timeline is the most aggressive published by any government authority. When a board asks “how urgent is this?”, pointing to a U.S. government program that requires compliance starting January 2027 is more persuasive than citing an EU roadmap that targets 2030 or a UK recommendation that targets 2035.

Third, it establishes a credibility floor. An institution that aligns with CNSA 2.0’s algorithm choices is, by definition, using algorithms at parameter levels that the most demanding cryptographic authority in the world considers adequate for national security. No auditor, insurer, counterparty, or regulator will question whether ML-KEM-1024 and ML-DSA-87 are strong enough. The institutional risk of being second-guessed on algorithm selection drops to zero.

These benefits do not mean financial institutions should adopt CNSA 2.0 wholesale. The SLH-DSA exclusion, the pure-PQC endpoint, and the Level-5-only constraint are NSA-specific policy choices that may not serve financial services well. But as a reference point for the core algorithm decisions (which algorithms, at what parameter levels, with what urgency, CNSA 2.0 is the strongest available anchor.

The Deadlines Are Coming

I return to a theme I have argued throughout PostQuantum.com: the deadlines are already set, and debating when a quantum computer will arrive is increasingly beside the point. For financial services, the relevant deadlines are not the CRQC timeline. They are the G7’s 2030-2032 target, the EU’s 2030 critical infrastructure milestone, the DORA supervisory expectations, the counterparty questions that arrive in next year’s vendor assessment, and the board member who reads about CNSA 2.0 and asks what the institution’s plan is.

None of these is a hard procurement gate like CNSA 2.0’s January 2027 deadline. All of them are soft deadlines that harden over time. The financial institutions that begin their cryptographic inventory and PQC pilot programs in 2026 will be positioned to meet them as they crystallize. Those that wait for a binding mandate will discover, as defense contractors are discovering now, that cryptographic migration timelines do not compress on demand.

For a comprehensive guide to the migration methodology, the PQC Migration Framework applies across industries. For the organizational readiness question (building the business case, governing the program, staffing the migration), Quantum Ready provides the strategic framework. And for financial institutions that want to understand the full US regulatory environment, my comprehensive analysis covers every relevant directive, memorandum, and supervisory signal.

The standard that started as an NSA mandate for classified systems is becoming the baseline expectation for any organization that takes cryptographic risk seriously. Financial services did not wait for CNSA 2.0 to become a legal obligation. It is adopting CNSA 2.0 because the alternative, having no concrete standard to anchor the migration, is worse.