Sbom and safe by design
For decades, the path to a product’s CE marking focused predominantly on physical and electromagnetic integrity. Did it shock or start a fire? Did it interfere with other devices? In short: electrical safety and EMC. Now also cybersecurity will become crucial, and will be managed with tools like the SBOM.
With the rise of IoT and Connected products, the landscape of regulatory compliance is fundamentally shifting. The European Union’s Cyber Resilience Act has arrived. It will be in full effect by December 2027.
This act has added a critical, non-negotiable third pillar: digital resilience. For any product with a digital element, from smart fridges to industrial controllers, cybersecurity is no longer an optional feature.
It is now a market-entry requirement. This new focus means the most important file in your company is the technical documentation used for certification. It must be completely rewritten to include proof of Secure by Design principles.
One the most critical key document is the Software Bill of Materials (SBOM).
The New Third Pillar of Certification
For years, we treated electrical safety and EMC as the two main pillars of market entry. If your product passed the dielectric strength test and stayed within radiated emission limits, you were generally cleared for the market. But with the CRA coming into full effect by December 2027, a third pillar has been permanently established: digital resilience. This is no longer a “best practice” or a suggestion for high-end IT equipment. It is a fundamental, non-negotiable requirement for any product with a digital element, from a simple smart plug to a complex industrial controller.
The implications for your technical documentation are massive. You can no longer present a dossier that only discusses hardware components and PCB layouts. Your documentation must now prove that your product was built using Secure by Design principles. If you cannot prove how you managed vulnerabilities during development, your certification is essentially incomplete.
The SBOM
If your product’s hardware Bill of Materials (BOM) is the list of every resistor, capacitor, and wire used in assembly, it is essential for proving electrical safety. Then the Software Bill of Materials (SBOM) is the digital equivalent. It’s an inventory of every software component, library, and module (especially open-source and third-party components) built into your product.
The SBOM must be a central part of your product’s technical documentation dossier, which is maintained throughout the product’s lifecycle.
The CRA specifically mandates that this SBOM must, at a minimum, cover top-level dependencies and be delivered in a common, machine-readable format (such as SPDX or CycloneDX).
But why is this level of detail now a regulatory requirement?
- Vulnerability Mapping: When a major vulnerability (like Log4Shell) is announced, a compliant manufacturer with an accurate SBOM can instantly query the document and identify every affected product and customer, allowing for a rapid, targeted patch. A manufacturer without an SBOM is essentially flying blind, risking massive fines and reputational damage.
- Supply Chain Transparency: It provides market surveillance authorities (and, upon request, customers) a view into the software supply chain, which is crucial given that most security flaws originate in third-party or open-source components.
- Post-Market Surveillance: It allows manufacturers to fulfil the CRA’s obligation to monitor vulnerabilities for the entire product support period (often five years or more), demonstrating a continuous commitment to cyber resilience far beyond the initial certification. The implications for the CE marking are significant. It acts as a continuous declaration of both physical and digital safety. (see this guide on the [CE Marking and the CRA] to learn more about the formal requirements).
Treating the SBOM as a mere checklist is a bad approach. It’s a dynamic document that must be updated whenever you patch, update, or change a component. Therefore, its creation must be automated and integrated into your development pipeline, not cobbled together at the last minute for a regulatory audit.
Understanding the Software Bill of Materials (SBOM)
If you have ever managed a production line, you are intimately familiar with the traditional hardware Bill of Materials (BOM). You need to know exactly which capacitor is on a board so you can track batches if a component failure occurs. What is the difference between a BOM and a SBOM? While the BOM tracks physical parts, the Software Bill of Materials is the digital equivalent. It is a nested inventory of every software component, library, and module used in your product. This includes the open-source code that your developers integrated during the build.
To understand why this document is now a regulatory cornerstone, we have to look at the constituent parts of the digital record. The following elements form the backbone of your software transparency strategy.
- Top-Level Dependencies: These are the primary software packages that your team has explicitly chosen to include in the project.
- Transitive Dependencies: These are the “hidden” libraries that your top-level components rely on to function correctly.
- Version Data: Precise versioning is required to determine if a specific component is susceptible to known exploits.
- License Information: This helps ensure that the software used does not violate legal terms or create intellectual property risks.
These parts are not just labels in a file. They represent a fundamental shift in how we track the lineage of our products throughout their entire lifecycle. When a regulator asks “What is in a SBOM?”, they are looking for this comprehensive map of your digital supply chain.
Is the SBOM Mandatory?
One of the most frequent questions I hear in the lab is, “Is SBOM mandatory?” The answer is a definitive yes under the Cyber Resilience Act. Why is SBOM required? Because without it, you cannot perform effective post-market surveillance or vulnerability mapping. If a major vulnerability like Log4Shell is announced, a compliant manufacturer with an accurate SBOM can instantly query their records and identify every affected product.
A manufacturer without this data is essentially flying blind and risking massive fines. This transparency is now viewed as a prerequisite for safety, similar to how we document fire-retardant materials.
Why is the SBOM Mandatory?
The requirement for an SBOM is a direct response to the increasing complexity of modern supply chains. Without it, you cannot perform effective post-market surveillance or vulnerability mapping. If a major vulnerability like Log4Shell is announced, a compliant manufacturer with an accurate SBOM can instantly query their records and identify every affected product. It is relevant also for industrial products in scope of EN 50742.
A manufacturer without this data is essentially flying blind and risking massive fines. This transparency is now viewed as a prerequisite for safety, similar to how we document fire-retardant materials. For more details on the legislative background, you can visit the European Commission page on the Cyber Resilience Act.
Challenging the Checklist Mentality
I often see companies treating the SBOM as just another box to tick on a compliance spreadsheet. This is a dangerous and fundamentally bad approach that will lead to significant regulatory friction. If your SBOM is a static document generated once and forgotten, it is already obsolete. Modern software environments change rapidly, and a compliance record must reflect the reality of the code currently running on the device.
To truly meet the “Secure by Design” requirements, you must move toward automated, continuous compliance. The following practices are essential for keeping your technical documentation accurate and useful.
- Automate Generation: You should use tools that scan your repositories and generate SBOMs in formats like CycloneDX or SPDX with every single software build.
- Integrate SBOM in CI/CD: By making the SBOM part of the continuous integration and delivery pipeline, you ensure that the record is always up to date.
- Define the Support Period: You must explicitly state in your instructions for use how long you will provide security updates.
- Establish Vulnerability Handling: Create a documented plan for how you will report exploited vulnerabilities to ENISA within the mandatory 24-hour window.
These steps ensure that your technical documentation is a reflection of reality rather than a snapshot of a moment that has passed. By automating the process, you ensure that your certification claims are backed by hard, verifiable data. This level of integrity is what will define “quality” in the digital age.
Technician Insight: Don’t confuse SOUP (Software of Unknown Provenance) with an SBOM. SOUP is a term used heavily in medical device standards (like IEC 62304) to describe third-party code. The SBOM is the formal document used to track and report that SOUP and other components for regulatory compliance.
Practical Steps to Update Your Compliance Process
The transition to CRA compliance demands a shift in mindset. You must align your software development process with your existing regulatory workflow. This starts with choosing a machine-readable format that the industry recognizes. Currently, the most common formats used for this purpose are CycloneDX and SPDX.
When you begin integrating these tools, you will likely discover that your “attack surface” is larger than you anticipated. This is why the major use case of SBOM is not just compliance, but active risk reduction. Does SBOM include vulnerabilities? Not directly, but it is the “key” that allows vulnerability scanners to tell you exactly which parts of your code are broken.
For manufacturers dealing with high-risk products, the complexity only increases as they must navigate overlapping deadlines. For instance, those using machine learning must also consider the [EU AI Act Compliance Timeline] to ensure their digital resilience measures satisfy both sets of regulations. The path to a valid CE mark now requires a deep understanding of both the physical and the virtual.
The Intersection of Software and Electrical Safety
We must emphasize that software can directly affect physical safety. In the context of EN 62368-1, we look at energy source classifications. If a software exploit can allow a hacker to override a thermal cutout or increase the output voltage of a power supply beyond safe limits, that software is now a safety-critical component. The CRA recognizes this. Your risk assessment must now bridge the gap: “Could a digital vulnerability lead to a physical fire or shock hazard?” If the answer is yes, your SBOM becomes as important as your insulation coordination records.
SBOM Best Practices for Small Manufacturers
For smaller firms, the jump to full automation can be daunting. What are SBOM best practices? 1. Start with the Build: Don’t try to create an SBOM by looking at your source code manually. Use a “build-time” tool that sees exactly what is being compiled into the final binary. 2. Use Machine-Readable Formats: Never provide an SBOM as a PDF. It must be in JSON or XML (CycloneDX/SPDX) so that your customers’ security tools can read it automatically. 3. Include the Hash: Every component in your SBOM should have a unique cryptographic hash (like SHA-256). This ensures that the component hasn’t been tampered with or replaced by a malicious version. 4. Update with Every Patch: If you push a firmware update to fix a bug, you must generate a new SBOM. The old one is no longer a valid representation of the product on the market.
