field note
Camera fleet visibility
Camera fleet visibility is knowing per camera what is working, past support, on a shared password, or on a published CVE. How to assemble that list.
2026-09-01
Camera fleet visibility is knowing, per camera, what is working, what is past vendor support, what is still on a default or shared password, and what is sitting on a published vulnerability. A down-icon answers the first question and only the first. A camera can be recording this minute and still be the one an insurer, an auditor, or an incident will land on.
The list has to come from the devices. A commissioning spreadsheet is a snapshot of the day someone typed it. Visibility is that list, kept current, with four columns filled in. It monitors device health, not video.
Four questions, one inventory
| Column | What it asks | A yes that still fails |
|---|---|---|
| Working | Reachable, powered, still doing the job it was installed for | The web page answers. The recording or detection path has been dead since March |
| Support | Newest firmware this model is eligible for, and whether the vendor still publishes any | The image is fine. The last firmware shipped years ago |
| Credentials | Unique, known, rotated, still matching every consumer | No factory default on current Axis, Bosch, and Hanwha. One shared admin password across the estate |
| Published vulns | Advisories that apply to this model and firmware, and whether CISA has listed any as exploited | The camera is up. The version it runs is named in an advisory |
Camera fleet posture is those four answers on every device, the same week. A program that only watches uptime will report a healthy fleet that is full of end-of-life hardware, shared passwords, and unpatched CVEs.
What is working
Working means the camera is reachable and still doing the job it was installed for: recording, detection, or both. An address that answers is the shallowest check. A camera can serve a web page while the recording path has been dead for weeks. A camera can be recording while aimed at a wall, bagged after paint, or so far out of focus that the scene is gone.
Health monitoring that cannot tell reachable from healthy will file those as up. Visibility that stops at ping will too. The recovery is different in each case: a switch port, a storage failure, and a bag on a dome are three tickets. Treating them as one red dot sends the wrong truck, or none.
What is past support
End of life and end of support are vendor facts, not a vibe about the picture quality. A camera can still produce a usable image after the vendor has stopped publishing firmware. That is a replacement decision sitting in a health column that still says up.
The three vendors MentatNOC supports answer the question in structurally different ways. The current versions, tracks, and lifecycle flags for common models are the camera firmware tracks reference. The shape, so the column is not a guess:
Axis. Eligibility is per product, across an active track plus long-term support tracks. Axis publishes an end-of-support date on each product page and commits to software support for at least five years after discontinuation. Two cameras that look identical can have different ceilings.
Bosch. Firmware ships per Common Product Platform, one current version per platform. A part number does not encode the platform. Platforms move through published stages: feature development, then maintenance, then security fixes only, then end of service, with month-level dates. A camera on an end-of-service platform is not behind. It is done.
Hanwha. Firmware is grouped by series or family. Hanwha states a policy of security firmware for up to five years after end of life and publishes no per-model dates. “Current” for a Hanwha camera is the latest binary that family will take, not a date you can put on a replacement spreadsheet without a policy of your own.
A version string in last year’s as-built is a fact, not a status. Visibility has to know what this camera is eligible for, and whether anything is still being published for it.
What still has a default or shared password
Current Axis, Bosch, and Hanwha cameras do not ship a factory password. You set the first credential when you reach the device. The per-model lookup is camera default passwords by model. Circulating credential lists for current Axis hardware are either about long-discontinued products or simply wrong.
The live fleet problem is almost never a printed default on those three brands. It is one shared admin password across hundreds of cameras, known to every technician who has ever been on site, unchanged since commissioning. It is also the older or unsupported camera that still answers on a documented default, which is how unnamed hardware becomes the foothold.
A camera that rejects a password you believe is correct is often not a credential problem. On recent Axis firmware, a factory-defaulted device changes how it accepts authentication. Treating that as “reset the password” costs a truck and a rebuild. Visibility has to tell unique-and-rotated apart from shared, and shared apart from “this device never had a factory default to find.”
Rotation that succeeds on the camera and breaks every recorder that consumes it is how fleets stop rotating. The credential column is not complete until the consumers still authenticate.
What is sitting on a published vulnerability
A published CVE means the vendor documented a weakness. A CISA Known Exploited Vulnerabilities (KEV) row means CISA has evidence it has been exploited somewhere. Whether it applies to a fleet depends on vendor, product, the firmware actually running, and whether the management path is reachable.
The camera CVE tracker is that table: Axis, Bosch, and Hanwha advisories merged with the camera-shaped slice of KEV, flagged for exploited-in-the-wild status. Axis, Bosch, and Hanwha publish camera CVEs. CISA currently lists none of those three as camera KEV rows. That is a statement about KEV, not a claim those products have no vulnerabilities.
Unsupported brands appear in KEV when CISA adds them. They do not belong in a “we support this” column. They belong in a named exception: isolate, replace, or refuse, with a date.
Matching an advisory to a camera requires the model and the firmware from the inventory. A CVE tracker without that inventory is a reading list. An inventory without the tracker is a list of cameras you cannot score.
How to assemble the list
The build order is the same every time. Skip a step and a column stays empty.
- Inventory from the devices. Make, model, current firmware, location, network identity, the track or platform the vendor uses. Key it the way firmware is decided, or the support column will be wrong.
- Fill working. Reachable apart from healthy. Recording or detection still happening, not only a web page.
- Fill support. Eligible version, lifecycle stage, whether any firmware is still published. Use the vendor’s rule, not a single “current” number for the whole fleet.
- Fill credentials. Unique per device, rotation age, whether every consumer still authenticates. Default vs shared vs never-had-a-default are three different answers.
- Fill published vulns. Model plus firmware against vendor advisories and KEV. A match is a named exception, not a red banner on the whole brand.
- Name an owner and a next action per row. Working failures become tickets. Support-ended cameras become a replacement list. Shared passwords become a rotation wave. KEV-yes firmware becomes a campaign or a removal. A column with no owner is a report.
Ten cameras do not need a product to hold this. A technician who knows the building can. The list becomes a program when the estate has more than one vendor, more than one site, and a week in which something publishes, expires, or gets swapped without the spreadsheet moving.
Doing this across 500 cameras
At five hundred cameras the four columns drift on different clocks. Uptime changes when a switch port dies. Firmware baselines move when a vendor publishes. A shared password is still shared until someone rotates it in the right order. A KEV row can be years old and still show up the month CISA adds it. A spreadsheet that was true on Monday is a hypothesis by Friday.
MentatNOC continuously watches those columns on every Axis, Bosch, and Hanwha camera you put under management: reachable apart from healthy, firmware eligibility and lifecycle, credentials, and the record of what changed. Firmware, passwords, and certificates go out in staged waves with canaries and automatic rollback. What happened is written to an audit log built so entries cannot be rewritten after the fact. It monitors device health, not video. Brand lookup for firmware and defaults, and the published-CVE table, stay on the resource pages above. The platform holds the fleet’s own rows. The layers are on the platform. The fastest way to see a fleet scored this way is a live platform demo.
Camera fleet health, compliance, and proof. One inventory, four columns, an owner per row. A camera that is up can still be the one that is past support, still on last year’s password, or named in an advisory. Visibility is knowing which.