CM.L2-3.4.5 Access restrictions for change: evidence

CM.L2-3.4.5 access restrictions for change: what the requirement asks for

CM.L2-3.4.5 requires you to control who can change your systems through both the physical path and the logical path, and you must evidence four actions for each path: define the restrictions, document them, approve them, and enforce them. If a Level 2 assessment is on your calendar, the assessor will look for a clear answer to one question: who is allowed to change a system, by what route, and how do you know nobody else did. A server room that requires a key card is only part of the answer. So are the administrator credentials, the patch interface, and the change windows that govern what happens inside the environment. The requirement is worth 5 points under the CMMC Scoring Methodology, so if it is NOT MET, the points come off your score of 110 and the gap cannot be carried on a POA&M. Under 32 CFR 170.21(a)(2), you must reach MET before you can hold Conditional or Final Level 2 status.

The risk behind this requirement is unrestricted change. If anyone with a login can alter a firewall rule, a logging setting or a CUI repository, then no baseline, hardening standard or change record means much, because nothing stops the drift. Assessors test this by pulling the actual mechanisms: the access control lists for the server room, the list of accounts that can modify production settings, the approval records tied to each change, and the audit records showing who changed what and when. In practice, three patterns make this requirement hard to pass. The first is informal administrator access, where engineers keep local admin rights because it is faster. The second is shared credentials, such as a single account used by a team, which makes it impossible to tie a change to a person. The third is changes made outside the ticket process, which leaves no approval record even when the change was reasonable.

Start by inventorying every route to a change, physical and logical, and confirming with the people who run each system which ones exist in practice, not only on paper. Ask for each change path: who holds the credential, who approved that access, when it was last reviewed, and whether the change is logged. Confirm that your change windows and approval workflow are written into your system security plan and that the evidence is in final form, since draft procedures do not count toward MET under the assessment rules. The exact mechanism you choose (badge system, privileged access tooling, patch interface) is your decision, and you should confirm the capabilities of any tool with its vendor before you rely on it in the SSP.

Which systems, places and people fall under access restrictions for change

Scoping decides how much work CM.L2-3.4.5 creates. The cards below cover the assets, locations, accounts and third parties that can change CUI systems, and the boundary decisions that determine which of them must be restricted, approved and evidenced.

CUI systems and security protection assets

Start with the systems that process, store or transmit CUI, plus the security protection assets around them, such as firewalls, identity services, logging servers and endpoint tools. Each of these can change the security posture of the CUI environment, so each needs a defined list of who may change it and how. Confirm the list against the system security plan so the change restrictions match the documented boundary.

Server rooms and wiring closets

Physical access restrictions apply wherever hardware that hosts CUI or security functions sits, including server rooms, network closets and cabinets in shared offices. Record which rooms hold in-scope equipment, who holds keys or badges for each, and how entry is approved and logged. Wiring closets are often overlooked, yet a network change made there can alter the boundary as much as a server rebuild.

Administrator and vendor accounts

Any account that can alter configuration, including domain administrators, cloud tenant owners, hypervisor and firewall administrators, and service accounts, falls under the logical restrictions. Inventory these accounts, separate change credentials from everyday logins where practical, and confirm which accounts can change settings without a recorded approval. Shared administrator accounts make it hard to show who changed what, so flag them early.

Managed service provider and third-party access

Vendors, managed service providers and remote support engineers who change systems count as people with change access, even when they sit outside the organization. Document how their access is requested, approved, time-limited and recorded, and whether they reach the environment through a constrained path. Contracts and flowdown terms should state these obligations, and the organization remains responsible for enforcing them.

OT, test equipment and cloud tenants

Operational technology, test equipment and cloud tenants each need their own boundary decision. OT and test gear may sit outside normal IT controls, and cloud tenants may be shared, administered by a provider, or spread across subscriptions. For each, decide whether it is inside the assessed boundary, record the reason, and document how change access is restricted if it is included.

Level 2 contract status

