Actor token abuse in Entra ID exposes tenant-wide impersonation

At a glance

What this is: This is an analysis of CVE-2025-55241, where undocumented Actor tokens in Entra ID could be abused to impersonate users across tenants and evade normal logging and policy enforcement.

Why it matters: It matters because IAM teams must treat legacy delegation paths as governance debt, not just a patching issue, when they can bypass tenant boundaries, revocation, and auditability.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

Context

Microsoft Entra ID’s legacy Actor token flow shows how undocumented delegation paths can undermine identity controls that teams assume are tenant-bound. In this case, weak validation in the deprecated Azure AD Graph API let a token issued in one tenant be accepted in another, which turned a special delegation mechanism into an impersonation primitive.

For IAM and PAM programmes, the problem is not limited to patching a single flaw. When a legacy identity path can bypass Conditional Access, evade revocation, and leave little useful victim-side telemetry, governance has to cover migration off the path itself, not just the exploit surface.

The article’s starting position is atypical in one important sense: the abuse path depended on a deprecated API and undocumented token behaviour, but the governance lesson is typical for large identity estates where old delegation mechanisms survive long after their original security assumptions have expired.

Key questions

Q: What breaks when legacy tenant delegation paths are still active in Entra ID?

A: Legacy delegation paths can break tenant binding, revocation, and auditability at the same time. If a token or assertion is accepted outside its intended issuer and tenant context, an attacker can impersonate privileged users, bypass policy enforcement, and create persistence that looks like normal administration.

Q: Why does weak issuer validation create tenant-wide impersonation risk?

A: Because issuer validation is what keeps one tenant’s identity artefacts from being replayed into another tenant’s trust boundary. When that check fails, the token can be accepted as if it were local, which turns delegation into cross-tenant impersonation and makes downstream controls much less effective.

Q: How can security teams tell whether an identity path is still safe to keep?

A: A path is not safe if it depends on deprecated APIs, undocumented tokens, or trust assumptions that are no longer enforced in the platform. The practical test is whether the path still has clear tenant binding, clear revocation semantics, and enough logging to support investigation.

Q: What should teams do after a forged admin session in Entra ID?

A: Treat the session as the start of persistence hunting, not the end of the incident. Look for long-lived secrets, new service principals, hidden role grants, and any change that would let the attacker return without repeating the original exploit.

Technical breakdown

How Actor tokens turn delegation into impersonation

Actor tokens are an undocumented delegation construct that let a service act on behalf of a user. In normal identity design, delegation should remain constrained by issuer, tenant, and audience checks. Here, the attack primitive worked because the token itself was accepted as a special authorisation artefact rather than treated as a tightly bound identity assertion. That meant the same object could be presented with different contextual claims than the issuer intended. Practical implication: treat undocumented delegation tokens as identity debt until they are fully removed from production paths.

Practical implication: inventory and eliminate undocumented delegation flows before they become impersonation channels.

Why weak tenant and issuer validation mattered

The Azure AD Graph API accepted the token without strictly verifying that the issuer and tenant matched the request context. That broke the binding that normally prevents one tenant’s artefacts from being replayed into another tenant’s trust boundary. Because the token was also unsigned, revocation-resistant during its validity window, and able to bypass Conditional Access, the validation gap became an end-to-end trust failure rather than a single parsing bug. Practical implication: tenant-bound identity assertions need context checks at the API edge, not just token issuance controls.

Practical implication: remove any identity path that does not enforce issuer, tenant, and audience binding end to end.

How persistence followed privileged impersonation

Once the attacker could impersonate a Global Admin, the issue shifted from access to durable control. The article describes adding long-lived secrets to service principals, creating shadow apps with broad permissions, and granting permanent admin roles to hidden accounts. Those changes are dangerous because they blend into ordinary administrative activity unless the programme has strong change detection and privilege hygiene. Practical implication: monitor for identity-state changes that outlive a normal admin session and look for hidden persistence artifacts in Entra ID.

Practical implication: watch for post-compromise changes that create standing privilege or hidden application trust.

Threat narrative

Attacker objective: The attacker’s objective was to impersonate privileged users across tenants, take over Entra ID, and establish durable administrative persistence.

