How to Become NIST PQ-Compliant Without Rebuilding Your Infrastructure

The most common objection to post-quantum migration is complexity. Organizations hear "replace your cryptography" and they hear "rebuild everything." They imagine ripping out TLS stacks, replacing hardware security modules, re-keying every database, rewriting every application that touches encryption. They estimate the cost at millions of dollars and years of engineering effort. And so they do nothing.

This objection is based on a false premise. Post-quantum compliance does not require replacing your existing cryptographic infrastructure. It requires adding a post-quantum layer on top of it. The distinction between replacement and overlay is the difference between a multi-year infrastructure project and a days-to-weeks integration effort.

The Overlay Model for Post-Quantum Compliance

An overlay approach adds post-quantum cryptographic protection to existing data flows without modifying the underlying transport, storage, or processing infrastructure. Your TLS connections continue to use their current cipher suites. Your databases continue to use their current encryption-at-rest mechanisms. Your applications continue to use their current authentication protocols. The overlay adds an independent, post-quantum attestation layer that provides quantum resistance for the data passing through these existing systems.

This works because the threat model that post-quantum cryptography addresses is specific. The primary threat is harvest-now-decrypt-later: an adversary intercepts encrypted traffic today and stores it for future decryption when quantum computers become available. The overlay model addresses this threat by adding a post-quantum attestation to every piece of data that passes through the system. Even if the underlying TLS session is eventually broken by a quantum computer, the post-quantum attestation proves the integrity and provenance of the data at the time it was created.

The overlay does not replace your existing security. It augments it. Your current encryption still provides protection against classical attackers. The overlay adds protection against quantum attackers. During the transition period, you have defense in depth: classical encryption for current threats and post-quantum attestation for future threats.

What NIST Actually Requires

Before discussing implementation, it is worth understanding exactly what NIST's post-quantum standards require. The requirements are more specific and more achievable than most organizations realize.

FIPS 203 (ML-KEM) standardizes a key encapsulation mechanism based on the Module Learning With Errors (MLWE) problem. Key encapsulation is the process of establishing a shared secret between two parties. ML-KEM replaces the key exchange component of protocols like TLS, where RSA or ECDH currently establishes the session key. FIPS 203 defines three parameter sets: ML-KEM-512 (NIST Level 1), ML-KEM-768 (Level 3), and ML-KEM-1024 (Level 5).

FIPS 204 (ML-DSA) standardizes a digital signature scheme based on the same MLWE problem family. Digital signatures authenticate messages, documents, and software. ML-DSA replaces RSA and ECDSA signatures. FIPS 204 defines three parameter sets: ML-DSA-44 (Level 2), ML-DSA-65 (Level 3), and ML-DSA-87 (Level 5).

FIPS 205 (SLH-DSA) standardizes a stateless hash-based signature scheme. Unlike ML-DSA and ML-KEM, which rely on lattice problems, SLH-DSA relies only on the security of hash functions. This provides a fundamentally different hardness assumption, which is valuable for defense in depth. SLH-DSA signatures are larger and slower than ML-DSA, but they provide a hedge against potential future advances in lattice cryptanalysis.

The critical insight is that NIST does not mandate a specific integration pattern. NIST specifies the algorithms. How you deploy those algorithms in your infrastructure is an engineering decision, not a standards requirement. An overlay that uses FIPS 204 ML-DSA signatures to attest data integrity satisfies the standards just as fully as a native TLS integration that replaces the handshake cipher suite.

The H33-74 Overlay Architecture

H33-74 implements the overlay model as a 74-byte attestation primitive. Every attestation is signed with three independent post-quantum signature families: ML-DSA (FIPS 204, lattice-based), FALCON (NTRU lattice-based), and SLH-DSA (FIPS 205, hash-based). The full attestation bundle is approximately 55,000 bytes. The distillation process reduces this to 74 bytes: 32 bytes stored on-chain or in any persistent storage, and 42 bytes stored in the Cachee infrastructure layer.

The three-family approach provides a critical security property that single-algorithm compliance cannot match. Breaks only if MLWE lattices, NTRU lattices, AND stateless hash functions are simultaneously broken. These are three independent mathematical bets. An advance in lattice cryptanalysis might compromise ML-DSA and require a transition to SLH-DSA, but the existing attestations signed with all three families remain valid as long as any one of the three assumptions holds.

Integration Pattern: API Attestation