Before fixing the scope, confirm with the contracting officer which CMMC Level 2 requirements currently apply to each contract, since the program's implementation schedule has changed. Ask whether a self-assessment or a third-party certification is required, and for which contracts. The answer determines how much evidence must be ready and how formal the restriction records need to be.

How an assessor tests access restrictions for change

This table compares the eight NIST SP 800-171A assessment objectives for CM.L2-3.4.5, the test approach an assessor applies to each, and the evidence requested. Read each row as a question the assessor must answer with final evidence, since the requirement is MET only when all applicable objectives are satisfied with evidence in final form, not drafts.

Assessment objective	Assessor test approach	Evidence requested	Common findings
Physical access restrictions on system changes are defined	Review the written definition of who may physically reach systems that change configuration, and where the boundary sits	Physical access policy or procedure naming the restricted areas and roles	Definition covers the data center but not network closets or field equipment
Physical access restrictions on system changes are documented	Confirm the definition appears in the system security plan or controlled procedure and is current	Documented procedure, SSP section, revision history	Procedure exists but was never approved or was last revised years earlier
Physical access restrictions on system changes are approved	Trace the approval of the restriction to an accountable owner and check the approval date	Signed approval, meeting minutes or workflow record	Approval dated after the restriction was already in use
Physical access restrictions on system changes are enforced	Test the key card, badge or lock controls against the list of authorized change personnel	Access credential lists, badge or door logs, sample walkthrough records	Shared badges or card holders who no longer need access still active
Logical access restrictions on system changes are defined	Review the definition of which accounts, roles and tools may modify configurations	Access control policy section, role definitions for change	Admin rights defined broadly as all IT staff with no change-specific boundary
Logical access restrictions on system changes are documented	Check that the logical restrictions are written down and tied to the systems in scope	Documented procedure, configuration of the change tool, system list	Restrictions described for one platform while others are changed through direct access
Logical access restrictions on system changes are approved	Verify that a named owner approved the logical restrictions and the change credentials model	Approval record, change authority matrix, credential ownership list	Approval covers the policy only, with no record for the actual credential holders
Logical access restrictions on system changes are enforced	Test whether a non-authorized account is blocked from changing settings, and whether changes pass through the approved interface or workflow	Change credential lists, audit records of change sessions, test results of blocked attempts, change window schedule	Changes made with shared administrator accounts outside the change window, or enforcement that exists only on paper

How to implement change access restrictions in six steps

This sequence takes an organization from undefined change rights to enforced, tested and periodically reviewed restrictions on who may change CUI systems, both physically and logically. Each step closes with an artifact an assessor can inspect against the 8 assessment objectives for CM.L2-3.4.5.

Define who may change which system classes
Start by listing the system classes in the CMMC boundary, such as domain controllers, firewalls, CUI enclave servers, workstations and network devices, and the physical locations that house them. For each class, name the roles allowed to make changes, separating physical access (server room entry, rack access) from logical access (administrative accounts, change credentials). The system owner and the security lead approve the list. Done means every class has named roles for both access types, and the approved list is traceable to the system security plan.
Document the restriction procedure
Write the procedure that governs how access to change systems is requested, granted, used and revoked. It should describe the key card or badge process for physical areas, the credential issuance path for logical changes, and the rule that changes go through approved interfaces only. Assessors look for this document first, because they test the procedure before they test the mechanisms. Done means the procedure is version controlled, assigned an owner, and signed off by the organization's responsible official.
Set approval routes and change windows
Define who approves each type of change access, how the approval is recorded, and which time windows allow changes to production CUI systems. Approval routes should match the change control process, so that a request for access and a request for a change can be traced to the same record. Document the windows, the emergency exception path and who authorizes exceptions. Done means a sample access request can be followed from approval to the granted credential, with timestamps and an approver name on each record.
Configure enforcement controls
Implement the controls that make the documented rules true. Examples include key card access limited to the server room for approved staff, dedicated change credentials separate from daily user accounts, a constrained patch management interface that is the only route for applying updates, and technical controls that prevent changes outside the approved windows. The CMMC Assessment Guide cites these forms of enforcement as examples, not a complete list. Done means each control has a configuration record, an owner and a screenshot or export showing its setting.
Test that enforcement blocks unapproved changes
Run tests that try to make changes without approval, using an account without change rights, from outside the approved window, and through a path other than the constrained interface. Record what the system did: denied, logged, alerted. Also confirm that approved changes succeed and leave audit records. Assessors test the mechanisms themselves, so this step produces the evidence they will ask to reproduce. Done means the test plan, the test results and the resulting audit log entries are retained in final form, not as drafts.
Set a recurring review of access and logs
Schedule a recurring review of change credentials, key card holder lists, approval records and audit logs to find stale access, unapproved changes and drift from the procedure. Record each review with its date, reviewer, findings and corrective action, and feed open findings into the plan of action where permitted. Confirm the review cadence with your assessor or consultant, since the schedule should match the organization's own risk decisions. Done means a dated review record exists for each cycle, showing that access was checked against the approved list.

