by Tim Marley

As we move into CIS Control 5, Account Management, we’re going to spend a few weeks working through the individual safeguards. We’re starting with 5.1: Establish and Maintain an Inventory of Accounts.

This control comes back to a principle we’ve already seen a few times. You cannot protect what you have not identified.

Every environment starts the same way

It doesn’t matter if you’re a ten-person shop or a ten-thousand-person enterprise. The process usually begins the same way. You stand up a platform, you create an administrative account, and from there, every person in the organization gets their own. That becomes their identity in the system. It’s how they log in, access tools, send email, and interact with data. More importantly, it’s how the organization ties activity back to a specific person.

Without that, none of the other controls work. You can’t assign permissions appropriately, you can’t monitor behavior, and you can’t hold anyone accountable for what they do in your environment.

Why unique accounts matter

Accounts are what allow you to differentiate between users, and that differentiation is what makes access control possible in the first place.

Someone in accounting needs access to financial systems, payroll data, and reporting tools. They probably don’t need access to your engineering repositories or proprietary product designs. Someone in engineering may need the exact opposite. That separation only works if each person has a unique account tied to a defined identity. Shared accounts collapse that model entirely. When three people log in under the same credentials, you lose the ability to know who did what, when, and whether it was appropriate.

Unique accounts also give you the ability to restrict access where it shouldn’t exist, grant access where it should, and track activity to a specific individual when something goes wrong. Those aren’t advanced security concepts. They’re the baseline. And they only work if the inventory behind them is accurate.

Accounts exist everywhere, not just in your primary system

It’s easy to think of accounts as just your main login. In practice, every system that requires authentication introduces another account to manage. Cloud platforms, line-of-business applications, accounting systems, ERP platforms, engineering tools. If those systems aren’t tied into a central identity platform, you have multiple account stores running in parallel, each with its own list of who has access and why.

And it goes further than user accounts. Most environments also carry service accounts, accounts created not for a person but for an application or automated process to authenticate against another system. Local administrator accounts that exist on individual machines. API keys that function like accounts but often get treated as configuration rather than identity. Shared accounts that a team uses collectively because nobody got around to setting up individual access.

Each of those is an entry point. Each of those needs to be in the inventory. Most organizations, when they actually look, find more accounts than they expected across more systems than they were tracking.

What an inventory actually means

This control isn’t just about knowing accounts exist. It’s about maintaining something usable. A username list is a starting point, not an inventory. At a minimum, you need to know who or what the account belongs to, what its business purpose is, and when it was created. That’s what allows you to answer the questions that actually matter: Who does this account belong to? Why does it exist? Should it still exist?

The drift problem

Account lists grow over time, and they rarely shrink on their own. New employees are added. Vendors get access for a project. Temporary accounts get created for testing. Some of those get cleaned up. A lot of them don’t.

The result is an environment that accumulates accounts no one is actively managing. Former employees who were offboarded from HR but not from every system they touched. Vendor accounts that outlasted the engagement. Service accounts tied to applications that were decommissioned two years ago. This isn’t usually the result of bad decisions. It’s the result of time and inattention.

That’s the drift problem. And it’s more common than most organizations want to admit when they first look.

Inventory is not a one-time exercise

CIS 5.1 requires accounts to be validated on a recurring basis, at minimum quarterly. That cadence exists for a reason. Environments change constantly. People are hired, promoted, transferred, and terminated. Vendors come and go. Systems get stood up and taken down. A quarterly review forces the organization to reconcile what exists against what should exist and close the gap between the two.

In practice, that review should answer a few specific questions for every account in the inventory. Is this account still tied to an active employee, contractor, or business function? Was access reviewed and approved recently? Is the account still needed, or has the role or project it supported ended? Those aren’t complicated questions, but they require someone to own the process and actually work through the list on a schedule.

Without that discipline, the inventory becomes a historical document. It reflects what was true when you built it, not what’s true now. And an outdated inventory is arguably worse than no inventory at all, because it creates a false sense of control.

From a security standpoint, every account is a potential entry point. Unknown accounts introduce risk because they operate outside your awareness. Unowned accounts introduce risk because no one is responsible for securing them. Neither of those is a condition you want to discover during an incident.

Before you can think about how accounts authenticate or what they’re permitted to access, you have to know they exist in the first place. That’s where this starts, and it’s what the rest of this series builds on.