Building a secure IoT device that trusts nothing and verifies everything sounds expensive. It does not have to be. You can build a zero trust IoT device with open source components using tools that are already stable, well tested, and free. The trick is choosing the right building blocks.
A zero trust architecture for constrained IoT devices is achievable today with open source secure elements, measured boot tools, and policy based access control. The core principles are device identity, continuous attestation, and least privilege. This guide walks through each layer with specific components and code patterns.
Why Standard IoT Security Falls Short
Traditional perimeter security assumes the network is safe. Zero trust assumes the network is hostile. For an embedded device that might sit in a factory, a hospital, or a smart building, that assumption is the only safe bet. A sensor that trusts its own firmware without verifying it is a sensor that can be reprogrammed by an attacker. A device that authenticates once and never rechecks is a device that leaks credentials.
Open source components give you full visibility into what your device is doing. You can audit every line. You can patch vulnerabilities yourself or rely on a community that does it faster than any vendor. For a zero trust IoT device, that transparency is not a bonus. It is a requirement.
The Architecture of a Zero Trust IoT Device
A zero trust device implements three core capabilities:
- Identity — The device can prove who it is using a hardware rooted key.
- Attestation — The device can prove its software has not been tampered with.
- Least privilege — The device only accesses the resources it needs, when it needs them.
Here is how those capabilities map to open source components you can integrate today.
1. Hardware Root of Trust with Open Source Secure Elements
The foundation of zero trust is a hardware anchor. You need a secure element that stores private keys and performs cryptographic operations without exposing secrets to the main processor. Open source options like the Trench project (a fully open source secure element firmware) or OpenSK (a Rust based FIDO2 authenticator) run on common secure hardware such as the NXP SE050 or the Infineon SLE78.
These components handle:
- Key generation and storage inside tamper resistant hardware
- Signing attestation challenges
- Deriving session keys for encrypted communication
Your device should never hold a raw private key in flash memory. The secure element does all signing. The main CPU only sees public keys and signed challenges.
2. Measured Boot with Open Source Firmware
Zero trust requires that the device can prove its boot chain is intact. coreboot and TianoCore (the open source UEFI implementation) support measured boot on embedded platforms like the Raspberry Pi CM4 and x86 industrial gateways. When the device boots, each stage measures the next stage and stores the hash in a Trusted Platform Module (TPM).
For devices without a discrete TPM, the wolfTPM library provides a software TPM that works on constrained MCUs. It is not as secure as a discrete chip, but it gives you a verifiable boot measurement on devices where cost matters more than absolute protection.
The boot measurement is sent to a remote verifier (your cloud backend) during the attestation handshake. If the measurement does not match the expected value, the device is denied network access.
3. Identity and Attestation Protocol
Once the device has a hardware rooted key and a boot measurement, it needs a protocol to prove its identity. FIDO2 and attestation using EAT (Entity Attestation Token) are both viable. For constrained devices, the CBOR based EAT format is more efficient than JSON.
Your device sends an attestation token that includes:
- The device public key signed by the secure element
- The boot measurement hash
- A nonce from the verifier to prevent replay attacks
The verifier checks the signature, confirms the boot measurement matches the expected value, and issues a short lived session token. That token is used for all subsequent API calls.
4. Least Privilege with Open Source Access Control
A zero trust device does not trust itself. Every request to a sensor, an actuator, or a network endpoint is authorized individually. On Linux based embedded devices, AppArmor or SELinux enforce mandatory access control. For RTOS based devices (FreeRTOS, Zephyr), the SMACK label system provides a lightweight alternative.
The policy should be:
- The device can only write to its own log file
- The device can only send data to one upstream MQTT broker
- The device cannot read other processes’ memory
These policies are defined in text files that ship with the firmware. They are compiled into the image and enforced at runtime.
Practical Steps to Build Your Device
Here is a numbered list of steps to move from concept to working prototype.
- Select your hardware and secure element. Choose a board that supports coreboot or has a TPM socket. Pair it with an open source secure element firmware like Trench.
- Flash coreboot with measured boot enabled. Configure coreboot to measure each stage and store the hash in the TPM or software TPM.
- Generate a device identity during first boot. The secure element creates a key pair. The public key is sent to your provisioning server.
- Implement the attestation client. Use the wolfTPM library to read the boot measurement and the secure element to sign the attestation token. Send the token to your verifier.
- Set up a remote verifier. This can be a Python or Rust service that checks EAT tokens against a database of known good measurements.
- Apply least privilege policies. Write AppArmor or SMACK profiles that restrict the device to only the files and network sockets it needs.
- Test the revocation path. If the device fails attestation, the verifier must deny the session. Simulate a tampered firmware and confirm the device is blocked.
Common Mistakes and How to Avoid Them
| Mistake | Why It Hurts Zero Trust | Open Source Fix |
|---|---|---|
| Using software keys | Keys can be extracted from flash | Use a secure element with Trench or OpenSK |
| Skipping boot measurement | Attacker can replace firmware without detection | Enable measured boot in coreboot |
| Long lived session tokens | Token theft gives permanent access | Issue tokens that expire in minutes |
| Hardcoded credentials | Credentials can be dumped from firmware | Derive session keys from attestation |
| No policy for local resources | Compromised process can read all files | Write AppArmor profiles for each binary |
Expert Advice on Constrained Devices
“On a device with 64 KB of RAM and 512 KB of flash, you cannot run a full Linux stack. Use Zephyr with the wolfSSL TLS library and a software TPM. The attestation token fits in a single CoAP message. Keep the policy simple: one allowed upstream, one log file, one watchdog check. That is enough for a zero trust baseline.”
Embedded security architect, open source IoT working group
Choosing the Right Components for 2026
The open source ecosystem for zero trust IoT has matured. Here are the components that work well together today:
- coreboot for measured boot on x86 and ARM
- Trench for secure element firmware on NXP and Infineon hardware
- wolfSSL and wolfTPM for TLS and TPM operations on constrained devices
- Zephyr RTOS for devices with less than 256 KB of RAM
- EAT library (CBOR based) for attestation tokens
- AppArmor for Linux based devices, SMACK for Zephyr
These components are all open source, actively maintained, and have been audited by third parties. You can combine them into a single firmware image using Yocto or a Zephyr build system.
Why Open Source Fits Zero Trust
Zero trust is about verification, not about trust in a vendor. A proprietary secure element might have a backdoor that you cannot see. An open source secure element can be audited by anyone. A proprietary boot loader might skip a measurement step. An open source boot loader is reviewed by hundreds of engineers.
For a deeper look at how open source protocols strengthen device identity, read about how open source authentication protocols strengthen IoT device identity. For a broader view of the ecosystem, see the guide on enhancing IoT security with open source embedded systems.
Building for the Real World
Your first zero trust device will not be perfect. You might find that the secure element is too slow for your use case, or that the boot measurement adds three seconds to startup. That is fine. Start with the core identity and attestation flow. Add measured boot later. Tighten the AppArmor policy over time.
The important thing is to start. Pick a constrained device, flash coreboot, integrate wolfTPM, and write a simple attestation client. Once you see the attestation token accepted by your verifier, you have a zero trust IoT device. From there, you can iterate.
For a complete reference architecture that includes gateway integration, see the guide on building a secure IoT gateway using open source software. And if you are wondering about regulatory compliance, the article on how open source can help meet IoT security regulations in 2026 covers the latest requirements.
Your Next Step
Grab a Raspberry Pi CM4 or a Sipeed MaixDuino. Flash coreboot. Install wolfSSL and wolfTPM. Write a 50 line attestation client in C or Rust. Set up a Python verifier on your laptop. When the device boots and the verifier says “attestation passed,” you have built a zero trust IoT device with open source components. That is a win. Now go ship it to production.