Which evidence passes for access restrictions for change

Assessors test CM.L2-3.4.5 by tracing a defined rule to the people, credentials and windows that enforce it, then to records showing the rule worked. The six artifacts below cover the policy, the physical and logical access lists, the approvals, the enforcement logs and the tests, and each must be kept current and in final form before an assessment.

Written access restriction procedure

The procedure defines who may change organizational systems, through which physical spaces and logical paths, and who approves each class of change. It should name an owner, carry an approval date and version, and state the change windows and exceptions. Check that the procedure matches what the system actually does, since an assessor will compare the two. Review it on a fixed schedule and after any change to the change control board or the system boundary.

Physical access holder list

This list names every person with key card or key access to server rooms, network closets and other spaces that house the system, with the reason for access and the approver. Pair it with access logs that show entries, and reconcile the two each period to catch former staff or unused cards. Badge deactivation records for departures are part of the same evidence. Ask your facilities team to confirm that the list is generated from the access control system, not kept by hand.

Logical change credential register

This register lists each account or credential that can alter system settings, patch systems or modify configurations, along with its owner, scope and the systems it reaches. Privileged accounts should be separate from everyday accounts, and shared credentials should be avoided or documented with a named custodian. Review the register against directory group membership to find drift. Confirm that the list covers service accounts and vendor access as well as staff accounts.

Approved change records

Each change record should show the request, the approver, the approval time, the implementer and the approved window in which the change ran. Records that show a change made outside its approved window, or without approval, are findings that need explanation and a corrective action. The change records are the same evidence used for CM.L2-3.4.3, so keep the fields consistent across both requirements. Store them in a system that preserves timestamps and cannot be edited after approval.

Audit logs of enforced denials

Logs from the directory, the configuration management tool, the hypervisor or the firewall should show that unauthorized change attempts were denied and that authorized changes were allowed through the designated path. Examples include denied logins to configuration interfaces and patch jobs that ran only through the approved patch interface. Confirm that logs are retained and protected under the audit requirements, because assessors will ask for them alongside the change records. Sample a few denials and approvals and trace each one back to its approval.

Test records for access mechanisms

Test records prove that the physical and logical controls work as written. Typical tests attempt a change with an unapproved credential, try entry to a server room without a valid card, and confirm that a change outside the window is blocked or flagged. Record the test steps, the expected result, the actual result, the tester and the date, and retest after significant changes. Assessors look for tests of the enforcing mechanism, not only a statement that the mechanism exists.

What meeting access restrictions for change costs

