3.5.6 — Disable Dormant Accounts

The One-Liner

An inactive account is a gift to an attacker — nobody’s using it, nobody’s watching it, and if it’s compromised, nobody notices.

What It Says

Disable identifiers after a defined period of inactivity.

What It Actually Means

Accounts unused for a set period get disabled automatically. 90 days is the common threshold, but you define the period in your policy.

Why this matters: dormant accounts are prime targets. An attacker who compromises a dormant account has time to operate undetected because nobody notices unusual activity on an account nobody uses.

Three things the assessor needs:

1. A defined inactivity threshold in your policy
2. An automated mechanism that disables accounts meeting that threshold
3. Evidence it’s working — a list of recently auto-disabled accounts

Service account exception: Some service accounts run monthly jobs (like license reconciliation or quarterly reports). They’d trigger a 90-day inactivity disable. Document these accounts and exclude them from auto-disable — but review them separately on a quarterly basis to confirm they’re still needed.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Is a period of inactivity defined after which identifiers are disabled?	Policy states the threshold — typically 90 days
2	Are identifiers disabled after the defined period of inactivity?	Automated process disables accounts, verified by recent disable log

---

What to Have Ready on Assessment Day

Documents they’ll review: Identification and authentication policy; procedures addressing identifier management; system security plan; system configuration settings; list of recently disabled identifiers

People they’ll talk to: Personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators

Live demos they’ll ask for: Mechanisms supporting or implementing identifier management

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “What is your defined inactivity threshold?”
• “Is the disable process automated or manual?”
• “Show me accounts that were recently disabled for inactivity.”
• “How do you handle service accounts that are legitimately used infrequently?”
• “How would you detect if a dormant account was being used by an attacker?”

Real-World Example

A contractor runs a weekly Power Automate flow that queries Entra ID sign-in logs for accounts with no activity in 90+ days. Matching accounts are automatically disabled and the IT manager gets a notification. The flow excludes a documented list of 6 service accounts (reviewed quarterly). The assessor asks to see the last execution — the flow disabled 2 accounts last week (a contractor whose engagement ended and an employee on extended leave). Both were reviewed and confirmed as correct disables.

---

Where Companies Trip Up

No auto-disable. Accounts stay active forever. Manual review catches some but misses others.

Threshold too long. 365 days is too long — an attacker has a year of undetected access. 90 days is standard.

Service accounts caught by auto-disable. A legitimate monthly process breaks because its service account was disabled. Document exceptions and review them separately.

No monitoring of dormant accounts. Accounts are eventually disabled but nobody watches for suspicious activity on dormant accounts before they’re disabled. SIEM rules for activity on dormant accounts catch this.

---

How to Talk About This

To a CEO or Board

Accounts unused for 90 days are automatically disabled. We don’t leave dormant accounts sitting around for attackers to find.

To an Engineering Team

Weekly automated flow: Entra sign-in activity > 90 days inactive → auto-disable. Service accounts documented and excluded. Quarterly review of excluded accounts. SIEM alert for sign-in activity on dormant accounts (last sign-in > 60 days). Disable log maintained.

---

Connected Requirements

Requirement	Why it matters here
3.5.1 — Prove Who You Are	Manages the lifecycle of identifiers established here
3.1.1 — Who Gets In	Dormant account disable is part of maintaining the authorized user list
3.9.2 — Revoke on Departure	Catches accounts that offboarding should have disabled but didn’t

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: IA.L2-3.5.6 | SPRS Weight: 1 point | POA&M Eligible: Yes