AC-6(1): Authorize Access to Security Functions

AC-6(1): authorize access to security functions requirement means you must explicitly approve which roles, accounts, and systems are allowed to perform security-relevant actions (for example, changing configurations, managing logs, or administering identity controls), and you must be able to prove that approval. Operationalize it by defining “security functions,” restricting access via RBAC/PAM, and retaining access-approval evidence tied to each function.

Key takeaways:

• Define and inventory “security functions” per system, then map each function to approved roles and named admins.
• Enforce approvals in tooling (RBAC, PAM/JIT, change control) so access can’t be granted ad hoc.
• Keep assessor-ready evidence: access matrices, tickets/approvals, role definitions, and periodic reviews.

AC-6(1) sits inside the NIST SP 800-53 Access Control family and tightens least privilege around the actions that can change your security posture. For a CCO, GRC lead, or Compliance Officer, the operational problem is rarely “do we have admins?” It’s “can we show that only the right people can touch the security controls, and that access was intentionally authorized, reviewed, and removed when no longer needed?”

This requirement is easiest to pass when you treat it like a closed-loop authorization system: define the security functions, pre-authorize who can perform them, technically enforce those authorizations, and retain evidence that the process ran. Auditors typically test this control by picking a handful of sensitive systems (identity, endpoint security, logging/SIEM, cloud control plane) and tracing whether the people with access were approved for those specific functions.

Done well, AC-6(1) reduces the blast radius of account compromise and prevents “shadow admin” sprawl. Done poorly, it fails on evidence: informal approvals, shared accounts, undocumented admin entitlements, or access that lingers after role changes.

Regulatory text

Control statement (excerpt): “Authorize access for {{ insert: param, ac-06.01_odp.01 }} to:” ¹

How operators should read this: AC-6(1) requires explicit authorization for access to security functions. In practice, you must (1) identify which functions count as security functions in your environment, (2) specify who is allowed to perform them, and (3) implement access controls so only those authorized identities can execute them, with reviewable records. The “authorize access” verb is the core: you need provable approval, not just technical capability. ²

Plain-English interpretation

Security functions are the “controls over the controls.” If someone can disable MFA, change firewall rules, alter audit logging, or grant themselves privileges, they can defeat your security program. AC-6(1) expects you to put those actions behind named roles, documented approvals, and technical guardrails (RBAC/PAM/change control), then show evidence during assessment.

Who it applies to

Entity scope:

• Federal information systems and contractor systems handling federal data that adopt NIST SP 800-53 as a control baseline ²

Operational context (where assessors look first):

• Identity and access management (IdP, directory services, MFA administration)
• Cloud control planes (AWS/GCP/Azure org, subscription/project, IAM)
• Security tooling administration (EDR, email security, SIEM, vulnerability scanning)
• Network/security infrastructure (firewalls, WAF, VPN, NAC)
• Logging/audit pipelines and retention settings
• Key management and secrets platforms (KMS/HSM, vaults)
• Endpoint and server configuration management

If you run these functions through third parties (managed SOC, MSP, cloud consultants), AC-6(1) still applies. You must authorize their identities and roles, not just trust the contract.

What you actually need to do (step-by-step)

Step 1: Define “security functions” for your environment

Create a list of security functions that materially affect confidentiality, integrity, availability, or auditability. Keep it concrete and system-specific.

Practical starting categories:

• Privilege management (grant/revoke admin roles, create service accounts, manage API keys)
• Security configuration changes (policies, baselines, conditional access, firewall rules)
• Monitoring and logging changes (disable logging, change log routing/retention, SIEM rules)
• Cryptographic and secrets operations (key rotation, vault policy changes)
• Incident response “break glass” actions (emergency access, containment tooling actions)

Artifact: “Security Functions Register” (by system/tool) that names each function and where it is performed (console, API, admin portal).

Step 2: Map each security function to authorized roles and approval authority

For each function, define:

• Authorized role(s): e.g., “Cloud Security Admin,” “SOC Engineer,” “IAM Admin”
• Approval authority: e.g., CISO delegate, Security Manager, Change Advisory Board (CAB)
• Constraints: MFA required, corporate device required, network restrictions, JIT only
• Separation-of-duties flags: functions that should require dual approval or independent review

Artifact: “AC-6(1) Access Authorization Matrix” with columns: System, Security Function, Role, Named Group, Approver, Enforcement Method, Evidence Location.

Step 3: Enforce authorizations in access systems (don’t leave it in policy)

Policy-only implementations fail quickly. Tie the matrix to technical controls:

• RBAC/Groups: Put security functions behind groups tied to roles (IdP groups, cloud IAM roles).
• Privileged Access Management (PAM): Require JIT elevation, approvals, session recording where feasible.
• Change control integration: Route security configuration changes through ticketed change workflows for in-scope systems.
• Service account controls: Limit token scopes, rotate secrets, restrict who can create or modify privileged service principals.

Operator tip: If you can’t enforce a function directly (some legacy tools are coarse), enforce the path to that function: dedicated admin accounts, network segmentation to admin interfaces, and compensating monitoring for privileged actions.

Step 4: Implement an authorization workflow that creates durable evidence

Define how authorization happens for employees and third parties:

• Request submitted with business justification and scope (which security functions)
• Approver verifies need-to-know and least privilege
• Provisioning executed by an admin who is not self-approving (where feasible)
• Confirmation captured (ticket closure + access assignment log)
• Auto-expiry for temporary access, or recertification for standing access

Minimum expectation: A traceable record that connects a person (or third-party identity), the access granted, and the approval.

Step 5: Review and remove access on a recurring basis

AC-6(1) is hard to defend if permissions accumulate over time.

