03.04.05 Access restrictions for change: requirements and evidence

What 03.04.05 access restrictions for change requires in plain terms

If a contract or assessment requires NIST SP 800-171, 03.04.05 asks you to define, document, approve and enforce the physical and logical restrictions that decide who may make changes to your system. The requirement is not satisfied by a policy that says only authorized people change systems. You must be able to show which people, roles and access paths can make changes, who approved those permissions, and how the restrictions are enforced in practice, both in the server room or facility and in the software and accounts used to reach the system. The risk behind the requirement is unauthorized or untracked change to a system that holds CUI. A change that nobody approved can weaken a security setting, open a path into the environment, or alter what data is stored and where. If the change is also unrecorded, the organization cannot tell whether its security baseline still holds. The requirement traces to control CM-5 in SP 800-53 Rev. 5, which NIST lists as the source for 03.04.05. Rev. 2 requirement 3.4.5 covers the same ground for CMMC Level 2, and NIST's change analysis classifies the Rev. 3 wording as editorial only, so an existing 3.4.5 implementation is a sound starting point.

In practice, the hard parts are predictable. Administrative accounts accumulate over years, with former project staff, service accounts and shared logins still able to change production. Emergency access is often granted informally during an outage and never removed, so the break-glass path becomes the normal path. Vendor and managed service access is frequently granted by a ticket and left open, with no defined window or named approver. Confirm with your assessor which evidence they will accept for each of these, and for the physical side, such as data center or network closet access lists. Start by listing every account, group and remote path that can change configuration, then check each against an approval record. Open-source ticketing tools such as GLPI can hold change approvals, and file integrity monitoring such as Wazuh can show who modified a monitored file, which together give the approval and detection evidence an assessor will ask for.

Which systems, people and third parties fall under 03.04.05

The scope of 03.04.05 is set by where change can happen, not by the size of the environment. Each decision below widens or narrows the set of people, paths and records an assessor will ask to see, so settle them before writing the procedures.

The CUI system boundary

Every component inside the boundary where CUI is processed, stored or transmitted, along with the security protection assets that support it, is in scope for access restrictions on change. Start from the boundary in the system security plan and confirm that it matches the actual inventory of hosts, containers, network devices and management consoles. Anything that can change a boundary component without being in the boundary definition is a gap an assessor will find. Ask whether shared services such as directory, logging or backup can alter in-scope systems.

Administrators and change implementers

Every account that can alter configuration, install software or push code to an in-scope system counts, including local administrators, service accounts and automation identities. The narrow version is a short, named list of people authorized to make each type of change. The wide version includes anyone with standing root or domain admin rights. Expect an assessor to compare the approved list with the actual privilege assignments in your directory and configuration management tools.

Physical access to server rooms and closets

Physical access that allows someone to plug into a console, swap a drive or replace a network device changes the system, so server rooms, network closets and cabinets holding in-scope equipment are part of 03.04.05. Document who holds keys, badges and combinations, who can enter without escort, and how entries are logged. Cloud-only organizations still need to know which colocation or cloud provider facilities their own staff can enter and what that provider has committed to in writing.

Remote and vendor maintenance paths

Vendor remote support sessions, jump hosts, VPN accounts and maintenance portals are logical paths to change the system even when no employee sits at the console. Each path needs an owner, an approval step, time-limited access and a record of the session. Inventory these paths separately from internal admin access, because they often sit outside the normal directory and are the most common gap found during reviews. Confirm with each vendor how it authenticates staff and whether it can make changes without your approval.

Cloud control planes

In a cloud deployment, the control plane (the console, API endpoints, infrastructure-as-code pipelines and identity roles that create or modify resources) can change in-scope systems without touching a server. Treat it as in scope when it can alter any in-scope component. Confirm which roles can modify network rules, images, instance configuration or logging settings, and whether those changes are restricted to approved change records. Ask your cloud provider which of these controls are yours to configure and which they operate on your behalf.

Change records that prove the restriction

A restriction is only evidenced if the change records show it working. Keep records that tie each change to an approver with the right authority, and check that the change tool's permissions match the access list. The Wazuh file integrity monitoring documentation describes alerts on file creation, modification or deletion with the user responsible, which can catch changes made outside the approved path. Confirm that alerts reach someone who reviews them.

How an assessor tests access restrictions for change

