Access Restrictions for Change

To meet the Access Restrictions for Change requirement, you must define, document, approve, and enforce who can make system changes, under what conditions, and with what physical and logical access constraints, then prove it with repeatable evidence. In practice, this means tightly controlling change-capable accounts, paths to production, and facility access tied to change execution (NIST Special Publication 800-53 Revision 5).

Key takeaways:

• Restrict change access by role, system boundary, environment, and change type, not by broad admin group membership.
• Require pre-change approval and technical enforcement (IAM, PAM, branch protections, CI/CD gates, network segmentation).
• Evidence must connect: request → approval → access granted → change executed → review/closure, for both logical and physical access.

“Access Restrictions for Change” is a change control requirement with teeth: it expects you to actively prevent unauthorized or unapproved changes by controlling the access paths that make changes possible. Under NIST SP 800-53 Rev. 5 CM-5, you must “define, document, approve, and enforce physical and logical access restrictions associated with changes to the system” (NIST Special Publication 800-53 Revision 5).

For a Compliance Officer, CCO, or GRC lead, operationalizing CM-5 is less about writing a change policy and more about proving that only the right people can perform change actions, only through approved mechanisms, and only after the right approvals. Auditors will look for mismatches between what your policy says and what your tooling allows. If engineers can push to production directly, if “temporary” admin access isn’t time-bound, or if data center access isn’t tied to authorized work, CM-5 will fail on “enforced,” even if “documented” looks strong.

This page gives you requirement-level steps, concrete control patterns, and the evidence pack to retain so you can implement quickly and defend it cleanly.

Regulatory text

Requirement (CM-5): “Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation: You need a controlled system for changes where:

• Define: you specify which roles can make which changes, to which components, in which environments, using which methods.
• Document: those restrictions exist in a policy/standard and are mapped to technical enforcement points (IAM/PAM, Git, CI/CD, consoles, network paths, facilities).
• Approve: changes (and sometimes the access required to implement them) go through a formal approval workflow aligned to risk.
• Enforce: the system blocks noncompliant change attempts; restrictions are not “honor system.”

A control that is only procedural (tickets and good intentions) typically fails the “enforce” part when production access is broad.

Plain-English requirement: what CM-5 is really asking

CM-5 expects you to treat “ability to change the system” as a privileged capability and lock it down. The “system” includes your FedRAMP boundary components: infrastructure, platform services, applications, configuration, and the pipelines and consoles that can modify them. “Physical access restrictions” apply where someone can change the system by touching hardware or connecting locally (data centers, cages, network closets, secure rooms, KVM, removable media handling). “Logical access restrictions” cover identity, authentication, authorization, and network pathways to admin interfaces and deployment mechanisms.

A simple rule helps: if a person can change production behavior, configuration, or security posture, CM-5 applies to the access route they use.

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating systems aligned to FedRAMP Moderate expectations (NIST Special Publication 800-53 Revision 5).

Operational context that triggers CM-5 work:

• You run production services (IaaS/PaaS/SaaS) where engineers administer infrastructure, code, configuration, or identity settings.
• You outsource operations to a third party (managed service provider, data center operator, DevOps contractor) who can implement changes.
• You use CI/CD or infrastructure-as-code where merges, pipeline runs, or parameter changes alter production.
• You have colocation or on-prem components inside the boundary where physical access enables change.

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

1) Define the “change surfaces” inside the system boundary

Create a list of change-capable surfaces and owners. Examples:

• Cloud control planes (AWS/GCP/Azure consoles, APIs)
• Kubernetes clusters and cluster-admin paths
• CI/CD (GitHub/GitLab/Azure DevOps), runners, deployment tools
• IaC repos (Terraform/CloudFormation), state backends
• Secrets management and key management systems
• Network devices, firewalls, WAF/CDN configuration
• Identity systems (IdP, IAM roles, directory groups)
• Physical facilities and any local management ports

Output: a scoped inventory that tells an auditor you know where changes can happen.

2) Define access restriction rules by change type and environment

Write a short Change Access Standard that answers, for each change surface:

• Who can request changes?
• Who can approve changes (and when do you need a second approver)?
• Who can implement changes?
• What environments are covered (dev/test/stage/prod)?
• What tooling pathways are allowed (CI/CD only, break-glass only, console prohibited, etc.)?

Keep this practical. A common strong pattern:

• Prod changes: only via CI/CD using protected branches and controlled runners; no direct console edits except break-glass.
• High-risk changes (IAM, network perimeter, logging, key management): stronger approval requirements and narrower implementer set.

3) Map rules to technical enforcement points (this is where most programs fail)

For each rule, identify the control that enforces it:

• IAM / RBAC: least privilege roles; separate read vs change permissions; separate prod vs non-prod roles.
• PAM: just-in-time privileged access; time-bound elevation; session recording where feasible; break-glass with compensating review.
• Git protections: protected branches; required reviews; signed commits if your environment supports it; restrict who can bypass.
• CI/CD gates: approval steps for prod deploy; restrict who can trigger prod pipelines; restrict runner credentials.
• Network restrictions: admin interfaces behind VPN/Zero Trust access; source IP allowlists for sensitive control planes where appropriate.
• Physical controls: badge access limited to authorized staff; visitor escort; access logs retained and reviewed for change windows.

If you can’t point to a system setting that blocks unauthorized change, you don’t yet “enforce.”

4) Put approval into the workflow, not the wiki

Implement a change workflow that produces traceable approvals:

• Standard change request fields (system component, risk level, rollback plan, testing evidence, planned window).
• Approval routing based on risk (service owner, security, operations).
• Separation of duties where feasible: approver is not the implementer for sensitive changes.

Important nuance: CM-5 says approve “access restrictions associated with changes.” In practice, you should be able to show that the change was approved and that any privileged access used to execute it was authorized and constrained.

5) Control third-party change access explicitly

If a third party can implement changes:

• Give them named accounts (no shared logins).
• Put them behind PAM and restrict to defined systems and time windows.
• Contractually require adherence to your change process and evidence delivery (tickets, approvals, logs).

Treat third-party remote hands or data center operators as part of “physical access restrictions” if they can touch boundary equipment.

6) Monitor and review for drift

Build a lightweight but consistent oversight loop:

• Review a sample of changes for correct approvals and correct access used.
• Review privileged group membership and production-capable permissions for appropriateness.
• Detect and respond to “out-of-band” changes (console edits, emergency access) with a defined retrospective review.

7) Make it auditable: connect the story end-to-end

For each production change, you should be able to reconstruct:

1. A request exists
2. Approval happened
3. The implementer had the right access at the right time
4. The system shows the change occurred through an approved path
5. Post-change validation and closure occurred

Tools can help connect these. In Daydream, teams commonly centralize control narratives and evidence pointers so the auditor sees one coherent chain instead of scattered screenshots and ad hoc exports.

Required evidence and artifacts to retain

Retain artifacts that prove definition, documentation, approval, enforcement:

Governance

• Change management policy and Change Access Standard tied to system boundary (NIST Special Publication 800-53 Revision 5)
• RACI for request/approve/implement roles
• Exception process for emergency/break-glass and after-action review template

Access control configuration (logical)

• IAM role definitions and permission sets for change-capable roles
• Production access group membership reports (current and historical where possible)
• PAM configuration: JIT policies, elevation workflows, session logs if available
• Git branch protection settings, repo permissions, required review rules
• CI/CD pipeline definitions showing approval gates and restricted triggers

Change records

• Change tickets with approvals, risk classification, testing and rollback notes
• Deployment logs linking build/deploy events to approved changes
• Evidence of peer review (PRs, review logs) for production-impacting code/IaC

Physical access evidence (where applicable)

• Facility access policy and authorized personnel list
• Badge/access logs for sensitive areas during change windows
• Visitor logs and escort records for anyone accessing boundary equipment

Common exam/audit questions and hangups

• “Show me how you prevent an engineer from changing production outside the approved process.”
• “Who can change IAM policies, security groups, logging configuration, or KMS keys? Prove it.”
• “Are approvals captured in a system of record, or are they informal?”
• “How do you handle emergency changes? Show the retrospective review and access logs.”
• “Do third parties have production change access? How is it restricted and monitored?”
• “Where are physical access restrictions relevant in your boundary, and what logs do you retain?”

