Access Restrictions for Change CM-5

Configuration Management · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds CM-5 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, Configuration Management family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

CM-5 (Access Restrictions for Change) makes sure only the right people can actually make changes. You define, document, approve, and enforce both physical and logical limits on who can alter the system — edit its config files, install software, or change its services. It is a Low-baseline control and the enforcement muscle behind change control: even a well-run approval process fails if anyone can bypass it and edit files directly.

What good looks like

Limit who can change the system to named administrators — ordinary accounts should not be able to edit config or install software.
Use least privilege: grant change rights through sudo (the ‘superuser do’ command that runs a task as an administrator) rather than sharing the root password.
Enforce it, do not just document it — file permissions, group ownership, and sudo rules should actually block someone who was not approved.
Log privileged changes so an access restriction can be checked, not just assumed.
Cover physical access too — console and boot access can bypass logical restrictions, so limit who can touch the machine or its virtual console.

Framework mapping

NIST CSF 2.0 — PR.PS-01 — Configuration management practices are established and applied

How to move it toward Implemented

Restrict administrative rights to a single group and grant them through sudo: put change-makers in the sudo (or wheel) group and remove everyone else.
Lock down config ownership and permissions so non-admins cannot edit them (for example, sudo chown root:root /etc/ssh/sshd_config && sudo chmod 600 /etc/ssh/sshd_config).
Confirm privileged actions are logged so each change is attributable to a person (check /var/log/auth.log on Debian/Ubuntu or /var/log/secure on Red Hat-based systems).
Review the sudoers list and group membership (sudo visudo and getent group sudo) and remove anyone who no longer needs change rights.
Attach the sudoers/group review and the config-permission settings as hardening evidence on the asset, naming CM-5 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.