top of page

Does Your PACS Live Inside Your CMMC Boundary? Why Physical Access Control Is a Scope Decision, Not an Afterthought

  • Writer: kate frese
    kate frese
  • May 23
  • 4 min read

Executive Summary

Most CMMC discussions start and end with "cyber." But CMMC scoping is fundamentally about where CUI lives, how it moves, and who can access the systems that store, process, or transmit it. That means your Physical Access Control System (PACS)—badge readers, controllers, access logs, admin consoles, and the network they ride on—can become part of your CMMC boundary faster than most organizations realize.


This white paper explains why PACS is often a scope decision, not a facilities afterthought. We'll walk through the practical ways PACS intersects with CUI environments, the most common scoping mistakes, and a defensible approach to deciding whether PACS belongs inside your CMMC boundary—and what to do either way.


Why This Matters: CMMC Scope Is About Access, Not Labels

CMMC scoping is not just "the IT network." It's the set of assets and environments that could reasonably impact the confidentiality of CUI. If physical access enables someone to reach systems that handle CUI, tamper with infrastructure that supports those systems, or obtain credentials, logs, or administrative control that affects CUI environments—then physical security and cyber security are no longer separable. They're one risk picture.

PACS sits at the intersection because it governs who can get into the spaces where CUI systems exist—and it produces data (logs, identities, schedules, access events) that can become sensitive in its own right.


What PACS Includes (So We Scope the Right Thing)

When people say "PACS," they often mean "badge readers on doors." In reality, PACS is an ecosystem: door readers and keypads, door controllers and panels, management servers and applications, admin workstations and consoles, identity store integrations (AD/Entra, HR systems), logging and retention systems, remote access methods (VPN, vendor support portals), and the network segments that connect these components. Scoping decisions should consider the whole chain, not just the hardware at the door.


The Core Question: Can PACS Affect CUI Confidentiality?

A clean way to evaluate PACS scope: Could compromise or misuse of PACS reasonably enable unauthorized access to CUI or to systems that handle CUI?

Path 1: PACS Controls Entry to CUI Spaces

If PACS controls entry to server rooms hosting CUI systems, offices where CUI is processed, print/scan rooms where CUI can be output, or secure storage areas for CUI media—then PACS is part of the access story. Even if PACS is not "cyber," it is a control that protects CUI environments.

Path 2: PACS Admin Access Is a High-Value Credential Target

PACS admin consoles often allow adding and removing badgeholders, changing access schedules, disabling alarms, and exporting access logs. If PACS admin accounts are weakly protected, shared, or remotely accessible without strong controls, an attacker can create physical access that bypasses cyber defenses entirely.

Path 3: PACS Data Becomes Sensitive and Crosses Boundaries

PACS logs can reveal staffing patterns, restricted area access, incident timelines, and privileged user movement. If those logs are stored on systems that also host CUI, or shipped to a centralized SIEM that is in-scope, PACS telemetry can become entangled with your CMMC boundary.

Path 4: PACS Runs on the Same Network as In-Scope Systems

This is the most common scoping failure: PACS sits on the corporate LAN, and the corporate LAN connects to enclaves that handle CUI. If PACS shares network paths with in-scope assets, you now have lateral movement risk, credential reuse risk, and shared management plane risk. Even if PACS isn't directly processing CUI, it can become a stepping stone.


Common Scoping Mistakes That Create Audit Pain

Mistake 1 — Treating PACS as "Facilities Only": Facilities may own the vendor relationship, but IT/security owns the boundary story. Split ownership means inconsistent controls and messy documentation.

Mistake 2 — No Clear Boundary Narrative: If you can't explain in one page where PACS lives, how it connects, and why it is or isn't in scope, you're inviting scope creep during assessment.

Mistake 3 — Remote Vendor Access Without Strong Guardrails: PACS vendors often require remote access for maintenance. If that access is persistent, poorly logged, or not MFA-protected, it becomes an easy back door into your environment.

Mistake 4 — Weak Identity and Role Management: Shared admin accounts, no RBAC, no quarterly access reviews, and no separation of duties are common in PACS deployments—especially older ones.


A Defensible Approach: Decide Scope Intentionally

Strategy A: Bring PACS Into the CMMC Boundary

Appropriate when PACS is tightly coupled to CUI spaces and systems, or when separating it would be impractical. Doing it properly means: dedicated network segmentation for PACS, strong admin authentication (MFA where possible), role-based access control and least privilege, centralized logging with retention and monitoring, documented vendor access procedures (time-bound, approved, logged), configuration management and patching cadence, and backups with recovery testing.

Strategy B: Keep PACS Out of Scope by Isolating It

Appropriate when you can clearly separate PACS from CUI environments and prove that separation. What you need: network isolation (separate VLAN or physical separation), no direct connectivity to in-scope enclaves, controlled documented data flows, strong boundary controls at integration points, and clear documentation including diagrams, asset inventory, and rationale.


Practical Controls Checklist: PACS + CMMC-Ready Hygiene

Asset inventory for PACS components (hardware, software, accounts). Network diagram showing PACS segments and connections. Admin account list with RBAC mapping. MFA enabled for admin access or compensating controls documented. Vendor access: approved method, time-bound access, logging, and review. Patch and update process for PACS servers and management workstations. Logging: access events, admin actions, configuration changes. Log retention aligned to incident response needs. Incident playbook for badge cloning, admin credential leaks, or log tampering. Quarterly access reviews and deprovisioning tied to HR events.


How Blue Violet Security Helps

Blue Violet Security approaches this as a scope and risk engineering problem, not a checkbox exercise. The deliverable isn't "PACS is in scope" or "PACS is out of scope." The deliverable is a defensible package: a clear boundary narrative (what's in, what's out, why), diagrams and data-flow mapping that match reality, a prioritized remediation plan that reduces audit and real-world risk, and a monitoring and governance approach that stays manageable for small teams.


Conclusion

CMMC scoping decisions that ignore physical access control create blind spots—exactly the kind that become painful during assessment or after an incident. PACS can be inside your boundary, outside your boundary, or partially intersecting—but it should never be accidentally connected to your CUI environment.



This content is provided for general informational purposes only and does not constitute legal or regulatory advice. Compliance requirements and regulations are subject to change. Blue Violet Security, LLC recommends consulting with appropriate legal and regulatory counsel before making compliance determinations.

Recent Posts

See All

Comments


bottom of page