Quantum-Safe Compliance: Post-Quantum Audit Evidence

Quantum-safe compliance is the practice of protecting compliance evidence — audit records, signed reports, logs, and ML-BOMs — with post-quantum cryptography so it remains verifiable for its entire retention period, even after quantum computers break today's RSA and elliptic-curve signatures. The core problem is a timing mismatch: regulators expect evidence to stay trustworthy for 7–10+ years, while the classical signature algorithms protecting that evidence are precisely the ones a cryptographically relevant quantum computer is expected to defeat. Quantum-safe compliance closes the gap by signing evidence with NIST-standardized post-quantum algorithms such as ML-DSA (CRYSTALS-Dilithium, FIPS 204), hashing it with SHA-3, and anchoring it in Merkle trees so any tampering is mathematically detectable.

This pillar guide explains the threat model (including harvest-now-decrypt-later), the August 2024 NIST post-quantum standards, how Dilithium signatures work at a practitioner level, why Merkle trees make audit trails tamper-evident at scale, and how to migrate with crypto-agility in mind.

Why does compliance evidence have a quantum problem?

Compliance evidence is unusual among digital assets in one specific way: its value depends on remaining provably intact for a long time. A gap assessment, an approval record, or a signed ML-BOM is not merely stored — it must be producible years later, with a credible answer to the question "how do we know this wasn't altered?" Retention obligations make the timescales concrete. Financial-controls regimes such as SOX require audit workpapers to be kept for roughly seven years. The EU AI Act, which entered into force in August 2024 with staged obligations, requires providers of high-risk AI systems to retain technical documentation for ten years after the system is placed on the market. ISO management-system certifications run on multi-year audit cycles, and litigation can reach back further still.

Now put that against the cryptography. Virtually all digital signatures in production today — RSA, ECDSA, Ed25519 — rest on two mathematical problems: integer factorization and the discrete logarithm. Shor's algorithm, running on a sufficiently large fault-tolerant quantum computer, solves both efficiently. When such a cryptographically relevant quantum computer (CRQC) exists, an attacker who obtains a public key can derive the corresponding private key and forge signatures at will. Every RSA and ECDSA signature — including ones created years earlier — stops being proof of anything, because a forger could have produced an identical signature after the fact.

That is the compliance-specific failure mode: not future data being stolen, but past evidence becoming repudiable. An audit trail signed with ECDSA does not degrade gracefully; on the day the algorithm falls, the entire historical record loses its integrity guarantee simultaneously, no matter how carefully it was stored.

What is harvest now, decrypt later?

Harvest now, decrypt later (HNDL) is the attack strategy that makes the quantum threat a present-tense problem. Adversaries — typically well-resourced state actors — record encrypted traffic and archives today, knowing they cannot decrypt them yet, and simply wait. When a CRQC arrives, everything harvested becomes readable retroactively. Data with a long confidentiality lifetime (health records, trade secrets, intelligence) is already being collected under this model.

For evidence integrity, the analog is "harvest now, forge later." An adversary does not even need to harvest anything: public keys and signed documents are widely available by design. Once classical signatures can be forged, backdating fraudulent "evidence," rewriting inconvenient audit history, or disowning genuine records all become feasible — and impossible to disprove cryptographically. A useful way to reason about urgency is Mosca's inequality: if X (how long your evidence must stay secure) plus Y (how long your migration takes) exceeds Z (time until a CRQC), you are already late. With ten-year retention windows and multi-year enterprise migrations, many organizations fail that test today even under optimistic estimates of Z.

What did NIST standardize in FIPS 203, 204, and 205?

After an eight-year open competition that began in 2016, NIST published its first three finalized post-quantum cryptography standards on 13 August 2024. Each covers a different job:

For signing compliance evidence, FIPS 204 / ML-DSA is the workhorse. NIST designated it the primary signature standard because it balances strong security with practical key sizes and fast signing and verification. SLH-DSA exists as a hedge: its security relies only on hash functions, an extremely well-understood assumption, at the cost of much larger signatures and slower signing. A further lattice signature, FN-DSA (Falcon), is planned as FIPS 206 but was not finalized in the August 2024 batch.

