Are all accounts associated with legitimate processes or current users (no orphaned/stale)?
Dormant accounts are the quietest exposure on any estate. Nobody notices when one is used, because nobody was watching an account nobody uses.
What the carrier is actually asking
The carrier is asking whether your directory reflects reality: no accounts for people who left, no accounts for projects that ended, no service accounts whose purpose nobody can name. It is a question about identity hygiene, and it is asked because dormant accounts are disproportionately represented in intrusion timelines.
Why it is underwritten
A stale account has three properties an attacker values: an old password that predates your current policy, no owner to notice unusual behaviour, and often a set of permissions accumulated before it went quiet. Credential stuffing and password spraying find these accounts first. Underwriters ask because the control is cheap and its absence is a reliable indicator of weak identity governance more broadly.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is one of the most directly measurable questions on any application. Entra ID records last sign-in per account, so staleness is a query rather than an opinion.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | User accounts with last interactive sign-in older than the threshold you set | A small, explained population. Accounts dormant beyond ninety days should be disabled or justified |
| Entra ID | Accounts that have never signed in | Provisioned and abandoned accounts are removed, since they carry an initial password and no observation |
| Entra ID | Guest and external accounts, and their last activity | Guests from finished engagements are removed. Guest sprawl is the most common form of this finding |
| Entra ID | Applications and service principals without an assigned owner | Every application has a named owner, so credentials have someone accountable for rotating them |
| Microsoft 365 | Licensed accounts with no mailbox activity, and orphaned Teams or sites | Licensed dormancy is both a cost and a risk signal, and orphaned collaboration spaces retain data with no owner |
Carriers do not require deletion. Disabling on departure, with retention for legal and forensic reasons, is a mature answer. What they do not accept is enabled accounts belonging to people who left, which is what an unmanaged directory produces.
What a defensible yes requires
- A defined dormancy threshold exists and accounts crossing it are disabled automatically or reviewed on a schedule.
- Departure triggers deprovisioning through a process that runs whether or not anyone remembers to file a ticket.
- Guest accounts have expiry or periodic review, so external collaboration does not become permanent access.
- Service accounts and applications have named owners and a purpose recorded somewhere durable.
- The current stale count can be produced on demand rather than reconstructed for the application.
How this answer goes wrong
The answer usually goes wrong at the boundary of the identity system. Human resources triggers deprovisioning for employees and not for contractors, so contractor accounts persist. Or the process disables the account and leaves the mailbox and the guest invitations in other tenants intact. The question asks about all accounts, and the accounts that survive a departure process are precisely the ones nobody sees.
Frequently asked
What counts as stale?
Most organisations use ninety days without an interactive sign-in, and carriers rarely dispute that. What matters more is that the threshold is defined, enforced, and the same one you can evidence.
Do service accounts count as orphaned if nobody owns them?
Yes, and they are the more serious version of this finding. A service account with no owner has no one to rotate its credential or notice its misuse.
How do guests fit into this?
Guest accounts are usually the largest stale population in a Microsoft 365 tenant, because invitations outlive the projects that produced them. Access reviews or automatic expiry solve it.
Is this asked in a claim review?
Frequently, because intrusion timelines so often begin at an account that should not have existed. It is an easy control to evidence before a loss and an uncomfortable one to explain after.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture