A federal contractor's badge reader went offline during a routine firmware update last year. IT investigated and discovered the VMS server — the one recording activity at 14 entry points across a DoD facility — had been communicating outbound to an IP address in Eastern Europe for 11 days. The camera firmware had been silently replaced. Nobody noticed because the system sat on the same flat network as general office workstations, and nobody was watching lateral traffic between segments. The breach wasn't detected by the physical security team. It was flagged by a SIEM analyst who almost dismissed it as noise.
That is the gap Zero Trust is designed to close. And most federal physical security programs haven't closed it yet.
Zero Trust Is a Set of Principles — Not a Product You Buy
NIST Special Publication 800-207 defines Zero Trust as an architectural philosophy built on one core assumption: no user, device, or system should be trusted by default, regardless of whether it sits inside or outside the network perimeter. The document runs 50 pages and covers identity, access policy, device health, and continuous monitoring. Most federal Zero Trust initiatives have focused almost entirely on network identity management and cloud access — think CAC authentication for email and multi-factor login for remote users.
That work matters. But it leaves an entire category of networked infrastructure largely unaddressed: Physical Access Control Systems (PACS) and Video Management Systems (VMS).
These are not passive hardware boxes. A modern PACS server runs an operating system, holds a database of every badge credential in the facility, communicates over IP, and often integrates with HR systems and Active Directory. A VMS platform streams and stores video from dozens or hundreds of cameras, each of which runs embedded firmware, accepts remote configuration commands, and maintains persistent network connections. These systems are as exposed as any enterprise server — and they're frequently treated like they're not on the network at all.
NIST SP 800-207 doesn't carve out an exception for physical security hardware. A network-attached device is a network-attached device. The principles apply whether it's a laptop or a door controller.
The FY2024 Federal Zero Trust Strategy issued by OMB (M-22-09) set a deadline for agencies to reach specific Zero Trust maturity milestones. Physical security systems weren't explicitly called out — which is exactly why they keep falling through the cracks during implementation planning.
What "Assume Breach" Looks Like on a Physical Security Network
The "assume breach" principle from NIST 800-207 means you design your architecture as if an attacker already has a foothold somewhere in your environment. The question isn't whether a device will be compromised — it's how much damage that compromise can cause before it's contained.
On a flat network — meaning a single VLAN where PACS controllers, VMS servers, IP cameras, workstations, and printers all communicate freely — the answer is: a lot of damage. One compromised camera becomes a pivot point. From there, an attacker can scan for the VMS server, attempt credential reuse against the PACS database, and potentially manipulate door access records or unlock specific entry points. This isn't a theoretical attack chain. It's been documented in both criminal and nation-state intrusion cases targeting critical infrastructure.
Assume breach changes the design logic entirely. Instead of asking "how do we keep attackers out," you ask "if something is already compromised, what can it reach?" The answer to that question should be: almost nothing beyond its own function.
Practical implementation for physical security means:
- PACS controllers and head-end servers placed on a dedicated network segment with explicit allow-list firewall rules — not broad access to the enterprise subnet
- VMS servers and IP cameras on a separate isolated segment, with camera-to-server traffic permitted but no direct camera-to-workstation or camera-to-internet paths
- All inter-segment traffic logged and inspected, not just north-south traffic from the perimeter firewall
- No management access to physical security devices from general user workstations — dedicated jump servers with MFA required for administrative sessions
- Outbound internet access for physical security devices blocked by default, with explicit exceptions for approved update servers only
This is not an expensive architecture. A properly configured next-generation firewall, a managed switch stack with VLAN segmentation, and a documented access control policy gets you most of the way there. The cost isn't the technology — it's the discipline to design it correctly from the start and not compromise it during installation because a subcontractor needed a shortcut to finish on time.
Continuous Device Verification Is Not Optional After the First Handshake
NIST 800-207 is explicit on this point: trust is not a one-time grant. A device that authenticated successfully at 9 a.m. may be running malicious firmware at 2 p.m. The architecture has to account for that.
For physical security systems, continuous verification means three things in practice:
1. Device identity management. Every IP camera, door controller, and server on the physical security network should have a known identity — a MAC address tied to a specific port, a certificate if the device supports it, or at minimum an asset record that's actively maintained. Unmanaged devices showing up on the segment should trigger an alert, not just get an IP from DHCP and start talking.
2. Configuration baseline monitoring. A camera running known-good firmware with a specific configuration has a measurable state. Drift from that state — a firmware version change, a new open port, a modified configuration file — should be detected automatically. Tools like network access control (NAC) platforms and device management systems from vendors like Axis, Genetec, and Lenel S2 have varying degrees of this capability built in. The question is whether it's enabled and whether anyone is reviewing the output.
3. Behavioral anomaly detection. A camera that normally sends a steady 4 Mbps video stream and suddenly starts generating 40 Mbps of outbound traffic at 3 a.m. is behaving abnormally. That traffic pattern should be visible in your SIEM or network monitoring platform. In most federal physical security deployments we've walked into, the VMS traffic is either not monitored at all or exempted from alerting rules because someone didn't want the noise. That's not a monitoring problem — it's a policy problem.
GSA's Physical Access Control System Procurement Guide references the need for system monitoring and audit logging, but stops short of prescribing the Zero Trust-aligned architecture that actually makes that logging actionable. Agencies filling that gap on their own are ahead of the curve. Agencies waiting for explicit guidance are already behind.
Network Segmentation Is the Baseline, Not a Best Practice
There's a framing problem in how physical security professionals talk about network segmentation. It gets described as a "best practice" — something desirable but optional, implemented when budget allows. That framing is wrong, and it's costing agencies real security exposure.
A PACS system that controls badge access to a Sensitive Compartmented Information Facility (SCIF) or a pharmacy dispensing cabinet or a weapons storage room is not a low-risk system. It is a high-value target. If it shares routing with general office infrastructure, any workstation user whose machine is compromised is one credential-theft attack away from having access to the PACS management interface. At that point, the physical security system itself becomes the attack surface — not just a victim of it.
The FICAM architecture guidance from GSA, combined with the DoD's Risk Management Framework (RMF) process under NIST SP 800-37, both establish requirements for security controls on systems handling access credentials. What they don't always make explicit is that network segmentation is the foundational control that makes everything else — logging, monitoring, least privilege — actually enforceable. Without segmentation, you're applying security controls to a system that can be bypassed from any compromised node on the enterprise network.
When TSS Group scopes a PACS or VMS deployment for a federal customer, network segmentation is built into the bill of materials before the first piece of hardware is specified. It's not a change order. It's not a value-added option. It's a design requirement, because the alternative creates liability for the agency and a security gap that an attacker will eventually find.
The specific architecture varies by facility and existing infrastructure:
- Greenfield deployments get dedicated physical security VLANs with next-gen firewall enforcement from day one
- Retrofit deployments require a network assessment first — we need to know what's already sharing segments with the existing PACS before we can design the isolation correctly
- Multi-building or campus deployments need a segmentation strategy that covers inter-building connections, not just the head-end server room
- Cloud-connected VMS platforms require additional scrutiny — the segmentation architecture has to account for what data leaves the network and under what conditions
The Bottom Line
Zero Trust for physical security isn't a product you procure or a certification you achieve. It's a set of architectural decisions you make — or fail to make — when you design and deploy PACS and VMS systems. NIST SP 800-207 gives you the framework. The three principles that matter most for physical security are network segmentation, continuous device verification, and assume-breach design. None of them require exotic technology. All of them require deliberate planning before hardware goes in the wall.
If your current physical security network puts cameras, door controllers, and office workstations on the same segment, start there. Map the traffic, document what should be communicating with what, and build the firewall rules that enforce it. That single action — proper segmentation with explicit allow-list policies — closes more attack surface than any camera upgrade or software feature ever will.
TSS Group designs physical security systems for federal agencies with Zero Trust architecture built in from the start. If you're scoping a PACS or VMS project and need a partner who understands both the technical requirements and the federal compliance environment, that's the conversation we're built for.