How can organisations tell whether Microsoft 365 controls are actually working?

Look for declining numbers of stale guests, reduced broad-group memberships, faster removal of obsolete delegated access, and shorter exposure windows for sensitive repositories. If those measures do not improve over time, the programme may be producing reports without changing actual access conditions.

Why This Matters for Security Teams

Microsoft 365 controls often look effective in a report while leaving real access paths unchanged. That gap matters because guest users, delegated permissions, broad group membership, and stale app consents can persist long after the business need has ended. Security teams need evidence of reduced exposure, not just completed tasks, and they need to verify whether controls are shrinking the attack surface over time. Guidance from the NIST Cybersecurity Framework 2.0 supports outcome-based measurement rather than checkbox activity.

This is especially important in Microsoft 365 because identity sprawl tends to accumulate quietly across Entra ID, SharePoint, Teams, Exchange, and connected apps. NHI Mgmt Group has noted that only 5.7% of organisations have full visibility into their service accounts in the broader identity landscape, which is a useful reminder that lack of visibility usually hides control failure, not control success. For background on how unmanaged identity exposure becomes operational risk, see the Ultimate Guide to NHIs. In practice, many security teams discover control failure only after a sensitive site has already stayed overexposed for weeks, rather than through routine verification.

How It Works in Practice

The most reliable way to tell whether Microsoft 365 controls are working is to track changes in actual access conditions, then tie those changes to specific control actions. Start with a baseline for stale guests, broad-group memberships, delegated mailbox access, app permissions, external sharing links, and privileged role assignments. Then measure whether those numbers decline after access reviews, policy enforcement, and remediation workflows.

For Microsoft 365, strong verification usually combines four layers:

• Access hygiene metrics, such as stale guests removed, unused accounts disabled, and expired access removed from sites and teams.

• Privilege reduction metrics, such as fewer users in broad groups, fewer permanent admin assignments, and tighter use of just-in-time elevation.

• Exposure window metrics, such as the time between detecting obsolete access and revoking it.

• Control persistence checks, such as whether policy changes remain in force after new sites, teams, or apps are created.

That approach aligns with outcome-focused identity governance, not reporting for its own sake. The Microsoft Midnight Blizzard breach is a reminder that identity and access weaknesses can become material even when the environment appears managed on paper. For a formal baseline on control outcomes, compare your programme to Ultimate Guide to NHIs — Standards and map the same principle to Microsoft 365 control testing. Teams should also validate whether alerts lead to actual revocation, because a detected issue that remains open is still active exposure. These controls tend to break down when permissions are spread across many owners and automation cannot reliably remove access without breaking legitimate collaboration.

Common Variations and Edge Cases

Tighter Microsoft 365 controls often increase administrative overhead, requiring organisations to balance faster access removal against the need to avoid business disruption. That tradeoff is most visible in environments with frequent guest collaboration, large M&A activity, or heavy use of shared mailboxes and delegated access.

Current guidance suggests treating some measures as stronger signals than others. A drop in stale guests is useful, but it is not enough if broad groups still grant excessive reach. Likewise, shorter exposure windows are a better indicator than audit completion alone, because they show how quickly the organisation actually responds. There is no universal standard for this yet, so the best practice is evolving toward continuous verification, not annual review.

Edge cases include regulated archives, long-lived project sites, and service accounts tied to legacy workflows. Those environments may require exceptions, but exceptions should be explicit, time bound, and reviewable. If the same accounts remain active across multiple quarters with no reduction in access scope, the controls are probably generating documentation rather than risk reduction. In Microsoft 365, that difference is what separates governance from real protection.

Related resources from NHI Mgmt Group

• How can organisations tell whether runtime identity controls are actually working?
• How can organisations tell whether their NHI controls are actually working?
• How can organisations tell whether governed data access is actually working?
• How can organisations tell whether their SBOM process is actually working?