CM-5 Access restrictions for change: requirements and evidence

What CM-5 access restrictions for change requires and why it is hard

When an assessor or a contract asks how changes to the system are limited to authorized people, the answer is that CM-5 requires the organization to define, document, approve and enforce both physical and logical restrictions on who can make changes. The control is about restricting the ability to change, not only recording that changes happened. The risk it addresses is familiar: an unauthorized or unreviewed change reaches production, whether through a hand-edited server, a configuration pushed from a laptop, a pipeline run by a shared account, or a vendor engineer working in a console nobody monitors. In the NIST baselines, CM-5 is selected for low, moderate and high systems, but not for the privacy baseline in SP 800-53B, so a privacy-only scope would not bring it into the assessment.

The control is hard because the places where change happens are spread across many systems. Access to change may be granted through cloud consoles, infrastructure-as-code repositories, CI/CD pipelines, hypervisor and container platforms, data center or colocation access, network devices, and accounts held by managed service providers. Each has its own role model, its own approval path and its own logs, and privileges often accumulate over time. An organization that can show an approved change process may still fail the assessment if a standing administrator account can bypass it. Before scoping work, confirm with your team which of these paths can alter production, who holds the standing and emergency privileges on each, and which ones can be tied back to a single approval record.

Start by listing every path that can change the system and mapping it to a named owner and an approval step. Ask whether the restriction is enforced by the platform or only described in a procedure, because the SP 800-53A assessment looks for both the written rule and evidence that it operates. Ask an implementation partner or an internal architect to confirm how privileged access is granted, reviewed and removed for each path, and whether break-glass access is logged and reviewed afterward. These questions determine how much of CM-5 can be met by configuration and how much depends on people following a process.

Which systems, accounts and third parties fall under CM-5

CM-5 applies to whoever can change the system, through any path. Scope is settled by the authorization boundary, the change paths that reach it, the physical locations that host it, and the accounts that act on it. Get these right first, because each one changes which access restrictions must be defined, approved and enforced.

Authorization boundary and impact level

The impact level of the system selects its baseline, and CM-5 is selected in the low, moderate and high baselines of SP 800-53B but not in the privacy baseline. Only the high baseline adds CM-5(1), automated access enforcement with audit records. Confirm the categorization first, then list every component inside the boundary that can be changed, including hypervisors, network devices and management planes that sit outside the application itself.

Consoles and administrative interfaces

Web consoles, cloud management portals, hypervisor managers and device admin pages each allow changes without passing through a pipeline. Inventory every interface that can alter configuration, record who holds access, and confirm that each one is covered by the access restrictions you define. An interface left out of the inventory is usually the one an assessor finds.

CI/CD pipelines and deployment tools

Build servers, deployment runners and infrastructure-as-code runners can push changes to production without a person touching a console. Document who can edit pipeline definitions, who can approve a promotion to production, and which service identities the runners use. Pipeline configuration is itself a change path, so its own edit rights belong in scope.

Configuration tools and vendor remote access

Configuration management tools, patch managers and vendor support sessions can change systems from outside the normal operating team. Scope each third party by named account, approved session, and the systems it may reach. Ask vendors to confirm which of their support paths can change configuration, and record how those sessions are approved, logged and ended.

Physical locations that host changeable systems

CM-5 covers physical access restrictions as well as logical ones. Data center halls, network rooms, cabinets holding out-of-band consoles and facilities with removable media all count if someone can alter the system there. Coordinate with the physical access controls already in place, and confirm which rooms are covered by the access approvals the assessor will ask to see.

Shared administrator and service accounts

Shared administrator accounts and service accounts are the most common gap in change access. Each one needs a named owner, a documented purpose, a defined set of permitted changes, and a credential storage method that records use. Where a shared account cannot be avoided, confirm that its use is attributable to an individual through an audit record, since untraceable changes weaken every other CM control.

How an assessor tests CM-5 under SP 800-53A

This table maps the SP 800-53A assessment elements for CM-5 to what an assessor examines, interviews and tests, and the findings that typically appear. Read each row as one assessment method, then check whether your evidence covers the matching objects before the assessment starts.

