AC-3(2): Dual Authorization

Dual authorization is a practical control for the riskiest moments in system administration: when a single operator could change access rules, disable security monitoring, alter logs, move sensitive data, or modify production in ways that are hard to reverse. AC-3(2) makes this requirement explicit by calling for enforced dual authorization for privileged commands and/or other actions. ¹

For a CCO or GRC lead, the fastest path is to treat AC-3(2) as a small number of tightly scoped “must-never-be-one-person” actions, then build an approval gate that cannot be bypassed during normal operations. Your success in audits will hinge on two things: (1) scope discipline (a clear list of actions and systems), and (2) evidence quality (records that show two different authorized individuals approved before the action was executed). ²

This page gives requirement-level implementation guidance: who it applies to, what to implement, how to prove it is operating, and how to avoid common failures that show up in assessments.

Regulatory text

Requirement (excerpt): “Enforce dual authorization for [privileged commands and/or other actions].” ²

What the operator must do:

1. Decide which privileged commands/actions are covered (the bracketed scope is your selection).
2. Implement a technical or workflow-enforced mechanism that requires two separate authorizations before execution.
3. Ensure the authorizers are independent and authorized, and the action is blocked without both approvals.
4. Maintain records that show the approvals occurred before execution and map to the specific action taken. ¹

Plain-English interpretation

AC-3(2) means: for certain high-impact administrative actions, one person cannot request and execute the action alone. A second authorized person must explicitly approve the exact action (with enough context to make a real decision), and the system must prevent execution until that approval exists. ¹

Dual authorization is commonly paired with separation of duties: the requester and approver should not be the same identity, and you should avoid designs where the approver is a “rubber stamp” with no ability to evaluate risk.

Who it applies to

AC-3(2) is relevant anywhere you need strong access enforcement over sensitive systems, especially:

• Federal information systems and programs aligned to NIST SP 800-53 (directly applicable in many federal contexts). ³
• Federal contractors and service organizations handling federal data where NIST SP 800-53 is flowed down contractually or used as the control baseline for ATO packages and customer due diligence. ¹

Operational contexts where auditors expect to see it

Implement dual authorization where a single privileged action could create irreversible security or compliance impact:

• Production firewall rule changes; security group changes that open inbound access
• Disabling EDR, SIEM forwarding, alerting, or log collection
• Changes to IAM that grant admin, create access keys, or bypass MFA
• Key management operations (KMS key policy changes, key deletion, HSM admin operations)
• Database exports of regulated datasets; bulk downloads from sensitive storage
• Privileged session approval for break-glass access into production
• Deleting or altering audit logs, snapshots, or backups

Your scoping choice should be documented and defensible. The control text intentionally leaves scope to the organization (“[privileged commands and/or other actions]”). ²

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

Step 1: Write a tight scope statement (the “dual auth list”)

Create a controlled list of covered actions with:

• System boundary (which environments/accounts/tenants)
• Action type (command category, API operation, console capability)
• Risk rationale (brief, not novel-length)
• Required approver role(s)
• Allowed emergency path (if any) and how it is logged

Practical approach: start with a short list of actions that create the most audit pain (log tampering, access policy changes, security control disablement, bulk data movement). Expand after the first operating cycle.

Step 2: Pick the enforcement pattern (prefer preventive gates)

Choose one or more patterns based on your tech stack:

Pattern A — PAM with approval workflow (common for human admin actions)

• Request privileged session or command execution in PAM
• Require two approvals (or one approval plus an independent security approver, depending on your model)
• PAM issues time-bound credentials or starts a brokered session only after approvals
• Record the session and tie it to the approvals

Pattern B — Change management gate (common for infrastructure-as-code)

• Changes go through pull requests
• Require two reviewers with CODEOWNERS / protected branches
• CI/CD deploys only from approved main branch
• Production credentials are not available to individual engineers

Pattern C — Cloud policy gate (common for API-level controls)

• Restrict sensitive API calls so only an automation role can perform them
• Automation runs only when a ticket is in an approved state with two approvers
• Attach the ticket ID to the change record and logs

Design test: attempt the action with one approver missing. The system should block it during normal operations.

Step 3: Define “independence” and prevent self-approval

Dual authorization fails if the same individual can approve twice using:

• Two accounts they control
• A shared team account
• An approver role that auto-approves without review

Controls to add:

• Unique identities; no shared admin IDs
• Approval policy that checks “requester != approver”
• Role design: approvers must be in a distinct group (for example, Security or SRE lead on rotation)
• Second approver cannot be a subordinate who cannot refuse

Step 4: Build the evidence bundle (make it audit-ready)

For each dual-authorized event, capture:

• Request ID and timestamp
• Requester identity and role
• Approver 1 identity, role, timestamp, decision
• Approver 2 identity, role, timestamp, decision
• Exact action approved (command category, system, scope, time window)
• Execution proof: session ID, command log, deployment ID, cloud trail event
• Outcome and any rollback reference

Retain evidence in a controlled repository with access controls and retention rules aligned to your broader audit logging program.

Step 5: Create exception rules for emergencies (and keep them narrow)

If you allow a break-glass path, document:

• When it is allowed (severity criteria)
• Who can invoke it
• What compensating controls apply (for example, post-event dual review, incident ticket, session recording)
• Who reviews and closes the exception

Avoid turning emergency access into the default.

Step 6: Operationalize ownership, cadence, and control health checks

AC-3(2) implementations fail because they live in policy but not in runbooks. Put the control on an operating cadence:

• Named control owner (Security, IAM, or Platform)
• Routine checks for bypass paths (new admin roles, new tools, new cloud services)
• Metrics that are qualitative but actionable (open exceptions, failed approvals, missing logs)
• Remediation tracking to closure

