Hanwha Wisenet firmware updates at scale

Hanwha Wisenet firmware updates are done in bulk from a management utility rather than one camera at a time, and the practical limit is the tool’s default of sixteen simultaneous upgrades with the rest queued behind them. That single number decides how long a campaign takes. The second number that matters is not published on any product page: Hanwha commits to cybersecurity firmware updates for up to five years after a model’s end-of-life and warranty date, which is the real answer to how long a Wisenet camera stays maintainable. This post covers both, and what to check before you start.

Firmware is grouped by series, not always by model

Some Wisenet models share a single firmware image across a series. The bulk update tool exposes this directly: alongside each camera’s current version it shows which series it belongs to, precisely because several models draw from the same image.

This is a different mental model from Axis, where eligibility is decided per product and two cameras on the same chip can have different ceilings. On the Wisenet side the grouping does more of the work, which means one download can cover a slab of your fleet, and it also means a model’s fate is tied to its series in ways the model number alone will not tell you. If you maintain a mixed Axis and Hanwha estate, your firmware standard has to describe both shapes. The Axis half is covered in AXIS OS upgrade paths explained, and the tier differences that decide which Wisenet models you are dealing with are in the Wisenet A, Q, X, and P series explained.

There are two supported ways to get the image itself: pull it through the management utility, which downloads current firmware directly, or download from the model’s product page. For a fleet, the first is the only one that scales, because it also tells you which cameras are behind before you have downloaded anything.

What a bulk upgrade actually does

The sequence is worth knowing precisely, because each step has a failure mode that shows up only at scale.

Discovery and credentials. The tool finds devices on the network, and the credentials it holds have to be right. A firmware status check across a large fleet will surface authentication prompts on any camera whose password has drifted from what the tool expects. At ten cameras that is a footnote. At five hundred it is the reason the campaign stalls before it starts, and it is a strong argument for knowing your credential state is clean going in. Rotation that left stragglers behind is the usual culprit, so clean up credentials as a separate exercise before the firmware campaign starts, never during it.

Status check. Every discovered camera reports its current version against what is available, so you get a list of what is actually behind rather than a guess. Do this before you plan the waves, not after.

Download. Any firmware you do not already hold locally is fetched first. Cameras sharing a series pull the same image, so the download count is smaller than the camera count.

The upgrade itself, and the number that governs everything. By default the tool upgrades up to sixteen devices simultaneously and queues the remainder, picking up the next camera as each one finishes. There is a sequential mode that does them strictly one at a time, and it takes substantially longer. There is also a scheduled start, which matters for after-hours work, with one condition attached: the program has to stay running for the campaign to proceed. A workstation that sleeps at 2am ends the campaign at 2am.

Reboot and confirmation. Each camera restarts and reports its new version back. That confirmation is what you check the wave against before releasing the next one.

Sixteen at a time is a reasonable default and it is also the entire capacity model. Five hundred cameras is not one operation, it is roughly thirty-one sequential batches with a reboot in each, run from a machine that must stay awake for the duration.

How long a Wisenet camera keeps getting firmware

This is the question nobody asks until an auditor does, and Hanwha does answer it, just not where you would look. The support policy states that Hanwha “provides users with cybersecurity-related firmware updates for up to 5 years after their EOL and Warranty date.”

Read that boundary carefully. The clock does not start when you bought the camera or when you installed it. It starts at the model’s end-of-life and warranty date, which is a property of the product, not of your purchase. A camera bought late in a model’s life inherits a support horizon that was already partly spent.

Three consequences follow, and all three show up in audits.

Warranty status is per unit and verified by serial number. Hanwha supports products under warranty regardless of EOL status, and agent-assisted support depends on that verification. Two identical cameras installed a year apart can sit on opposite sides of the line.

Out of warranty and EOL means self-service. Documentation and knowledge base only. Repair requests on out-of-warranty EOL hardware are at Hanwha’s discretion, and can be declined when parts are no longer available or the repair costs more than the product is worth.

The EOL list is published, and it is the document to check. Hanwha maintains a complete list of discontinued products. That list, plus the five-year rule, plus each camera’s own warranty status is the whole calculation. There is no single page that does it for you, which is exactly why fleets get this wrong.

For anyone writing a maintenance standard: “supported” for a Wisenet camera has two tiers, and a camera receiving cybersecurity firmware but no agent-assisted support is in a genuinely different position than one still in warranty. Auditors accept both. They do not accept “we assumed it was still getting updates.”

Before you start a Wisenet campaign

1. Run a firmware status check across the whole fleet first. Plan from what is actually behind, not from what you think is deployed.
2. Fix credentials before you fix firmware. Authentication prompts during a bulk run are the single most common reason a campaign stalls.
3. Check each distinct model against the discontinued list, and record whether it is inside or outside its five-year window. This is the column that quietly goes stale.
4. Size waves against sixteen at a time. The default concurrency, not your camera count, sets the calendar.
5. Do not schedule a run on a machine that sleeps. The utility has to keep running for the queue to drain.
6. Validate a canary per series before the rest of that series moves. Series grouping means one bad image reaches a lot of cameras quickly.

Doing this across 500 cameras

The arithmetic is the part people underestimate. Sixteen concurrent upgrades, a reboot each, a validation pause between waves, and a workstation that has to stay awake through all of it turns into more maintenance windows than anyone budgeted. The firmware campaign planner runs that math against your fleet size and window length before you commit to a date.

The support horizon is worse, because it decays silently. Nothing on the camera announces that its model went EOL two years ago, and nothing warns you when the five-year cybersecurity window closes on a device still recording quietly in a stairwell. MentatNOC tracks each model’s status and each camera’s version continuously, pushes firmware in staged waves with canaries and automatic rollback, verifies every image’s integrity before it reaches a camera, and reports the fleet’s real state rather than the state of a spreadsheet. The write-side detail is on the firmware, password, and certificate actions page, and the staged rollout runs end to end in a live platform demo.

Check the discontinued list, confirm the warranty status, size the waves against sixteen, and keep the workstation awake. Wisenet fleets update cleanly when those four are handled and drift badly when they are not.