CMMC Level 2 Practice 3.4.5: Define, document, approve, and enforce physical and logical access restrictions associated with

CMMC Level 2 Practice 3.4.5 requires you to formally define, document, approve, and then consistently enforce the physical and logical access restrictions tied to your CUI environment. To operationalize it fast, you need an access restriction standard, an approval workflow, technical enforcement points (IAM, network, endpoint), and repeatable evidence showing restrictions are applied and reviewed. ¹

Key takeaways:

• Document access restrictions by asset/system boundary, role, and access method (physical entry and logical access) and tie them to your CUI scope. ²
• Prove “approve and enforce” with workflow records plus system configurations that match the documented restrictions. ³
• Build an evidence cadence that produces assessor-ready artifacts without scrambling (tickets, logs, access lists, diagrams, and review records). ³

This practice is about turning “who can get in” into a controlled, auditable program across two planes: physical access (facilities, rooms, racks, media storage) and logical access (accounts, roles, network paths, remote access, administrative interfaces). Assessors will look for alignment between your written restrictions, the approvals you collect, and what systems actually enforce. If your policy says only cleared engineering staff can access a CUI enclave, but your identity groups, VPN rules, or badge lists don’t match, 3.4.5 becomes a fast finding.

Operationally, the most efficient way to meet CMMC Level 2 Practice 3.4.5: define, document, approve, and enforce physical and logical access restrictions associated with requirement is to treat “access restrictions” as a controlled specification: (1) define scope and boundaries, (2) write role-based restrictions, (3) require formal approvals for exceptions and privileged access, (4) implement enforcement points, and (5) collect evidence continuously. CMMC draws from NIST SP 800-171 Rev. 2 and is assessed under the CMMC program rule structure, so your approach needs to be both technically real and documentation-complete. ⁴

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.4.5 (Define, document, approve, and enforce physical and logical access restrictions associated with).” ¹

What the operator must do:

• Define the restrictions: state what access is permitted and what is prohibited for both physical entry and logical system access in the environment that stores/processes/transmits CUI. ²
• Document the restrictions: put them in controlled documents (policy/standard/procedure) that an assessor can trace to the in-scope boundary and systems. ²
• Approve the restrictions and changes: show governance over who can grant access, how exceptions are approved, and how decisions are recorded. ³
• Enforce the restrictions: demonstrate technical and procedural enforcement (badge systems, keys, escort rules; IAM groups, MFA conditions, network segmentation, admin controls) and show it works in practice. ³

Plain-English interpretation

You need a single, coherent answer to: “Which people can access which CUI locations and systems, through which paths, under which conditions, and with whose approval?” Then you must implement it so the real environment matches the answer.

Think of 3.4.5 as the control that prevents “tribal knowledge access.” If access rules live only in admins’ heads, you cannot prove they are defined, approved, or consistently enforced. ²

Who it applies to (entity and operational context)

Applies to organizations pursuing CMMC Level 2 for DoD work where CUI is present in systems, networks, cloud services, or facilities. ⁵

Typical in-scope contexts:

• A dedicated CUI enclave (on-prem or cloud) with controlled remote access.
• Mixed environments where only certain apps, shares, or projects contain CUI, requiring segmentation and tight role definition.
• Facilities with CUI in offices, labs, secure rooms, print areas, or locked cabinets/media storage.

Also applies to third parties that can access your CUI environment (managed service providers, consultants, staffing firms) because their access must be restricted, approved, and enforced the same way as employees. ¹

What you actually need to do (step-by-step)

1) Lock the CUI boundary first

If you cannot clearly state what is “in” and “out,” you cannot define meaningful restrictions.

• Identify in-scope systems, identities, networks, facilities/areas, and data flows for CUI.
• Produce a boundary description that ties to real enforcement points (VPN, firewall segments, cloud accounts/subscriptions, physical rooms). ³

Deliverable: CUI boundary statement + supporting diagrams (network and physical areas).

2) Define the access restriction model (roles, methods, locations)

Create a simple matrix that covers:

