03.01.06 Least privilege: privileged accounts: requirements and evidence

What 03.01.06 asks for and why admins must split their accounts

If a contract requires NIST SP 800-171, 03.01.06 asks two things of your system: you must restrict privileged accounts to personnel or roles you define, and you must require anyone holding a privileged account to use a separate non-privileged account when doing non-security work, such as reading email or browsing the web. The requirement has one organization-defined parameter (ODP), the personnel or roles allowed to hold privileged accounts on the system. NIST does not supply that value, and if your federal customer does not specify it, you must set it yourself and be able to show it. Start by listing every account with administrative rights, then write down which roles are entitled to each one. That list is the first piece of evidence an assessor will ask for.

The second half is where most gaps appear. Administrators often run daily work from the same account they use for changing firewall rules or domain settings, so a phishing email or a malicious web page can inherit full privileges. Hard cases are usually undocumented shared administrator accounts, local admin accounts that were never inventoried, and service accounts whose owners are unclear. Each of these needs an owner, a documented purpose and a decision on whether it stays privileged. Confirm with your identity team which directory and platform accounts carry privilege, and whether your identity provider can enforce separate admin identities or only record them.

For readers who have worked with Rev. 2, this requirement traces to Rev. 2 requirement 3.1.6, and NIST's change analysis classifies the change as significant because Rev. 3 adds more detail and foundational tasks. The same change analysis shows that Rev. 3 addresses withdrawn requirements 03.04.09 and 03.13.03 partly through this requirement, so expect assessors to look for its evidence in configuration and communications work as well. Check the current assessment procedure in SP 800-171A Rev. 3 before you finalize your evidence set, because the examine, interview and test objects it lists go beyond a policy document.

Which privileged accounts and systems fall in scope for 03.01.06

Scoping 03.01.06 starts with a list of every account and system that holds privileged rights over CUI or the security controls that protect it. The organization owns that list and the personnel or roles ODP that governs it, so each card below is a decision to record before an assessor asks.

The CUI system boundary

Start with the system security plan boundary, because privileged accounts outside it are usually out of scope while accounts that can reach CUI, its storage or its transmission paths are in scope. Check whether administrators of hosts, containers and network paths that carry CUI are covered, even when those hosts are run by a shared team. Record the boundary decision and the reasoning behind it, since an assessor will test whether the privileged account list matches it.

Directory and identity platforms

Directory services, identity providers and their synchronization connectors hold rights to create, change and remove accounts across the system. Treat their directory administrators as the highest-impact privileged population, and confirm which roles can modify group membership, authentication policy or provisioning targets. Open-source options such as FreeIPA and authentik centralize these rights, so the ODP can name a small set of identity roles rather than individuals on each application.

Operating system and database administrators

Local root, Windows administrator and database owner accounts are often created during build and then forgotten. Inventory built-in and system-generated privileged accounts, the groups that grant them and the people or service accounts that use them. Note that examine objects for this requirement include lists of system-generated privileged accounts and of system administration personnel, so these lists must exist and match.

Cloud and hypervisor administrators

Cloud tenant owners, subscription administrators and hypervisor management consoles can create or reach CUI workloads without touching the guest operating system. Confirm which roles can create virtual machines, change network rules or export snapshots, and decide whether those roles fall within the ODP. Ask the cloud or data center operator how its own staff access are controlled, because that affects what the organization can claim.

Security tooling accounts

Scanners, log collectors, endpoint agents and backup software often run with broad read or write rights. These accounts are privileged even when no person logs into them, and their rights should be limited to the functions they perform. Confirm that administrators of security tools do not also use those tools' privileges for routine work, which is the separation the requirement describes.

Third-party administrators

Managed service providers, integrators and vendor support engineers may hold privileged access through remote sessions or shared jump accounts. Decide whether they fall within the personnel or roles ODP, how their accounts are named and approved, and what agreement governs their use. Access certification campaigns in midPoint can help review these grants on a set schedule, although the organization still decides which roles qualify.

How an assessor tests least privilege for privileged accounts

This table compares the three SP 800-171A Rev. 3 assessment methods for 03.01.06 (examine, interview and test), the objects an assessor pulls for each, and the findings that commonly appear. Read each row as a question the assessor will ask and the artifact your organization should have ready before the assessment begins.