The examine method checks whether the rules for who may change the system are written down, approved and consistent with each other. For 03.04.05, SP 800-171A Rev. 3 directs assessors to look at the configuration management policy and procedures, the procedures for access restrictions for system changes, and the configuration management plan. The assessor is checking for a documented basis for the control, not for proof that it runs in practice.

Configuration management policy and procedures: Confirm the policy names an owner, states who may make changes, and is reviewed on a defined schedule.
Access restriction procedures: Look for steps that define physical and logical restrictions, the approval path for each change type, and how exceptions are handled.
Configuration management plan: Check that the plan identifies the systems in scope, the roles that hold change rights, and the tools that enforce the restrictions.
Common finding: Procedures that describe access restrictions in general terms without naming roles, groups or systems, so they cannot be tested.
Common finding: Documents that conflict, such as a plan that lists one approver while the procedure lists another.

Before the assessment, confirm that each document is current, approved by the right owner and traceable to the system security plan.

Sequence for implementing change access restrictions

This sequence turns 03.04.05 from a policy statement into enforced limits on who can change the system, both physically and logically. Each step produces a record an assessor can examine, interview against and test.

Define the change-authorized population and access points
Start by listing every person, service account and vendor identity that can make changes to the system, and every physical location from which changes can be made, such as server rooms, network closets, data center racks and maintenance consoles. The security or system owner approves this list, with the scope drawn from the system security plan boundary. The step is done when each entry has a named owner, a stated reason for change access and an approval date. Keep the list current, because the assessor will compare it against the access records you produce later.
Document the restriction procedure in the configuration management plan
Write the procedure that states how change access is granted, reviewed, removed and enforced, and place it in the configuration management plan alongside the policy and procedures that govern configuration management. The procedure should name the roles that approve access, the systems where it applies and the records that prove each restriction is in force. Assessors examine this document first, so the step is complete only when the plan, the procedure and the system security plan describe the same restrictions. Confirm the wording with your assessor or contracting authority if the scope is unclear.
Restrict logical change rights through identity and privilege groups
Move change rights into defined identity and privilege groups, so that administrative and configuration rights are held only by members of groups tied to the authorized population. Remove standing change rights from general user accounts, separate change roles from everyday user roles where the platform allows it, and bind service accounts to specific tasks. Your identity administrator or platform engineer carries out this work, and the output is an exported group membership report that matches the approved list. Where a platform cannot separate these rights, record the limitation and the compensating control you chose.
Route every change through an approval record
Require each system change to be requested, reviewed and approved in a ticket or change record before anyone implements it, and make the approval a precondition for access to the change path. A service desk or change tool, such as the open-source GLPI Assistance module that handles tickets and changes under ITIL practices, can hold these records if your organization selects it. The step is done when a sample of recent changes shows a request, an approver who is on the authorized list and a timestamp that precedes implementation. Changes made outside this path should show up as exceptions for review.
Verify physical access restrictions at each access point
Confirm that the physical locations identified in the first step are controlled by locks, badge readers, or escorted access rules that match the documented procedure. The facilities or physical security lead inspects each point, checks the access list against the authorized population and records any gaps. This work overlaps with physical protection requirements in 03.10, so reuse those access lists rather than building a second set. The step is done when each access point has an inspection record and every person with physical change access appears on the approved list.
Test enforcement and monitor for unauthorized changes
Attempt changes with accounts that are not on the authorized list and confirm that the system blocks them or that the attempt is logged and alerted. Then check that changes made through approved accounts can be traced to an approval record. File integrity monitoring, such as the open-source Wazuh module that alerts when a user or process creates, modifies or deletes a monitored file, can provide evidence of unauthorized changes if you configure it for the relevant directories. The step is done when you have test results, alert samples and a documented remediation for each failure, and when you have scheduled periodic review of the access lists.

Evidence that passes 03.04.05 and how to keep it current

An assessor testing 03.04.05 will ask for a short set of artifacts that show who may change the system, how that authority was granted, and whether it was enforced. Each artifact goes stale in its own way, so each needs a named owner and a refresh trigger between assessments. The cards below cover the documented procedure, the role mapping, the access lists, the approval records, the enforcement logs and the physical access lists.

Documented restriction procedure

This is the written procedure that defines how physical and logical access restrictions for system changes are set, approved and enforced. It should name the systems in scope, the roles that hold change authority and the steps for granting and removing it. Assessors compare it against what staff actually do, so check that the procedure still names current tools and teams. A stale procedure refers to retired ticketing queues, former administrators or change windows nobody follows.

Role-to-change-authority mapping