Standardization changed the compliance conversation. Before FIPS 204, "post-quantum" meant experimental parameter sets and shifting drafts; after it, ML-DSA is a stable, citable federal standard that auditors, tooling vendors, and regulators can reference. NIST has also published draft transition guidance signaling that classical public-key algorithms should be deprecated around 2030 and disallowed by 2035 — a timeline that overlaps the retention window of evidence being generated right now.

How do CRYSTALS-Dilithium (ML-DSA) signatures work?

Dilithium is a lattice-based signature scheme. Its security rests on two related problems over structured lattices — Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS) — which ask, roughly, whether you can recover a secret from noisy linear equations, or find unusually short vectors satisfying a linear relation. Decades of cryptanalysis, classical and quantum, have produced no efficient algorithm for these problems; crucially, Shor's algorithm does not apply to them at all.

At a practitioner level, the flow looks familiar. Key generation produces a public matrix-and-vector pair and a private set of short secret vectors. Signing uses the Fiat–Shamir with aborts paradigm: the signer commits to a random-looking value, derives a challenge by hashing it together with the message, and computes a response using the secret key — restarting ("aborting") internally whenever the response would leak statistical information about the secret. Verification recomputes the challenge from the message and signature and checks the algebraic relation using only the public key. Signing and verification both run in milliseconds on commodity hardware, with verification especially cheap — a useful property when auditors re-verify thousands of artifacts.

The practical trade-off is size. Lattice keys and signatures are kilobytes, not bytes:

A Dilithium signature is roughly fifty times larger than an ECDSA one. For constrained radio packets that can hurt; attached to an audit artifact or an ML-BOM measured in kilobytes or megabytes, it is noise. Compliance evidence is close to the ideal post-quantum workload: documents are comparatively large, signing happens at generation time rather than per-request, and verification speed matters more than signature bytes. SecureGRC signs every generated artifact with CRYSTALS-Dilithium as standardized in FIPS 204 for exactly this reason.

How do Merkle trees make audit evidence tamper-evident?

Signatures prove each artifact individually. A Merkle tree binds the whole evidence stream together so that history itself becomes tamper-evident. The construction is simple: hash each artifact (SecureGRC uses SHA-3) to form the leaves of a binary tree; hash each pair of siblings to form their parent; repeat until a single Merkle root remains. That one hash value now commits to every artifact beneath it — flip a single bit in any historical record and the root changes.

Two properties make this ideal for audit trails:

• Batching with O(log n) proofs. Proving that a specific artifact is included under a given root requires only the sibling hashes along its path to the root — an inclusion proof. For 1,000,000 artifacts, that is about 20 hashes, a few hundred bytes. Verification cost grows logarithmically no matter how large the evidence store becomes, so one anchored root can efficiently cover an entire reporting period.
• Retroactive immutability. Because each root commits to everything before it, tampering with any past artifact invalidates the proofs of every artifact in the batch. There is no way to quietly rewrite one record; the inconsistency is mathematically visible to anyone holding the root.

In SecureGRC's audit trail, every artifact — threat profiles, control mappings, gap analyses, ML-BOMs, compliance reports — is SHA-3 hashed, signed with Dilithium, and anchored into a Merkle tree. The signature answers "who produced this, and has this document changed?"; the tree answers "has the history changed?" Together they turn an evidence store into a structure where tampering is not just prohibited by policy but detectable by arithmetic.

Why does verifying with only public keys matter to auditors?

The property auditors care about most is independent verifiability: SecureGRC's evidence chain can be checked using public keys alone. An auditor, regulator, or customer verifying an artifact needs the artifact, its Dilithium signature, its Merkle inclusion proof, and the signer's public key — nothing else. No login to the platform, no API access, no trust in the vendor's database, no dependence on the vendor still existing when the evidence is examined.

This inverts the usual GRC trust model. Most compliance platforms are, structurally, a database that says "trust me": the record is whatever the system displays, and the platform operator could in principle alter it. Public-key-only verification removes the operator from the trust equation entirely. The practical consequences:

