AC-6 Least privilege: requirements and evidence

What AC-6 least privilege asks for and why it is hard to keep

An assessment is coming, and the access list you hand over is longer than anyone planned. AC-6 asks the organization to apply the principle of least privilege: each user, and each process acting for a user, should hold only the access needed to do the job assigned to it. For a person, that means the permissions their current role requires, not the sum of every role they have held since they joined. For a process, such as a service account, an integration or a scheduled job, it means the account can reach only the data and functions its task needs. The principle is simple to state and hard to see in practice, because nobody removes access by default. Users change teams, projects end, temporary grants are never retired, and service accounts gain rights during an incident and keep them afterward. This gradual buildup is usually called access accumulation or privilege creep, and it is the main reason AC-6 findings appear at assessment time.

The control is hard to hold because access is granted on events and removed rarely. Provisioning tickets are closed, but deprovisioning and role changes depend on someone noticing that a permission is no longer needed. Without a recurring review, the set of privileges drifts away from what each person's job actually requires, and a one-time cleanup starts going stale as soon as it is finished. Assessors testing AC-6 typically look for evidence that privileges are defined against assigned tasks, that the lists of assigned authorizations exist and match the system, and that someone reviews them on a schedule and acts on the results. Before the assessment, confirm with your assessor which review frequency and documents your organization's own parameters require, and check whether your access review produces records that show decisions to keep, change or revoke access.

Which systems, accounts and third parties AC-6 reaches

AC-6 applies only where the system's impact level selects it, so scoping starts with the baseline and then follows the accounts and parties that hold privileges. The cards below cover the decisions that change how much least privilege work an assessor will expect, from impact level through service identities to outside administrators.

Impact level decides whether AC-6 applies

SP 800-53B selects AC-6 in the moderate and high baselines and does not select it in the privacy baseline. A system categorized low for confidentiality, integrity and availability may not carry AC-6 at all, while a moderate or high system must meet it with its enhancements. Confirm the categorization in the system security plan before scoping any AC-6 evidence, because the selected baseline sets the whole list of required enhancements.

Enhancements that follow the baseline

In the moderate and high baselines, AC-6(1), AC-6(2), AC-6(5), AC-6(7), AC-6(9) and AC-6(10) apply, and AC-6(3) applies only at high. A high system therefore carries more privileged command and network access work than a moderate one. Build the scope list from the baseline profile, not from the base control alone, so the assessor does not find an unassessed enhancement.

Human administrator accounts

Named administrator accounts, including those used for database, network and directory administration, are the most obvious privileged population. Each one needs a documented list of authorized privileges, a link to a business need and a reviewer. Ask for the account export from each system in scope, because shared or dormant administrator accounts are often the first finding.

Service and process identities

AC-6 covers processes acting for users, so service accounts, CI/CD runners, automation jobs and API tokens fall in scope when they hold elevated rights. Inventory each non-human identity, its owner, its granted permissions and whether it can perform privileged functions. An identity that never logs in interactively can still be the widest-privileged account in the environment.

Cloud and SaaS administrator roles

Cloud tenancies, SaaS admin consoles and infrastructure-as-code pipelines usually grant privileged functions through roles, groups and policies rather than through local accounts. Scope the role assignments in each console and the standing versus elevated access they grant. Confirm which privileged functions the provider exposes and which the organization can configure, because the evidence must show the organization's own grants.

Third-party and managed service administrators

Managed service providers, system integrators and vendor support staff who administer a system are in scope when they hold privileged access, even though the organization does not employ them. Their access should be granted for defined tasks, reviewed like internal accounts and tied to contract terms. Confirm with each provider how it logs in, who on its side holds the credentials and how its access is removed when the engagement ends.

Which AC-6 enhancements the moderate and high baselines select

The moderate baseline selects six of the ten AC-6 enhancements. Each one narrows the basic least-privilege requirement in a specific direction, and each gives an assessor a different thing to examine. Confirm the selection against the SP 800-53B profile and your own tailoring decisions before scoping testing.

AC-6(1), authorize access to security functions: Access to security-relevant functions, such as audit configuration, identity administration and security tool settings, is explicitly authorized for defined roles. Assessors ask for the authorization list and a sample of who holds it.
AC-6(2), non-privileged access for nonsecurity functions: People who hold security roles use a separate, non-privileged account for ordinary work such as email and web browsing. Assessors look for evidence of distinct accounts for daily use.
AC-6(5), privileged accounts: Accounts with elevated rights are limited to personnel with a defined need and tracked as their own population. Assessors compare the privileged account list against the authorized personnel list.
AC-6(7), review of user privileges: Assigned privileges are reviewed at a defined frequency, and rights no longer needed are removed. Assessors check the review records and the follow-up actions taken.
AC-6(9), log use of privileged functions: Execution of privileged functions is logged. Assessors sample audit records to confirm privileged actions appear with the identity of the actor.
AC-6(10), prohibit non-privileged users from executing privileged functions: Systems block non-privileged accounts from running privileged functions. Assessors test this by attempting privileged operations from a non-privileged account and reviewing the denial records.

Check that the frequency and scope values in your system security plan are filled in, because assessors test against those values.

How an assessor tests AC-6 and what they ask to see

This table compares the three SP 800-53A assessment methods for AC-6 Least privilege, the objects each method uses and what the assessor asks you to produce. Read it as a checklist: each row is a line of evidence to have ready before the assessment starts, and the common findings column shows where organizations usually fall short.

Assessment method	Assessment object (SP 800-53A)	What the assessor asks for	Common findings
Examine (determination statement)	List of assigned access authorizations (user privileges) and system audit records	A current list of user privileges per system, plus audit records showing privileged function use, both traceable to assigned tasks	Privilege lists exist but are not tied to defined task needs, or audit records do not capture privileged function use
Interview	Organizational personnel who define least privileges necessary for specified tasks	A walkthrough of how the organization decides which access each task requires and who approves exceptions	Owners cannot explain how privileges were scoped, and approvals are informal or undocumented
Interview	System and network administrators	Explanation of how privileged accounts are separated from everyday accounts and how privileged commands are restricted	Administrators use shared or standing privileged accounts for routine work, or cannot describe the restrictions in place
Test	Mechanisms implementing least privilege functions	Demonstration that role, group or policy settings grant only the intended access, with a sample of accounts checked against the stated need	Settings grant broader access than documented, or non-privileged users can reach privileged functions in practice
Test (illustrative)	Mechanisms implementing least privilege functions	A sample user from each role attempting a privileged action, with the denial or approval recorded	Test results are not retained, so the assessor cannot confirm the mechanism worked on the assessment date
Examine (review evidence)	List of assigned access authorizations and system audit records	Records of periodic privilege reviews, with decisions to keep, change or remove access	Reviews happen once and are not repeated, or reviewers approve access without checking the stated need

How to implement least privilege that passes AC-6 testing

This sequence turns the AC-6 requirement into a set of documented access rules, role models, separated privileged accounts, restricted privileged functions, logs and scheduled reviews that an assessor can examine and test. Each phase ends with an output that can be shown as evidence.

Define task-to-access rules and approvers
The organization, through its system owners and the personnel who define necessary privileges, writes down which tasks each user population performs and the minimum access each task needs. Each rule names the approver who authorizes it. The output is a signed access matrix that maps tasks to permitted accesses, which an assessor can compare against the list of assigned access authorizations. The step is done when every system in scope has an approved matrix with named approvers.
Build role and group models in the identity source
Translate the approved matrix into roles or groups in the directory or identity provider that governs the system, such as FreeIPA or authentik where those fit the environment. Assign users to roles based on the matrix, not on ad hoc requests. The output is a role catalog with membership exports that show who holds which access. Confirm with your platform team which identity source is authoritative for each application before building the models.
Separate privileged and non-privileged accounts
Create distinct administrative accounts for users who need security or privileged functions and keep their everyday accounts free of those rights. Administrators sign in with the privileged identity only for privileged tasks. The output is a register of privileged accounts, their owners and the functions each may perform, which is the list that AC-6(5) and AC-6(1) assessments typically examine. Confirm that privileged accounts are not used for routine email or browsing.
Restrict privileged functions to privileged identities
Configure the systems so that security functions, such as changing access policies, managing audit settings and administering other accounts, are reachable only through privileged roles. Non-privileged users receive no path to these functions, including through command interfaces or API endpoints. Where the high baseline applies, also restrict network access to privileged commands. The output is a tested permission map showing that non-privileged test accounts are denied privileged functions, which supports the AC-6(10) and AC-6(3) checks.
Log privileged function use
Enable audit logging for every privileged function and route the records to a store that the administrators cannot edit. Each entry should show the account, the function, the time and the result. The output is a sample of privileged-use log entries tied to named accounts, which is the audit record evidence an assessor requests for AC-6(9). Verify that logs are generated during a controlled test of a privileged action, not only assumed from configuration files.
Run access certification campaigns
Schedule reviews of user privileges in which designated reviewers decide whether each access item stays, changes or is revoked within a set timeframe. Tools such as midPoint support certification campaigns for role assignments, which helps counter access accumulation and supports segregation of duties. The output is a completed campaign record showing reviewer decisions, revocations and the evidence of follow-through. Define the review frequency in the access control policy, and confirm the frequency against the applicable framework or contract.
Deprovision access when roles change
Connect the identity source to target applications so that role removals and account deletions propagate automatically. The authentik SCIM provider, for example, pushes user and group changes to target applications and deprovisions users who lose access. The output is a change test showing that a removed role disappears from the target application, with the sync log as evidence. Confirm that every in-scope application is covered, because any application left out of provisioning becomes a gap in the review.

