Building a Trusted Embedded Product with i.MX95 Security Features

An embedded product can boot correctly, run its application, and still be exposed to serious security risks. Consider an industrial system based on the NXP i.MX95. It may process camera or sensor data, store calibration parameters, preserve operational settings, and receive software updates after deployment. If those assets are not protected, an attacker could try to replace boot software, extract sensitive information from storage, install an unauthorized update, or restore an older software version with known vulnerabilities.

This is why embedded security cannot depend on a single mechanism. Trust has to be maintained from the first stage of boot through data protection, software updates, and long-term product maintenance.

Security Starts Before Operating System

A product can leave the factory in a secure state and still become vulnerable later if its update mechanism is weak. Embedded systems often remain deployed for years, which means software updates become part of the security architecture. Over-the-Air (OTA) updates make it possible to remotely deliver software, firmware, or system images to devices already deployed in the field, allowing security fixes, bug fixes, and new functionality to be introduced without requiring physical access to each device.

However, the ability to update a device remotely also introduces an important security question: How can the device verify that an update is legitimate and safe to install?

A secure OTA process should not only deliver new software. It should also verify that the update comes from an authorized source, validate the package before installation, preserve a recovery path, and ensure that the new software successfully boots before it is considered active.

Secure Boot then provides another layer of protection by authenticating the installed boot components during the next startup.

This creates a layered model in which transport security, update authentication, boot verification, and recovery each solve a different problem. The i.MX95 platform provides the hardware security foundation, while the complete OTA solution is built through integration with the Yocto image, bootloader, storage layout, update framework, and release infrastructure.

From Development Flexibility to Production Enforcement

A secure product also needs a controlled transition from engineering to production.

During development, teams need visibility and flexibility. They must be able to test signed images, inspect authentication failures, verify recovery procedures, and confirm that their security configuration works as expected.

Once the security flow has been validated, the device can move from an OEM Open development state to an OEM Closed production state, where the configured security policy is enforced.

This transition is important because production security is not simply a build option. It involves provisioning trust into the device and locking down behavior that was intentionally more flexible during development. The result is a system designed to behave differently once it becomes a production product.

Trusted Software and Protected Data Are Different Problems

Secure Boot helps determine whether software is authentic and authorized.

It does not, by itself, protect sensitive data stored on the device. That distinction is especially relevant for products that store calibration information, system configuration, inspection results, sensor data, or customer-specific information.

For data at rest, disk encryption can be introduced using technologies such as dm-crypt and LUKS. This protects selected storage areas even if the physical media is removed from the device.

Encrypted boot can also protect selected boot artifacts, but it serves a different purpose from disk encryption.

The distinction is simple:

• Secure Boot protects what is allowed to run.

• Encryption protects what should not be readable.

In many production systems, both are necessary.

Security Must Continue After Deployment

A product can leave the factory in a secure state and still become vulnerable later if its update mechanism is weak. Embedded systems often remain deployed for years, which means software updates become part of the security architecture.

Over-the-Air (OTA) updates allow software, firmware, or system images to be remotely deployed to devices after they have been installed in the field. This makes it possible to deliver security fixes, bug fixes, and new functionality without requiring physical access to each device.

A secure OTA process should not only deliver new software. It should also verify that the update comes from an authorized source, validate the package before installation, preserve a recovery path, and ensure that the new software successfully boots before it is considered active. Secure Boot then provides another layer of protection by authenticating the installed boot components during the next startup.

This creates a layered model in which transport security, update authentication, boot verification, and recovery each solve a different problem. The i.MX95 platform provides the hardware security foundation, while the complete OTA solution is built through integration with the Yocto image, bootloader, storage layout, update framework, and release infrastructure.

Preventing a Return to Vulnerable Software

Even authenticated software can become unsafe over time. Imagine that version 5 of a product contains a vulnerability and version 6 fixes it. Both versions may still have valid signatures. Secure Boot can confirm that version 5 is authentic, but that does not mean the product should still be allowed to run it.

This is where antirollback becomes important. Antirollback allows the system to enforce a minimum accepted software version, preventing older releases from being reintroduced after a security threshold has been advanced. This is different from recovery rollback. Recovery rollback helps a device return to a known-good system after a failed update. Antirollback protects against returning to software that is no longer considered acceptable from a security perspective. Both mechanisms can be necessary in the same product.

Building Trust Across the Product Lifecycle

The value of the i.MX95 security architecture is not found in one isolated feature. It comes from how the different mechanisms work together throughout the product lifecycle. Secure Boot establishes trust in the software being executed. Encryption protects sensitive information. Secure OTA maintains software integrity after deployment. Antirollback helps prevent the reintroduction of vulnerable software. The device lifecycle controls when development flexibility ends and production enforcement begins.

Together, these mechanisms support a broader objective: ensuring that an embedded product can continue to establish trust even after it has left the development environment. For companies building industrial or edge devices, this is increasingly important. Products may operate remotely, process valuable data, and remain in the field for long periods of time. Their security architecture therefore has to be designed not only for first boot, but for years of operation.

The NXP i.MX95 provides the hardware foundation for that model, while Yocto integration, update infrastructure, encryption strategy, recovery planning, and production provisioning define how that foundation becomes a secure product. RidgeRun supports teams working with i.MX95 security architectures, from platform bring-up and Yocto integration to Secure Boot, data protection, OTA workflows, and production validation.

Need Help Securing Your Embedded Platform?

RidgeRun can help you integrate and validate security features throughout your embedded product lifecycle. For practical guidance on NXP i.MX95 and NVIDIA Jetson, explore our Platform Security Manual and learn how we can help bring these security concepts into your product.