• Auditor independence is preserved. Verification happens offline, with open FIPS 204 implementations, on the auditor's own machine. The evidence stands or falls on mathematics, not on the platform's word.
• Evidence is portable. Signed, anchored artifacts can be handed to a regulator or acquirer as self-contained proof, exactly as a signed ML-BOM can be shared without exposing the model behind it.
• Disputes become checkable. If two parties disagree about what a report said in 2026, the signature and inclusion proof settle it — either the artifact verifies against the anchored root or it does not.

This composes naturally with SecureGRC's metadata-only architecture: model weights, training data, and proprietary IP never enter the platform, so what gets signed and anchored is extracted metadata — shareable by construction, provable by cryptography.

How does quantum-safe signing compose with ML-BOMs and ISO 42001?

Post-quantum signing is not a standalone feature; it is what upgrades compliance documents into compliance evidence. Two compositions matter most.

Signed ML-BOMs

A machine learning bill of materials inventories a model's components, datasets, dependencies, and licenses in CycloneDX (ML-BOM support since v1.5) or SPDX form. Unsigned, it is a claim that could have been edited at any time. Signed with ML-DSA and Merkle-anchored, each ML-BOM version becomes a fixed point in history: an auditor can confirm both that the document is unaltered and that it existed in that exact form when anchored. Because models retrain frequently, the ML-BOM sequence itself becomes a verifiable changelog of the model estate.

ISO/IEC 42001 evidence duties

ISO/IEC 42001:2023, the AI management system standard published in December 2023, follows the standard management-system pattern: define policies and controls, then retain documented information proving they operate. Its Annex A controls — covering themes such as AI system documentation, impact assessment, data provenance, and lifecycle management — all generate records that certification audits will examine. Quantum-safe signing gives every one of those records integrity protection scaled to the certification's multi-year lifetime. In SecureGRC, this happens at the end of the TCCE pipeline — threat assessment, control mapping against the ISO/IEC 42001 control library, compliance evaluation, then evidence linking — so each conclusion ships already bound to its signed supporting evidence, with threat profiles mapped to MITRE ATLAS along the way.

How should organizations migrate to post-quantum cryptography?

Post-quantum migration is an industry-wide, multi-year effort, and compliance teams do not need to solve all of it. They need to sequence it correctly. A practical order of operations:

1. Inventory your cryptography. You cannot migrate what you have not mapped. Catalog where signatures, hashes, and key exchange protect long-lived records — audit logs, signed reports, document management, timestamping services.
2. Classify by data lifetime, not system age. Mosca's inequality is the sorting function: assets whose required security lifetime plus migration time exceeds plausible CRQC timelines go first. Ten-year evidence beats thirty-day session tokens every time.
3. Move long-lived evidence to FIPS 204 signing now. Evidence generated today with classical signatures will still be inside its retention window in the mid-2030s — the same horizon at which NIST's draft guidance disallows RSA and ECDSA. New evidence pipelines are the cheapest place to be quantum-safe, because there is no legacy verification chain to preserve.
4. Design for crypto-agility. Algorithms should be replaceable configuration, not architecture. That means versioned signature metadata on every artifact, support for parallel or hybrid signatures during transition, and re-anchoring strategies so historical evidence can be re-committed under new algorithms if standards evolve. FIPS 204 is expected to serve for decades, but the lesson of the RSA-to-quantum arc is precisely that assumptions expire.
5. Prefer tooling that is post-quantum by default. Retrofitting PQC onto a platform designed around classical PKI is a genuine engineering program. SecureGRC took the opposite path: as a purpose-built, early-stage platform opening early access in 2026, its audit trail is Dilithium-signed, SHA-3 hashed, and Merkle-anchored from the first artifact — a design contrast with broad incumbent GRC suites that our SecureGRC vs OneTrust comparison explores.

Frequently asked questions

Common questions on post-quantum audit evidence. Broader product questions are answered in the SecureGRC FAQ.