Who is accountable when authentication policy changes enable tenant takeover?

Why This Matters for Security Teams

Tenant takeover rarely starts with a password problem. It usually starts when an authentication policy, directory role, or conditional access rule is changed without a clear owner for the resulting blast radius. NIST’s Cybersecurity Framework 2.0 treats governance and accountability as core security functions, because policy drift can be just as dangerous as stolen credentials. When policy mutation rights are fragmented, attackers can move from a single configuration change to broad account compromise, especially across shared tenants and delegated administration paths.

This is also where NHI governance becomes relevant. NHIMG’s Top 10 NHI Issues notes that 97% of NHIs carry excessive privileges, which is a reminder that identity control failures are usually systemic, not isolated. The same pattern applies when authentication policy changes silently expand who can authenticate, who can consent, or who can reset access. In practice, many security teams encounter tenant takeover only after a policy exception has already been exploited, rather than through intentional change review.

How It Works in Practice

Accountability should follow the control plane that can actually change authentication outcomes. That means the team owning directory roles, the team governing authentication methods, and the application or tenant owner must all be visible in the approval path. If one group can relax MFA, add a trusted device condition, or exempt a service principal while another group owns the tenant, the resulting risk cannot be assigned after the fact. The right model is explicit policy ownership, change approval, and logging that ties every authentication-policy mutation to a named control owner.

In operational terms, that usually means:

• Separating who requests a change from who approves it, especially for MFA, SSO, federation, and conditional access rules.
• Recording which tenant, application, or identity population the policy applies to, including delegated admin scope.
• Reviewing policy mutations alongside privileged role assignments, not as a separate ticket queue.
• Using change records that show before-and-after policy state, so investigators can reconstruct escalation paths.
• Treating emergency exceptions as time-bound and reviewable, not permanent bypasses.

NHIMG’s Lifecycle Processes for Managing NHIs is useful here because authentication policy changes often affect non-human workloads indirectly through tokens, app registrations, and automation accounts. NIST guidance also supports this view: policy should be governable, auditable, and mapped to risk treatment rather than left to ad hoc admin convenience. These controls tend to break down when multiple teams can independently alter identity policy in a shared tenant because no single owner can see the full escalation path.

Common Variations and Edge Cases

Tighter authentication governance often increases operational overhead, requiring organisations to balance rapid response against change discipline. That tradeoff is real, especially during incident response, merger integration, or tenant migrations where administrators need temporary access to restore service. Current guidance suggests the exception should still be owned, time-boxed, and logged, but there is no universal standard for every identity stack yet.

Edge cases usually appear where authentication policy is enforced across multiple platforms, such as hybrid identity, federated SaaS, or managed service integrations. In those environments, a policy change in one system can create an unexpected trust path in another. This is why the Regulatory and Audit Perspectives section of NHIMG’s guide matters: auditors care less about which console was clicked and more about whether policy mutation rights, approvals, and evidence are traceable. The practical question is not just who approved the change, but who could have prevented it.

Related resources from NHI Mgmt Group

• Who should be accountable when a large authentication change affects thousands of users?
• Who is accountable when weak authentication fallbacks increase identity risk?
• How should security teams separate authentication from authorisation in IAM policy?
• Who is accountable when automated access changes fail an audit or create privilege drift?