Assessment method	Objects the assessor reviews	What the assessor is confirming	Common findings
Examine: determination statements	Access control policy and procedures; least privilege procedures; list of system-generated privileged accounts; list of system administration personnel; system audit records	Policy and procedures define the restriction of privileged accounts, and the account and personnel lists match what the system actually grants	Policy names no defined personnel or roles for privileged accounts; the procedure is not dated or approved; admin lists do not match directory group membership
Interview: personnel	People responsible for defining least privilege; personnel with information security responsibilities; system administrators	Those who define the rule can explain it, and administrators know they must use a separate non-privileged account for email, browsing and other non-security work	Administrators describe using one account for everything; the definers cannot name the roles that are allowed privileged access
Test: mechanisms	Mechanisms implementing least privilege functions, such as directory group membership, role assignments and privileged access controls	The system restricts privileged accounts to the defined personnel or roles, and the restriction works when tested	Privileged groups contain users outside the defined roles; nested or inherited group membership grants admin rights that the list omits
Organization-defined parameter (ODP) check	The value assigned to the personnel or roles parameter for 03.01.06	The ODP is defined, written down and specific enough to test against the system	ODP left blank or described generically such as authorized staff; no owner or approval date recorded
Separate non-privileged accounts for non-security work	Admin account inventory; account naming records; sample of admin sessions and audit records	Administrators use a separate standard account for non-security functions and information, and the privileged account is used for security tasks	Admins without a second account; shared admin credentials used for email; no audit trail linking admin activity to a named person
Audit records supporting the test	System audit records of privileged account logons and privileged actions	Privileged use is traceable to individuals and matches the approved roles	Logs do not identify the individual behind a privileged session; no review of privileged logons

Implementing 03.01.06 in the order an assessor will check it

This sequence turns 03.01.06 from a policy statement into evidence an assessor can examine, interview against and test. Each step produces a written record that the next step depends on, so the final review shows the restriction is defined, applied and still in force.

Define the ODP values in writing
Requirement 03.01.06 has one organization-defined parameter: the personnel or roles to which privileged accounts on the system are restricted. The system owner and security lead agree the approved list of roles, such as system administrators, security administrators and named platform engineers, and record who approved it and when. If a federal customer has already specified this value, use that value and record the source. The output is an approved ODP record that the system security plan can reference. Confirm the wording with your contracting officer or assessor before you rely on it.
Inventory every privileged account
Build a complete list of accounts that hold privileged rights on the system. Include named administrator accounts, directory and identity provider admin roles, database and hypervisor administrators, and the built-in and system-generated accounts that ship with operating systems and applications. Service accounts and automation accounts with elevated rights belong on the list too, because assessors commonly check whether these were omitted. Pull the lists from each platform directly rather than from memory. The output is a privileged account inventory with owner, purpose and the role each account maps to.
Map each privileged account to an approved role
Compare every entry in the inventory against the ODP record. Accounts assigned to people or roles on the approved list stay; any account held by someone outside that list is removed or reassigned, and any account with no clear owner is investigated before it is kept. Document the exception path for emergency or break-glass accounts so that they are restricted, monitored and tied to a named role. The output is a role mapping that shows, for each privileged account, the approved personnel or role it serves and the date the mapping was last checked.
Adopt a dual-account standard for administrators
Require every person who holds a privileged account to also hold a separate non-privileged account for email, web browsing, documents and other non-security work. The privileged account is used only for administrative tasks and security functions. Write the standard so that it names the accounts involved, forbids using the privileged account for routine work, and states how staff access each account. Confirm that your identity platform supports separate identities for the same person and that the standard is applied to contractors and service desk staff. The output is a signed dual-account standard that sits alongside the access control policy.
Enforce the split with technical controls
A written standard alone does not show that privileged accounts are not used for non-security work. Configure the identity provider and systems so that privileged roles are granted only to the separate administrative identities, and remove privileged rights from the everyday accounts. Where the platform allows it, require separate sign-in for privileged sessions. Confirm each setting in the platform itself and export the configuration as evidence. The output is a set of configuration records that an assessor can test directly against the approved role mapping.
Prove the split with logs and reviews
Collect audit records showing who signed in to each privileged account, when, and for what administrative actions, and check that privileged accounts are not used for non-security activity. Schedule recurring reviews of the privileged account inventory, the role mapping and the audit records, and use a certification campaign or equivalent review so that a named reviewer confirms or revokes each privileged assignment. Record the findings and the corrective action taken. Ask your assessor which review frequency and log retention they expect. The output is a review record, with dated findings, that closes the loop on the earlier steps.

How identity tooling turns privileged access into evidence

