Microsoft 365 offboarding gaps expose standing admin access

At a glance

What this is: This is a product-focused analysis of a Microsoft 365 security scanning session that exposed how disabled accounts can still retain critical Entra ID and PIM privileges.

Why it matters: It matters because identity teams often treat account disablement as offboarding completion, while NHI, autonomous, and human governance all depend on proving that access, tokens, and device trust were actually removed.

By the numbers:

• The scan ran 612 checks across Entra ID, Intune, Exchange, SharePoint, Teams, and OneDrive.
• 1, otal findings: over 1,300.
• The remediation session ended with seven sequential steps and an estimated cleanup time of 45-60 minutes.
• The free tier covers Entra ID with the top 10 findings and full remediation detail permanently.

👉 Read Senserva's analysis of Microsoft 365 offboarding gaps and privileged access

Context

Microsoft 365 offboarding often looks complete when the account is disabled, but the real governance question is whether roles, tokens, and device trust have been removed as well. In this session, the primary keyword is Microsoft 365 offboarding, and the issue is that disablement can create a false sense of closure while privileged access remains active.

The article shows why identity governance cannot stop at the user object. Entra ID, PIM, and device enrollment state all have to be assessed together because access paths survive in different control planes, and a single disabled account can still retain enough authority to become a breach starting point.

Key questions

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. That means the account is offboarded on paper, not in practice. The control failure is unfinished lifecycle removal, not failed authentication.

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. If refresh tokens remain valid, devices stay enrolled, or PIM assignments survive, an attacker may still find a usable path into the tenant. Security teams have to govern the whole identity state, not just the sign-in flag.

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. The result should be a closed identity with no surviving administrative path. If any artefact remains, offboarding is incomplete.

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.

Technical breakdown

Disabled accounts and standing privilege in Entra ID

Disabling an account only blocks interactive sign-in. It does not automatically remove privilege assignments, invalidate all tokens, or clear device-based trust paths. In Microsoft 365, standing roles can remain attached in Entra ID and PIM, which means the identity may still be a usable control surface if an attacker can recover credentials, leverage cached sessions, or abuse adjacent trust. The security problem is not account existence alone, but the residual authority attached to that object after offboarding. Practical assessment has to distinguish authentication denial from authorisation removal.

Practical implication: verify that disablement is paired with role removal, token revocation, and device trust cleanup.

PIM eligibility is not the same as revocation

Privileged Identity Management separates eligible activation from always-on access, but that distinction only helps if the lifecycle is enforced correctly. A disabled user can still carry eligible or even active privileged assignments if offboarding is incomplete, and those assignments may include Global Administrator or Application Administrator rights. That creates a gap between the ticket being closed and the privilege actually disappearing. In governance terms, the control failure is lifecycle drift across identity state and privilege state, not a missing alert. The environment still contains authority even when the account looks closed.

Practical implication: reconcile offboarding workflows against PIM assignments, not just account status.

Device trust, refresh tokens, and the long tail of access

A stale enrolled device can preserve access longer than teams expect because tokens, certificates, and device posture often outlive the employee account event. If refresh tokens are never revoked and the device remains enrolled, the identity boundary remains porous even after the user is disabled. This is especially dangerous in cloud collaboration stacks where the same identity touches email, files, chat, and app registrations. The important technical point is that access is distributed across authentication artefacts, not concentrated in one account flag. Practical governance has to treat device state as part of identity lifecycle, not a separate hygiene task.

Practical implication: include device unenrolment and refresh token invalidation in every leaver workflow.

Threat narrative

Attacker objective: The objective is to preserve or regain administrative control even after the organisation believes the account has been offboarded.

1. entry: an attacker could start from a disabled Microsoft 365 account if credentials or password hashes were recovered from breach data or residual session artefacts.
2. credential_harvested: the account still retained standing Application Administrator and PIM-linked authority, so the attacker would not need to escalate from zero privileges to meaningful control.
3. escalation: with app administration access, the attacker could persist through malicious app registrations, OAuth flow manipulation, or creation of a clean admin account.
4. impact: the environment could be turned into a long-lived foothold that bypasses the appearance of offboarding and enables token theft, privilege abuse, and administrative persistence.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing Application Administrator access is a blast-radius problem, not just a privilege problem. Once that role survives offboarding, the compromised identity can create persistence without needing to touch every other control. This is the kind of residual authority that makes Microsoft 365 offboarding a governance discipline rather than an administrative task. Practitioners should treat role survivability as the real risk indicator.

