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.1 The Supply Chain Stack

Most embedded products incorporating TI silicon follow a layered supply chain: TI silicon at the foundation, TI SDK providing the firmware and software stack above the silicone, a Tier 1 manufacturer or SoM vendor integrating silicon and SDK into a board or module, and the OEM building the final product on top. The supply chain responsibility stack maps this stack and aligns the CRA requirements alongside each layer.

TDA54x TDA4VH AM62 CRA Shared Responsibility Across the Supply Chain Figure 3-1 CRA Shared Responsibility Across the Supply Chain

Section 3.1 shows how the CRA responsibilities are shared throughout the supply chain. TI addresses hardware- and component-level requirements (bottom two layers). Tier 1 suppliers and SoM vendors carry intermediate integration requirements. The OEM holds full product-level conformity responsibilities. Patches, advisories, and vulnerability reports form a circular disclosure loop (right oval, clockwise). Article 14 requires each manufacturer in the supply chain to independently report actively exploited vulnerabilities; national CSIRT and ENISA are notified concurrently at each manufacturer level (dashed arrows) - see Article 14 - Reporting Obligations for Manufacturers for reporting timelines and obligations by layer. Regulation (EU) 2024/2847 (Cyber Resilience Act).

The vulnerability disclosure chain in the supply chain responsibility stack shows how security advisories and patch obligations flow upward through the stack:

  1. TI issues a CVE advisory through TI-PSIRT
  2. The Tier 1 or SoM vendor incorporates that advisory into a board-level update and passes the advisory to their OEM customers
  3. The OEM patches the product and delivers the update to end users. If the vulnerability is being actively exploited, TI notifies the national CSIRT and ENISA concurrently under Article 14.

The Tier 1 or SoM vendor and the OEM carry the same obligation independently if either party becomes aware of an actively exploited vulnerability in the end product.

The CRA requires manufacturers to report two types of security events, each with a three-step notification sequence. The first - Track 1 - applies to actively exploited vulnerabilities such as known flaws in the product that attackers are using against users. Track 2 applies to severe incidents with a security impact on the product such as events that affect, or can affect, the ability of the product to protect the availability, authenticity, integrity, or confidentiality of data or functions, or that have led or can lead to the introduction or execution of malicious code in the product or in a user's systems. All notifications under both tracks are submitted simultaneously to the national CSIRT designated as coordinator and to ENISA through the CRA Single Reporting Platform.

Table 3-1 Article 14 - Reporting Obligations for Manufacturers
Deadline Content (verbatim)
Track 1: Actively Exploited Vulnerability (Art. 14(1)-(2))
Within 24 hours of becoming aware "an early warning notification of an actively exploited vulnerability...indicating, where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available"
Within 72 hours of becoming aware "a vulnerability notification...which shall provide general information, as available, about the product with digital elements concerned, the general nature of the exploit and of the vulnerability concerned as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take"
No later than 14 days after a corrective or mitigating measure is available "a final report...including at least: (i) a description of the vulnerability, including its severity and impact; (ii) where available, information concerning any malicious actor that has exploited or that is exploiting the vulnerability; (iii) details about the security update or other corrective measures that have been made available to remedy the vulnerability"
Track 2: Severe Incident with Impact on Security (Art. 14(3)-(4))
Within 24 hours of becoming aware "an early warning notification of a severe incident having an impact on the security of the product with digital elements...including at least whether the incident is suspected of being caused by unlawful or malicious acts"
Within 72 hours of becoming aware "an incident notification...which shall provide general information, where available, about the nature of the incident, an initial assessment of the incident, as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take"
Within 1 month of the 72h incident notification submission "a final report...including at least: (i) a detailed description of the incident, including its severity and impact; (ii) the type of threat or root cause that is likely to have triggered the incident; (iii) applied and ongoing mitigation measures"

Track 1 applies when a known flaw in the product is being actively exploited, and the reporting clock is tied to vulnerability discovery and remediation. Track 2 applies when a security event has already affected the product or the users, regardless of whether a specific vulnerability has been identified. The reporting clock for Track 2 is tied to the occurrence of the incident. The two tracks are not mutually exclusive. An actively exploited vulnerability that results in a security breach triggers both simultaneously, and each event requires an independent set of notifications.