03.01.05 Least privilege: NIST SP 800-171 evidence

What NIST SP 800-171 least privilege requires and why assessors press on it

If a contract requires NIST SP 800-171 and you must show least privilege for systems that hold CUI, the core question is simple: can you prove that every user and process holds only the access its tasks need, and that someone reviews those privileges on a schedule? Requirement 03.01.05 Least privilege asks for exactly that. It requires you to allow only the system access that users and their processes need for assigned tasks, to authorize access to defined security functions and security-relevant information, to review the privileges assigned to roles or classes of users at a defined frequency, and to reassign or remove privileges as needed. The requirement carries three organization-defined parameters (ODPs) that you must set yourself unless your federal agency specifies them: the security functions that need authorized access, the security-relevant information that needs authorized access, and the frequency of privilege reviews. A blank or vague answer to any of these leaves the requirement incomplete.

The risk the requirement targets is privilege accumulation. Users change roles, projects end, and temporary elevations are granted for an incident and never revoked, so access grows while nobody decides it should. Rev. 2 stated the older requirement, 3.1.5, in narrower terms. NIST's change analysis classifies the Rev. 3 version of this requirement as a significant change, with more detailed statements and foundational tasks that must be carried out, so an assessment will look for a documented procedure, a defined review cadence and records that show the cadence was followed. Your CUI scope is also tied to this requirement's withdrawn predecessor, 3.4.9 in Rev. 2, which NIST says 03.01.05 addresses together with other access control requirements, so the least privilege design affects more than one control.

What usually makes this hard is not writing the policy but finding the privileges that already exist. Access is often granted by email, copied from a colleague, or added to a shared group, and it is rarely removed when the reason goes away. Start by exporting current role and group memberships for every system in your CUI boundary and comparing them with approved job functions. Then decide who reviews each role, how often, and what evidence the review leaves behind. Access certification tools such as midPoint, which lets designated reviewers keep, change or revoke role assignments within a set timeframe, can produce that evidence, though you should confirm how the review records are retained for your assessor. Ask your assessor early which review frequency and privilege lists they expect to see.

Which systems, roles and third parties fall under least privilege

Least privilege reaches further than the systems that hold CUI. Any account, directory, console or automated process that can reach CUI or change how security works is part of the assessment. The cards below cover the scoping decisions that most often change the work, and what the assessor will ask to see for each.

Systems that store, process or transmit CUI

Start with the system boundary defined in the system security plan, then list every account that can read, change or move CUI inside it. This includes application databases, file shares, collaboration tools and backup repositories. For each, check whether privileges are assigned by role and whether the list of assigned access authorizations matches what the policy says. Assessors typically sample these lists, so keep them current and exportable.

Identity sources and directories

Directories such as LDAP services, Kerberos realms and identity providers decide what every downstream application grants. A privileged group in the directory can reach systems far outside the CUI boundary, so it is in scope even if no CUI sits in the directory itself. Document which groups can add members, change group membership or reset credentials, and confirm that these rights are limited to the roles that need them.

Administrative tooling and consoles

Configuration tools, deployment pipelines, remote management agents and cloud consoles can change security settings for every system behind them. Assessors look at whether administrators hold these powers only when a task requires them and whether the use of those powers is recorded. Ask your team to list each tool, the roles that can open it, and whether any role can reach it without a documented business need.

Cloud management planes

Cloud accounts, subscriptions and projects often carry the broadest rights in an environment, because one administrative role can create resources, read storage and alter network rules. Review the role assignments at the account and organization level, not only inside individual workloads. Confirm that standing administrative access is replaced with narrower roles where the platform allows, and that the review frequency you set is applied to these roles too.

Service accounts for automated processes

Scheduled jobs, integrations and build agents usually run under accounts that no person logs into, which makes their rights easy to forget. Under 03.01.05, a process that runs under broad rights is in scope just as a user with those rights would be. Inventory each service account, its owner, the systems it touches and the reason it holds each privilege. Remove rights a process does not use and record the owner who answers for each account at review time.

Defined security functions and information