Assessment element	What the assessor looks at	Common finding
Examine: configuration management plan	Whether the plan defines who may change the system, how access restrictions for change are set, and who approves them	Plan describes access restrictions only in general terms with no named roles or approval steps
Examine: system architecture and configuration documentation	Where change paths exist, such as admin consoles, pipelines, jump hosts and direct database access, and which of them are restricted	Documented architecture omits an administrative path that can alter production settings
Examine: logical and physical access approvals	Signed or recorded approvals for each person granted change-capable logical or physical access, with dates and scope	Approvals exist but do not match actual access grants, or they expire without renewal
Examine: access credentials and change control records	Whether credentials that can make changes map to approved individuals, and whether change records show who made each change	Shared or stale credentials can change the system, or change records lack the executing identity
Interview: personnel with logical access control responsibilities	How administrators grant, review and remove change-capable access, and what they do when access is requested outside normal process	Staff describe a process that differs from the written procedure or cannot name the approver
Interview: personnel with physical access control responsibilities	How facility and data center access to change-capable equipment is authorized, escorted and removed	Physical access lists are not reviewed against current staff or contractors
Test: processes for managing access restrictions to change	Attempt or observe a change by a non-approved identity and confirm the restriction blocks it, and confirm that the attempt is logged	Restrictions depend on procedure alone, with no technical block or audit record for the attempt

How to implement CM-5 in order

This sequence turns CM-5 from a policy statement into enforced, logged and reviewed restrictions on who can change each system and through which path, with each step producing evidence an assessor can examine.

Define who may change each system
Start by listing every system in scope and every path that can alter it: production consoles, administrative interfaces, configuration repositories, deployment pipelines, infrastructure-as-code, and physical access to hardware or data center racks. For each path, name the roles or groups allowed to make changes and the ones explicitly excluded. Owners of the system and the change control body should sign off on this map. The output is a written access restriction matrix that ties each change path to an approved role list, which becomes the reference for every later step.
Document restrictions in the configuration management plan
Record the access restriction matrix in the configuration management plan, the document that governs roles, processes and configuration items across the life cycle. The entry should state who approves changes to access restrictions, how exceptions are requested, and where the approved role lists are stored. Ask the people who own the plan to confirm that it matches how changes actually happen in your environment. The output is a versioned plan section that an assessor can compare directly against the systems.
Obtain and record approvals
Route the restriction matrix and the role assignments through the approval process the plan defines. Approvers typically include the system owner, the security function and, where the organization requires it, the change control body. Record each approval with the approver's name, date and the version of the matrix they reviewed. Where a restriction is relaxed for an emergency or a one-off need, require a separate documented approval. The output is a signed approval record for the matrix and for each role assignment.
Implement logical restrictions in identity and code systems
Configure the identity provider so that only the approved groups can reach each administrative interface, using role-based access and least privilege for each group. In the source control system, enable branch protection on production branches so that merges require review from approved people. In deployment pipelines, add approval gates that only named roles can release. Confirm the configuration with a test account from each group, and keep the group membership exports as evidence. The output is a working set of group definitions, protected branches and pipeline approvers that match the approved matrix.
Implement physical restrictions where relevant
Where systems or hardware can be changed on site, such as data center racks, network closets or removable media, align physical access lists with the same approved roles. Physical access authorization and visitor controls are usually owned by facilities teams, so coordinate with them and confirm which controls already exist. Record the access list, the process for adding or removing names and the escort rules for visitors. The output is a physical access list that matches the logical role matrix, or a documented statement that no on-site change path exists for the system.
Enable logging of access and changes
Turn on audit records for every change path so that each access to a restricted interface and each change is recorded with the actor, time and action. Forward these records to a central store that the change owners cannot edit. Where automated enforcement is in use, log the denied attempts as well as the allowed ones. Test the logging by making a change through each path and confirming the record appears. The output is a sample of audit records for each restricted path that shows who changed what and when.
Review restrictions periodically and after changes
Set a review schedule in the plan and compare the live group memberships, branch protections, pipeline approvers and physical access lists against the approved matrix. Look for accounts that no longer need access, groups that grew beyond their approved role, and unapproved exceptions still in place. Record findings, assign corrections and update the matrix through the approval path if the business need changed. The output is a dated review record with findings and closed corrections, which shows the restrictions are still enforced over time.

How the CM-5 enhancements change the work in the high baseline