This mapping shows which job roles may approve, implement or emergency-override changes to each system component, and which roles only request them. It answers the question an assessor asks first: who is allowed to change this system and why. Review it when reporting lines change, when a team is reorganized and when a contractor's role ends. A stale mapping lists people who have left and omits the on-call engineers who now make emergency changes.

Access list for change-capable accounts

This is an export of every account, group and service identity that can alter configurations, deploy software or modify the change tooling, with the date each was last reviewed. Include administrator groups on hypervisors, configuration management servers and the repositories that hold infrastructure code. Compare the list against the role mapping and remove accounts that have no matching role. A stale list contains shared administrator logins, orphaned service accounts and privileges granted for a project that closed long ago.

Physical access lists

For facilities and cabinets that house system components, keep the list of people authorized to enter server rooms, network closets and areas where hardware can be physically changed. Record the sponsor who approved each entry and the date of the last review. Confirm the list against badge system exports at the same time, since a list and a badge system that disagree will fail a test. A stale list keeps the access of visitors, vendors and staff who moved to other sites.

Approval records tied to changes

Each change to the system should carry a record showing who requested it, who approved it, whether the approver held the authority the role mapping assigns and when it was implemented. The assessor will select sample changes and trace them back to an approval. Use a ticketing system such as GLPI, whose Assistance module handles tickets, problems and changes under ITIL practices, or a comparable tool your team already runs. A stale record set includes changes marked approved after the fact, or approvals given by people outside their assigned authority.

Enforcement logs and drift alerts

Enforcement evidence shows that changes outside the approved path were blocked or detected. File integrity monitoring such as Wazuh records a baseline of checksums and attributes for monitored files, then alerts when a user or process creates, modifies or deletes one, including who made the change. Verify jobs in Bareos compare files against cataloged attributes, which supports detection of unapproved changes. Review alerts against approval records each cycle, because an alert with no matching ticket is the finding an assessor will test for. Stale evidence means monitored paths were never updated after the environment changed.

What meeting 03.04.05 costs in money and effort

This table breaks down the money and effort behind 03.04.05 by cost component, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request, since no supplied figures give prices or durations for this requirement. The main takeaway is that role design and evidence upkeep usually cost more over time than the tooling itself, and open-source tooling mainly removes license spend.

Cost component	Who is paid	One-time or recurring	What drives it
Ticketing and change records (for example GLPI or Zammad)	Software vendor or none if self-hosted open source; implementation partner for setup	Setup is one-time; hosting and administration recur	Number of change types, approval steps and integrations with other systems
File integrity monitoring (for example Wazuh)	Open-source platform carries no license fee; infrastructure and internal staff are paid	Deployment is one-time; alert triage and tuning recur	Number of monitored hosts, directories and change volume that generates alerts
Backup verification (for example Bareos Verify jobs)	Open-source platform carries no license fee; storage and staff time are paid	Configuration is one-time; scheduled verify jobs recur	Size of the protected data set, verification frequency and storage capacity
Engineering time for role design and enforcement	Internal staff, or an implementation partner under a written scope	Mostly one-time, with periodic review	Number of CUI systems, separation of duties required and number of physical access points to define
Privileged administrator population	Internal staff time to review and recertify access	Recurring	Size of the admin population and frequency of role changes; fewer named administrators lowers review effort
Evidence upkeep	Internal compliance and operations staff	Recurring	Frequency of changes, number of approval records to retain and how often access lists are reviewed
External testing or review	Independent assessor or security testing firm, under a written scope	Recurring at each assessment cycle	Scope of systems in the assessment boundary and depth of review of change controls
Auditor sampling	Assessor or the contracting federal agency's assessor, not the implementation partner	Recurring at each assessment	Number of change samples the assessor selects and how easily records can be retrieved

Who owns 03.04.05 and what a partner can take on

Your organization remains accountable for 03.04.05 because the requirement concerns who may change the system, and that decision belongs to the people who run it and answer for it. Under the NIST FAQ, the federal agency that holds the contract is responsible for how SP 800-171 is applied and for any compliance issues, so your leadership must be able to explain the access model without relying on a vendor.

Policy and procedures: Approve the configuration management policy and the procedures for access restrictions for system changes, and name the owner who reviews them.
Approvers and authority: Name the personnel with logical and physical access control responsibilities, define who may approve changes, and document how that authority is delegated.
Access decisions: Decide which accounts, roles, change windows and physical locations may modify production systems, and record each grant and removal.
Exceptions and emergencies: Decide how emergency changes are authorized and reviewed afterward.

