Trackr.Live The landing site for Trackr Services
§ Trackr.Live

AC — Access Control

Access Control is the first control family in NIST SP 800-53, and on most systems it is also the family with the largest live control count and the one assessors spend the most time on. AC governs who gets onto the system, what they can touch once they are on, and how those grants are created, constrained, and torn down. It does not authenticate anyone (that is IA), and it does not record what they did (that is AU). Keeping those boundaries straight matters, because a lot of bad SSP prose smears AC, IA, and AU into one undifferentiated “access” blob, and an assessor who reads carefully will catch it.

Schematic of a layered access boundary: an identity badge resolving into a set of permission gates, with several gates open and most closed, feeding into a guarded enclave.

AC is a control catalog family from SP 800-53, not a stage of the RMF. The RMF itself is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. AC controls get pulled in at Select, implemented and documented at Implement, and graded at Assess, with whatever didn’t pass landing in the POA&M and riding into continuous monitoring. So when someone says “we’re doing AC for the RMF,” what they mean is: the baseline picked a set of AC controls, and now those controls need real implementations and SSP narratives that survive an assessor reading them against the actual system.

What’s in the family

In Rev 5 the AC family spans AC-1 through AC-25, but that range is not a continuous list of live controls. Several were withdrawn or rolled into other controls during the Rev 4-to-Rev 5 cleanup. AC-15 (automated marking) is withdrawn; a handful of others were incorporated elsewhere. If your SSP still cites a withdrawn AC control by number, that is a Rev 4 artifact someone forgot to retire.

The ones that carry the weight:

  • AC-1, Policy and Procedures. Every family has a -1. It is the documented org-level policy and the procedures that operationalize it. Boring, mandatory, and the first thing pulled in an assessment because everything else inherits its existence from here.
  • AC-2, Account Management. The account lifecycle: request, approve, provision, modify, disable, remove, review. Enhancements do most of the real work, especially AC-2(1) automated management, AC-2(3) disable inactive accounts, and AC-2(12) monitoring for atypical usage.
  • AC-3, Access Enforcement. The technical mechanism that actually enforces the authorizations AC-2 hands out. AC-2 decides Jane should have read on the share; AC-3 is the thing that says no when she reaches for write.
  • AC-4, Information Flow Enforcement. Boundary and cross-domain flow control. On most Moderate systems this is light; on anything with a CDS or multi-enclave routing it becomes a project of its own.
  • AC-5, Separation of Duties and AC-6, Least Privilege. The two that auditors love because violations are concrete and demonstrable. The AC-6 enhancements are where most of the findings live: (1) authorize access to security functions, (2) non-privileged access for non-security functions, (5) privileged accounts, (9) logging privileged-function use, (10) prohibit non-privileged users from executing privileged functions.
  • AC-7, Unsuccessful Logon Attempts and AC-8, System Use Notification. Lockout thresholds and the login banner. AC-8 is the one assessors literally screenshot: the consent-to-monitoring banner has approved language for federal and DoD systems, and if yours says something a lawyer wrote in 2011, expect a finding.
  • AC-11 / AC-12, Device Lock and Session Termination. Inactivity lock (AC-11(1) pattern-hiding display so the screen doesn’t leak the last thing you were doing) and termination of the session itself. Rev 5 renamed AC-11 from the old “Session Lock” to “Device Lock”; an SSP still calling it Session Lock is quoting Rev 4.
  • AC-17, Remote Access. VPN, jump hosts, bastion access. AC-17(2) crypto protection, AC-17(3) managed access points. This is the one that breaks in interesting ways (more below).
  • AC-18 / AC-19, Wireless and Mobile Devices. Often N/A on a pure datacenter system, often a mess on anything with a field component.
  • AC-20, Use of External Systems. The inheritance boundary. This is where your PaaS or SaaS provider’s responsibility ends and yours begins, and it is the single most misunderstood control in any cloud SSP.
  • AC-21 / AC-22, Information Sharing and Publicly Accessible Content. PII sharing decisions and keeping nonpublic data off the public-facing surface.

Baselines and where the controls come from

The baselines no longer live in 800-53. In Rev 4, Low/Moderate/High allocations sat in Appendix D of the catalog itself. Rev 5 split them out into SP 800-53B, which is the document you tailor against. FIPS 199 sets your categorization, FIPS 200 sets the minimum-security floor, and 800-53B turns the resulting impact level into a starting control set. For national-security systems, CNSSI 1253 overlays it instead. FedRAMP and DoD (via the RMF and DoDI 8510.01) layer their own overlays on top.

Which means the AC controls in your system are not a free choice. They are: the 800-53B baseline for your impact level, plus or minus tailoring you can defend in the SSP, plus whatever your overlay forces. Tailoring out AC-6(9) on a High system because “it’s noisy” is a conversation you will lose.

