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.
How legacy tenant delegation paths break Entra ID trust boundaries
Legacy delegation paths are not just old wiring, they are alternate trust paths that can keep accepting assertions, tokens, or admin actions after the intended tenant and issuer checks should have moved on. That means the control plane can stop behaving like a single tenant boundary and start behaving like a split-brain trust model, where different parts of Entra ID disagree about who is acting and where authority comes from.
When that happens, tenant binding is the first thing to weaken. A delegation path that still honours a prior tenant relationship can let an actor present valid-looking identity material under the wrong context, so policy decisions are made against stale assumptions rather than current ownership and scope.
This is especially dangerous because revocation is only effective if every path that can consume the token or assertion actually checks the current trust state. If one legacy path does not, an access grant can outlive the intended tenant relationship even after the administrative relationship was changed elsewhere.
Why revocation, admin boundaries, and audit trails drift apart
Revocation fails when one control plane says the trust is gone but another path still treats it as valid. In practice, that creates a gap between directory state, token acceptance, and visible administration, which is why the same action can be both technically revoked and still operationally usable.
Auditability also degrades because activity may look like ordinary tenant administration instead of cross-tenant abuse. The logs can show a legitimate administrative pattern while the real problem is that the accepted context was wrong, so investigators see privilege use without the original trust violation that made it possible.
That mismatch matters because privileged actions taken through stale delegation paths can blend into normal tenant operations. The result is not only unauthorized access, but a hidden control failure where the evidence trail no longer lines up cleanly with the actual authority boundary.
What attackers gain from stale delegation paths
For an attacker, an active legacy delegation path is valuable because it can convert a one-time foothold into durable access. If the token or assertion is accepted outside its intended tenant context, the attacker may impersonate privileged users, bypass policy enforcement, and preserve access through a path that still looks administratively legitimate.
The practical risk is persistence through trust abuse rather than obvious malware-like behaviour. That makes it harder to detect quickly, because the attacker does not need to break the system once they have found a delegation path that still confers authority in the wrong place.
For identity teams, the key question is not whether the old path is documented somewhere, but whether it can still authorize real actions today. In Entra ID actor token flaw (CVE-2025-55241), hidden actor-token handling and validation issues showed how cross-tenant trust mistakes can become full tenant takeover conditions. The related risk is broader in the Active Directory and Entra ID Hardening Guide, which treats delegation and hybrid trust paths as control surfaces that need explicit hardening.
Risk and Threat Considerations
Legacy delegation paths create a trust-bypass condition because the platform may still accept assertions or tokens that should no longer be authoritative for the tenant. That exposes revocation gaps, weak tenant isolation, and audit confusion, especially when privileged actions continue to succeed after the intended trust relationship has changed.
Failure mechanism: A stale delegation route continues to validate identity material under an outdated issuer or tenant context, so policy enforcement and revocation no longer apply consistently across every access path.
Impact: Attackers can impersonate privileged users, maintain persistence, and carry out administrative actions that look legitimate in logs, which increases both blast radius and investigation time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Legacy delegation paths depend on controlled account relationships and revocation. |
| AC-3 — Access Enforcement | The issue is whether tenant and issuer context are enforced on every access path. | |
| AU-2 — Event Logging | Auditability breaks when legacy paths obscure who actually authorized the action. | |
| Recommendation — Inventory delegated accounts and disable any stale trust path that still authorizes access. Enforce tenant-scoped authorization at every delegation and token validation point. Log issuer, tenant, and delegation context for every privileged acceptance event. | ||
Practitioner Guidance
What to prioritise: Treat tenant delegation paths as authorization infrastructure, not as a migration detail. The first question is whether any legacy route can still accept a token, assertion, or admin action after the intended tenant binding has changed.
What to verify: Confirm that revocation works end to end across every issuer, federation, and delegation path, not just in the primary admin workflow. If a control change does not stop the oldest path from authorizing, the tenant boundary is not actually enforced.
What good looks like: Every delegation path is explicitly inventoried, tied to a current owner, and tested for revocation behaviour, tenant scoping, and audit visibility. If the path cannot be explained in current operational terms, it should be treated as a residual trust risk until proven otherwise.
Practitioner takeaway: The real failure is not “old delegation exists”, it is “old delegation still matters”, because any surviving trust path can nullify revocation, blur tenant boundaries, and give an attacker a clean persistence route.
Related resources from NHI Mgmt Group
- What breaks when legacy access paths are still active during a breach?
- What breaks when organisations rely on legacy delegation practices in Active Directory?
- What breaks when teams try to modernize legacy applications too quickly for Microsoft Entra ID?
- When does a short-lived API key still create material risk?