Who is accountable when former employees still have Microsoft 365 access?

Why This Matters for Security Teams

Former employee access is not just a cleanup task. In Microsoft 365, a delayed offboarding step can leave mailbox access, shared drives, application tokens, and delegated permissions active long after HR has closed the departure. That creates a governance problem because accountability is split across identity administration, endpoint control, data owners, and the business function that approved the access in the first place. Current guidance suggests this should be treated as an access lifecycle failure, not a one-time admin error.

The issue is especially visible where identity controls are mature in one system but weak in adjacent services. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, a reminder that revocation gaps often persist outside the human account itself. The same pattern appears in Microsoft 365 when access is inherited through groups, app consent, or shared ownership rather than a single user record. In practice, many security teams discover the accountability gap only after an ex-employee has already accessed mail, files, or shared workspaces.

How It Works in Practice

Accountability usually follows control of the lifecycle, not just control of the account. Identity teams typically own disablement in Entra ID, IT owns tenant administration and conditional access, and the business owner or manager owns the decision to retain or remove access to specific mailboxes, Teams, SharePoint sites, and line-of-business apps. That shared model lines up with the OWASP Non-Human Identity Top 10 view that credential and access risk is operational, not purely technical. The same logic applies to former employees whose access persists through delegated rights, service principals, or app connections.

In Microsoft 365, effective offboarding should include:

• Immediate account disablement and session revocation in the identity provider.
• Removal from groups, shared mailboxes, Teams, SharePoint, and Power Platform assets.
• Review of delegated access, mailbox forwarding, app consents, and OAuth grants.
• Ownership transfer for business-critical resources before the user is removed.
• Verification that retention policies preserve data without preserving live access.

That process works best when there is a named control owner for each step and a checklist tied to HR departure events. Where the environment includes automation, a stronger model is to trigger JIT revocation and access review at termination time, then confirm that no residual access paths remain. The broader NHI pattern in 52 NHI Breaches Analysis shows why this matters: access often survives in places people do not think to check, especially in integrations and shared credentials. These controls tend to break down in federated tenants with legacy apps because ownership is unclear and entitlement inheritance is not fully mapped.

Common Variations and Edge Cases

Tighter access removal often increases operational overhead, so organisations have to balance speed against the risk of breaking legitimate business processes. That tradeoff is most visible when the departed employee owned shared mailboxes, workflow approvals, or service integrations that cannot simply be deleted. Best practice is evolving, but there is no universal standard for this yet: some organisations move to immediate disablement with later entitlement cleanup, while others require business-owner signoff before revoking collaborative resources.

Another edge case is when the former employee’s credentials were used to administer scripts, shared accounts, or application registrations. In that situation, accountability extends beyond the human identity and into the underlying secret or workload identity. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privilege and poor visibility amplify this problem. Organisations should pair offboarding with secret rotation and ownership reassignment, especially for admin or automation accounts. In cloud-heavy environments, the answer is often shared accountability with explicit evidence, because no single team can prove control if identity, retention, and application ownership are all fragmented.

Related resources from NHI Mgmt Group

• Why do former employees still keep access after offboarding in many organisations?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?