Evidence that passes AC-6 and how to keep it current

An assessor testing AC-6 Least privilege looks for a chain of records: what access was granted, who approved it, what privileged actions were logged, whether someone reviewed the grants, and whether blocking controls were tested. Each artifact below supports one link in that chain, and each needs a refresh routine so it reflects the system as it runs today.

List of assigned access authorizations

This is the export of user privileges that an assessor examines first. It should show each user and each process acting for users, the roles or groups that grant access, and the tasks those grants support. Check that the list comes from the live directory or identity provider, not a spreadsheet, and that it covers service accounts and application roles as well as human users. Regenerate it from the source system before each assessment and keep dated copies so changes between assessments can be traced.

Privileged account inventory and approvals

Keep a current inventory of accounts that hold administrative or security function rights, with the approver, the business reason and the date each grant was made. The inventory should separate standing privileges from time-bound elevation so an assessor can see which accounts are permanent. Confirm that every privileged account has a named owner and that no shared administrator logins exist without a documented exception. Reconcile the inventory against directory group memberships each month.

Audit records of privileged function use

Audit records showing when privileged functions ran, by whom and against which system are the evidence for AC-6(9). Confirm that logging is enabled on administrative consoles, privileged commands and security configuration changes, and that the records are protected from the administrators whose actions they capture. Sample several weeks of records and check that each privileged session maps to an approved account. Retention periods should follow the organization's audit policy, which you should confirm with the assessor before the review period starts.

Completed privilege review records

Reviews of user privileges address AC-6(7). Each review record should list the accounts and roles examined, the reviewer, the reviewer's decision to keep, change or revoke each item, and the date the revocations were carried out. An access certification campaign tool can produce this trail, with reviewers deciding within a set timeframe whether to keep, change or revoke role assignments. Ask the assessor how often they expect reviews to occur for your impact level, then schedule them to match.

Blocking tests for non-privileged users

AC-6(10) requires that non-privileged users cannot run privileged functions, so test records should show attempts by standard accounts to perform privileged actions and the denials that followed. Run these tests after each significant role model or directory change, and record the test account, the function attempted, the expected result and the actual result. Store the scripts in version control so the same tests can be repeated. Any failed test should link to a remediation ticket and a retest record.

Provisioning and removal records

Provisioning logs show that privileges were granted and withdrawn through the defined process, and removal records show that access ended when a person left a role. For AC-6 these records support the claim that grants match approvals. Where an identity provider pushes changes to target applications, keep the sync logs and deprovisioning events, and check that a user who loses access to an application is removed from it. Refresh these logs by export at each review cycle so gaps are visible early.

What meeting AC-6 costs in money and effort

