field note
Axis camera firmware update failed: how to recover
An Axis camera firmware update that failed rarely bricks the camera. Work out which stage it failed at, confirm the real state, and recover without losing rollback.
2026-08-06
An Axis camera firmware update that failed almost never leaves you with a dead camera. AXIS OS is written to a second bank and only takes over once it verifies, so an upgrade that dies during the upload, the write, or the reboot leaves the previous firmware exactly where it was. The camera that genuinely does not come back is rare. What is common is the recovery attempt that turns a recoverable camera into a real problem. This post covers how to tell what actually failed, what to do for each cause, and which recovery steps to avoid.
Before anything else, confirm it failed
Most “failed” Axis upgrades are cameras that were still working. A firmware image of a few hundred megabytes takes minutes to upload, verify, write, and reboot, and the camera is unreachable for a good part of that. From the outside, a camera two thirds of the way through a successful flash is indistinguishable from one that died in the middle of it.
That matters because of how the rollback bank works. Starting a second upgrade purges the restore point created by the first one, including when the first one was seconds from finishing. An operator who fires a retry at a slow camera destroys its path back to the previous firmware and can interrupt a write that was going to succeed.
So the first step after an apparent failure is to wait out the full expected window, then ask the camera what version it is running rather than assuming. Three answers are possible:
- The new version. It worked. Validate and commit.
- The old version, camera healthy. The upgrade failed cleanly and rolled back. Diagnose before retrying.
- No answer at all. The camera is not on the network. That is a different problem, covered below, and it is still usually not a firmware problem.
Where it failed decides what you do
An AXIS OS upgrade runs through a fixed sequence, and the stage it stopped at tells you both what went wrong and how much recovery work you owe.
Upload. The image never fully reaches the camera. Network drops, a session that times out on a slow link, an interface that renegotiates mid-transfer. The camera is untouched.
Verify. The image arrives but does not check out. AXIS OS images are signed, and the camera validates both the signature and that the image belongs to this product before it writes anything. A truncated download, a corrupted file, or an image for the wrong model stops here. Again, the camera is untouched.
Write. The image is being written to the inactive bank. This is the stage people fear, and it is the stage where dual-bank handling earns its keep: an interrupted write leaves the active bank untouched, so a power cycle brings the camera up on the firmware it was already running.
Reboot. The camera restarts onto the new firmware. If the new firmware cannot come up, the camera falls back. An uncommitted upgrade also rolls back automatically on a power cycle, which is a safety net during validation and a trap if you leave a wave uncommitted over a weekend that includes a power event.
Commit. You accept the upgrade. The restore point, firmware plus the configuration snapshot taken when the upgrade started, survives the commit and stays available until the next upgrade begins.
The causes worth checking first
| Symptom | Likely cause | What to do |
|---|---|---|
| Upload stalls or times out | Link quality, switch renegotiation, a saturated uplink during business hours | Move the work to a maintenance window, upgrade fewer cameras per wave, upgrade from a host on the same site |
| Image rejected immediately | Wrong image for this model, or a corrupted download | Re-download from the model’s own page and check the published SHA-256 before it goes near a camera |
| Rejected on a camera that is several versions behind | A required intermediate release | Read that product’s release notes; a few older products must pass through a specific version before the target |
| Rejected when installing older firmware | Downgrades are not free | Downgrade flashing requires a hard factory default, and only the latest release on the 11.11 or 10.12 LTS tracks are legal targets |
| Fails on one model only, repeatedly | The model is not eligible for that track at all | Confirm the target against that model’s support page, not the family or the chip generation |
| Random failures across a wave | Power or PoE budget, not firmware | Check the switch’s PoE headroom and whether the cameras dropped during a reboot storm |
The wrong-image case deserves emphasis because it is quiet at small scale and expensive at large scale. Axis publishes a SHA-256 checksum next to every firmware download. Verifying it takes seconds and is the only thing standing between a corrupted or mismatched file and a hundred cameras receiving it in sequence. Which target version each model should be receiving in the first place is the subject of AXIS OS upgrade paths explained, and getting that wrong accounts for a good share of the failures above.
The camera came back, but something is wrong
A successful flash can still look like a failure, because the reboot exposes everything the camera was quietly carrying.
It answers, but returns 401 with known-good credentials. On AXIS OS 12.1 and later, a factory-defaulted camera changes its HTTP authentication policy: it accepts Basic over HTTPS and digest only on plain HTTP and RTSP. Upgraded-in-place cameras keep their old policy, so this shows up on exactly the cameras that were reset during recovery. Test Basic over HTTPS before you conclude anything about the account. The full diagnostic ladder for a camera rejecting a known-good credential is in Axis camera default password: what it is and is not.
It never rejoins the network on an 802.1X port. A factory default wipes the device certificate along with everything else. The switch port then refuses to authenticate the camera, so it never gets an address and reads as bricked when it is running perfectly well. Recovering it means an unauthenticated port, or a provisioning VLAN, and then reissuing the certificate. The wider problem of tracking those certificates is covered in camera certificates: expiry, 802.1X, and rotation.
It has a new IP address. A factory-defaulted camera goes back to DHCP. If your VMS references cameras by address rather than by identity, the camera is online and the recording is not.
Its clock is wrong. After a default, NTP configuration is gone. Timestamps drift immediately and quietly, and the footage keeps recording with the wrong time on it.
Every one of these follows from a factory default, which is why the default should be the last recovery step you take rather than the first.
When the camera really does not come back
Work the ladder in order, and stop as soon as the camera answers.
- Wait out the full window. Several minutes, not thirty seconds. Do not start a second upgrade.
- Power cycle once. An uncommitted upgrade rolls back on power loss, and an interrupted write leaves the previous firmware bootable. This step alone recovers most cameras.
- Confirm whether it is on the network at all. A camera that responds on its address but not in your management tool is a very different problem from one that never appears. Axis device discovery tooling will find units that have fallen back to a different address.
- Check the physical layer. PoE delivered, link light, correct VLAN, port not error-disabled. A camera that lost power mid-flash and a camera whose switch port shut down look identical from a console.
- Then, and only then, factory default with the control button. Understand what you are trading: configuration, certificate, NTP, addressing, and on 12.1 or later, the authentication policy. Plan to reprovision.
- Reflash the correct, checksum-verified image for that exact model.
- Escalate to Axis support for a unit that will not enumerate after a default. At that point it is a hardware conversation, not a firmware one.
The ladder exists because each rung costs more than the one before it. Most teams skip straight to step five and spend the rest of the afternoon rebuilding a camera that a power cycle would have fixed.
Preventing the next one
- Verify the checksum on every image, once, before the campaign starts.
- One canary per distinct model, validated in the VMS, before anything else moves.
- Waves small enough that a bad wave is an inconvenience, and spaced far enough apart to actually see problems.
- Never retry without confirming the camera’s real state first.
- Commit deliberately, and do not leave an uncommitted wave sitting over a weekend.
- Do the work in a window where power and network are stable, not during business hours on a shared uplink.
Doing this across 500 cameras
At ten cameras, the procedure above is a careful afternoon. At five hundred across a dozen sites, it becomes arithmetic. Waves and soak periods dominate the calendar far more than push speed does, and the firmware campaign planner works that math against your own fleet size and window length.
The failures themselves scale badly for a different reason: nobody is watching each camera closely enough to tell “still writing” from “died at the write.” That ambiguity is what produces the blind retry, and the blind retry is what turns a recoverable camera into a truck roll. MentatNOC pushes firmware in staged waves with canaries and automatic rollback, verifies every image’s integrity before it reaches a camera, and reports each device’s actual upgrade state rather than a guess, so a slow camera is never mistaken for a failed one. Authentication handling works on both sides of the 12.1 policy change, so a reset camera does not read as a credential failure. The write-side story is on the firmware, password, and certificate actions page, and the staged rollout runs end to end in a live platform demo.
Wait, confirm state, power cycle, then escalate. In that order, an Axis firmware update that failed costs you a few minutes. Out of order, it costs you a site visit.