The clock is ticking: The two CRA deadlines to keep in mind
Two dates are shaping current preparation efforts.
September 2026: vulnerability reporting starts
Starting in September 2026, manufacturers must have processes in place to monitor vulnerabilities and report the vulnerability state of any equipment they commercialise. This marks the start of mandatory, ongoing vulnerability management.
This means manufacturers must know:
- every software component inside their device
- which vulnerabilities affect those components
- which are relevant in their context
- how they plan to mitigate or fix them
For open-source developers, this is especially important: community projects publish updates, but it is the commercial integrator, not the upstream developer, who holds responsibility under the CRA.
December 2027: Full CRA application
By December 2027, all requirements of the Cyber Resilience Act become fully applicable. Manufacturers will need to demonstrate that they:
- meet secure‑by‑design expectations,
- maintain documentation,
- perform risk assessments,
- update their products over time,
- and manage vulnerabilities continuously.
The missing puzzle pieces: Harmonised standards
However, the industry is still waiting for harmonised standards that will translate the broad legal requirements into concrete technical rules. These standards will clarify how to apply the law in practice, but as of now, manufacturers must interpret the regulation largely on their own.
Legislation vs specification: Why engineers are struggling
A major source of confusion comes from the nature of the CRA itself. It is a legal text, not a technical specification. Engineers are used to working from detailed, prescriptive requirements, but the CRA provides only about a page and a half of technical obligations. The rest describes legal concepts, responsibilities, and enforcement mechanisms.
This forces teams to work differently. Instead of implementing predefined specifications, they must derive their own requirements from the regulation’s intent. It means:
- perform risk assessments,
- interpret definitions,
- decide for themselves how the principles of the CRA translate into technical measures for their products
- justify their decisions through documentation
This is closer to legal reasoning than software development.
While this is uncomfortable for many teams, it is necessary and temporary. Harmonised standards will eventually fill this gap. Until then, manufacturers must rely on their own risk‑based processes.
Cyber Resilience Act & Open Source: Who holds responsibility?
One of the most debated topics is the definition of “manufacturer” for software components. When software integrators provide code that becomes part of a customer’s device, they often wonder how CRA responsibilities apply to them.
The CRA resolves this through the concept of commercial use. Open-source authors who make their work available freely are not considered manufacturers under the CRA. They are intentionally protected to preserve innovation in open-source communities.
Liability instead falls on the first commercial entity that integrates an open-source component into a product they intend to sell or monetise. Even if that company did not write the component, they become responsible for ensuring that the component meets CRA obligations in the context of their device.
This applies even if the commercial value comes not from the product itself, but from services built around it. Training, consulting, and integration services that monetise open-source components also qualify as commercial use.
This shifts responsibility to:
- integrators
- distributors
- device manufacturers
- service providers monetising the software
In other words: if you profit from open source projects, you inherit its risks.
The layered nature of modern software supply chains
To understand CRA responsibility, it helps to recognise that modern digital products are not monolithic artifacts. They are hierarchical compositions of hardware modules, drivers, operating systems, frameworks, libraries, middleware, and applications. Each of these layers may contain numerous sub‑components.
In the context of Linux‑based embedded systems, this can easily mean hundreds of software packages combined into a final product. The CRA applies to each of these layers. A PDE may refer to the final device, but it also applies to all the intermediate components that compose it.
This layered reality is why the CRA puts such emphasis on transparency.
SBOM: The backbone of CRA open-source compliance
Because devices are assembled from so many components, manufacturers must maintain a detailed Software Bill of Materials (SBOM). The SBOM is the foundation of the Cyber Resilience Act vulnerability management process. Without it, manufacturers cannot know what vulnerabilities affect their device.
An effective SBOM allows teams to:
- list every software component included in the product
- identify potential vulnerabilities in each
- understand whether vulnerabilities are relevant in their operational context
- determine how to respond (fix, mitigate, disable, or accept the risk)
- document all decisions to demonstrate compliance
Read our article on What is a Software Bill of Materials (SBOM)
Vulnerability analysis requires a combination of cybersecurity expertise and deep technical understanding. It is not enough to read the description of a CVE; teams must understand the software architecture, configurations, interfaces, and threat environment of their device.
And because open source software evolves continuously, SBOM maintenance must be automated and updated throughout the product lifecycle.
Managing open-source vulnerabilities: a continuous, never-ending process
Perhaps the most challenging aspect of CRA compliance is that vulnerability management is not a one‑time activity. New vulnerabilities appear constantly, and devices may remain in the field for ten or fifteen years.
Manufacturers need a continuous process to:
- consume vulnerability notifications
- analyse which vulnerabilities affect their configurations
- deploy patches or workarounds
- communicate updates to customers
- contribute fixes back to open-source communities (as required by the CRA)
Read our article on the CRA requirements for vulnerability management
This process demands both organisational maturity and technical tools like CVEScan. Many companies seek external support when building these capabilities for open-source and other components, especially during the early phases.
The double edged sword of composition
Thinking in terms of composition is essential. Reusing open source and third‑party components lets manufacturers build complex devices more quickly and efficiently.
Read our article on software composition
However, composition does not mean that responsibilities are delegated. Manufacturers retain full responsibility for every component they choose to integrate.
Some manufacturers hope that upstream communities, integrators, or vendors will provide “CRA‑compliant” versions of software, but compliance is not a product; it is a process. No component is CRA‑compliant on its own. Only the final assembled product can be assessed for compliance in its operational context.
At the same time, supply chain attacks (such as attempts to compromise widely used compression libraries) show why careful oversight of dependencies is essential. A single compromised component can undermine an entire system.
Conclusion: the Cyber Resilience Act and open source, a necessary evolution
The Cyber Resilience Act impact on open source software may feel daunting, especially in the absence of harmonised standards, but its requirements largely reflect established best practices. Once manufacturers analyse the regulation in detail, most find that they already perform many of the required activities ; just not always in a formalised, documented, or continuous way.
The CRA pushes the industry toward:
- better long‑term processes,
- more transparency,
- and stronger supply‑chain awareness.
It also reinforces the principle that open source is not just “free”; it is a shared ecosystem where commercial users must take responsibility for the components they rely on.
In an environment where nearly all commercial devices depend on open-source software, this shift is both necessary and overdue.
Pierre Gal, Head of Software, The Embedded Kit. Pierre brings 20 years of experience in embedded systems and software. He leads The Embedded Kit brand, delivering ready‑to‑use embedded software foundations that help manufacturers accelerate development with higher quality and stronger cybersecurity.
Michael Röder, Director, Software & Services, Avnet Silica. Michael heads Avnet Silica’s Software & Services Group in EMEA, supporting customers with training, consulting, engineering services, and long‑term maintenance strategies for secure, compliant connected devices.