The requirement leaves two lists to the organization: the security functions that need authorized access and the security-relevant information that needs the same protection. Your organization must write these lists itself, because NIST does not supply the values. Include items such as audit configuration, key material, firewall rules and access review records. Then check that every role able to reach these items appears on the list, since an assessor will test the defined list against the actual rights.

How an assessor tests least privilege against SP 800-171A

This table shows how an assessor tests 03.01.05 under SP 800-171A Rev. 3, method by method, with the objects requested, the questions asked and the findings that most often appear. Read each row as a request the assessor will make, and prepare the matching evidence before the assessment begins.

Assessment method	Objects the assessor requests	Common findings
Examine	Access control policy and procedures, procedures for least privilege, the list of assigned access authorizations (privileges), system configuration settings and system audit records	Procedures describe least privilege in general terms without naming the roles, privileges or review cycle the system actually uses
Interview	Personnel responsible for defining least privileges, personnel with information security responsibilities and system administrators	Administrators describe privileges from memory, and the answers differ from the assignment list or from one another
Test	Mechanisms implementing least privilege functions and mechanisms implementing reviews of user privileges	Privileges are granted broadly by default, or the review mechanism exists but cannot be shown to run
ODP check: security functions	Documented value for the security functions to which access is authorized	No organization-defined value exists, so the requirement cannot be marked as met
ODP check: security-relevant information	Documented value for the security-relevant information to which access is authorized	The category is described in policy but not tied to specific data stores, logs or configuration files
ODP check: review frequency	Documented review frequency for privileges assigned to roles or classes of users	The frequency is stated as periodic or as needed, which does not give the assessor a value to test against
Review evidence	Completed review records, the decisions taken (keep, change, remove) and the change tickets that carried them out	Reviews are recorded as complete, but no removals or changes follow, or the reviewer is the person who holds the access
Assigned privileges	Current role and privilege assignments, compared with the authorizations the policy allows	Accounts hold privileges that no current task needs, often inherited from earlier roles

Implementing least privilege in the order an assessor will check it

This sequence turns 03.01.05 into a set of decisions, documents and configuration records that an assessor can trace from the requirement to the live system. Each step ends with an artifact the organization can show, so the review can confirm the decisions were made, written down and applied.

Define the three organization-defined parameters
Start by deciding the three ODP values the requirement leaves to the organization: which security functions need authorized access, which security-relevant information needs authorized access, and how often role privileges are reviewed. Ask the contracting federal agency whether it has specified values, because if it has not, the nonfederal organization must assign them itself to complete the requirement. Record each decision in a signed ODP decision record that names the approver, the date and the rationale. The step is done when every value is written, approved by someone with authority over the system, and linked from the system security plan.
Document the role catalog and role privileges
Build a catalog of the roles or classes of users on the system, then list the privileges each role holds, including access to the security functions and security-relevant information named in the ODP record. Present the result as a role-to-privilege matrix that shows which roles can reach which functions and data. Assessors compare this matrix against the access authorizations in the system, so every privilege in the directory or application should appear in it, and every row should map to a documented task. The step closes when the matrix is approved by the data owners and a security lead, and any role that grants more than its task needs has been flagged for correction.
Write the least privilege procedure
Write a short procedure that explains how access is requested, justified against an assigned task, approved, granted and removed. The procedure should state who may approve privileges and how processes and service accounts receive only the access they need. An assessor tests whether the procedure exists and whether people who perform the work know it, so the output is a versioned document referenced by the access control policy. Confirm it is consistent with the role matrix and the ODP record. The step is complete when the procedure is approved and the approval is recorded in the document history.
Configure systems and directories to match the matrix
Map each role in the matrix to groups, roles or policies in the directory, operating systems and applications, then remove grants that do not appear in the matrix. Identity platforms such as FreeIPA can centralize group membership for Linux and UNIX environments, and authentik can serve as the identity provider that applications use for sign-in, but the organization must confirm each platform's role and group model before relying on it. Export the configuration settings and group memberships as evidence, and retain them with a timestamp. The step closes when a comparison of the exports against the matrix shows no unexplained privileges.
Run and record the first privilege review
Conduct the first review of role privileges at the frequency set in the ODP record. Designated reviewers should confirm, change or revoke each role assignment and privilege, and record the decisions with their reasons. Access certification tools such as midPoint can structure this work by assigning reviewers, setting a decision timeframe and capturing outcomes, although the organization must verify that its chosen tool meets its review design. Keep the review minutes, the list of decisions, and the reviewer sign-off. An assessor interviews the people who performed the review, so each reviewer should be able to explain the decisions they recorded.
Close out removals and track the changes
Act on every revoke or change decision from the review. Remove the privilege in the source system, not only in a report, and confirm the removal in a fresh configuration export. Where a removal cannot be completed in time, record the exception with an owner and a plan rather than leaving the grant silently in place. Note that CMMC Level 2 does not allow requirement 3.1.5 on a plan of action and milestones for Conditional status, so the organization should plan to meet this requirement fully before assessment. The step closes when each review decision has a matching change record and the next review date is on the calendar.

