A/B system update is a controlled update method that keeps two system partitions or images, with one active and one inactive. The device boots from the inactive copy after the update, so a failed installation can be rolled back by returning to the known-good version.
How A/B system updates work
An A/B system update keeps two bootable system partitions or images. One copy stays active while the other is updated in the background, then the device switches to the newly written copy after validation or reboot.
This model is designed to reduce downtime and make update failure less disruptive. Because the previous version remains available, the system can fall back to a known-good state if installation or first boot of the updated image fails.
Why A/B updates are used
The main value of A/B update design is resilience during software delivery. It is common in devices that must stay available, recover quickly, or tolerate interrupted updates, because the update process does not need to overwrite the running system in place.
A/B is especially useful when a bad package, power loss, or boot regression would otherwise leave the device unable to start. In those cases, the inactive partition acts as a recovery path rather than a temporary staging area only.
Security implications of the rollback model
A/B updates improve availability, but they do not by themselves prove that the new image is trustworthy. The security value depends on update authenticity, boot integrity, and whether the device can detect tampering before it commits to the new image.
Where update verification is weak, attackers may try to introduce a malicious image, force a rollback to a vulnerable version, or exploit the gap between staging and activation. The partition model protects continuity, but the surrounding update trust chain still determines whether the device actually boots safe software.
For readers looking at update trust chains in depth, The Update Framework Guide covers the root-of-trust, verification, and rollback protections that strengthen secure software delivery.
What organizations should verify
Teams should confirm that both partitions are included in asset inventory, update orchestration, and recovery planning. It is not enough to know that A/B exists, they also need to know which image is active, which one is staged, and how version state is recorded after each switch.
They should also validate the integrity of the inactive image before activation, not only after the reboot. In connected-device environments, this often means pairing the update mechanism with signed packages, measured boot or similar trust checks, and clear procedures for handling failed updates and repeated rollback events.
For vehicle and embedded deployment contexts, the UNECE R156 Software Update Management System Guide is a useful reference for update governance and controlled deployment, while the Connected and Autonomous Vehicle Security Guide places OTA update security in a broader operational context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain integrity and provenance | A/B updates depend on trustworthy artifact delivery and integrity validation. |
| Recommendation — Verify update artifact provenance before allowing a new image to activate. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | A/B updates rely on integrity checks before newly staged software is trusted. |
| CM-3 — Configuration Change Control | Partition-based updates are a controlled change process that must be authorized and tracked. | |
| Recommendation — Apply SI-7 to validate staged images before booting the updated partition. Use CM-3 to govern image replacement, activation, and rollback decisions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | A/B update behaviour depends on hardened, known-good software states and recovery baselines. |
| Recommendation — Maintain known-good baselines for both partitions and verify them after each update. | ||
Practitioner Guidance
Why practitioners should care: A/B update design is only as safe as the controls around image signing, boot validation, and rollback handling. If those controls are weak, the mechanism can preserve uptime while still preserving a compromised or vulnerable state.
What to watch for: Repeated fallback to the old partition, unexplained version reversions, and devices that boot successfully only after multiple attempts can indicate update integrity problems, failed activation, or tampering in the update path.
Practitioner takeaway: Treat A/B as a recovery architecture, not a security guarantee. The update process still needs trustworthy verification, operational visibility, and a clear decision on when rollback is safe versus when it could reintroduce known exposure.
Related resources from NHI Mgmt Group
- What should security teams do first when a Windows sensor update causes widespread system crashes?
- What should Mac security teams do first when a system update fixes a password logging bug?
- What happens when a phishing or update-based infection lands on a system with outdated protections?
- What happens when a malicious app is installed through a compromised system app update channel?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org