Immutable OS and Verified Boot: Why TPM Isn’t Required to Secure Edge Nodes

By Eric Seme

The False Dependency on TPM

For years, secure system design has implicitly assumed that a Trusted Platform Module (TPM) is required to establish a reliable chain of trust. That assumption is convenient, but it is not technically accurate.

A TPM provides a standardized mechanism for measured boot, attestation, and sealed storage. However, it is not the only way to achieve those properties, nor is it required to achieve the most critical one: ensuring that only trusted software executes on a device.

What matters is not the presence of TPM, but whether the system enforces integrity from the very first instruction executed.

Integrity as the Real Control Plane

Edge environments no longer operate in isolation. Systems are distributed, interconnected, and continuously updated. In this context, trust cannot be assumed based on network position or physical location.

Instead, trust must be derived from verifiable integrity.

This requires answering three questions at any given time:

• What is running?

• How did it get there?

• Has it been modified?

Verified boot and immutable operating systems directly address these questions.

Immutable Operating Systems: Operational Security, Not Convenience

Immutable operating systems fundamentally change how systems are managed and secured. Rather than modifying a running system, the entire operating system is delivered as a complete image, mounted as read-only, and updated atomically (OSTree Project, 2023; Canonical Ltd., 2024).

This eliminates entire classes of failure:

• Configuration drift

• Partial updates

• Persistent compromise through filesystem mutation

The system becomes deterministic. Either it is in a known good state, or it is rolled back to one.

Verified Boot as a Chain, Not a Feature

Secure Boot validates that code is signed. Verified Boot extends that concept into a chain of trust.

Each stage verifies the next:

firmware → bootloader → kernel → root filesystem

Technologies such as UEFI Secure Boot (UEFI Forum, 2023), U-Boot Verified Boot (U-Boot Project, 2023), and dm-verity (Linux Kernel Organization, 2023) allow this chain to extend from hardware into runtime.

The result is simple: unauthorized code does not execute, and unauthorized modifications are detected.

Operating Without TPM: What Actually Changes

Removing TPM does not break this model. Verified boot, immutable systems, and rollback mechanisms remain fully functional.

What changes is not integrity, but standardization.

Without TPM:

• Measured boot is not uniform across platforms

• Remote attestation becomes implementation-specific

• Sealing secrets to system state is less portable

These are real trade-offs, but they do not invalidate TPM-free architectures.

Alternative Roots of Trust

Modern systems already implement alternative trust models.

In x86 environments:

• UEFI Secure Boot + Unified Kernel Image (UKI) + dm-verity

In embedded and ARM systems:

• ROM-based root of trust

• U-Boot verified boot

• Keys stored in OTP or secure elements

• DICE-derived identity (Trusted Computing Group, 2023; Google, 2023)

These architectures demonstrate that trust can be anchored without TPM.

Attestation Without TPM

Attestation is where TPM traditionally dominates. However, frameworks such as DICE, PSA, and IETF RATS provide viable alternatives.

Using these models:

• Device identity is derived from boot state

• Evidence is encoded in tokens (EAT) (IETF, 2024)

• Verification can be performed remotely

This approach is not as standardized as TPM-based PCR models, but it is increasingly viable in edge and embedded systems (IETF, 2023).

Security Is an Operational Discipline

The most common mistake in edge security design is focusing exclusively on boot integrity.

In practice, security depends on:

• Key management and rotation (NIST, 2019)

• Secure update pipelines (AWS, 2023)

• Rollback and recovery mechanisms (NIST, 2018)

• Continuous validation of system health

Immutable operating systems enable these practices, but they do not replace them.

Conclusion

TPM is a useful component, but it is not a prerequisite for secure system design.

A system that enforces verified boot, operates on immutable images, and maintains a controlled update process can achieve strong, production-grade security without TPM.

The real requirement is not a specific hardware module. It is a system architecture that enforces integrity, consistency, and recoverability at every stage of operation.

About the Author

Eric Seme is an industrial cybersecurity expert and the founder of EmberNet, where he focuses on developing hyper-converged infrastructure and zero-trust architectures for the plant floor. His work centers on helping organizations transition from legacy perimeter models to resilient, identity-driven operational environments.

Bibliography

Amazon Web Services. (2023). AWS IoT device management and OTA updates.

Canonical Ltd. (2024). Ubuntu Core documentation.

Google. (2023). Open DICE: Device Identifier Composition Engine.

IETF. (2023). Remote Attestation Procedures (RATS) Architecture (RFC 9334).

IETF. (2024). Entity Attestation Token (EAT) (RFC 9711).

Linux Kernel Organization. (2023). dm-verity and fs-verity documentation.

NIST. (2018). SP 800-193: Platform Firmware Resiliency Guidelines.

NIST. (2019). SP 800-147: BIOS Protection Guidelines.

OSTree Project. (2023). OSTree documentation.

Trusted Computing Group. (2023). DICE Attestation Architecture.

U-Boot Project. (2023). Verified Boot documentation.

UEFI Forum. (2023). UEFI Specification Version 2.10.