This table breaks down the money and effort behind least privilege for AC-6, separating one-time setup from recurring review and evidence work. Read it as a checklist of cost components to request in a written quote, with notes on where self-hosted open-source tooling removes license spend. No figures are given because none were supplied for this topic.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Role design and cleanup	One-time, then recurring when roles change	Number of applications, legacy accounts with accumulated rights, and how many roles must be mapped to job functions	Start from the systems in scope, retire unused roles early, and define a small set of privileged roles before onboarding more applications
Identity platform licenses or self-hosted tooling	Recurring for commercial licenses; one-time setup for self-hosted tools	User count, connected applications, and whether provisioning and certification features are licensed separately	Self-hosted open-source options such as midPoint (EUPL-1.2+), authentik (MIT) and FreeIPA (GPL-3.0-or-later) can remove license fees, but infrastructure and operations effort remain
Engineering time for enforcement	One-time, with recurring tuning	Number of systems that need enforced least privilege, separate privileged and nonprivileged paths, and command-level restrictions for the high baseline	Enforce through existing directory and identity mechanisms first and document any exceptions in the system security plan
Recurring privilege review effort	Recurring	Frequency of access reviews, number of privileged accounts, and how many reviewers are involved	Scope reviews to privileged and high-risk entitlements, use certification campaigns with defined decision timeframes, and automate evidence capture
Logging of privileged functions	One-time setup, recurring storage and review	Volume of privileged function events, log retention needs, and the systems that must forward logs centrally	Log only the privileged functions defined for AC-6(9) and route them to a central store with clear retention settings
Evidence upkeep	Recurring	Frequency of changes to roles, number of systems, and how much evidence is gathered by hand	Keep role inventories, review records and privileged account lists in version-controlled or exported form that can be refreshed on a schedule
External testing or review	Recurring or per engagement	Scope of testing, whether privilege escalation paths are included, and how often testing is repeated	Agree scope in writing, test privilege boundaries as part of wider security testing, and retest only after material role changes
Auditor sampling	Recurring per assessment cycle	Number of accounts and reviews the assessor samples, and how complete the evidence is on first request	Prepare a clean population of privileged accounts and review records so samples can be pulled without rework

How midPoint, authentik and FreeIPA produce AC-6 evidence

Each of the three tools covers a different link in the AC-6 evidence chain, and none of them proves least privilege alone. midPoint produces the review record, authentik shows that access is removed when it should be, and FreeIPA holds the directory structure that defines who can administer what. The organization still owns the decision about which privileges are necessary. The tools only show how those decisions were made and carried out. midPoint (EUPL-1.2+) runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This answers the review expectation in AC-6(7) and counters access accumulation over time. Confirm with the midPoint documentation which campaign results, reviewer decisions and timestamps can be exported as audit records, and whether those exports carry enough detail for an assessor to match each decision to a named privileged role.

authentik (MIT) uses its SCIM provider to push user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and deprovisions users from the target when they lose access to the application. The useful evidence here is the gap between a role being removed in the source and the account being removed in the target, so plan to capture sync logs for a sample of leavers and role changes. Confirm the exact export options for sync events in the authentik documentation before you promise an assessor a particular log format. FreeIPA (GPL-3.0-or-later) uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It provides centralized access control and delegated administration through its web UI and command line tools. For AC-6(1) and AC-6(5), the evidence is a list of who holds administrative roles and which delegations exist, along with the change history. Confirm with the FreeIPA project documentation which audit and change records the directory retains, and where they must be stored to satisfy your retention requirements.

Who does what: your team, a partner and the auditor

AC-6 is an organizational requirement, so accountability for least privilege stays with your organization regardless of who builds the tooling. Your team decides which access is needed for each assigned task, approves privileges, and runs the reviews that show privileges are still appropriate. Those decisions carry the risk, and an assessor will ask who made them and on what authority.

Defining necessary access: Your business and system owners state which tasks need which privileges, and this definition sits in your access control policy and procedures.
Approving privileged assignments: Named approvers, not the people who configure the systems, authorize privileged roles and privileged accounts.
Running privilege reviews: Your managers or designated reviewers confirm, change or revoke user privileges on a defined schedule, and they keep the decision records.
Restricting privileged functions: Your administrators decide who may run privileged functions and who may reach privileged commands over the network.
Keeping ownership of exceptions: Any standing privilege outside the model needs a documented justification and an accountable owner.

Before engaging anyone, confirm that you can name the owner of each privileged role and the reviewer for each review cycle.

Questions buyers ask about AC-6 cost, effort and outsourcing

How much effort does AC-6 take for a moderate system?

