Why do identity recovery and security recovery need different runbooks?

Why This Matters for Security Teams

identity recovery and security recovery are often treated as the same incident because both involve a service account, API key, or automation workload that no longer behaves as expected. They are not the same operational problem. Recovery after accidental deletion is usually about speed, completeness, and restoring service with the right identity objects. Recovery after malicious change is about evidence, trust, and proving the last known good security state. That distinction matters because the wrong runbook can either leave the system down too long or bring it back with compromised settings intact. For NHI-heavy environments, the blast radius is often larger than teams expect. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. Security teams should also account for governance expectations in NIST Cybersecurity Framework 2.0, especially around recoverability, access control, and change management. In practice, many security teams encounter identity recovery after a routine deletion, but security recovery only after a hidden privilege change has already been used for persistence or lateral movement.

How It Works in Practice

A clean identity recovery runbook focuses on reconstructing the identity object itself: re-creating the account, restoring group membership, reissuing certificates or keys if needed, and validating that dependent applications can authenticate again. The goal is to return the workload to service with the minimum safe set of permissions. A security recovery runbook is different. It must determine what changed, when it changed, who or what changed it, and whether the change was part of a broader compromise. That is why the two runbooks need different checkpoints:

• Identity recovery confirms object existence, ownership, naming, and dependency mapping.
• Security recovery confirms policy baselines, privileged roles, secret rotation status, and audit trails.
• Identity recovery may restore from backup; security recovery must restore from a trusted state after validation.
• Identity recovery can prioritise service continuity; security recovery must prioritise forensic integrity and controlled re-enablement.

This is also where NHI-specific evidence matters. The 52 NHI Breaches Analysis and Top 10 NHI Issues show that compromise patterns often involve secrets, over-privilege, and weak rotation rather than simple loss of an account object. That is why a security recovery workflow usually includes secret invalidation, privilege review, and re-certification before service is fully restored. These controls tend to break down when the workload is deeply embedded in CI/CD pipelines because the same automation that recreates identity can also reapply unsafe permissions at scale.

Common Variations and Edge Cases

Tighter recovery controls often increase downtime and operational overhead, so organisations have to balance restoration speed against assurance. That tradeoff is real, especially when the same team owns platform uptime and incident response. Some environments blur the boundary between identity and security recovery. For example, if an API key is lost and the only surviving copy is in a compromised vault, the issue is both availability and trust. Current guidance suggests treating that as a security incident first, because the system may still authenticate even though the credential is no longer safe. Similarly, if a service account is deleted but audit logs show no change in permissions or secrets, a faster identity rebuild may be appropriate. Edge cases become harder when there is no clean backup of the trusted state, or when downstream services cache tokens and roles for hours or days. In those cases, best practice is evolving toward separate runbooks that share a common inventory and escalation path but diverge at the decision point: restore identity object versus rebuild trust. That approach aligns with the principle of limiting standing privilege and verifying recovery before re-enablement, which is consistent with Zero Trust expectations in NIST Cybersecurity Framework 2.0 and the NHI governance lessons surfaced in the Ultimate Guide to NHIs. When deletion, token theft, and policy tampering happen together, a single runbook usually fails because it cannot restore trust and availability in the right order.

Related resources from NHI Mgmt Group

• How should security teams scope recovery access for cloud identity backups?
• How should security teams handle unsupported identity platforms in production?
• How should security teams handle unsupported identity platforms?
• How should security teams implement GRC so identity controls are part of it?