How Far Can One Stolen Identity Reach?

What Is the Reach of a Stolen Identity?

The reach of a stolen identity is everything that account can change after it signs in: its roles, group memberships, application assignments, and the permissions granted inside each application, cloud service, or API it can reach. Network segmentation does not limit it, because a firewall governs which connections are allowed, not what a valid identity is authorized to do.

A Practical IAM Check

The Real Problem

The Network Was Locked Down. The Account Still Had Access.

Picture an automation account that connects two business applications. Someone steals its credential. The attacker cannot reach much through the internal network, which is good. But the account also has a privileged role in the identity provider and access to several cloud applications. Those permissions still work. The network controls have not failed. They were never meant to govern all of that access.

This is a hypothetical example, not an incident at JPMorgan. But it is the sort of situation an IAM team should be able to answer questions about before it happens.

Jamie Dimon recently warned that AI will help attackers find weaknesses faster. In the same conversation, he pushed companies to strengthen network segmentation, pay attention to IAM, and fix the problems they already know about. The IAM part deserves more attention than it usually gets.

A firewall tells you which connections are allowed. It does not tell you what a valid cloud identity is authorized to do after it signs in. If an integration has permission to add users, change a policy, or assign a powerful role, an attacker who gets that identity may be able to do those things too.

And this is rarely a neat one-to-one setup. An account created for one integration can pick up another role during a migration. A group gets reused. Somebody grants an exception to get a deployment out the door. Six months later, nobody is quite sure which permissions are still needed.

You do not need a major incident to find this problem. Pick a service account and follow its permissions. The uncomfortable surprises tend to be in the relationships between accounts, groups, roles, and applications, not in the account name itself.

Start With One Account

What Can This Identity Actually Change?

Choose one integration account that matters to the business. Not your most complicated one. Pick something that touches a critical application and has a real owner, or should have one. Then open the IdP and trace its group memberships, assigned roles, application access, and authentication methods.

Now call the application owner. Ask what that same identity can do inside the application. The IdP may show that an application is assigned, but it will not necessarily tell you every permission the application grants. Do the same for any cloud service or API it can reach.

You should be able to write down four answers without spending a week on an access review:

During an incident, disabling the account or revoking its token may be necessary. It is not always the end of the job. The attacker may already have added another credential, assigned a different administrator, or changed access for somebody else. Those changes need to be found and dealt with separately.

When the Cleanup Starts

Stopping the Attacker Does Not Undo the Changes

Say the security team finds a compromised automation account and disables it. Good first move. Then IAM discovers that a privileged group gained a new member and an application policy changed during the same window. Which version of those settings should the team put back?

This is where having identity history makes a difference. Acsense preserves point-in-time copies of supported identity objects and relationships in Okta, Microsoft Entra ID, and Auth0. IAM teams can compare earlier configurations with the current state, review what changed, and choose the specific objects or relationships to recover where that recovery is supported. Coverage varies by provider and object type.

There is another problem to plan for: what if the attacker also has administrator credentials? You cannot rely on a recovery record the attacker can rewrite. Acsense Vault keeps immutable recovery copies in an isolated, air-gapped environment. The intent is straightforward: compromising a privileged account should not let somebody go back and change the copies you need for recovery.

Access to the recovery system matters too. If your IdP is unavailable, it should not be your only way into the tools you need to restore it. Acsense recommends separate recovery access rather than relying solely on the customer IdP. Backup data integrity is checked every two weeks. That helps protect the recovery starting point, although it is not the same thing as proving a particular recovery point was safe.

The response still takes people making decisions. Security contains the attacker and checks for other access paths. IAM works with application owners to decide which earlier state was legitimate. Acsense supports the agreed recovery work for supported configurations, users, groups, policies, and assignments. Then the team checks the resulting IdP configuration and tests access to the applications that matter.

Not everything lives in the IdP. An application-side permission, token, secret, or trust setting may need separate work. You also do not want to restore a bad configuration just because it is older. The goal is not to make the screen look like yesterday. It is to put back the access the business actually intended.

Try This in Your Next IAM Meeting

A 40-Minute Test Worth Running

At the end, you should know where one identity has too much reach, which permissions need a second owner, and how long it takes your team to find and reverse a bad change. That is more useful than simply counting how many accounts were reviewed.

AI may make finding weaknesses faster. Your team can still decide how much a stolen identity can do, keep a reliable record of changes, and practice getting the right access back before an incident forces the issue.