Arm-powered devices now run everything from hobbyist projects to cloud servers — and many of them need the kind of firmware-level protection that Secure Boot provides. But unlike the x86 PC world, where UEFI Secure Boot is largely a solved problem, the Arm64 landscape remains a patchwork. Some Linux distributions boot seamlessly with Secure Boot enabled; others require manual key enrollment or fail outright. The difference often comes down to which system-on-chip is inside your device and whether the firmware plays along.

This guide cuts through the confusion, breaking down what actually works today, where the pitfalls lie, and how to get Secure Boot running on your Arm hardware.

The Hardware Lottery: Why Your Arm Board Dictates the Experience

On x86, nearly every consumer motherboard ships with Microsoft’s Secure Boot keys preloaded in firmware. That’s what lets Linux distributions boot without complaint after a simple shim hand-off. On Arm, there is no such standardization. Arm Holdings licenses its chip designs to dozens of manufacturers — Qualcomm, Rockchip, Broadcom, NXP, and many others — and each builds its own firmware. Some provide UEFI; many do not.

As The Register noted in a September 2025 analysis, u‑boot remains the de facto boot loader for most Arm single‑board computers. Modern u‑boot can implement UEFI interfaces and enforce Secure Boot, but it ships with an empty key database. You must generate and enroll your own keys, then sign every boot component — shim, GRUB, kernel — yourself. That’s a far cry from the “it just works” experience on x86 machines.

There is, however, a brighter path. Community‑driven EDK II UEFI ports now exist for popular platforms like the Raspberry Pi 3/4 and Rockchip RK3588‑based devices. These firmware images provide a conventional UEFI graphical interface, standard variable storage, and — crucially — the ability to chain‑load your OS from a familiar environment. For RK3588 boards, the EDK II port even supports ACPI, PCIe, and networking alongside Secure Boot hooks. When these firmware images are installed, the Arm Secure Boot story starts to look a lot more like the PC one.

Distribution Readiness: Who Ships a Microsoft‑Signed Shim on Arm64?

Even with UEFI‑compatible firmware, your Linux distribution must provide a boot chain that the firmware trusts. The industry standard approach is to use shim — a small, Microsoft‑signed EFI binary that validates a distribution’s bootloader. On x86, all major distros ship a shim signed by Microsoft’s UEFI CA. On Arm64, the picture is mixed.

Ubuntu and Debian: Ready out of the box

Both Ubuntu and Debian package arm64 builds of shim and GRUB that carry Microsoft signatures. On hardware with firmware that already trusts Microsoft keys (for example, devices using an EDK II image or boards where the vendor preloaded them), Secure Boot “just works.” Ubuntu’s official documentation details the shim‑signed and grub‑efi‑arm64‑signed workflow, making it the closest thing to a plug‑and‑play experience.

SUSE and openSUSE: Similar confidence

The SUSE family also invests in signed shim binaries for AArch64. Reports from the community suggest that openSUSE Tumbleweed and SUSE Linux Enterprise Server for Arm can boot with Secure Boot enabled on properly equipped hardware, mirroring their x86 counterparts.

Fedora and RHEL: A more complicated story

Fedora’s x86 builds have long included a Microsoft‑signed shim, but the Arm64 variant has lagged. Mailing list discussions and bug reports confirm that Fedora’s arm64 shim was not historically signed by Microsoft, forcing users to disable Secure Boot or enroll their own keys. Fedora maintainers are aware of the gap and are working on signing infrastructure, but as of late 2025, a signed arm64 shim is not guaranteed in every release.

Red Hat Enterprise Linux takes a different approach entirely. RHEL’s shim is signed with a Red Hat‑owned certificate, not a Microsoft one. On x86 this works because Red Hat also enrolls its own CA into the firmware’s Machine Owner Key (MOK) list during installation, but the same automated step may not be present on Arm64 deployments. Consequently, RHEL‑based systems on Arm often need Secure Boot disabled during installation, followed by manual key import. CentOS Stream and AlmaLinux — both derived from RHEL sources — generally ship a Microsoft‑signed shim, giving them a more straightforward experience on consumer‑grade Arm hardware.

Before installing any distribution, check the signature on the shim package (look for shim‑aa64 or shim‑signed) with sbverify. If the output doesn’t show a Microsoft certificate, expect extra steps.

What Secure Boot Actually Protects (and Where It Falls Short)

