STDA030 April   2026 AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM62A1-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62P , AM62P-Q1 , AM6411 , AM6412 , AM6421 , AM6422 , AM6441 , AM6442 , TDA4AEN-Q1 , TDA4AH-Q1 , TDA4AL-Q1 , TDA4AP-Q1 , TDA4VE-Q1 , TDA4VEN-Q1 , TDA4VH-Q1

 

  1.   1
  2.   Abstract
  3. 1Introduction
  4. 2Scope of CRA
  5. 3Product Requirements
  6. 4Vulnerability Handling Process
  7. 5Information and Labeling
  8. 6TI Processors Meeting the Requirements of the CRA
  9. 7Conclusions
  10. 8References

TI Processors Meeting the Requirements of the CRA

The Jacinto™ (TDA4x and DRA8x) and Sitara™ (AM6x) processor families are engineered to satisfy security by default requirements. In every microprocessor in these families, a dedicated public key is hardwired into the silicon. Only firmware signed with the corresponding private key can pass the boot check. This key establishes a hardware root-of-trust that verifies both authenticity and integrity for all software running on the platform, so that only authenticated software runs on the processor.

TDA4x, AM6x Root of Trust (RoT) Key ProvisioningFigure 6-1 Root of Trust (RoT) Key Provisioning

TI processors embed hardware access control that segment the on‑chip memory into isolated zones, shielding critical memory sections from unauthorized read or write operations. The platform enables separation between concurrent workloads by assigning each application (which often runs on a distinct CPU core within the same device) an individual protected code and data region; thereby, preventing accidental leakage or malicious interference. In addition to these memory safeguards, the processors offer features to access control the debug port. A debug interface can be permanently disabled for production units, or the debug interface can be exposed only after a request is authenticated through a signed certificate, thus closing common attack vectors that exploit debugging tools.

Comprehensive documentation is supplied for each package and the firmware and software released for TI processors is first scanned for known vulnerabilities. Together, these controls meet the appropriate level of security required by the Cyber Resilience Act.

TI aims to release software with no known vulnerabilities. TI has had an active vulnerability handling process for many years through TI's Product Security Incident Response Team (PSIRT). The vulnerability handling process at TI includes the following examples:

  • The generation of an SBOM
  • Tracking vulnerabilities across various software that TI provides as part of the processors
  • Providing fixes to critical vulnerabilities
  • Public disclosure when the vulnerabilities are fixed

TI is actively monitoring the requirements of the coordinated vulnerability disclosure (CVD) and putting a system in place for vulnerability disclosures.

Processors from TI provide a set of compliance artifacts that satisfy the requirements of the Cyber Resilience Act in a straightforward way. Each silicon family is shipped with a detailed datasheet, and TI publishes a clear update policy that informs customers when and how firmware patches are delivered. For every software stack (for example, bootloaders, SDKs, and middleware) an SBOM lists all top‑level licenses, components, and the dependencies, making vulnerability tracking easy. TI generates and provides an SBOM as part of newer SDK releases for each processor. The lifecycle guide for the product outlines the support period, end‑of‑life dates, and the scope of warranty for each device. The comprehensive user guides explain how to configure security features, such as secure boot and debug port control; while every chip carries a unique part number and die ID that allows end users to verify the exact product variant. All together, these documents, updates, SBOMs, and identifiers give OEMs the evidence required to prove CRA compliance of TI processors.