3.4.5 — Lock Down Change Access

The One-Liner

If everyone on IT can push changes to production, you’ve got an access control problem on top of a change management problem.

What It Says

Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

What It Actually Means

Only authorized people can make changes — and the restriction is defined, documented, approved, and technically enforced. This requirement covers both physical and logical access to the systems being changed.

Eight things are assessed — four for physical access and four for logical access. For each type:

1. Defined. Who is authorized to make changes? A named list of people or specific roles.
2. Documented. The authorization is written down — not tribal knowledge.
3. Approved. An appropriate authority (system owner, security lead) signed off on the access.
4. Enforced. Technical controls actually prevent unauthorized people from making changes. Policy alone doesn’t count.

Physical access means restricting who can physically touch CUI systems — server rooms, network closets, data centers. If a change requires racking a server or swapping a drive, only authorized personnel should have physical access.

Logical access means restricting who can remotely modify CUI systems — admin consoles, deployment tools, configuration interfaces. Not every IT person should have write access to production. Use least privilege: separate admin accounts, Privileged Identity Management (PIM), and just-in-time access elevation.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are physical access restrictions for changes defined?	Named list of who can physically access CUI infrastructure
2	Are physical access restrictions documented?	Written documentation — not verbal
3	Are physical access restrictions approved?	Signed off by system owner or security lead
4	Are physical access restrictions enforced?	Badge access, locked server room, escorted visitor policy — technically enforced
5	Are logical access restrictions for changes defined?	Named list of who has admin/write access to CUI systems
6	Are logical access restrictions documented?	Written documentation of who has what level of access
7	Are logical access restrictions approved?	Approved by system owner or security lead
8	Are logical access restrictions enforced?	RBAC, PIM, separate admin accounts — technically enforced

---

What to Have Ready on Assessment Day

Documents they’ll review: Configuration management policy; procedures addressing access restrictions for system changes; system security plan; list of personnel authorized for physical changes; list of personnel authorized for logical changes; access approvals; change control records showing who implemented each change

People they’ll talk to: Personnel with logical access control responsibilities; personnel with physical access control responsibilities; information security personnel; system or network administrators

Live demos they’ll ask for: “Who can access the server room? Show me the badge access list.” “Log in as a general IT user and try to modify a CUI server config — show me it’s blocked.” “Show me the PIM elevation process for admin access.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Who is authorized to make physical changes to CUI systems? Show me the list.”
• “Who is authorized to make logical changes? Is this list different from general IT staff?”
• “Are these authorizations approved and documented? By whom?”
• “Log in as a standard IT user — can you modify production? Show me the block.”
• “Does your change documentation include the name of the person who made the change?”
• “How do you handle external technicians who need physical access? Show me the process.”

Real-World Example

A defense contractor’s server room requires badge access — only three IT staff and the facilities manager have active badges, documented in the physical access register and approved by the IT Director. For logical changes, four sysadmins have admin accounts but they’re not standing privileges — admins use Azure PIM to request just-in-time elevation for a maximum of four hours, with a business justification logged. General IT staff have read-only access to CUI systems. When an external technician needs to install hardware, security issues a temporary escort badge; the technician is accompanied at all times and the visit is logged. Change tickets include the name of the implementing admin and the PIM activation record. The assessor reviews the badge access list, the PIM configuration, and a recent change ticket showing the implementing admin’s name and PIM activation timestamp.

---

Where Companies Trip Up

Too many people with change access. Every IT person has admin rights to every system. The assessor asks “how many people can modify this server?” and the answer is twelve. Restrict production change access to the minimum — use PIM for just-in-time elevation.

No documentation. People have access but there’s no record of who or why. The assessor asks “show me the approved list of people authorized to make changes” and it doesn’t exist. Maintain a documented, approved list.

Policy without enforcement. Policy says only senior admins make production changes, but the technical controls don’t enforce it. A junior admin can log in and modify anything. RBAC and PIM must enforce the restriction, not just policy.

Physical access uncontrolled. Server room door propped open, no badge access, visitors unescorted. Physical access to CUI infrastructure must be as controlled as logical access.

---

How to Talk About This

To a CEO or Board

Only designated staff can make changes to our CUI systems — both physically and through admin access. Change access is documented, approved by management, and technically enforced. We use just-in-time privilege elevation so nobody has standing admin rights.

To an Engineering Team

Physical: badge access to server room, documented access list, escorted visitors. Logical: Azure PIM for just-in-time admin elevation (4-hour max), separate admin accounts, RBAC enforced. General IT: read-only on CUI systems. Change tickets document who implemented. Access list reviewed quarterly.

---

Connected Requirements

Requirement	Why it matters here
3.4.3 — Control Every Change	The change management process that these access restrictions support
3.1.5 — Separate Duties	Separation of duties applied to change implementation
3.1.7 — No Shared Accounts for Admin	Admin accounts used for changes must be unique per person
3.10.1 — Control Physical Access	Physical access restrictions to CUI infrastructure

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: CM.L2-3.4.5 | SPRS Weight: 5 points | POA&M Eligible: No