1. Entry occurred when the attacker obtained an Actor token in their own tenant through a legacy flow that still supported the undocumented delegation mechanism. The victim tenant had no direct visibility into that issuance event.
2. Credential abuse followed when the attacker presented the token to the deprecated Azure AD Graph API with a victim tenant ID and discovered user identifier. Weak issuer and tenant validation let the token be accepted in the wrong context.
3. Escalation happened when the attacker forged an impersonation token for a Global Admin, bypassed Conditional Access, and gained the ability to perform read and write actions across Entra ID.
4. Impact came through durable backdoors such as long-lived secrets, shadow apps, and permanent admin roles that could survive the original compromise and complicate cleanup.

Breaches seen in the wild

• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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 delegation becomes identity debt the moment it outlives tenant binding. Actor tokens were designed for a special delegation path, but that design assumed issuer and tenant checks would remain trustworthy. Once the Azure AD Graph API stopped enforcing those boundaries strictly, the token stopped being a controlled delegation artefact and became an impersonation primitive. The practitioner lesson is that undocumented identity paths cannot be allowed to survive as normal operations.

Conditional Access cannot compensate for a token that is accepted in the wrong trust domain. This attack bypassed policy because the authorization decision happened after the trust boundary had already failed. That means Conditional Access was not the missing control in the first place; tenant and issuer validation were. IAM teams should read this as a warning that policy layers are only as strong as the binding underneath them.

Tenant-wide impersonation creates a governance blind spot, not just a breach event. The article shows that token creation was logged in the attacker’s tenant, while the victim tenant saw little useful evidence. That separation breaks normal audit assumptions and weakens incident reconstruction. The implication is that auditability must be designed around cross-tenant delegation artefacts, not assumed from local logs.

Standing privilege after impersonation is the real persistence vector. The article’s persistence phase shows how attackers translate temporary impersonation into durable control by planting secrets, apps, and hidden admin roles. That is a classic governance failure in which short-lived abuse is converted into long-lived authority. Teams should treat post-compromise identity-state change as the main containment problem.

Actor token abuse is a named example of tenant-boundary collapse. The specific failure mode is not merely token theft or weak authentication. It is the collapse of the assumption that delegation remains constrained to a single tenant and a single issuer context. Practitioners need to rethink which legacy identity mechanisms still depend on that assumption and remove them before they are exploited again.

From our research library:

• Impersonation fraud accounted for over 85% of all fraud attacks in 2025.
• Read next: Top 10 NHI Issues

What this signals

Tenant-boundary collapse: The deeper issue here is not just token misuse, but the failure of identity governance to survive a deprecated trust path. When a legacy delegation mechanism can be accepted in the wrong tenant, the control problem moves from authentication into trust boundary enforcement and evidence quality.

Programmes that still rely on long-tail identity integrations should expect this class of issue to surface again wherever issuer validation, revocation, and audit trails are split across old and new APIs. The right programme response is to treat migration off unsupported identity paths as governance work, not only technical debt reduction.

For practitioners

• Audit and remove legacy delegation paths Identify any remaining flows that depend on Azure AD Graph or undocumented impersonation behaviour, then decommission them in favour of Microsoft Graph and supported identity patterns.
• Enforce zero standing Global Admin privilege Replace permanent Global Admin assignments with JIT elevation, and verify that no admin role remains continuously active without a time bound.
• Validate tenant and issuer binding at the API edge Review identity integrations to ensure issuer, audience, and tenant context are checked before a token can be accepted for authorization.
• Hunt for persistence artifacts after impersonation Search for long-lived secrets, shadow applications, and hidden admin role grants that could have been created during a forged admin session.
• Increase logging coverage for cross-tenant delegation Correlate identity events from both the issuing tenant and the consuming tenant so token creation, use, and privilege changes can be reconstructed.

Key takeaways

• The article shows how undocumented Actor tokens became a cross-tenant impersonation path once tenant and issuer validation were not enforced.
• The attack mattered because it could bypass Conditional Access, affect Global Admins, and leave the victim tenant with little useful logging.
• The most relevant control failure was tenant-bound identity validation, followed by removal of legacy delegation paths that can still create standing privilege.

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.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

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.