With wolfBoot 2.8.0, TrustZone became an increasingly important part of the platform’s security model. That release expanded wolfBoot’s ability to place cryptographic services inside secure TrustZone enclaves, including PKCS#11 support via wolfPKCS11, and PSA Crypto with DICE attestation through wolfPSA. In both cases, the benefit is clear: sensitive cryptographic operations and security-critical state can live in the secure world, while the non-secure RTOS and application code remain clients of those services rather than direct owners of the secrets.
The new support for fTPM as root of trust builds on that same architectural idea, but introduces a different security interface and a different usage model. Instead of exposing PKCS#11 or PSA APIs from the enclave, wolfBoot can now host a firmware TPM inside the secure domain and present a virtual TPM interface to the non-secure side. That creates a new option for developers who want to separate cryptography and platform security logic from the non-secure world, while still giving applications and RTOS services a familiar way to consume those capabilities.
What these TrustZone-backed approaches have in common is the boundary itself. The hardware-enforced separation between secure and non-secure worlds lets wolfBoot keep cryptographic engines and sensitive state out of the main software stack. Where they differ is in the programming model they expose. wolfPKCS11 serves PKCS#11 consumers, wolfPSA serves PSA Crypto and attestation flows, and the new fwTPM option serves TPM-style workflows such as measurement, PCR handling, and policy-based platform security operations.
TrustZone options around wolfBoot 2.8.0 and beyond
| TrustZone service | Secure-side engine | Non-secure interface | Best fit |
|---|---|---|---|
| PKCS#11 in TrustZone | wolfPKCS11 | PKCS#11 API | Applications that need token-style key storage and cryptographic operations |
| PSA Crypto + DICE attestation in TrustZone | wolfPSA | PSA Crypto and attestation APIs | Systems built around PSA services, attestation, and measured device identity |
| New fwTPM in TrustZone | fwTPM hosted by wolfBoot | Virtual TPM interface accessed through wolfTPM | Systems that want TPM-style measurements, PCR policy, and platform security workflows without exposing the engine to the non-secure world |
Hosting the TPM inside the secure domain
This new fwTPM mode is particularly compelling because it places the TPM engine itself inside the secure TrustZone enclave. In other words, the TPM is simulated in the secure world rather than implemented as a separate external chip or as logic running in the non-secure software domain. wolfBoot becomes the host for that firmware TPM service, keeping command processing and sensitive TPM state on the secure side of the TrustZone boundary.
That design makes strong architectural sense. The bootloader is already one of the earliest and most trusted components in the system. Extending wolfBoot to host a secure-domain fwTPM means the same trust boundary that protects secure boot and early security decisions can also protect TPM-oriented services. It is a natural evolution for systems that want stronger separation without extra hardware.
A virtual TPM for the non-secure world
On the non-secure side, applications and RTOS services do not need to interact with a custom secure service API. Instead, they see a virtual TPM interface and can access it through wolfTPM. This is an important detail, because it keeps the software model familiar. The non-secure domain continues to behave like a TPM client, while the secure domain remains responsible for actually executing TPM commands.
That separation is where this feature becomes especially attractive for embedded developers. The RTOS and application layer can continue using TPM-style workflows for measurement, PCR extension, policy handling, and related platform security tasks, but the underlying cryptographic engine and sensitive state remain outside their reach. TrustZone provides the hardware isolation, wolfBoot hosts the secure service, and wolfTPM gives the non-secure software stack a practical way to consume it.
Why this matters for embedded systems
Many embedded platforms now include TrustZone-style hardware isolation, but not all of them include a discrete TPM. Even when an external TPM is technically possible, it may increase bill of materials cost, board complexity, and integration effort. A TrustZone-hosted fwTPM offers a different path: keep the TPM model, keep the separation, and remove the need to rely on a separate hardware component for every design.
This also helps from a software integration perspective. Teams that already understand TPM concepts do not need to abandon that model when moving to smaller TrustZone-enabled microcontrollers. Instead, they can preserve TPM-oriented workflows while shifting the implementation into a secure enclave managed by wolfBoot. That lowers friction for developers who want to adopt stronger platform security without redesigning their software architecture around proprietary mechanisms.
More than a theoretical design
This is not just an abstract architecture discussion. The implementation is already exercised through a TrustZone test path that demonstrates practical TPM-style operations across the secure boundary. That matters, because it shows the design is useful for real security flows rather than being limited to a minimal transport demonstration.
In practice, this means wolfBoot is not simply acting as a bootloader that starts secure and non-secure worlds. It is also becoming a more capable secure services foundation for systems that want isolated cryptography, attestation-related building blocks, and now TPM-style platform security functions, all anchored in the hardware-enforced TrustZone boundary.
A new TrustZone option in the wolfBoot toolbox
The addition of fwTPM to the wolfBoot TrustZone model gives developers another meaningful choice. Some systems will prefer PKCS#11 services in the secure world. Others will want PSA Crypto and DICE-based attestation flows. And now, systems that benefit from TPM-style platform security can use a secure-domain fwTPM while keeping the non-secure RTOS and applications on the client side of the boundary.
That is the common pattern across all of these options: separate the cryptographic engine from its users by using the TrustZone boundary provided by the hardware. The new fwTPM support stands out because it applies that pattern to a TPM-oriented security model, bringing familiar TPM workflows to embedded systems in a way that feels both modern and practical.
wolfBoot continues to grow beyond secure boot alone, offering a stronger foundation for embedded platform security in systems that need isolation, flexibility, and a clear separation of trust. To learn more about wolfBoot, wolfTPM, and TrustZone-based secure services, contact us at facts@wolfssl.com.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now