This is one of the practices where small contractors fail not because of technical capability, but because of habit. Your IT person has a global admin account and uses it for everything: checking email, browsing the web, managing servers, ordering lunch. The assessor will look for evidence that privileged accounts are reserved for privileged work. This practice pairs directly with AC.L2-3.1.5 (least privilege) and AC.L2-3.1.4 (separation of duties), and connects to AC.L2-3.1.7 (preventing non-privileged users from executing privileged functions). Get this one right and those two get easier.
What the assessor is actually evaluating
The assessor is checking whether your admins live in their admin accounts all day or whether they use them only when they need to. This sounds simple. In practice, it’s one of the most common gaps in small organizations.
Here’s what the assessor will specifically look at: Does every person with privileged access also have a separate standard account? Is there a naming convention that makes it obvious which is which? Can you show sign-in logs proving the admin accounts aren’t being used for email, Teams, web browsing, or other daily activities?
The reasoning behind this practice is straightforward. A compromised admin account is catastrophic. A compromised standard account is bad but contained. If your IT person browses a malicious website while logged in as a global admin, the blast radius is your entire environment. If they browse that same site on a standard account, the damage is limited to that account’s permissions. The assessor understands this and wants to see that you do too.
The assessor will also check whether this applies to your MSP’s accounts in your environment. If your MSP has admin credentials that their engineers use for everything including checking your ticket queue, that’s the same problem wearing a different hat.
What a realistic SSP definition looks like
[Organization Name] requires all personnel with privileged access to maintain separate non-privileged (standard) accounts for everyday use. Privileged accounts are used exclusively for administrative functions such as system configuration, account management, and security operations.
Privileged accounts follow a naming convention that distinguishes them from standard accounts (e.g., adm.jsmith@ for admin, jsmith@ for standard). Standard accounts are used for email, web browsing, document editing, and other non-administrative tasks. Privileged accounts are not assigned email licenses or web browser access.
Sign-in activity for privileged accounts is monitored to verify they are only used for administrative purposes. Anomalous usage patterns, such as a privileged account accessing email or browsing the web, trigger an alert for review.
Notice a few things about that language:
It describes the naming convention. The prefix pattern (adm.jsmith@) makes it instantly visible which account is which. When the assessor pulls up your user list, they can see the separation at a glance. Some organizations use a suffix or a completely separate naming scheme. The method matters less than being consistent and obvious.
It removes temptation. The SSP says privileged accounts don’t have email licenses or browser access. That’s active technical enforcement beyond written policy. If the admin account physically can’t open Outlook, nobody is going to accidentally check email with it.
It includes monitoring. Sign-in logs are reviewed to make sure the separation is happening in practice. This is where the assessor will focus: not on whether the policy exists, but on whether the behavior matches.
How to present your evidence
- User list showing separate standard and privileged accounts with clear naming convention
- License assignments showing privileged accounts lack email/productivity licenses
- Sign-in logs for privileged accounts showing only administrative portal access
- Sign-in logs for standard accounts showing daily-use activity
- Conditional access policy or technical control restricting privileged account usage (if implemented)
Start with the user list. Pull up your identity provider and show the assessor your accounts. They should be able to immediately see which accounts are standard and which are admin based on the naming convention. Point out that every person with an admin account also has a corresponding standard account.
Then show the license assignments. Admin accounts should not have email, Office apps, or other productivity licenses. This is the strongest evidence because it demonstrates actual technical enforcement, going beyond a mere policy statement.
Finally, pull up sign-in logs. Show that the admin accounts are only signing into admin portals and management consoles. Show that the standard accounts are the ones hitting email, Teams, and SharePoint. The contrast between the two tells the whole story.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
One account for everything. The IT admin has one account that's both their daily driver and their admin account. Email, Teams, SharePoint, and also Exchange admin, Azure admin, and firewall management. This is the most common finding for this practice.
Separate accounts exist but aren't used properly. The admin account was created, but sign-in logs show it accessing email three times last week. The policy exists but behavior doesn't match. The assessor will check.
No naming convention. The user list has accounts like "admin1" and "helpdesk" mixed in with standard user accounts and there's no systematic way to tell which is which. The assessor shouldn't have to guess.
MSP admin accounts ignored. The contractor's own staff have proper separation, but the MSP's accounts in the environment don't follow the same standard. If the MSP has admin access, those accounts need the same treatment.
Clear naming convention visible in the user list. License assignments that technically prevent admin accounts from accessing email and productivity tools. Sign-in logs that match the policy. MSP accounts following the same standard. When the assessor can see the separation in both the configuration and the behavior, this is a quick practice to clear.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
This practice has a direct implication for your MSP. Their engineers probably have admin accounts in your environment. Those accounts need to follow the same separation standard as your internal accounts.
The assessor will ask about this. “What about your MSP’s admin access?” is a near-certain question. Your MSP should be prepared to explain their own account structure: how their admin accounts in your environment are separate from any accounts they use for daily operations, how those accounts are named, and how usage is monitored.
The best MSSPs I’ve worked alongside already enforce this by policy. Their engineers have separate admin credentials per customer environment, those credentials are stored in a privileged access management system, and sign-in activity is logged and reviewed. If your MSP gives their engineers one set of credentials that’s used for both admin work and checking tickets, that’s a gap.
The MSSP should be in the room for this one. The assessor will want to hear directly from the person who manages those admin accounts, not a secondhand explanation from the contractor.
Assessors check sign-in logs for this one. If you claim separate accounts but the logs show your admin account checking email, you lose the practice. Make sure your technical controls match your policy. Remove email licenses from admin accounts. Use conditional access to restrict admin account usage if you can. The assessor wants to see that you've made it technically difficult to misuse admin accounts, not just that you've written a policy.
Ask your MSP to show you their admin accounts in your environment. Do they follow a naming convention? Are they scoped to admin functions only? Can your MSP produce sign-in logs for their admin accounts showing administrative use only? If they can't answer these questions, that's a conversation to have before the assessment, not during it.
This page covers AC.L2-3.1.6 from NIST SP 800-171 Rev 2 (3.1.6). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.