Tooling that explains what it cannot see is more useful than tooling that only reports findings. The article’s most valuable behavior was not the number of checks, but the explicit disclosure of skipped control groups and the permissions required to unlock them. That moves the product from static scanning toward governance clarity. The practical lesson is that visibility gaps must be surfaced as first-class findings, not hidden behind a finished report.

Residual identity artefacts are the failure mode this session exposes. The disabled account, eligible role assignments, stale device, and unrevoked tokens all outlived the supposed offboarding event. That pattern is exactly why lifecycle controls must be judged on artefact removal, not ticket closure. For identity teams, the question becomes whether any privileged artefact can still act after the human has left.

Microsoft 365 offboarding is a cross-domain control problem, not a single-workflow problem. Entra ID, PIM, device management, and session revocation all have to converge for the state to be truly closed. If one layer lags, the identity remains operational in practice even if it is administratively disabled. Practitioners need one closure standard that spans authentication, authorisation, and device trust.

From our research:

• 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.
• For lifecycle-driven identity programmes, the next step is to pair lifecycle cleanup with breach intelligence such as Schneider Electric credentials breach to see how residual access becomes real attacker leverage.

What this signals

Residual identity artefacts will become a board-level issue as Microsoft 365 estates mature. The pattern here is not a one-off admin mistake, but a structural mismatch between human offboarding processes and cloud privilege persistence. Teams that still measure closure by ticket completion will keep missing the real risk window.

Identity lifecycle programmes need a closure standard that spans user, role, and device state. In practice, that means the offboarding workflow must prove token invalidation, role removal, and enrolled device cleanup before the account is considered dead. Without that standard, the programme is only partially governing access.

The article’s most transferable lesson is that visibility gaps should be treated as governance events. When a scanner cannot see Conditional Access, Sign-In logs, or PIM alerts, the platform is telling you where your review process is blind, not merely where the report is incomplete.

For practitioners

• Rebuild leaver workflows around artefact removal Treat disabled account status as an intermediate step only. Require explicit removal of role assignments, eligible PIM entitlements, refresh tokens, and enrolled devices before closure is accepted.
• Reconcile PIM against offboarding tickets Match every terminated user against active, eligible, and standing privileged assignments in Entra ID. Any mismatch should block ticket closure until the privilege record is gone.
• 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.
• Surface control-group gaps as findings If a scanner cannot inspect Conditional Access, Sign-In logs, Authentication Methods, or PIM alerts, make the missing visibility part of the output so teams know the report is incomplete.
• Use attacker-path reconstruction for critical accounts Map how a disabled account could still become an admin foothold through app registrations, OAuth manipulation, or token reuse, then test whether that path is actually closed.

Key takeaways

• The core problem is not disabled accounts, but surviving privilege and trust artefacts after offboarding.
• The article shows a concrete scale issue, with 612 checks uncovering more than 1,300 findings across core Microsoft 365 services.
• Teams should validate role removal, token revocation, and device cleanup together, or assume the identity is still operational.

Key terms

• Residual Identity Artefact: An access-related object that survives after a user appears to be offboarded, such as a token, role assignment, enrolled device, or app trust. In practice, these artefacts keep the identity operational even when the account is disabled, creating a gap between administrative closure and actual access removal.
• Standing Privilege: Privilege that remains continuously available rather than being issued only when needed. In Microsoft 365, standing privilege can exist through role assignments, eligible activations, or legacy trust paths, and it becomes especially risky when offboarding does not remove it alongside the account.
• Identity Lifecycle Closure: The point at which an identity can no longer act because authentication, authorisation, device trust, and related artefacts have all been removed or invalidated. For governance teams, closure is a state that must be proven, not assumed from a disabled account flag.

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.

👉 Senserva's full post shows the account-level walk-through, skipped control groups, and remediation sequence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.