Identity tooling produces evidence for 03.01.06 when every privileged grant traces back to a defined person or role. An assessor will ask who holds privileged accounts and how that list is kept, so the list should be exported from the directory itself. FreeIPA, which uses 389 Directory Server as a multi-master LDAPv3 directory, stores users, groups and hosts with centralized access control and delegated administration through its web UI and command line tools. Privileged roles can be modeled as groups, and delegation can limit who may change their membership. Your team must confirm which groups and delegations exist in its own deployment and map them to the personnel or roles the organization has defined. Keep a dated export of group membership at each review so the evidence shows the state at a point in time.

Removing access is the other half of the evidence. The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users who lose access to the application. For a privileged role in a downstream application, a removal in the source directory can reach the target without a manual ticket, provided the role is mapped to a group the provider manages. Test one removal end to end and keep the sync and target application logs. Separate administrator accounts are a provisioning design decision too. The non-privileged account used for email and general work should be a distinct identity, and your team must decide how it is provisioned and confirm that the tooling can manage it.

Periodic review turns the list into a decision record. midPoint access certification campaigns assign designated reviewers, who decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This counters access accumulation and supports segregation of duties, and each decision leaves a record an assessor can sample. Confirm the review frequency, reviewer roles and timeframe against your own policy, and confirm that campaigns can target privileged roles in your deployment. These tools support the organization's choices but do not make them. The organization defines the personnel or roles permitted to hold privileged accounts, assigns the organization-defined parameter values, and remains accountable for the outcome.

Evidence that passes a 03.01.06 review and how to keep it current

An assessor testing 03.01.06 examines documents, interviews administrators and tests the mechanisms that restrict privileged accounts. The six artifacts below cover the decisions, the account records and the ongoing reviews that show the requirement is met today, not only at the time of the last assessment. Refresh frequencies and sign-off roles are set by your own policy, so confirm them with your assessor before the review begins.

Written ODP decision

The organization-defined parameter for 03.01.06 names the personnel or roles to which privileged accounts are restricted. Record that decision in the access control policy or system security plan, with the roles named, the approver and the date. Assessors check that the value is defined, so a blank or vague entry fails the ODP check. Review it whenever the administrative model changes and at the policy review cycle your organization sets. Sign-off: the system owner and the CISO or equivalent.

Privileged account inventory

Maintain a current list of every system account with privileged rights, including built-in administrators, service accounts and break-glass accounts. Each entry should show the owner, the role that grants the privilege and the systems it covers. Assessors interview system administrators and compare this list against the system's own account data, so gaps between the two are a common finding. Refresh it at least monthly and after every onboarding, offboarding or role change. Sign-off: the system owner, reviewed by the security team.

Role or group assignment exports

Export the group memberships and role assignments from your directory and identity provider, such as FreeIPA groups or authentik group membership, and keep dated copies. These exports prove which people hold privileged roles and that non-administrators do not. Confirm that exports come from the system of record rather than a spreadsheet. Export on the same schedule as the inventory and retain each copy with its date. Sign-off: the identity administrator, with the system owner confirming scope.

Dual-account standard and admin usage rules

Write a standard that requires administrators to hold a separate non-privileged account for email, browsing and other non-security work, and to use the privileged account only for administrative tasks. Pair it with usage rules covering when elevation is allowed and how it is logged. Assessors ask administrators to demonstrate the split, so the rules should match what staff actually do. Review annually and after any change to tooling. Sign-off: the CISO, with HR acknowledgment from each administrator.

Audit records of non-privileged use

Collect audit records that show administrators working from non-privileged accounts during routine, non-security activity, and show privileged sessions limited to administrative tasks. Records should include the account identifier, timestamp and the function performed. Review a sample on a set schedule and document exceptions with a reason. Retention and protection of these records fall under the audit family, so confirm the retention period with your assessor. Sign-off: the security operations lead, reviewed by an independent party where possible.

Recurring access review records

Run periodic access certification campaigns in which designated reviewers decide whether to keep, change or revoke each privileged role assignment within a set timeframe. Keep the campaign definition, reviewer list, decisions and evidence of follow-through, such as revoked assignments removed from the system. midPoint's access certification feature can produce these records if it is in scope. Confirm your review cadence with your assessor, since the requirement is met by the process you document. Sign-off: the business owner of each system, with the CISO reviewing completion.

What meeting 03.01.06 costs in money and effort