This table breaks down the cost components of enforcing CM.L2-3.4.5 access restrictions for change, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to scope a quote and to separate costs your organization carries from fees paid to an independent assessor. No figures are given because none are supplied for this topic.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it, and what to ask for in a quote
Tooling and licenses	Software vendor, or no license fee for self-hosted open-source ticketing	Recurring if licensed, one-time setup otherwise	Number of users and approvers. Ask whether the quote includes a self-hosted option and which change functions are included, such as GLPI Assistance change records.
Engineering time for logical enforcement	Internal staff or implementation partner, fixed-scope	One-time, with periodic review	Number of systems and change paths. Ask what gets configured: change credentials, constrained patch interfaces, and enforcement tests.
Facilities work for key cards and locks	Building contractor, locksmith or access control vendor	One-time installation, recurring key and badge management	Number of physical spaces holding CUI systems. Ask who issues, revokes and logs badges and whether badge logs feed change records.
Fixed change windows and schedule controls	Internal change managers or implementation partner	One-time design, recurring enforcement	Number of maintenance windows and emergency change paths. Ask how exceptions are approved and recorded.
Procedure writing and approval workflow design	Internal compliance staff or implementation partner	One-time, with updates after major changes	Number of change types and approvers. Ask for the written procedure, the approval matrix and the review cycle.
Evidence upkeep and log review	Internal security or operations staff	Recurring	Volume of changes and audit log sources. Ask how change records, approvals and access logs are kept in final form for assessors.
Vendor and remote change access	Internal staff, managed service providers and outside vendors	Recurring	Number of vendors with change rights. Ask how their credentials are scoped, approved and reviewed.
External testing or review by a partner	Independent testing firm or implementation partner, fixed-scope	One-time pre-assessment, optional recurring	Scope of systems tested. Ask what is tested, what deliverables are produced and whether retesting is included.
Assessor fees	Paid to the independent assessor, not to DeployOpen	Per assessment	Scope and assessment method. Confirm the fee and assessor independence with the assessor before work begins.

Which open-source tools can support change control evidence

Ticketing platforms can produce the change records and approval trails that show who asked for a change and who approved it. They cannot, on their own, stop anyone from changing a system, so each tool below needs to be paired with physical and logical controls that enforce the restrictions.

GLPI change records

GLPI's Assistance module creates, follows and processes tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. Configure change records to capture the requester, the approver, the systems affected and the scheduled window, because those fields are what an assessor compares against actual activity. Check whether the approval step is enforced by the workflow or only recorded by convention, since assessors test the mechanism, not the intent.

Approval trails in ticketing

An approval trail links a change request to the person who authorized it before work started. Confirm that the tool keeps the approval timestamp and approver identity in a record that cannot be silently edited after the fact. Export or retain these records outside the ticketing database so they remain available when the tool is upgraded or replaced.

Zammad as a request intake

Zammad is a web-based helpdesk that brings requests from email, chat, telephone and social media into one ticket system. It is built for customer communication, so its ticket model may not map cleanly to a change control board with defined approval steps. Test whether approval routing, change windows and pre-change sign-off can be modeled before relying on it as the system of record.

Licensing obligations to confirm

GLPI is licensed under GPL-3.0-or-later and Zammad under AGPL-3.0-only. Each license carries conditions on distribution and, for AGPL, on network use of modified code. Ask counsel to review how these terms apply to your deployment, including any custom modifications, before the tool becomes part of a contract-supporting environment.

What ticketing cannot enforce

Neither tool locks a server room, issues key cards or limits which credentials can change settings. A change ticket can record that access was approved, but the restriction itself lives in badge systems, privileged access management, directory groups and change windows enforced on the systems. Map each approved change to the mechanism that actually blocks unapproved changes, and keep that mapping in the system security plan.

Who owns, implements and tests access restrictions for change

The organization owns CM.L2-3.4.5. Leadership must decide who may change systems, both physically and logically, and the people accountable for those decisions must approve the procedure in writing. The control is not delegated to a consultant or a tool. Whatever the organization signs is what the assessor will test against, so the organization must be able to explain each restriction and show that it operates day to day.

Approving changes: Name the roles that may approve a change to a system with CUI and the conditions under which approval is required.
Managing key card holders: Own the list of people with server room or network closet access, and remove them promptly when their role changes.
Managing change credentials: Decide which accounts can modify configuration, who holds privileged change credentials, and how those credentials are issued and revoked.
Defining change windows: Set the approved periods for changes and the process for emergency changes outside them.
Signing the procedure: Approve the access restriction procedure and keep it current with the system security plan.