Evidence that passes least privilege and how to keep it current

Assessors testing 03.01.05 look for documented rules, a record of how privileges were decided, and proof that reviews happened and changed access when they should. The cards below cover the artifacts that tie those pieces together, and how to refresh each one between assessments so it reflects the system as it is today.

Access control policy and procedures

The written policy and procedures state who decides what a role may access, how least privilege is applied, and who runs the reviews. An examiner will compare them with what the system actually does, so the document should name the roles, the review owner and the escalation path for disputed grants. Check it against the current org chart and tooling at least each time the defined review frequency comes around, and record the revision date and approver on every change.

ODP decision record

Three organization-defined parameters apply to 03.01.05: the security functions that need authorization, the security-relevant information that needs authorization, and the review frequency. NIST does not set these values, so the organization must, and the decision record shows what was chosen and why. Keep it under change control so that any change to the review frequency or the protected functions is visible to an assessor and tied to a dated approval.

Role-to-privilege matrix

This matrix maps each role or class of user to the security functions and security-relevant information it may reach. It is the reference that reviewers use to judge whether a grant is justified, so every row should trace to a documented task. Regenerate it from directory and application role data after each joiner, mover or leaver batch rather than editing it by hand, and note the source system and export date on the document.

System configuration exports showing grants

Configuration exports from directories, operating systems, databases and cloud consoles show the privileges actually in force, which may differ from the matrix. Schedule exports at a cadence the organization defines and retain them with timestamps, so the history shows privilege drift over time. Compare each export with the matrix, and treat any grant without a matching role as a finding to resolve before the next review closes.

Privileged access list

The privileged access list names every account with administrative or security-relevant rights, the business reason for each, and the approver. It supports the separate requirements on privileged accounts and privileged functions, so an assessor will check it against audit records of privileged function use. Review it on the same cycle as the broader privilege review, and remove entries for service accounts or contractors whose tasks have ended.

Signed review records and removal tickets

Each review should record, for every role or user reviewed, a decision to keep, change or revoke, the reviewer's name and the date. Every change or revocation then needs a removal ticket that shows completion, and the ticket should link back to the review item. Confirm that revocations actually took effect in the system, because an approved removal that was never applied is a common gap an assessor will find.

What meeting 03.01.05 costs and what drives the cost

This table lists each cost component of meeting 03.01.05, who is paid for it, whether it is one-time or recurring, and what makes it grow. Use it to shape a written quote, because most of the spend is staff time rather than software. No dollar figures or durations are given here because none were supplied for this requirement.

