Pre-Rotation Private Key Recovery
Lock in your digital identity recovery path before you ever need it
Pre-Rotation, popularized by the KERI protocol, resolves the catastrophic-loss problem inherent in decentralized identity systems. Before a primary private key is ever used, the holder generates one or more rotation keys and cryptographically commits to them in the key event log. If the primary key is later compromised or lost, the holder broadcasts a rotation event using a pre-generated backup key, invalidating the old key and establishing the new one. This mirrors Bitcoin multisig best practices: recovery capability is established proactively, not reactively. The cost is that losing all rotation keys alongside the primary leaves no recovery path, making custody hygiene across multiple separated locations non-negotiable.
- Prepare recovery mechanisms before you need them, never reactively
- Pre-commit to rotation keys cryptographically before first use of the primary key
- Physical and logical separation between primary and rotation key storage is mandatory
- Match recovery complexity to the sensitivity of what the key controls
- Context determines the acceptable trade-off between convenience and recovery assurance
- Generate your primary private key and establish your DIDCreate the primary cryptographic key pair that will serve as your decentralized identity anchor. This key controls your DID and authorizes all subsequent credential issuance and presentation.Pro tipGenerate keys offline on a hardware device wherever your threat model warrants maximum isolation.
- Generate pre-rotation key pairs before the primary key is used publiclyBefore the primary key is used for any public-facing operation, generate one or more backup rotation key pairs. These keys exist solely to replace your primary key if it is compromised or lost.Pro tipGenerate multiple staged rotation levels for deep fallback—if Rotation Key 1 is also compromised, Rotation Key 2 can still recover your identity.WarningNever generate rotation keys on the same device or at the same session as your primary key if your threat model includes device-level or session-level compromise.
- Commit pre-rotation key hashes to your key event log before first useCommit the cryptographic hash of your rotation keys into your protocol's key event log before the primary key is ever used publicly. This proves you controlled the rotation keys before any compromise occurred, preventing fraudulent rotation claims from an attacker.WarningRetroactive commitment—made after the primary key has been used—cannot prevent an attacker who already controls the primary key from submitting their own fraudulent rotation claim first.
- Store rotation keys in separated, secure custodyPlace rotation keys in geographically or custody-separated storage entirely apart from your primary key—hardware wallets, safety deposit boxes, trusted multisig participants, or institutionally held custody as warranted by your threat model.Pro tipTreat rotation key custody with the same rigor as a Bitcoin inheritance plan—someone trusted must be able to use them on your behalf if needed.
- Document and rehearse the rotation event broadcast procedureWrite out the exact steps to broadcast a key rotation event and test them against a dedicated test DID before any real compromise forces live execution. Know precisely how to revoke the old key and establish the new controlling key.Pro tipRun an annual rotation drill on a test identity to ensure the procedure still works and all custody participants know their role under pressure.WarningA rotation procedure that has never been tested will likely fail when executed under the time pressure and stress of a live compromise event.
- Broadcast a rotation event immediately upon detected compromiseWhen compromise is detected or credibly suspected, use a pre-rotated backup key to broadcast a rotation event that invalidates the old key and establishes the new controlling key across the network. Act before the attacker can issue fraudulent credentials using the compromised key.WarningA compromised primary key continues to be valid for credential issuance until the rotation event is confirmed by the network—broadcast immediately, do not delay to investigate first.
A developer establishes a DID using KERI and immediately generates two rotation keys, committing their hashes to the Key Event Log before any credentials are issued against the primary. Rotation keys are stored on separate hardware wallets in different physical locations. When the developer's laptop is later stolen, they broadcast a rotation event from one backup hardware wallet, invalidating the stolen primary key across the KERI witness network within hours.
A Bitcoin self-custodian maps pre-rotation logic onto a 2-of-3 multisig: one key for daily use, one in a home safe, one held by a trusted family member with a sealed recovery procedure. When the daily-use key is compromised, the remaining two keys authorize migration to a new wallet, preserving the full stack without any exchange or custodian involvement.
Drawn from the KERI (Key Event Receipt Infrastructure) protocol and described on TFTC, where it was cited alongside Bitcoin multisig as a model for proactive decentralized key recovery without any centralized fallback or support hotline.