Confirm with your assessor which records they expect to see for each of these items before you finalize the procedure.

Where organizations fall short on change access restrictions

Most failures against CM.L2-3.4.5 are not missing policies. They are restrictions that exist on paper, approvals that arrive too late to count, and enforcement that nobody has tested. The gaps below are the ones that tend to surface when an assessor asks for evidence of who could change a system and who actually did.

Shared credentials used for changes

Administrators and vendors often make changes through a shared root, domain or vendor account, so the system cannot show which person made which change. The requirement expects specific credentials for making changes, which means changes are tied to named, authorized individuals. Closing step: issue named privileged accounts to each authorized changer, restrict the shared account to break-glass use with its password vaulted and checked out, and confirm from the logs that each recent change maps to one person.

Physical access granted but never reviewed

Key cards to server rooms and network closets get issued when a project starts and rarely removed when people change roles or leave. An assessor will ask who holds access and whether anyone checked that list recently. Closing step: export the badge holder list for each room that houses changeable systems, compare it against current authorized changers, remove stale entries, and record the review date and reviewer as evidence.

Approvals recorded after the change

Tickets are often opened or updated once the change is already live, so the approval timestamp falls after the implementation timestamp. That sequence shows the restriction was not enforced, even if the approver later signed off. Closing step: configure the change workflow so implementation tasks cannot start until the approval state is recorded, then sample recent changes and compare the approval and implementation times line by line.

Emergency changes with no record

Urgent fixes made directly on a host during an incident can skip the workflow entirely, leaving no change record, approver or window. These are often the changes an assessor is most interested in. Closing step: define an emergency change path with named authorizers and a required retrospective ticket within a set period, and review the system audit logs against the ticket queue to find changes that have no matching record.

Drafts presented as final procedures

Change control procedures, approval matrices and change window schedules are frequently marked as drafts in a shared folder, or were approved by email but never finalized. Under the assessment rules, a requirement is met only with evidence in final form, so a draft does not satisfy the objectives. Closing step: give every procedure a version number, an approver, an effective date and a final status in the document control system, and remove or label superseded copies.

Enforcement configured but never tested

Restrictions may be set in group policy, a privileged access tool or a patch interface, yet nobody has tried to make an unapproved change to see whether it is blocked. The assessment objectives include testing the mechanisms that enforce change access restrictions, not only reading their configuration. Closing step: script a test in which an unauthorized account and an out-of-window change attempt are both made, record whether each is blocked and logged, and retain the results with the date and tester name.

Questions buyers ask about CM.L2-3.4.5 before hiring help

How much effort does CM.L2-3.4.5 take compared with other CM requirements?

It is a moderate effort requirement, and the effort depends mostly on how many ways a change can reach your systems. CM.L2-3.4.5 is worth 5 points, the same weight as CM.L2-3.4.1, and NIST SP 800-171A breaks it into 8 assessment objectives. CM.L2-3.4.7 has 15, so it generally asks for more evidence to show. The work is not the mechanism alone. You must define, document, approve and enforce both physical and logical restrictions, and an assessor will test each of those four steps for both types. Count your change paths first: server rooms, admin consoles, patch tools and change windows. Each one adds an approval record and an enforcement test to prepare.

Can a small team handle CM.L2-3.4.5 in-house?

Yes, a small team can often do it in-house if the people who make changes are separate from the people who approve them. The hard part is usually not the technology but the separation of duties. A lean team may have one administrator who both requests and performs changes, and that pattern will not produce the approval evidence an assessor expects. Small teams commonly use a ticketing tool to hold change requests and approvals, and open-source options such as GLPI include a change workflow based on ITIL practices, which you should confirm meets your needs. Engaging outside help is most useful for the document set, the enforcement tests and a pre-assessment review, not for running daily changes.

What does the internal team need to provide for CM.L2-3.4.5?

