Trust at every layer: How sealed images extend OS integrity from boot to runtime

Consider a medical device running Linux in a hospital. It processes patient data, adjusts dosing, and reports to clinical systems. Or an ATM on a street corner, processing transactions around the clock. Or a gateway device at the edge of a manufacturing network, relaying sensor data from the factory floor. The operating system (OS) on each of these was verified when it was installed. But is every binary and library still exactly what was built? If you would demand that guarantee for a device in an operating room or on a factory floor, why not expect the same from the servers running your business?

The gap in your boot chain

Typically, a default generic operating system install comes "unlocked", allowing you to be root on your computer and make persistent changes. So while a generic Red Hat Enterprise Linux (RHEL) or Debian install supports secure boot, it's typically only the kernel that's signed. The cryptographic chain of trust from firmware doesn't cover the root filesystem or apps. But for organizations that want to make "appliances", it's possible to increase security by chaining from secure boot to integrity of the operating system, using custom signatures.

From container workflows to OS integrity

Most organizations already build, sign, and ship container images through CI/CD pipelines. Every container pull verifies a cryptographic digest. Every time a new container starts, the runtime confirms the image matches what was signed. Organizations already trust this model for their applications.

Image mode for RHEL brings that same container workflow to the operating system itself. Instead of installing and configuring an OS by hand or through scripts, you define it in a Containerfile (or another compatible OCI buildsystem), build it as a container image, and deploy it with bootc. The OS becomes a versioned, reproducible artifact that moves through the same pipeline as your applications. Updates are atomic. Rollback is built in. Every deployed system runs the image you built, and you can trace that image back to the build system that produced it.

Enabled by image mode, sealed images take this one step further. The OS image you built and signed is now cryptographically verified from firmware through runtime. You are not adopting a new process. You are extending one you already trust, from your applications into the OS layer.

How it works

Secure boot and a signed unified kernel image already verify the boot chain: Bootloader, kernel, initramfs. Sealed images extend verification into the immutable OS image itself, with file-level precision. Using composefs and fs-verity, a cryptographic digest of the OS container image is embedded directly in the signed UKI at build time. At runtime, every file you or your team added to that image is individually verified against that digest. The system refuses to load any OS file that does not match. If something has been modified, corrupted, or replaced after the image was built, the kernel returns an I/O error. The file is not served. Not logged and served, not flagged and served. It is simply unreadable. The tampered content is effectively gone, so the kernel does not deliver it to any process.

What this means for your infrastructure

The signing chain is under your control. You generate the keys, you sign the images, you decide what your systems trust. No vendor is required in your chain of custody.

High-security organizations in government, finance, and healthcare have demanded this level of OS integrity for years. Sealed images deliver it, and it is available to any organization that wants it. You do not need to be in a regulated industry to benefit from knowing that your operating system is exactly what you built.

It is worth being precise about what sealed images cover. The seal protects the files in the immutable OS image: The base operating system, and all the software you layer on top of it. Your monitoring agents, your security tools, your application binaries, and the specific packages your team added to the base image. All of it is sealed. It does not cover writable configuration in /etc or runtime state in /var. That distinction is deliberate. The seal protects the OS you built. Your configuration management and runtime security tools help protect the rest.

At the start of this article, I mentioned a medical device and an ATM, but this goes beyond even those examples. Picture a datacenter, an edge fleet, or a manufacturing floor. One Containerfile defines the OS. One pipeline builds, signs, and seals it. The same sealed image deploys to bare metal, to VMs, to cloud instances. The same integrity follows it everywhere. This is not a niche capability for a narrow use case. It is what OS integrity should look like.

Get started

Sealed images are available as a technology preview in RHEL 10.2. It is built on upstream Linux technologies, including significant components of the systemd project, existing tooling around secure boot and composefs, which provides a flexible and efficient way to have integrity like dm-verityprovides, but with the flexibility of a filesystem-based approach. This is where OS management is heading. The technology preview is open, the tooling works today, and we'll be publishing a step-by-step series on the Red Hat Developer Blog in the coming weeks to help you see what building and verifying systems this way actually looks like in practice.