RMFInsider

AC-6 in Revision 5 is a single sentence: employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks. There is nothing in that sentence an assessor can sample. So AC-6 is almost never failed on intent. It is failed on evidence, and the evidence lives in the enhancements: a privileged account inventory that matches the directory, a dated review of assigned privileges under AC-6(7), administrators holding a privileged account separate from their daily account, and logs showing privileged function use under AC-6(9). If you want to pass AC-6, stop writing philosophy into the implementation statement and start producing artifacts. Below is the artifact list, the exact wording that keeps a review record from being thrown out, and the two findings that recur.

AC-6 is rarely sampled alone. It gets pulled alongside AC-2 account management, the control assessors reach for first, because the same account export answers both, and a contradiction between them is free for a validator to find.

Why a Design Principle Becomes an Evidence Problem

The base control states a principle. Principles are assessed by inference, which means the assessor infers from your artifacts. If the artifacts show a help desk group with the ability to reset privileged account passwords, the inference goes against you no matter how carefully the implementation statement is written. The useful move is to stop defending the principle and start answering the enhancements, because the enhancements have testable objects: account lists, review records, naming conventions and log samples.

What the Moderate Baseline Actually Pulls

SP 800-53B allocates six AC-6 enhancements to the moderate baseline, and each one is a different artifact.

• AC-6(1), Authorize Access to Security Functions: authorize access for defined individuals and roles to defined security functions and security-relevant information. Artifact: a role to privilege mapping, approved in writing.
• AC-6(2), Non-privileged Access for Nonsecurity Functions: require users with access to security functions or security-relevant information to use non-privileged accounts or roles when accessing nonsecurity functions.
• AC-6(5), Privileged Accounts: restrict privileged accounts on the system to defined personnel or roles. Artifact: the named roles, not the phrase “authorized personnel”.
• AC-6(7), Review of User Privileges: review privileges at a defined frequency to validate the need, and reassign or remove them when needed.
• AC-6(9), Log Use of Privileged Functions: log the execution of privileged functions.
• AC-6(10), Prohibit Non-privileged Users from Executing Privileged Functions: prevent non-privileged users from executing privileged functions.

The high baseline adds AC-6(3), Network Access to Privileged Commands. AC-6(4), AC-6(6) and AC-6(8) sit in no SP 800-53B baseline, which does not mean they are absent from your package: CNSSI 1253 and the overlays applied to national security systems can add enhancements, and so can a service or component tailoring decision.

Read Your Own Control Set Before You Write Anything

Open the control in eMASS and read the assessment procedures that are actually there, with their CCIs. I have watched three hours go into an implementation statement for an enhancement the package never selected. The baseline in the book is the starting point. The control set in your package is the requirement.

The Privileged Account Inventory, and Why It Is Never Complete

The inventory is one dated list: every account inside the boundary that holds elevated rights, with an owner by name, a stated purpose, and a type. Four types are enough: human administrator, service or application account, emergency or break-glass account, and vendor or support account.

Inventories come back incomplete because they get built from the directory alone, and the privileges people use day to day are not all in the directory. Pull from the directory groups, then keep pulling: local administrators membership on a sample of hosts, sudoers and wheel membership on the Linux estate, hypervisor and virtual center administrative roles, database system administrator roles, network device accounts at full privilege level, the application role that can change other users, and the backup and storage consoles. The backup console is the one that gets missed, and it can read everything on the system by design.

Service accounts deserve their own column, because the credential lifecycle question lands on them first. The overlap with IA-5 authenticator management and the service accounts nobody will claim is where an AC-6 conversation usually turns into a two control conversation.

AC-6(7): The Review, and the Record That Proves It

The enhancement has two parts. Review, at a frequency you define, the privileges assigned to roles and classes of users you define, to validate the need for those privileges. Then reassign or remove privileges if necessary to correctly reflect mission and business needs. Both halves get tested.

Define the frequency by population rather than giving everything one number. Quarterly for privileged roles and annually for standard users is defensible and it is a cadence you can sustain. Name the roles reviewed in the SSP sentence so the scope of the review is not a judgment call during the assessment.

A review record that survives sampling contains all of this.

