Implement Secure Boot and Filesystem Encryption in Embedded Systems

In today’s connected world, cybersecurity isn’t something you tack on at the end—it’s as essential to your design process as hardware specs and UX. Whether you're building medical devices, industrial controllers – even smart-home systems – getting security right from the start protects your users, your reputation and your IP.

In this post, we’ll look at how you can use Secure Boot and Filesystem Encryption to lock down your device. These features aren't just “nice-to-haves” — they’re often the difference between a trustworthy product and a vulnerable one.

Locking the Front Door is Just the First Step

If you’ve worked on embedded Linux devices, you’ve probably covered the basics: closing debug console access (like UART), disabling JTAG unless it's absolutely needed (there are secure ways to do it), and turning off SSH access in production. These are good initial steps, but they only protect against the most obvious threats. Modern threats require stronger defenses. That’s where Secure Boot and Filesystem Encryption come in.

Secure Boot: Ensure Only Your Code Runs

Secure Boot is all about making sure your device runs only what you intend it to run. It works by cryptographically verifying each stage of the boot process — bootloader, kernel — so nothing unauthorized can sneak in.

Here’s an overview. Your hardware is provisioned with a public key, stored securely in ROM or another protected area. The boot ROM verifies the bootloader’s signature using that key. If it checks out, the bootloader runs and performs a similar check on the next stage. Any tampering along the way breaks the chain and stops the boot process.

Implementing Secure Boot also means taking responsibility for how you manage your private signing keys. These never go on the device—they stay in your build infrastructure, used only to sign trusted binaries. If you lose control of those keys, the whole system's integrity is at risk.

One thing to watch for is licensing. If you’re using components under GPLv3 or LGPLv3, you may be required to provide end users with a way to load their own signed code or even re-sign and run modified versions. That doesn't mean Secure Boot is off the table — you just need to handle it carefully, either by supporting user keys or choosing permissive licenses.

Filesystem Encryption: Protect Data and IP at Rest

If your application code is written in an interpreted language like Python then your source code is also your deployed product. Without protection, anyone with physical access could extract and reverse-engineer it. 

That’s where filesystem encryption comes in.

The challenge is doing this securely and conveniently. You don’t want your user to type a password every time the device boots, but you still need a way to keep encryption keys out of reach.

Modern SoCs solve this problem with embedded cryptographic engines or secure key storage. For example, NXP’s CAAM module allows the filesystem encryption key to be stored encrypted and then automatically decrypted by the chip at boot. The unencrypted key never leaves the hardware and isn’t accessible to software running on the main processor.

Another option is to generate a key that’s stored in a secure hardware block — one that lets you use the key but never read it. In both cases, encryption is transparent to the system but completely opaque to attackers.

Runtime Protection: Keep Secrets Safe Even When Running

Boot-time and at-rest security are great, but what about when your system is up and running? If your device includes a private certificate for authentication or secure communication it could be vulnerable if the system gets compromised.

There are two solid approaches to protecting secrets in use.

One is to run a separate secure OS alongside your main system using hardware-enforced memory separation. ARM’s TrustZone architecture supports this with OP-TEE, an open-source Trusted Execution Environment. You pass encrypted secrets to OP-TEE, it decrypts and uses them internally, and the main OS never sees the plaintext.

The other is using dedicated crypto hardware, for instance a secure element or TPM, that can store the certificate and perform operations like signing or decrypting data internally. The certificate can’t be extracted, only used.

Both approaches isolate sensitive operations and protect against runtime threats like privilege escalation or memory scraping.

Safeguard Your Product: Cybersecurity is a Design Decision

Features like Secure Boot and Filesystem Encryption help you protect not just your users, but your IP, your compliance posture, and the long-term integrity of your product. So adopt a security mindset: plan early, choose wisely. The more you understand your cybersecurity options, the better equipped you are to choose what your project truly needs.

If you're navigating embedded device cybersecurity and need deeper guidance, we’re here to help. Looking for more cybersecurity-related content? Read our post Recent Initiatives to Improve C and C++ Memory Safety.