Proof with an expiry date

The first four notes in this series built a self-hosted AI stack you could defend to an auditor: sovereign by deployment, with integrity proven at the model, the data, and the hardware. This one adds the axis the other four assumed away. Time. Every integrity guarantee you established has a cryptographic expiry date, and for a regulated firm the records can outlive the cryptography protecting them.

The mismatch nobody costed

A regulated firm keeps records for a long time. Transaction records, communications, audit evidence, and client documentation run to retention horizons of five to seven years under FCA SYSC and the PRA Rulebook, longer under tax and pension rules, and in some cases the obligation is effectively indefinite. That is the business you are in: proving, years later, that a thing happened the way you said it did.

The integrity of those records rests on cryptography. Digital signatures attest that a document is what it claims to be. Encryption protects archives at rest. Both rely today on RSA and elliptic-curve algorithms, and both are broken by a sufficiently capable quantum computer, retroactively, across an entire archive at once. So the mismatch is this: you may be obligated to keep records verifiable for fifteen or twenty-five years, while the algorithms making them verifiable have a regulator-flagged end of life inside that window. The proof can expire before the obligation does.

How close is the threat, honestly

Take the technical distance seriously, because overstating it is how this argument loses a literate reader. A cryptographically relevant quantum computer, one that can run Shor's algorithm against RSA-2048, does not exist today and is not close in raw terms. The bottleneck is error-corrected logical qubits, and current machines are orders of magnitude short of the count required. Credible estimates for arrival span the late 2020s to beyond 2040, and anyone quoting a confident date is guessing.

The case does not rest on a date. It rests on two things that are true now regardless of when the machine arrives: retention horizons that reach past the plausible arrival window, and the harvest-now-decrypt-later threat. An adversary does not need a quantum computer today to act today. They need only to copy your encrypted archive now and store it until the capability lands. For a regulated firm the retained archive is the prize, because its value does not decay, it accrues. A February 2025 Europol Quantum Safe Financial Forum statement put the call to action plainly to the sector. The scoping matters: harvest-now is a real threat for data whose sensitivity outlives Q-day, and a much weaker one for records that will be worthless to an attacker by the time they can be read. Prioritise accordingly rather than treating every archive as equally exposed.

What crypto-agility actually means

Crypto-agility is not "use stronger encryption." It is an architectural property: cryptographic algorithms are abstracted behind interfaces, so a primitive can be replaced without rebuilding the system that depends on it. An agile system lets you change a signature scheme as a controlled operation, not a re-architecture.

Two cautions keep this from being a slogan. First, agility is itself an attack surface. A system that can negotiate or swap algorithms can be pushed to negotiate down to a weak one; downgrade and algorithm-confusion attacks are the cost of doing agility badly, and the design has to pin minimums, not just enable choice. Second, agility is what makes the rest of the series survive. The root of trust from the previous note, the hardware attestation chain, is only as durable as the algorithm it is bound to. An attestation chain hardcoded to one signature scheme is not agile, and the moment that scheme is disallowed, the root the firm relied on expires with it. Build agility in and a primitive change is a maintenance task; leave it out and a primitive change is a forced rebuild of everything that trusted the old one, under time pressure, all at once.

The standards are finalised; the deadlines are guidance, not rules

This is no longer a research topic. NIST finalised the first post-quantum standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. The algorithms to migrate to exist and are standardised. Worth holding in view: PQC schemes can still fail. SIKE and Rainbow were broken during and after the selection process, which is precisely why hybrid deployment, classical and post-quantum together, is the recommended interim rather than a clean switch.

The published timelines, by instrument and status:

Read the convergence carefully. These dates are not three independent confirmations; they are largely downstream of one upstream signal, the US National Security Memorandum 10 and NIST's lead, echoed across allied jurisdictions. Treat them as one correlated guidance horizon, not as triangulated proof. None of these instruments is a financial-services rule, and one of them is still a draft. For a firm with a cross-border perimeter the binding constraint is whichever regulator moves first, and the EU has tied its roadmap to DORA, NIS2, and the Cyber Resilience Act, which is suggestive of where sector pressure will land without yet being an obligation.