• The period and the as-of date, with the account export attached as it looked on that date. Attach the export, not a link to a live page that will have changed by the time anyone opens it.
• The roles or populations reviewed, matching the wording in the SSP.
• The reviewer and the validating authority: the ISSO can run the review, but the data owner or system owner is who validates that the privilege is still needed.
• A per-account decision recorded as keep, reduce or remove. A list with no decision column is an inventory, not a review.
• Actions taken, with dates and ticket or change request numbers for every reduction and removal.
• Signature and date.

Four consecutive quarterly reviews with zero removals will draw a question, and it is a fair one. Privilege creep is constant in an organization where people transfer, so a review that never finds anything suggests the review is reading the wrong list. Transfers are also where this control touches the PS controls covering onboarding, transfers and terminations, and a transfer that added rights without removing the old ones is the classic finding.

Two Accounts, Two Purposes

AC-6(2) is the separation requirement in plain terms: an administrator reads email and browses with a standard account and administers with a separate privileged account. Make it visible with a naming convention, then make the convention evidence. Document it, produce a directory export showing the paired accounts, and show that the privileged accounts have no mailbox and are denied the logon rights they do not need.

AC-6(5) is the companion: privileged accounts restricted to named roles. Write the roles into the SSP, by title, with the approval path for adding someone. The Windows Server STIGs carry much of the technical enforcement here, including the deny-logon and administrator account restriction rules, and on Linux the sudoers configuration is the artifact. The STIG results prove the setting. They do not prove you decided who should hold the privilege, which is what AC-6(5) is asking.

Privileged Function Logging, and the Handoff to the Audit Family

AC-6(9) in Revision 5 says log the execution of privileged functions. That wording hands the work to the audit family, because the event selection lives in the AU-2 and AU-12 logging requirements for DoD systems. Your AC-6(9) evidence is two items: the audit configuration that generates elevation and privileged command events, and a dated log sample showing those events for a real period.

AC-6(10) is the prevention side, including preventing non-privileged users from circumventing the safeguards. Evidence is configuration: user account control settings, sudoers restrictions, application role configuration that blocks self-elevation. Expect an assessor to ask for a negative test, where a standard account attempts a privileged action and is refused, with a screenshot and a date.

The Two Findings That Recur

Service Accounts with Domain Admin That Nobody Will Claim

Every over-privileged service account is an orphan, and the paperwork agrees: three teams, each certain it belongs to the other two. The honest path out is sequential. Inventory it. Get a dated memo assigning an owner, even provisionally, because an owner can be asked questions and a blank cannot. Then open a POA&M line with a documented reduction plan and target dates, and test the reduction in a maintenance window before you make it permanent. An over-privileged account with an owner and a dated plan is a risk you are managing. The same account with no owner is a finding with no end date.

A Review That Was Performed but Not Recorded

“We go through privileged accounts every quarter in the sync” is something I believe and an assessor cannot credit. The work was done. The control still fails, because AC-6(7) is assessed on the record. Three minutes of writing at the end of the meeting converts a performed review into a passed control, and the gap between those two outcomes is the single cheapest win in the AC family. Build the habit before the team arrives, not during the week you are getting a package ready for an SCA-V assessment.

The Artifact List

Hand over these and AC-6 stops being an argument.

• The privileged account inventory, dated, with owner, purpose and account type per entry.
• A group membership export for every privileged directory group, dated the same day as the inventory.
• Local administrators and sudoers evidence for a named sample of hosts, with the sample basis stated.
• Signed AC-6(7) review records for the last two cycles, with the account exports attached.
• The account naming convention and the separation of duties statement covering privileged versus daily accounts.
• The role to privilege mapping for the application, approved by the system or data owner.
• Audit configuration plus a log sample showing privileged function execution.
• POA&M entries for every over-privileged account not yet reduced, each with an owner and a target date.

Every AC-6 gap described above ends in the same place: a POA&M line with an owner, a scheduled completion date and milestones that hold up to a quarterly review. If yours lives in a spreadsheet that gets opened the week before an assessment, the POA&M Tracker has the fields validators ask for and the cadence to keep the dates current. Load your privileged account gaps into it this week and you will walk into Step 4 with a plan rather than a list.