Actor token forgery exposes a blind spot in Entra trust chains

At a glance

What this is: This is an analysis of Actor Token Forgery, a technique that turns compromised certificates and trusted service principals into impersonation tokens inside Microsoft Entra.

Why it matters: It matters because identity teams must govern certificates, app registrations, and delegation paths as security objects, not just authentication artifacts, across NHI, human, and hybrid identity programmes.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read SlashID's analysis of Actor Token Forgery and Entra trust abuse

Context

Actor token forgery exploits a core assumption in identity security: that delegated access flows can be trusted because the underlying service principal and certificate are trusted. In Microsoft Entra, that assumption is weakened when actor tokens, hybrid trust paths, and app credentials are treated as normal plumbing rather than governed identity assets.

For IAM and NHI teams, this is a certificate governance problem as much as an authentication problem. The article shows how forged tokens can be minted from legitimate trust chains, which means visibility, lifecycle control, and revocation discipline matter as much as MFA and conditional access.

That makes the topic relevant to hybrid Microsoft estates, privileged application access, and service-to-service delegation models. The starting position described in the article is unfortunately typical of modern enterprise trust design, not an edge case.

Key questions

Q: What breaks when service-to-service tokens can be forged in Entra?

A: The break is not just technical acceptance. It is governance visibility. When a trusted certificate can mint a token that looks legitimate to downstream services, the organisation loses reliable sign-in evidence, revocation becomes weak, and conditional access no longer represents the full control boundary for privileged access.

Q: Why do trusted service principals create more risk than ordinary app registrations?

A: Trusted service principals can impersonate identities across Microsoft workloads, so compromise of their signing material has a broader blast radius than a single app session. In hybrid environments, that trust can extend across Exchange, SharePoint, Graph, and related delegation paths, which makes certificate control a core identity security issue.

Q: How do security teams detect forged identity assertions in practice?

A: They compare the certificate thumbprint in the token against the registered keyCredentials set, monitor Add keyCredentials events, and correlate unusual Graph or mailbox access with recent credential changes. A mismatch is a strong indicator that the token was created outside the expected trust chain.

Q: Who is accountable when a managed identity is abused?

A: Accountability usually sits with the cloud and identity teams together. Platform owners control how the VM and metadata service are exposed, while IAM teams control RBAC scope and lifecycle review. If the identity can act beyond its workload’s purpose, the failure is governance, not just detection.

Technical breakdown

How actor tokens are issued inside Entra trust chains

Actor tokens are special delegated assertions issued by Microsoft services through Access Control Service and used to represent one identity acting on behalf of another. In the described flow, Exchange and SharePoint rely on a trust relationship that treats the token as valid without rechecking the original authentication event in the same way a user sign-in would be handled. That creates a blind spot: the token is accepted because the chain is trusted, not because each hop is independently observable. Once an attacker controls the signing material, the token becomes a reusable proof inside that trust boundary.

Practical implication: service principals and certificate-backed delegation paths need continuous inventory and review, not one-time configuration checks.

Why forged OAuth tokens can pass validation without MFA

A forged OAuth token can pass validation when it is signed with a trusted certificate or key that the target service already accepts. The article shows that the resulting token can look legitimate to Microsoft Graph, Exchange, SharePoint, and related apps because the issuer, audience, and signing chain align with expected values. MFA does not intervene here because there is no interactive login event to challenge. This is not a password problem. It is a delegated trust problem where the security boundary sits in certificate material and service principal permissions.

Practical implication: conditional access coverage alone is insufficient if certificate issuance, app registration, and key insertion are not tightly controlled.

Why service-to-service authentication creates a visibility gap

Service-to-service authentication was built to let trusted workloads exchange assertions without human friction, but that design suppresses many of the signals defenders rely on. The article notes no issuance logs for actor tokens, no usage logs in the usual sense, and no straightforward revocation path for the forged bearer token. That means compromise can persist inside the trusted path even while the tenant appears normal at the user layer. The architectural issue is not just lack of telemetry. It is that the trust model itself assumes the service boundary is safer than it may actually be.

Practical implication: correlate app-level activity, certificate changes, and mailbox or Graph access logs because identity logs alone will miss the abuse pattern.

Threat narrative

Attacker objective: The attacker wants durable, stealthy access to tenant data and privileged Microsoft workloads by impersonating trusted identities inside Entra.

1. Entry begins with compromise of a global admin account, exposed CI/CD token, or over-permissive app registration that gives the attacker a foothold in the tenant.
2. Escalation occurs when the attacker steals or injects a signing certificate, then uses Graph or ROADtools to mint actor tokens and impersonation tokens that inherit trusted delegation.
3. Impact follows when the forged token is used to access Microsoft Graph, Exchange, SharePoint, or OneDrive without MFA, interactive login, or normal Entra visibility.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Certificate trust without lifecycle control is the governance gap this attack exploits. The article shows that once signing material is present on a trusted service principal, the token chain can be abused without touching the user authentication layer. That means certificate issuance, key insertion, and app registration lifecycle are identity controls, not backend administration tasks. Practitioners should treat every trusted certificate as a governed credential with ownership, rotation, and offboarding.