Confirm that these owners can answer assessor interview questions directly, because the assessment method for this requirement includes interviews with the people who hold these responsibilities.

Where organizations fall short on change access restrictions

Most organizations define who may change a system on paper, then lose track of that answer during an incident, a vendor visit or a rushed release. The gaps below are the ones assessors most often find when they test 03.04.05 against the procedures and records that show access restrictions are defined, approved and enforced.

Undocumented emergency access

Break-glass accounts and emergency elevation paths often exist outside the change process, so an administrator can alter production during an outage without any record of who approved it. Assessors ask for the documented emergency procedure, the list of people allowed to use it and the logs showing each use. Check that every emergency use is reviewed after the fact and tied to a change or incident ticket.

Shared administrative accounts

When several engineers log in with one administrator account, the system cannot show which person made a change, and the restriction on who may change the system becomes unenforceable. Confirm that each person who can change configuration has an individual privileged identity, and that the list of holders matches the access restriction documentation. Shared credentials that cannot be retired should be listed as a defect with an owner and a date.

Approvals that do not match the change

A ticket may show an approved change for a minor patch, while the deployed work touched firewall rules, service accounts or other security-relevant settings. This gap appears when approvals are granted to a summary rather than to the specific configuration items affected. Compare recent approved tickets with the actual configuration history and confirm that each material change has a matching approval.

Physical access lists out of date

Badge lists for server rooms, network closets and data halls often keep former contractors and role changers long after their duties ended, so physical access to change systems is broader than the documented restriction. Assessors interview the people who maintain these lists and compare them with current staffing and vendor schedules. Confirm that list reviews occur on a defined cycle and that removals are processed when roles change.

Vendor access outside the change process

Managed service providers and software vendors sometimes connect remotely to make changes through their own tools, bypassing the ticketing and approval steps the organization requires. This creates changes that no internal approver reviewed and sessions that the internal team cannot trace. Confirm that every vendor session is requested through the change process, time-bound, and recorded, and that the vendor's access list is reviewed with the internal one.

Common questions about 03.04.05 access restrictions for change

What drives the effort and cost of meeting 03.04.05 access restrictions for change?

The biggest drivers are how many people and systems can change the environment today, how many separate change paths exist (cloud consoles, hypervisors, endpoint management, network devices, and physical access to racks), and how much of the approval and enforcement logic is already written down. Fewer change paths and a clear list of who holds change rights make the requirement cheaper to meet. Costs fall into two groups: one-time work to define roles, restrict access and build records, and recurring work to review access lists and keep evidence current. No price is given here because none is supplied for this requirement; ask any provider for a quote built from a written list of systems and change paths.

When should 03.04.05 be in place before an assessment?

It should be operating, with records, before the assessor starts testing, because the assessor looks for evidence that the restrictions are enforced over time, not just described. In practice, the access restrictions, the change approval roles and the change logs need to exist for a period long enough to show they were used. Teams often start this work alongside configuration change control (03.04.03) so that the approval workflow and the access restrictions point to the same records. Confirm the exact evidence window with the assessing body or sponsoring agency before you schedule.

What does the client's team need to provide for this work?

The client's team must own the decisions that the requirement assigns to the organization: who may change the system, who approves changes, and who can physically reach the equipment. An implementation partner can prepare the configuration of access controls, change tooling and logging, but it cannot decide who is authorized. Expect to supply the current account and role inventory, the list of physical access holders for relevant rooms, the existing change procedures, and named staff for interviews. Staff who hold logical or physical access control duties will be interviewed, so they need to be available and able to explain the process.

Can an organization meet 03.04.05 without outside help?

Yes, an organization can meet the requirement in-house if it has staff who understand its systems, can write and maintain the procedures, and can produce evidence on a schedule. The work is mostly defining roles, restricting access through existing identity and administration tools, and keeping records. Outside help is most useful when the environment is complex, when the team lacks time to build the evidence, or when an independent view is needed before an assessment. Whichever path is chosen, the organization remains responsible for its controls, and only an independent assessor can issue the assessment result.

How does 03.04.05 relate to CMMC practice 3.4.5?