• Run periodic reviews of privileged groups/roles tied to security functions.
• Reconcile HR role changes and offboarding to remove access quickly.
• Validate third-party access terms: named users, start/end dates, sponsor, and scope.

Artifact: Completed access review attestations plus evidence of removals (tickets, IAM change logs).

Step 6: Test the control like an auditor will

Build a simple test script:

• Pick critical systems (IdP, cloud IAM, SIEM, EDR).
• For each, list security-function roles and export current membership.
• Sample memberships and trace each back to an approval record.
• Verify technical enforcement: confirm role grants the function and non-members can’t perform it.

This turns AC-6(1) into a repeatable control, not a one-time documentation exercise.

Required evidence and artifacts to retain

Keep evidence tightly mapped to “authorize access”:

1. Security Functions Register (system-by-system list of security functions).
2. AC-6(1) Access Authorization Matrix (functions → roles/groups → approver).
3. Role descriptions and RBAC design (what each privileged role can do).
4. Provisioning records (tickets/requests, approvals, and implementation evidence).
5. Current access exports (privileged group membership, IAM role assignments).
6. Access review outputs (attestations + remediation actions taken).
7. Third-party access documentation (named accounts, sponsor, contract/SOW linkage where relevant, and termination steps).
8. Break-glass procedure and access logs (who can invoke, under what conditions, and what happened when used).

Daydream fits cleanly here as the system of record that links the control owner, the implementation procedure, and the recurring evidence artifacts into an assessor-ready package, so you can answer “show me authorization” without rebuilding context each audit cycle.

Common exam/audit questions and hangups

Assessors and auditors typically probe these points ²:

• “Define security functions in your environment. Which systems are in scope?”
• “Show the list of people who can administer the IdP / cloud org / SIEM. Who approved them?”
• “How do you prevent ad hoc admin grants outside the workflow?”
• “Do third parties have privileged access? Are they named, scoped, and time-bound?”
• “Show evidence of access reviews and removals.”
• “Can an admin approve their own access? If yes, what compensating control exists?”

Hangup to anticipate: Teams can produce a privileged access list but cannot tie each entitlement to an approval and a defined security function.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating “security functions” as “anything admin does”	Scope becomes un-auditable and inconsistent	Define a bounded register focused on control-impacting actions; keep it per system/tool
Shared admin accounts	No individual authorization trail	Require named accounts; use PAM for escalation and session accountability
Approval exists but not tied to specific functions	Authorization is too generic	Approvals must reference role/group that maps to specific security functions
Third-party admin access granted informally	Creates unmanaged privileged paths	Force third parties through the same RBAC/PAM and approval workflow; require a sponsor
Access reviews done but no remediation evidence	Looks performative	Retain tickets/logs showing removals, downgrades, or documented exceptions
Break-glass accounts ignored	High-impact access without governance	Define who can use break-glass, require post-use review, and store logs with the ticket

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions. Operationally, AC-6(1) failures increase the chance that one compromised admin credential becomes a full security-control takeover: disabling logging, weakening MFA, or changing alerting rules. That risk is why auditors demand both technical restrictions and evidence of explicit authorization. ²

A practical 30/60/90-day execution plan

First 30 days (foundation)

• Assign a control owner and define in-scope systems where security functions live (IdP, cloud IAM, SIEM, EDR).
• Draft the Security Functions Register for those systems.
• Build the AC-6(1) Access Authorization Matrix and align approvers.
• Pull current privileged access exports and identify gaps (no owner, no ticket, unknown third-party accounts).

By 60 days (enforcement and workflow)

• Convert the matrix into enforced RBAC groups/roles; remove direct user grants where possible.
• Stand up or tighten PAM/JIT for the most sensitive roles; require MFA and strong admin access paths.
• Implement a standard access request form that forces selection of specific security-function roles.
• Remediate obvious issues: shared accounts, orphaned accounts, and third-party access without sponsors.

By 90 days (audit-ready operation)

• Run an access review cycle for security-function roles; document removals and exceptions.
• Execute an internal audit-style sample: trace selected admins to approvals and verify technical enforcement.
• Package evidence for assessors: register, matrix, exports, approvals, review results, and break-glass records.
• Put recurring reminders and evidence capture on a compliance calendar so the control stays alive.

Frequently Asked Questions

What counts as a “security function” for AC-6(1)?

Treat security functions as actions that can change or disable security controls, alter monitoring/logging, or grant privileges. Define them per system (IdP, cloud IAM, SIEM, EDR) and document them in a register so your scope is consistent. ²

Do I need a formal ticket for every admin permission change?

You need durable authorization evidence that ties a person to a privileged role and approver. A ticket is the simplest way to produce that evidence, but some organizations use IAM workflow logs or PAM approval records if they are retained and searchable.

How do we handle third-party administrators (MSP/MSSP/consultants)?

Require named third-party accounts, map them to the same privileged roles as employees, and route access through your approval workflow with an internal sponsor. Avoid permanent standing access unless you can justify it and review it regularly.

Are break-glass accounts allowed under AC-6(1)?

Yes, but they still need pre-authorization (who can access them, under what conditions) and strong accountability. Keep access logs and require a post-use review record tied to an incident or change ticket.

What’s the minimum evidence an auditor will accept?

Expect to show (1) a defined list of security functions, (2) a role/group mapping that restricts those functions, (3) approval records for each privileged user, and (4) periodic review outputs with remediation proof.

We have coarse “admin” roles in a legacy tool. How can we comply?

Document the limitation, restrict who can access the tool’s admin role, and add compensating controls around the admin path (dedicated admin accounts, tighter network access, stronger MFA, and monitoring of privileged actions). Keep the authorization matrix and approval trail clean.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5