• Subjects: employee roles, contractors, third-party support, visitors.
• Objects: systems (apps, servers), data repositories, admin consoles, network segments, physical rooms/racks.
• Methods: onsite access, remote access, privileged access, service accounts, break-glass access, removable media.
• Conditions: MFA, device compliance, time-of-day, escort required, logging required, encryption requirements.

Practical tip: Start with a default-deny posture for both physical and logical access to the CUI boundary, then explicitly list allowed paths. Keep exceptions rare and time-bounded in your process. ²

Deliverable: Access Restrictions Standard (role-based) + Access Control Matrix.

3) Document the approval workflow (who can say “yes”)

Assessors will test whether approvals are real, consistent, and recorded.

• Define approval authority for:
  • New user access to in-scope systems
  • Privileged/admin access
  • Physical access badges/keys to controlled areas
  • Temporary access and visitor access
  • Exceptions to standard restrictions
• Require a recorded request and approval artifact (ticket, workflow, signed form) with business justification and scope. ³

Deliverable: Access Request/Approval Procedure + exception procedure.

4) Implement enforcement points (make the systems match the paper)

Map each restriction to a control mechanism:

• Logical enforcement:
  • IAM groups/roles mapped to job roles
  • MFA and conditional access for remote/admin access
  • Network segmentation rules that limit east-west movement
  • Privileged access management (or tightly controlled admin group membership with approvals)
  • Device posture checks where feasible (managed endpoints for CUI access)
• Physical enforcement:
  • Badge access lists for controlled doors
  • Locked racks/cabinets for CUI systems or media
  • Visitor controls (sign-in, escort, badge differentiation)
  • Procedures for keys and badge issuance/revocation

If a restriction has no enforcement point, it is a “paper control.” That is a common failure mode in CMMC assessments. ³

Deliverable: Configuration snapshots and settings exports showing enforcement.

5) Prove enforcement through recurring reviews (and fix drift)

Create repeatable checks that catch mismatch between documentation and reality:

• Periodic review of:
  • In-scope system access lists (app roles, file shares, cloud IAM)
  • Privileged/admin group membership
  • Remote access/VPN entitlements
  • Badge access lists for controlled areas
  • Third-party access still needed and still approved
• Tie review results to remediation tickets and document closures. ³

Deliverable: Access review records + remediation evidence.

6) Integrate third parties into the same restriction and approval model

For each third party with access:

• Document permitted systems and methods (interactive admin, support portal, VPN, bastion).
• Require named accounts where possible, role-limited permissions, and clear start/stop dates.
• Ensure offboarding removes logical and physical access quickly and evidences the removal. ¹

Deliverable: Third-party access register + approvals + termination evidence.

Required evidence and artifacts to retain (assessor-ready)

Keep evidence that shows definition, documentation, approval, and enforcement. A tight evidence set:

• Access Restrictions Policy/Standard (physical + logical) ²
• CUI boundary definition and diagrams ³
• Role-based access control matrix mapped to in-scope systems
• Access request/approval tickets (including privileged access and exceptions) ³
• IAM exports: group membership, role assignments, admin lists
• Remote access configuration evidence (e.g., conditional access/MFA settings)
• Network segmentation evidence (rule sets, diagrams, change records)
• Physical access artifacts: badge issuance logs, door access lists, visitor logs, key control logs
• Access review reports and follow-up remediation tickets ³
• Onboarding/offboarding checklists with timestamps and completion evidence

Evidence hygiene rule: Store artifacts in a controlled repository with versioning and clear “period of performance” context so an assessor can sample a time window without ambiguity. ³

Common exam/audit questions and hangups

Assessors tend to press on traceability. Expect questions like:

• “Show me your documented restriction for this system, then show me the configuration that enforces it.” ³
• “Who approves privileged access, and where is the approval recorded?” ³
• “How do you restrict physical access to CUI work areas after hours?” ²
• “How do you prevent third-party support accounts from having broad standing access?” ³
• “How do you detect and correct access drift?” ³

Hangups that cause delays:

• अस्पष्ट CUI scope and moving boundaries
• Shared accounts or informal admin access
• Physical controls managed by facilities without security governance records
• Exceptions approved verbally with no durable record

