NIST PQC Compliance: Audit Trails Banks Need by 2030

In January 2023, the Office of Management and Budget issued Memorandum M-23-02: "Migrating to Post-Quantum Cryptography." The memo directed all federal agencies to inventory their cryptographic systems, identify systems vulnerable to quantum computing, and prepare migration plans to NIST-standardized post-quantum algorithms. The deadline for completed migration: 2030. Not "begin planning by 2030." Completed migration by 2030.

In September 2022, the National Security Agency published CNSA 2.0 (Commercial National Security Algorithm Suite 2.0), establishing the cryptographic algorithm requirements for National Security Systems. The timeline is explicit: software and firmware signing must use post-quantum algorithms by 2025. All other uses, including symmetric key establishment and authentication, must transition by 2030. For systems protecting classified data with a long secrecy lifetime, CNSA 2.0 recommends immediate transition because data encrypted today with classical algorithms can be captured and decrypted once quantum computers arrive.

These are not suggestions. They are federal mandates with specific deadlines. And while they apply directly to federal agencies and national security systems, their implications cascade through the entire financial system. Every bank that holds federal deposits, services federal customers, interacts with federal payment systems, or operates under federal regulatory oversight is connected to systems that must comply by 2030. When your counterparties migrate to post-quantum cryptography, you must be interoperable. When your regulators expect post-quantum audit trails, you must produce them. The 2030 deadline is not just a federal problem. It is a banking problem.

The compliance timeline

Understanding the urgency requires understanding how the timeline works for audit trails specifically. Banks have regulatory requirements to retain records for fixed periods — seven years for most transaction records under the Bank Secrecy Act, ten years for some categories, permanently for certain corporate records. A record created today and signed with RSA-2048 has a seven-year retention requirement, meaning it must remain verifiable until 2033. A record created in 2027 must remain verifiable until 2034. Every day of delay creates another day of records that enter the vulnerability window — records signed with classical cryptography that may be exposed to quantum forgery before their retention period expires.

The timeline math is unforgiving. If cryptographically relevant quantum computers arrive by 2033 (within the range of informed estimates), then every record signed with classical cryptography before 2026 is already past the point of protection — those records' retention periods extend into the quantum era, and they cannot be retroactively re-signed with post-quantum algorithms because the original signing context (keys, authorization state, temporal proof) no longer exists in the required form. Records being created right now are on the boundary. Records created from 2027 onward are clearly within the vulnerability window unless signed with post-quantum algorithms from the start.

This is why "begin planning" is insufficient. Planning does not protect records being created today. Only implementation protects records being created today. Every month spent in planning, procurement, vendor evaluation, and pilot programs is another month of records entering the vulnerability window with no quantum resistance.

OMB M-23-02: what it actually requires

The memo's requirements are structured in phases. Phase 1 required agencies to submit a cryptographic systems inventory — identifying all systems using public-key cryptography, their algorithm types, key sizes, and the data sensitivity they protect. Phase 2 requires prioritization: which systems protect the most sensitive data, which have the longest data lifetimes, which interact with the most external systems. Phase 3 requires migration plans with timelines, resource requirements, and testing procedures. Phase 4 is execution: actual deployment of post-quantum algorithms in production systems by the 2030 deadline.

For banks, the relevant implication is interoperability. Federal payment systems — Fedwire, FedACH, the Fed's forthcoming FedNow enhancements — will migrate to post-quantum cryptography. Banks that interact with these systems must be able to produce and verify post-quantum signatures. Federal customers (agencies, contractors, military personnel) will expect their banking relationships to support post-quantum security. Federal examiners will expect to verify audit trails signed with NIST-standardized post-quantum algorithms.

The memo explicitly calls out the harvest-now-decrypt-later threat: data and signatures captured today can be stored and attacked once quantum computers arrive. This is not a future threat. It is a present-tense threat to the future integrity of current records. The memo's position is clear: organizations that hold data or produce signatures with long-term value must begin post-quantum migration immediately, not at the 2030 deadline.

CNSA 2.0: the NSA's algorithm requirements

CNSA 2.0 specifies exact algorithms and parameter sets. For digital signatures, the approved algorithms are ML-DSA (FIPS 204) at security levels 2, 3, or 5, and XMSS/LMS hash-based signatures. For key establishment, ML-KEM (FIPS 203) at security levels 3 or 5. The suite explicitly retires RSA, ECDSA, and ECDH for national security use, with a hard deadline for complete transition.

