Crypto Incident Response: Rotate Compromised Primitives in Days, Not Months

The uncomfortable truth about cryptographic incidents is that most of the damage is decided months earlier. If algorithms are hardcoded, keys are unnamed, and custody ceremonies exist only as aspirational slides, “rotate” means a multi-quarter rewrite. If you designed for crypto-agility, rotation is an incident phase with a clock—not a research project.

This playbook assumes you already have inventory and signing paths from earlier essays: threat model, HSM/MPC, production custody, and post-quantum migration as the planned cousin of emergency change.

What counts as a crypto incident#

Not every CVE is a Sev-1. Treat as crypto-incident when any of these are true:

• Private key material may be exposed (logs, ticket, backup, insider, vendor breach)
• A signing or TLS primitive you depend on is broken or urgently deprecated
• Approval or custody controls failed (single person signed beyond policy; break-glass abused)
• Evidence of forged tokens, unexpected chain signatures, or mass auth failures tied to crypto validation

IBM’s breach-cost research consistently shows credential and system compromise among the most expensive paths, with financial services historically at the high end. Speed of containment and rotation is part of cost control—not only forensics theater.

Phase 0 — Preconditions you need before the pager#

Write these while calm:

• Algorithm and key inventory with owners and environments
• Dual-run capability for verification (accept old + new) where protocols allow
• Named rotation owners for hot, warm, and cold paths
• Comms templates for customers, partners, and regulators when safeguarding is affected
• Kill switches for hot signing velocity

Phase 1 — Detect and classify (minutes to a few hours)#

1. Freeze speculative “quick patches” that widen blast radius 2. Classify: confidentiality of key material vs integrity of signatures vs availability of auth 3. Scope: which products, chains, APIs, partner integrations 4. Open a dedicated incident channel with crypto, platform, legal/compliance, and exec liaison

Tie detection to the metrics in the next essay on crypto risk observability—failed auth spikes, novel signing destinations, and inventory drift are early signals.

Phase 2 — Contain (hours)#

• Disable or rate-limit compromised hot paths; move critical ops to warm with heightened quorum
• Revoke sessions, tokens, and API keys that depend on the burned material
• Preserve evidence (HSM logs, approval trails, chain txs) before wiping
• If ledger keys are involved, follow chain-specific pause/guardian patterns you already tested—do not invent governance under fire

Containment without a plan to rotate only buys silence.

Phase 3 — Rotate (target: days)#

Order of operations that usually works:

1. Generate new material in the correct custody path (HSM/MPC/cold ceremony)—never reuse entropy or “temporary” laptop keys 2. Deploy dual verification or dual encryption where possible so old and new overlap safely 3. Cut signing/issuing to new material; keep old verify-only as short as risk allows 4. Re-encrypt or re-wrap long-lived secrets that used the old key (Zone B data from ledger boundaries) 5. Retire and destroy or escrow-old-per-policy; update inventory and compliance evidence (compliance as architecture)

Those “prepared” targets are why agility is an operational property, not a slogan.

Phase 4 — Verify and learn (days to two weeks)#

• Prove old material cannot sign production paths
• Run a customer-visible integrity check where appropriate (e.g. attestations still verify)
• Update threat model assumptions that failed
• Schedule the next rotation drill—tabletop plus one technical dry-run per year minimum for critical keys

Special case: algorithm break vs key leak#

Key leak: assume total compromise of that identity; rotate material and review all signatures/transactions in the exposure window.

Algorithm break: may require coordinated dual algorithms and partner timelines—closer to a compressed PQC migration. Do not “just bump a library” if wire formats and HSMs must change.

People and vendors#

Incidents fail socially as often as cryptographically: unclear authority, vendor SLAs that start at “next business week,” or cold keys nobody can convene. Keep vendor escalation paths next to the runbook. If a custodian or KMS is in the path, know the emergency re-key API before you need it.

After the fire#

Ship the boring fixes: remove hardcoded algorithms, tag every key with purpose and age, and put rotation MTTD/MTTR on the same dashboard as uptime. Our cyber security and blockchain teams run these drills with fintech clients so the first rotation is not the first rehearsal.