top of page

Actor Tokens Unmasked: The Hidden Microsoft Entra ID Weakness Threatening Cloud Security

Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), has long been the cornerstone of identity and access management (IAM) across the Microsoft ecosystem. Powering secure authentication for Microsoft 365, Azure resources, and thousands of third-party applications, Entra ID underpins identity security for enterprises worldwide. In September 2025, disclosures by independent researchers revealed CVE-2025-55241—a critical vulnerability that allowed attackers to impersonate Global Administrators across virtually any Entra ID tenant. This flaw combined undocumented “Actor tokens” with a validation weakness in the legacy Azure AD Graph API. Together, these issues shattered one of the most important assumptions of cloud security: tenant isolation. This article examines the vulnerability’s technical underpinnings, its far-reaching implications, and what organizations can do to protect themselves. Understanding Microsoft Entra ID and Tenant Isolation Entra ID is Microsoft’s cloud-based IAM service that provides single sign-on (SSO), multi-factor authentication (MFA), and security controls across apps and resources. Each tenant in Entra ID represents a single organization, managing user identities, roles, and permissions across: Microsoft 365 applications (Exchange Online, SharePoint, Teams) Custom enterprise applications Third-party SaaS products such as Salesforce, Dropbox, Google Workspace, and SAP Hybrid on-premises environments Tenant isolation is the principle that one organization’s identity environment remains completely separate from another’s. This separation ensures that even if one tenant is compromised, other tenants remain unaffected. CVE-2025-55241 disrupted this foundational security model. Actor Tokens: The Invisible Keys to the Kingdom The first component of the vulnerability involved Actor tokens, a type of JSON Web Token (JWT) issued by Microsoft’s legacy Access Control Service (ACS). These tokens are intended to facilitate service-to-service communication within Microsoft’s own infrastructure—particularly for Exchange Online and SharePoint. Key characteristics that made Actor tokens dangerous: Unsigned and Unrevocable: Lacking cryptographic signatures, Actor tokens could be forged or manipulated without detection. They also had a fixed 24-hour validity and could not be revoked during that period. Trusted for Delegation: Actor tokens included a “trustedfordelegation” claim, allowing them to impersonate any user in a tenant—including Global Administrators—without requiring user credentials or explicit consent. No Logging or Telemetry: Issuance and usage of Actor tokens were not logged within target tenants. Conditional Access policies were bypassed entirely, eliminating one of the primary defense layers. Dirk-jan Mollema, the security researcher who uncovered this flaw, called Actor tokens “something that never should have existed” due to their lack of basic security controls. The Azure AD Graph API Flaw: Breaking Cross-Tenant Boundaries The second component of CVE-2025-55241 was a validation weakness in the Azure AD Graph API (graph.windows.net)—a legacy interface used by many Microsoft internal services. Although officially deprecated, Azure AD Graph remained widely integrated into enterprise environments. During testing, Mollema discovered that the API failed to validate tenant IDs on incoming impersonation tokens. This meant an attacker could: Use an Actor token from their own (controlled) tenant. Construct an impersonation token for a user in a different tenant. Submit requests to Azure AD Graph as that user. Access or modify sensitive data—including Global Admin-level operations—in the target tenant. Initially expecting an “access denied” message, Mollema instead observed that the API treated his cross-tenant token as valid but flagged the identity as “not found.” By substituting a valid user ID (netId) from the target tenant, he gained full access to tenant data. This flaw effectively bypassed Microsoft’s tenant isolation model, opening the door to silent, large-scale compromise across multiple organizations. What Data Was at Risk? The combined use of Actor tokens and Azure AD Graph API’s flawed validation exposed a wide array of sensitive assets: User profiles, email addresses, and personal details Group memberships, roles, and privileged accounts Tenant configurations, Conditional Access policies, and MFA settings Application registrations and API permissions BitLocker recovery keys and security configurations for endpoint devices Because read operations in Azure AD Graph generated no logs, attackers could exfiltrate data invisibly. Even some write actions appeared to originate from legitimate Global Admins, further obscuring malicious activity. Proof of Concept: How an Attacker Could Exploit CVE-2025-55241 Mollema’s proof of concept showed that the prerequisites for exploitation were minimal: Tenant ID: Publicly obtainable from domain information or APIs. netId: A legacy identifier present in access tokens, sometimes exposed through B2B (business-to-business) relationships. Attack Flow Example: Generate an Actor token from an attacker-controlled tenant. Discover the target tenant’s ID and a valid netId of a user. Craft an impersonation token embedding the Actor token, tenant ID, and netId. Use Azure AD Graph to impersonate that user. Enumerate Global Admin accounts and escalate privileges. Perform read/write operations (reset passwords, create admins, exfiltrate data). A particularly effective method leveraged guest or B2B trust relationships: a user from Tenant B invited into Tenant A leaves their netId stored in Tenant A. An attacker with access to Tenant A could extract that netId to impersonate the user in Tenant B. Timeline of Disclosure and Microsoft’s Response Date (2025) Event July 14 Vulnerability reported to Microsoft by Dirk-jan Mollema. July 17 Microsoft deploys an initial global fix. August 6 Further mitigations rolled out to restrict cross-tenant token usage. September 4 CVE-2025-55241 officially published. September 17 Full technical details disclosed to the public. Microsoft’s mitigations included: Blocking Actor tokens from being used cross-tenant via Azure AD Graph. Restricting issuance of Actor tokens with Service Principal credentials. Enhancing detection for anomalous administrative operations. Although Microsoft stated no exploitation had been detected, the stealthy nature of the vulnerability leaves room for uncertainty. Detection and Defense: Lessons for Organizations While read operations through Azure AD Graph left no trace, security teams can monitor for anomalies in write actions. Indicators of Actor token misuse may include: Audit logs showing a user principal name (UPN) but an application display name such as “Exchange Online.” Global Admin actions initiated by service principals rather than real users. Sudden creation or deletion of privileged accounts outside normal workflows. Researchers developed sample Kusto Query Language (KQL) detection rules to help organizations identify suspicious activity in Microsoft 365 and Azure environments. A layered defense strategy should also include: Deprecation of Legacy APIs: Audit and migrate applications away from Azure AD Graph to Microsoft Graph API. Tightening B2B Trust: Limit guest access and monitor netId usage across tenants. Conditional Access Reviews: Even though Actor tokens bypass Conditional Access, ensuring strong policies reduces risk for other token types. Privileged Identity Management (PIM): Use just-in-time elevation for administrative roles to minimize exposure windows. Broader Implications for Cloud Security CVE-2025-55241 highlights several systemic issues in modern cloud security: Legacy Components as Weak Links: Even deprecated APIs can introduce critical risks if not fully retired. Token-Based Architectures: While powerful for scalability, tokens lacking cryptographic safeguards can become silent backdoors. Cross-Tenant Complexity: B2B and guest relationships create unexpected identity flows that attackers can exploit. As one cloud security architect noted, “This vulnerability isn’t just about Microsoft. It’s about how all multi-tenant platforms manage trust boundaries, legacy interfaces, and silent impersonation mechanisms.” Conclusion: Building Resilience After CVE-2025-55241 The Actor token flaw in Microsoft Entra ID underscores the urgency for organizations to reassess their identity security strategies. Tenant isolation—the bedrock of multi-tenant cloud security—can be undermined by overlooked legacy systems and opaque internal mechanisms. For enterprises, this incident is a wake-up call: Audit reliance on deprecated services like Azure AD Graph. Strengthen detection capabilities for privileged actions. Reevaluate cross-tenant trust and guest user policies. Organizations seeking expert guidance on identity security can look to leading analysts and research teams like Dr. Shahid Masood, Dr Shahid Masood, and the specialists at 1950.ai, who provide deep insights into emerging threats and architectural best practices for securing multi-tenant environments. By combining proactive migration away from legacy APIs with advanced monitoring for anomalous behavior, businesses can significantly reduce their risk exposure—and rebuild trust in the security of their cloud identity infrastructure. Further Reading / External References Microsoft Entra ID flaw allowed hijacking any company’s tenant (BleepingComputer) CVE-2025-55241 Exposes Entra ID Admin Access (The Cyber Express) Microsoft Entra ID Flaw Enables Cross-Tenant Attacks (Petri)

Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), has long been the cornerstone of identity and access management (IAM) across the Microsoft ecosystem. Powering secure authentication for Microsoft 365, Azure resources, and thousands of third-party applications, Entra ID underpins identity security for enterprises worldwide.


