AC.L2-3.1.7 Privileged functions

AC.L2-3.1.7 asks you to stop non-privileged users from running privileged functions and to log every time a privileged function runs. This page covers what assessors test, the evidence that passes and what the work costs.

Book a callTalk to us
On this page

What AC.L2-3.1.7 privileged functions requires and why assessors check it

AC.L2-3.1.7 requires a defense contractor to stop non-privileged users from executing privileged functions and to capture every execution of those functions in audit logs so misuse can be detected. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.7, a derived security requirement in the Access Control family. The risk it addresses is familiar: an ordinary user account, a compromised workstation or a service account with more rights than its job needs can change security settings, export CUI, create accounts or disable logging. Without enforcement, the privileged functions sit one click away from everyone who can log on, and without logging, nobody notices when they are used.

The hard part is that the requirement cannot be met until the organization defines what counts as a privileged function. Assessors start by asking for the list: which functions (for example, managing user accounts, changing audit settings, altering firewall rules, reading or exporting CUI in bulk, or installing software on servers) are privileged, and which accounts and roles are assigned to them. The assessment objectives in NIST SP 800-171A then test four things: that privileged functions and non-privileged users are defined, that non-privileged users are prevented from running privileged functions, that those executions are captured in audit logs, and that the mechanisms behind both enforcement and auditing are in place. A list that names only the obvious administrator tasks will not satisfy the assessor if the system allows other paths to the same functions.

Before the assessment, confirm three things with your own environment: the privileged function inventory is current and approved, role and group assignments in your identity and directory systems match that inventory, and audit records show who ran each privileged function, when, and on which system. Ask your assessor or your implementation partner which logs they expect to see and whether they want sample entries from each privileged function. Because this requirement carries 1 point in the scoring model, its treatment on a POA&M matters for Conditional status, so confirm current scoring and POA&M rules against the eCFR text of 32 CFR Part 170 before you plan around them.

Which systems, accounts and third parties fall under the privileged function requirement

AC.L2-3.1.7 applies wherever privileged functions touch systems that process, store or transmit CUI, so scope is set by the CUI boundary and the people who can change it. The cards below cover the decisions that most often change the amount of work, and each one should be settled and written down before evidence collection begins.

Systems inside the CUI boundary

Start by listing every system that processes, stores or transmits CUI, including directory services, backup platforms, logging stores and management consoles that can reach those systems. Privileged functions on these components are in scope even when the component holds no CUI itself, because an administrator there can change how CUI is protected. Ask the assessor to confirm the boundary early, since a narrow boundary reduces both the function list and the log sources you must prove.

Which admin consoles count as privileged

Privileged functions include more than the operating system root or domain admin role. Hypervisor and cloud control planes, firewall and VPN management, security tool configuration, key management and audit log settings all change security behavior. Build one inventory that names each function, the accounts allowed to run it and the system where it runs, so that assessors can test enforcement and logging function by function.

Managed service providers with privileged roles

When an external provider administers an in-scope system, its engineers hold privileged functions even though they are not your employees. Document which provider roles can run which functions, whether they use dedicated accounts, and where their actions are logged. Confirm the provider's own environment is in scope or is covered by a separate assessment, since the provider's logs and access paths may become part of your evidence.

Cloud administrators and tenant roles

Global administrators, subscription owners and project owners in cloud tenants can create accounts, change logging and grant themselves further access. Treat these roles as privileged functions wherever they can affect CUI systems, and check whether the tenant's own audit logs capture role assignments and privileged actions. Confirm with your cloud provider which administrative actions are recorded and for how long, because gaps here are hard to fix retroactively.

Shared administrative accounts

A shared administrator account makes it impossible to attribute a privileged action to one person, which weakens both the enforcement and the audit objectives of AC.L2-3.1.7. Decide whether shared accounts will be retired, or whether each privileged action will be traceable through individual named accounts or elevation records. If a shared account must remain, document who knows its credentials, how access is checked out and how each session is logged.

Security functions and audit settings

Accounts that change audit configuration, disable logging or alter security alerting are privileged even when they never touch CUI directly. Assessors look for these functions because misuse here hides every other misuse. Restrict them to named roles, keep their executions in logs that the function's own users cannot edit, and list them in the same inventory as other privileged functions.

How an assessor tests privileged function control and audit logging