The simplest integration pattern is API-level attestation. For every API response that contains sensitive data, the server makes a single API call to the H33 attestation endpoint. The response includes a 74-byte attestation that the client can independently verify. The server's existing TLS connection continues to provide transport security. The attestation adds post-quantum proof of integrity and provenance.

Implementation requires adding one API call to the response pipeline. The call takes the response payload as input and returns the 74-byte attestation. The attestation is included in a response header or in the response body. Total implementation effort is typically measured in hours, not weeks.

Integration Pattern: Document Attestation

For document-centric workflows, every document is attested at the point of creation or modification. The 74-byte attestation is embedded in the document metadata, in a sidecar file, or in a document management system record. When the document is retrieved, the attestation is verified, confirming that the document has not been modified since it was attested and that the attestation was created using post-quantum signatures.

This pattern is particularly valuable for legal documents, healthcare records, financial statements, and any document with long-term evidentiary requirements. The ArchiveSign product implements this pattern specifically for documents that must maintain verifiable integrity for decades.

Integration Pattern: Event Attestation

For event-driven architectures, every event is attested as it flows through the system. Authentication events, transaction events, configuration changes, access control decisions -- each receives a 74-byte attestation that can be stored in the event log alongside the event itself. The attestation creates a post-quantum audit trail that cannot be retroactively forged, even by an adversary with a quantum computer.

This pattern addresses one of the most significant gaps in current compliance architectures: the audit trail. Most audit trails today are protected by classical signatures or by database access controls. Both are vulnerable to quantum attack. A post-quantum attested audit trail provides evidence that will remain verifiable regardless of advances in quantum computing.

Step-by-Step: From Zero to PQ-Compliant

Step 1: Identify Sensitive Data Flows

Begin with a data flow inventory focused on sensitivity horizon. Which data must remain confidential or verifiable for more than ten years? Healthcare records, legal communications, financial data, intellectual property, biometric data, and authentication credentials all qualify. Rank these flows by sensitivity and volume.

Step 2: Choose Integration Points

For each sensitive data flow, identify the point at which attestation is most effective. For API-driven systems, this is typically the response pipeline. For document management systems, this is the point of document creation or ingestion. For event-driven systems, this is the event publisher. The goal is to attest data at the earliest point in its lifecycle.

Step 3: Implement Attestation

Integrate the H33 attestation API at each chosen integration point. The API accepts a payload (the data to be attested) and returns the 74-byte attestation. Store the attestation alongside the data. This step typically requires writing a thin client library or middleware component that calls the attestation API.

Step 4: Implement Verification

Add verification at the points where attested data is consumed. When a client receives an API response with an attestation, it calls the H33 verification endpoint to confirm the attestation is valid. When a document is opened, the application checks its attestation. When an audit trail entry is reviewed, the attestation is verified. Verification is a single API call that returns a pass/fail result.

Step 5: Document Compliance

Create compliance documentation that maps your H33-74 attestation implementation to the specific NIST FIPS requirements. Document which algorithms are used (ML-DSA per FIPS 204, SLH-DSA per FIPS 205), which data flows are protected, and how verification is performed. This documentation serves as evidence for auditors, regulators, and cyber insurance underwriters that your organization has implemented post-quantum cryptographic controls.

Step 6: Plan the Broader Migration

With the overlay providing immediate post-quantum protection for your most sensitive data, you can plan the broader migration (replacing TLS cipher suites, updating HSMs, re-keying databases) at a sustainable pace. The overlay buys you time without buying you risk. Your most sensitive data is protected now, and you can migrate the underlying infrastructure as the ecosystem matures and as post-quantum TLS becomes standard.

Compliance Mapping: FIPS to Implementation

Auditors and compliance officers need to see a clear mapping between the NIST standards and the implementation. Here is how the H33-74 overlay maps to the specific FIPS requirements.

FIPS 204 (ML-DSA) Compliance: Every H33-74 attestation includes an ML-DSA-65 signature. The signature is generated using a NIST-compliant implementation of the CRYSTALS-Dilithium algorithm as standardized in FIPS 204. The key generation, signing, and verification operations follow the standard exactly. The ML-DSA signature is one of three signatures in each attestation; it can be independently verified against the ML-DSA public key.

FIPS 205 (SLH-DSA) Compliance: Every H33-74 attestation includes an SLH-DSA-SHA2-128f signature. This provides a hash-based signature that is independent of the lattice assumption underlying ML-DSA. The SLH-DSA signature provides NIST Level 1 security based solely on the security of SHA-256, a thoroughly analyzed and widely trusted hash function.

