MCUboot offers three ways to run a new image. Swap copies the new image into the primary slot and keeps the old one for revert. Direct-XIP runs the newest valid image from whichever slot holds it. RAM load copies the newest image to RAM and runs it there. The right pick depends on flash, speed and revert needs.
Slots first
The MCUboot design document describes each flash area as having a primary and a secondary slot. Normally the bootloader runs only from the primary slot. Direct-XIP and RAM load are the exceptions, where both slots are treated as equal.
Swap
In swap mode the new image is moved into the primary slot and the old image is kept in the secondary slot. An upgrade can be a test swap, which reverts on the next boot unless the application confirms the image, or a permanent swap. Swap progress is recorded so an interrupted swap can resume after a reset.
The document says swap using scratch may be removed in the future, and it prefers swap using offset over swap using move. If you are choosing today, read the current docs for your MCUboot version.
The cost is the copy time. Each upgrade rewrites flash, which takes a while and wears it.
Direct-XIP
Both slots are equal, and the bootloader runs the newest valid image from whichever slot has it, judged by version number. An invalid image is erased before the other slot is tried. Optional revert support exists behind a build option. There is no copy step, so boot after an upgrade is quick, and the document notes that image encryption is not supported in this mode.
RAM load
Again both slots are equal. The newest image is copied to the load address in its header, validated and executed there. The platform must define the RAM region, and images are signed with a load address. With image encryption enabled, images are decrypted in RAM before running. You need enough RAM to hold the image.
A quick decision guide
- Small flash, simple design, want automatic revert: swap, with test mode and a confirm step.
- Slow flash or tight boot-time budget: direct-XIP, if you can build for both slot addresses and do not need encryption in that mode.
- Execute from RAM anyway, or need decrypt before run: RAM load.
Whichever you choose, pair it with signature verification and rollback protection. The next question is how to stop an attacker installing an old, signed, vulnerable image, which is covered in security counter versus version number.
Quick check
Does swap mode support revert?
Yes. A test swap reverts on the next boot unless the image is confirmed.
Which mode supports image encryption?
The MCUboot document says direct-XIP does not support image encryption, and describes decrypting encrypted images in RAM for RAM load.
Where Safeguard fits
Safeguard does not replace a bootloader or a hardware root of trust. It covers the software side around them: SBOM and dependency scanning for the components that end up in your builds, policies and gates that block a risky release, and compliance evidence. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
