Notifications
Clear all
Topic starter
08/07/2026 7:09 pm
TL;DR: A disabled Microsoft 365 account still carried five PIM role assignments, a standing Application Administrator grant, and a stale device with tokens never revoked, according to Senserva. The real failure is the assumption that disabling an account means its privileges are gone.
NHIMG editorial — based on content published by Senserva: Microsoft 365 offboarding gaps exposed in beta testing
By the numbers:
- The scan ran 612 checks across Entra ID, Intune, Exchange, SharePoint, Teams, and OneDrive.
- Total findings: over 1,300.
- The free tier covers Entra ID with the top 10 findings and full remediation detail permanently.
Questions worth separating out
Q: What breaks when a Microsoft 365 account is disabled but privileged access remains attached?
A: The organisation loses the signal that the leaver workflow is complete, but the identity can still retain administrative power through standing roles, eligible PIM assignments, or stale devices.
Q: Why do disabled Entra ID accounts still create security risk?
A: Because account disablement does not automatically revoke every credential, token, or privilege associated with the identity.
Q: How do security teams know whether offboarding actually worked?
A: They should verify that the user no longer has active or eligible privileged assignments, that tokens have been revoked, and that enrolled devices and app trust artefacts are removed.
Practitioner guidance
- Rebuild leaver workflows around artefact removal Treat disabled account status as an intermediate step only.
- Reconcile PIM against offboarding tickets Match every terminated user against active, eligible, and standing privileged assignments in Entra ID.
- Add device trust to identity governance reviews Check whether stale enrolled devices still exist for former users and verify that tokens, certificates, and device registrations are invalidated as part of offboarding.
What's in the full article
Senserva's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step remediation output showing exactly how the PowerShell fix sequence was structured.
- The full list of skipped control groups and the permissions required to unlock each one.
- The environment-specific mapping from findings to account names, device IDs, and role assignments.
- Pricing and packaging detail for the free tier and paid subscription.
👉 Read Senserva's analysis of Microsoft 365 offboarding gaps and privileged access →
Microsoft 365 offboarding gaps: are your controls keeping up?
Explore further
08/07/2026 7:33 pm
Disabled-account governance failed because identity state and privilege state were treated as the same thing. The session shows a familiar Microsoft 365 assumption collapse: if the account is disabled, the access is gone. That assumption fails when standing roles, device trust, and token artefacts survive the offboarding ticket. The implication is not just better cleanup, but a redesign of how closure is defined in identity lifecycle governance.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant behaviour gap that often starts long before offboarding workflows fail.
A question worth separating out:
Q: Who is accountable when a disabled account still has admin access?
A: IAM, PIM, and endpoint owners share accountability because the failure spans identity lifecycle, privilege governance, and device trust. The correct framework is to measure whether the closure state was validated across all three control planes. If those controls are split, the residual access gap becomes easy to miss.
👉 Read our full editorial: Microsoft 365 offboarding gaps expose standing admin access
