TL;DR: Patching closes the entry point but does not restore trust after administrative compromise, according to Acsense, and the article uses a four-day exploitation window to show why identity recovery must be isolated, immutable, and testable. The governing assumption that a patched platform is also a trusted platform collapses once an attacker can alter recovery paths, tokens, and connected systems.
At a glance
What this is: This is an analysis of why patching alone does not restore trusted identity state after administrative compromise in Okta or Microsoft Entra ID.
Why it matters: IAM teams need recovery methods that survive compromised admin authority, because trusted state, not just fixed software, determines whether access can be safely resumed.
Context
IAM disaster recovery means restoring an identity platform to a trusted, working state after breach or misconfiguration, even when attacker-controlled administrator credentials may still exist. The article argues that the core failure is confusing patching with recovery, because a fixed platform is not automatically a trustworthy one.
The problem is especially acute for Okta and Microsoft Entra ID because those systems decide who and what the organisation trusts. If attackers can change tokens, users, groups, or federation relationships before detection, the team needs a separate recovery path that is outside the compromised authority domain.
Key questions
Q: What fails when an identity platform is patched after administrator compromise?
A: The failure is trust-state recovery, not patch validation. A patch can close the original entry point while attacker-created tokens, changed group membership, modified federation links, or altered connected systems still remain. Teams must assume the platform may be technically current but operationally untrusted until the recovery state is verified and restored from a protected source.
Q: Why does IAM disaster recovery need more than a fixed version and change history?
A: Because version history shows intent, not necessarily the live state at the moment of compromise. A compromised admin can alter runtime settings, permissions, or dependencies without leaving a simple Git trail. Recovery needs a protected state source that captures what was actually trusted, not only what was approved in source control.
Q: What are the signs that identity recovery is not actually isolated from production?
A: The clearest signs are shared administrator credentials, shared cloud authority, backup jobs controlled from the same tenant, or rollback artefacts that can be deleted by production admins. If those paths overlap, the recovery copy shares the same blast radius and may fail exactly when it is needed most.
Q: Should security teams automate rollback after identity compromise?
A: Yes, but only for clearly bounded, high-confidence changes and only when the rollback source is protected from the attacker. Automatic recovery is useful when it removes delay, but it becomes dangerous if the baseline itself can be altered. Approval-gated restoration is still needed for broader tenant-wide changes.
Technical breakdown
Why patching does not restore trusted identity state
Patching removes a known vulnerability, but it does not reverse the administrative actions that happened before the fix. In identity systems, an attacker with privileged access can create tokens, alter users and groups, change federation relationships, or modify connected systems without needing to keep exploiting the original flaw. That is why the recovery problem is not only code integrity. It is state integrity. A trustworthy identity platform must be able to prove what changed, what remains trusted, and what must be rolled back before access resumes.
Practical implication: treat patching as entry-point closure, not as evidence that identity state is safe to reuse.
Why Git is not the same as an isolated recovery copy
Version control is valuable for intended configuration change, but it is not a complete recovery system. Git records what someone committed, not necessarily what was live when an attacker gained control. It can also miss runtime state, object relationships, secrets, and restoration ordering. If the same identity authority controls both production and the repository, the recovery source may share the same blast radius. Recovery needs a protected copy that preserves actual state outside the production control plane.
Practical implication: separate the system of record for recovery from the identities and controls that administer production.
Why recovery must be immutable, air-gapped, and testable
The article’s recovery model depends on a copy that cannot be casually rewritten by the compromised administrator. Immutable storage prevents silent alteration, air gap separates administrative authority, and testability proves the snapshot can actually restore applications and access. The point is not only keeping backups. It is making sure the last trusted state survives long enough to be useful and can be verified before the business depends on it again. Without that proof, the recovery copy is only a promise.
Practical implication: validate that recovery artefacts are both protected from admin abuse and usable in a real rollback.
Threat narrative
Attacker objective: The attacker’s objective is to obtain administrative control over trusted software distribution and the downstream identity or access relationships that depend on it.
- Entry occurred through a critical authentication flaw in a widely used software supply-chain platform, giving an unauthenticated actor administrative access.
- Credential and authority abuse followed as attackers created administrator tokens and mapped users, groups, credential sets, and federation relationships.
- Impact emerged when connected systems and trust relationships could no longer be assumed reliable, even after the patch was applied.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
- Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Trusted recovery is a separate control plane from patching: A fixed product version does not prove that the identity state surrounding it is trustworthy. The breach window matters because privileged actors may already have altered tokens, federation links, or connected systems before remediation begins. The implication is that IAM disaster recovery must be designed around state restoration, not software repair.
Recovery copies must survive the administrator: The assumption that backup access is benign was designed for normal operations, not for a compromised privileged operator. That assumption fails when the actor can delete, rewrite, or disable the very artefacts needed for rollback. The implication is that recovery authority must be separated from production authority.
Git is a change record, not a trust guarantee: Configuration history helps explain intent, but it does not prove live runtime state or restore all dependencies. If the recovery source shares the same identity boundary as production, it can be altered by the same compromise. Practitioners should treat source control as useful evidence, not as the recovery system itself.
Identity disaster recovery is now a blast-radius discipline: The real question is no longer whether a platform can be upgraded quickly, but whether trusted state can be re-established before downstream systems continue to rely on compromised authority. That makes recovery design a core identity control, not an operational afterthought.
Fast response only works when the last trusted state is provable: Automated rollback, approval gates, and verified snapshots only help if the state they restore is outside the attacker’s reach. This article sharpens a named concept we call trusted recovery authority: the ability to restore identity services from a protected state the attacker cannot tamper with. Practitioners should measure whether that authority truly exists before the next incident.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Trusted recovery authority: Identity programmes now need a separate notion of who is allowed to restore trust, not just who is allowed to administer production. When the same account can both change and recover the system, the recovery plan inherits the compromise and loses its value.
Patch speed matters, but recovery design determines whether a fixed platform can be used safely again. For IAM teams, the operational test is whether the last trusted state is protected from the same blast radius that affected production.
A recovery copy that has never been exercised is still an assumption. The programme question is whether identity, federation, and application trust can be rebuilt from an immutable source before the business keeps depending on the compromised state.
For practitioners
- Separate recovery authority from production admin rights Place identity backup and rollback controls behind different credentials, different approval paths, and a distinct administrative boundary from the live tenant.
- Maintain an immutable last trusted state Keep a continuously captured recovery copy that cannot be rewritten by the same account used to manage production identity changes.
- Test full-state restoration, not just file recovery Restore applications, federation relationships, and access paths in a controlled exercise so you know the identity platform can return to working trust.
- Review audit trails for post-compromise identity drift Check for new administrator tokens, group changes, backdoor users, and trust-path edits before declaring the platform safe again.
Key takeaways
- Patching closes the entry point, but it does not remove attacker-created identity changes or prove that trust has been restored.
- The core evidence here is that exploitation continued days after the fix, showing why recovery and patching are separate operating problems.
- An isolated, immutable, and tested recovery path is the control that determines whether IAM can return to a trustworthy state after compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Recovery authority must survive compromised admin access and prevent poisoned trust from persisting. |
| NHI-05 — Overprivileged NHI | The article centres on excessive administrative authority over identity recovery paths. | |
| Recommendation — Separate recovery authority from production access so compromised admins cannot rewrite rollback state. Reduce recovery-plane privileges so production admins cannot alter backup or rollback controls. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central to preventing production admin rights from controlling recovery. |
| Recommendation — Apply AC-6 to split recovery control from operational administration. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity recovery depends on controlling who can change trust state and rollback artefacts. |
| Recommendation — Review permissions that can alter trusted identity state and narrow them to separate recovery roles. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes token creation and downstream trust manipulation after administrative access. |
| Recommendation — Map post-compromise identity drift to credential access and lateral movement detection. | ||
Key terms
- Trusted recovery: Trusted recovery is the process of restoring identity services from a known-good state after disruption or compromise. It requires clean backup paths, clear restoration authority, and validation that the recovered system does not carry forward attacker changes or stale privileged access.
- Recovery Copy: A recovery copy is a preserved version of identity configuration, relationships, and supporting state that can be used to rebuild a service after failure. In this context, it must reflect real runtime state and sit outside the production blast radius so compromised administrators cannot casually alter it.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Identity State: Identity state is the live condition of an account, token, certificate, or permission set at a given moment. It matters because a task can be complete while the real access remains active, stale, or overprivileged. Security teams should validate identity state rather than relying only on process completion.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org