In several organizations, “impersonation” of global administrators does not arrive with a suspicious interactive sign-in, but with a token that seems legitimate, issued in a context that modern defenses do not control in the same way. The pattern repeats: historical automations, integrations with retiring APIs, and inherited permissions that were never revalidated as Entra ID evolved (Conditional Access, enterprise application restrictions, consent hardening, etc.).
The risk is not abstract: when a workload obtains a valid token with equivalent privileges (or with the ability to act “on behalf of”) a highly privileged role, the attacker does not need to “break” MFA; they simply do not come in through that door. At the center of the problem are legacy tokens and S2S scenarios with “actor”, combined with endpoints and permissions that historically have allowed directory operations with inconsistent controls versus current policies.
What went wrong: when a valid token replaced the Global Admin sign-in
The typical failure is not “a Global Admin reused a password”, but that an application or workload identity (service principal, app registration, certificate) retains broad directory permissions and can request tokens in non-interactive flows. If that app was designed for administration (without a least-privilege model) or was granted admin consent years ago, the resulting token can be used to change critical configurations without meeting the same requirements (MFA, device compliance, location) you would impose on a human.
In S2S scenarios, the nuance of the actor also appears: tokens where a technical entity acts as an “actor” executing actions on a “subject”. In old integrations and migrations, this ends up in operations that, from an audit perspective, appear attributable to a user/admin when in reality they originate from an application. In enterprise environments this complicates incident response: the team first looks at sign-in logs and does not find the expected Global Admin “login”.
Real consequence: high-impact changes (e.g., modification of application credentials, permission adjustments, alteration of policies or assignments) executed from automations, pipelines, or hosts without hardening. In the best case, you end up with a “governance gap”: nobody can explain why an app had that scope. In the worst case, it is a silent and persistent escalation path.
The attack surface: legacy tokens, S2S “actor”, and obsolete APIs that bypass guardrails
Legacy tokens usually come in via two routes: (a) historical flows and permissions that are not aligned with how access to privileges is intended to be controlled today, and (b) dependence on old APIs and endpoints (classic case: Azure AD Graph) that have had behaviors and control models different from Microsoft Graph and modern controls around Conditional Access.
The operational problem is that control was designed around the user (MFA, risk, device state), but many sensitive operations are executed from non-human identities. If, additionally, an obsolete API allows equivalent actions with a different set of evaluations, the attacker will choose that path. They do not need to magically “bypass” Conditional Access: it is enough to operate in a lane that is not subject to the same evaluation or that is monitored more poorly.
- Overly broad application permissions (app-only)
In enterprises it is common to find apps with directory-level permissions granted “so it works” in an old project. Those permissions are, in practice, a permanent authorization; if the secret/certificate leaks or the environment where the app lives is compromised, the attacker gains an administrative capability very close to that of a Global Admin, without human interaction.
- Dependence on legacy endpoints and permissions (e.g., Azure AD Graph)
When legacy integrations coexist, the team may be hardening Microsoft Graph and leaving a parallel path open. The real impact in enterprise is seen when an “unauthorized” change is executed via a route nobody reviews because the organization already “migrated to Graph”… just not completely.
Early signals that do appear in enterprise environments (and are often overlooked)
Effective detection requires stopping looking only for “weird logins” by administrators and starting to correlate application activity with configuration changes. When abuse is via a non-interactive token, the trace looks more like activity of a “normal” app than like suspicious human access.
What gives these cases away is usually the combination of: a technical identity that suddenly performs directory operations it did not perform before, a credential or permission change associated with a service principal, or calls to old APIs that still exist in the environment. The pattern is very common in organizations with mergers/acquisitions, where “orphan” apps with high permissions remain.
- Administrative activity originating from service principals
If you see critical configuration changes attributed to an application (or to an automation) outside change windows, treat it as an incident until proven otherwise. Most teams underestimate this because “it is a system account”, when precisely for that reason it is a priority target.
- Residual use of Azure AD Graph / legacy endpoints
In practice, it appears as traffic or dependencies in old scripts (PowerShell, third-party tools) that nobody touched in years. The risk is not only that “it is old”: it is that it can escape the same controls and alerts the team has tuned for Microsoft Graph and interactive sign-ins.
If your SOC is based on alerts for sign-ins and role changes, but not on auditing changes on objects (applications, service principals, credentials), you may be blind to the preparation phase: the attacker first ensures persistence in apps and then executes the takeover.
How to do it in practice: inventory, legacy blocking, and validation that no “parallel lane” remains
The first realistic step in enterprise is to accept that “turning off legacy” without inventory breaks things. The correct approach is to operate in waves: identify which apps still use legacy permission/endpoint, define an owner, migration plan, and temporary controls. Meanwhile, reduce blast radius: cut permissions, rotate credentials, and limit where the automation can run.
Concrete actions that often work well when there is pressure and critical systems:
- Create a living inventory of privileged apps
Identify service principals and app registrations with high-impact application permissions (especially directory permissions). Assign a responsible owner, justification, and review date. In enterprise, this prevents the “nobody knows who owns it” that makes it impossible to cut permissions without panic.
- Configure guardrails to prevent an app from becoming “Global Admin by token”
Cut permissions to minimums, separate apps by function (read vs write), and avoid concentrating administration in a single technical identity. Complement with rotation and secure storage of secrets/certificates; if an app keeps long-lived credentials on a shared server, the token is the last link: the real problem is custody of the identity.
- Validate with evidence: change auditing and path testing
It is not enough to “believe” Conditional Access protects. Verify in audit logs which identity performs changes to: app credentials, permissions (app roles/consent), directory configuration, and assignments. Also, explicitly test that legacy paths are no longer used in production (for example, by removing script dependencies and monitoring controlled errors in pre-production environments before the cutover).
A typical mistake is to consider the gap closed after hardening human administrator access. If an app retains broad permissions, the attacker will not need to impersonate the Global Admin “logging in as them”; it will be enough to operate where the organization does not require MFA because it “does not apply” to workloads.
Recommendations for enterprise environments
Global Admin impersonation in Entra ID, when mediated by legacy tokens and S2S patterns with “actor”, is rarely detected with controls focused only on human sign-ins. The operational key is to treat application identities as privileged identities: inventory them, assign owners, justify permissions, and audit their activity as if they were administrators.
If in your environment there is still dependence on obsolete APIs (such as Azure AD Graph) or old scripts that request tokens via legacy routes, assume it as a “parallel lane” that can evade part of your modern policies and telemetry. Effective closure is not only technical: it requires governance discipline (ownership, periodic reviews, and permission removal), plus evidence-based validation (who made the change, with which identity, via which API), so that a valid token cannot become covert administration of the tenant.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.