Who is accountable when Office 365 access stays active after role changes?

Why This Matters for Security Teams

Office 365 access that remains active after a role change is not just an HR hygiene issue. It is a lifecycle ownership failure that can leave mail, SharePoint, Teams, and connected SaaS workflows exposed long after the original business need has ended. The practical risk is persistent access through shared admin paths, delegated permissions, and stale group membership, especially when no one is accountable for certification and deprovisioning.

Current guidance from the OWASP Non-Human Identity Top 10 reinforces a broader point that also applies to human and machine access: identity sprawl becomes a security problem when ownership is unclear. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a useful signal for how quickly entitlement drift can accumulate when reviews are inconsistent. The same pattern appears in Office 365 when role changes do not trigger timely access review, exception handling, and removal from privileged groups.

In practice, many security teams encounter the failure only after a former role holder still has access to sensitive mailboxes or collaboration spaces, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability should be split by control, not by blame. Identity governance owns the process, application or platform owners own the access model, and business managers own the approval of ongoing need. That division matters because Office 365 access often persists through multiple layers: direct assignments, Entra ID groups, role memberships, guest access, delegated mailbox permissions, and app-consented permissions.

A workable model is to tie role-change events to an access review workflow. When an employee changes departments or job functions, the workflow should identify all Office 365 entitlements, compare them to the target role, and remove anything not justified. Where business continuity is needed, temporary exceptions should be time-bound and explicitly approved. This aligns with the lifecycle and offboarding discipline described in the Ultimate Guide to NHIs, even though the account type here is human, because the governance pattern is the same: enumerate, validate, revoke, and re-certify.

• Trigger reviews from HR or identity events, not only from annual certification cycles.
• Map each Office 365 entitlement to a named owner and a business justification.
• Use short review windows for elevated access and delegated mailbox permissions.
• Document who approves exceptions, who executes removal, and who verifies completion.
• Measure removal latency and failed revocations as operational security metrics.

For implementation detail, the OWASP Non-Human Identity Top 10 is a useful reminder that unmanaged identity lifecycle creates durable risk, while the NHI Mgmt Group research base shows how often privileged access remains broader than intended. These controls tend to break down when role changes happen inside federated tenants with custom mailbox delegation and no reliable source-of-truth for ownership.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance rapid collaboration against stricter review and revocation discipline. That tradeoff is especially visible in Office 365 because some roles require temporary overlap, shared service accounts, or mailbox delegation during handovers.

Best practice is evolving on exactly how much automation should be used for role-change deprovisioning. In mature environments, identity governance can revoke standard access automatically while routing edge cases to human approval. In less mature environments, a manual checkpoint may be the only reliable safeguard, but that should be treated as a transition state, not a final design. The main exception is where an employee changes roles but retains a formal business need for a subset of prior access; in that case, the exception should have an expiry date, not indefinite continuation.

Another common edge case is access granted through groups or applications that indirectly reach Office 365 content. If the review only checks direct assignments, stale access remains invisible. NHI Mgmt Group’s 52 NHI Breaches Analysis is a useful reminder that missed lifecycle control is usually an aggregation of small ownership failures, not a single dramatic misconfiguration. Security teams should therefore assign accountability at the entitlement layer, not just the person layer.

Related resources from NHI Mgmt Group

• Who is accountable when server access remains active after offboarding?
• Who is accountable when access is left active after a role change or departure?
• Who is accountable when automated deprovisioning does not happen after access review?
• Who is accountable when a former employee still has access after offboarding?