In the high baseline, CM-5 stops being only a policy exercise. SP 800-53B Release 5.2.0 selects enhancement CM-5(1), automated access enforcement and audit records, in the high baseline only, so a moderate or low system is not required to meet it. Release 5.2.0 lists CM-5 with 7 numbered enhancements, but CM-5(2), CM-5(3) and CM-5(7) are withdrawn, leaving 4 current enhancements. Confirm the current enhancement wording in the OSCAL catalog before you scope any work, because withdrawn items still appear in older documents and internal control libraries.

In plain terms, automated enforcement means the system itself, not a person's memory of the procedure, decides whether a change is allowed. For a typical environment, that points to the tools that gate changes: privileged access groups in the directory, repository branch protections, deployment pipeline approvals, and the hypervisor or cloud IAM policies that control who can alter production. Audit records mean each attempted and completed change is logged with the identity, the approval reference and the outcome. Ask your team to show, for one recent production change, the system log entry that proves the change was permitted, not only the ticket that says it was approved.

Dual authorization and limiting production privileges are themes many teams associate with this control, but do not assume they are required enhancements. Check the current catalog text for CM-5 before you write them into a requirement, a plan or a contract. Whatever the catalog says, a tool that can record who approved a change and who executed it, and that blocks the same person from doing both where your policy requires it, will help you produce the evidence an assessor asks for under the high baseline.

Evidence that passes a CM-5 test

An assessor testing CM-5 looks for documents that define who may change the system, records that show those rules were approved and applied, and proof that someone checks them over time. The cards below cover each artifact the SP 800-53A examine and interview methods typically reach for, and how to keep each one current between assessments.

Approved access restriction definitions

This is the written definition of which physical and logical access restrictions apply to changes, including who may change production, from where, and through which tools. Assessors start here because every other artifact is tested against it. Check that it names the configuration management plan it belongs to, carries an approver and date, and was reviewed after the last significant architecture change. Confirm the definition matches what the systems actually enforce.

Role and group membership lists

Export the current membership of groups that hold change authority, such as production deployers, database administrators and firmware maintainers, and tie each group to the access restriction definition. Assessors compare these lists against the people named in interviews. Review them on a fixed schedule and record who reviewed them. Stale memberships from reassigned staff are a common finding.

Approval records for access grants

Every grant of change authority should have a ticket or signed request showing who asked, what access was requested, who approved it and when it was granted. Keep these in the same system as change tickets so the trail is continuous. Sample a few grants during preparation and confirm each one has an approver who is not the requester. Missing approvals are often the easiest gap to close before an assessment.

Access credential inventory

Maintain an inventory of accounts, service identities, deploy keys and privileged credentials that can make changes, with owner, scope and last-used date. Assessors use it to confirm that credentials match approved roles and that unused ones are removed. Reconcile the inventory against directory and platform exports at a defined frequency. Confirm that shared or break-glass credentials are logged and listed.

Change control records showing who changed what

Logs and tickets from configuration tools, deployment pipelines and file integrity monitoring show the actor, the object changed and the time. Wazuh file integrity monitoring can alert on creation, modification or deletion of monitored files and record who made the change, which helps an assessor test whether changes passed through the approved path. Check that changes made outside the pipeline raise alerts and are reconciled to a ticket.

Physical access approvals and periodic reviews

For changes made at hardware, data center or network closet level, keep the approval records for physical access, visitor logs and the periodic review of who still holds that access. Assessors test whether physical change authority matches the logical definition. Record each review with the reviewer, the population reviewed and the removals made. Confirm the review frequency is written in the access restriction definition itself.

What meeting CM-5 costs in money and effort

This table breaks down the cost components of meeting CM-5, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. No prices or durations are supplied, so use it as a checklist for scoping and for comparing written quotes. Open-source tooling removes license spend but not the staff time needed to configure, test and evidence enforcement.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Identity and access tooling	Mostly recurring if commercial; open-source platforms remove license spend, while the organization still pays for hosting and operation	Number of systems under change control, number of privileged groups, and whether enforcement is centralized or per host
Engineering time to build enforcement	One-time. Internal staff or an implementation partner configure physical and logical restrictions, approval workflows and audit logging	Number of change paths (cloud consoles, CI/CD, hypervisors, network devices), and how much existing access is undocumented
Dual authorization and workflow setup	One-time build, then recurring administration by the organization as approvers change	Whether the approval chain is defined in tooling or in email, and how many approvers each change class needs
Evidence upkeep	Recurring. Internal compliance or platform staff collect approvals, change records and access credential lists	Degree of automation in exporting logs and tickets, and how many systems produce separate evidence
Periodic access reviews	Recurring. Internal reviewers, usually system owners, confirm who holds change rights	Frequency the organization sets, number of accounts, and staff turnover that forces re-review
External testing or review	Recurring or periodic. Paid to an independent tester or reviewer if the organization chooses to commission one	Scope of testing, whether it covers only configuration or also attempts to bypass change restrictions
Auditor sampling	Recurring at each assessment. Paid to the independent auditor or assessor, who issues the findings	Sample sizes the assessor selects, number of change records retrieved, and how easily evidence can be produced on request
Staff time after go-live	Recurring. Operations and security staff handle exceptions, emergency changes and tooling updates	Frequency of emergency changes and how clearly break-glass procedures are documented and reviewed