While CNSA 2.0 applies to National Security Systems, its algorithm choices set the benchmark for the broader federal ecosystem. NIST's own post-quantum standards (FIPS 203, 204, 205) are the same algorithms in the same parameter sets. When a bank's examiner asks "are your audit trail signatures compliant with current NIST standards?" the answer they expect references FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), not RSA-2048 or ECDSA-P256.

H33 implements all three NIST-standardized post-quantum signature families: ML-DSA-65 (FIPS 204), SLH-DSA-SHA2-128f (FIPS 205), and FALCON-512 (FIPS 206). This exceeds CNSA 2.0's minimum requirements (which specify ML-DSA alone) by adding two additional signature families for assumption diversity. The construction is forward-compatible: if CNSA 3.0 requires multi-family signatures (which is the logical progression from the current single-family minimum), H33-74 already implements it.

The seven-year liability window

Here is the concrete liability exposure for a bank that has not yet deployed post-quantum audit trail signatures:

Records created in 2020 with RSA-2048 signatures have a retention requirement through 2027. If quantum computers arrive after 2027, these records are safe — their retention period has expired. Records created in 2024 have a retention requirement through 2031. If quantum computers arrive before 2031, these records are vulnerable — their signatures can be forged, and the bank cannot prove the integrity of four years' worth of compliance decisions, transaction authorizations, and audit events.

