# Lanzaboote Secure Boot and Measured Boot for NixOS

> Lanzaboote adds UEFI Secure Boot and TPM-backed Measured Boot support to NixOS. Its main distinction is a UKI stub that keeps the kernel and initrd separate, reducing EFI System Partition pressure for systems with multiple boot configurations.

**nix-community/lanzaboote** — Secure Boot & Measured Boot for NixOS [maintainers=@blitz @raitobezarius @nikstur]

- Repository: https://github.com/nix-community/lanzaboote
- Website: https://nix-community.github.io/lanzaboote/
- Stars: 1,903 · Forks: 119
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nix-community-lanzaboote

## Lanzaboote's NixOS Boot Security Role

Lanzaboote targets a specific gap in NixOS boot management: boot loaders, kernels, and initrds already exist as signed artifacts, but they still have to be assembled into a Unified Kernel Image and placed on the EFI System Partition. Its `lzbt` command handles that path. According to the README, the application accepts a NixOS bootspec document, signs the relevant files, creates a UKI with the Lanzaboote stub, and installs the UKI and supporting files on the ESP. It also accounts for multiple NixOS generations and signs every configuration that should remain bootable.

The intended users are NixOS operators who need UEFI Secure Boot or TPM-backed Measured Boot. Secure Boot uses signatures across the boot chain so that a trusted component transfers control only after checking the next component. Lanzaboote can also participate in Measured Boot, where TPM measurements bind secret release to an expected boot policy. This matters for encrypted systems because, as the README explains, a LUKS volume key can be released only when its measurements match the configured policy.

The two mechanisms are related but separate. Secure Boot can be used without relying on a TPM measurement policy, and the README says Measured Boot is compatible with Secure Boot but can also be used without it. Lanzaboote therefore addresses two different trust questions: whether a boot component is authorized by signature, and whether the measured sequence of components satisfies policy.

## Inside the Lanzaboote UKI and ESP Layout

A conventional UKI approach packs the Linux kernel and initrd into one EFI image. The README identifies `systemd-stub` as the usual stub for this format. When every NixOS configuration needs its own UKI, a machine with many generations accumulates large images on an EFI System Partition whose space is limited. That is a boot-image size and partition-capacity problem, not merely a file management inconvenience.

The Lanzaboote stub changes the layout. The kernel and initrd remain separate files on the ESP, while the signed UKI carries the connection needed to load them. According to the README, the trust chain is preserved by validating the kernel signature and embedding a cryptographic hash of the initrd in the signed UKI. A matching hash establishes that the external initrd corresponds to the signed boot artifact.

This design gives each NixOS generation its own UKI without requiring the kernel and initrd to be embedded in every UKI. It also creates a deliberate dependency: the boot configuration is split across several files, and a missing or mismatched component can prevent the expected boot path. Operators must therefore treat the UKI, kernel, initrd, signatures, and ESP contents as one boot set rather than as unrelated files.

Lanzaboote also has a narrow `fwupd` integration. When Lanzaboote and `services.fwupd` are enabled, a `preStart` hook ensures that a signed `fwupd` binary is placed in `/run` for `fwupd.service`. The README does not explain the signing policy, certificate workflow, or failure behavior for this integration.

## Secure Boot Keys, Measured Boot Policy, and Recovery

Installing a Secure Boot tool is not enough by itself to establish the security property an operator expects. The README lists three additional requirements: a BIOS password or similar restriction that prevents unauthorized changes to Secure Boot policy, integrity protection for the booted system, and current firmware. Lanzaboote documents boot-image signing, but it explicitly leaves those wider controls outside the scope of its README.

Measured Boot has separate operational obligations. The root volume needs encryption configured with secure options, the setup must protect against confusion attacks, and attended systems should ideally use a PIN. The README also tells operators to back up a passphrase or recovery key so a brittle TPM does not become a direct path to data loss. None of these steps are implemented or explained in the README, so a complete adoption decision must include the external documentation and the machine-specific encryption setup.

The repository is licensed under GPL-3.0. That identifies the project's license, but the README does not explain how it applies to generated boot artifacts, key files, modified configuration, or distribution of binaries. Code copying, modification, and redistribution therefore require a separate license review. This article does not provide legal advice or assume that every file on the ESP inherits or does not inherit a particular treatment.

## Setting Up Lanzaboote from the Published Documentation

The README does not provide a complete copy-and-paste installation command, NixOS module declaration, hardware preparation sequence, or first-boot checklist. It directs users to the project's documentation at `https://nix-community.github.io/lanzaboote/` and states that Secure Boot and Measured Boot become available by adding the project to a NixOS configuration. It also says the implementation relies on `bootspec`, which has been enabled by default since NixOS 23.05.

Because the exact configuration keys are not present in the README, inventing a snippet would risk producing an unusable setup. A first real use should follow the linked documentation for declaring Lanzaboote, selecting or generating the relevant keys, building the NixOS configuration, and rebooting into the generated boot configuration. The expected visible result, based on the README, is a signed Lanzaboote-created UKI and its associated files installed on the ESP.

