field note
AXIS OS upgrade paths explained: tracks, traps, and rollback
AXIS OS upgrade eligibility is per product, not per chip. How the active and LTS tracks work, the 12.1 HTTPS auth change, and the rollback rules that bite.
2026-07-31
AXIS OS upgrade paths are decided per product, not per chip: the only reliable way to know a camera’s firmware ceiling is that model’s own support page on axis.com. Two cameras with the same SoC can have completely different futures, and starting with AXIS OS 12.1 a factory-defaulted camera quietly changes how it authenticates over HTTPS. Both facts have burned experienced integrators. This post walks through how the tracks actually work, the two traps, and the rollback semantics you should understand before you flash anything.
How AXIS OS tracks work
Axis maintains one codebase but ships it on parallel tracks:
| Track | Current line | What it receives |
|---|---|---|
| Active | 12.x | New features plus security and stability fixes |
| LTS 2024 | 11.11.x | Security and stability patches only |
| LTS 2022 | 10.12.x | Security and stability patches only |
The active track is where new capability lands. Every couple of years Axis freezes a release into a long-term support (LTS) track, which then receives patches but no new features. A camera on an LTS track is not “behind” in any meaningful security sense as long as it is on the latest release within that track. That distinction matters for compliance reporting: “not on 12.x” is not a finding, but “three patch releases behind on its own track” is.
When you plan upgrades, the question is never “what is the newest AXIS OS.” It is “what is the newest release on the track this specific product is eligible for.” Which brings us to the first trap.
Trap one: track eligibility is per product, not per chip
It is tempting to reason from the hardware platform. ARTPEC-7 is a current-generation SoC, the camera is still sold or only recently discontinued, so surely it gets AXIS OS 12. Sometimes yes, sometimes no, and the chip tells you nothing either way.
A concrete pair: the AXIS P3727-PLE panoramic and the AXIS Q1615 Mk III both run ARTPEC-7. The Q1615 Mk III moved onto the 12.x active track. The P3727-PLE did not and never will: its ceiling is LTS 2024, meaning 11.11.x, with AXIS OS support running to the end of 2029. Same silicon, opposite outcomes. Axis decides track eligibility model by model, and the decision is published in exactly one authoritative place: the firmware section of that product’s support and downloads page on axis.com.
The practical consequences:
- Never plan a fleet upgrade from the chip generation or the product family. Check each distinct model against its own support page and record the track.
- A mixed fleet will have mixed ceilings. A site full of “current” Axis hardware can legitimately span 10.12, 11.11, and 12.x targets. Your patching standard has to be track-relative, not version-absolute.
- Discontinued does not mean unsupported. The P3727-PLE is discontinued (its successor is the P3735-PLE) yet still receives LTS 2024 patches for years. Retirement planning and patch planning are separate exercises.
If your firmware tracking lives in a spreadsheet, this is the column that goes stale silently. Axis can promote a model to a new track, or a new LTS can freeze, and your spreadsheet will not tell you.
Trap two: the 12.1 HTTPS authentication change
Starting with AXIS OS 12.1, the default HTTP(S) authentication policy on a factory-defaulted camera changed. Under the new “Recommended” default, the camera accepts Basic authentication over HTTPS and digest authentication only on plain HTTP and RTSP. Digest over HTTPS, the combination most tooling and most VMS integrations were built around, is rejected with a 401 even when the credentials are perfectly valid.
The trap has a second layer that makes it genuinely nasty:
- Upgraded cameras keep their old policy. Take a camera from 11.x to 12.4 in place and digest over HTTPS keeps working. Nothing appears broken.
- Factory-defaulted cameras get the new policy. The same model, same firmware, reset to defaults during a repair or a redeploy, now 401s the exact same client.
So the failure shows up unpredictably: one camera in fifty, always the one that was recently replaced or reset. We have verified this live on an M4218-V running 12.4.59: digest probes over HTTPS return 401, Basic over HTTPS returns 200, same account, same password.
The misdiagnosis is almost irresistible. A 401 with known-good credentials reads as “the account lost admin rights” or “the password rotation broke this camera,” and people burn hours resetting credentials that were never wrong. The rule worth memorizing: a 401 on an AXIS OS 12.x camera means try Basic over HTTPS before you conclude anything about the credentials.
Two closing notes on this one. Basic over HTTPS is fine cryptographically, since the credentials travel inside TLS, which is exactly why Axis made the change. And the policy is configurable today, but Axis has announced that AXIS OS 13, expected on the active track in September 2026, reworks how that setting is managed. OS 13 also enforces password complexity for new and edited accounts, with a minimum profile of 15 characters that cannot be disabled. If your tooling creates camera accounts, check your generated passwords against that now.
Rollback rules worth knowing before you flash
Axis dual-bank firmware handling is genuinely good, but the semantics are specific and the failure mode for misunderstanding them is losing your way back.
- The restore point is firmware plus a full configuration snapshot, created when an upgrade starts. Rolling back restores both, and it works even after you commit the new firmware.
- The restore point is destroyed by the next upgrade start. Including a failed one. Starting a second flash, for any reason, purges your path back to the previous state.
- An uncommitted upgrade auto-rolls back on power cycle. Useful as a dead-man switch, but it means you should validate and commit promptly, or a routine power event will silently undo your work.
- Downgrade flashing is not a rollback substitute. Flashing older firmware requires a hard factory default (full configuration wipe), and only the latest release on the 11.11 or 10.12 LTS tracks are legal targets.
The operational rule that falls out of the second point: never retry an upgrade that might still be running. Large firmware images take minutes to flash and verify, and a camera mid-reboot looks exactly like a camera that failed. If an impatient operator (or an impatient script) fires a second upgrade at it, the retry purges the rollback bank of a camera that was seconds from succeeding. Confirm the actual upgrade state before any retry, every time.
A sane upgrade procedure for an Axis fleet
- Inventory distinct models, not just camera counts. Track eligibility is per model.
- Check each model’s support page on axis.com and record its track and the latest release on that track. Firmware downloads sit behind a MyAxis sign-in; the page also publishes a SHA-256 checksum for each image.
- Verify the checksum of every downloaded image before it goes anywhere near a camera. This is your only defense against a corrupted or wrong-model image at scale.
- Flash a canary first. One camera per model, validated against your VMS and monitoring before anything else moves.
- Roll in waves, validate, then commit. Confirm streams, recording, and authentication behavior (especially on anything that was factory-defaulted) before committing each wave.
- Re-check credentials behavior on 12.1+. If a camera 401s after upgrade or reset, test Basic over HTTPS before touching the account.
Doing this across 500 cameras
Everything above is manageable for ten cameras and a free afternoon. Across hundreds of cameras and multiple sites, the manual version decays fast: the track spreadsheet goes stale, a reset camera 401s and eats an afternoon of credential archaeology, and someone eventually double-flashes a slow camera and loses its rollback bank.
How long the fleet-scale version actually takes, in maintenance windows, calendar weeks, and engineer hours, is a question with real arithmetic behind it: soak periods between waves dominate the calendar, and push speed barely moves it. The firmware campaign planner works that math for your fleet, and the firmware tracks reference holds the current per-track versions this post keeps telling you to look up.
This is the category of work MentatNOC automates. The platform knows every model’s track, flags the day a new release lands on it, verifies every image’s integrity before it touches a camera, and pushes firmware in staged waves with canaries and automatic rollback. Authentication handling works on both sides of the 12.1 policy change, so a factory-defaulted camera does not read as a credential failure. The full write-side story is on the firmware, password, and certificate actions page, and you can see the staged rollout flow end to end in a live platform demo.
Check the support page, respect the track, verify the checksum, and never flash twice without confirming state. Get those four habits right and Axis fleets upgrade uneventfully, which is the whole point.