CM-5(4): Dual Authorization

CM-5(4) requires you to enforce dual authorization before any covered change is implemented in your environment, meaning no single person can both approve and execute the change. Operationalize it by defining which changes are in scope, building two-person approvals into your change workflow and technical gates, and retaining evidence that approvals occurred before deployment. ¹

Key takeaways:

• Define “changes in scope” precisely, then enforce dual approval for those changes before implementation. ¹
• Make dual authorization real with workflow controls plus technical enforcement (branch protections, CI/CD approvals, privileged access controls), not policy-only.
• Auditors look for pre-implementation approval evidence, separation of duties, and exception handling that can’t be abused.

The cm-5(4): dual authorization requirement is a straightforward control with sharp operational edges: it fails when teams treat it as a policy statement rather than an enforced workflow. Your job is to make sure that covered changes cannot be implemented unless two distinct authorized individuals approve them. This is fundamentally about preventing a single actor, whether malicious or mistaken, from pushing a risky change into production without a second set of accountable eyes.

In practice, “dual authorization” intersects with change management, access control, and CI/CD design. You will need to decide what change types are in scope (for example, production code deploys, firewall rule changes, IAM policy updates, configuration changes, or emergency break-glass actions), where the approvals must occur (ticketing, code review, pipeline gate, PAM session approval), and how you will prove it later.

This page gives requirement-level implementation guidance you can execute quickly: scoping, workflow design, technical guardrails, evidence to retain, and auditor-ready talking points. It is written for a CCO, compliance officer, or GRC lead coordinating Security, IT operations, and engineering.

Regulatory text

Control requirement (excerpt): “Enforce dual authorization for implementing changes to {{ insert: param, cm-5.4_prm_1 }}.” ¹

What the operator must do:
You must ensure that changes to the defined in-scope objects (the parameterized “cm-5.4_prm_1” population in your system security plan) cannot be implemented unless two authorized persons provide approval. The intent is enforcement, not guidance: the workflow and/or technical controls must prevent implementation without the second authorization. ¹

Plain-English interpretation

Dual authorization means:

• One person cannot unilaterally implement a covered change.
• Approval must happen before implementation.
• The two authorizations must be attributable to two distinct identities with appropriate authorization.
• The organization can demonstrate this happened through logs, tickets, and system controls.

This is commonly implemented as “two-person rule” or “four-eyes principle” for high-impact changes.

Who it applies to

Entity scope

CM-5(4) is typically applied in:

• Federal information systems, and
• Contractor systems handling federal data ¹

Operational context (where it shows up)

You should expect CM-5(4) to apply wherever a single change can materially impact confidentiality, integrity, or availability, including:

• Production deployments and infrastructure-as-code merges
• Identity and access management changes (roles, policies, SSO settings)
• Network/security control changes (firewall rules, WAF policies, EDR exclusions)
• Data protection control changes (encryption settings, key management configurations)
• Privileged access pathways (PAM policies, break-glass procedures)
• Change windows and emergency change processes

Your exact scope depends on what you define as the “changes to” population in your control parameterization and system boundary documentation.

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

1) Define the in-scope “changes to” population

Create a short, explicit list of change categories and assets that require dual authorization. Keep it operational, not theoretical. Example categories:

• “All production environment changes”
• “All changes to IAM policies/roles for privileged groups”
• “All changes to firewall/security group rules”
• “All changes to CI/CD pipeline definitions used for production releases”

Decision tip: If a change can grant access, remove logging, reduce protection, or cause outage, it is a strong candidate for in-scope.

Output artifact: “CM-5(4) Dual Authorization Scope Statement” (one page) referenced in your SSP/control narrative. ²

2) Assign roles and separation-of-duties rules

Document who can:

• Request a change
• Approve a change (Approver #1 and Approver #2)
• Implement/execute the change

Minimum operational rule: the implementer cannot be the only approver. Stronger rule: the implementer cannot be either approver for high-risk changes.

Output artifact: RACI matrix for change approvals and implementers, mapped to teams (SRE, platform, security, app engineering).

3) Embed dual authorization in your change workflow (ticketing)