Your team needs named owners for each control point before any outside partner starts work. The usual roles are:

A facilities or physical security owner who controls server room key cards and access logs
An identity administrator who manages change-specific credentials and their approval trail
A system owner for each platform who defines which changes are allowed and in which windows
Named approvers for changes, separate from the people who implement them
A records owner who keeps change records and audit records in final form

The partner can draft procedures, but policy decisions and approvals must come from your organization, because the assessor tests what you actually did.

How long does CM.L2-3.4.5 take to implement, and what drives the timeline?

No researched duration is available for this requirement, so confirm the timeline in a written scope rather than relying on a general estimate. The main drivers are the number of physical spaces with system access, the number of credential systems that control changes, how many change paths already produce records, and whether change windows are documented today. Work goes faster when a single approval workflow covers most systems and slower when each platform has its own informal process. Ask the partner to list the assumptions behind the timeline, including what your team must deliver and by when, since a delay on an owner's approval usually moves the whole schedule.

Can CM.L2-3.4.5 be placed on a POA&M?

No, CM.L2-3.4.5 cannot be placed on a plan of action and milestones (POA&M). Under the CMMC Scoring Methodology in 32 CFR 170.24, it is worth 5 points, which is more than 1 point, and 32 CFR 170.21(a)(2) does not allow requirements of that weight on a POA&M. If the requirement is NOT MET, its 5 points are subtracted from the maximum score of 110. You must reach MET for all applicable objectives, with evidence in final form, before you can reach Conditional or Final Level 2 status. Treat this as a go-live requirement and plan your evidence around it. The eCFR text for 32 CFR Part 170 contains the rule.

What changes if CMMC Level 2 certification is suspended?

The requirement itself does not change, but the timing of third-party certification does. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, and it began a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW has also said it will enforce NIST SP 800-171 Rev. 2 in the interim. Check the DoW CIO About CMMC page and your contracting officer for the current status, because the rule text and the DoW pages do not yet fully agree.

What should a written scope from an implementation partner include for CM.L2-3.4.5?

A written scope should name the systems, physical spaces and change paths in scope, and state which of the 8 assessment objectives each deliverable covers. Ask for:

A list of change paths, including server rooms, admin consoles, patch interfaces and change windows
The procedures and approval workflows to be written, with the owner of each
Evidence to be produced: access approvals, credential records, change records and audit records
Tests of the enforcement mechanisms, with the test steps written down
The client-side tasks and decisions the timeline depends on
Exclusions, such as what is not covered and who issues any assessment report

DeployOpen works this way: its fixed-scope engagements agree scope, deliverables and timelines in writing before work starts, and it prepares systems and evidence without issuing audit reports or certificates.

How DeployOpen scopes and prepares access restrictions for change

DeployOpen works on CM.L2-3.4.5 by preparing the physical and logical restrictions on who can change your systems and the evidence that proves they operate. The organization owns its change policy and access decisions, and an independent assessor makes the MET determination.

How we scope

Written scope lists the in-scope systems, change paths, and physical areas such as server rooms and network closets.
Scope names each change channel, including admin consoles, patch interfaces, and configuration tools, that must be restricted.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure logical restrictions such as privileged change roles, separate change credentials, and approval gates in your platforms.
We set up physical controls with your facilities team, including key card access to server rooms and logged entry records.
We configure fixed change windows and a constrained patch path, then test that unauthorized changes are actually blocked.

How we hand over

Documentation covers each restriction, its approver, its owner, and the steps to request an exception.
Evidence packs include access lists, approval records, change window settings, and enforcement test results in final form.
Handover includes a walkthrough so your staff can run approvals and review access without DeployOpen involved.

How we support

Ongoing support is available as a retainer for periodic access reviews, change window updates, and evidence refreshes.
Retainers can cover upgrades to the self-hosted platforms that enforce change restrictions, when you request them.
Your assessor, whether a C3PAO or a self-assessment reviewer, decides the outcome; we prepare the evidence they will examine.