After that build, the first boot is where the architecture can be checked in practice. An operator needs to determine whether firmware accepted the signed image, whether the selected NixOS generation appeared, and whether the separately stored kernel and initrd were loaded. For Measured Boot, TPM policy behavior must also be verified through the chosen release policy. The README describes these components, but it does not provide firmware-specific troubleshooting commands or expected log output, so the repository overview cannot prescribe them.

## Lanzaboote's Storage Trade-off and Failure Boundaries

The separate-file UKI layout is the strongest project-specific design choice in the README. Embedding a kernel and initrd in every configuration produces large UKIs, while Lanzaboote signs the UKI and keeps the external files smaller. This favors systems with multiple NixOS generations and constrained ESP capacity.

That design also has boundaries. The initrd is not embedded. Its integrity is represented by a hash in the signed UKI, so the hash calculation and loading sequence must remain consistent. The README does not document recovery behavior when an ESP contains an old UKI, an absent generation, an unbootable configuration, or a mismatched initrd. It also does not document rollback. Those cases require checking the documentation and validating the installed boot entries before relying on the tool.

A fully self-contained UKI is another possible requirement. `systemd-stub` supports the common packed-image model, which Lanzaboote explicitly uses as its comparison point. If an operator requires kernel and initrd to travel as one file, or wants the most direct use of `systemd-stub`, Lanzaboote's size optimization is not an advantage.

The platform boundary is equally important. The funding section refers to additional work for architectures and PKCS#11 workflows, but the README does not identify which architectures are currently supported. Firmware behavior, key storage, TPM policy handling, and architecture coverage must therefore be verified in the project's documentation before rebuilding a production machine.

## Lanzaboote Compared with systemd-stub UKIs

The clearest documented alternative is a UKI built with `systemd-stub`. Both approaches place the kernel and initrd behind a UEFI application stub and are presented within the same Secure Boot and Measured Boot context. The difference is packaging. `systemd-stub` requires the kernel and initrd to be packed into each UKI. Lanzaboote stores them separately and binds the initrd to the signed UKI through an embedded cryptographic hash.

This is not a difference in the basic goal. It is a trade-off between image portability and ESP usage. Packed UKIs keep the boot components together, which can simplify copying as one artifact. Lanzaboote reduces the size of the per-generation image and avoids consuming kernel and initrd storage repeatedly inside every UKI. The choice is clearest for machines with several boot configurations, but the README does not quantify the exact space saved for a particular kernel, initrd, filesystem overhead, or ESP size.

Measured Boot remains an associated workflow rather than a reason to assume that either packaging choice alone protects secrets. The README says the TPM measurements must be bound to a security policy and that root encryption and confusion-attack protections require additional configuration. A comparison should therefore include the complete policy and recovery design, not just UKI construction.

## Lanzaboote Release Activity and Upgrade Surface

The repository is not archived, and its last push was on 2026-10-15. Recent releases include `v1.2.0` on 2026-09-26, `v1.1.0` on 2026-06-22, and `v1.0.0` on 2025-12-10. These facts support recent project activity, but the README does not provide a compatibility matrix, migration guide for each release, or long-term support policy.

For a boot-security component, an upgrade can affect signed artifacts, UKI layout, TPM policies, key handling, firmware interaction, and installed generations. The repository includes `CHANGELOG.md`, `docs/`, Nix files, Rust sources, and examples, based on its layout, but the README does not state what an operator must regenerate or revalidate after upgrading. `lzbt` is described as signing every configuration that should be bootable, yet the README does not say whether it removes stale UKIs or files belonging to obsolete generations.

That makes the upgrade cost procedural rather than merely computational. A production adoption should compare release notes, preserve recovery access, rebuild rather than assume in-place compatibility, and confirm that both the current and intended recovery boot paths remain available. The key question is whether the exact deployment is covered by the project's release documentation.

## Conclusion

NixOS operators who need Secure Boot or policy-bound TPM secret release should evaluate Lanzaboote, especially when several boot generations make embedded UKIs costly. Systems that need a fully self-contained boot image or require a documented one-command setup in this repository should look elsewhere. Before adoption, verify the installation procedure in the linked Lanzaboote documentation, firmware support, key management, recovery planning, and the final UKI and TPM measurements on the target machine.

## FAQ

### What does Lanzaboote do for NixOS?

Lanzaboote provides tooling for UEFI Secure Boot and TPM-backed Measured Boot. Its `lzbt` command signs NixOS boot components, creates a UKI, and installs the result and supporting files on the EFI System Partition.

### How does the Lanzaboote UKI handle the kernel and initrd?

The kernel and initrd are stored separately on the ESP rather than packed into the UKI. The signed UKI validates the kernel and embeds a cryptographic hash of the initrd to maintain the boot trust chain.

### Does Lanzaboote work with Measured Boot without Secure Boot?

Yes. The README says Measured Boot is compatible with Secure Boot but can also be used without it. It still requires TPM measurements, a matching security policy, and secure root-volume configuration.

## Sources

- [License: GPL-3.0](https://github.com/nix-community/lanzaboote/blob/master/LICENSE)
- [nix-community/lanzaboote on GitHub](https://github.com/nix-community/lanzaboote)
- [Project website](https://nix-community.github.io/lanzaboote/)
- [README](https://github.com/nix-community/lanzaboote/blob/master/README.md)
- [Releases](https://github.com/nix-community/lanzaboote/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nix-community-lanzaboote