Look Beyond the Original Credential
Identity incident recovery is the work of finding and correcting every access change an attacker made inside Okta, Microsoft Entra ID or another identity provider, not only revoking the credential they used to get in. Revoking a token closes the entry point. It doesn’t account for what changed while the attacker was inside.
On September 10, 2026, Anthropic published Detecting and countering misuse of AI: September 2026. Its case study GTG-50014: ShinyHunters smash-and-grab opportunists describes several operations involving suspected ShinyHunters affiliates.
One compromise progressed from a stolen developer token to full administrative control of a victim’s cloud environment in roughly three hours. Anthropic describes that incident on page 14. This was a specific reported compromise, not an average attack timeline.
The report covers selected notable cases disrupted between December 2025 and August 2026, not a representative sample of all attacks. For an IAM team, the question is what happened while the attacker had access. Revoking the original credential matters. It does not account for every permission, account or configuration change made during the intrusion.
In GTG-20006: Russian espionage, the “Maintaining access” finding on page 9 describes AI helping the attacker register devices it controlled in victims’ tenants. The GTG-50014 case study describes another persistence pattern: Figure 9, “Mint/persist,” on page 19 explains how attackers created additional credentials and lasting access intended to survive credential rotation.
These are separate cases, but they raise the same question for responders: after closing the entry point, have you accounted for the access established afterward? The GTG labels identify actors tracked by Anthropic, not individual incident numbers.
A Payroll Application, an Intrusion and a Legitimate Release
Consider a hypothetical incident involving a payroll application connected to Okta. This is an illustrative scenario, not an incident documented by Anthropic.
The security team identifies a stolen administrative credential and revokes it. During the investigation, the IAM team discovers that a sign-on policy was weakened and an account was added to a group with privileged access to the payroll application.
Meanwhile, another administrator deployed an approved application update. The security team also disabled a suspect account as part of containment. Some changes belong to the attacker, one belongs to a legitimate release, and another is part of the response.
A list of changes is useful. It is not yet a recovery plan.
Correct the Damage Without Undoing Containment
The team needs to compare the affected configuration with earlier versions, review the approvals and establish which relationships changed. The account named in an event identifies the credential used, but the investigation still needs to determine whether its use was legitimate. The review should reach back to the first suspicious activity, rather than assume the first alert marks the start of the compromise.
Returning everything to yesterday’s state would be the wrong objective. It could remove the legitimate application update or reactivate the account disabled during containment. The intended outcome is more specific: remove the unwanted access, restore the reviewed sign-on settings, preserve the approved release and keep the suspect account disabled.
That distinction matters when choosing between an individual correction, bulk recovery and a broader rollback. The scope should follow the evidence, not simply the number of changes found.
Before execution, the reviewer should see what will change and which related objects could be affected. The plan also needs a final check against the live environment. Someone may have made another legitimate change while the investigation was underway.
After the correction, read the resulting configuration again and test the affected access. The payroll team should retain the access it needs. The unwanted access should no longer be granted. Keep the before-and-after values, the approval and the access-test results alongside the completed job.
Choose a Recovery Point You Can Explain
In GTG-50029: Hacktivists targeted European political and affiliated entities, Anthropic describes a campaign observed in spring 2026. On page 35, it reports that the attacker poisoned a victim’s backups, presumably to maintain access, and explains that restoring them would have reintroduced the infection. This was a website compromise involving WordPress components, not a reported compromise of an Okta, Microsoft Entra ID or Auth0 backup.
The lesson for identity teams is about choosing the recovery state. In the payroll scenario, a backup taken after the group membership was added could contain that membership. Restoring it successfully would not solve the access problem.
Why does the team trust this version of the policy, these assignments and these related objects? What evidence places them before the unwanted change? Which later changes should remain? Where the evidence is incomplete, that uncertainty belongs in the recovery plan.
Immutability protects a retained copy from alteration. It does not establish that its original contents were appropriate. Proving that an object can be restored is also different from deciding that restoring it is the right response.
A successful restore of the wrong state is still the wrong outcome.
Where Acsense Helps With Identity Recovery
This is where preserved identity history becomes useful during the incident, not just after someone decides to perform a restore. Acsense’s investigation tools let teams compare historical and current versions of supported identity objects and inspect related entities. Recovery can include an individual object and its associations. For broader Okta incidents, tenant rollback supports reviewing and selecting the changes to include.
For the payroll investigation, that gives the IAM team a way to examine the configuration change and its relationships before choosing a recovery action. It reduces the amount of reconstruction the team has to do while the incident is already in progress.
The response still needs to match the provider and object involved. Acsense’s September 14, 2026 feature support matrix lists per-object rollback and bulk recovery for Okta and Microsoft Entra ID, with partial object-type coverage for Auth0. A supported provider does not mean every object supports every operation.
Protection Framework is designed to use that history for controlled correction: prepare a specific response, recheck the current state, preserve unrelated changes and verify the result. These principles do not mean every response should run automatically. Controls and automated actions depend on the release, provider and object type.
For Okta, the Recoverability Report adds background recovery-check results, including validated objects, issues, skipped objects and measured recovery time. These results help teams identify recovery problems before an incident. They do not establish whether a particular historical configuration should be trusted.
This is the identity-configuration part of the response, not proof that every credential, endpoint or downstream application is clean. The team still needs evidence for those parts of the incident. Restoring configuration also cannot undo information already stolen.
Practice the Decision, Not Just the Restore
Reproduce the payroll scenario in a test environment as part of your disaster recovery testing. Introduce an unwanted access change alongside an approved application update. Add a deliberate containment action, such as disabling a test account. Then ask the team to investigate, prepare a recovery plan and answer five questions:
- Separating changes: can they identify the unwanted change without discarding the legitimate one?
- Trusted state: can they explain why they trust the selected recovery state?
- Containment: does the plan keep containment actions, such as the disabled account, in place?
- Verified access: can they demonstrate the resulting access after the correction?
- Coverage gaps: can they identify anything the recovery tools do not cover?
Record how long it takes to answer those questions, not only how long the restore job runs.
“We revoked the token” is an important update. Before closing the identity part of the incident, the team should also be able to say what changed, what it repaired and how it checked the result.
Frequently Asked Questions
Does revoking a compromised token remove the attacker’s access?
Not necessarily. Revocation blocks that credential, but permissions, group memberships, registered devices, policy changes or additional credentials created during the intrusion can remain. Anthropic’s September 2026 report describes attackers deliberately creating access intended to survive credential rotation.
Why not roll the identity tenant back to the day before the incident?
A blanket rollback can remove legitimate changes made during the same window, such as an approved application release, and can reactivate accounts disabled during containment. Recovery scope should follow the evidence, not the calendar.
Can restoring a backup reintroduce the compromise?
Yes. A backup taken after an unwanted change contains that change. Immutability protects a copy from being altered, but it doesn’t prove the contents were trustworthy when the copy was taken, so teams need evidence that a recovery point predates the unwanted change.
Which identity providers does Acsense support for recovery?
As of Acsense’s September 14, 2026 feature support matrix, per-object rollback and bulk recovery are listed for Okta and Microsoft Entra ID, with partial object-type coverage for Auth0. Tenant rollback with selectable changes is available for broader Okta incidents. Supported operations vary by object type.