Configure your ITSM or ticketing system so that in-scope changes require:

• Two approvals captured as distinct approver identities
• Approval timestamps
• Evidence of what was approved (change description, risk, rollback, affected systems)
• A gate that prevents “implementation started” status until both approvals exist

Practical pattern:

• Standard change template includes fields: scope, risk, test evidence, rollback plan, approver 1, approver 2.
• “Emergency” template still requires dual authorization, but may allow post-implementation review only if your documented exception process permits it and you can prove tight constraints (see Step 7).

4) Enforce dual authorization technically (don’t rely on policy alone)

Auditors will challenge “we require two approvals” if the systems allow bypass.

Use at least one technical enforcement point for each in-scope change path:

Code and infrastructure changes

• Require pull requests with two approvals before merge.
• Protect main branches; block direct pushes.
• Restrict who can dismiss reviews.
• Require signed commits where feasible.

CI/CD deployments

• Add an approval gate requiring two approvers for production stages.
• Restrict who can rerun or manually trigger production jobs.
• Ensure pipeline changes themselves are in-scope and require dual authorization.

Privileged administrative changes

• Use PAM with dual approval for privileged sessions or high-risk commands.
• Require dual control for secrets retrieval, key access, or policy changes where your tools support it.

Configuration consoles (cloud/SaaS)

• Restrict direct console changes; route through IaC or controlled workflows.
• Where console changes are unavoidable, enforce dual authorization through privileged session approval plus ticket approval, and reconcile via logs.

5) Define what counts as “authorization” and “dual”

Write a tight rule set auditors can test:

• Authorization must be explicit (recorded approval action), not informal chat.
• Two authorizations must be independent (two distinct user accounts).
• Approvers must be authorized for that system and change type.
• Approvals must precede implementation; if emergency exception exists, define it narrowly and review quickly.

6) Train approvers and implementers on “what good looks like”

Approvals should verify:

• The change matches the request and scope
• Risk has been assessed (lightweight is fine for routine changes)
• Testing evidence exists or is planned
• Rollback/backout exists
• Maintenance window and comms are appropriate
• Segregation of duties is preserved

7) Build an exception process that cannot become the default

Dual authorization often breaks during incidents. You need an exception mechanism that stays auditable:

• Define “emergency change” criteria
• Require at least one approval pre-implementation when feasible
• Require second approval as soon as conditions permit
• Require documented incident/ticket linkage
• Require post-change review and lessons learned

If you allow break-glass, require strong compensating controls (short-lived access, tight logging, post-event review, and explicit managerial sign-off).

Required evidence and artifacts to retain

Use an evidence register so you can produce proof quickly:

Evidence	What it proves	Example source
Dual authorization scope statement	What “changes to” are in scope	SSP/control narrative attachment
Change approval records	Two distinct approvals occurred pre-implementation	ITSM ticket with two approvers + timestamps
PR review logs	Two reviewers approved before merge	Git platform audit log / PR metadata
CI/CD release gate logs	Production deploy required two approvals	Pipeline run logs showing approvals
PAM approval logs	Privileged actions required dual approval	PAM workflow/audit trail
Access control configuration	Only authorized approvers can approve	RBAC settings export/screenshot
Exception tickets + post-implementation reviews	Emergency process exists and is controlled	Incident/change record package

Retention period is program-specific; align to your org’s audit and records policy.

Common exam/audit questions and hangups

1. “Show me the last set of production changes and the two approvals for each.”
   Be ready with a sampled export: ticket ID, PR link, pipeline run link, approvers, timestamps, and implementation time.

2. “Can an engineer self-approve?”
   If yes, expect scrutiny. If no, show enforcement: branch protections, ITSM approval rules, or PAM workflow constraints.

3. “What stops someone from bypassing the workflow?”
   “Policy” is not an acceptable answer by itself. Show technical gates and restricted permissions.

4. “How do you handle emergency fixes?”
   Provide your emergency criteria, documented approvals, and post-change review evidence.

5. “Who can change the change control settings?”
   Meta-control matters. Put the change tooling configuration itself in scope for dual authorization.

