Tenant-scoped trust breaks first, because a token issued in one directory can be accepted as authority in another. That undermines Conditional Access, audit separation, and revocation assumptions at the same time. In practice, teams lose the ability to tell whether a privileged action came from a valid local identity or a mis-scoped delegation artefact.
Why This Matters for Security Teams
Cross-tenant reuse of legacy impersonation tokens does more than weaken access control. It collapses the assumptions behind tenant isolation, audit integrity, and revocation. If a token minted in one directory is accepted elsewhere, then Conditional Access can be bypassed, investigation trails become ambiguous, and offboarding no longer guarantees that delegated access is gone.
This is the same class of failure seen across token and secret sprawl incidents such as the Salesloft OAuth token breach and the Cisco Active Directory credentials breach, where trust artifacts outlived the controls meant to contain them. NIST Cybersecurity Framework 2.0 emphasizes that identity assurance and access governance must be continuously enforced, not assumed at issuance. In practice, many security teams discover cross-tenant token misuse only after a privileged action has already been executed from the wrong directory, rather than through intentional validation.
How It Works in Practice
Legacy impersonation tokens were often designed for convenience in a single directory or tightly controlled federation boundary. Once those tokens are accepted across tenants, the identity provider may no longer be able to reliably tell whether the token is being used by the intended tenant, a delegated admin, or an attacker exploiting mis-scoped trust.
The practical failure mode is usually a chain reaction:
- Token issuance is tied to the original tenant, but validation is too permissive elsewhere.
- Conditional Access and device posture rules apply inconsistently across directories.
- Audit logs show a valid token, but not always the correct tenant context.
- Revocation in the source tenant does not fully contain cross-tenant reuse if downstream trust remains accepted.
That is why current guidance suggests moving away from static, long-lived impersonation semantics and toward tighter workload or delegated identity boundaries. The Guide to the Secret Sprawl Challenge shows how quickly credential trust expands beyond its original design once secrets are copied, cached, or reused. In parallel, NIST guidance on identity and access management, along with the NIST Cybersecurity Framework 2.0, supports continuous verification, explicit scoping, and timely revocation rather than inherited trust.
Operationally, teams should confirm whether tokens are tenant-bound, whether the resource server re-checks tenant context at every request, and whether delegated access is recorded with enough fidelity to distinguish original issuance from downstream reuse. These controls tend to break down in hybrid identity environments where legacy federation, multiple Entra-style directories, and application-level caching all preserve trust longer than the security team expects.
Common Variations and Edge Cases
Tighter token scoping often increases migration overhead, requiring organisations to balance compatibility with the security benefit of tenant isolation.
Some environments cannot remove cross-tenant token acceptance immediately because older applications, partner integrations, or service accounts depend on it. Current guidance suggests treating that as a temporary exception, not an operating model. Best practice is evolving toward short-lived, explicitly tenant-scoped credentials, with clear issuer and audience validation at runtime.
There are also edge cases where cross-tenant access is legitimate, such as mergers, managed service providers, or centralized security operations. In those cases, the risk is not the existence of cross-tenant access itself, but the lack of precise policy boundaries and reviewable delegation records. A shared control plane should not mean shared trust by default.
NHIMG research on the JetBrains GitHub plugin token exposure and the Sisense breach shows how quickly exposed credentials become enterprise-wide liabilities when scope and lifecycle controls are weak. The operational rule is simple: if a token can cross tenants, the organisation must assume the trust boundary is already weaker than the documentation claims.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses overbroad NHI trust and token scope across environments. |
| NIST CSF 2.0 | PR.AC-1 | Identity assertions and access enforcement must stay tenant-specific. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification instead of inherited trust. |
Reassess token trust per request and remove assumptions that one tenant can trust another.
Related resources from NHI Mgmt Group
- What breaks when human MFA is used for bots and AI agents?
- Why do bearer tokens create risk in MCP if they are reused across systems?
- What breaks when revocation only applies to token state and not to legacy device records?
- What are the implications of using OAuth tokens in third-party integrations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
