What AC.L2-3.1.6 non-privileged account use asks for
AC.L2-3.1.6 asks an organization to make sure that administrators and other privileged users do not perform everyday, nonsecurity work with their elevated access. Picture an administrator who reads email, browses the web and opens documents from the same account that changes firewall rules or adds users to a directory. If that session picks up a phishing link or a browser exploit, the malware inherits administrative rights from the start. The requirement is meant to separate those two activities: security functions run through a privileged account or role, and nonsecurity functions run through a standard account. In the CMMC Level 2 model, the requirement is a derived requirement carried over from NIST SP 800-171 Rev. 2, and it is worth 1 point in scoring. The wording here is our own explanation, so check the exact text in the Level 2 model and the NIST publication before you write policy language.
Making this work is harder than the policy suggests. Administrators often work from a shared or single workstation where a standard account and a privileged account are both logged in, and switching is inconvenient. Habit pulls people back to the account they already use for everything. Many organizations also make the administrator account the mailbox or the calendar owner, which means the privileged identity is exposed to the same phishing traffic as every other user. Each of these conditions can be fixed, but none is fixed by a written policy alone. The reader should inventory which privileged accounts also hold mail, web or document rights, and decide whether each one needs to be split, moved to a separate administrative workstation, or restricted by role.
Which systems, accounts and people fall under AC.L2-3.1.6
AC.L2-3.1.6 applies wherever a privileged account can reach the CUI system and the nonsecurity work that account performs. Scoping starts with the CUI boundary, then follows the people, accounts and workstations inside it. The decisions below determine how much separation the organization must build and how much evidence it must produce.
The CUI system boundary
The requirement applies to the systems that store, process or transmit CUI and to the accounts that can administer them. Map every component inside the boundary, including identity services, directories, logging and backup systems that privileged users can change. Confirm with your assessor which supporting systems count as in scope, because an administrator who can alter a directory that controls CUI access affects the boundary even if that directory holds no CUI itself.
Domain, network and application administrators
Identify every account with elevated rights, including domain administrators, local administrators, network device administrators and application owners. Shared or generic admin accounts should be resolved before assessment because each must be traceable to one person. Build a list of who holds each privilege and the nonsecurity tasks they perform, so the organization can show which people need a separate everyday account.
Cloud tenant administrators
Cloud tenants that store or process CUI, such as hosted email, collaboration suites and infrastructure consoles, are generally treated as part of the assessed environment when CUI reaches them. Global administrators, subscription owners and billing roles all carry privilege. Decide whether these roles sit under the same non-privileged account model as on-premises administrators, and document the role assignments that show it.
Dedicated administrative workstations
Whether administrators use a separate workstation changes the work substantially. A shared workstation used for both email and privileged sessions requires strict role separation and browser restrictions. A dedicated, hardened administrative workstation with no general web or email access makes the separation easier to show, but it adds purchase, patching and management effort. Ask the assessor how they expect the separation to be demonstrated before choosing a design.
Nonsecurity functions in scope
Nonsecurity functions are the everyday tasks that do not change security settings, such as email, web browsing, office productivity and general file work. Each must be listed, because the requirement is met only when privileged users perform them under a non-privileged account or role. Office suites, collaboration tools and browsers used on admin machines all belong on this list, along with any tool that can open untrusted content.
Privileged users who are also general users
Staff who hold privilege only occasionally, such as on-call engineers or help desk staff, still fall under the requirement. The question is whether their everyday session runs under a non-privileged identity. Confirm how elevation is requested, whether it is time-limited, and whether the organization can show logs of each elevated session, because occasional privilege is still privilege that assessors will test.
How an assessor tests non-privileged account use
The first assessment objective under AC.L2-3.1.6 asks whether the organization has identified its nonsecurity functions. These are the everyday tasks an administrator performs under an elevated account when it is not a security or administrative action, such as email, web browsing, document editing and general application use. NIST SP 800-171A treats this identification as a separate test, so an assessor will ask for a written list rather than inferring it from the system design.
- Scope of the list: It should name each nonsecurity function that users with privileged roles can reach from the system, including functions on administrator workstations.
- Ownership and approval: Show who maintains the list and the date it was last reviewed.
- Alignment with the system security plan: Functions listed here should match the system boundary and the privileged roles described elsewhere.
- Coverage of new tools: Adding a collaboration tool or browser extension should prompt an update to the list.
Before the assessment, confirm with your assessor which artifact format they accept for this list and whether they expect it to be version controlled.
The second objective asks whether users are required to use non-privileged accounts or roles when they access nonsecurity functions. An assessor tests this by comparing who holds privileged rights with the accounts those people use for daily work. The evidence is the mapping itself: each administrator should have a separate standard identity for email and browsing, and the privileged identity should be reserved for administrative work.
- Dual-identity records: Account inventories should pair each privileged user with a non-privileged account.
- Role definitions: Show which roles lack rights to administrative functions and which roles hold them.
- Directory exports: Current group memberships from the identity provider, such as group lists exported from directory services, support the mapping.
- Exceptions: Any administrator who works from a single account must have a documented, approved reason.
The assessor will sample accounts, so keep the records current and consistent with what the directory shows on the assessment day.
SP 800-171A allows assessors to test the mechanisms that implement least privilege, not only the policy that describes them. For AC.L2-3.1.6, this means checking whether the system actually prevents a privileged account from being used for nonsecurity work or, at minimum, makes that use visible. Potential evidence includes least privilege procedures, the list of system-generated security functions assigned to accounts or roles, configuration settings and audit records.
- Configuration evidence: Show settings in the identity provider, operating system or directory that restrict privileged group membership to administrative sessions.
- Authentication separation: Demonstrate that privileged sessions require a different login path than daily work, where the platform supports it.
- Audit records: Logs that show privileged accounts used for browsing or email are a finding, so confirm that logging is enabled and retained.
- Test results: A live demonstration in which a sample administrator attempts a nonsecurity task under the privileged account is strong evidence.
Confirm with your platform documentation which controls are native and which need a third-party tool before you promise a specific mechanism.
Assessors also talk to people. The CMMC Assessment Guide Level 2 expects system administrators and other privileged users to be trained not to use privileged accounts for everyday tasks such as browsing the internet. Interviews check whether administrators understand the rule, can explain their dual-account practice, and know where to go when they are unsure. Training records show that the instruction was delivered and repeated.
- Interview preparation: Administrators should describe their own workflow accurately, without guessing at the answer.
- Training content: Materials should explain the nonsecurity functions list and the account to use for each task.
- Completion records: Keep dated attendance or completion records for privileged users, including new hires and role changes.
- Refresher cycle: Show how training repeats when roles change or the nonsecurity functions list is updated.
Before assessment day, ask your team to walk through the interview questions with a colleague who does not run the system, and confirm that every privileged user has a completed training record.
How to implement non-privileged account use in steps
This sequence gives each privileged user a standard account for everyday work, limits privileged accounts to security tasks, and produces the inventory, configuration and training records an assessor needs to test AC.L2-3.1.6.
Inventory every privileged account and role
The system owner, with the identity team, lists every account, group and role that can change security settings, manage other accounts, or reach security functions. Include local administrator accounts on workstations and servers, directory administrators, cloud tenant administrators and service roles tied to people. The output is a privileged account register with the owner, system and justification for each entry. Confirm the list against directory group membership and local admin group membership rather than relying on memory, because assessors will compare the register with system settings.
Define the nonsecurity functions for standard accounts
The security team and system owner write down the nonsecurity functions that must run from a standard account, such as email, web browsing, office productivity, document editing and general application use. Record which functions remain privileged because they change security configuration, such as account management, audit settings and firewall rules. The output is an approved list of nonsecurity functions that the system security plan can reference. Assessors look for this list because the requirement cannot be tested without knowing which functions are nonsecurity functions.
Create standard accounts or roles for each administrator
For each person in the privileged register, the identity team creates a separate standard account or role for everyday work and keeps the privileged account for security tasks only. Use distinct naming, such as a clear prefix or suffix, so logs show which identity was used. In a directory such as FreeIPA or a federated setup fronted by authentik, configure the standard account with the access it needs for nonsecurity applications only. The output is a paired account list showing each administrator's standard and privileged identities, approved by the account owner.
Restrict privileged accounts to security tasks
Remove privileged group membership from standard accounts, and remove local administrator rights from the day-to-day accounts used for email and browsing. Limit the privileged accounts to the defined security functions, and block them from common applications such as mail clients and web browsers through application allow lists or access policies where the platform supports them. Confirm each setting in the directory and on endpoints. The output is a configuration baseline that shows privileged accounts cannot be used for nonsecurity functions by default.
Configure enforcement for privileged sessions
Enforce the separation technically rather than relying only on instruction. Options include a separate administrative workstation used only for privileged work, session policies that block browsing and mail from privileged sessions, and access gateways that require the privileged identity only for administrative paths. Document which option the organization chose and why, and confirm the configuration with a test login. The output is configuration evidence, such as policy exports, workstation build records and test results, that an assessor can review.
Train administrators on the separation
Train every system administrator and other privileged user on when the privileged account may be used, why email and web browsing must use the standard account, and how to report a mistake. The CMMC Assessment Guide expects privileged users to be trained not to use privileged accounts for everyday tasks such as browsing the internet. Record attendance, the training content version and the acknowledgment from each person. The output is a signed or electronically acknowledged training record for each privileged user, tied to the register from the first step.
Collect audit evidence and review the separation
Enable logging of privileged logons and privileged sessions, then sample the logs to confirm that privileged identities are used for security tasks and not for web or mail activity. Review the register and group memberships on a schedule the organization defines, and record exceptions with an owner and a closure date. Keep the final versions of the register, configuration exports, training records and log samples together, since assessors accept only evidence in final form. The output is an evidence package that can be shown to the assessor and updated when administrators or systems change.
Which evidence shows administrators use non-privileged accounts
Assessors look for a paper trail and a working control, and the two have to agree. The artifacts below cover the definitions, the configuration that enforces separation, the logs that prove it happened, and the training that explains why. Keep each one current between assessments so that a sample pulled at any time matches what the system does.
List of nonsecurity functions
This is the defined list of activities that privileged users perform without needing elevated rights, such as email, web browsing, office productivity and document editing. Assessors start here because the requirement only applies to functions you have named. Review the list when you add a SaaS tool or change a workstation image, and record the review date and approver so the list is traceable.
List of security functions by account
This inventory maps each system-generated security function, such as managing accounts, changing audit settings or altering firewall rules, to the specific account or role allowed to perform it. It shows that security tasks are deliberately assigned instead of defaulting to a shared administrator login. Reconcile it against directory group membership at each review, since drift between the mapping and actual role assignments is a common finding.
Least privilege procedures
These written procedures describe how privileged accounts are requested, approved, granted, reviewed and removed. They should state that administrators hold a separate, non-privileged account for daily work and a privileged account used only for security tasks. Confirm the procedure matches what the identity team actually does, because assessors compare the document with interviews and tickets.
Configuration settings enforcing separation
Exports from the identity provider, directory and endpoint management tools show the enforced setting, such as a privileged group that cannot sign in to mail or browsing applications, or a workstation policy that removes local administrator rights from daily accounts. Keep dated screenshots or config exports for each platform in scope. Re-export after every upgrade, because defaults change and an old export can misrepresent current enforcement.
Audit records of privileged logons
Logs should show that privileged accounts authenticate for security tasks and do not appear in sessions for email, web or document work. Correlate logon events with application access records so that an assessor can see both the logon and the activity that followed. Retain these logs under your audit policy, and set a recurring review that flags privileged accounts used outside the defined security functions.
Training records for administrators
The assessment guide expects system administrators and other privileged users to be trained not to use privileged accounts for everyday tasks such as browsing. Keep signed attendance or learning platform records with dates, course content version and the names of the people trained. Retrain on a schedule and whenever a new administrator joins or the procedure changes, and confirm the cadence against your own policy.
What meeting AC.L2-3.1.6 costs in money and effort
This table breaks the cost of meeting AC.L2-3.1.6 into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure requests for quotes and to separate internal work from outside help. No price figures are given because none are supplied for this requirement, so the drivers and quote items matter more than any number.
| Cost component | Who is paid or who does the work | One-time or recurring | Main cost drivers and what to request in a quote |
|---|---|---|---|
| Directory and identity tooling | Identity platform vendor or open-source project, plus internal or partner engineers | One-time setup, then recurring licensing or support where applicable | Existing identity platform, number of applications to integrate, and whether separate admin accounts need their own directory groups. Request a list of licenses, support terms and integration scope. |
| Workstation or virtual desktop changes | Internal IT staff or implementation partner | One-time build, recurring image maintenance | Number of administrator workstations, whether a separate admin desktop or jump host is used, and how many images must be maintained. Request the build plan and image update schedule. |
| Engineering time to create separate roles and restrict privileged accounts | Internal engineers or an implementation partner under a fixed-scope agreement | One-time for initial role design, recurring for changes | Number of privileged systems, number of administrators, and how many nonsecurity functions must be mapped. Request a written list of systems in scope and the role matrix deliverable. |
| Training time for administrators and privileged users | Internal staff time, trainer fees if external | Initial training one-time, refresher training recurring | Number of privileged users and turnover rate. The CMMC Assessment Guide Level 2 expects privileged users to be trained not to use privileged accounts for everyday tasks such as browsing. Request training content, attendance records and refresher cadence. |
| Evidence upkeep and periodic review | Internal compliance staff or a partner preparing evidence | Recurring | Frequency of access reviews, number of systems producing logs, and how much evidence must be retained. Assessors look for final-form evidence, so request a sample evidence package and review schedule. |
| Assessor fees, if a certification assessment applies | Certified third-party assessor organization (C3PAO) for Level 2 certification, or self-assessment staff time | Recurring at each assessment cycle | Whether the contract requires certification or self-assessment, and the scope of the assessment. The Department of War suspended Phase II on 13 July 2026, so confirm the current assessment requirement with the contracting officer before budgeting. |
| Proof and testing support | Internal testers or an outside security testing firm | Recurring, often tied to review cycles | Number of privileged accounts sampled and whether assessors need test results of role restrictions. Request a test script showing how non-privileged use is verified. |
Who does what for non-privileged account use
Your organization owns AC.L2-3.1.6 and every decision about it. Leadership and the security function define the policy that says which tasks are nonsecurity functions and which accounts may perform them. Your team also decides how privileged accounts are named, issued and retired, and it is accountable for whether administrators actually follow the rule day to day, because no tool can enforce behavior that people are not trained to follow.
- Policy and scope: Define which activities count as nonsecurity functions, such as email, web browsing and document editing, and state that privileged accounts must not perform them.
- Account and role model: Decide which roles hold privileges and maintain separate standard accounts for administrators.
- Workstation standards: Specify the admin workstation or standard workstation each administrator uses for daily work.
- Training: Train system administrators and other privileged users not to use privileged accounts for everyday tasks such as browsing the internet.
- Ownership of records: Keep the signed policy, role assignments and access reviews that show the rule is in force.
Before any assessment, confirm that each privileged user can name their standard account and that the policy text matches what administrators do.
An implementation partner prepares the technical side of the control. DeployOpen, for example, configures identity and access systems inside your own environment, separates privileged and standard roles where your platforms allow it, and organizes the evidence so an assessor can follow it. The partner works from the policy and role model your team approves. It does not set the policy, decide who is privileged, or judge whether the control is met.
- Identity configuration: Set up the identity provider so that applications authenticate against a single source of accounts, with separate groups or roles for privileged and standard use.
- Role design: Map privileged roles to the platforms and tools that need them, and document which functions each role can reach.
- Logging and evidence packages: Collect configuration exports, role assignment listings and audit records that show the separation is enforced.
- Platform hardening: Confirm that privileged sessions are used only for security functions in the systems the partner builds.
- Documentation: Write the procedures and configuration records that your team reviews and signs.
Ask any partner to state in writing which parts of the work it performs, which evidence it prepares, and that the outcome is determined by your organization and the independent assessor.
The independent assessor tests AC.L2-3.1.6 against the assessment objectives in NIST SP 800-171A. For a Level 2 certification, that assessor is a C3PAO authorized or accredited by The Cyber AB. The assessor first confirms that nonsecurity functions have been identified, then checks that privileged users are required to use non-privileged accounts or roles to reach them. Assessors may examine the mechanisms that enforce least privilege, not only written policy.
- Objective review: Check that the listed nonsecurity functions match what the environment actually provides.
- Configuration testing: Test whether a privileged account can reach a nonsecurity function, and whether the standard account is used for it.
- Evidence review: Examine configuration settings, role listings, audit records and training records in final form.
- Interviews: Ask administrators how they perform daily tasks and whether they understand the rule.
- Independent result: Only the assessor determines whether the requirement is met and issues the outcome.
Confirm the assessor's accreditation status with The Cyber AB and keep your evidence in final form before the assessment begins.
Where organizations fall short on non-privileged accounts
Most failures against AC.L2-3.1.6 are not missing technology. They are gaps between a written rule and what administrators actually do on a Tuesday afternoon. The cards below cover the habits, records and enforcement gaps that assessors most often find, and what to change for each.
Admins reading email from privileged accounts
The most common failure is an administrator who opens mail, browses the web or edits documents while signed in with the account that can change directory settings or security configuration. The fix is a separate standard account for everyday work, with the privileged account used only for administrative sessions. Check whether any privileged identity has a mailbox or a web proxy profile, because either one is a signal that the split is not real.
No list of nonsecurity functions
The requirement turns on which functions are nonsecurity functions, and assessors cannot test enforcement without that list. Many organizations have never written one. Document the functions administrators perform from the standard account, such as email, web, office productivity and general file access, and map each to the roles that may perform it. Keep the list under configuration control so it changes when the environment does.
Privileged accounts with mailboxes
A mailbox, calendar or collaboration license attached to an administrator account gives that account a route into phishing and attachment exposure it does not need. Review directory objects for privileged identities that carry mail or productivity licenses, and remove them where the business can operate without them. Where a mailbox must exist for an administrative purpose, record that exception and its approval.
Shared administrative accounts
A shared admin login makes it impossible to tie an action to one person, which weakens the non-privileged split and the audit trail that supports it. Replace shared credentials with named privileged accounts, each linked to a standard account for the same person. Confirm that the identity provider or directory records who used which account, and that the shared accounts are either retired or tightly restricted and monitored.
Missing training records
The CMMC Assessment Guide expects system administrators and other privileged users to be trained not to use privileged accounts for everyday tasks such as browsing. A policy that no one has acknowledged does not show that training happened. Keep dated training content, attendance or completion records for each privileged user, and a refresher schedule. Ask the assessor during planning which training evidence they will accept.
Policy without technical enforcement
A rule that says administrators must not browse from privileged accounts is weak if nothing stops them. Enforcement comes from role design: privileged roles that do not grant mail or general web access, conditional access or session policies that restrict where privileged sign-ins can be used, and reviews of directory and log data that show whether the rule holds. Test it by attempting the forbidden action from a privileged session and keeping the result.
How long and how much effort does AC.L2-3.1.6 take to meet?
Is AC.L2-3.1.6 expensive to meet compared with other CMMC requirements?
Usually not on its own. AC.L2-3.1.6 is a single practice, and the cost sits in the work behind it: deciding which accounts are privileged, creating a separate non-privileged account for each administrator, and proving that the separation holds. Most of the effort is configuration and documentation, not new tooling. No cost figure is supplied for this requirement, so ask any provider for a written, scope-based quote that lists the number of administrators, systems and identity sources in your environment. Costs recur mainly when administrator rosters change and evidence must be refreshed.
How much time does it take to implement non-privileged accounts for administrators?
The duration depends on how many administrators you have, how many systems they touch, and whether accounts are already separated. A small environment with one identity source and a few administrators can often move faster than a large environment with local accounts on many servers. No duration is supplied for this requirement, so confirm timing against your own asset inventory and change windows before you commit to a schedule. Plan extra time for testing, because administrators must be able to do their jobs from the new accounts.
Can our internal team meet AC.L2-3.1.6 without outside help?
Yes, many teams can, provided they have someone who understands identity management and can write the evidence clearly. The work is mostly administrative: define the nonsecurity functions, assign non-privileged roles, configure separation in your directory, and train administrators. Outside help is most useful for designing the identity layer, hardening it and preparing evidence in a form an assessor will accept. Organizations own their controls. An implementation partner such as DeployOpen can prepare systems and evidence, but only an independent assessor issues results.
What do administrators have to do differently day to day?
Administrators must sign in with a standard account for email, web browsing, document work and other everyday tasks, and use a separate privileged account only for security and administrative functions. This change affects habits, so it needs clear written rules and short training. The CMMC Assessment Guide Level 2 expects privileged users to be trained not to use privileged accounts for everyday tasks such as browsing the internet. Expect some friction in the first weeks, and plan for help desk questions about which account to use.
Can AC.L2-3.1.6 go on a POA&M, and what does that require?
Under the supplied rule facts, AC.L2-3.1.6 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21, so it may be placed on a plan of action and milestones (POA&M) for Conditional Level 2 status. That status requires a score of at least 88 of 110 (0.8), and closeout is due within 180 days. Treat this as a fallback, not a plan. Ask your sponsor or contracting officer how they will treat a Conditional status, and confirm the scoring rules in the eCFR before relying on it.
Which CMMC phase status should we confirm before planning this work?
Confirm the current phase status on the DoW CIO About CMMC page before you set a deadline. Supplied facts indicate that the Department of War suspended Phase II on 13 July 2026, with a 60-day review by a CMMC Reform Task Force, while Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. The same facts note that the eCFR still shows the original four-phase schedule. Ask your contracting officer which assessment type applies to your contracts, and plan the control work regardless, because the requirement itself does not change.
What evidence should we collect so the effort is not repeated at assessment time?
Collect evidence while you configure the control. Keep the list of nonsecurity functions, the list of system-generated security functions assigned to accounts or roles, the configuration settings that enforce separation, and audit records showing that privileged accounts are used only for privileged work. NIST SP 800-171A names these as potential evidence for 3.1.6. Keep final, dated versions, not drafts. Build these records into your administrator onboarding and review cycle so they stay current without a separate project.
How DeployOpen prepares non-privileged account evidence
DeployOpen starts this work with a fixed-scope, written engagement that names the privileged account population before any configuration begins. In practice that means listing the administrator roles, service and break-glass accounts, and the nonsecurity functions those people use every day, such as email, web browsing, document work and collaboration tools. The scope also records which systems sit inside the CMMC assessment boundary, because an assessor will only test accounts that belong to systems in that boundary. Your organization owns the decision on which functions count as nonsecurity and which accounts are privileged. DeployOpen documents the proposed model so your security lead can approve or amend it before build work starts.
Once the model is approved, DeployOpen implements the separation in your own infrastructure using self-hosted open-source platforms. Identity is typically handled by a directory service such as FreeIPA, which provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, and an identity provider such as authentik, which delegates sign-in to applications through OAuth2, OpenID Connect, SAML, LDAP and proxy providers. The work covers separate administrator identities that are not used for mail or browsing, group and role assignments that keep the everyday account free of administrative rights, and application configuration that routes sign-in through the identity provider. Ask the implementer to show which configuration keys, group memberships and provider settings enforce each rule, and to confirm that each platform's capabilities match your environment before you rely on them.
The evidence package is what an assessor reads, so DeployOpen assembles it alongside the configuration. It typically includes the approved privileged account model, the role and group definitions, exported configuration showing enforcement, a list of accounts with their assigned roles, and the training record for administrators on not using privileged accounts for everyday tasks. Your organization must keep this evidence in final form, since drafts do not satisfy the assessment objectives. DeployOpen does not issue audit reports, attestations or certifications. Only an independent assessor or C3PAO can assess the control and issue a result, so ask any implementation partner to explain in writing which artifacts it produces and which decisions remain with your organization and the assessor.