Frequent implementation mistakes and how to avoid them

• Mistake: Dual authorization exists only in a policy.
  Fix: enforce in systems (PR protections, pipeline gates, PAM approvals) so bypass is hard.

• Mistake: Approvals happen after deployment.
  Fix: require pre-implementation approvals; treat post-approval as an exception with documented rationale.

• Mistake: The same identity approves twice (or shared admin accounts).
  Fix: prohibit shared accounts for approvals; require distinct user IDs and MFA for approvers.

• Mistake: Scope is vague (“all changes”).
  Fix: define the “changes to” population in operational terms, tied to asset inventory and environments.

• Mistake: Emergency path becomes the normal path.
  Fix: monitor emergency change volume, require post-change review, and escalate repeat offenders to leadership.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this specific requirement, so this page does not cite any enforcement actions.

Operationally, CM-5(4) reduces the risk of:

• Insider threat or compromised admin accounts pushing destructive changes
• Accidental outages from unreviewed production changes
• Control degradation (logging disabled, security rules loosened) without oversight

These are common themes in security incidents, and auditors treat dual authorization as a practical safeguard when systems are high impact.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and workflow)

• Publish the dual authorization scope statement for in-scope change types and systems.
• Assign control ownership and a RACI for request/approve/implement roles.
• Update ITSM templates to require two approvals for in-scope change records.
• Pick one enforcement path per change type (PR approvals for code, pipeline gates for deploys, PAM approvals for admin actions).
• Stand up an evidence register with where artifacts live and who can export them.

Days 31–60 (add technical gates and close bypass routes)

• Turn on branch protections and restrict review dismissal.
• Implement CI/CD approval gates for production stages and lock down who can modify pipelines.
• Restrict direct production console changes; route through IaC or ticketed changes.
• Define and test the emergency change path, including post-change review steps.
• Run an internal audit-style sample: pull a set of recent changes and verify dual authorization evidence.

Days 61–90 (operate, measure, and harden)

• Add monitoring: alerts for deployments without required approvals, direct pushes, or console changes.
• Review exceptions and tune scope where it is too broad or too narrow.
• Train approvers with a short checklist and require approval notes for high-risk changes.
• Prepare an assessor packet: narrative, scope, workflow screenshots, and sample evidence.

Where Daydream fits naturally: If you need to operationalize CM-5(4) across many systems and third parties, Daydream can track the control owner, map implementation procedures to each environment, and automate recurring evidence collection so you can answer audits without assembling proof by hand.

Frequently Asked Questions

Does CM-5(4) require two approvals for every change, including low-risk changes?

The requirement is to enforce dual authorization for implementing changes to the defined in-scope population. Define that population explicitly, then enforce dual authorization for those changes consistently. ¹

Can the implementer be one of the two approvers?

CM-5(4) does not spell out a specific separation-of-duties model in the excerpt provided, but auditors commonly expect independence for high-risk changes. If you allow implementer-as-approver, document the rationale and add compensating controls like additional logging and restricted privileges.

Do two code reviewers satisfy dual authorization for production deploys?

They can, if your workflow ties approvals to the actual implementation path and prevents deployment without those approvals. Many teams need both PR approvals (change authorization) and a deployment gate (implementation authorization) to cover console or pipeline bypass risks.

How do we handle emergency production fixes without slowing incident response?

Define an emergency change process with narrow entry criteria, require as much pre-approval as feasible, and mandate a prompt post-change review with documented second authorization. The key is that emergency handling is controlled and auditable, not informal.

What evidence is most persuasive to auditors?

System-enforced artifacts beat screenshots: ITSM approval logs, PR audit logs, CI/CD gate logs, and PAM approval records that show approver identities and timestamps before implementation.

What if a third party makes changes in our environment (managed service, SaaS admin)?

Treat the third party as part of your change population. Contractually require dual authorization (or an equivalent control), require change tickets with two approvals, and request periodic evidence exports or attestations aligned to your scope.

Footnotes

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

2. NIST SP 800-53 Rev. 5