Zero Trust Security Requires Edge-Based Trust Decisions

In this interview with Help Net Security, Chuck Davis, VP of Global Information Security at Hikvision, explores how zero trust principles apply to physical security systems such as cameras and door controllers. He explains the nuances of making trust decisions at the edge without accidentally rebuilding outdated perimeter models, why these devices must be treated as IT assets, and the lasting lessons from the Mirai botnet attack. Davis also addresses posture assessment for devices that cannot run standard security agents, and how to manage device identity and revoke trust across tens of thousands of endpoints during an active incident.

The conventional zero trust mantra is “never trust, always verify.” But physical security systems impose a hard constraint: a 200-millisecond door unlock decision cannot afford to wait for a cloud-based policy engine that might be experiencing latency. How do you design trust decisions at the edge without quietly reintroducing the perimeter assumptions you are trying to eliminate?

A common misunderstanding about zero trust is that every authorization decision must be routed to a centralized policy engine in real time. This is often cited as a reason to exclude physical security systems from zero trust architecture altogether, as if a door controller’s time limit exempts it from sound security principles. In reality, it is a design constraint, and there is a well-established architecture for meeting it without abandoning the core tenet that nothing should be trusted simply because of its network location.

Zero trust does not mandate centralized decision execution. It requires centralized trust governance. These are distinct concepts, and keeping them separate is what makes edge enforcement viable.

The preferred model is distributed trust with centralized policy. Policy creation, identity governance, and authorization logic remain centralized. Enforcement happens locally at the edge, where latency and operational continuity matter most. This architecture separates the Policy Decision Point (PDP) from the Policy Enforcement Point (PEP). The PDP determines whether access should be granted based on identity, context, policy, and risk signals. The PEP, residing on the edge controller or access device, executes that decision locally. The door opens in well under 200 milliseconds. The policy governing that decision was authored, validated, and pushed from a centralized system.

The critical point is that local enforcement does not mean local trust. Edge devices should operate with cryptographically signed policies, short-lived credentials, and well-defined access boundaries. Policies are distributed and cached locally but remain governed centrally, refresh on a defined cadence, and are subject to revalidation. A controller should never be trusted just because it sits inside a particular VLAN or building network. That is the old perimeter security model in disguise, and it can quietly creep back into zero trust architectures if you are not deliberate about preventing it.

This is where organizations often run into operational trouble. You start with a well-designed architecture and a 90-second policy cache lifetime. Then a network hiccup causes a door to fail to unlock, and someone submits a facilities ticket. Instead of fixing the underlying network reliability issue, the security team extends the cache lifetime to avoid more complaints. Ninety seconds becomes 30 minutes, then four hours, then a 12-hour offline grace period. At that point, you no longer have zero trust at the edge. You have a slowly drifting perimeter, and nobody documented it as a security decision because it happened one exception at a time.

The architecture also requires a deliberate answer to the fail-safe versus fail-secure question, and the answer is not the same for every door. Emergency egress systems often prioritize availability and life safety, so they should default open under degraded network conditions. Highly restricted environments may require the opposite. Those outcomes need to be explicit architectural decisions, not accidental side effects of a dropped network connection.

Ultimately, zero trust is not about routing every decision through the cloud. It is about ensuring that wherever decisions are made, they are identity-aware, constrained, continuously validated, and revocable. The 200-millisecond door controller is not an exception to that principle. It is a particularly clear illustration of why the architecture must be designed for the environment it operates in.

A Hikvision device sits at a fascinating intersection: it is simultaneously an IoT endpoint, a data processor, and a physical actuator. When conducting a threat model for a customer’s environment, which of these three identities generates the most dangerous blind spots, and can you walk us through a real scenario where that blind spot was exploited?

The framing of your question assumes organizations are actively managing all three identities and just getting one wrong. The more common challenge across the industry is that the foundational shift has not fully taken hold: physical security devices are still not universally treated as IT assets.

There is a tendency to think of physical security equipment only in terms of its physical purpose. A camera is a camera. A badge reader is a badge reader. An NVR is a recording appliance. That framing shapes everything downstream: how devices are inventoried, how they are maintained, and how cyber risk for those systems is assigned across the organization. The moment a physical security device connects to a network, it becomes something else entirely. It becomes an embedded compute platform running an operating system, authentication services, APIs, a web interface, a database, encryption functions, and remote management capabilities.

When physical security and IT operate in separate silos, that risk often falls into the gap between them. That gap is where the blind spots live.

The scenario that brought this into sharp focus was the Mirai botnet in 2016. Mirai’s operators scanned the internet for IoT devices, including large numbers of IP-connected security cameras and DVRs, and compromised them at scale by logging in with factory credentials that had never been changed. No zero-day exploits. No sophisticated tradecraft. Those compromised cameras were recruited into a botnet used to launch some of the largest distributed denial-of-service attacks ever recorded, including the October 2016 attack against Dyn that took down Twitter, Reddit, Netflix, and large portions of internet infrastructure for hours.

What made Mirai so damaging was not the sophistication of the attack. It was that the industry had not yet established consistent standards for how these devices should be deployed and secured. Devices were internet-exposed without firewall protection. Security hardening guidance was inconsistent or absent. Network monitoring on physical security segments was rare. Mirai exposed the gap between how these devices were being deployed and how they needed to be managed as networked IT assets.

That is the blind spot. Not a sophisticated attack against a complex threat model. Internet-exposed cameras, running factory defaults, with likely nobody watching the traffic they were generating.

