STDA050 October   2026 AM2431 , AM2432 , AM2434 , AM623 , AM625 , AM625-Q1 , AM625SIP , AM62A1-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62L , AM62P , AM62P-Q1 , AM6411 , AM6412 , AM6421 , AM6422 , AM6441 , AM6442 , AM67 , AM67A , AM68 , AM68A , AM69 , AM69A , DRA821U , DRA829J , DRA829V , TDA4AEN-Q1 , TDA4AH-Q1 , TDA4AL-Q1 , TDA4AP-Q1 , TDA4APE-Q1 , TDA4VE-Q1 , TDA4VEN-Q1 , TDA4VH-Q1 , TDA4VL-Q1 , TDA4VM , TDA4VM-Q1 , TDA4VP-Q1 , TDA4VPE-Q1 , TDA54-Q1

 

  1.   1
  2.   Abstract
  3. 1Introduction
  4. 2CRA Scope and the Component Supplier Question
    1. 2.1 What the Regulation Covers
    2. 2.2 How the CRA Classifies TI Products
    3. 2.3 The Integration Boundary
  5. 3Shared Responsibility Model
    1. 3.1 The Supply Chain Stack
    2. 3.2 Responsibility Allocation by CRA Requirement
    3. 3.3 The Tier 1 and SoM Vendor Layer
  6. 4TI's Security Capabilities Relevant to CRA
    1. 4.1 Hardware Security Capabilities
    2. 4.2 SDK and Software Security
    3. 4.3 Documentation and Lifecycle Artifacts
  7. 5Conclusion
  8. 6References

3.2 Responsibility Allocation by CRA Requirement

Section 3.2 lists the main CRA requirements to each party in the supply chain. Where a manufacturer is not physically established in the EU, the CRA requires them to appoint an authorized EU representative. This representative is a locally registered entity that can receive regulatory communications and act on the behalf of the manufacturer. The allocation reflects TI's interpretation of a typical embedded product supply chain. Specific products and supply chain arrangements can result in different allocations, however, Section 3.2 is not a substitute for product-specific compliance analysis.

Table 3-2 CRA Obligation Allocation Across the Supply Chain
CRA Requirement Regulation Reference TI (Component Manufacturer) Tier 1 / SoM Vendor OEM Product Manufacturer
Cybersecurity risk assessment Art. 13(2) Chip-level threat model; security datasheet Board-level risk assessment Product-level risk assessment covering the full system
SBOM - top-level dependencies Annex I, Part II, item 1 SBOMs (SPDX, CycloneDX); secure SW using MySecure Board-level SBOM Product SBOM integrating all supplier SBOMs and own application software
No known exploitable vulnerabilities at release Annex I, Part I, item 2(a) SDK scanned before each release Board (BSP) software scanned before release. Vendors also provide the SDK and other SW. Full product scanned for known vulnerabilities before EU market placement
Secure by default configuration Annex I, Part I, item 2(b) Hardware root of trust and secure boot capability available; ROM-enforced on security-enforced device variants Board defaults configured Product shipped in secure default state; customer instructions provided; customer forced to change defaults like password
Security updates possible Annex I, Part I, item 2(c) Firmware patches delivered through the CI/CD pipeline or secure folder (based on sensitivity). PSIRT/PSAP tracks and communicates patch status. Board update mechanism Delivery of updates to end users; free of charge
Protection from unauthorized access Annex I, Part I, item 2(d) Hardware access control; debug port control Board-level authentication Product-level authentication and access management
Integrity protection Annex I, Part I, item 2(f) Signed firmware architecture supports boot integrity; cryptographically enforced on security-enforced device variants Firmware signing for board components System-level integrity verification
Limit attack surfaces Annex I, Part I, item 2(j) Hardware isolation Board interface configuration Product interface minimization and hardening
Security test reports for product security testing and vulnerability handling Annex I Part I, Annex I Part II & Annex VII(6) Test reports covering component-level security features. Updated reports for each component-level vulnerability fix. Test reports covering board-level security integration. Updated reports for each board-level vulnerability fix. Test reports covering end product security features. Updated reports for each product-level vulnerability fix.
CE marking Art. 29-30 Required on TI components placed on the EU market Required if Tier 1 places module on EU market independently Required on the end product
Authorized EU representative Art. 18 TI maintains EU presence Required if Tier 1 is not established in EU Required if OEM is not established in EU
Coordinated vulnerability disclosure (CVD) policy Annex I, Part II, item 5 TI PSIRT policy Tier 1 own CVD policy OEM own CVD policy for their product
Vulnerability reporting contact Annex I, Part II, item 6 psirt@ti.com Tier 1 security contact OEM security contact published to end users
Report actively exploited vulnerabilities Art. 14 TI notifies national CSIRT and ENISA concurrently using the CRA Single Reporting Platform - see Article 14 - Reporting Obligations for Manufacturers for the full notification sequence. Tier 1 notifies national CSIRT and ENISA concurrently - see Article 14 - Reporting Obligations for Manufacturers for the full notification sequence. OEM notifies national CSIRT and ENISA concurrently - see Article 14 - Reporting Obligations for Manufacturers for the full notification sequence.
Support period declaration Annex II, item 7 Lifecycle guide per device family Module support period declared Product support period declared to end users
Technical documentation Art. 31 Component-level technical documentation Module-level technical documentation Full product technical documentation