How do you rotate a compromised signing key without breaking an append-only audit chain?

You rotate a compromised signing key by issuing a new key and recording the rotation as a signed event inside the same audit chain, not by rewriting the log. Each key carries a validity window, so every historical entry stays verifiable under the key that signed it, while the compromised key is marked retired from a fixed point forward. Revocation does not erase history; it becomes another sealed line in it. An append-only ledger verifies each entry against the key valid at its own timestamp, not whatever key is current today.

Key compromise is a when, not an if, and in 2026 the regulators that matter treat the audit trail as the deliverable. An audit chain that shatters the moment a key is rotated is not evidence; it is a liability, so buyers ask how the log survives its own rotation first.

How does key rotation actually work without breaking the chain?

Each signing key has a validity window: a start time, an end time, and a unique identifier. Every entry is signed by the key valid at that instant, which it stores alongside the signature. When a key is retired, the system appends a rotation event, itself signed and timestamped, naming the outgoing and incoming keys, the reason and the effective moment of the change.

Verification then follows one rule: read an entry's timestamp, look up the key that was valid then, and verify the signature against it. Entries written before the rotation still verify under the old key because it was genuinely valid when they were written. Nothing is re-signed or moved; the compromised key simply stops being valid after the rotation timestamp.

“Rotating a key should add a line to the record and never remove one, and a system that cannot rotate without rewriting is not keeping an audit chain at all.”

What can an auditor check after a key is rotated?

An auditor runs three checks.

• Continuity: every entry links to the one before it by hash, so any deletion or insertion breaks the chain and is visible.
• Key provenance: every signature verifies against the key valid at the entry timestamp, and every key change is itself a signed, in-chain event with no gaps.
• Attestation: each key traces back to the hardware device that generated and held it.

We call the combined pass the retired-key test: take any entry written before a compromise and confirm it still verifies under the now-revoked key. If it verifies, history held; if not, the chain was tampered with. This is a yes or no answer reproducible offline, without a network connection and without trusting us.

Why does hardware-attested identity matter here?

A key on its own is a secret that can be copied. Hardware-attested identity binds each key to the physical device that generated it, inside a secure element the operator owns. The device signs an attestation that the key never left it, and that binding is recorded in the chain when the key is enrolled.

This changes what a compromise means. If a signature appears from a key but its attestation does not match the enrolled device, the entry is suspect on its face. Rotation then revokes not just a number but a device relationship, because the chain records which attested device each key belonged to. An attacker who lifts a key cannot reproduce that attestation, so a forged entry fails the test.

Why is the audit ledger signed with post-quantum algorithms?

An audit chain has to stay verifiable for years, sometimes decades. A signature scheme that is safe today but broken by a quantum computer in the 2030s makes every historical seal forgeable, so the ledger is sealed with post-quantum digital signatures. We use FIPS 204, the ML-DSA standard, as the primary algorithm and FIPS 205, the SLH-DSA standard, as a hash-based alternative. FIPS 203, ML-KEM, is key encapsulation and never signs anything, so it plays no part in sealing the ledger.

A retired key therefore stays cryptographically meaningful long after retirement: the old entries do not become forgeable when the algorithm era moves on, which a classical signature cannot promise past the quantum horizon.

Which rules make this necessary?

Several regimes converge on the same demand: prove what happened, and prove nobody rewrote the record.

• DORA, in force since January 2025, requires financial entities to evidence operational resilience, including the integrity of their logs through an incident.
• NIS2 extends comparable obligations to essential and important entities across critical sectors.
• GDPR requires that you can show who accessed personal data and when, without gaps.
• ISO/IEC 42001 sets out auditable governance for AI management systems.

The EU AI Act adds the sharpest edge for AI systems. The high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read the deferral as a build window, not a reprieve: a vendor whose audit chain cannot survive a key rotation cannot meet these standards, because a broken chain is indistinguishable from a hidden one.

Where do public cloud AI services fall short?

Regulated operators cannot send an audit chain, or the data it describes, to a service they do not control. Public cloud AI services run on infrastructure reachable under laws such as the US CLOUD Act, which can compel disclosure regardless of where the data sits. A signing key held in an environment the operator does not control cannot be attested to a device the operator owns, and its rotation is governed by a provider, not by the auditor.

Mickai is a Sovereign Intelligence Operating System. It runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so the audit chain, the signing keys and their attestations never leave the building. The rotation mechanism, the hardware binding and the post-quantum ledger sit within 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, patent pending. Sovereignty is what lets rotation stay an internal, provable event rather than a request to a third party.

Frequently asked questions

Does rotating a signing key invalidate old audit log entries?

No. Old entries stay verifiable under the key that was genuinely valid when they were written. Rotation only changes which key is valid going forward, so nothing already recorded is invalidated.

Can you rotate a signing key offline, with no internet connection?

Yes. Because a Sovereign Intelligence Operating System runs on operator-owned hardware behind a zero-egress inbound perimeter, the new key is generated, attested and enrolled locally. The rotation event is signed and appended with no external service, and no network is needed to verify the chain afterwards.

What is the difference between revoking a key and rewriting the audit log?

Revoking a key marks it invalid from a stated moment forward and records that decision as a signed event. Rewriting the log alters or removes past entries, which an append-only chain makes both impossible and detectable. The first leaves history intact; the second breaks the hash links and fails verification.

Which post-quantum standard signs the audit ledger, FIPS 203 or FIPS 204?

FIPS 204, the ML-DSA standard, is the primary signature algorithm that seals and verifies the ledger, and FIPS 205, SLH-DSA, is a hash-based alternative. FIPS 203, ML-KEM, is key encapsulation and never produces signatures, so it plays no role in sealing or verifying an audit chain.

How does an auditor verify the chain after a key has been compromised?

The auditor takes any entry written before the compromise and confirms it still verifies under the now-revoked key, then checks that every hash link is unbroken and every key change is a signed in-chain event. This retired-key test returns a reproducible yes or no offline, without trusting the vendor.