Actor token abuse in Entra ID exposes tenant-wide impersonation

At a glance

What this is: This is an analysis of how undocumented Entra ID actor tokens can be abused to impersonate users across tenants and evade normal access controls.

Why it matters: It matters because identity teams need to treat legacy delegation flows, standing admin access, and tenant-bound controls as one attack surface across NHI, human IAM, and privileged access programmes.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Fabrix Security's analysis of Entra ID actor token abuse and tenant impersonation

Context

Actor tokens are a legacy impersonation mechanism that allows one service to act on behalf of a user, but in this case weak tenant and issuer validation turned that delegation path into a cross-tenant impersonation problem. For IAM teams, the issue is not only token abuse, but the collapse of assumptions about where identity authority is supposed to stop.

The Entra ID case shows how deprecated API paths can outlive the controls that were meant to govern them. When Conditional Access, logging, and revocation do not apply consistently across the full identity path, the result is an identity plane that is partially observable and partially enforceable, which is enough for attackers to work around normal governance.

This is an IAM and NHI governance problem as much as a product flaw: any permanent or legacy impersonation path creates a privilege boundary that defenders may believe has already been retired. The article's starting position is atypical in scale, but the pattern it exposes is common in environments that keep old integration paths alive.

Key questions

Q: What breaks when legacy impersonation tokens can be used across tenants?

A: Tenant-scoped trust breaks first, because a token issued in one directory can be accepted as authority in another. That undermines Conditional Access, audit separation, and revocation assumptions at the same time. In practice, teams lose the ability to tell whether a privileged action came from a valid local identity or a mis-scoped delegation artefact.

Q: Why do deprecated identity APIs create disproportionate risk for IAM teams?

A: Deprecated APIs often keep old authentication semantics alive after the organisation has moved on to newer controls, which creates hidden trust paths. Those paths may bypass current policy, logging, or revocation models, so the risk is not just technical debt but active governance drift. A legacy API can become a bypass even when the modern platform is well managed.

Q: What do security teams get wrong about token-based persistence?

A: They often focus on account reset and miss the durable artefacts that survive a token compromise. Shadow applications, added service principal secrets, and hidden role assignments can preserve access even after the original token is gone. Effective containment requires finding the persistence layer, not only the entry point.

Q: Who is accountable when impersonation abuse bypasses directory controls?

A: Accountability sits across identity platform owners, application owners, and privileged access governance, because the failure usually spans token policy, API lifecycle, and role management. If the organisation allowed the legacy path to remain active, the control owner for that path is accountable for the exposure. If it was not inventoried, ownership is itself the gap.

Technical breakdown

Undocumented impersonation tokens and tenant binding

Actor tokens are unsigned JWTs used in a legacy delegation flow, meaning they can represent authority without the normal protections teams expect from modern token handling. In the described flaw, the critical failure was weak validation of issuer and tenant context in Azure AD Graph, so a token created in one tenant could be accepted in another. That breaks the basic assumption that identity assertions are scoped to the tenant where they were issued. Practical implication: retired delegation flows must be inventoried and removed, not just patched at the edge.

Practical implication: remove deprecated token paths and enforce strict tenant and issuer binding on every remaining delegation mechanism.

Why Conditional Access was bypassed

Conditional Access is only effective when the platform correctly recognises the identity event that should trigger policy evaluation. Here, the attacker used an actor token that appeared to come from a legitimate privileged identity, so the request could bypass policy decisions that would normally interrupt suspicious access. This is a classic example of control-plane mismatch: the policy engine was not the weak point, the identity assertion was. Practical implication: validate that policy enforcement covers legacy APIs, not only the modern authentication path.

Practical implication: test policy coverage against legacy APIs and impersonation paths, not only modern sign-in flows.

Persistence after tenant takeover

Once an attacker can impersonate a Global Admin, the technical problem shifts from initial abuse to durable control. The article notes options such as long-lived secrets on service principals, shadow applications with broad permissions, and hidden admin accounts. These are persistence mechanisms because they survive beyond the original forged token and make normal administrative change detection much harder. Practical implication: privileged app governance and service principal review must be treated as part of incident containment, not as a separate hygiene task.

Practical implication: inspect service principals, shadow apps, and hidden admin assignments as part of containment after any token impersonation event.

Threat narrative

Attacker objective: The attacker aims to achieve cross-tenant administrative impersonation that lets them take over Entra ID and establish persistent privileged access.

1. Entry occurs when the attacker obtains an Actor Token through a legacy service path in their own tenant, creating a legitimate-looking delegation artefact.
2. Credential abuse follows when the token is presented in the victim tenant despite weak issuer and tenant validation, allowing impersonation of users including Global Admins.
3. Impact occurs when the attacker uses that impersonation to alter policies, create durable access, and retain control through hidden secrets or shadow applications.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy impersonation paths become governance liabilities when tenant binding is no longer enforced. Actor tokens were designed for a narrow delegation condition, but that condition collapsed once tokens could be replayed across tenants. The result is not just a bug in validation, but a governance failure in how identity authority is scoped and retired. Practitioners should treat any undocumented impersonation mechanism as a control boundary until proven otherwise.

