Why do dormant service accounts create such a high compromise risk in Microsoft 365 environments?

Why dormant service accounts become easy targets in Microsoft 365

Dormant service accounts are attractive because they often sit outside normal user controls while still holding real permissions. In Microsoft 365, that combination usually means weak password hygiene, limited monitoring, and little human attention. Attackers do not need a noisy exploit when a quiet login path can deliver mailbox, SharePoint, or tenant-wide access.

The risk rises further when the account was created for a legacy integration, shared across workflows, or forgotten after a project ended. Those accounts can retain delegated access, app permissions, or admin-like reach long after the original business need has faded.

What makes dormant accounts so exploitable in practice?

Attackers value dormant accounts because they are predictable and forgiving. A dormant service account may have a known naming pattern, a password that has never been rotated, and no MFA to slow repeated guesses. That makes password spraying and credential stuffing far more effective than against actively used accounts with adaptive controls.

Microsoft 365 also makes the detection problem harder when there is no normal baseline of interactive use. If an account rarely signs in, a successful login can blend into low-volume authentication noise instead of standing out as an obvious anomaly. That is why compromise often goes unnoticed until the attacker has already moved into email, file storage, or identity-connected applications.

In many environments, the account is not just a login, it is a trust bridge. If it can authenticate to Exchange, SharePoint, Teams, or a connected app, the attacker inherits whatever the account was allowed to do. The risk is therefore less about the account being “inactive” and more about the account still being able to cross valuable trust boundaries.

Why the exposure can outlast the original purpose

Dormancy is dangerous because access often survives while ownership disappears. A service account can remain valid after the team that created it has changed, the integration has been replaced, or no one remembers who can approve rotation. That weakens the practical ability to review whether the permissions still match the business function.

When these accounts are embedded in automation, scripts, or third-party connections, the blast radius can also be wider than it first appears. A single dormant credential may unlock multiple systems, and a compromised account can be reused to pivot into other SaaS apps, inboxes, or administration workflows.

For a broader view of why dormant and overprivileged machine identities become enterprise problems, NHIMG’s Ultimate Guide to NHIs is a useful starting point, and the Service Account Security Guide goes deeper on discovery, least privilege, and rotation.

Risk and Threat Considerations

Dormant service accounts create a high compromise risk because they combine low scrutiny with high trust. Attackers can test credentials repeatedly, wait for a successful hit, and then use the account’s legitimate permissions to blend into ordinary Microsoft 365 activity.

Failure mechanism: password guessing succeeds against a rarely used account because the credentials are weak, unchanged, or not protected by MFA, and the resulting sign-in does not trigger strong behavioral suspicion.

Impact: the attacker can reach mail, files, delegated permissions, or connected apps, then extend access before the organisation notices that the account should have been dormant or retired.

Practitioner Guidance

What to prioritise: Treat dormant service accounts as live exposure, not housekeeping. The first question is whether the account can still authenticate and whether its permissions still match an active business owner. If ownership is unclear, the account is already in a higher-risk state.

What to verify: Confirm last use, current owner, password age, MFA status where possible, and every application or tenant privilege attached to the account. If the account exists only for a retired integration, the safest default is disablement, not continued monitoring.

Common mistake: teams often focus on whether the account is being used regularly and miss the fact that dormant accounts are dangerous precisely because they are not being watched. Low usage reduces human visibility, it does not reduce attacker interest.

Practitioner takeaway: The real control objective is not simply to find dormant accounts, it is to remove unneeded authentication paths, reduce standing privilege, and ensure every remaining service account has an owner, a purpose, and a rotation plan.

Related resources from NHI Mgmt Group

• Why do compromised credentials and over-permissioned service accounts create such high risk in GitHub code environments?
• Why do dormant and shared accounts create such a high risk in enterprise environments?
• Why do service accounts with standing privilege create such high breach risk?
• Why do pre-auth service flaws create such a high compromise risk?