In September 2025, disclosures by independent researchers revealed CVE-2025-55241—a critical vulnerability that allowed attackers to impersonate Global Administrators across virtually any Entra ID tenant. This flaw combined undocumented “Actor tokens” with a validation weakness in the legacy Azure AD Graph API. Together, these issues shattered one of the most important assumptions of cloud security: tenant isolation.


This article examines the vulnerability’s technical underpinnings, its far-reaching implications, and what organizations can do to protect themselves.


Understanding Microsoft Entra ID and Tenant Isolation

Entra ID is Microsoft’s cloud-based IAM service that provides single sign-on (SSO), multi-factor authentication (MFA), and security controls across apps and resources. Each tenant in Entra ID represents a single organization, managing user identities, roles, and permissions across:

  • Microsoft 365 applications (Exchange Online, SharePoint, Teams)

  • Custom enterprise applications

  • Third-party SaaS products such as Salesforce, Dropbox, Google Workspace, and SAP

  • Hybrid on-premises environments


Tenant isolation is the principle that one organization’s identity environment remains completely separate from another’s. This separation ensures that even if one tenant is compromised, other tenants remain unaffected. CVE-2025-55241 disrupted this foundational security model.


Actor Tokens: The Invisible Keys to the Kingdom

The first component of the vulnerability involved Actor tokens, a type of JSON Web Token (JWT) issued by Microsoft’s legacy Access Control Service (ACS). These tokens are intended to facilitate service-to-service communication within Microsoft’s own infrastructure—particularly for Exchange Online and SharePoint.