This table lists the cost components of meeting 03.01.06 for privileged accounts, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices are given: the cost follows from a written scope, so use the drivers to frame what you ask for in a quote and confirm each item in your own environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Directory and identity licenses	Vendor, if a commercial directory or identity product is chosen	Recurring (license or subscription)	Zero for self-hosted open source such as FreeIPA or authentik, but confirm whether vendor support contracts are needed
Engineering time for account separation	Implementation partner or internal platform team	One-time, with later changes	Number of administrators who need a separate non-privileged account, and how many systems use shared admin logins today
Role design for ODP values	Internal security and identity owners, with partner support	One-time, revised on org changes	Number of ODP roles or personnel groups the organization must define and approve
Integration of privileged paths	Platform engineering for each connected system	One-time per system, then recurring checks	Number of systems, applications and jump points that must enforce privileged-function restrictions
Evidence upkeep	Internal compliance or operations staff	Recurring	Frequency of access reviews, how many privileged accounts exist, and whether audit records are exported automatically
External review or testing of privileged paths	Independent tester or assessor, chosen by the organization	Recurring at the frequency you set	Scope of testing, number of privileged pathways, and whether results feed a remediation process
Assessor time sampling administrator accounts	The organization pays the assessor under the assessment agreement	Recurring with each assessment cycle	Number of administrator accounts and systems sampled, and how well evidence is organized before the visit

Which open-source identity tools support least privilege evidence

authentik is an identity provider released under the MIT license. Its SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0, which helps keep privileged-role membership in downstream systems aligned with what the identity source says. That matters for 03.01.06 because an assessor will ask whether privileged accounts are restricted to the defined personnel or roles, and whether those restrictions hold in the applications that actually grant administrative rights.

Provisioning of privileged group membership: SCIM pushes group creations, changes and deletions, so administrative group membership can be traced from the source to the target application.
Hourly full sync: The provider runs a full sync every hour, which bounds how long a stale grant can persist in a target system.
Deprovisioning on loss of access: Users are removed from the target when they lose access to the application, which supports revoking privileged access when a role changes.
Limits of the evidence: authentik governs accounts only in applications connected through its providers. Local administrator accounts on servers, databases or appliances that never receive SCIM updates fall outside its records.

Confirm which privileged applications are connected through SCIM, which admin paths still use local or break-glass accounts, and whether those paths are covered by the system security plan and audit records.

Where organizations fail 03.01.06 and how to close each gap

Most failures against 03.01.06 are not missing tools. They are undocumented decisions: who holds privileged accounts, which personnel the organization defined, and whether those privileges were ever reviewed. The cards below cover the gaps assessors most often find and a concrete closing action for each.

ODP value never written down

Requirement 03.01.06 has one organization-defined parameter: the personnel or roles to which privileged accounts must be restricted. If the organization never records that value, the assessor has nothing to test against, and the determination statement that checks the ODP is defined will fail. Close it by writing the approved roles into the system security plan and the access control procedure, then tying each privileged group in the directory to one of those roles.

Shared or undocumented administrator accounts

A shared administrator login makes it impossible to tie a privileged action to a person, and an undocumented account often survives staff changes unnoticed. Assessors ask for the list of system-generated privileged accounts and the list of administration personnel, then compare the two. Close it by issuing one named privileged account per administrator, disabling generic logins, and reconciling the privileged account list against the current roster each review cycle.

Administrators browsing and mailing with privileged accounts

The requirement is that users with privileged accounts use a non-privileged account for non-security work, such as web browsing, email and document editing. When administrators read mail or open attachments while logged in as domain or root, a phishing message or malicious page can inherit elevated rights. Close it by giving each administrator a standard daily account and configuring the privileged account for administrative sessions only, then testing that email client and browser do not run under it.

Service accounts with no owner

Service and integration accounts often hold broad rights and have no named person responsible for them, so nobody decides whether they should keep those rights. Under 03.01.06 the organization must still define which personnel or roles may hold privileged accounts, and an ownerless service account fails that test. Close it by recording an accountable owner and an approved role for every service account in the inventory, and removing privileges the service does not use.

Access reviews with no recorded decisions

Teams often run privileged access reviews but keep no record of what the reviewer decided, so assessors see activity without evidence of control. Recorded decisions to keep, change or revoke each privileged assignment, with a deadline and a named reviewer, are what turn a review into evidence. Close it by keeping a dated review log with the reviewer, each decision and the change ticket that followed. Open-source identity governance tools such as midPoint support certification campaigns that produce this record, and you should confirm the exact reporting features in your own deployment.

Questions buyers ask about 03.01.06 cost, effort and outside help

How much effort does 03.01.06 take compared with the rest of the access control family?

03.01.06 is one of the lighter requirements in the access control family in terms of assessment scope, because it has one organization-defined parameter and three determination statements in SP 800-171A Rev. 3. The effort lies less in the number of checks than in the groundwork: deciding which personnel or roles may hold privileged accounts, then proving that every administrator separates privileged and everyday accounts. Requirements such as 03.01.01 (account management) carry more parameters and more lifecycle work, so most teams spend more time there. Ask any consultant to show how 03.01.06 connects to 03.01.05 and 03.01.07, since much of the evidence overlaps with them.