Hangup to anticipate: teams show a change policy and tickets, but cannot show enforcement controls that block direct production change.

Frequent implementation mistakes and how to avoid them

1. Overbroad admin roles “for convenience.”
   Fix: split read/admin; separate prod from non-prod; require time-bound elevation for prod.

2. Approvals exist, but implementers can bypass via console/API.
   Fix: restrict console permissions; require CI/CD for prod; treat console as break-glass only and log it.

3. Shared accounts for operations or third parties.
   Fix: named accounts and PAM; terminate access promptly; review routinely.

4. No linkage between ticket and change event.
   Fix: require ticket IDs in PR titles, commit messages, or deployment annotations; keep deployment logs.

5. Physical access ignored because “we’re in the cloud.”
   Fix: if any boundary component is physically hosted/managed, document the facility controls and keep access logs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Operationally, CM-5 failures increase the likelihood of unauthorized changes, misconfigurations, and security control bypass. They also degrade your ability to prove control effectiveness during an assessment because auditors test both the written control and the actual system constraints (NIST Special Publication 800-53 Revision 5).

Practical execution plan (30/60/90-day)

Use phases so you can move fast without pretending every environment changes overnight.

First 30 days (stabilize and scope)

• Identify production change surfaces and owners; document current access paths.
• Freeze and review membership of production-capable groups/roles; remove obvious excess.
• Publish a Change Access Standard that states: allowed change paths to production, required approvals, break-glass rules (NIST Special Publication 800-53 Revision 5).
• Pick evidence sources you will rely on (ticketing system, Git provider, CI/CD, IAM, PAM).

Days 31–60 (enforce technically)

• Implement/strengthen Git branch protections and mandatory reviews for production repos.
• Add CI/CD approval gates for production deploy stages; restrict who can trigger and who can approve.
• Move production admin access behind PAM or time-bound elevation.
• Lock down direct console edits for common change types; document break-glass exceptions.

Days 61–90 (prove it and harden)

• Run an internal audit of a sample of production changes, tracing request → approval → access → execution → closure.
• Add detective controls for out-of-band changes and define the required retrospective review package.
• Formalize third-party change access restrictions and evidence expectations.
• Centralize evidence pointers and narratives so audits are repeatable; many teams use Daydream to keep the control story and evidence map current as systems evolve.

Frequently Asked Questions

Does CM-5 require separation of duties for all changes?

CM-5 requires you to define, approve, and enforce access restrictions tied to changes (NIST Special Publication 800-53 Revision 5). Separation of duties is a strong way to enforce restrictions for high-risk changes, but you should scope it based on change risk and what your tooling can enforce.

Are emergency (break-glass) changes allowed under this requirement?

Yes, if you define and document the emergency path, restrict who can use it, and keep auditable records of the access and the change. Pair break-glass with a required after-action review and tighter logging to show enforcement (NIST Special Publication 800-53 Revision 5).

What counts as “physical access restrictions” for a cloud service?

If your system boundary includes facilities, cages, network rooms, removable media handling, or third-party remote hands that can affect boundary components, physical access restrictions apply. If you have no physical components in scope, document why and focus on logical change pathways.

We already have a change ticket process. Why do auditors still flag CM-5?

Ticketing proves “approve,” but CM-5 also requires “enforce” (NIST Special Publication 800-53 Revision 5). If engineers can still change production via direct console/API access without technical barriers, the control is procedural rather than enforced.

How do we handle third parties who need to implement changes?

Provide named access, restrict it to specific systems and time windows, and route it through the same approval and logging expectations as employees. Keep evidence that ties their access and actions to approved work (NIST Special Publication 800-53 Revision 5).

What’s the minimum evidence set to keep for each production change?

Keep (1) the approved request, (2) proof of who implemented it, (3) logs showing what changed and when, and (4) proof the change occurred through the approved pathway (PR/merge and/or pipeline logs). Add break-glass evidence where relevant (NIST Special Publication 800-53 Revision 5).