The first check is definitional. Before an assessor can test whether non-privileged users are blocked, the organization must be able to say which functions are privileged and which user accounts are authorized to perform them. NIST SP 800-171A treats this as its own assessment objective, covering both privileged functions and non-privileged users. Assessors typically start by asking for the written list and then compare it against the live system, so a list that does not match the configuration will fail this check even if the enforcement is sound.

  • Privileged function list: A written inventory of functions such as adding or removing accounts, changing security settings, installing software, and reading or changing audit configuration.
  • Assigned accounts: The named accounts or groups that hold each privileged function, with the approval record for each assignment.
  • Least privilege procedures: The documented process that grants and reviews privileged access, including how the list is kept current.
  • Non-privileged user definition: A clear statement of which roles are not privileged, so the boundary being enforced is explicit.
  • Consistency check: Evidence that the list in the policy matches the groups and roles configured on the systems.

Confirm that the list covers the application, the operating system and the identity provider, since privileged functions often sit in all three. Use the definition in NIST SP 800-171A as the reference for what the assessor will expect to see.

How to implement privileged function control and logging in order

This sequence turns AC.L2-3.1.7 from a policy statement into evidence an assessor can test: a defined list of privileged functions, enforcement that stops non-privileged accounts from running them, audit records for every execution, and a tested proof that both controls work.

  1. Define privileged functions and non-privileged users

    Start by listing the functions in your CUI environment that change security settings, manage accounts, alter audit configuration, or access CUI at an administrative level. Name the non-privileged user population the requirement applies to, such as standard end users and service accounts that should not hold administrative rights. The system administrator and the security owner should agree on the boundary, and the output is a draft function list with a short rationale for each entry. Confirm the boundary against the system security plan before moving on, since assessors compare the two.

  2. Document the function list and assigned accounts

    Turn the draft into a controlled document that records each privileged function, the roles or groups authorized to perform it, and the named accounts assigned to those roles. Include the approval date and the approver, and tie the document to the access control procedures already in place for least privilege. The output is a signed function list with an account-to-function matrix. An assessor will ask for this list first, so make sure it matches what the directory and application role assignments actually show.

  3. Configure enforcement for non-privileged accounts

    Use role-based access controls, operating system group policy, application permission models, and cloud IAM policies to ensure that non-privileged accounts cannot execute the listed functions. Remove standing administrative rights from everyday accounts and require a separate privileged identity for administrative work. In self-hosted platforms, such as Nextcloud administration pages or OpenBao policies, confirm which actions are restricted by role and test them with a non-admin account. The output is a configuration baseline showing the enforced settings, which you should store under change control.

  4. Enable audit capture for each privileged execution

    Turn on logging for every privileged function so each execution creates a record with the user, time, function, and outcome. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory or to a path set with logfile_audit, and OpenBao audit devices keep a JSON log of every API request and response with most sensitive values hashed. Confirm which events your platform captures and where logs are stored, since some privileged actions may not be logged by default. The output is a documented logging configuration with sample records for each function on the list.

  5. Forward and monitor privileged events centrally

    Send privileged audit records to a central store so that misuse can be detected rather than only found after the fact. Platforms such as Wazuh can decode collected logs and compare events against its ruleset, writing matches to alerts.log and alerts.json, and OpenSearch Security Analytics can run detectors against ingested logs using Sigma rules. Write rules that flag privileged executions by unexpected accounts or outside approved windows, then confirm the alert path reaches a reviewer. The output is a rule set and a test alert that shows the chain works end to end.

  6. Test enforcement and logging together

    Test both halves of the requirement with documented cases. Attempt each privileged function from a non-privileged account and record that it is denied, then perform the same function with a privileged account and confirm the audit record appears with the correct identity and timestamp. Run the tests in a non-production copy where possible and keep the raw results. Mapped to the four assessment objectives in NIST SP 800-171A, the output is a test report with pass or fail results per function. Any failure goes back to the configuration step and is retested.

  7. Retain evidence and review on a schedule

    Store the function list, enforcement settings, log samples, detector rules, and test results together in the evidence repository for the system security plan. Set a recurring review to confirm the function list still matches the system after upgrades, new integrations, and staff changes, and retest after material changes. Ask your assessor or C3PAO which evidence form they expect for final documents, because NIST SP 800-171A treats evidence in draft form differently from final evidence. The output is a maintained evidence package that can be produced without rebuilding it.

Which evidence passes the privileged function requirement

An assessor testing AC.L2-3.1.7 looks for two things: that privileged functions are defined and enforced, and that their execution is captured in audit records. The artifacts below connect those two halves, so each one should point to the same list of privileged functions and the same accounts. Every artifact must be final and dated for the assessment period, because a draft does not count toward MET.