Records created today — April 2026 — have a retention requirement through April 2033. The most informed estimates from the intelligence community and academic research suggest cryptographically relevant quantum computers (capable of running Shor's algorithm at sufficient scale to break RSA-2048) by the early 2030s. This puts records created today squarely in the vulnerability window. Not probably. Not definitely. But plausibly — and "plausibly" is sufficient to create regulatory and litigation risk.

Every day of delay extends this liability. Tomorrow's records have a retention requirement through April 2033 plus one day. Next month's records through May 2033. Next year's records through April 2034. The vulnerability window grows monotonically with every day that passes without post-quantum protection. There is no catch-up mechanism — you cannot retroactively sign historical records with post-quantum algorithms because the original signing keys, authorization contexts, and temporal proofs no longer exist.

This is why the compliance question is not "do we need to migrate by 2030?" It is "every day we wait, how many more records enter the unprotectable vulnerability window?" For a bank processing one million transactions per day, that is one million new liability records per day of delay.

The drop-in migration path

The traditional approach to cryptographic migration is a multi-year infrastructure project. Inventory all systems using classical cryptography. Select replacement algorithms. Modify every system's cryptographic layer. Test for interoperability. Deploy in stages. Manage the transition period where both classical and post-quantum systems coexist. This is the approach described in NIST SP 1800-38 (Migration to Post-Quantum Cryptography) and it is realistically a 3-5 year effort for a large institution.

For audit trail signatures specifically, there is a faster path. The audit trail does not need to replace its existing infrastructure. It needs to add a parallel attestation layer that provides post-quantum signatures alongside whatever classical signatures or integrity mechanisms already exist. The existing logging system continues to operate unchanged. A new attestation layer produces 74-byte H33-74 substrates for each audit event and stores them alongside the existing records. The existing records remain available for current verification workflows. The substrates provide post-quantum verification for future workflows.

This is not a rip-and-replace. It is an additive deployment. The integration point is a single API call after each audit event is produced. The API returns 74 bytes. Those 74 bytes are stored. The existing system is not modified, not replaced, not disrupted. The migration from "no post-quantum audit trail" to "post-quantum audit trail operating in parallel" takes days to weeks, not years.

H33's attestation API accepts canonical audit data and returns a 74-byte substrate signed with three NIST-standardized post-quantum signature families (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f). The API completes in under 26 milliseconds. For on-premises deployments, the runtime installs on the bank's own hardware with no external dependency. For cloud deployments, the API endpoint is available immediately with no infrastructure provisioning.

What examiners will expect

Regulatory examinations follow trends with a predictable lag. New technology arrives. Early adopters deploy it. Guidance documents reference it. Examination procedures incorporate it. Findings cite its absence. For post-quantum cryptography, the timeline is compressed because the guidance documents already exist (M-23-02, CNSA 2.0, NIST SP 800-131A Revision 2) and the examination procedures are catching up.

Based on current regulatory trajectory, here is what bank examiners will likely ask, and when:

2026-2027: "Has your institution completed a cryptographic inventory? Have you identified systems that rely on algorithms vulnerable to quantum computing? Do you have a migration plan?" This is Phase 1-2 of M-23-02 compliance. Banks that have not started this process will receive findings.

2028-2029: "What is your migration timeline? Have you begun deploying post-quantum algorithms in pilot systems? Can you demonstrate interoperability with federal payment systems that have already migrated?" This is Phase 3. Banks without a concrete deployment plan will receive stronger findings.

2030+: "Are your audit trail signatures NIST-compliant post-quantum? Can you independently verify the integrity of records from 2026-2029 against quantum forgery?" This is Phase 4. Banks that did not deploy post-quantum signatures before 2030 will not be able to verify pre-2030 records against quantum adversaries — because those records were never signed with post-quantum algorithms, and cannot be retroactively signed.

The competitive advantage of early deployment is clear: banks that deploy post-quantum attestation in 2026 can demonstrate compliance at every examination stage. Their 2026 records are verifiable against quantum adversaries. Their 2027 records are verifiable. Their 2028 records are verifiable. By the time examiners demand post-quantum audit trails, early adopters have four years of protected records. Late adopters have zero years of protected records and a gap that cannot be closed retroactively.

Sector-specific regulatory guidance

Beyond the general federal mandates, banking-specific regulators have issued or are developing guidance that references the quantum computing threat:

OCC: The Comptroller's Handbook on Information Technology requires banks to manage cryptographic risk as part of their overall information security program. The handbook's examination procedures include assessing whether cryptographic controls are "appropriate to the risk" — and as quantum computing risk increases, "appropriate" will mean post-quantum.

Federal Reserve: SR 05-23 requires information security programs to address emerging threats. The Fed's supervision technology group has been briefed on post-quantum cryptography requirements and is developing examination procedures that reference NIST PQC standards.

FDIC: The Federal Deposit Insurance Corporation's IT examination procedures reference NIST standards for cryptographic controls. As NIST deprecates classical algorithms (which SP 800-131A already does for short-key RSA), FDIC examiners will expect compliance with current standards.

FFIEC: The Federal Financial Institutions Examination Council's Information Security booklet addresses cryptographic risk management and references the need to plan for "cryptographic transitions" — language that was added specifically to address the quantum computing threat.

None of these regulators have issued a hard mandate for post-quantum deployment in banks (that comes through the M-23-02/CNSA 2.0 cascade). But all of them have established the framework for expecting it, and all of them will incorporate it into examination procedures as the 2030 deadline approaches. Banks that get ahead of this curve face easier examinations. Banks that fall behind face findings, corrective actions, and the operational burden of an accelerated migration under regulatory pressure.

The cost comparison

The cost of deploying H33-74 post-quantum attestation for a bank's audit trail is straightforward to estimate. The API-based deployment requires no infrastructure procurement, no hardware deployment, no cryptographic library integration, and no system architecture changes. The integration work is a single API call per audit event — typically a one-to-two-week engineering effort to add the call to existing logging pipelines and store the 74-byte responses.

The cost of not deploying — the cost of leaving audit trail signatures in classical-only form — is harder to quantify but potentially enormous. Regulatory findings create remediation costs. Enforcement actions create legal costs and reputation damage. Litigation where audit trail integrity is challenged — and the bank cannot prove its records are untampered because the classical signatures are now forgeable — creates liability exposure proportional to the value of the contested transactions.

The asymmetry is extreme. The cost of protection is an API call and 74 bytes of storage per record. The cost of exposure is unlimited — it is whatever liability attaches to the records that become unprovable once quantum computers break their classical signatures. For a bank holding billions in assets and processing millions of transactions daily, that exposure dwarfs any implementation cost by orders of magnitude.

Implementation today, not 2030

The 2030 deadline is a maximum, not a target. The M-23-02 memo explicitly states that systems with long-lived data should migrate immediately because of the harvest-now-decrypt-later threat. Audit trails are, by definition, long-lived data — they exist specifically to be verified years after creation. Every audit trail record is "long-lived data" in the memo's framework. The memo's logic therefore implies that audit trail signatures should be among the first systems to migrate, not the last.

H33 provides the implementation path. Three NIST-standardized post-quantum signature families. 74-byte persistent footprint. Single API call integration. 2,216,488 attestations per second sustained throughput. Under 26 milliseconds per attestation. On-premises deployment available for institutions that require it. No infrastructure rebuild. No multi-year migration project. No waiting for 2030.

The compliance roadmap is clear. The standards are finalized. The deadline is set. The implementation exists and runs at production scale today. Every day between now and deployment is another day of records entering the vulnerability window. For banks that take their compliance obligations seriously — and their regulators will ensure that all of them eventually do — the migration starts now.

Contact support@h33.ai for enterprise deployment consultation and on-premises licensing.