A simple way to run this like a real control:

• Create a requirement control card with objective, owner, trigger events, execution steps, and exception rules.
• Define the minimum evidence bundle for each execution cycle (inputs, approvals, output artifacts, and retention location).
• Run recurring control health checks and track remediation items to validated closure with due dates. ¹

Required evidence and artifacts to retain

Keep artifacts in a way an assessor can trace from requirement → design → operation:

Governance artifacts

• Dual authorization policy/standard (what requires dual auth, who approves, prohibition on self-approval)
• System scope list (environments/accounts and covered action categories)
• RACI for requesters/approvers/control owner
• Exception procedure for emergency access and compensating controls

Operating evidence (samples)

• Tickets/requests showing two approvals before execution
• PAM approval logs and session recordings (or references)
• Pull requests with two approvals and protected-branch settings evidence
• CI/CD logs proving only approved artifacts deployed
• Cloud audit logs (for example, API call logs) tied to the approved request ID

Configuration evidence

• Screenshots/exports of approval workflow settings (PAM, ITSM, Git settings)
• IAM policies showing only automation roles can execute sensitive actions
• Protected branch rules / CODEOWNERS configuration
• Break-glass account controls and monitoring rules

Common exam/audit questions and hangups

Expect these and prepare short, evidence-backed answers:

1. “Which actions require dual authorization, and why?”
   Provide your scoped list and rationale.

2. “Show me enforcement. Where does the system block execution?”
   Walk through the gate in tooling, then show a failed attempt without full approvals.

3. “How do you prevent the requester from approving their own request?”
   Show workflow constraints and identity controls.

4. “How do you know approvals happened before the action?”
   Show timestamps across ticket approvals and execution logs.

5. “What about automation and infrastructure-as-code?”
   Explain your PR approvals + protected branches + restricted production credentials.

6. “How do you handle emergencies?”
   Show break-glass procedure, monitoring, and post-event review evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Dual authorization exists only in policy	Auditors test reality, not intent	Implement a technical gate in PAM, ITSM, Git, or cloud policy
Approvals are generic (“approved change”)	No proof approvers understood what they approved	Require structured fields: system, action type, risk, time window
Same person can approve twice	Defeats the control	Enforce requester≠approver and unique identities; ban shared admin
Dual auth applies to “everything privileged”	Scope becomes unmanageable; bypasses appear	Start with a narrow high-risk list; expand deliberately
Emergency access becomes the normal path	Control erodes quietly	Tight criteria, monitoring, and mandatory post-event review
Evidence scattered across tools	Assessment delays and missed samples	Define an evidence bundle and a single retention location

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AC-3(2). Treat that as “no cases cited here,” not “no risk.” The risk is straightforward: without dual authorization, a single compromised admin account or malicious insider can execute high-impact actions that are difficult to detect or reverse, including disabling monitoring and altering access controls. ¹

In third-party risk and customer diligence, dual authorization is often evaluated as a marker of mature privileged access management. If you cannot demonstrate preventive enforcement plus evidence, expect follow-up questions, compensating control requests, or contractual control gaps.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and choose the gate)

• Name an owner and approver roles for dual authorization.
• Produce the initial “dual auth list” of covered actions and in-scope systems.
• Choose enforcement pattern(s): PAM approvals, PR approvals, ITSM gate, or automation-only with ticket checks.
• Draft the control card: objective, triggers, steps, exceptions, and evidence bundle. ¹

Days 31–60 (implement enforcement and produce first operating evidence)

• Configure workflows to require two independent approvals.
• Block direct execution paths (remove standing access; restrict sensitive APIs to automation roles).
• Pilot with one production system or one high-risk action category.
• Capture an evidence set from real tickets/requests and store it in your audit repository.

Days 61–90 (expand coverage and harden against bypass)

• Expand to remaining in-scope systems and actions.
• Add checks for bypass: new admin roles, new CI/CD paths, alternate consoles.
• Run a control health check and track remediation items to closure with owners and due dates. ¹
• Prepare an audit walkthrough: scope list, workflow config, and a clean sample set.

Where Daydream fits naturally: Daydream is useful once you have real operation to track: a control card, a defined evidence bundle, and recurring health checks with remediation closure. That is the difference between “configured once” and “operating control you can prove.”

Frequently Asked Questions

Does AC-3(2) require two approvals for every privileged action?

No. The requirement lets you define the scope: “privileged commands and/or other actions.” Document the actions you selected and enforce dual authorization for that list. ²

Can a manager’s email approval count as the second authorization?

It can, but it is hard to defend unless it is tied to the specific request, captured in a controlled system, and provably occurs before execution. Most teams pass audits more cleanly with workflow-based approvals that bind to execution logs.

Is two-person review in Git (two PR approvals) acceptable dual authorization?

Often yes for infrastructure-as-code changes, if protected branch rules prevent merging without two approvals and production deployments only occur from that approved branch. You still need evidence that the deployment came from the approved change.

How do we handle emergency break-glass access without violating AC-3(2)?

Define a narrow emergency procedure with compensating controls and strong logging, then require prompt post-event review and approval documentation tied to the actual actions taken. Keep proof that emergencies are rare and reviewed.

What’s the minimum evidence an auditor will ask for?

Expect to show the configured enforcement mechanism plus multiple real samples that tie request, two approvals, and execution outcome together. If any of those links are missing, the control usually gets written up as partially implemented.

How do we prevent “approval fatigue” and rubber-stamping?

Reduce scope to high-impact actions, require structured request fields, and rotate approvers. If approvers cannot quickly understand the risk and expected outcome, approvals degrade into a formality.

Footnotes

1. NIST SP 800-53 Rev. 5 PDF

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

3. NIST SP 800-53 Rev. 5