Approved privileged function list

This is the starting point for the requirement. It names each privileged function in the system, such as adding accounts, changing audit settings, modifying security configuration and reading protected CUI stores, and lists the accounts and roles authorized to run each one. Assessors compare this list against the accounts in your directory and the enforcement settings. Confirm that the list is approved by the accountable owner, carries a version date, and includes the non-privileged users who must be blocked from these functions.

Least privilege procedures

These procedures describe how privileged rights are granted, reviewed and removed. They explain who can approve a privileged assignment, which roles map to which functions, and how a temporary elevation ends. Assessors use them to judge whether the enforcement in your configuration follows a deliberate design. Keep the procedure current with the function list so that a new privileged function cannot exist without an owner and an approved role.

Configuration exports showing enforcement

Exports of role assignments, group policies, sudo or administrator rules, and application permission settings show how non-privileged users are actually prevented from running privileged functions. Capture them from the live system with timestamps, not from memory or a screenshot taken for the assessment. Each export should match the approved function list, so a reviewer can trace every privileged function to the setting that blocks non-privileged accounts.

Sample audit records of privileged executions

Audit records prove that privileged executions are captured. Pull samples that show who ran a privileged function, what it changed, when it happened and from which system. Include at least one execution by a privileged account and one denied attempt by a non-privileged account, if your logs record denials. Confirm that the audit source is enabled for each function on the list, and that the records are retained and protected according to your audit policy.

Privileged activity review records

Review records show that someone looks at privileged activity after it happens. They include the date of each review, the reviewer, the log scope, the findings, and the follow-up for any execution that did not match an approved change or assignment. Reviews are the evidence that turns captured logs into detected misuse. Keep them signed or otherwise attributable, and confirm that the reviewer is not the same person who executes the privileged functions being reviewed.

Keeping each artifact final and current

Assign an owner, a version number and a review date to every artifact, and store the final copy in your evidence repository. When an account, role or function changes, update the list, the procedure and the export together, then retain the prior version. Before an assessment, check that each artifact covers the full assessment period and that no working drafts are presented as final. A draft or unsigned artifact leaves the objective unmet, even when the control works.

What meeting AC.L2-3.1.7 costs in money and effort

This table breaks the cost of AC.L2-3.1.7 into the work that produces its evidence, from inventorying privileged functions to ongoing log review. Each row shows whether the cost is one-time or recurring, what pushes it up, and how self-hosted open-source tooling can reduce license spend. The 1-point value under 32 CFR 170.24 is the only scoring fact here, so the main takeaway is that the effort lies in the evidence, not the score.

Cost componentOne-time or recurring, and who is paidWhat drives the cost and how to reduce it
Defined function inventoryOne-time to build, recurring to update. Internal staff, with optional consultant time for the initial list.Driven by the number of administrative roles, custom applications and privileged scripts. Reduce it by listing functions once per system and tying each to a named role group.
Configuration and enforcement workOne-time for initial role and permission settings, recurring when systems change. Internal engineers or an implementation partner.Driven by how many platforms hold privileged functions and how well roles are already separated. Reduce it by enforcing privilege through existing role models in self-hosted platforms rather than custom code.
Audit logging setupOne-time configuration per system. Internal engineers, with license cost only where a commercial SIEM is chosen.Driven by the number of log sources and how much event detail each one emits. Self-hosted tools such as Nextcloud admin_audit, OpenBao audit devices and Wazuh can remove commercial logging license spend, but each still needs configuration and testing.
Log storage and reviewRecurring. Storage infrastructure, staff time for review, and any analytics licenses.Driven by retention needs, log volume and how often reviewers examine privileged events. OpenSearch Security Analytics can run detectors against ingested logs, which can reduce manual review, but detector tuning takes ongoing effort.
External review or assessor preparationPeriodic. Consultant or internal preparation time; the assessor is paid separately and remains independent.Driven by how complete the evidence is in final form before assessment. Reduce it by keeping function lists, configuration exports and log samples current, and by asking any preparation provider for a written scope.
Ongoing upkeepRecurring. Internal staff, plus optional retainer support for upgrades and testing.Driven by platform upgrades, staff turnover and new privileged functions added over time. Reduce it by reviewing the function inventory on a fixed schedule and by confirming with each vendor how audit settings survive upgrades.

Who owns the privileged function control, who prepares evidence and who assesses it

