RMFInsider

AC-2 is the account management control in NIST SP 800-53 Revision 5, and it carries twelve lettered requirements that cover the entire life of an account: which account types are allowed, who manages them, who approves creation, how use is monitored, how often accounts get reviewed, and how all of that ties back to the personnel termination and transfer process. Assessors sample AC-2 early because it is one of the few controls where the evidence is live. They do not have to take your word for anything. They pull a user list, pick five names, and ask for the signed access request, the training record, and the out-processing checklist behind each one. If any of the three is missing, the control comes back other than satisfied, and the rest of the access control family starts the assessment underwater.

What AC-2 Says in Revision 5

Revision 5 rewrote the control into twelve lettered requirements. If your implementation statement still reads like Revision 4, the letters have moved under you and one requirement is genuinely new. Here is the whole control in plain language, with the assignment language spelled out instead of bracketed.

1. Define and document the account types allowed on the system, and the types specifically prohibited. Naming the prohibited types is the new part.
2. Assign account managers, by name or by role.
3. Set the prerequisites and criteria for group and role membership.
4. Specify, for each account, the authorized users, the group and role membership, and the access authorizations.
5. Require approval from named personnel or roles before an account is created.
6. Create, enable, modify, disable, and remove accounts according to a documented policy and procedure.
7. Monitor the use of accounts.
8. Notify account managers inside a stated timeframe when an account is no longer needed, when a user is terminated or transferred, and when system usage or need to know changes.
9. Authorize access based on a valid access authorization, the intended system usage, and any other attributes the organization requires.
10. Review accounts for compliance with your own account management requirements on a stated frequency.
11. Establish and implement a process for changing shared or group account authenticators when somebody leaves that group.
12. Align account management with the personnel termination and transfer process.

The last requirement is the one that quietly does the damage. It is not a technical control at all. It is an agreement between the ISSO and whoever runs in-processing and out-processing, and it breaks when those two functions sit in different buildings with different ticket queues. For the wider picture of how the control families are laid out in Revision 5, the walkthrough in NIST 800-53 controls explained covers the structure.

Why Assessors Sample AC-2 First

The evidence is live, not narrative

An assessor cannot independently verify a contingency plan without watching you run an exercise. They can verify AC-2 in twenty minutes with a user export and three questions. That asymmetry is the entire reason the control lands early on an assessment agenda. It produces a defensible finding quickly, and the finding is difficult to argue with, because the system generated the evidence rather than you. The prep work described in how to prepare for an SCA-V assessment is worth doing before the in-brief, not after it.

One bad sample widens into the whole family

AC-2 sits upstream of AC-3, AC-5, AC-6 and IA-2. If the account list is wrong, every control that depends on knowing who has access becomes suspect. An assessor who finds two orphaned accounts in a sample of five will widen the sample, and a widened AC-2 sample tends to produce findings on least privilege and separation of duties as a byproduct. One sloppy spreadsheet turns into four findings and a POA&M line each.

The Failures That Show Up Again and Again

• Orphaned accounts. A user rotated off the program in April and the account was still enabled in September, and nobody can produce the out-processing checklist. The DISA Security Requirements Guides set automatic disable at 35 days of inactivity, so a live account with a last logon five months back is a finding against your own configuration before it is a finding against the control.
• Approval records that do not exist. The account is legitimate, the person is legitimate, and there is no signed system authorization access request behind it. Requirement e is explicit that approval comes before creation. A help desk ticket reading “create account per email from the PM” is not an approval record.
• Group membership with no criteria. Requirement c asks for prerequisites and criteria. Answering “the ISSM approves it” describes a process, not criteria. The assessor wants to know what makes somebody eligible for the privileged group before the ISSM is ever asked.
• Shared and service accounts nobody owns. Requirement k needs a documented process for rotating a shared authenticator when somebody leaves the group. Service accounts running scheduled jobs fail here reliably, because the credential has not changed since the system was stood up and the last person who knew it rotated off the contract two years ago.
• Account reviews that are not reviews. A spreadsheet with a date on it is not a review. The assessor looks for evidence of a decision: accounts flagged, accounts removed, a signature, and a follow-up showing the flagged accounts actually went away.