Key characteristics that made Actor tokens dangerous:

  • Unsigned and Unrevocable: Lacking cryptographic signatures, Actor tokens could be forged or manipulated without detection. They also had a fixed 24-hour validity and could not be revoked during that period.

  • Trusted for Delegation: Actor tokens included a “trustedfordelegation” claim, allowing them to impersonate any user in a tenant—including Global Administrators—without requiring user credentials or explicit consent.

  • No Logging or Telemetry: Issuance and usage of Actor tokens were not logged within target tenants. Conditional Access policies were bypassed entirely, eliminating one of the primary defense layers.


Dirk-jan Mollema, the security researcher who uncovered this flaw, called Actor tokens “something that never should have existed” due to their lack of basic security controls.


The Azure AD Graph API Flaw: Breaking Cross-Tenant Boundaries

The second component of CVE-2025-55241 was a validation weakness in the Azure AD Graph API (graph.windows.net)—a legacy interface used by many Microsoft internal services. Although officially deprecated, Azure AD Graph remained widely integrated into enterprise environments.


During testing, Mollema discovered that the API failed to validate tenant IDs on incoming impersonation tokens. This meant an attacker could:

  1. Use an Actor token from their own (controlled) tenant.

  2. Construct an impersonation token for a user in a different tenant.

  3. Submit requests to Azure AD Graph as that user.

  4. Access or modify sensitive data—including Global Admin-level operations—in the target tenant.


Initially expecting an “access denied” message, Mollema instead observed that the API treated his cross-tenant token as valid but flagged the identity as “not found.” By substituting a valid user ID (netId) from the target tenant, he gained full access to tenant data.

This flaw effectively bypassed Microsoft’s tenant isolation model, opening the door to silent, large-scale compromise across multiple organizations.


What Data Was at Risk?

The combined use of Actor tokens and Azure AD Graph API’s flawed validation exposed a wide array of sensitive assets:

  • User profiles, email addresses, and personal details

  • Group memberships, roles, and privileged accounts

  • Tenant configurations, Conditional Access policies, and MFA settings

  • Application registrations and API permissions

  • BitLocker recovery keys and security configurations for endpoint devices


Because read operations in Azure AD Graph generated no logs, attackers could exfiltrate data invisibly. Even some write actions appeared to originate from legitimate Global Admins, further obscuring malicious activity.