Can a small IT team complete 03.01.06 in-house?

Often yes, if the team can document who holds administrative rights and can show that administrators log in with separate accounts for non-security work. The work is mostly policy definition, an account inventory, and configuration of directory and privileged access tooling. A small team usually struggles with the evidence side: exporting account lists, keeping records of role approvals, and explaining the setup to an assessor during an interview. Consider a partner if the directory is fragmented across several systems or if no one on staff has built this kind of access model before. Either way, the organization owns the decision on who gets privileged access.

What does the work need from our staff?

The work needs input from four groups: the people who approve privileged access, system administrators who will change their working habits, whoever owns the identity directory, and the security or compliance lead who will hold the evidence. Approvers must agree on the personnel or roles allowed to hold privileged accounts. Administrators must accept a separate standard account for email, browsing and documents. Directory owners must confirm that privileged accounts can be created, grouped and reviewed in their platform. Assessors will interview these people, so each should be able to explain their part in plain terms.

How long does 03.01.06 take to implement?

No duration applies here until the scope is written down, because the time depends on how many systems hold privileged accounts, how many administrators need separate accounts, and how mature the current identity setup is. Ask any implementation partner for a fixed-scope plan that lists the systems in scope, the deliverables, and the dates agreed in writing before work starts. Treat any single figure offered without that scope as a sales estimate, not a plan. The timeline should also cover the time needed for staff to adopt the separate accounts, which is often the slowest step.

What drives the cost of 03.01.06 work?

Cost is driven mainly by the scope and the starting point. The main drivers are the number of systems and directories that issue privileged accounts, the number of administrators, whether accounts are already split by purpose, whether a central identity platform exists or must be added, and how much evidence must be gathered for an assessment. One-time costs cover design, configuration and documentation. Recurring costs cover periodic access reviews, account changes as staff move, and support. When requesting a quote, ask for the costs split into one-time and recurring items, the systems covered, and which evidence the partner will prepare versus which the organization must maintain itself.

Can an implementation partner issue the compliance result for 03.01.06?

No. An implementation partner can configure privileged access, document the procedures, and prepare the evidence an assessor will examine, interview staff about, and test. Only an independent assessor, such as a DCMA DIBCAC assessor for DoD assessments or another qualified assessor, can determine whether the requirement is met and report it. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. The organization remains responsible for its controls and for the accuracy of any score it submits. Confirm the assessor's role and the reporting path in writing before the engagement starts.

How DeployOpen prepares privileged access evidence for 03.01.06

DeployOpen starts this work by building a complete inventory of privileged accounts inside the client's own infrastructure, because an assessor cannot test a restriction the organization has not identified. The team works with the client to list every account that holds administrative rights on in-scope systems, including accounts created by the system itself, service and automation accounts, and directory groups that grant elevated roles. Each entry is matched to a named role or defined group of personnel, which becomes the value the organization assigns to the 03.01.06 organization-defined parameter. Because NIST does not supply that value, the client must decide it, and DeployOpen's role is to document the decision and make the directory reflect it. The output is a scoped register that the client approves before any configuration changes are made.

Implementation then uses self-hosted open-source identity platforms to enforce the restriction and the separation. FreeIPA, which uses 389 Directory Server as a multi-master LDAPv3 directory, can hold privileged groups and delegated administration rights in one place, so membership is a controlled, reviewable decision rather than a local account setting. authentik's SCIM provider can push user and group changes to target applications and deprovision users when they lose access, which keeps downstream systems aligned with the register. For dual-account separation, DeployOpen configures administrators with a non-privileged identity for email, documents and general browsing and a separate privileged identity used only for security functions. midPoint access certification campaigns can then route role assignments to designated reviewers, who decide within a set timeframe whether to keep, change or revoke them. The client should confirm each platform's exact capability against its own environment before relying on it.

The evidence package is what an independent assessor will examine and interview against. DeployOpen assembles the approved register, the policy and procedure documents for least privilege, configuration exports showing group membership and delegation, samples of separate administrator accounts, certification campaign records and privileged-function audit records. DeployOpen prepares this material but does not assess it, and it does not issue assessment results, attestations or certifications; only the organization's assessor or the relevant assessing body can do that. Engagements are fixed-scope, with the systems covered, deliverables and timelines agreed in writing before work starts. Ongoing reviews of the privileged account population, certification cycles and evidence refreshes are available as retainers, which matters because the register goes stale as people change roles.

03.01.06 Least privilege: privileged accounts