Start by identifying every mailbox, guest account, and service-linked identity that can still authenticate or inherit access. Then apply ownership validation, inactivity thresholds, and quarantine workflows so dormant identities are disabled before they become usable attack paths. The key control is not cleanup alone, but enforceable lifecycle ownership.
Why This Matters for Security Teams
Dormant Office 365 accounts are not just housekeeping issues. They are retained authentication paths that can still inherit mailbox access, SharePoint permissions, guest collaboration rights, and in some cases downstream service trust. That matters because inactivity is not the same as revocation: an unused identity can remain perfectly usable for an attacker who has stolen a password, token, or session artifact.
Security teams should treat dormant accounts as part of identity attack surface management, not simple user administration. Current guidance aligns with lifecycle control, ownership validation, and timely disablement, which is consistent with the control logic in NIST Cybersecurity Framework 2.0 and the lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. The real risk is not only external compromise; it is also privilege inheritance, abandoned guest access, and stale owner mappings that survive org changes.
NHI Management Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification, which is a strong indicator that lifecycle gaps linger well past detection. In practice, many security teams discover dormant access only after a mailbox, token, or guest identity has already been used as the easiest path in.
How It Works in Practice
Effective governance starts with inventory, but not a flat list of accounts. Teams need to classify every dormant identity by type, ownership, and blast radius: employee mailbox, guest account, shared mailbox, service-linked identity, delegated admin account, or legacy integration account. The next step is to confirm whether the identity can still authenticate directly or can inherit access through group membership, app permissions, or retained mailbox delegation.
From there, apply an inactivity threshold that is operationally defensible. There is no universal standard for this yet, so many organisations use different thresholds for different account classes. A mailbox with no logon for 30 to 60 days may warrant review, while a guest account with no business owner and no active collaboration may justify faster quarantine. The key is that the threshold must trigger action, not just reporting.
- Validate ownership before disablement, because false positives are common after reorganisations and mergers.
- Quarantine first when business disruption is possible, then disable if the owner does not respond.
- Revoke active sessions, refresh tokens, app consents, and conditional access exceptions at the same time.
- Check for inherited access through Microsoft 365 groups, delegated mailbox permissions, and connected apps.
This workflow should be backed by change control and logging so that an account can be restored quickly if business need is proven. It also benefits from a secret and entitlement review, because dormant identities often remain valuable only due to still-valid credentials or app grants. The broader NHI lifecycle principles discussed in Ultimate Guide to NHIs and the exposure patterns in Guide to the Secret Sprawl Challenge both point to the same operational issue: unused access becomes dangerous when no one is accountable for its continued existence. These controls tend to break down when ownership data is stale across tenant, HR, and directory systems because revocation decisions cannot be trusted.
Common Variations and Edge Cases
Tighter dormant-account controls often increase helpdesk workload and can interrupt legitimate collaboration, so organisations have to balance security gain against business continuity. That tradeoff is especially visible in Microsoft 365 tenants with heavy guest access, regulated retention settings, or shared mailboxes used by rotating teams.
Best practice is evolving for these cases. For example, some organisations keep mailbox content under retention policy while disabling authentication, which preserves records without preserving access. Others use a staged quarantine model for VIP accounts, legal hold cases, or executive assistants, where a control owner must attest before full disablement. The important point is that retention and authentication are separate decisions.
Be careful with “inactive” identities that still have machine-like behaviour. A mailbox may appear dormant but continue to receive forwarded mail, delegate access, or API-based access through an integrated app. Guest accounts are also often missed because they are outside the normal employee lifecycle and may retain access after the sponsoring relationship ends. The 52 NHI Breaches Analysis shows why abandoned access paths matter: attackers repeatedly exploit identities that defenders assumed were no longer active. Current guidance suggests treating these edge cases as lifecycle exceptions with explicit expiry, not as permanently tolerated risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Dormant accounts often fail rotation and revocation expectations. |
| NIST CSF 2.0 | PR.AC-1 | Access management must remove stale authentication paths. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is undermined when dormant accounts retain inherited access. |
Disable inactive identities and revoke associated secrets on a defined lifecycle schedule.