Actor Token Forgery is not a password bypass, it is an assumption collapse in delegated identity design. The premise that access can be monitored and revoked at the token layer fails when the token is minted inside a trusted service-to-service path and never produces the usual sign-in evidence. That assumption was designed for human-paced authentication events and stable session boundaries. The implication is that Entra programmes must rethink what “observable access” means for delegated application trust.

Runtime privilege is the wrong control lens when the real issue is forged trust material. The attacker is not merely abusing excess privilege after authentication. They are manufacturing authentication evidence by compromising the certificate that proves service identity. That shifts the security question from “who got in?” to “which trust anchors can still mint acceptable identity assertions?” Practitioners should regard certificate provenance as part of the identity plane.

Hybrid Microsoft estates need a delegation-chain governance model, not isolated app security checks. Exchange, SharePoint, Graph, and on-prem hybrid components behave as one trust fabric when actor tokens are forwarded across them. If each component is reviewed independently, the chain can remain exploitable even when each individual service looks compliant. The practical conclusion is that identity governance must follow the delegation path across services, tenants, and trust boundaries.

Token logging gaps make this a detection problem as much as a prevention problem. The absence of issuance and usage logs for actor tokens means defenders cannot rely on user-centric telemetry to prove abuse. That is why integrity checks on keyCredentials, certificate thumbprints, and suspicious Add keyCredentials events matter so much. In practice, the control objective is to make forged trust material detectable before it becomes a stealth access path.

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 how slowly identity recovery can lag behind compromise.
• For a broader lifecycle lens, review Ultimate Guide to NHIs , Why NHI Security Matters Now alongside certificate governance controls.

What this signals

Actor Token Forgery turns certificate hygiene into an access-control issue. Teams that still separate app registration management from identity governance will miss the attack path entirely, because the signing key is the identity. The relevant shift is to manage trusted certificates, delegation scopes, and service principals as one governed control surface, especially where Microsoft Graph and hybrid Exchange are involved.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, delegation abuse becomes predictable rather than exotic. The lesson for practitioners is to reduce the number of apps that can mint identity assertions and tighten who can alter key material.

Delegation-chain governance: this is the control concept that matters here, because abuse often moves from certificate compromise to impersonation to cross-service access without leaving a normal sign-in trail. Identity teams should align detection, certificate rotation, and privileged app review around that chain rather than around individual services.

For practitioners

• Audit trusted delegation certificates Inventory every service principal with keyCredentials or preferredTokenSigningKeyThumbprint set, and flag certificates that are long-lived, unowned, or attached to high-privilege apps.
• Monitor certificate insertion events Alert on Add keyCredentials activity in AuditLogs, especially when a new certificate appears on Graph, Exchange, or other privileged applications without a matching entitlement change.
• Correlate app activity with identity telemetry Join mailbox, SharePoint, and Microsoft Graph access patterns with Entra audit data so service-to-service abuse can be detected even when standard sign-in logs are absent.
• Restrict delegated trust paths Minimise the number of applications trusted for delegation, remove unnecessary Application.ReadWrite.All permissions, and shorten certificate lifetimes so forged assertions have less time to operate.
• Validate token integrity against registered keys Compare token thumbprints and certificate metadata against the registered keyCredentials set, and treat unregistered signing material as a high-confidence compromise signal.

Key takeaways

• Actor Token Forgery shows that trusted certificates can become impersonation weapons when service-to-service delegation is not tightly governed.
• The impact is broad because forged tokens can bypass MFA, conditional access, and standard identity logs while still appearing legitimate to Microsoft services.
• The control that matters most is certificate and delegation lifecycle governance, backed by integrity checks and correlated telemetry across the identity stack.

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.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
• TrustedForDelegation: A trust setting that allows one service to present identity on behalf of another under a delegated model. It reduces friction for legitimate workloads, but it also creates a broad trust boundary that attackers can abuse if certificate material or app permissions are not controlled.
• Certificate Thumbprint: A fingerprint used to identify a specific signing certificate or key in token validation and inventory processes. When token thumbprints do not match registered key material, defenders have a strong signal that the assertion was created outside the expected trust chain.

What's in the full article

SlashID's full post covers the operational detail this post intentionally leaves for the source:

• ROADtools command flow showing how actor tokens and impersonation tokens are generated in practice.
• Audit and detection examples for Add keyCredentials events, including high-privilege app changes.
• Integrity-check methods for comparing token thumbprints to registered certificate metadata.
• Service-to-service abuse patterns across Exchange, SharePoint, Graph, and hybrid trust paths.

👉 SlashID's full post covers the attack flow, detection logic, and certificate governance gaps in detail.

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.