Most of these controls are not novel. The challenge is operational discipline. Isolate physical security devices on their own network segment. Place them behind a firewall with no direct inbound access from the internet. Keep firmware current. Follow manufacturer hardening guidance. If remote access is required, use a VPN or zero trust network access solution. If an attacker cannot reach your security camera, they cannot attack it.

Physical security infrastructure is enterprise IT infrastructure. The most important architectural shift is recognizing it as such and managing it accordingly.

Firmware is the soft underbelly of physical security devices. What does a zero trust posture assessment look like for a camera or access reader that cannot run an EDR agent, cannot be patched during business hours, and may have a seven-year depreciation cycle baked into a facilities budget?

A mature zero trust assessment for these environments starts by accepting an uncomfortable reality: many physical security devices will never achieve the same security telemetry or control depth as enterprise laptops and servers. Trying to force traditional IT security assumptions onto them leads to frustration and poor risk decisions. The goal is not perfect visibility. The goal is risk reduction through compensating controls.

The concept I find most useful here is the trust envelope. Rather than trying to instrument the device directly, you define and enforce a boundary of acceptable behavior around it. What should this device communicate with? Which protocols? How often? At what volume? That profile, captured through network telemetry from adjacent infrastructure, becomes your posture proxy. A camera that should only communicate with a local video management server should not be initiating outbound connections to unfamiliar infrastructure. Anything outside the envelope is worth investigating.

On the device side, the assessment should focus on what you can actually validate. Secure boot and signed firmware verification provide stronger assurance that the device is running what it is supposed to be running. A software bill of materials (SBOM) gives you the component-level inventory you need to know when a vulnerability in a third-party library inside that firmware actually affects you. I would take that a step further and argue that a network bill of materials (NetBOM), a structured inventory of what devices exist, their expected communication patterns, and their approved network dependencies, is equally important. Without that foundation, you are making security assertions against an unknown baseline.

Surrounding the device, least-privilege networking does the heavy lifting when endpoint controls are unavailable. Segmentation, deny-by-default firewall rules, and tightly scoped management access through dedicated out-of-band networks collectively limit what an attacker can do even if a device is fully compromised. You may not be able to see inside the box, but you can control what the box can reach and who can reach it.

Lifecycle governance is where many organizations fall short. Facilities budgets assume seven to ten years of operational use. Security expectations move considerably faster. That gap widens quietly until a device that still functions perfectly well is running firmware nobody is updating anymore. At that point, it stops being a technical problem and becomes a business risk decision. Replacement thresholds, vulnerability disclosure monitoring, and procurement standards tied to vendor support commitments all need to be part of the assessment framework from the start.

The real maturity test is whether the organization can detect a compromise quickly, isolate the affected device cleanly, and keep it from becoming something larger.

Identity for human users is hard enough. For physical security devices, you are dealing with device identity at scale, sometimes tens of thousands of endpoints in a single campus deployment. What does credential compromise look like when the “user” is a PTZ camera, and how do you revoke trust from a device that is bolted to a ceiling in a restricted zone during a live incident?

Device identity at scale is a different problem entirely, and the physical security environment makes it harder in ways that do not get enough attention.

A campus deployment managed with shared credentials or static API keys is not a device identity program. It is an asset list with false confidence attached to it. Shared credentials do not compromise the way a human account does. There is no failed login from an unusual location, no suspicious authentication time, no behavioral anomaly a security team can correlate against a user profile. Few environments have written detection rules for a PTZ camera behaving like an authenticated user account.

What credential compromise looks like for a physical security device is more subtle. Configuration changes initiated from unexpected management sources. Outbound connections to destinations outside the device’s established communication baseline. Firmware version mismatches against what the asset inventory says should be running. Authentication attempts to the management plane from IP addresses that are not the designated controller. None of those are exotic indicators. They are just indicators that most physical security environments are not actively watching for.

The scale problem compounds everything. When thousands of devices share a credential pool, a single compromise does not affect one device. It potentially affects all of them, and you may have no clean way to determine which ones were accessed or what was done. The architecture that makes this manageable is individual device certificates issued from an enterprise PKI with automated enrollment and renewal. One certificate per device. Defined lifetime. Automated renewal. A device that fails to renew, or whose certificate is explicitly revoked, loses authenticated access.

Certificate support varies significantly across manufacturers, ranging from basic certificate import through a web interface all the way to full automated lifecycle management with SCEP enrollment, OCSP revocation, and API-driven certificate rotation. Those are not the same thing, and procurement teams should ask specifically which capabilities a device supports before assuming enterprise PKI integration is possible. Identity without automated rotation eventually becomes credential management debt. Certificate lifecycle automation may become an increasingly important differentiator in physical security procurement.

The groundwork for revocation has to be laid before an incident, not during one. The authorization to execute isolation actions needs to be pre-granted. The network hooks need to be pre-configured. The mapping from every device to its switch port, VLAN, and management controller needs to exist in the asset inventory before something goes wrong. When that preparation is in place, quarantining a compromised device becomes a VLAN reassignment or an ACL update from the network access control platform, executed remotely in under a minute without dispatching anyone to the physical location. Where certificate-based identity is deployed, revocation can close authenticated sessions quickly, though the speed depends on whether the environment uses real-time OCSP checking or CRL-based revocation.

Device identity at scale requires deliberate architecture, tested processes, and clear ownership. The time to build that foundation is before an incident makes it urgent.