Frequent implementation mistakes (and how to avoid them)

1. One policy for everything, no system-level restrictions.
   Fix: keep policy high-level, but add a system-by-system access matrix for in-scope assets. ²

2. Approvals exist, but not for the highest-risk access (admin, remote, third party).
   Fix: require explicit approvals for privileged roles and remote entry paths, and retain the tickets. ³

3. Physical access treated as “facilities,” not security.
   Fix: bring badge lists, visitor logs, and key control under the same control owner and evidence process as IAM. ³

4. Exception process becomes the normal process.
   Fix: time-box exceptions, require compensating controls, and force re-approval. Keep an exception register. ³

5. Evidence is ad hoc.
   Fix: define an evidence calendar and standard exports/screenshots. Daydream can help you map 3.4.5 to control operation steps and recurring evidence capture so you are ready before an assessor asks. ³

Enforcement context and risk implications

The provided sources for this requirement do not include public enforcement case citations for 3.4.5 specifically, so you should treat enforcement risk here as assessment and contract eligibility risk under the CMMC program structure and its alignment to NIST SP 800-171 Rev. 2 expectations. ⁶

Practical risk outcomes when 3.4.5 is weak:

• Unauthorized access to CUI from over-permissioned accounts or poorly controlled remote paths
• Insider threat exposure from inadequate physical restrictions
• Failure to demonstrate control operation during a CMMC assessment due to missing approval and enforcement evidence ³

A practical 30/60/90-day execution plan

Numeric day-based timelines are not source-backed in the provided materials, so treat this as a phase plan you can compress or extend based on scope and staffing. ³

Phase 1: Immediate (establish control design)

• Confirm CUI boundary and in-scope assets (logical and physical). ³
• Draft Access Restrictions Standard and RBAC matrix for in-scope systems. ²
• Define approval authorities and exception process; implement a single intake path (ticketing or workflow). ³

Phase 2: Near-term (implement and align enforcement)

• Align IAM groups/roles to the RBAC matrix; remove broad access not supported by documented restrictions. ²
• Lock down remote and privileged access paths; ensure approvals exist for each privileged assignment. ³
• Bring facilities artifacts into scope: badge lists, visitor procedures, and controlled-area definitions. ³

Phase 3: Ongoing (operate, review, and produce evidence)

• Run recurring access reviews and document remediation. ³
• Test a sample: pick a user, trace their approved access to enforcement configurations and logs.
• Use Daydream to maintain the 3.4.5 control narrative and automate evidence requests/collection across IT and facilities teams so the control stays “always ready.” ³

Frequently Asked Questions

Does 3.4.5 require both physical and logical controls even if we are “cloud-first”?

Yes. You still have physical access considerations for offices, endpoints, and any areas where CUI can be viewed or stored, plus logical access for cloud tenants and applications. ²

What counts as “approval” for access?

Approval is a recorded decision by an authorized approver that grants specific access under defined conditions. A ticket, workflow record, or signed form works if it is traceable to the access granted. ³

Do we need a separate policy for physical access vs logical access?

You can keep them in one access restrictions standard if it stays readable and enforceable, but the restrictions must clearly cover both physical entry and logical system access for the CUI boundary. ²

How do we handle third-party MSP access under 3.4.5?

Document exactly what systems they can access and how, require explicit approvals, and enforce least-privilege roles with strong authentication for remote/admin paths. Keep offboarding evidence when the engagement ends. ⁷

What evidence is strongest for “enforce”?

Configuration evidence (IAM role assignments, conditional access rules, VPN entitlements, firewall rules) plus logs or review records that show the restrictions are active and monitored. Pair each documented restriction with its technical enforcement point. ³

We have informal visitor procedures. Is that a problem?

It becomes a problem if you cannot show defined restrictions and consistent enforcement for controlled areas where CUI is present. Convert informal practice into a written procedure and retain visitor logs and escort requirements as evidence. ¹

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; 32 CFR Part 170; DoD CMMC Program Guidance

5. 32 CFR Part 170; DoD CMMC Program Guidance

6. 32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

7. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2