The sovereignty question underneath

One point a self-hosting series cannot skip: the post-quantum standards a non-US firm adopts are US-originated, selected and published by NIST. That is not a reason to avoid them, they are the most scrutinised options available, but it is a sovereignty fact worth naming, and other jurisdictions are forming their own positions. India's CERT-In and RBI, and Singapore's MAS, are developing PQC guidance on their own timelines, and a firm operating across those perimeters should track them rather than assume the NIST horizon transfers unchanged. Agility is the hedge that makes jurisdictional divergence survivable: if you have abstracted the primitive, supporting a second approved scheme for a second regulator is a configuration change, not a second migration. And the lock-in caution is concrete. If your cryptography is hardcoded inside a vendor product you do not control, you are not agile no matter what your architecture diagram says; the part of the stack you self-host is the part you can actually keep agile.

The audit-defensible position

Strip away the cryptography and this is an audit-evidence problem, so frame it the way an auditor reads. What a defensible firm can show today, without waiting for a sector mandate:

• A cryptographic bill of materials (CBOM). An inventory of where cryptography is used across the estate: which algorithms, in which systems, protecting which data, under which retention obligation. You cannot migrate what you have not found, and the inventory is itself a deliverable an auditor can test. Be honest that CBOM tooling is still immature, so resource it as a real programme rather than assuming a tool will hand it to you.
• A dated migration plan, prioritised by retention horizon times adversary value. Not retention alone. The systems to move first are those holding data that is both long-retained and worth stealing; a fifty-year pension record with low intelligence value is not the same priority as client financial positions with a long sensitivity tail.
• Hybrid deployment during transition, with the classical half implemented correctly, since a weak classical leg negates the post-quantum one. Hybrid is the hedge against the new schemes themselves failing.
• Crypto-agility designed into anything new, with negotiated-downgrade protection, and built on vetted libraries. Own your cryptographic posture; do not write your own primitives, where early PQC implementations have already shipped side-channel bugs.

A hard reality sits across all of this: most of a regulated firm's cryptography lives inside COTS and vendor systems it does not control. You cannot make a core-banking platform or a market-data vendor agile by deciding to. The defensible move is to inventory that dependency, press vendors on their PQC roadmaps as a procurement criterion, and keep your own self-hosted layer genuinely agile. None of this requires a quantum computer to exist, a regulator to issue a mandate, or the migration to be finished. It requires the firm to have started, deliberately, with evidence. That is the whole of the audit-defensible position: not "we are quantum-safe," which no one can honestly claim yet, but "we have inventoried our exposure, prioritised it by retention and adversary value, and we are migrating on a dated plan with agility built in."

The series, closed

Five notes, one argument. Sovereign by default set the deployment stance. The model supply chain, the data and prompt supply chain, and the hardware root of trust each closed an integrity gap in the stack you can self-host and defend. This note closes the last one: temporal integrity, the property that the proofs still hold years after you wrote them.

There is a tension worth admitting at the close. A world of crypto-agility is a world where proof is provisional, valid until the next migration, and that sits oddly against a records function whose purpose is durable certainty. The resolution is to treat durability as something you maintain rather than something you set once. Put the five notes together and they describe an audit-defensible self-hosted AI stack: sovereign in deployment, verified at the model, the data, and the hardware, and durable across the retention horizon the firm is actually obligated to. The thread through all five is the same. Integrity is not a posture you adopt after an incident or a deadline. It is a property you build into where the boundaries sit, and into how long they are designed to hold.

About the Author

I am a CISA and CISSP-certified governance practitioner. My day-to-day work spans technology risk, audit defensibility, and cross-border regulatory intelligence across the UK (FCA, PRA), India (RBI, SEBI, IFSCA), Southeast Asia (MAS), and the Gulf (CBUAE), with working knowledge of the EU AI Act's financial services implications.

My current research sits at the intersection of audit-defensible AI deployment patterns and supervisory expectations in regulated firms, including sovereign open-weights deployment and the governance of agent and inference pipelines in firms with cross-border regulatory perimeters.

LinkedIn • [email protected] • rtapulse.com