The account review is the artifact that ages in dog years. A user list you pulled in March is a historical document by the time a validator opens it in September, and validators can read a file creation date as well as you can.

The Evidence Package That Passes

Build the AC-2 evidence set once and keep it current, instead of assembling it the week the assessment team lands. What holds up under sampling:

1. A current account inventory export from the authoritative source, dated, with account type, owner, privilege level, creation date and last logon.
2. A signed access request behind every account on that export, filed so you can pull any single one of them inside a minute.
3. The account management procedure that names the account managers, the approval authority, the review frequency, and the disable and removal timelines. This is the document requirement f points at.
4. The last three account reviews, annotated with what was found and what was done, plus the tickets proving the removals happened.
5. Signed out-processing checklists for recent departures, each showing a dated account disable step.
6. Configuration exports or screenshots proving the inactivity setting is enforced on the system, not merely written into the procedure.

Each of those maps to a specific assessment procedure and CCI, which is how a validator actually grades the control rather than reading your narrative. If you are unsure how CCI-level detail turns into a pass or fail, the walkthrough on entering test results in eMASS shows the same screens the validator is working from.

The Enhancements DoD Baselines Pull In

AC-2 carries thirteen enhancements in Revision 5. These are the ones that land on a moderate or high DoD baseline, and what each one costs you in practice:

• AC-2(1) Automated System Account Management. You need tooling, not a process narrative. Active Directory plus an identity governance product satisfies it. A shared mailbox does not.
• AC-2(2) Automated Temporary and Emergency Account Management. The Security Requirements Guides commonly set this window at 72 hours. Prove the automation, not the intent.
• AC-2(3) Disable Accounts. This is where the 35 day inactivity rule lands, alongside disabling accounts with expired credentials and accounts belonging to users who no longer need them.
• AC-2(4) Automated Audit Actions. Creation, modification, enabling, disabling and removal all get logged, and account managers get notified. This is the handoff point to AU-2 and AU-12, so the two evidence sets have to agree with each other.
• AC-2(5) Inactivity Logout. Trivial to satisfy with a group policy object, easy to fail when one legacy application ignores it.
• AC-2(7) Privileged User Accounts. A role-based scheme plus a review of privileged assignments. Assessors sample privileged accounts separately and at a higher rate.
• AC-2(9) Restrictions on Use of Shared and Group Accounts. If you use them, document the conditions. If you claim you do not use them, the assessor will still go looking for service accounts.
• AC-2(12) Account Monitoring for Atypical Usage. This needs a detection capability and a written definition of atypical. Pointing at the SOC works only if the SOC can show you the rules.
• AC-2(13) Disable Accounts for High-risk Individuals. A defined timeframe and a named trigger, normally from the security office or the insider threat program.

Writing the Statement So It Survives Validation

AC-2 implementation statements fail for the same reason other statements fail: they restate the control instead of describing the system. Go requirement by requirement and name the tool, the role, the frequency and the artifact. “Accounts are reviewed periodically” is a restatement. “The ISSO exports the account list from Active Directory on the first business day of each month, reconciles it against the signed access request folder, and forwards discrepancies to the ISSM for removal within five business days” is an implementation, and a validator can test every clause of it. The examples in how to write a control implementation statement are worth copying the structure from rather than the wording.

AC-2 is not a difficult control. It is an unforgiving one, because it is the one place in the package where an assessor can hold what you wrote next to what the system is doing, live, while you watch. Fix the account review first, the approval records second, and the out-processing handoff third, and the rest of the access control family gets considerably quieter. If you want the full list of what should be staged before an assessment team opens your package, work through the RMF Checklist and start at the top.