NVIDIA Jetson Security: JetPack and Yocto Integration
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
To enable and validate security features on NVIDIA Jetson, first choose your product's software workflow: JetPack / Jetson Linux (L4T) or Yocto / OpenEmbedded. Both support security integration, but the locations of signing configurations, image recipes, boot artifacts and flashing tools differ. This guide compares the paths and links to implementation instructions for Secure Boot, Trusted Execution Environment (TEE), disk encryption, secure over-the-air (OTA) updates, and production signing.
NVIDIA Jetson Security: JetPack and Yocto Integration
NVIDIA Jetson platforms are designed for embedded and edge-AI systems that combine high-performance computing, GPU acceleration, camera and multimedia processing, and connectivity in a single platform. These capabilities make Jetson suitable for applications such as robotics, autonomous systems, industrial automation, intelligent cameras, medical devices, and other connected edge products.
These systems may process sensitive information, communicate with external services, control physical devices, and execute software that determines the behavior of the complete product. For this reason, securing a Jetson-based system involves more than protecting the Linux operating system. The platform must establish trust during boot, authenticate the software that is executed, protect sensitive data and cryptographic material, secure software updates, and restrict unauthorized access to the device.
This guide presents a practical path for securing NVIDIA Jetson platforms. It covers security mechanisms such as Secure Boot, Trusted Execution Environments (TEE), disk encryption, Trusted Platform Module (TPM) integration, secure OTA updates, system access restrictions, and the procedures required to bring security configurations into production.
The developer can use this guide to move from a working Jetson software image to a validated security configuration. Each security mechanism should be implemented according to the threats and security requirements of the product and validated before production enforcement.
Unlike platforms where this manual follows a single build environment, NVIDIA Jetson security can be integrated through two different development flows:
- JetPack Build Process – Security configuration using NVIDIA Jetson Linux, the Linux for Tegra (L4T) BSP, and NVIDIA's flashing and signing tools.
- Yocto Build Process – Security integration as part of a Yocto-based Linux distribution and its reproducible build process.
Both approaches target the security capabilities of the Jetson platform, but the configuration, build, signing, image generation, and deployment procedures differ.
The appropriate path should therefore be selected according to the Linux distribution and build system used by the product.
NVIDIA Jetson Security Implementation Paths
The security requirements of the product should remain independent of the selected build system.
For example, a product may define the following requirement:
Security requirement: Only authorized software must execute during boot.
The mechanism used to satisfy this requirement may be Secure Boot in both cases, while the integration procedure differs depending on whether the product is built using JetPack/L4T or Yocto.
This separation allows the security architecture to remain focused on what the product must protect while the implementation procedure remains specific to the selected software stack.
NVIDIA Jetson Security with JetPack / Jetson Linux
The JetPack Build Process describes how security mechanisms are configured, built, flashed, and validated using the NVIDIA Jetson Linux environment and the tools provided as part of the Linux for Tegra BSP.
This path is appropriate for products based directly on NVIDIA Jetson Linux and its standard BSP and flashing infrastructure.
The JetPack security documentation in this manual covers topics such as:
- Security flow and platform trust architecture.
- Secure Boot.
- Trusted Execution Environment (TEE).
- Disk encryption.
- Over-the-Air (OTA) updates.
- Trusted Platform Module (TPM).
- Kiosk modes and access restrictions.
- Bringing Secure Boot configurations into production.
- Integration of signing infrastructure and Hardware Security Modules (HSMs).
- Integration of signing workflows with CI/CD.
See NVIDIA Jetson JetPack Build Process for the detailed procedures.
NVIDIA Jetson Security with Yocto / OpenEmbedded
Some Jetson products use Yocto instead of the standard JetPack root filesystem and development workflow.
In these systems, security mechanisms must also be integrated into the reproducible Yocto build process.
The Yocto Build Process section describes how the security configuration participates in image generation and how the required platform mechanisms can be integrated into the product's Yocto configuration.
The Yocto security documentation in this manual covers topics such as:
- Secure Boot.
- Trusted Execution Environment (TEE).
- Disk encryption.
Depending on the security mechanism, implementation may involve Yocto configuration, recipes, classes, signing infrastructure, image generation, and NVIDIA platform-specific tools.
See NVIDIA Jetson Yocto Build Process for the detailed procedures.
JetPack vs Yocto: Build and Security Integration Differences
NVIDIA Jetson security features can be implemented through either the standard JetPack / Jetson Linux workflow or a Yocto-based workflow. The security objectives are the same in both cases, but the build model, artifact organization, signing integration, flashing process, and customization points are different.
For this comparison, Jetson Linux R39.2 / JetPack 7.2 is used as the main reference. Beginning with JetPack 7.2, NVIDIA officially supports Yocto on Jetson platforms and aligns this support with the OpenEmbedded for Tegra (OE4T) project.
Software Model
| Topic | JetPack / Jetson Linux | Yocto |
|---|---|---|
| Base software model | NVIDIA-provided Jetson Linux BSP and Linux for Tegra workspace. | Metadata-driven image generation through BitBake, OpenEmbedded, and Jetson BSP layers. |
| Main workspace | Linux_for_Tegra/
|
Yocto build directory and layer stack. |
| BSP integration | Provided directly by NVIDIA Jetson Linux BSP components. | Provided primarily through OE4T meta-tegra.
|
| Root filesystem | Prepared inside the BSP workspace and modified as needed. | Generated from recipes, package selections, image configuration, and distribution metadata. |
| Typical customization | BSP files, rootfs contents, NVIDIA flashing configuration, signing options. | Layers, recipes, classes, machine configuration, distro configuration, image recipes. |
In the JetPack workflow, development normally starts from NVIDIA-provided BSP components and binary artifacts. A typical BSP workspace is organized around:
Linux_for_Tegra/ ├── bootloader/ ├── kernel/ ├── rootfs/ └── nv_tegra/
In the Yocto workflow, the target image is described before it is built. A simplified layer model is:
Product-specific layer
|
v
meta-tegra-community Optional
|
v
meta-tegra
|
v
meta-openembedded
|
v
OpenEmbedded Core / BitBake
Build Workflow
| Topic | JetPack / Jetson Linux | Yocto |
|---|---|---|
| Target selection | Usually selected when invoking NVIDIA flashing tools. | Selected before the build through MACHINE and Yocto configuration.
|
| Build process | Uses prepared BSP files, rootfs content, and NVIDIA tools. | BitBake resolves recipes, layers, machine configuration, dependencies, and image contents. |
| Example command | sudo ./flash.sh <board> <rootdev>
|
. ./setup-env --machine jetson-orin-nano-devkit-nvme
|
| Image generation | Based on the prepared Linux for Tegra workspace. | Generated reproducibly from metadata and source/layer revisions. |
In JetPack / Jetson Linux, the BSP workspace remains an important part of both image preparation and deployment. The target configuration is selected through commands such as:
sudo ./flash.sh <board> <rootdev>
or through the initrd-based flashing flow:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh <options> <board> <rootdev>
In Yocto, platform selection normally happens earlier in the workflow. For example:
. ./setup-env --machine jetson-orin-nano-devkit-nvme
A simplified Yocto flow is:
Select MACHINE
|
v
Select DISTRO and image recipe
|
v
BitBake resolves recipes and dependencies
|
v
Build root filesystem and BSP components
|
v
Generate deploy artifacts
|
v
Generate Jetson flashing package
Build Artifacts
Both workflows must produce the platform components required to boot the Jetson, but they organize those artifacts differently.
| Workflow | Artifact Organization |
|---|---|
| JetPack / Jetson Linux | The Linux_for_Tegra directory acts as the BSP workspace containing bootloader, kernel, rootfs, NVIDIA platform content, flashing tools, and partition configuration.
|
Yocto / meta-tegra
|
BitBake generates machine-specific deploy artifacts and can package the required flashing content as part of the build output. |
Important JetPack BSP directories include:
| Directory | Role |
|---|---|
bootloader
|
Bootloader binaries, Tegra flashing tools, partition configuration, and related boot components. |
kernel
|
Linux kernel and related kernel content. |
rootfs
|
Target root filesystem. |
nv_tegra
|
NVIDIA platform and userspace content used by the BSP. |
In Yocto, generated output is stored under the BitBake deployment directory for the selected machine. One important meta-tegra output is the Tegra flashing archive:
<image>-<machine>.tegraflash-tar.zst
This archive packages the machine-specific content required by the OE4T flashing flow.
Security Integration Differences
| Security Task | JetPack / Jetson Linux | Yocto |
|---|---|---|
| Secure Boot signing | Integrated through NVIDIA Jetson Linux signing and flashing tools. | Integrated through Yocto variables, classes, and meta-tegra signing support.
|
| UEFI Secure Boot | Configured through NVIDIA tooling and UEFI key configuration files. | Can be integrated into the image build and deploy artifacts through the Yocto workflow. |
| Disk encryption | Configured through Jetson Linux security procedures and flashing flow. | Integrated into the Yocto image, initramfs, storage layout, and related recipes. |
| OTA | Implemented through Jetson-compatible OTA tooling and update framework configuration. | Integrated with Yocto image generation, update artifacts, and release metadata. |
| Production signing | Often added around the NVIDIA flashing/signing workflow. | Can be integrated with CI/CD, signing services, and Yocto artifact generation. |
The security mechanism does not change only because the build system changes. Secure Boot, disk encryption, TEE, TPM, and OTA still protect the same platform assets. What changes is where the configuration lives and how it becomes part of the product release process.
When to Use Each Path
| Use JetPack / Jetson Linux when... | Use Yocto when... |
|---|---|
| The product is based directly on NVIDIA Jetson Linux. | The product already uses a Yocto-based Linux distribution. |
| The team wants to stay close to NVIDIA's standard BSP and flashing workflow. | The team needs reproducible image generation from layers, recipes, and metadata. |
| Customization is mostly around BSP configuration, rootfs changes, and deployment scripts. | Customization must be captured as product layers, recipes, image features, and distro policy. |
| Manual or scripted NVIDIA flashing workflows are acceptable. | CI/CD, release automation, and controlled image reproducibility are major requirements. |
The correct path should be selected according to the product's software architecture, release process, maintainability requirements, and manufacturing workflow. The security requirements should be defined independently, then implemented through the build path selected by the product.
FAQ
- How do I enable security features on NVIDIA Jetson?
- Choose the security guide for the product's build workflow—JetPack/L4T or Yocto—then configure and validate each mechanism, such as Secure Boot, TEE, disk encryption or OTA, using the relevant feature-specific procedure.
- Should I use JetPack or Yocto for NVIDIA Jetson security?
- Use JetPack if the product follows NVIDIA's Linux for Tegra BSP and flashing process. Use Yocto if the product uses BitBake, OpenEmbedded layers and recipes. The security goal remains the same; integration and artifact handling differ.
- Can I integrate NVIDIA Jetson Secure Boot into Yocto?
- Yes. RidgeRun's Yocto Secure Boot documentation covers the integration path, with release-specific signing, deployment and validation details.
- What is the difference between SoC Secure Boot and UEFI Secure Boot on Jetson?
- SoC Secure Boot anchors authentication in the early hardware and firmware boot chain. UEFI Secure Boot checks supported later-stage EFI applications and boot payloads against a UEFI signature policy. They protect different portions of the boot sequence.
- Does Secure Boot encrypt the Jetson root filesystem?
- No. Boot authentication and data-at-rest confidentiality are different security objectives. Disk encryption requires separate storage, key-management and unlock configuration.
- Does a Jetson booting successfully prove Secure Boot is enabled?
- No. Successful authorized boot should be complemented by controlled negative tests showing that unauthorized or tampered boot components are rejected.
- What changes when moving a Jetson security configuration from JetPack to Yocto?
- The security goals can remain unchanged, but build configuration moves from the NVIDIA BSP workspace and flashing scripts to Yocto metadata, recipes, classes and deploy outputs, together with platform-specific NVIDIA tools.
- What should be documented when validating Jetson security?
- Record the module, carrier board, storage, BSP or Yocto release, relevant software revisions, key and fuse state, test commands, expected results, observed logs, and recovery procedure.
Related Documentation
- RidgeRun Platform Security Manual
- Platform Support
- NVIDIA Jetson JetPack Security
- NVIDIA Jetson Yocto Security
- NVIDIA Jetson Linux R39.2 Developer Guide
Contact Us
For help integrating or validating Jetson security, production signing, or Yocto and JetPack builds, contact RidgeRun.