Who is accountable when malicious identity changes are restored too slowly?

Why This Matters for Security Teams

When malicious identity changes are restored too slowly, the problem is not only recovery speed. It is also whether the organisation is still trusting a compromised identity state while business services are coming back online. That is why accountability usually sits with both the identity owner and the resilience or recovery owner, with governance expectations shaped by NIST Cybersecurity Framework 2.0 and zero trust practices. In NHI environments, delayed rollback can leave service accounts, API keys, and automation pipelines active after they should have been revoked.

This matters because identity changes are often propagated across directories, vaults, CI/CD systems, and application configs at different speeds. If one system restores a malicious state later than another, the environment can drift into an inconsistent and unsafe posture. NHI Mgmt Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a clear sign that remediation is often slower than attackers expect. That gap is explored further in the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis.

In practice, many security teams discover the accountability gap only after a revoked token, bad role assignment, or compromised service account has already been reintroduced during recovery rather than through intentional control design.

How It Works in Practice

The operational answer is to assign shared responsibility with clear decision boundaries. Identity teams normally own the correctness of the restored identity state, including role mappings, keys, certificates, and revocation status. Resilience or incident recovery teams own the timing, sequencing, and validation of restoration so the business can return safely. Current guidance suggests these owners should agree on a recovery objective that includes both service uptime and identity integrity, not just one or the other.

Practitioners usually need four controls working together:

• Trusted rollback points for directories, vaults, and IAM policy stores, so malicious changes can be removed from a known-good baseline.
• Validation checks that compare restored identities against approved access models before systems are reconnected.
• Revocation workflows for secrets, API keys, certificates, and privileged sessions, so restored accounts do not keep attacker-established trust.
• Escalation paths that define who approves delayed restoration when business pressure conflicts with containment.

For non-human identities, the fastest safe recovery often depends on how well the organisation can inventory and rotate credentials, which is why guidance in the Top 10 NHI Issues is so relevant. NIST’s zero trust model also reinforces that access should be re-evaluated continuously, not assumed safe because a system has been restored. Where teams have strong observability and short-lived credentials, recovery can be verified quickly. Where secrets are embedded in code, config files, or legacy automation, restoration becomes slower and harder to trust. These controls tend to break down when identity data is spread across unmanaged scripts and third-party tooling because revocation and reissuance cannot be coordinated reliably.

Common Variations and Edge Cases

Tighter restoration control often increases outage time, requiring organisations to balance containment against service availability. That tradeoff becomes more visible when the restored identity is used by critical automation, customer-facing integrations, or scheduled jobs that cannot tolerate long interruption. There is no universal standard for the exact recovery sequence yet, so best practice is evolving around risk-based prioritisation rather than a single fixed rule.

One edge case is a partial restore where the identity is technically back, but its privileges, tokens, or trust relationships are still under review. In those cases, teams may choose to restore the account in a constrained state first and expand access only after verification. Another case is federated environments, where restoration in one directory does not automatically clean up downstream caches or cloud role assumptions. The JetBrains GitHub plugin token exposure and Cisco DevHub NHI breach illustrate how identity compromise can persist through tooling, integrations, and trust chains even after a primary fix is made.

For high-value identities, some organisations define dual approval for restoration, while others use automated rollback with human verification after the fact. The right model depends on whether the greater risk is reintroducing the attacker or prolonging the outage. The practical lesson is that accountability should be explicit before the incident, because identity recovery becomes messy once multiple teams are changing the same account state at once.

Related resources from NHI Mgmt Group

• Who is accountable when an identity platform falls out of support or drifts from policy?
• Who is accountable when an AI agent changes prices or processes a refund incorrectly?
• Who is accountable when delegated workload identity ownership drifts over time?
• Who should be accountable for machine identity assets that have no clear owner?