Proof of Concept: How an Attacker Could Exploit CVE-2025-55241

Mollema’s proof of concept showed that the prerequisites for exploitation were minimal:

  • Tenant ID: Publicly obtainable from domain information or APIs.

  • netId: A legacy identifier present in access tokens, sometimes exposed through B2B (business-to-business) relationships.


Attack Flow Example:

  1. Generate an Actor token from an attacker-controlled tenant.

  2. Discover the target tenant’s ID and a valid netId of a user.

  3. Craft an impersonation token embedding the Actor token, tenant ID, and netId.

  4. Use Azure AD Graph to impersonate that user.

  5. Enumerate Global Admin accounts and escalate privileges.

  6. Perform read/write operations (reset passwords, create admins, exfiltrate data).


A particularly effective method leveraged guest or B2B trust relationships: a user from Tenant B invited into Tenant A leaves their netId stored in Tenant A. An attacker with access to Tenant A could extract that netId to impersonate the user in Tenant B.

Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), has long been the cornerstone of identity and access management (IAM) across the Microsoft ecosystem. Powering secure authentication for Microsoft 365, Azure resources, and thousands of third-party applications, Entra ID underpins identity security for enterprises worldwide. In September 2025, disclosures by independent researchers revealed CVE-2025-55241—a critical vulnerability that allowed attackers to impersonate Global Administrators across virtually any Entra ID tenant. This flaw combined undocumented “Actor tokens” with a validation weakness in the legacy Azure AD Graph API. Together, these issues shattered one of the most important assumptions of cloud security: tenant isolation. This article examines the vulnerability’s technical underpinnings, its far-reaching implications, and what organizations can do to protect themselves. Understanding Microsoft Entra ID and Tenant Isolation Entra ID is Microsoft’s cloud-based IAM service that provides single sign-on (SSO), multi-factor authentication (MFA), and security controls across apps and resources. Each tenant in Entra ID represents a single organization, managing user identities, roles, and permissions across: Microsoft 365 applications (Exchange Online, SharePoint, Teams) Custom enterprise applications Third-party SaaS products such as Salesforce, Dropbox, Google Workspace, and SAP Hybrid on-premises environments Tenant isolation is the principle that one organization’s identity environment remains completely separate from another’s. This separation ensures that even if one tenant is compromised, other tenants remain unaffected. CVE-2025-55241 disrupted this foundational security model. Actor Tokens: The Invisible Keys to the Kingdom The first component of the vulnerability involved Actor tokens, a type of JSON Web Token (JWT) issued by Microsoft’s legacy Access Control Service (ACS). These tokens are intended to facilitate service-to-service communication within Microsoft’s own infrastructure—particularly for Exchange Online and SharePoint. Key characteristics that made Actor tokens dangerous: Unsigned and Unrevocable: Lacking cryptographic signatures, Actor tokens could be forged or manipulated without detection. They also had a fixed 24-hour validity and could not be revoked during that period. Trusted for Delegation: Actor tokens included a “trustedfordelegation” claim, allowing them to impersonate any user in a tenant—including Global Administrators—without requiring user credentials or explicit consent. No Logging or Telemetry: Issuance and usage of Actor tokens were not logged within target tenants. Conditional Access policies were bypassed entirely, eliminating one of the primary defense layers. Dirk-jan Mollema, the security researcher who uncovered this flaw, called Actor tokens “something that never should have existed” due to their lack of basic security controls. The Azure AD Graph API Flaw: Breaking Cross-Tenant Boundaries The second component of CVE-2025-55241 was a validation weakness in the Azure AD Graph API (graph.windows.net)—a legacy interface used by many Microsoft internal services. Although officially deprecated, Azure AD Graph remained widely integrated into enterprise environments. During testing, Mollema discovered that the API failed to validate tenant IDs on incoming impersonation tokens. This meant an attacker could: Use an Actor token from their own (controlled) tenant. Construct an impersonation token for a user in a different tenant. Submit requests to Azure AD Graph as that user. Access or modify sensitive data—including Global Admin-level operations—in the target tenant. Initially expecting an “access denied” message, Mollema instead observed that the API treated his cross-tenant token as valid but flagged the identity as “not found.” By substituting a valid user ID (netId) from the target tenant, he gained full access to tenant data. This flaw effectively bypassed Microsoft’s tenant isolation model, opening the door to silent, large-scale compromise across multiple organizations. What Data Was at Risk? The combined use of Actor tokens and Azure AD Graph API’s flawed validation exposed a wide array of sensitive assets: User profiles, email addresses, and personal details Group memberships, roles, and privileged accounts Tenant configurations, Conditional Access policies, and MFA settings Application registrations and API permissions BitLocker recovery keys and security configurations for endpoint devices Because read operations in Azure AD Graph generated no logs, attackers could exfiltrate data invisibly. Even some write actions appeared to originate from legitimate Global Admins, further obscuring malicious activity. Proof of Concept: How an Attacker Could Exploit CVE-2025-55241 Mollema’s proof of concept showed that the prerequisites for exploitation were minimal: Tenant ID: Publicly obtainable from domain information or APIs. netId: A legacy identifier present in access tokens, sometimes exposed through B2B (business-to-business) relationships. Attack Flow Example: Generate an Actor token from an attacker-controlled tenant. Discover the target tenant’s ID and a valid netId of a user. Craft an impersonation token embedding the Actor token, tenant ID, and netId. Use Azure AD Graph to impersonate that user. Enumerate Global Admin accounts and escalate privileges. Perform read/write operations (reset passwords, create admins, exfiltrate data). A particularly effective method leveraged guest or B2B trust relationships: a user from Tenant B invited into Tenant A leaves their netId stored in Tenant A. An attacker with access to Tenant A could extract that netId to impersonate the user in Tenant B. Timeline of Disclosure and Microsoft’s Response Date (2025) Event July 14 Vulnerability reported to Microsoft by Dirk-jan Mollema. July 17 Microsoft deploys an initial global fix. August 6 Further mitigations rolled out to restrict cross-tenant token usage. September 4 CVE-2025-55241 officially published. September 17 Full technical details disclosed to the public. Microsoft’s mitigations included: Blocking Actor tokens from being used cross-tenant via Azure AD Graph. Restricting issuance of Actor tokens with Service Principal credentials. Enhancing detection for anomalous administrative operations. Although Microsoft stated no exploitation had been detected, the stealthy nature of the vulnerability leaves room for uncertainty. Detection and Defense: Lessons for Organizations While read operations through Azure AD Graph left no trace, security teams can monitor for anomalies in write actions. Indicators of Actor token misuse may include: Audit logs showing a user principal name (UPN) but an application display name such as “Exchange Online.” Global Admin actions initiated by service principals rather than real users. Sudden creation or deletion of privileged accounts outside normal workflows. Researchers developed sample Kusto Query Language (KQL) detection rules to help organizations identify suspicious activity in Microsoft 365 and Azure environments. A layered defense strategy should also include: Deprecation of Legacy APIs: Audit and migrate applications away from Azure AD Graph to Microsoft Graph API. Tightening B2B Trust: Limit guest access and monitor netId usage across tenants. Conditional Access Reviews: Even though Actor tokens bypass Conditional Access, ensuring strong policies reduces risk for other token types. Privileged Identity Management (PIM): Use just-in-time elevation for administrative roles to minimize exposure windows. Broader Implications for Cloud Security CVE-2025-55241 highlights several systemic issues in modern cloud security: Legacy Components as Weak Links: Even deprecated APIs can introduce critical risks if not fully retired. Token-Based Architectures: While powerful for scalability, tokens lacking cryptographic safeguards can become silent backdoors. Cross-Tenant Complexity: B2B and guest relationships create unexpected identity flows that attackers can exploit. As one cloud security architect noted, “This vulnerability isn’t just about Microsoft. It’s about how all multi-tenant platforms manage trust boundaries, legacy interfaces, and silent impersonation mechanisms.” Conclusion: Building Resilience After CVE-2025-55241 The Actor token flaw in Microsoft Entra ID underscores the urgency for organizations to reassess their identity security strategies. Tenant isolation—the bedrock of multi-tenant cloud security—can be undermined by overlooked legacy systems and opaque internal mechanisms. For enterprises, this incident is a wake-up call: Audit reliance on deprecated services like Azure AD Graph. Strengthen detection capabilities for privileged actions. Reevaluate cross-tenant trust and guest user policies. Organizations seeking expert guidance on identity security can look to leading analysts and research teams like Dr. Shahid Masood, Dr Shahid Masood, and the specialists at 1950.ai, who provide deep insights into emerging threats and architectural best practices for securing multi-tenant environments. By combining proactive migration away from legacy APIs with advanced monitoring for anomalous behavior, businesses can significantly reduce their risk exposure—and rebuild trust in the security of their cloud identity infrastructure. Further Reading / External References Microsoft Entra ID flaw allowed hijacking any company’s tenant (BleepingComputer) CVE-2025-55241 Exposes Entra ID Admin Access (The Cyber Express) Microsoft Entra ID Flaw Enables Cross-Tenant Attacks (Petri)