Secure Boot prevents unsigned or incorrectly signed bootloaders, kernels, and drivers from loading. That blocks many bootkits and rootkits cold. But it’s not a silver bullet. Two systemic weak spots have emerged on Arm:

  • Key lifecycle risk: The Microsoft UEFI CA certificate that signs shim is nearing expiration. On x86, firmware updates are relatively routine; on Arm, embedded boards often go years without a firmware refresh. If your device’s firmware doesn’t receive an updated key database, a perfectly valid shim could be rejected in the future.
  • SBAT and revocation complexity: The Secure Boot Advanced Targeting mechanism lets distros blacklist known‑vulnerable components. But applying SBAT updates requires coordinated changes to both firmware variables and OS packages — a fragile choreography that even x86 systems have stumbled over, as seen when Windows firmware updates accidentally broke Linux’s SBAT chain.

Secure Boot also doesn’t inspect the behavior of signed software. A signed but exploitable GRUB remains dangerous. Therefore, Secure Boot should be viewed as one layer in a defense‑in‑depth strategy, not a standalone guarantee.

Step‑by‑Step: Enabling Secure Boot on Your Arm Device

The exact procedure depends on your firmware path.

If you’re using a community EDK II UEFI image (e.g., Raspberry Pi 4, RK3588)

  1. Flash the EDK II firmware onto an SD card or to the board’s SPI flash, following the port’s documentation.
  2. Boot into the UEFI front page. Under “Device Manager” → “Secure Boot Configuration,” enroll the default keys or your own PK, KEK, and db certificates.
  3. Install a distribution that includes a Microsoft‑signed shim, such as Ubuntu or openSUSE. The installer should proceed without Secure Boot errors.
  4. After installation, verify the chain with mokutil --sb-state.

If you’re limited to u‑boot without a UEFI GUI

  1. Generate signing keys with OpenSSL or a dedicated tool like efitools.
  2. Enroll the Platform Key (PK), Key Exchange Key (KEK), and db into u‑boot’s UEFI variables using eficonfig or by writing to the environment directly.
  3. Sign shim, GRUB, and the kernel using sbsign or your distribution’s signing utilities.
  4. Configure u‑boot to load the signed shim as the first UEFI application.
  5. Test the boot with Secure Boot enabled; if it fails, use efivar to inspect the db content and verify signatures.

For both paths, keep your private keys offline and preferably stored in a hardware security module if this is being done at scale.

The Enterprise Angle: Key Management and Supply Chain Risks

IT teams deploying Arm servers — Cavium, Marvell, Ampere, or NVIDIA BlueField DPUs — face an additional burden. Unlike consumer boards, these platforms often have vendor‑provided EDK II firmware and can support Secure Boot from the factory. But that does not mean they ship with Microsoft keys. Enterprises must:

  • Audit hardware: inventory whether each device has UEFI, which keys are enrolled, and whether the firmware allows remote key updates.
  • Negotiate with vendors: demand documented Secure Boot flows, firmware update SLAs, and support for custom key enrollment and revocation.
  • Build a signing pipeline: integrate kernel, module, and bootloader signing into CI/CD, mirroring the model used for cloud‑native OSes like Flatcar or CoreOS.

The operational overhead is real. Without automation, rotating signing keys or responding to an SBAT revocation can take hours per device — impractical at datacenter scale. Start planning for that now, not when your existing certificates expire.

What’s Next: Key Expiry, Vendor Adoption, and the Slow March to Uniformity

Several developments will shape the Arm Secure Boot landscape over the next two years.

  • Microsoft CA transition: The replacement of the current signing key is underway. Distributions that rely on Microsoft‑signed shims will need to coordinate updates, and firmware vendors must push new db entries. Keep an eye on your distribution’s security advisories for SBAT and DBX updates — especially if you manage fleets of Arm devices.
  • EDK II proliferation: The RK3588 EDK II port is a bellwether. As more SoC vendors adopt or support mainline EDK II, the “chain‑load to UEFI” model could become standard, with manufacturers eventually shipping UEFI firmware directly. Watch the edk2‑platforms repository and vendor announcements.
  • Distribution convergence: Fedora’s push for arm64 signing parity is likely to succeed eventually, and RHEL might reconsider its key‑management strategy if enterprise customers demand seamless Secure Boot on Arm. Until then, check your chosen distro’s latest release notes before committing.

Arm Secure Boot is no longer a missing feature — the building blocks exist. But it remains a “some assembly required” experience. With the right hardware and a bit of prep work, you can achieve the same boot‑time integrity you’d expect on a PC. If you pick a board with a supported EDK II firmware and a distribution that ships a Microsoft‑signed arm64 shim, the process can be nearly invisible. For everything else, arm yourself with signing tools and a solid understanding of UEFI key management.