The organization owns AC.L2-3.1.7 from start to finish. Only its own staff can decide which functions count as privileged, which people may hold them, and how long audit records are kept. Those decisions are the baseline the assessor tests against, so they must be written down before any tooling is configured. In a Level 2 self-assessment, the organization also performs the testing itself, and the in-house team remains accountable when a log entry shows misuse.

  • Defining privileged functions: Maintain a documented list of privileged functions, such as user administration, security configuration, audit settings and access to CUI repositories, along with the non-privileged users who must be kept away from them.
  • Approving privileged accounts: Record who holds each privileged role, who approved it and the business reason. Review assignments on a set cycle and remove access when people change roles or leave.
  • Owning audit logs: Decide what is logged, where logs are stored, who may read them and who reviews them. Name a reviewer for each log source and keep records showing that reviews actually happened.
  • Signing off the evidence: Approve the system security plan language and the evidence pack before they are shared. Evidence must be in final form, because draft documents do not satisfy the assessment objectives.

Check that each of these decisions has a named owner, a date and a document the assessor can open.

Where organizations fall short on privileged functions and how to close each gap

Most failures against AC.L2-3.1.7 are not missing tools. They are undefined privileged functions, shared accounts, controls nobody tests, logs nobody reads, and administrative actions in consoles that never reach a log. Each card names one gap, what an assessor will notice, and the action that closes it.

Privileged functions never formally defined

Many organizations enforce restrictions on administrators without ever writing down which functions count as privileged. The assessment objective for defining privileged functions and non-privileged users is the first thing an assessor checks, and without a list there is nothing to test against. Build a register of privileged functions per system, covering account management, security configuration, log settings, and data export, and map each function to the roles allowed to run it. Confirm the register is approved and current before the assessment starts.

Shared admin accounts blur privilege

When several people log in as one administrator account, the system cannot show which person ran a privileged function, and any restriction on that account applies to everyone who uses it. Assessors look for the list of user accounts assigned to each privileged function, and a shared login makes that list impossible to state accurately. Replace shared administrator logins with named privileged accounts, separate them from everyday accounts, and restrict each named account to the functions its owner is authorized to run.

Enforcement configured but never tested

A role setting that blocks non-privileged users from a function is only evidence if someone has shown it works. Teams often configure permissions during build and never check them again after upgrades, group changes or new integrations. Plan a recurring test in which a standard user account attempts each defined privileged function and the result is recorded, including the denial message and the time. Keep those test results with the configuration baseline so an assessor can see enforcement in operation, not just in settings.

Audit logs written but never reviewed

Logs that capture every privileged execution still fail the second half of the requirement if no one looks at them. Assessors ask who reviews privileged activity, how often, and what happens when an unexpected change appears. Assign a named reviewer, define a review cadence, and record each review with its findings and any follow-up ticket. A simple checklist of expected privileged activity, compared against the log, is usually enough to show the review took place.

Privileged actions in consoles with no log

Administrative work often happens in cloud management consoles, hypervisors, firewalls and appliance web interfaces, and some of these record little or nothing about who changed what. An assessor who asks to see the log for a privileged action on an appliance may find none, which breaks the capture objective even when the application logs are complete. Inventory every administrative interface that touches systems in scope, confirm what each one records, enable its audit or activity logging, and forward those records to the central log store. Where a console cannot produce a log, document the compensating control or the change to the system before it is accepted into scope.

Questions about AC.L2-3.1.7 cost, effort and outside help

How much effort does AC.L2-3.1.7 privileged functions take to meet?

The effort is usually modest for the requirement itself, but it depends on how many privileged functions exist and how many systems they touch. The work has two parts: writing down which functions are privileged and which accounts hold them, and then configuring enforcement and audit logging for each function. Assessors test four assessment objectives under NIST SP 800-171A, so every privileged function needs a documented definition, an enforcement mechanism, and a log record. A small environment with one directory and a few admin consoles is far simpler than a multi-tenant platform with dozens of administrative interfaces. Ask any consultant to size the work by counting privileged functions and systems in your written scope, not by a flat fee.

Can our own team meet AC.L2-3.1.7 without outside help?

Yes, a capable internal team can meet this requirement, because it is a configuration and documentation task rather than a new technology build. The team needs a current list of privileged functions, a clear mapping of those functions to roles, and proof that non-privileged users cannot run them. Outside help is most useful when the team lacks time to review logs, when systems are unfamiliar, or when an independent view is needed before a self-assessment is submitted. Your organization owns the control and the final evidence. An implementation partner can prepare configurations and evidence, but only an independent assessor can issue a certification assessment result.