Three-Family Security Guarantee: Beyond the individual FIPS compliance of each signature, the combination of ML-DSA (MLWE lattice), FALCON (NTRU lattice), and SLH-DSA (hash-based) provides security against any single-family cryptanalytic breakthrough. This exceeds what any single FIPS standard requires, providing a safety margin that auditors and risk managers can document as defense in depth.

What About Key Exchange?

A fair objection to the overlay approach is that it addresses signature-based integrity but does not directly address key exchange. TLS sessions that use RSA or ECDH key exchange remain vulnerable to harvest-now-decrypt-later even with H33-74 attestation. The attestation proves that the data was genuine at the time of creation, but it does not prevent the data from being decrypted if the key exchange is broken.

This is a legitimate concern, and the answer has two parts.

First, for data confidentiality, the overlay approach should be combined with hybrid key exchange that includes ML-KEM (FIPS 203) alongside the classical key exchange. Most modern TLS libraries now support hybrid ML-KEM key exchange. Enabling it is a configuration change, not a code change. The combination of hybrid key exchange (for confidentiality) and H33-74 attestation (for integrity and provenance) provides comprehensive post-quantum protection.

Second, for data integrity and provenance, the attestation alone provides post-quantum protection. Even if an adversary can decrypt the traffic, they cannot forge the attestation. They can read the data, but they cannot modify it, reorder it, or deny that it existed. For many compliance use cases, attestation-based integrity is the primary requirement, and confidentiality is addressed by separate controls.

Cost and Timeline Comparison

The difference in cost and timeline between the overlay approach and a full infrastructure rebuild is dramatic.

A full post-quantum migration, replacing TLS stacks, HSMs, database encryption, application-level cryptography, and key management systems, typically takes two to five years and costs millions of dollars for an enterprise-scale organization. The project requires cryptographic engineering expertise, extensive testing, and careful coordination across dozens of systems and teams.

An overlay implementation with H33-74 typically reaches production for the highest-priority data flows within one to four weeks. The cost is the API usage fees plus the engineering time for integration, which is measured in person-days rather than person-years. The overlay provides immediate compliance documentation for auditors and regulators while the broader migration proceeds at its own pace.

The overlay is not a substitute for eventual full migration. It is a bridge that provides immediate protection and compliance while the full migration is planned and executed. The bridge eliminates the false choice between "do everything at once" and "do nothing until we are ready."

Addressing Auditor Questions

Auditors evaluating post-quantum compliance will ask specific questions. Here are the answers the overlay approach provides.

"Which NIST post-quantum algorithms have you implemented?" ML-DSA-65 (FIPS 204), SLH-DSA-SHA2-128f (FIPS 205), and FALCON-512. Three independent algorithms, three independent hardness assumptions.

"Where are post-quantum controls applied?" At every identified sensitive data flow, via API-level, document-level, or event-level attestation. The inventory of covered data flows is documented and maintained.

"How do you verify post-quantum integrity?" Every attestation can be independently verified by calling the H33 verification endpoint. The verification checks all three signatures, validates the hash commitment, and returns a cryptographic proof of validity.

"What is your migration timeline for full post-quantum integration?" The overlay provides immediate post-quantum protection. The broader migration to post-quantum TLS, HSMs, and native database encryption is planned according to the organization's infrastructure lifecycle. The overlay ensures that no sensitive data flows lack post-quantum protection during the transition.

"How do you handle key management for post-quantum keys?" H33 manages the post-quantum key lifecycle, including generation, rotation, and revocation. The organization does not need to deploy separate HSMs or key management infrastructure for the overlay. When the organization migrates to native post-quantum key management, the transition is seamless because the attestation format does not change.

The Compliance Timeline Is Now

NIST finalized FIPS 203, 204, and 205 in August 2024. CNSA 2.0 requires software signing and web services to use post-quantum algorithms by 2025. The federal deadline for National Security Systems is already past for some categories. Financial regulators are incorporating quantum risk into examination guidance. Cyber insurers are asking about post-quantum migration plans on renewal applications.

The overlay approach makes it possible to respond to all of these pressures immediately, without the multi-year timeline of a full infrastructure rebuild. The first organization in any industry to achieve post-quantum compliance gains a competitive advantage. The last organization to achieve it faces enforcement risk.

The path from zero to PQ-compliant is measured in days, not years. The tools exist. The standards are final. The only remaining question is when you choose to start.