Which open-source tools produce CM-5 evidence

Assessors testing CM-5 examine change control records and logical access approvals, so the first question is where the approved change lives. GLPI's Assistance module (licensed GPL-3.0-or-later) records changes alongside tickets and problems, following ITIL practices. A change record can hold the requester, the description, the approval decision and the outcome, which gives an examiner one traceable history per change. The GLPI Assistance documentation describes these objects in detail.

Per-change history: Each change is a record with its requester, description, status and resolution, so an examiner can follow one change from request to closure.
Planning views: Planning helps show that changes were scheduled and reviewed within the period under test.
Statistics: Reports on change volume and status support sampling, since an assessor often selects a sample of changes to trace.
Recurrent changes: Standard, repeating changes can be tracked on a schedule, which supports evidence of periodic review.
Kanban view: Shows which changes await approval, helping the change body evidence that approvals happened before implementation.

Confirm with your team whether approval steps are configured as required gates in your version, because a record of an approval does not by itself prevent an unapproved change from being made.

Where CM-5 implementations usually fall short

CM-5 is rarely missing on paper. The gaps appear when the documented restrictions differ from who can actually change the system, and when approvals and physical access are not tied to a record. The cards below cover the gaps assessors most often probe and how to close each one.

Informal change rights exceed documentation

Engineers often keep administrative rights granted for an incident or a past project, so their real change authority is wider than the restriction document says. Compare the written access restrictions for change against the actual role bindings, privileged groups and deployment permissions in each environment. Remove or time-limit any right that the documented process does not grant, and record who approved each exception.

Shared accounts with production access

A shared administrator or deployment account makes it impossible to tie a production change to one accountable person. Assessors testing CM-5 look for individual credentials on every path that changes the system. Replace shared accounts with named identities, route privileged use through a broker or session recording, and confirm that logs show the person, not the account, behind each change.

Approvals that are not recorded

Verbal or chat approvals for a change are common, and they leave no evidence that the restriction was enforced. The approval should be a record linked to the change ticket, showing the approver, the scope and the time. Check that deployments cannot proceed without a linked approval, and sample past changes to confirm each one has a matching record.

Physical access not tied to change

Data center or server room access is often granted for facilities reasons and never reviewed against who is authorized to change hardware or local consoles. Link physical access approvals to the change authority list, so that anyone who can touch the hardware is also documented as allowed to change it. Review badge logs against scheduled maintenance windows to find access with no matching change.

No review of who holds change authority

Change authority tends to accumulate as people move teams, and nobody is assigned to remove it. Without a periodic review, the list of people who can change the system goes stale. Set a defined review cycle, have the system owner sign off on the current list, and compare it with the directory and privileged group memberships before each review closes.

CM-5 questions buyers ask before hiring help

How much effort does CM-5 take to implement?

The effort depends on how many systems fall in scope, how many people can change them today, and how much of the access model already exists in writing. CM-5 asks the organization to define, document, approve and enforce physical and logical restrictions on who can change the system. Most of the work is deciding who may make which kinds of change, recording that decision, and then configuring access so the decision holds. Teams that already run identity management, privileged access and change tickets usually start further along than teams that rely on shared administrator accounts. Ask any provider for a scoped estimate built from your system inventory, your number of administrative roles and your current change records, not a generic hours figure.

How long does it take to get CM-5 evidence ready?