Cost component	One-time or recurring	Who is paid	Main drivers and how to contain them
Tooling and licenses	Recurring	Software vendors or none for open source	Number of systems and identity sources in scope. Self-hosted open-source identity platforms such as authentik or FreeIPA remove license fees, but hosting, patching and backup still need budget.
Role design and privilege mapping	One-time, with periodic updates	Internal engineers, IAM staff or an implementation partner	Number of roles and classes of users. Fewer, well-defined roles cut the work of defining least privilege and of later reviews. Ask the partner to show how many roles the scope assumes.
Enforcement configuration	One-time, then change work	Internal platform engineers or an implementation partner	Number of applications, operating systems and services that must enforce role grants. Ask whether each system integrates with the identity provider or needs manual configuration.
Access review campaigns	Recurring	Designated reviewers in business and IT, plus the team that runs the campaign	Number of accounts and role assignments, and how often the ODP review frequency is set. A tighter frequency raises reviewer hours. Access certification tooling, such as the midPoint access certification campaigns, can reduce preparation time but still needs reviewers to decide.
Evidence upkeep	Recurring	Compliance lead and system owners	Volume of listed privileges, system configuration settings and audit records kept for assessors. Standardized exports from the identity platform lower the effort of each assessment cycle.
External testing or review	Recurring or per engagement	Independent testers or an assessor, depending on the assessment type	Scope of the privilege tests and how many mechanisms are exercised. Request a fixed scope in writing that lists systems, roles and test cases.
Assessor sampling and assessment fees	Per assessment	The assessing body, under the contract or program that requires the assessment	Sample size the assessor chooses and the number of systems it covers. Keep privilege lists complete and current so sampling does not expand into manual reconstruction of history.
Remediation of privilege findings	Recurring, unpredictable	Internal staff or partner	Number of excess privileges found in reviews. Reviewing role grants against tasks each cycle keeps this from building up before an assessment.

Using midPoint, authentik and FreeIPA for least-privilege evidence

midPoint, authentik and FreeIPA each produce a different kind of 03.01.05 evidence: a review record, a sign-in map and a host access map. Together they can show who holds access, who approved it and where it is enforced, but each covers only part of the privilege model. Confirm how each one maps to your roles and ODP values before you cite it.

midPoint access certification campaigns

midPoint, licensed under EUPL-1.2+, runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke role assignments. For 03.01.05, this supports the recurring review of privileges assigned to roles or classes of users, which is one of the organization-defined parameters you must set. It also supports segregation of duties by keeping reviewers separate from the people whose access they review. Confirm the review frequency matches your ODP value and identify which decision records the campaign keeps for an assessor.

authentik as the identity provider

authentik, licensed under MIT, is the identity provider that applications delegate sign-in to. It supports OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. For 03.01.05, this gives you one place to show which applications receive which identities, which supports the authorization of access to security functions and security-relevant information. Check that every application inside your CUI boundary delegates to it, and document any application that still keeps local accounts as an exception with its own privilege review.

FreeIPA single sign-on for Linux and UNIX

FreeIPA, licensed under GPL-3.0-or-later, provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Privileged access on those hosts is where least privilege often erodes, so your assessor will ask whether the groups and host access rules match the privileges your reviews approve. Confirm which host access and group features you will use, then test that removing a user from a group actually removes their access to the hosts you manage. Record the test result as evidence.

What the tools do not settle

None of these tools makes an organization compliant with 03.01.05. The organization still owns its privilege model, its ODP values and the decision made in each review. Assessors examine the access control policy, the list of assigned privileges and system configuration, interview administrators and test the mechanisms. Use the tools as evidence sources, and document each privilege granted outside them. An implementation partner can prepare the configuration and evidence, but only an independent assessor reaches the assessment conclusion.

In-house, partner or auditor: who owns least privilege

The organization owns 03.01.05 in full. Its own people decide which security functions and security-relevant information need authorized access, how often role privileges are reviewed, and who approves each change. These are business and risk decisions, and no partner or assessor can make them on the organization's behalf. The organization also owns the access control policy and procedures that the assessor will examine.

Organization-defined values: Setting the three ODP values for 03.01.05 (the security functions, the security-relevant information and the review frequency) is the organization's job. Under the Rev. 3 model, if a federal agency has not specified them, the nonfederal organization must assign them.
Role and privilege decisions: Approving which roles receive which privileges, and who may grant or remove them, stays with accountable owners.
Review execution: Performing the periodic privilege reviews and recording the decisions, including reassignments and removals, is an internal activity.
Policy and procedures: Writing and maintaining the least privilege procedure and the access control policy that the assessor examines.
Interviews: Staff with responsibility for defining least privilege and system administrators will be interviewed, so they need to know the decisions and be able to explain them.

Before engaging any outside party, confirm internally who signs off the ODP values and who holds the review evidence.

Where least privilege evidence usually falls short and how to close it

Assessors testing 03.01.05 Least privilege usually find the same few weaknesses: parameters that were never set, access that nobody can explain, and reviews that leave no record of what changed. The cards below name each gap and the first step to close it, so the evidence matches what the requirement asks for.

