English
Français
繁體中文
Most of what’s been written about the EU Cyber Resilience Act (CRA) treats it as an engineering security problem: secure-by-design principles, vulnerability disclosure timelines, and Software Bills of Materials (SBOM) that can be produced in CycloneDX or SPDX format on demand.
I understand the appeal. Security teams are used to owning compliance mandates, and SBOM generation looks like a solvable tooling problem. Point a scanner at the build pipeline, get a machine-readable output, file it away.
But an SBOM is a claim about your bill of materials. It isn’t a replacement for one.
The harder part comes when something goes wrong. A newly identified vulnerability has to be traced to the affected component or software, then to the configurations and product variants that use it. Supplier decisions and changes come into play. So do products already on the market.\
Suddenly, generating the SBOM looks like the easy part.
The CRA treats product security as a standing obligation, not a launch-day checkbox
The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU law that covers “products with digital elements,” including hardware, software, and products that combine the two, on the EU market. It entered into force on December 10, 2024.
In broad terms, the CRA requires manufacturers to address cybersecurity from the design stage, maintain information about product components and vulnerabilities, handle vulnerabilities after a product ships, and meet reporting obligations when certain security problems occur.
The obligations don’t all arrive at once. Reporting requirements apply from September 11, 2026. Full compliance requirements, including CE marking, apply from December 11, 2027.
Non-compliance can carry significant penalties.
The operational challenge starts much earlier. Manufacturers need to know what is in a product and keep that information current enough to respond to a security issue when it arises.
Viewed that way, the CRA is also a product-data and traceability problem.
The clock starts this month, not in 2027
CRA’s full compliance deadline, including CE marking and conformity assessment, is December 11, 2027. That’s the date most people remember, which makes the regulation still feel comfortably in the future.
But the reporting obligations start September 11, 2026.
For certain actively exploited vulnerabilities and severe incidents, the timelines include an early warning within 24 hours and a more detailed notification within 72 hours.
Think about what has to happen during those 72 hours. Where did the affected component come from? Which configurations use it? Did a supplier change it? Which released products are affected?
There isn’t much time to go looking for those answers.
This is the distinction I think gets lost when CRA is framed mainly as an SBOM problem. An SBOM tells you what your systems believe is in the product. Once a vulnerability is found, the surrounding product definition becomes just as important.
Can you connect the affected component or software dependency to the right release? The right configuration? The supplier decision behind it? And can you identify the products that actually made it to market?
That is where traceability becomes operational rather than theoretical.
An SBOM is only as accurate as the product definition supporting it
A software bill of materials has to be generated from something.
That gets complicated quickly when the bill of materials is maintained in one system, and the manufacturing BOM has drifted into another. Supplier information may be sitting in an email. Some changes may never have been cleanly made back into the governed product record.
The SBOM inherits those gaps. Machine-readable doesn’t necessarily mean complete.
Electronics manufacturing makes this particularly easy to see. PCBA data is still often handed downstream as a part number plus a package of manufacturing files, while design intent, approved sources, substitutions, and manufacturing decisions may be kept elsewhere.
Then reality intervenes.
A component becomes unavailable. An alternative gets qualified. A supplier makes a different decision to keep production moving.
The question later is whether anyone can trace what happened. Did the substitution make it back into the product record? Can engineering, manufacturing, compliance, and security see the decision and understand where it applies?
Software has the same problem in a different form. Firmware versions change. Open-source dependencies evolve. Configurations diverge. Supplier-provided software may move independently of the mechanical or electrical definition.
Over time, the product in the market can look quite different from the product definition the enterprise thinks it has.
Here’s a useful test: identify a vulnerability in one component or software dependency and try to find every affected product, configuration, and variant within 72 hours. Then prove the answer.
For many manufacturers, that exercise will uncover problems that have little to do with vulnerability scanning.
Compliance assembled at release time doesn’t survive an incident clock
A familiar pattern across regulated manufacturing is to reconstruct compliance status near a release gate. Someone pulls information from engineering systems, supplier declarations, spreadsheets, email, and the ERP system. The evidence gets assembled and reviewed, and the product moves forward.
It’s cumbersome. But it can work when the company controls the deadline.
An incident is different.
A vulnerability can be disclosed tomorrow morning. A supplier can identify a problem months after products have shipped.
At that point, the clock is already running.
The relationships between the product, component, software, configuration, change, and supplier evidence need to be available. Reconstructing them under pressure is not much of a strategy.
This is where CRA exposes a problem manufacturers have lived with for years. Fragmented product data creates rework, slows decisions, complicates change management, and makes compliance harder.
Now it carries another risk. The deadline can come from outside the company.
Lifecycle traceability is what makes a fast response possible. The SBOM identifies what is supposed to be present. Traceability helps answer what happened around it: where it was used, what changed, which configuration was released, and what supplier evidence supported the decision.
Those connections matter when the reporting clock begins.
This is where the digital thread becomes practical
The digital thread has been discussed for years in terms of engineering efficiency, collaboration, and better decisions. The CRA gives it a much more immediate job.
Someone needs to be able to ask a difficult question about a product and follow the answer throughout its lifecycle without rebuilding the history from scratch.
That doesn’t mean putting everything into one giant system. For most enterprises, that’s neither realistic nor necessary.
It does mean maintaining the connections. A hardware change may affect a configuration. A supplier decision may change an approved source. Software may evolve separately but still belong to a particular released product. The evidence behind those decisions needs to remain connected as well.
PLM, MBSE, MBE, software lifecycle management, ERP, supplier systems, and security tooling all have a role. The bigger issue is what happens between them.
Do those relationships remain intact as the product changes?
The CRA provides a fairly unforgiving way to find out.
The work the CRA is really asking for
None of this is legal or compliance advice. Classification decisions, conformity-assessment paths, and specific reporting obligations should go through qualified legal and compliance counsel, not a vendor blog post.
For engineering organizations, though, CRA raises a practical question: can the product data support a fast answer under a hard deadline?
Most CRA content focuses on what the regulation requires. There is another question worth asking now, before the deadline arrives.
What does the engineering data need to look like to make that response possible?
The difference could determine whether a 72-hour notification is produced from governed information or turns into a fire drill involving emails, spreadsheets, phone calls, and memory.
The security tooling gets the headline. The governed product definition and the traceability around it are what make that tooling useful.
Recommended actions
None of these requires a finished CRA compliance program to start. They’re questions worth answering before the next deadline, not after it.
- Inventory what’s actually in scope. Identify which product lines qualify as “products with digital elements” under the CRA that would require a well-maintained SBOM. This is a classification exercise that belongs to compliance and legal counsel, not engineering alone.
- Find out where your bill of materials actually lives. Is there one governed BOM connected to compliance and supplier data, or several versions drifting apart across ECAD, ERP, and spreadsheets that nobody’s reconciled recently?
- Look for the substitutions that were not logged. Ask suppliers and fabricators directly whether component substitutions have gone through change control or simply been shipped. An honest answer is more useful than a comfortable one.
- Run the 72-hour test now, without the pressure of an actual incident. Pick one product and see how long it takes to trace a specific component or software dependency to every affected product, configuration, and variant. Then look at what evidence supports the answer. If the trace depends on someone’s inbox, spreadsheet, or memory, that is part of the problem the test is meant to expose.
- Treat compliance and supplier data as part of the product record. Whatever platforms hold engineering data should maintain the relationships between product definition, approved sources, compliance status, supplier evidence, changes, and released configurations, so the documentation trail becomes a byproduct of normal work rather than a project someone has to reconstruct before every release or incident response.
For a deeper look at how supply volatility, cross-domain change, and rising evidence expectations are converging on high-tech and electronics manufacturers, including the Digital Product Passport (DPP) and CRA specifically, see the companion piece, From Fragmented Data to High-Tech Resilience.
