Cryptographic Key Lifecycle: How KERI Handles Rotation, Recovery, and Delegation

Every cryptographic identity has a lifecycle problem. Keys get compromised. Devices get lost. Employees leave organisations. Relationships between entities change. The question for any identity infrastructure is not whether it will need to handle key changes, it will, but whether it was designed with that expectation from the start, or whether key management is an edge case bolted on after the core system was built.

Most identity systems treat key management as an afterthought. The result is infrastructure that calcifies: keys that were supposed to be temporary become permanent because rotation breaks downstream dependencies, recovery mechanisms that were added later don't integrate cleanly with the trust model, and delegation gets approximated with shared secrets or privileged accounts rather than cryptographic authorisation chains.

KERI treats key lifecycle as a first-class design concern. Rotation, recovery, and delegation are not extensions to the core protocol, they are what the protocol was built to do.

Rotation

Key rotation in KERI is not a destructive update to a mutable record. It's an event appended to the key event log, a signed statement from the currently authoritative keys transferring control to a new key set. Verifiers who hold the KEL can trace an unbroken authorisation chain from the identity's inception through every subsequent rotation to the current state. There is no ambiguity about which keys are currently authoritative, and no moment in the rotation process where authority is unclear.

The log structure means rotation is fully auditable. You can see exactly when each rotation occurred, what keys were involved, and that each transition was properly authorised by the keys that held authority at the time. This audit trail is cryptographically bound to the log's structure, revising history would require invalidating the hash chain and the signatures on every subsequent event.

Rotation also provides forward security at the identity level. Once a key is rotated out, it can no longer authorise new events. Compromise of a historical key doesn't affect current authority, an attacker who recovers an old private key gains no ability to issue new events or perform further rotations. The authority timeline is one-directional: you can trace it forward, but you cannot alter it retroactively.

Recovery

Recovery addresses the harder problem: what happens when the keys that should authorise a rotation are themselves compromised or unavailable?

In KERI, recovery is not a separate mechanism, it is pre-rotation. At every rotation (and at inception), the controller commits to the next key set by publishing its hash. The actual keys remain secret until the next rotation event reveals them. If the current operational keys are compromised, the attacker cannot forge a valid rotation because the pre-rotation commitment was established before the compromise, and the pre-committed keys are ones the attacker doesn't hold.

This is covered in depth in a separate post on pre-rotation, but the key point for lifecycle management is this: KERI doesn't treat recovery as an emergency procedure. It treats it as a property that's continuously maintained. Every valid state of the identity includes a cryptographic commitment to the next state. The ability to recover is always present, not something you set up after an incident.

The operational implication is that recovery keys, the pre-committed next keys, should be generated and stored with recovery-grade security from the beginning. Offline storage, hardware security modules, geographic distribution, multi-party custody. The protocol doesn't mandate any specific approach, but it creates the right structural incentive: the next keys matter, and they should be protected proportionally.

Delegation

Delegation allows one KERI identity to authorise another identity to act on its behalf. The delegating identity signs a delegation event; the delegate's inception event references that authorisation. The relationship is recorded in both parties' key event logs and verifiable by any third party who holds them.

This is relevant for organisational contexts where a legal entity needs to delegate signing authority to individuals or systems. A corporation might maintain a root identity and delegate to identities representing specific departments, employees, or automated systems. Each delegation is explicit, auditable, and scoped, the delegate's authority is derived from and bounded by the delegation event.

Delegation in KERI is cooperative: the delegator must explicitly approve the delegate's inception and can revoke it later. This is a stronger model than simply issuing a credential, it creates a verifiable chain of authority that any verifier can trace. If a delegation is revoked, any verifier checking credentials issued by the delegated identity will trace back to the delegator and see that the delegation no longer holds.

When an employee leaves or a system is decommissioned, the revocation is an event on the delegating identity's KEL. There is no need to track down and invalidate individual credentials. The chain of authority breaks at the delegation event, and everything downstream is affected.

Lifecycle as Architecture

The reason KERI handles these concerns more coherently than most identity systems is that they were design inputs, not additions. The key event log structure was designed to support rotation from the beginning. Pre-rotation, the mechanism that protects against key compromise during rotation, was in the original design. Delegation was considered before the data model was finalised.

The consequence is an identity infrastructure where the difficult operational realities of cryptographic key management are governed by the same verifiable, auditable mechanisms as the identity itself. Key changes don't require out-of-band trust or administrative intervention. They require the right keys and the right event structure. That's a meaningful difference when you're building systems that need to remain trustworthy across years of personnel changes, infrastructure migrations, and evolving threat models.