Undefined organization-defined parameters

03.01.05 has three organization-defined parameters: the security functions and the security-relevant information that need authorized access, and the frequency for reviewing role privileges. If your organization never sets these values, an assessor cannot confirm the requirement is met. Start by writing the three values into the system security plan, with the security functions and information types named, and the review frequency stated. Confirm that the values appear in the access control procedures an assessor will examine.

Privileges granted through unexplained groups

Many environments hold privileges through directory groups that were created years ago and now have no owner or documented purpose. Assessors interviewing system administrators often find that nobody can say why a group carries administrative rights. Export the group membership and the rights each group grants, then assign an owner and a written justification to every group that carries security-relevant access. Remove groups that cannot be justified.

Reviews without recorded decisions

Teams often run a privilege review, confirm that it happened, and keep no record of which entries were kept, changed or revoked. The examine method looks for the list of assigned privileges and the audit records of changes, so a review with no output does not show the requirement working. Keep each review's input list, the reviewer's decision for each item, the date, and the ticket showing each removal. Certification tools such as midPoint can record these decisions within a set timeframe if you confirm the reviewer workflow fits your process.

Service and automation accounts left out

Service accounts, scheduled jobs, CI pipelines and integration accounts often hold broad rights and sit outside the periodic review because they are not tied to a person. Yet 03.01.05 applies to processes as well as users. Build an inventory of non-human accounts, record the purpose and the minimum rights each one needs, and add them to the review population with a named owner. Ask whether any of them hold administrative rights they do not use.

Privilege accumulation after role changes

When people change roles, they often keep the access from their previous role because nobody removes it at transfer. Over time this accumulates privileges that no current task needs. Tie privilege removal to the role-change workflow, so the request for a new role includes an explicit step that reassigns or removes the old privileges. Check a sample of employees who moved teams in the last year and compare their current rights with their current job.

Withdrawn Rev. 2 requirements mapped to 03.01.05

NIST states that withdrawn requirement 03.04.09, which replaced Rev. 2 requirement 3.4.9, and withdrawn requirement 03.13.03, which replaced Rev. 2 requirement 3.13.3, are addressed partly by 03.01.05. Organizations that only track the Rev. 3 requirement often overlook the duties these earlier requirements carried. Add the Rev. 2 requirements to your crosswalk, and confirm that the privilege controls covering system configuration and the privilege-related parts of boundary protection are documented under 03.01.05 and its related requirements. If you are assessed against Rev. 2 under CMMC, check the Rev. 2 numbering in your plan.

Questions buyers ask about least privilege before hiring help

How much work does 03.01.05 least privilege usually take, and what drives it?

No researched figure exists for the effort, so treat any number you hear with caution and ask for a scoped estimate. The main drivers are the number of systems and roles that carry CUI, how many privileges have been accumulated over time, and whether the organization has a current role model it can map to. Organizations with many legacy applications and undocumented admin rights usually spend more time on the first inventory than on the configuration changes. Ask any partner to break the quote into discovery of roles and assignments, redesign of role or group structure, configuration of enforcement, the first access review, and documentation for the assessor. Ask whether each part is one-time or recurring, since the review frequency you define for the organization-defined parameter sets the ongoing work.

Can our team implement least privilege on its own?

Yes, an organization can implement 03.01.05 with its own staff, because the requirement asks for outcomes it controls: restricted access, defined ODP values, and periodic review with reassignment or removal. The harder question is capacity and independence. The team needs someone who can read identity and directory data, change group and role assignments on each system in scope, and keep records that show decisions were made. Many teams find that the inventory of existing privileges across cloud, directory and application layers is the slowest part. If internal staff already own identity administration and can run a documented review cycle, they may not need outside help for the initial work. Ask a partner to state in writing which parts they would perform and which your staff must own.

What do role owners and system administrators need to contribute?

Role owners and system administrators supply the facts that make least privilege work, and the assessor will interview them. Role owners must state which tasks each role needs, which security functions and security-relevant information those tasks touch, and who approves changes. System administrators must confirm how privileges are actually assigned on each platform, including inherited rights and service accounts that no one remembers creating. Plan time for these people to review draft role definitions, to validate a sample of assignments, and to answer interview questions on the review process. Ask the partner or auditor to list which individuals will be interviewed for 03.01.05, because the assessment procedure names personnel with responsibility for defining least privilege, information security personnel and system administrators.

