Zero trust for camera fleets

Zero trust for camera fleets is authenticating and authorizing every camera, and every consumer of that camera, without granting trust because the device sits on the camera VLAN, because the organization owns it, or because it was commissioned years ago. NIST SP 800-207 states the rule without cameras in mind: no implicit trust based solely on physical or network location, or on asset ownership. Authentication and authorization of both the subject and the device happen before a session to a resource is established. On a camera fleet those two roles collapse onto the same hardware.

A camera is a subject when it presents an identity to the switch to get on the network. It is a resource when a recorder, a technician, or a health platform opens a session to it. Trusting the VLAN treats both of those as already decided. Searchers type zero trust IoT for this same architecture applied to cameras, recorders, and the tools that reach them. It monitors device health, not video.

What the seven tenets actually require of a camera

NIST SP 800-207 section 2.1 lists seven tenets and says they are the ideal goal, not a claim that every tenet can be implemented in its purest form. That caveat matters more for cameras than for laptops. A recording path is a long-lived session. A dome cannot do multifactor authentication. Firmware eligibility is per product, not a single current number. The useful work is mapping each tenet onto the device.

Tenet	Camera reading	What fleets do instead
1. All data sources and computing services are resources	Each camera is a resource. So is the recorder that consumes it. The VLAN is not a resource that confers trust	The camera segment is treated as the trusted zone
2. All communication is secured regardless of network location	Certificates actually in service, unique credentials, management not reachable from the internet	“It is on our LAN, so HTTPS can wait”
3. Access is granted per session	NIST allows this to mean “sometime recently,” not a new handshake every frame. Re-evaluate credentials and certificates on a defined cycle. Access to one camera does not grant access to the next	Either treat a 24/7 stream as a web login, or never re-evaluate because the stream is long-lived
4. Access is determined by dynamic policy, including device state	Policy inputs are firmware eligibility, certificate validity, unique credentials, and whether the running version is named in an advisory	Policy is “cameras on VLAN 40”
5. The enterprise monitors integrity and security posture of every asset	Reachable is not healthy. Inventory comes from the devices. No asset is inherently trusted	A down-icon in the recorder, checked when someone notices
6. Authentication and authorization are dynamic and enforced before access	Unique device credential plus a certificate. Multifactor authentication belongs on the human session to the management system. NIST 800-207 names MFA for access to enterprise resources; the camera cannot do it	Waiting for the dome to grow a second factor, or skipping rotation because MFA is for users
7. Collect asset state and use it to improve policy	Evidence generated as the week happens, per camera	A commissioning spreadsheet

CISA’s Zero Trust Maturity Model v2.0 puts the same split in different words. Identity includes non-person entities. Devices include IoT. The model also says it does not address challenges specific to operational technology or certain classes of IoT. Cameras sit in that gap. The April 2026 joint guide Adapting Zero Trust Principles to Operational Technology closes part of it: when the device cannot support modern access controls, put compensating controls around it, including multifactor authentication on the human path that reaches the device. That is the camera rule. MFA the technician. Do not wait for the hardware.

Four standing grants that look like zero trust

Most camera programs fail NIST’s first assumption without noticing. The assumption is that the entire enterprise private network is not an implicit trust zone. On a camera estate the implicit zone is usually four standing grants, not one VLAN:

Standing grant	What it actually says	Why it fails 800-207
Location	It is on the camera segment, so it belongs	Network location is the thing tenet 2 says not to treat as trust
Ownership	We bought it, so it is ours	NIST assumption 3: no resource is inherently trusted. Subject credentials alone are insufficient for device authentication
Consumer	The recorder still has a password that works	A standing secret is a session that never ended
Technician	Anyone who has been on site still can	Access to camera 12 is not authorization for camera 13, and last year’s truck is not a current grant

A remote-access product can authenticate the operator who opens a session. The fleet still has to authenticate the camera as subject and as resource. The four grants above skip both checks.

Three identities, and why factory origin is not ownership

A camera holds three identities that fail independently. Programs that collapse them into “the password” will rotate the wrong one, or none of them.

Identity	What it proves	Who issues it	How it actually fails
Factory device identity	This hardware was built by that manufacturer	The vendor, at manufacture	Treated as a rotatable certificate, or accepted as proof the camera is yours
Operational network identity	This camera is allowed on this segment today	Your CA, as the 802.1X client certificate	Expires, the switch drops the port, the path you would use to renew it is gone
Admin and consumer credentials	A named account may manage the device or pull a stream	You, at commissioning, then every consumer that stored a copy	One shared admin password across the estate, known to every technician, never rotated because rotation breaks recording

Axis cameras with Edge Vault ship an IEEE 802.1AR Initial Device Identifier (IDevID), branded Axis device ID, stored in the tamper-protected keystore and signed by Axis. Axis documents that IEEE 802.1X is enabled by default with that device ID pre-selected, including in the factory-default state. IEEE 802.1AR also defines a Locally Significant Device Identifier (LDevID) issued by the owner. The IDevID is permanent. A factory default does not delete it. The LDevID is operational. A factory default does delete it. Axis says the device ID is designed to prove the origin of the device. A genuine Axis camera that is not in your inventory still has a valid one: a spare from a truck, a demo unit, a camera that belongs to the integrator. A RADIUS policy that accepts any certificate signed by the Axis CA as production access treats all of those as members of the estate. The published practice, including Cisco’s 802.1AR onboarding note, is narrower. IDevID gets the device onto a restricted path long enough to provision it. Production access requires an LDevID from your CA. Keep the factory identity. Issue your own certificate for the port. Do not rotate the IDevID as if it were the operational certificate.