The effort depends mostly on how many accounts, roles and privileged functions the system has, not on the control text itself. AC-6 is selected in the moderate baseline, and that baseline also pulls in AC-6(1), AC-6(2), AC-6(5), AC-6(7), AC-6(9) and AC-6(10), so the work covers more than one least privilege statement. Effort rises when role definitions are missing, when privileges were granted ad hoc over years, or when logs of privileged functions are not yet collected. Ask any provider to break the estimate into role analysis, privilege clean-up, logging configuration, evidence capture and assessment support, and to state which items are one-time and which recur.

Can AC-6 be done in-house without an outside partner?

Yes, an organization can implement AC-6 with its own staff, because the organization owns its controls and the decision to meet them. The main questions are whether the team can define least privilege for each task, operate the identity and directory systems that enforce it, and produce evidence that an independent assessor can examine. Teams that lack identity engineering capacity often bring in an implementation partner to prepare systems and evidence, while the assessor remains independent. Only an independent auditor, assessor or certification body issues reports or certificates, so an outside partner does not change who signs the assessment.

What does the work need from the team?

AC-6 work needs people who can answer three kinds of question. Business owners must say which tasks each role performs, so the organization can define the access those tasks need. System and network administrators must explain how privileged functions are currently reached, including network paths to privileged commands in the high baseline. Security or compliance staff must agree the review cadence, the logging scope and the evidence format. Plan time for these people, because the technical changes usually wait on their decisions. Ask the provider which of these inputs it expects from your team in writing.

What does a fixed-scope engagement for AC-6 cover?

Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For AC-6, a written scope would normally state which systems and identity sources are in play, which AC-6 enhancements apply to the system's baseline, which role and privilege inventories will be produced, how privileged function logging will be configured and what evidence package will be handed over. It should also state what the client must provide and what sits outside the work, such as the independent assessment itself. DeployOpen does not publish a price list, and a quote follows from the written scope.

Does AC-6 alone satisfy an assessment?

No. AC-6 is one control among many, and assessors test it alongside related controls such as AC-2 account management, AC-3 access enforcement and AC-5 separation of duties. SP 800-53A gives AC-6 one determination statement and examine, interview and test methods, which means an assessor will look at documents, speak with personnel and test the mechanisms that implement least privilege. A passing result depends on evidence across the system, not on a single privilege list. Confirm with your assessor which related controls they will test and which system boundary they will use.

How often do privilege reviews need to recur?

AC-6(7) requires review of user privileges, and the frequency is set by the organization in its own policy and system security documentation, not by a number in the control text. The review is recurring work, so it carries an ongoing cost in staff time and tooling. Access certification tools can support the cycle. For example, midPoint access certification campaigns let designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments, which helps counter access accumulation. Ask your team to define the review cycle, the reviewers and the records kept for each cycle before you size the work.

What drives the time an AC-6 project takes?

Duration is driven by scope rather than by a fixed number of weeks. The main drivers are the number of identity sources and applications, how many privileged roles already exist, how much role mapping is needed, whether the directory is self-hosted or integrated with external identity providers, and how quickly the organization can make decisions. FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory with centralized access control and delegated administration, and authentik's SCIM provider can deprovision users when they lose application access, so the existing tooling can shorten or lengthen the work. Request a schedule tied to the written scope and the milestones that depend on your team.

How DeployOpen scopes and prepares AC-6 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so least privilege is set up and evidenced where your accounts and roles actually live. We prepare the systems, privilege settings and records that an independent assessor would examine, while your organization keeps ownership of its controls.

How we scope

We agree in writing which systems, identity sources and privileged functions fall within the AC-6 scope.
We list the assigned access authorizations and privileged roles that the written scope will cover.
Engagements are fixed-scope, and ongoing support for privilege reviews is available as a retainer.

How we build

We configure role and group models so users receive only the access their assigned tasks need.
We separate privileged administrative accounts from everyday accounts and restrict privileged functions to authorized roles.
We enable logging of privileged function use and test that access enforcement mechanisms behave as the design states.

How we hand over

We document the privilege model, role definitions and review procedure in a form your assessor can examine.
We deliver privilege review records, privileged function log samples and test results mapped to the AC-6 assessment objects.
We confirm with your assessor which evidence formats and sampling they expect before handover.

How we support

We can run periodic privilege reviews as a retainer, with reviewers recording keep, change or revoke decisions.
We keep role definitions and logging configuration current as platforms are upgraded and patched.
Independent auditors and certification bodies issue any assessment report or certificate, not DeployOpen.

AC-6 Least privilege