How do the Rev. 2 3.1.5 and Rev. 3 03.01.05 differences affect CMMC Level 2 and POA&M eligibility?

CMMC Level 2 still assesses Rev. 2, so the Rev. 2 requirement 3.1.5 is what the assessment checks today. NIST's change analysis classifies the move to 03.01.05 as significant, with more detail and foundational tasks, so a Rev. 2 control set that looks complete may not cover the Rev. 3 expectations. The CMMC practice AC.L2-3.1.5 is worth 3 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, that practice cannot be placed on a plan of action and milestones to reach Conditional status, so it must be fully implemented at assessment time. Confirm the current contract and assessment requirements with your contracting officer, because a federal rule change is still pending.

Will a federal agency or the proposed FAR rule publish the ODP values for least privilege?

Nothing supplied confirms that an agency will publish values for the three least privilege parameters. NIST does not assign organization-defined parameter values, and where a federal agency does not specify them, the nonfederal organization must assign them to complete the requirement. The proposed FAR overhaul would require contractors to use ODP values published by the DoW CIO, but that rule was not final as of October 2026. Until your contract, the DFARS clause or a written agency instruction says otherwise, you should define the security functions, the security-relevant information, and the review frequency yourself and document the rationale. Ask your contracting officer whether any values have been published for your contract.

What will an assessor ask for to test least privilege?

An assessor will examine the written access control policy and least privilege procedures, the list of assigned access authorizations, system configuration settings and system audit records. They will interview personnel who define least privileges, information security staff and system administrators. They will test the mechanisms that enforce least privilege and the mechanisms that run reviews of user privileges. Prepare evidence in advance: your defined ODP values, role definitions, a dated privilege export for each in-scope system, records of completed reviews with decisions to keep, change or revoke, and logs showing privilege changes. Confirm with your assessor which format they accept, since the procedure does not prescribe one.

What can a partner do, and what can it not do for the assessor's role?

A partner such as DeployOpen can plan the scope, implement and document least privilege configuration in your own environment, and prepare the systems and evidence an assessment will examine. DeployOpen works on self-hosted open-source platforms inside your infrastructure and most engagements are fixed-scope, with the deliverables agreed in writing before work starts. A partner cannot make the assessment decision, issue a report, or certify that you meet 03.01.05. Only an independent assessor or certification body issues those results. The organization keeps ownership of its controls, its ODP values and its review decisions, so those must come from your own accountable staff. Ask any partner to show in the proposal which evidence it will prepare and which decisions remain yours.

How DeployOpen works on this

DeployOpen plans and prepares the systems, role model and evidence that show least privilege for 03.01.05 in your own environment. The organization keeps ownership of its controls, and an independent assessor reaches the assessment conclusion.

How we scope

Inventory the systems, roles and privilege classes in the CUI boundary that need least-privilege treatment.
Agree in writing which security functions and security-relevant information require authorized access.
Record the review frequency your organization assigns to role and privilege reviews, since NIST leaves that value to you.
Confirm which assessment objects, such as policy, assignment lists and audit records, are in scope.

How we build

Map each role to the minimum permissions its tasks need, and document the mapping for assessors.
Configure identity providers and directory services so access follows defined roles, using the platforms you select.
Set up logging so privilege assignments and changes produce audit records an assessor can examine.
Test that users and processes are denied functions outside their assigned roles before sign-off.

How we hand over

Deliver the least-privilege procedure, role matrix and ODP value record in formats your team can maintain.
Provide a privilege review workflow with reviewer assignments, review records and reassignment or removal steps.
Document test results and configuration evidence that map to the 03.01.05 determination statements.
Walk your assessor and administrators through the evidence so they can answer interview questions accurately.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover periodic privilege reviews, role changes and re-testing after platform upgrades.
Ask any provider to confirm in writing which review tasks remain with your staff and which are included.
Independent auditors and assessors issue any reports or conclusions, not DeployOpen.