IDevID as the standing 802.1X credential has a second cost. Factory identities are issued for the life of the hardware. They do not give you the yearly re-evaluation that a customer LDevID expiry does. Certificate expiry is the built-in “sometime recently” that tenet 3 can actually use on a camera.

Current Bosch models also ship with device-specific factory certificates. Bosch then assigns certificates in the on-device store to specific usages. An uploaded certificate does nothing until it is assigned to the service that needs it, so a renewal that never gets bound is not an identity change.

Hanwha embeds device certificates during manufacturing starting with the Wisenet 7 generation (2020). Wisenet 5 era cameras, including X series models that share a letter with later hardware, do not have that stack. A mixed Hanwha fleet therefore contains cameras that can present a factory identity and cameras that cannot. The series letter does not tell you which. The chipset generation does.

Enabling 802.1X on the cameras leaves the other two identities unchecked. Axis can authenticate to the switch at factory default on the vendor identity. Bosch can hold a new certificate that is not in service. Hanwha can show a certificate in the store while HTTPS or 802.1X is still presenting the old one. Verify what the device is presenting, not what the store contains. The discipline is camera certificate management.

A factory default is where the three identities split in public. On AXIS OS 12.1 and later, a reset camera also changes how it accepts authentication: same model, same firmware, opposite policy from its upgraded-in-place neighbor. The operational certificate is gone. The IDevID is still there, and 802.1X comes back on with the Axis device ID pre-selected. What happens next is a RADIUS policy question, not a camera question. If production access requires your LDevID, the camera never gets an address and reads as bricked while it is running. If production access still accepts the vendor IDevID, the reset camera lands on the trusted segment as a new device with no consumer credentials and a first-boot account still to create. Treat it as a new device until all three identities are true again.

Per-session access on a stream that never ends

Tenet 3 is the tenet camera programs either ignore or over-read. NIST says access is granted per session, then immediately allows that evaluation to mean “sometime recently” rather than immediately before every transaction. Authentication to one resource does not grant access to a different one.

A recorder holding a stream is a session that may last months. You cannot re-prompt it like a browser. The camera-fleet reading is narrower than the slogan:

1. Name every consumer. Recorders, health platforms, technician tools, forgotten integrations. If you cannot list them, you cannot re-authorize them.
2. Re-evaluate on a cycle you can defend. Credential rotation and LDevID renewal are the session refresh. Additive cutover: add the new credential, cut consumers over, verify at the recorder, then retire the old one. A standing password that has not been reviewed since commissioning is a session that never ended.
3. Least privilege per consumer. The recorder needs to pull a stream. It does not need administrator. A shared admin password used for recording, management, and every truck is one identity doing three jobs.
4. One camera’s grant is not the fleet’s grant. A technician session to camera 12 is not authorization for camera 13.

The delayed failure is the one that produces findings. An established recorder session can keep running on an old credential after you thought you rotated. The icon stays green. A reboot later drops the stream, and the gap is dated to the power event, even though the grant had already expired.

Dynamic policy a camera can actually fail

Tenet 4 says access depends on the observable state of the requesting asset: software versions, installed credentials, time, previously observed behavior. For a camera that list is already operational, and it is the four columns in camera fleet visibility: working, support, credentials, and published vulnerabilities. Zero trust for camera fleets is using that inventory as the policy input this week. IDevID does not belong in the certificate column; the column is asking about the LDevID and the HTTPS certificate actually in service.

A camera that cannot meet the policy, because it cannot take current firmware or cannot hold an 802.1X certificate, is a replacement decision. Wisenet 5 era Hanwha, and any Axis or Bosch unit past the vendor’s firmware window, cannot fully join a program that requires a current factory identity and a current image. Writing the policy without the support column describes a fleet that no longer exists.

The control set that holds the policy is camera hardening: unique credentials, current firmware, valid certificates, closed management, an inventory that matches the floor. Hardening is the five controls. Zero trust is re-checking them against live identity and posture. A baseline checked last quarter is a historical fact. Tenet 4 needs this week’s firmware, certificates, and credentials.

What you can verify continuously, and what still takes a person

Continuous diagnostics, in 800-207 tenet 5, is measuring posture and applying fixes. On Axis, Bosch, and Hanwha hardware that is reachable, credential state, certificate validity, firmware eligibility, and whether the camera is still doing the job it was installed for can be checked without a site visit.

A bag on a dome, a turret knocked by a lift, a failed injector, and a camera that never had a factory identity because it predates the vendor’s secure element still take a truck or a replacement. What zero trust removes is sending that truck to discover the camera was in a planned certificate wave, and calling the fleet done because the recorders sit behind a login.

Doing this across 500 cameras

At ten cameras a technician can hold the three identities in a notebook. At five hundred cameras across mixed Axis, Bosch, and Hanwha generations the factory identity exists on some devices and not others, 802.1X expiries cluster by the week the site was commissioned, and the recorder still authenticates with a password every technician has written down. The VLAN still looks clean. None of the seven tenets is satisfied by that picture.

MentatNOC continuously watches those identities and that posture on every Axis, Bosch, and Hanwha camera you put under management: reachable apart from healthy, firmware eligibility, credentials, certificates, and the record of what changed. Passwords and certificates go out in staged waves with canaries and automatic rollback, including additive credential cutover so recording does not drop. What happened is written to an audit log built so entries cannot be rewritten after the fact. It monitors device health, not video. MentatNOC helps you prove those controls operated. It does not certify anyone. The write-side path is on firmware, password, and certificate actions. The fastest way to see a fleet scored this way is a live platform demo.

Camera fleet health, compliance, and proof. Three identities per camera, re-evaluated on a cycle, no trust from the VLAN. A camera that is up can still be the one with no factory identity, an expired client certificate, or last year’s password in every recorder.