NIST does not publish a timeline for implementing CM-5, and no figure in this guide should be read as one. The main drivers are the number of change paths to cover (console access, configuration management tools, source repositories, deployment pipelines and physical access to hardware), whether an access approval process exists, and how many logs need to be retained and reviewed. Evidence is also time dependent: an assessor will usually want to see approvals and access records from a real period of operation, not only a configuration snapshot taken on the day of review. Ask any provider to break the schedule into the definition, enforcement and evidence collection phases, and to state which dependencies sit with your team, such as identity provider changes or change advisory board availability.

What does CM-5 need from our internal team?

CM-5 needs decisions from people who own the system and its risk, not only from engineers who configure it. The internal team typically supplies the names of the people who approve access to change the system, the rules for which changes need a second approver, and the owner of each physical access control point such as a data center cage or a rack. Engineers must confirm which tools and accounts can alter production, and an operations or security lead must agree on how access reviews and audit records are kept. Plan for these people to spend time in workshops and reviews. If nobody internally can make those decisions, that gap is the first thing to resolve before any outside help is useful.

Can we implement CM-5 in-house without a partner?

Yes, an organization can implement CM-5 with its own staff, and nothing in NIST SP 800-53 requires an outside party to do so. The control is about the organization's own decisions and enforcement, so the organization owns it. Teams that choose in-house work usually need people who understand their identity and access tooling, their deployment paths and their assessment obligations, plus enough time to build the evidence trail. Outside help is most useful when the team lacks configuration capacity, when several self-hosted platforms must be wired together, or when an assessor is expected soon and the team has no recent examples of approved changes. A partner can prepare systems and evidence, but the organization still makes and records the access decisions.

What does a partner change about CM-5 work?

A partner changes who carries the configuration and documentation workload, not who owns the control. DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and an independent assessor makes that determination. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the written scope to name the change paths covered, the access records produced, the approvals that remain with your staff, and the handover material your team will keep after the engagement ends.

Does NIST endorse a tool or publish cost estimates for CM-5?

No. NIST's risk management FAQ states that NIST does not offer or endorse any compliance program or tool, and that it does not estimate certification or compliance costs or set federal implementation timelines. The tools named on this page, such as GLPI, Zammad, Wazuh and Bareos, are open-source projects that can help produce evidence for CM-5, but their presence here is not an endorsement by NIST or a statement that they satisfy the control on their own. Confirm each tool's capabilities against its own documentation and against your assessor's expectations. For cost, build your own estimate from the scope, the internal roles involved and the quotes you receive from any provider.

What should a CM-5 quote include before we sign?

A useful quote lists the systems in scope, the change paths covered, the access restrictions to be configured, the approval workflow, the audit records to be produced and the evidence package delivered. It should separate one-time work, such as design, configuration and documentation, from recurring work, such as access reviews, retained log management and periodic re-validation. It should also state what your staff must provide, the assumptions behind the scope, and what is excluded, including any assessment fees charged by an independent assessor. Because most engagements are fixed-scope, ask the provider to confirm in writing that the deliverables and timelines match the scope you approved.

How DeployOpen prepares CM-5 evidence

DeployOpen's part in CM-5 starts with a written scope. Before any tooling is configured, the organization and DeployOpen agree which systems fall under the access restrictions, which change paths reach production (infrastructure as code, configuration management pipelines, direct administrative sessions, vendor maintenance access), and which roles hold physical and logical change rights. The organization owns the restrictions and the approvals. DeployOpen documents the scope, prepares the restriction definitions for approval, and records the decisions so the assessor can trace each restriction to a named owner.

The technical preparation uses self-hosted open-source tooling inside the client's own cloud accounts, data centers or air-gapped network. Ticketing and change workflow in GLPI can carry approvals for each change, Wazuh file integrity monitoring can be set to alert on creation, modification or deletion of monitored files and directories, and Bareos verify jobs can compare files against previously cataloged attributes. Whether each product can enforce a given restriction, rather than only record it, is a question to confirm during scoping against the client's actual change paths. DeployOpen then assembles evidence packs organized around the SP 800-53A examine, interview and test objects for CM-5, such as approvals, access credentials, change control records and the access restriction processes themselves.

DeployOpen does not issue audit reports, attestations or certifications. Independent assessors and certification bodies make those determinations, and DeployOpen supports them by explaining the evidence, answering technical questions and correcting gaps the client chooses to address. Ongoing support, monitoring and upgrades are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. To compare proposals, ask each provider which systems and change paths the quote covers, which tools it proposes to run, and which evidence items it commits to prepare.

CM-5 Access restrictions for change