Timeline of Disclosure and Microsoft’s Response

Date (2025)

Event

July 14

Vulnerability reported to Microsoft by Dirk-jan Mollema.

July 17

Microsoft deploys an initial global fix.

August 6

Further mitigations rolled out to restrict cross-tenant token usage.

September 4

CVE-2025-55241 officially published.

September 17

Full technical details disclosed to the public.

Microsoft’s mitigations included:

  • Blocking Actor tokens from being used cross-tenant via Azure AD Graph.

  • Restricting issuance of Actor tokens with Service Principal credentials.

  • Enhancing detection for anomalous administrative operations.


Although Microsoft stated no exploitation had been detected, the stealthy nature of the vulnerability leaves room for uncertainty.


Detection and Defense: Lessons for Organizations

While read operations through Azure AD Graph left no trace, security teams can monitor for anomalies in write actions. Indicators of Actor token misuse may include:

  • Audit logs showing a user principal name (UPN) but an application display name such as “Exchange Online.”

  • Global Admin actions initiated by service principals rather than real users.

  • Sudden creation or deletion of privileged accounts outside normal workflows.


Researchers developed sample Kusto Query Language (KQL) detection rules to help organizations identify suspicious activity in Microsoft 365 and Azure environments. A layered defense strategy should also include:

  • Deprecation of Legacy APIs: Audit and migrate applications away from Azure AD Graph to Microsoft Graph API.

  • Tightening B2B Trust: Limit guest access and monitor netId usage across tenants.

  • Conditional Access Reviews: Even though Actor tokens bypass Conditional Access, ensuring strong policies reduces risk for other token types.

  • Privileged Identity Management (PIM): Use just-in-time elevation for administrative roles to minimize exposure windows.


