• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 134 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3351: Inquiry: TI CC3551 and CC3351 Support Status for EU CRA Compliance and Hardware Security Architecture Discussion

Mike Wu1
Genius 3151 points

Part Number: CC3351
Other Parts Discussed in Thread: CC3551E

Dear TI Team / [Name of AE / FAE],

Hope this email finds you well.

My client is currently developing a new generation of products utilizing TI's Wi-Fi 6 and BLE 5.4 solutions—specifically the CC3551 (Wireless MCU) and CC3351 (Companion IC). These products are primarily targeted at the European market.

As the EU Cyber Resilience Act (CRA) will officially mandate vulnerability and cybersecurity incident reporting starting this September (2026), and require full CE mark security compliance by 2027, my client is conducting a strict and comprehensive review of their product's security architecture.

To ensure my client's end products smoothly comply with the CRA regulations, I would like to inquire on their behalf about the current CRA support status and official technical guidelines for these two chips:

1. Software Bill of Materials (SBOM) and Continuous Vulnerability Patching (PSIRT)

  • Can TI provide machine-readable SBOMs for the CC3551 SimpleLink SDK, as well as the drivers and firmware for the CC3351?

  • Regarding the CRA requirement for continuous vulnerability patching throughout the product lifecycle, how should my client coordinate with TI's PSIRT to ensure they receive vulnerability alerts and security patches within the strict timeframes required by the regulation?

2. Security Implementation Guidelines for CC3551 and CC3351

  • CC3551: It integrates an Arm® Cortex®-M33 with TrustZone® technology. Regarding the CRA's emphasis on "Secure by Design," does TI provide reference designs or application notes on Secure Boot, Secure OTA updates, and how to isolate cryptographic keys from general applications?

  • CC3351: Since it operates alongside an external Host, how does TI address the CRA's anti-tampering and anti-rollback inspection requirements? Are there best practice guidelines for integrating the CC3351's firmware authentication and anti-rollback mechanisms on the Host side?

3. Competitor Architecture Discussion and CRA Compliance Clarification
Additionally, while evaluating other solutions on the market, my client noticed that a competitor, the ESP32-S3, specifically highlights the following security mechanisms in its official documentation:

"ESP32-S3 provides comprehensive security mechanisms and protection measures for IoT devices to prevent various malicious attacks and threats. It supports flash encryption based on the AES-XTS algorithm, secure boot based on the RSA algorithm, digital signatures, and HMAC. ESP32-S3 also adds a 'World Controller' module, providing two non-interfering execution environments to implement a Trusted Execution Environment (TEE) or privilege separation mechanism."

We would like to take this opportunity to consult TI's experts:

  • Does the mere presence of these hardware security features (Flash encryption, Secure Boot, TEE) mean the chip itself can directly "meet or pass" the European CRA's underlying requirements?

  • When benchmarking against this, what are the corresponding mechanisms in TI's CC3551 and CC3351 to achieve similar isolated environments, Flash encryption, and Secure Boot? Compared to this type of competitor architecture, does TI offer a more comprehensive, unique, or CRA-aligned advantage and service to help end customers achieve final CRA certification?

4. Official Certifications and Compliance Declarations

  • Has TI released any whitepapers, Declarations of Conformity (DoC), or third-party security verification reports for these two chips regarding the European CRA (or EU RED Article 3.3 security requirements)? This would greatly assist my client as supporting evidence when applying for the CE mark for future products.

With the regulatory reporting deadline approaching in the second half of this year, the underlying chip's security architecture is critical to my client's project timeline. If you have any relevant documentation, please kindly share it with us for evaluation. I would also be more than happy to help arrange a brief online meeting between my client and your team for further discussion.

Thank you very much for your continuous assistance and support. Looking forward to hearing from you.

Best regards,

Mike Wu