Even the people who need admin rights shouldn’t use them all day. Most of an administrator’s day is ordinary work: reading email, browsing the web, writing documents. None of that needs admin power. This control says to do that everyday work from a normal account, and switch to the privileged account or role only when you’re actually doing admin or security work.

Here’s why it matters. If an admin reads email while logged in as admin and clicks the wrong link, the attacker instantly has admin control over your environment. If that same click lands on a regular account, it’s a much smaller problem. Separating the two shrinks the blast radius of a bad day.

The “or roles” wording matters if you use role-based access: switching roles can do the same job as switching accounts, as long as the role change truly changes what the person, and their automated processes, can do.

Do everyday work from an everyday account. Save the powerful account for the powerful work.

To be compliant, each of those boxes needs to be real and repeatable:

• A separate non-privileged account (or a role that drops privileges) for each person who also holds admin access.
• Everyday work done from the regular account: email, web, and documents don’t touch the privileged account.
• Privileged accounts used only for admin and security tasks, not routine activity.
• Elevation as the exception, so people log in with normal access by default and step up only when a task requires it. Enforce it technically where you can.
• Records of who holds a separate admin account, plus logs showing privileged accounts aren’t used for routine work.

The idea is simple: the account that can run your environment should barely ever be logged in.

Think in three buckets. An assessor will want all three, so it helps to build them at the same time.

People

• The IT or security lead who owns the account model
• The admins who actually use two accounts, or role-based elevation
• Whoever reviews how privileged accounts are used

Tools

• An identity system that supports separate admin accounts or role elevation
• Logging that shows what privileged accounts are used for
• Somewhere the account model is documented

Documents

• A policy requiring non-privileged accounts for everyday, nonsecurity work
• A list of who has separate privileged and non-privileged accounts, or role-based elevation
• Logs or records showing privileged accounts are used only for admin and security tasks
• A note in your System Security Plan (SSP) describing the account model

You don’t need heavy tooling. You need to show that admins live in a regular account and step up only when the work requires it.

Build this right after 3.1.5. Once you’ve decided privilege should be rare, this control makes sure even the people who have it don’t expose it during routine work. Set it up when you first create admin accounts, because getting an admin into the two-account habit from day one is far easier than breaking a single-account habit later. It also pairs with the next control, which keeps regular users from running privileged functions at all.

A compliant contractor can usually answer yes to all of these:

• Does each admin have a separate, non-privileged account for everyday work?
• Is routine work (email, web, documents) done from the non-privileged account?
• Are privileged accounts or roles used only for admin and security tasks?
• Can you show that privileged accounts aren’t used for routine activity?

If any answer is no, that’s your next place to start.

This control doesn’t stand alone. A few close relationships:

• Least privilege (3.1.5): that control keeps privilege rare; this one keeps even that privilege out of everyday use.
• Privileged functions (3.1.7): the next control keeps non-privileged users from running privileged functions at all, and captures it when they try.
• Audit & Accountability: logging is how you show a privileged account is used only for admin and security work.

Every organization implements these controls a little differently. If you’re not sure whether your approach would satisfy an assessor, join one of our upcoming webinars or schedule a 15 Minutes with FutureFeed session. We’d rather answer your questions now than have you discover them during an assessment.