What does AC.L2-3.1.7 need from engineering and compliance teams?

Engineering and compliance each own a distinct part of the work. Engineering typically needs to:

  • Identify privileged functions in each system, such as administrative consoles, security settings and user management
  • Restrict those functions to authorized roles and test that standard accounts are blocked
  • Turn on audit logging for each privileged action and confirm that records are created and retained

Compliance typically needs to maintain the list of privileged functions, approve role assignments, review sample logs, and store the system security plan entry and test results in final form. Both teams should agree on who reviews privileged-function logs and how often.

How long does it take to be ready for AC.L2-3.1.7?

No fixed duration applies, because readiness depends on the starting point. The main drivers are whether privileged functions are already documented, whether audit logs for administrative actions are enabled, how many systems fall inside the assessment boundary, and whether any applications lack role-based restrictions. Teams with an accurate access inventory and existing admin logging can often close the gap quickly, while teams that must redesign roles or add a logging platform need more time. Ask a prospective partner to break the readiness plan into discovery, configuration, testing and evidence collection, and to name the dependencies in the written scope.

Can AC.L2-3.1.7 go on a POA&M, and how many points is it worth?

AC.L2-3.1.7 is worth 1 point under 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21, so it can be placed on a plan of action and milestones for Conditional Level 2 status if the score is at least 88 of 110. The closeout period is 180 days. Treat this as a constraint to confirm against the current rule text and the Department of War's latest guidance, because the Phase II suspension announced on 13 July 2026 changed the timeline for certification. A POA&M is a temporary arrangement, so use it only for a documented gap with a funded fix, not as a way to defer the work.

What should we ask a partner to include in a written scope for AC.L2-3.1.7?

A written scope should name the systems in the boundary, the privileged functions to be defined, and the logging platform used for evidence. Ask the partner to state its deliverables in the form:

  • A reviewed inventory of privileged functions and assigned accounts
  • Configuration changes with before and after settings for each enforcement mechanism
  • Sample audit records showing captured privileged executions
  • A test record mapped to the four NIST SP 800-171A objectives

Also confirm what is excluded, who owns each deliverable, the review cycle, and how change requests affect price and timing. DeployOpen plans and implements these engagements on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts, and does not issue assessment reports or certifications.

Do open-source logging tools reduce the cost of AC.L2-3.1.7 evidence?

They can reduce licensing spend, but the main cost remains configuration, testing and review labor. Self-hosted platforms such as Nextcloud, with its admin_audit app writing to audit.log, OpenBao audit devices, and Wazuh or OpenSearch for correlation and alerting can produce the records assessors look for. Confirm that each product captures the specific privileged functions in your environment, since coverage varies by application. Ask for hosting, retention and review costs to be shown separately in the quote, because those recur after the first assessment.

How DeployOpen scopes and prepares privileged function evidence

DeployOpen scopes this requirement by first agreeing in writing which systems, administrative roles and privileged functions fall inside the assessment boundary. The starting point is the list of privileged functions the organization already defines, such as directory administration, firewall rule changes, backup restores, key management and access to the audit store itself. Where that list does not exist or is incomplete, the engagement includes a short discovery step to build it and to map each function to the accounts that hold it. The written scope then names the platforms in play, for example a self-hosted Nextcloud instance with the admin_audit app, an OpenBao deployment with its audit devices, and the log pipeline that carries their records, so that enforcement and logging are tested against the same boundary the assessor will use.

Enforcement and audit work is planned and built inside the client's own cloud accounts, data centers or air-gapped networks. For each privileged function, DeployOpen configures the restriction (role separation, administrative consoles limited to designated groups, and non-privileged accounts that cannot reach privileged paths), turns on logging for every execution, and forwards those records to a central store. The deliverables typically include configuration exports, role-to-function matrices, sample audit records for each function and the documented procedure for reviewing them. The client should confirm each log source's exact capture behavior with the vendor and test it in their own environment, because a log that exists on paper but omits the event an assessor will ask for is a common gap.

DeployOpen's role is to plan, implement and document this setup and to prepare the evidence an assessor will review, under a fixed written scope. It does not issue audit reports, attestations or certifications. For Level 2 certification, an independent assessor from an authorized or accredited certification body performs the assessment, and any self-assessment remains the organization's own responsibility. Before work begins, ask for the deliverables, the systems covered, the evidence format and the acceptance criteria in writing, and confirm with your assessor that the proposed evidence meets their expectations.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com