Deeper: the difference between a baseline and your control set.
The 800-53B baseline is a starting point, not the answer. Tailoring is the documented act of adding, removing, or adjusting controls and enhancements from that baseline, and every tailoring decision needs a rationale the AO will accept. Removing a control because it doesn’t apply (no wireless, so AC-18 is N/A) is clean. Removing one because it’s inconvenient is not. Overlays run the other direction: FedRAMP’s Moderate baseline pulls in AC enhancements above the bare 800-53B Moderate set, and a national-security system under CNSSI 1253 may carry a different selection entirely for the same impact level. The SSP has to show the math, baseline to overlay to final control set, or the assessor can’t tell a deliberate tailoring decision from a control someone simply forgot.

Control Typical first live at What an assessor actually checks
AC-2 Low Pull a current user list, sample disabled/terminated accounts, check the dates against the recert evidence. Stale accounts = finding.
AC-3 Low Attempt an unauthorized action with a test account; confirm enforcement, not just policy.
AC-6 Moderate Who holds admin/root, and why. Maps privileged accounts to a documented need.
AC-6(9) Moderate/High Privileged-function execution is logged and the log is reachable (ties straight to AU).
AC-7 Low Lockout threshold config matches the SSP-stated value.
AC-8 Low Screenshot of the banner, compared to approved language.
AC-11 Moderate Lock timeout configured and enforced, not just documented in a GPO that doesn’t apply to the OU.
AC-17 Low Remote-access paths enumerated, crypto verified, split-tunnel posture confirmed.
AC-20 Low The inheritance story for the external service is real and matches the CRM/responsibility matrix.

Treat the “first live at” column as directional, not gospel. Your overlay moves things, and an enhancement that’s optional at Moderate is often mandatory at High.

Where it actually goes wrong

AC-2 recertification rot. The control says review accounts periodically. The procedure says quarterly. What you find in practice is a recert that gets rubber-stamped: a manager hands a list of forty names, the manager clicks approve-all because forty names on a Friday afternoon is forty names on a Friday afternoon, and three of those accounts belong to people who left in Q2. The recert happened. The artifact exists, the date is current, and it is worthless. An assessor who cross-references the recert against the HR offboarding feed (or just samples five terminated employees and looks for live accounts) will find this every time the process is theater. If you own the control, automate the cross-check: AC-2(3) disable-on-inactivity is the cheapest real control in the family and most shops underuse it.

AC-6 least-privilege drift. Least privilege is true on day one and false by month nine. Someone needs elevated access for a migration, gets it, the migration ends, the grant doesn’t. Multiply by every emergency for a year. The SSP narrative still describes the clean day-one state. AC-6(9) logging exists precisely so this drift is visible in the audit record, which is why High baselines force it and why tailoring it out is hard to defend.

AC-17 remote-access edge cases. The standard VPN story is clean. The edge cases are not. Split-tunnel that someone enabled for a video-conferencing carve-out and never closed. The jump host that’s in scope for AC-17 but whose own access controls were never assessed because everyone assumed it was “just infrastructure.” Vendor maintenance access (which is really AC-17 wearing an MA hat) that comes in over a path nobody documented. Contractor laptops hitting the environment from a network you don’t control. Enumerate every remote path, not just the sanctioned one, because the assessor will ask “is that the only way in” and the honest answer is usually “no.”

PaaS / cloud inheritance under AC-20. This is where I’ll plant a flag: most AC inheritance claims in cloud SSPs are overstated, and AC-20 is where it shows. Inheriting AC-2 from your CSP for the platform’s accounts does nothing for your application’s accounts. FedRAMP authorizes the platform’s control implementation, not yours. The customer-responsibility matrix exists exactly to draw that line, and “inherited from [CSP]” written against a control the CRM marks as customer-responsibility is a finding waiting to happen. On a PaaS the split is genuinely murky for AC-3 and AC-4 (you control app-layer enforcement, the provider controls the substrate), and writing that boundary honestly is more useful than claiming a clean inheritance you can’t back up. GovCloud versus commercial changes the authorization boundary too; don’t copy a commercial-tenant SSP into a GovCloud system and assume the inheritance carries.

Artifacts

AC implementations land in three places. The SSP carries the control narrative: how each AC control is implemented on this system, in specifics, not catalog paraphrase. The SAR is the assessor’s verdict on whether those narratives match reality. The POA&M holds whatever failed, with a remediation date that someone will eventually be asked about. The fastest way to fail an AC assessment is an SSP that restates the 800-53 control text back at the assessor instead of describing the system. They have read the catalog. They want to know what you did.

If your AC narratives could be copy-pasted into any other system’s SSP without changing a word, they are too generic to pass, and that genericness is the single most common reason AC control implementations come back as “Other Than Satisfied.”

Sources

Adjacent material on this site