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.

So what counts as a nonsecurity function? That question is the heart of this requirement.

• Nonsecurity functions: email, web browsing, document editing, collaboration tools, ordinary business applications, and routine ticket work.
• Privileged or security functions: changing security configurations, administering accounts, modifying permissions, installing or configuring protected system components, managing security tooling, and any change that requires elevated rights.

The account or role you use should match the function you are performing. That is worth remembering more than “administrators need two accounts.”

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

To implement this effectively, each of those boxes needs to be real and repeatable:

• A non-privileged working context for each person who holds admin access: a separate regular account, or a role that carries no privilege until they elevate.
• 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 privileged access and how they elevate, plus logs showing what privileged accounts are used for.

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

Here is the order I would work through it in a real environment:

Think in three buckets. Building your evidence across all three helps you show that the requirement is implemented, not just documented.

You do not need heavy tooling. What matters is that administrators live in a regular account, step up only when the work requires it, and that you can see it happening.

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.

An administrator signs into their workstation with normal user privileges. They read email, browse the web, work tickets, attend meetings, and create documents without administrative rights. When an administrative task comes up, they deliberately authenticate or elevate into a privileged context, perform the task, and return to their normal context. The privileged activity is logged and attributable to them.

That is what it looks like in practice. An organization implementing this requirement well can usually answer yes to all of these:

• Does everyone with admin rights have a non-privileged way to do 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?
• Is privileged activity logged, attributable to a person, and reviewed?

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.