Conditional Access cannot compensate for a broken identity assertion. If the platform accepts a forged or mis-scoped token as a legitimate privileged session, policy evaluation happens too late to matter. This is why access policy, token semantics, and API deprecation have to be governed together rather than as separate tracks. The practical conclusion is that policy coverage must be verified against every legacy authentication and authorisation path.

Persistent admin change after token abuse is a service principal and shadow app problem, not just an account problem. The article shows how attackers turn a one-time impersonation into long-lived access by planting secrets and hidden permissions. That means the attack surface includes the lifecycle of non-human identities and privileged applications, not only user accounts. Practitioners should investigate app credentials and role assignments as first-class persistence artefacts.

Identity teams need to read this as an NHI governance issue with human blast radius. A forged service-mediated token can ultimately control human-facing services, from email to storage to directory policy. That cross-domain path is why NHI governance cannot sit apart from human IAM and PAM. When non-human delegation fails, the downstream impact lands on every identity programme that depends on it.

Legacy delegation debt: This breach exposes the risk created when retired authentication patterns remain reachable inside modern identity platforms. The debt is not only technical maintenance but governance ambiguity, because defenders assume the old path is no longer in scope while attackers still see a usable control bypass. The implication is that deprecation and lifecycle retirement must be treated as security controls, not housekeeping.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• That matters because The 52 NHI breaches Report shows how long-lived access artefacts turn one identity failure into repeated compromise.

What this signals

Legacy identity paths are now a lifecycle problem, not just a platform patching problem. If your programme still assumes that deprecated APIs disappear once a migration starts, the control model is already behind the attack surface. Teams should tie API decommissioning to identity lifecycle evidence, service principal review, and JIT admin enforcement, because residual delegation is where hidden access survives.

Tenant-bound trust needs to be tested as an assumption, not a feature claim. A platform can support modern controls and still fail if an older delegation path remains reachable. Identity architects should map where issuer, tenant, and policy enforcement are actually coupled, then verify those assumptions against legacy integrations and admin workflows.

With 97% of NHIs carrying excessive privileges, per our Ultimate Guide to NHIs, the real exposure is usually not the token alone but the authority attached to it. That makes JIT for privileged admin, service principal hygiene, and shadow app discovery the controls most likely to change the outcome. In this class of incident, blast radius is governed by entitlement shape more than by token format.

For practitioners

• Inventory every legacy impersonation and delegation path Map all services and APIs that still accept deprecated Azure AD Graph or similar legacy token flows, then remove or isolate them before relying on policy claims. Include any path that can mint or accept impersonation tokens outside your current control model.
• Verify tenant and issuer binding on all token acceptance points Test whether each identity boundary rejects tokens created in the wrong tenant or with mismatched issuer context, including old APIs, service integrations, and admin workflows. Treat a passing test as a prerequisite for continuing to operate the path.
• Eliminate permanent Global Admin standing privilege Move privileged administration to JIT access, then confirm that no long-lived Global Admin assignments remain in hidden accounts, shadow apps, or emergency break-glass paths that can be reached through impersonation.
• Audit service principals for persistence artefacts Search for long-lived secrets, newly added credentials, broad app permissions, and dormant admin-consent grants after any token abuse or directory anomaly. These are the post-compromise footholds that keep the attacker present after initial detection.
• Extend incident response to identity platform cleanup Make app credential review, admin role review, and directory policy review part of the containment checklist so the response does not stop at account reset. The goal is to remove the attacker’s ability to re-enter through identity artefacts.

Key takeaways

• Actor token abuse shows how a deprecated delegation path can turn tenant-scoped identity into cross-tenant administrative impersonation.
• The exposure is amplified when privileged identity paths remain undocumented, because Conditional Access and logging cannot reliably compensate for a broken trust boundary.
• Teams should remove legacy token acceptance, enforce tenant binding, and inspect service principals for persistence artefacts as part of identity incident response.

Key terms

• Actor Token: An actor token is a delegated identity artefact that allows one service to act on behalf of a user. In this incident pattern, the risk came from legacy handling that weakened issuer and tenant validation, turning a special-purpose mechanism into a cross-tenant impersonation path.
• Tenant Binding: Tenant binding is the control that ensures an identity token is only accepted in the directory where it was issued. When this binding is weak or absent, a token can be replayed in the wrong context, which breaks trust boundaries and can allow privileged impersonation.
• Shadow Application: A shadow application is an app registration or service principal that exists outside normal governance visibility or ownership. Attackers use it to keep access after the initial compromise by adding secrets, permissions, or hidden roles that look like routine administration.
• Standing Privilege: Standing privilege is persistent access that remains available without just-in-time approval or expiry. In identity attacks, it increases blast radius because attackers can inherit authority immediately once they obtain the right token, account, or delegated path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Fabrix Security: Exploiting Actor Tokens: High-Level Overview. Read the original.