CMMC Level 2 practice CM.L2-3.4.5 corresponds to the Rev. 2 requirement 3.4.5, and NIST's change analysis traces 03.04.05 in Rev. 3 back to that same Rev. 2 requirement, classifying the change as editorial only. The CMMC scoring methodology in 32 CFR 170.24 assigns that practice 5 points. Under 32 CFR 170.21, this practice cannot be placed on a plan of action and milestones to reach Conditional status, so it must be fully implemented for that status. Because DoD assessments currently use Rev. 2 wording, teams should confirm the applicable version in their contract before mapping evidence.

What does a partner do, and what does the assessor do?

A partner plans the work, configures access restrictions and change tooling, sets up logging, prepares procedures and assembles evidence so the organization can show the control operating. An assessor, such as an independent auditor or a government assessor where the contract requires one, examines documents, interviews personnel and tests the process, then reports the result. The partner does not issue reports, attestations or certifications, and it does not decide whether the requirement is met. Ask any provider to state this split in writing in its scope.

Which open-source tools can produce evidence for this requirement?

A change-request workflow can be handled by GLPI's Assistance module, which supports tickets and changes following ITIL practices, with approvals tracked as part of the record. Zammad can route change-related requests from users into a ticket system. Wazuh file integrity monitoring can alert when a user or process creates, modifies or deletes a monitored file, with details on how, when and by whom. Bareos Verify jobs compare files against previously cataloged attributes, which can help show whether unauthorized changes occurred. Tools produce records, but the organization must still define who may change the system and confirm each tool's capabilities in its own environment.

Where to read the requirement and assessment procedure

Start with the primary text. The requirement for 03.04.05 sits in NIST SP 800-171 Rev. 3, and the assessment procedure that an assessor will follow sits in its companion, SP 800-171A Rev. 3. Read the requirement first, then the assessment procedure, because the procedure shows what an assessor will ask to see: the *configuration management policy and procedures*, the procedures for access restrictions for system changes, the configuration management plan, interviews with the people who control logical and physical access, and a test of the process itself. Both documents are published on the NIST site, and the requirement page is the one to bookmark. Confirm the current wording there before you write it into a system security plan or a policy, because summaries, vendor blogs and training slides often paraphrase the text and drift from it.

If your contract flows down CMMC, the scoring and remediation rules matter as much as the requirement text. CMMC Level 2 still assesses this practice against Rev. 2 numbering, as CM.L2-3.4.5, and the scoring methodology in 32 CFR 170.24 sets its point value. Check the enforced version with your contracting officer, because the DoW has tied current assessments to Rev. 2 while the rule set evolves. Then read 32 CFR 170.21 before you plan any remediation. It governs when a plan of action and milestones may be used, and for this practice it does not permit a POA&M to support Conditional status. In practice, that means access restrictions for change need to be working at assessment time, not scheduled as a future fix.

Ask your assessor, or the contracting officer who will rely on the result, which requirement version and which scoring rules apply to your contract. Record the answer in writing, along with the date you checked the NIST and eCFR pages. An implementation partner can help you map your change-control and access records to the determination statements, but only the authority that governs your contract can tell you which version counts.

How DeployOpen scopes and evidences 03.04.05

DeployOpen helps organizations define who can change a nonfederal system holding CUI, then builds the access restrictions and records that show they operate. The organization owns the requirement and its decisions, while DeployOpen prepares the systems, procedures and evidence that an assessor will examine, interview against and test.

How we scope

Confirm which systems, change paths and administrator groups fall within the CUI boundary before work starts.
Agree in writing which physical and logical change-access restrictions are in scope, with deliverables and timelines.
Identify the named owners for logical access control and physical access control who will be interviewed.
Engagements are fixed-scope, and ongoing support can be added as a retainer once the written scope is agreed.

How we build

Document who may make changes to in-scope systems, and tie each role to an approved access path.
Configure change-access restrictions in the ticketing and change workflow, such as GLPI's Assistance module, so changes are requested and approved.
Set up file integrity monitoring with Wazuh and verify jobs with Bareos to detect changes made outside approved access paths.

How we hand over

Deliver the procedures for access restrictions for system changes and the configuration management plan that assessors examine.
Provide test records showing that change-access restrictions were exercised, including approvals, denied attempts and alert reviews.
Hand over a walkthrough for interviews with the people who administer logical and physical access to change paths.

How we support

Review change-access restrictions when personnel, roles or change tooling are altered, and record each review.
Keep monitoring rules, approval workflows and documentation current through a retainer if the organization wants continuous support.
Ask any independent assessor or certification body you engage to confirm which evidence they accept for 03.04.05.