Physical security fleets — cameras, badge readers, door locks, sensors, turnstiles — are networked computers with the same attack surface as any endpoint, and almost none of the protection. This paper examines how Threatmatic combines Zero Trust Network Access (ZTNA), post-quantum cryptography via QSChannel™, and Privacy Enhancing Technology (PET) to close that gap, with particular attention to how QSChannel™ builds on and extends WireGuard's own quantum-resistant design intent.
The Attack Surface Nobody Models
Physical security devices are rarely included in threat models. They are treated as infrastructure — installed, configured, and forgotten. But each one is a networked computer with open ports, firmware vulnerabilities, and the ability to communicate laterally once compromised.
A camera becomes a foothold. Cameras are among the most frequently compromised networked devices in the world — not because attackers want the footage, but because unpatched firmware and factory-default passwords make them reliable entry points. Once inside a camera, an attacker has a persistent, authenticated presence from which they can map the environment, intercept management traffic, and pivot toward higher-value targets.
A badge reader gets spoofed. If the communication between a reader and its access control server is unencrypted or authenticated only at connection setup, an attacker on the same segment can intercept and replay valid credential exchanges — granting access without ever presenting a physical badge. The system logs show a valid credential. Nothing looks wrong.
A door controller receives forged commands. In a flat physical security network, anything that can reach the access control server can potentially issue door open or close commands. A compromised camera can become a door controller. A spoofed sensor can trigger false alarms or mask an active intrusion.
The pattern is consistent: a device in your fleet gets compromised, and the attacker uses it not as an end in itself, but as a starting point for something worse.
Why Traditional Security Tools Don't Reach These Devices
Most enterprise security tools were never designed for physical security infrastructure. Endpoint detection and response platforms require software agents. You cannot install an agent on a badge reader or a door lock controller — these devices run stripped-down firmware with no accessible operating system layer. Network access control solutions depend on device compliance checks that assume the device can run code. VPNs assume the device has a user interface and a keyboard.
The result is a predictable gap. Managed laptops and servers get full protection. Physical security devices get none.
Zero Trust Network Access: Cryptographic Identity for Every Device
Zero Trust Network Access (ZTNA) is built on a simple principle: nothing is trusted because of where it is. Trust must be earned, verified, and continuously maintained — by every device, on every connection, every time.
Cryptographic identity, not network position. A badge reader is not trusted because it is on the physical security VLAN. It is trusted because it holds a verified cryptographic identity checked on every communication. A compromised device attempting to impersonate a legitimate reader fails identity verification even if it is physically in the same rack. Position means nothing. Identity means everything.
Explicit permissions, nothing else. Every device is defined by what it is allowed to do — and nothing more. A camera is authorized to stream to its management platform, and nothing else. A badge reader is authorized to communicate with the access control server, and nothing else. Any attempt to communicate outside these explicit boundaries is blocked automatically and triggers an alert. Lateral movement is structurally impossible.
Continuous verification, not point-in-time trust. Threatmatic verifies every session, every handshake, every packet exchange against the device's known identity and behavioral baseline. A device that begins behaving inconsistently — regardless of its enrollment status — is flagged and isolated before the anomaly can cascade.
Agentless enrollment. None of this requires installing software on devices that can't run it. Threatmatic discovers and enrolls every device through network-layer fingerprinting — identifying each device by manufacturer, device type, firmware version, and communication pattern without touching the device itself.
Privacy Enhancing Technology: Security Without Surveillance
Physical security devices handle deeply sensitive data. Cameras capture footage of real people. Badge readers log every movement of every employee. Biometric readers store physiological data that can never be changed if compromised. Securing them traditionally means monitoring them — and monitoring them means creating the very data that creates privacy liability.
Threatmatic resolves this with Privacy Enhancing Technology (PET) and fully homomorphic encryption (FHE) built into the security layer itself.
Device behavior, not device content. Threatmatic monitors communication behavior — packet rates, protocol conformance, connection patterns, session timing — without ever inspecting the payload. A camera's video stream is never seen by the security layer. A badge reader's credential data is never accessed. Security is achieved through behavioral analysis, not content inspection.
Fully homomorphic encryption for fleet intelligence. FHE allows computation to happen on encrypted data without decrypting it first. Threatmatic can aggregate and analyze behavioral patterns across your entire fleet — identifying anomalies, benchmarking performance, surfacing threat signals — without the underlying data ever existing in plaintext. Your fleet becomes measurably more secure over time without creating a secondary data liability.
No PII stored, ever. Device identity in Threatmatic is cryptographic, not biographic. No personally identifiable information passes through the Threatmatic monitoring plane. The platform tracks device behavior — communication patterns, protocol conformance, session characteristics — without touching the personal information those devices process.
Post-Quantum Cryptography: WireGuard's Design Intent, Fulfilled
Most physical security devices will be in service for ten to fifteen years. The traffic those devices generate today — credential exchanges, access logs, camera management streams — may still be sensitive in 2035.
Harvest Now, Decrypt Later (HNDL) makes this threat immediate, not future. Adversaries are capturing encrypted traffic today with the explicit intention of decrypting it once quantum computers become capable. Classical encryption offers no protection against this attack.
What WireGuard Designed For
The WireGuard protocol paper (Donenfeld, NDSS 2017) explicitly anticipates the quantum threat in Section 5.2, "Optional Pre-shared Symmetric Key Mode." The authors describe an optional 256-bit pre-shared key (PSK) that peers may exchange out-of-band and inject into the handshake's key derivation chain — specifically to mitigate harvest-now-decrypt-later attacks against Curve25519 ECDH.
The paper states directly:
"The attack model here is that adversaries may be recording encrypted traffic on a long term basis, in hopes of someday being able to break Curve25519 and decrypt past traffic."
But the authors also concede:
"In lieu of using a completely post-quantum crypto system, which as of writing are not practical for use here, this optional hybrid approach of a pre-shared symmetric key to complement the elliptic curve cryptography provides a sound and acceptable trade-off for the extremely paranoid."
WireGuard's PSK mode was a stopgap — sound in principle, limited in practice. Manual PSK distribution creates key management overhead. A static pre-shared key that is never rotated eventually becomes a liability. The authors knew this. QSChannel™ is what WireGuard's Section 5.2 was waiting for.
How QSChannel™ Fulfills WireGuard's Quantum-Resistant Design
Rather than a manual pre-shared key, QSChannel™ uses ML-KEM (NIST FIPS 203) to encapsulate a fresh session key on every handshake — and injects that ML-KEM-derived key directly into WireGuard's PSK slot. The result is that WireGuard's own quantum mitigation mechanism is activated automatically, on every session, with a key that was never transmitted classically and cannot be broken by a quantum computer.
The pre-shared key is no longer pre-shared: it is post-quantum encapsulated, fresh per session, and forgotten immediately after use.
What QSChannel™ Retains from WireGuard
WireGuard's symmetric encryption layer — ChaCha20Poly1305 AEAD — was already quantum-resistant. At 256-bit key lengths, Grover's algorithm effectively halves the security to 128 bits, which remains far beyond any foreseeable attack. BLAKE2s and HKDF, used for hashing and key derivation, are similarly unaffected by quantum advances. QSChannel™ keeps all of this.
What it replaces is the one component WireGuard's authors identified as the quantum weak point: Curve25519 ECDH key exchange. ML-KEM takes that role. ML-DSA (NIST FIPS 204) takes the role of static public key authentication. Both are standardized by NIST and designed to resist attacks from quantum computers at any foreseeable scale.
Ephemeral Keys and Perfect Forward Secrecy
WireGuard already generates a fresh Curve25519 ephemeral key pair per session and zeroes handshake material from memory after key derivation — a design discipline that limits exposure if a long-term key is later compromised. QSChannel™ preserves this discipline with ML-KEM ephemeral encapsulation: a new key pair is generated for every session, no long-lived keys are ever reused, and a device compromised in the future yields zero usable cryptographic material from any prior session.
Traffic captured today cannot be decrypted later — not by a classical computer and not by a quantum one.
Asymmetric Path Isolation
QSChannel™ goes further than WireGuard's single bidirectional tunnel. Outbound and inbound traffic travel on separate encrypted tunnels with independent keys. An attacker who intercepts one direction of a communication cannot reconstruct the full session. Session hijacking and man-in-the-middle attacks are mathematically impossible under this architecture.
| WireGuard | QSChannel™ | |
|---|---|---|
| Key exchange | Curve25519 ECDH (quantum vulnerable) | ML-KEM / FIPS 203 (quantum resistant) |
| Authentication | Curve25519 static keys | ML-DSA / FIPS 204 (quantum resistant) |
| Symmetric encryption | ChaCha20Poly1305 (quantum resistant) | ChaCha20Poly1305 (retained) |
| Hashing | BLAKE2s (quantum resistant) | BLAKE2s (retained) |
| Quantum mitigation | Optional PSK, manual | ML-KEM into PSK slot, automatic per session |
| Tunnel topology | Single bidirectional | Separate outbound/inbound, independent keys |
| PFS | Ephemeral Curve25519 | Ephemeral ML-KEM |
What Fleet-Wide Protection Actually Looks Like
With Threatmatic deployed across a fleet of 200 devices — cameras, badge readers, door locks, turnstiles, environmental sensors, and access control panels across a campus — your security operations team has a view that did not previously exist.
Every device is behaviorally visible. Not just "is it online?" visible, but what it is communicating, who it is communicating with, whether its patterns match its established baseline. A camera that has never made an outbound connection outside its management platform is flagged the moment it tries to. A badge reader whose communication volume suddenly spikes is isolated before anyone investigates manually.
Every device is isolated. Each device operates in its own cryptographic micro-zone, permitted only to communicate with explicitly authorized endpoints. Lateral movement — the primary technique attackers use to escalate from a compromised device to a broader intrusion — is structurally impossible.
Every event is logged with cryptographic integrity — each entry chained to the previous, making retroactive tampering detectable. When something happens, the evidence is already there.
The fleet gets smarter. Behavioral baselines improve with time. Threat patterns identified across one deployment inform defenses across all — without sharing raw data, and without exposing any device's specific communication content.
Deployment Without Disruption
These devices cannot go offline. Access control systems cannot have downtime. Security cameras cannot have gaps in coverage.
Threatmatic deploys in passive discovery mode first — typically one to two weeks — observing and mapping every device's communication patterns without enforcing policy. This builds the accurate behavioral baseline that makes enforcement precise. False positives are minimal because policy reflects observed reality, not theoretical assumptions.
When enforcement activates, the existing infrastructure is unchanged: no new network hardware, no reconfiguration of existing devices, no installation of agents. The fleet continues to operate exactly as it did — with every device now cryptographically identified, behaviorally monitored, and protected against lateral movement.
Summary
Threatmatic's approach to physical security fleet protection rests on three interlocking layers:
ZTNA isolates every device in its own cryptographic micro-zone, enforcing explicit permissions per device and blocking lateral movement structurally.
QSChannel™ secures every device communication with post-quantum cryptography — building directly on WireGuard's transport foundation and fulfilling the quantum-resistant design WireGuard's authors explicitly intended in Section 5.2, replacing Curve25519 with ML-KEM and activating WireGuard's PSK quantum mitigation automatically on every session.
PET and FHE allow behavioral monitoring and fleet-wide intelligence without ever touching device content or exposing PII — security that genuinely protects without creating new privacy liability.
The fleet you deploy today will still be secure in 2035. The devices that protect your people deserve to be protected themselves.
To see how Threatmatic secures physical security fleets in your environment, contact us or start a 14-day Silent Discovery Pilot.