EU Cyber Resilience Act makes transparency a CE requirement for connected products

With the Cyber Resilience Act, SBOMs, open-source governance, and supply-chain visibility are becoming essential for compliance and market access. In a three-part article series, eeNews examines various aspects of the CRA and, in particular, how companies should now proceed. As outlined in the first installment of the article series, the EU’s Cyber ​​Resilience Act (CRA), or Regulation (EU) 2024/2847, will make cybersecurity a mandatory CE requirement for connected products starting in 2027. The second part focuses on why “Security by Design” and “Secure by Default” will become mandatory, and what this specifically means for embedded and IoT developers. Now this third part brings together compliance and supply chain aspects. By the way, eeNews, together with Lemberg Solutions, is also organizing the free webinar “Building CRA-ready IoT products: the practical side of compliance” on 10 September, 2026. This webinar will show what a CRA-compliant SDLC looks like in practice. Registration for the webinar is now open. The new transparency requirement CRA is often discussed in the context of secure product design, vulnerability management, and software updates. However, one of its most significant implications lies elsewhere: transparency. Manufacturers will not only have to build secure products, they will also have to demonstrate that they understand exactly what is inside them, how security risks are managed, and how vulnerabilities are addressed throughout the product lifecycle. For embedded and IoT manufacturers, this represents a fundamental shift. Modern products are assembled from a complex mix of commercial software, open-source components, third-party libraries, cloud services, firmware modules, and increasingly sophisticated hardware platforms. Maintaining visibility across this ecosystem is becoming not merely a best practice, but a regulatory necessity. The CRA’s lifecycle approach means that security management does not end once a product reaches the market. Instead, manufacturers must continuously monitor vulnerabilities, maintain documentation, assess risks, and provide updates throughout a product’s supported lifetime. Why transparency matters The growing complexity of embedded systems has made it increasingly difficult to understand which components are present in a product and how they relate to one another. A modern industrial controller, for example, may contain: A real-time operating system (RTOS) Open-source networking libraries Cryptographic modules Third-party communication stacks Vendor firmware Cloud connectivity services Wireless modules and drivers When a critical vulnerability is disclosed, manufacturers must be able to quickly answer several of the following questions: Is the vulnerable component used in our product? Which product versions are affected? Is the vulnerability exploitable in our specific implementation? What mitigation or update is required? Without systematic component tracking, answering these questions becomes a time-consuming and error-prone exercise. The CRA effectively turns such visibility into a compliance requirement. The central role of the SBOM One of the most important tools for achieving CRA compliance is the Software Bill of Materials (SBOM). An SBOM is essentially an inventory of all software components contained within a product. It identifies software packages, component versions, dependencies, relationships between components, and licensing information. A well-maintained SBOM allows manufacturers to rapidly determine whether newly disclosed vulnerabilities affect their products. It also improves communication with customers, suppliers, auditors, and regulatory authorities. For embedded manufacturers, the SBOM provides a foundation for vulnerability management. Instead of manually investigating every security advisory, teams can quickly identify impacted products and prioritize remediation efforts. As security regulations mature, SBOMs are becoming a cornerstone of modern product cybersecurity programs. SPDX and CycloneDX: Different approaches to software transparency Several standardized SBOM formats are already widely available, with SPDX and CycloneDX emerging as the dominant approaches. SPDX (Software Package Data Exchange) originated within the open-source compliance community at Linux Foundation. Its primary goal is to provide transparency regarding software components and their associated licenses. SPDX helps organizations answer questions such as: Which open-source components are included in the product? Under which licenses are they distributed? Are there legal or intellectual-property obligations attached to their use? As a result, SPDX has become particularly valuable for compliance, legal, and procurement teams. CycloneDX emerged from the application security and DevSecOps community and focuses strongly on cybersecurity risk management. The OWASP Foundation and Ecma International Technical Committee for Software & System Transparency (TC54) drive the continued advancement of the specification. The format is designed to: Model software dependencies Track vulnerabilities Integrate with CI/CD pipelines Support automated security assessments CycloneDX allows organizations to connect software components directly to vulnerability information such as Common Vulnerabilities and Exposures (CVEs), enabling continuous security monitoring throughout the product lifecycle. In practice, many organizations are expected to use both approaches. While SPDX provides legal and licensing transparency, CycloneDX supports operational vulnerability management. Together they offer a powerful framework for meeting emerging cybersecurity and regulatory requirements. Open source remains essential The CRA does not prohibit the use of open-source software. In fact, open source remains a critical part of modern embedded and IoT development. Operating systems, networking stacks, cryptographic libraries, middleware, and development frameworks frequently originate from open-source projects. These components often benefit from extensive peer review and broad community support. However, the CRA makes clear that manufacturers cannot treat open source as a black box. Organizations must know which open-source components are used, which versions are deployed, what security vulnerabilities exist, and how vulnerabilities are monitored and remediated. Responsibility ultimately rests with the product manufacturer, regardless of whether software was developed internally or obtained from external sources. The lesson is clear: open source remains fully viable, but it must be managed systematically. What about legacy products? Many products currently deployed in the field were developed long before the CRA was conceived. The regulation does not impose a universal requirement to redesign every existing product. Nevertheless, manufacturers are expected to perform risk-based assessments of legacy systems and determine whether reasonable security improvements can be introduced. Possible measures include: Retrospective security evaluations Additional monitoring capabilities Enhanced update mechanisms Extended vulnerability management processes Clearly defined maintenance and end-of-life policies Where technical limitations prevent meaningful improvements, transparency becomes particularly important. Manufacturers should document constraints, explain risks, and establish clear support expectations. The CRA recognizes that perfection is rarely achievable in long-lived embedded environments. What matters most is demonstrable due diligence and traceability. Looking beyond software: The need for hardware transparency Although the CRA does not explicitly require a Hardware Bill of Materials (HBOM), many embedded-system developers see hardware transparency becoming increasingly important. Cybersecurity vulnerabilities do not only exist in software. Microcontrollers, communication modules, secure elements, processors, and other hardware components can also introduce risks into a product. As organizations seek greater visibility across their supply chains, a broader view is emerging: HBOM + SBOM + VEX = future transparency framework What does it mean? HBOM documents hardware components: What hardware does the product contain? SBOM documents software components: What software runs on it? VEX (Vulnerability Exploitability eXchange) provides information about whether a known vulnerability is actually exploitable in a specific product Together, these tools can help manufacturers evaluate vulnerabilities more accurately while reducing unnecessary remediation efforts. It is precisely this combination that is likely to establish itself as the de facto standard for CRA-compliant embedded and IoT products. Conformity assessment and product categories Not every product will undergo the same compliance process. The CRA distinguishes between several product categories with different conformity-assessment requirements. Most products with digital functionality fall into the standard products category. Examples include connected consumer products, standard industrial devices, and typical IoT products. Manufacturers can generally perform internal conformity assessments themselves. Then there are important products with significant cybersecurity implications, such as operating systems, firewalls, password managers, and cryptographic libraries may require additional scrutiny. In some cases, self-assessment remains possible when harmonized standards are fully applied. Deviations from those standards may require external review. Highly sensitive products, including Hardware Security Modules (HSMs), root-of-trust components, and critical network infrastructure require mandatory assessment by a notified body.  For affected manufacturers, these external evaluations may introduce additional cost and development effort, but are intended to provide a higher degree of assurance. The organizational challenge The biggest challenge of the CRA may not be technical. Many organizations already know how to implement secure boot, cryptographic functions, or signed updates. The more difficult task is building the processes needed to manage security over many years. Manufacturers must establish capabilities for: Secure development lifecycle management Vulnerability disclosure handling Patch management Security documentation Audit preparation Supply-chain transparency For many companies, especially small and medium-sized enterprises, this will require new skills, new tools, and closer cooperation between engineering, compliance, quality assurance, product management, and operations teams. The transition from project-based security to lifecycle-based security may prove to be the most significant transformation driven by the CRA. Compliance becomes an engineering discipline The Cyber Resilience Act represents more than another compliance obligation. It fundamentally changes how embedded and IoT products are developed, documented, maintained, and supported. Security alone will no longer be enough. Manufacturers must also demonstrate visibility into their software, hardware, dependencies, vulnerabilities, and supply chains. SBOMs, vulnerability management processes, transparency frameworks, and conformity assessments are becoming integral parts of product engineering. Organizations that embrace these practices early can turn compliance into a competitive advantage. Those that delay may face increasing costs, greater regulatory risk, and potentially restricted access to the European market. For the embedded and IoT industries, the message is clear: transparency is no longer optional. It is becoming a core requirement of product quality. Sources: Cyber Resilience Act – legal text FAQ – Cyber Resilience Act implementation (PDF) eeNews: Cyber Resilience Act, Part 1: The first deadlines are approaching eeNews: Cyber Resilience Act, Part 2: Security by Design becomes mandatory eeNews: What embedded developers need to know about the CRA Webinar: Building CRA-Ready IoT Products: The Practical Side of Compliance The post Cyber Resilience Act, Part 3: Transparency becomes a product requirement appeared first on eeNews Europe.