by Heath Gieson

 

Years ago, I worked with a client to implement multi‑factor authentication across their organization. As part of the project, they gave us a list of users who required MFA and explained that this represented all the active users in the business. That sounded reasonable, so we implemented MFA exactly as scoped and closed the project.

A few months later, they experienced an account compromise.

The compromised account belonged to someone who had not worked at the company for six years. The account was still enabled. MFA had never been applied because the user was not considered active by HR and therefore never appeared on the MFA list in the first place. What followed was a deeper review of their environment, where we discovered several additional accounts for terminated employees that were still active.

None of this was intentional. All of it was the result of weak termination discipline.

By the time organizations reach Control 5, identity has effectively become the control plane. MFA, access controls, and monitoring all depend on accounts being accurate and intentional. Dormant accounts undermine every one of those controls, often without anyone realizing it.

On paper, Control 5.3 is simple. Disable dormant accounts after a defined period of inactivity. In practice, it fails because many organizations do not have a clear, enforced process for terminating user accounts. The pattern is common. An employee leaves, and someone asks to keep the account active so the rest of the team can access email, files, or chats. The password is changed and shared internally. What was meant to be temporary quietly becomes permanent.

This approach creates multiple problems at once. Shared credentials eliminate accountability. Dormant accounts are rarely monitored. And most importantly, these accounts fall outside normal security initiatives because they are no longer considered active users. That is exactly why the MFA deployment failed. The account was invisible to the process that was meant to protect it.

The right solution is not to keep accounts enabled. It is to transfer access properly. Modern platforms support email delegation, file ownership transfer, and shared access without leaving an account active. Doing this consistently requires a policy, a defined process, and the discipline to enforce it.

Control 5.3 is not really about inactivity timers or technical settings. It is about operational maturity. Organizations need to clearly define what dormant means, tie account disablement to HR events rather than informal requests, and review enabled and disabled accounts on a recurring basis. Exceptions should be rare, documented, and time‑bound.

From an audit and defensibility standpoint, this control is straightforward when it is real. Auditors are not looking for perfection. They want to see that a termination policy exists, that inactivity thresholds are defined, that reviews occur on a cadence, and that accounts are actually being disabled. Checks and balances matter here, just as they do in any well‑run process.

While Control 5.3 focuses on dormant accounts, it also highlights a broader truth. Account creation is just as important as account termination. If organizations do not control how accounts are created, tracked, and retired, every downstream control becomes weaker.

Security maturity is not about adding more tools. It is about making the basics work, consistently and intentionally.