AC-3(10): Audited Override of Access Control Mechanisms

To meet the ac-3(10): audited override of access control mechanisms requirement, you must allow any “break-glass” or administrative override of automated access controls only under defined conditions, and you must log, review, and retain evidence of each override event. Operationalize this by implementing a controlled override workflow, strong approvals, immutable logging, and recurring oversight. ¹

Key takeaways:

• Define exactly when overrides are allowed and who can execute them, then enforce that in IAM/PAM workflows. ¹
• Ensure every override is audited end-to-end: event details, approver, justification, scope, and time bounds, with protected logs. ¹
• Treat overrides as high-risk exceptions: require rapid review, compensating controls, and closure evidence. ²

AC-3(10) is one of those controls that looks simple but fails in execution: most environments already have “override” paths (admin consoles, emergency access accounts, firewall rule bypasses, database superuser, SaaS break-glass). The compliance gap happens when those paths are informal, undocumented, or unaudited. Examiners and assessors care because an override is a direct route around preventive access controls, which means it can bypass least privilege, separation of duties, and normal approvals.

NIST’s requirement is short: employ an audited override of automated access control mechanisms. The missing operational detail is what makes or breaks you: clear trigger conditions, strict limitations, workflow enforcement, and evidence you can hand to an assessor without scrambling across tools.

This page gives requirement-level implementation guidance you can execute quickly: what systems it applies to, how to design and operate the override mechanism, what evidence to retain, and the audit questions you should pre-answer. It also includes a practical execution plan and common failure modes seen in real assessments. ³

Regulatory text

NIST excerpt (AC-3(10)): “Employ an audited override of automated access control mechanisms under {{ insert: param, ac-03.10_odp.01 }} by {{ insert: param, ac-03.10_odp.02 }}.” ¹

Operator interpretation of the parameters (what you must decide and document):

• “Under [conditions]”: Define the allowed scenarios (for example: incident response, safety, system recovery, or urgent production outage) and prohibited scenarios (for example: convenience access, routine troubleshooting when standard access is possible). ¹
• “By [roles/individuals]”: Define which roles can request, approve, and execute an override, and how you prevent a single person from doing all three without oversight when feasible. ¹
• “Audited override”: The override must create audit records sufficient to reconstruct what happened, who did it, why, what was changed or accessed, and when the override ended. Those records must be protected from alteration. ²

Plain-English interpretation (what AC-3(10) really expects)

You are allowed to have emergency bypasses of access control, but you must treat them as controlled exceptions:

1. Make overrides hard to use accidentally (gated workflow, explicit justification).
2. Make overrides time-bounded and scoped (minimum access, short duration).
3. Make overrides observable and reviewable (complete audit trail + recurring review).
4. Prove it with evidence (records that tie the event to approvals, logs, and closure actions). ³

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 controls are in scope (for example via agency requirements, authorization boundaries, or customer contractual flow-downs). ²

Operational scope (where overrides exist in practice)

• Privileged Access Management (PAM): emergency admin accounts, password vault “break-glass,” session elevation bypass.
• IAM / Directory services: temporary group membership overrides, forced MFA bypass for locked-out execs (high risk).
• Cloud control planes: emergency changes to IAM policies, security groups, KMS key policies.
• Databases / data platforms: superuser access, row-level security bypass, emergency data fixes.
• Network / security tooling: firewall rule bypasses, endpoint policy exclusions, “allow all” temporary rules.
• SaaS admin: tenant-level admin actions that bypass standard RBAC.

If a team can say, “we can just do X as admin,” you have an override path that must be audited under AC-3(10). ²

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

1) Inventory override paths (don’t start with policy)

Create a list of override mechanisms per system:

• Emergency accounts (local admin, root, “breakglass@”)
• Built-in bypass features (MFA bypass, temporary access tokens)
• “Out-of-band” control paths (console access, direct database access)
• Operational runbooks that imply bypass (“disable policy enforcement,” “turn off guardrails”)

Deliverable: an Override Register (system, mechanism, owner, how invoked, current logging, risk notes).

2) Define allowable conditions and approvals

Write a short standard that answers:

• What events qualify (incident, outage, safety, regulatory obligation, critical customer impact).
• Who can request and who can approve.
• Whether approval can be pre-approved for certain scenarios (and how you document it).
• What must be in the justification (ticket/incident ID, scope, target system, reason). ¹

Practical decision matrix (use it in the standard):

Scenario	Allowed?	Approval type	Maximum scope	Required ticket	Post-review
Production outage	Yes	Manager + security (or on-call approver)	Specific system/service	Incident	Required
Incident response containment	Yes	Security incident commander	Specific hosts/accounts	Incident	Required
Routine troubleshooting	No (default)	N/A	N/A	N/A	N/A
Executive locked out	Rare, tightly controlled	Security approval	Single user	Ticket	Required

3) Implement a controlled override workflow in tooling

Where possible, enforce in systems instead of relying on humans:

• Route requests through ITSM (ticket) or IR tooling (incident).
• Use PAM for checkout of emergency credentials with approvals and time limits.
• Require step-up authentication for the override action (strong auth even if normal controls are being bypassed).
• Enforce time-bound access (automatic expiry / deprovision).
• Require session recording for privileged sessions when feasible (especially where the override grants broad admin).

Goal: the override is not a secret backdoor; it is a formal, observable path. ²

4) Configure audit logging that captures what assessors need

