Active Directory Hygiene: The Boring Security Win That Will Save Your Weekend

Here is a true thing that should make you a little uncomfortable: across every post-incident review for credential-based breaches in the past five years that I've read, "the attacker used a dormant account" is in the top three root causes. Not zero-days. Not phishing the CEO. Just an account that should not have existed any more, that nobody was watching, that still had access.

The boring fix is the most effective fix. Active Directory hygiene is uglier than buying a new shiny tool, and it cuts your attack surface more. Here is the rhythm that works.

The 30-day rhythm

Once a month, on a calendar invite that nobody can move:

• Pull every account that hasn't authenticated in 90 days. Look at the list. Resist the urge to apologize to the people whose accounts you're about to disable.
• Disable accounts inactive 90-180 days. Disable is reversible. People will tell you they "needed that". They almost never did.
• Archive or delete accounts inactive beyond 365 days. A year is a long time. If they come back, you'll re-onboard them. They won't.
• Track every exception explicitly with a named owner and a re-review date. "Bob from accounting said don't touch it" is not an exception. "Bob from accounting owns the renewal pipeline; review July 1" is an exception.

Group sprawl, the silent killer

Empty groups. Nested groups whose owners left in 2019. Groups named after a project that ended before the iPhone X came out. All of them accumulate quietly until someone tries to audit access and discovers the org chart is fiction.

A quarterly "rename or delete" sweep — one afternoon, one analyst, no heroics — keeps the directory navigable. Renaming is underrated. A group called FIN-LEGACY-AP-2018 tells you exactly what to do with it. A group called Group_New_2 tells you the person who created it has since left, possibly never to be heard from again.

Service accounts — where breaches actually start

Service accounts are where bad hygiene goes to die. Created in 2014. Last password change: 2014. Owner: left in 2017. Permissions: a generous interpretation of "we need it to work, just give it everything".

The remediation playbook, in order:

• Inventory. Pull every service account. Tag with owner (a person, currently employed, who has been told they own it) and the system it serves.
• Right-size permissions. Most service accounts have far more access than they need. Cut to least-privilege and watch what breaks. Restore the minimum needed to un-break it. Document.
• Rotate or move to managed. Where the platform supports managed service accounts (gMSA in Windows, IAM roles in AWS, workload identity in Kubernetes), migrate. Where it doesn't, rotate passwords on a schedule and store them in a vault that nobody has the master key to in a Post-it note.

None of this work will make a slide deck. All of it will make your weekend in six months noticeably less stressful when the incident review goes: "looks like the dormant account from 2018... wait, it was disabled in 2024. Huh. Carry on."