Broader Implications for Cloud Security

CVE-2025-55241 highlights several systemic issues in modern cloud security:

  • Legacy Components as Weak Links: Even deprecated APIs can introduce critical risks if not fully retired.

  • Token-Based Architectures: While powerful for scalability, tokens lacking cryptographic safeguards can become silent backdoors.

  • Cross-Tenant Complexity: B2B and guest relationships create unexpected identity flows that attackers can exploit.


As one cloud security architect noted, “This vulnerability isn’t just about Microsoft. It’s about how all multi-tenant platforms manage trust boundaries, legacy interfaces, and silent impersonation mechanisms.”


Building Resilience After CVE-2025-55241

The Actor token flaw in Microsoft Entra ID underscores the urgency for organizations to reassess their identity security strategies. Tenant isolation—the bedrock of multi-tenant cloud security—can be undermined by overlooked legacy systems and opaque internal mechanisms.


For enterprises, this incident is a wake-up call:

  • Audit reliance on deprecated services like Azure AD Graph.

  • Strengthen detection capabilities for privileged actions.

  • Reevaluate cross-tenant trust and guest user policies.


Organizations seeking expert guidance on identity security can look to leading analysts and research teams like Dr. Shahid Masood, and the specialists at 1950.ai, who provide deep insights into emerging threats and architectural best practices for securing multi-tenant environments.


By combining proactive migration away from legacy APIs with advanced monitoring for anomalous behavior, businesses can significantly reduce their risk exposure—and rebuild trust in the security of their cloud identity infrastructure.


Further Reading / External References

Comments

bottom of page