Who is accountable for Microsoft 365 trust exceptions that remain open?

Why This Matters for Security Teams

Open Microsoft 365 trust exceptions are not just configuration debt. They are explicit departures from a security baseline, which means someone approved a weaker control and someone else must keep watching it. In practice, the risk is that exceptions drift from temporary business need into permanent access paths, especially when ownership is split between IAM, platform, and operations teams. NIST’s NIST Cybersecurity Framework 2.0 emphasises governance and ongoing risk management, which is exactly what an exception requires once it is opened.

For Microsoft 365 environments, that matters because trust exceptions often affect authentication, conditional access, admin consent, device trust, or privileged app behaviour. A single exception can create an enduring gap if no one is assigned to review expiry, compensating controls, and business justification. NHIMG research on Microsoft Midnight Blizzard breach shows how identity and trust weaknesses become material when attackers can operate inside the control plane. In practice, many security teams discover open exceptions only after an audit finding or incident review, rather than through intentional governance.

How It Works in Practice

Accountability should follow the control owner, not the person who merely noticed the exception. The IAM or platform owner who approved it is accountable for business justification, expiration, and compensating controls. The security team is accountable for continuous review, evidence collection, and escalation when an exception ages beyond policy. This is consistent with the direction of the NIST Cybersecurity Framework 2.0, where governance is an active discipline rather than a one-time approval.

A practical operating model usually includes:

• A named exception owner in the ticket or risk register.
• An explicit review date and expiry date, not an open-ended waiver.
• Documented compensating controls such as MFA, scoped admin roles, or device compliance checks.
• Evidence of periodic review by security, not just approval by engineering.
• Escalation to risk or leadership when an exception remains open past tolerance.

For Microsoft-specific trust issues, this should also be tied to identity telemetry and admin activity review. NHIMG analysis of the Microsoft Azure OpenAI service breach and the DeepSeek breach reinforces a simple pattern: trust weaknesses become dangerous when they are both persistent and under-monitored. The exception owner closes the loop; security verifies that the loop stays closed. These controls tend to break down in federated tenant environments where multiple admins can modify policy without a single accountable service owner.

Common Variations and Edge Cases

Tighter exception governance often increases operational friction, so organisations must balance speed of change against the risk of leaving a control gap open indefinitely. Current guidance suggests that accountability can be shared, but responsibility should never be ambiguous. If an exception is granted for a business-critical integration, the application owner may own the use case, while IAM or platform still owns the control and the security team owns review.

Edge cases appear when exceptions are created for third-party integrations, emergency break-glass access, or tenant migrations. In those cases, best practice is evolving around time-bound approval, documented compensating controls, and a clear retirement plan. If no expiry exists, the exception is no longer an exception in operational terms. It is a permanent override that should be treated as a baseline change, reviewed through formal risk acceptance.

NHIMG research on Microsoft Midnight Blizzard breach is a useful reminder that identity exceptions can become attractive footholds when review discipline weakens. Accountability breaks down when exceptions are managed in scattered admin settings, because no single owner has both the authority and the incentive to remove them on time.

Related resources from NHI Mgmt Group

• Who is accountable when risk remains open after security flags it?
• How should security teams decide whether to keep a legacy SEG with Microsoft 365?
• Why do leaked secrets remain such a persistent NHI risk?
• Who is accountable when former employees still have Microsoft 365 access?