Your logs must answer “who, what, when, where, why, and how long”:

• Who: individual identity, not shared accounts; if shared exists, wrap it in PAM with named checkout.
• What: action taken (role granted, policy changed, rule disabled), objects impacted.
• When: start time, end time, and duration (or expiry).
• Where: source IP/device, console/API used.
• Why: justification text and ticket/incident reference.
• Approvals: approver identity and timestamp. ¹

Protect logs:

• Centralize to SIEM/log platform.
• Restrict who can alter or delete logs.
• Monitor for override events as high-severity signals. ²

5) Establish recurring review and closure

Define an operational cadence:

• Review each override for appropriateness, scope, and closure actions (removal of temp access, rollback of bypass).
• Document corrective actions if the override exposed a design issue (“why did we need this bypass?”).
• Track repeat patterns to eliminate chronic override needs (engineering fixes). ²

6) Map ownership and evidence production (assessment readiness)

Assign:

• Control owner (GRC or Security).
• Process owner (IAM/PAM lead).
• System owners (apps/platforms with override paths).
• Evidence owner (who exports logs/tickets on request).

If you use Daydream, this is where it fits naturally: map AC-3(10) to the accountable owner, the exact procedure, and a recurring evidence checklist so audits don’t become “search and screenshot” exercises. ¹

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

• Policy/standard: “Audited Override of Access Controls” section with conditions and role authority. ¹
• Override Register: inventory of mechanisms and owners.
• Workflow evidence: sample tickets/incident records showing request, approval, justification, and closure.
• PAM/IAM configuration exports: emergency account configuration, approval rules, expiry settings.
• Audit logs: SIEM queries or log exports showing override events and related admin actions.
• Review records: periodic review notes, sign-off, findings, and remediation tracking. ²

Common exam/audit questions and hangups

Expect these, and pre-build answers:

1. “Show me an override event end-to-end.” They want ticket → approval → access grant → activity log → removal/expiry → review record.
2. “Who can override controls, and under what conditions?” If your answer is “admins,” you will get a finding. ¹
3. “How do you prevent unauthorized use of emergency accounts?” Look for PAM gating, MFA, restrictions, and monitoring.
4. “Are override logs tamper-resistant?” If admin users can delete local logs, central logging and access controls become critical. ²

Frequent implementation mistakes (and how to avoid them)

• Mistake: Break-glass account exists, but no one reviews usage.
  Fix: mandate post-event review and capture evidence in the ticket.
• Mistake: Shared emergency credentials with no named accountability.
  Fix: require named checkout via PAM or equivalent.
• Mistake: Overbroad overrides (global admin, allow-all firewall).
  Fix: scope to the minimum system/object and time-box access.
• Mistake: Overrides happen in chat, not in a system of record.
  Fix: require ticket/incident reference in the override workflow and in logs.
• Mistake: Logging exists but cannot be correlated to approvals.
  Fix: enforce ticket IDs in request forms and write SIEM correlation rules.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AC-3(10) primarily as an assessment and authorization risk: override paths are common root causes in security incidents because they bypass preventive controls and reduce traceability. Your risk narrative should be straightforward: if overrides are not audited, you cannot prove authorized use, investigate quickly, or support non-repudiation. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Build the Override Register and identify the highest-risk systems (cloud control plane, directory/IAM, PAM, production databases).
• Publish the minimum viable override standard: allowed conditions, roles, required approvals, required ticketing.
• Turn on/verify centralized logging for override events in the highest-risk systems; document how to query it. ²

Next 60 days (enforce workflow and reduce discretion)

• Implement or tighten PAM emergency access (approvals, expiry, named checkout).
• Require ticket/incident IDs in override requests; train on-call teams.
• Add monitoring/alerts for override events; start a review log with sign-off.

By 90 days (operate the control and make audits easy)

• Run recurring override reviews; document findings and remediation.
• Test an override scenario during an exercise and confirm evidence is produced end-to-end.
• In Daydream (or your GRC system), map AC-3(10) to the control owner, procedure, and recurring evidence artifacts so collection becomes a routine task, not a scramble. ¹

Frequently Asked Questions

Do we have to forbid all overrides to comply with AC-3(10)?

No. AC-3(10) assumes overrides may be necessary, but it requires that overrides occur only under defined conditions and that every use is audited. ¹

What counts as an “automated access control mechanism” in practice?

RBAC/ABAC enforcement, IAM policies, MFA enforcement, conditional access, security guardrails, and other system-enforced controls that normally prevent access or actions. If an admin can bypass it in an emergency path, treat that as in scope. ²

If we use a break-glass account, is logging into the account enough?

Logging the login is rarely enough. You typically need to capture the approval/justification and the actions taken during the override window, then retain review evidence that the access was removed or expired. ²

Can we approve overrides after the fact?

AC-3(10) requires an audited override “under” defined conditions and “by” defined roles, so you should define whether emergency situations allow post-approval and what compensating steps apply. Document that rule clearly and apply it consistently. ¹

How do we handle third-party managed services with their own emergency access?

Treat the third party’s emergency access path as an override mechanism for your environment. Require contract terms and operational reporting that give you audit records for their override events, plus a review process on your side. ²

What’s the minimum evidence an assessor will accept for AC-3(10)?

A documented standard defining conditions and authorized roles, plus at least one complete example showing approval/justification, the override event in logs, and a completed review/closure record tied to a ticket or incident. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON