The EU Cyber Resilience Act is coming for your software

The Cyber Resilience Act is the EU's answer to twenty years of insecure consumer and business software being sold into the bloc. It applies to "products with digital elements" placed on the EU market, which is regulator language for almost anything that ships with code in it. The compliance deadline is December 2027. The enforcement mechanism is a fine of up to fifteen million euros or 2.5% of global turnover, whichever is larger.

A new survey from the Open Source Security Foundation found that two-thirds of manufacturers and developers worldwide are "not familiar at all" or "only slightly familiar" with the act. In the US and Canada the figure is 72%. The UK number is not separately reported but, anecdotally, looks similar. The deadline is eighteen months away and most of the businesses it will land on are not yet aware of it.

This filing covers what the CRA actually requires, what an SBOM is, and what a UK SME should do about both before the deadline.

Who it applies to

The CRA does not care where you are based. It cares where the product is sold. Any software, firmware, or hardware-plus-software that is placed on the EU market by a "manufacturer" falls in scope. The exemptions are narrow: pure SaaS that does not ship binaries to the customer is partly outside; bespoke software written for one customer is partly outside; medical devices, automotive, and aviation already have their own equivalents.

That leaves a long list of things that are inside. The shrink-wrapped Windows app you sell to UK and EU customers. The mobile app on the iOS and Android stores. The internet-connected device you build and ship. The downloadable installer for the on-premises version of your SaaS product. The firmware in your hardware. The Docker image you publish on the public registry. The open-source library you maintain as a commercial side-business.

The OpenSSF survey numbers that should worry an SME selling into Europe:

41% of manufacturers have not determined whether the act applies to them.
45% are uncertain about the compliance deadlines.
56% are unaware of the penalties for non-compliance.
54% are unclear on the different obligations for "manufacturers" and "stewards", which are two distinct CRA categories with different duties.
Only 32% of manufacturers currently produce an SBOM for all of their products.

The third and last numbers are the most operationally important. The penalties bite from December 2027 and the SBOM is the practical evidence regulators will look at first.

What the CRA actually requires

Strip the legal language away and the act asks for five things from a manufacturer.

Security by design. The product is designed to be secure for the duration of its expected lifetime, not just at the moment of shipping. The lifetime question is one the act forces you to answer in writing.

Vulnerability management for the lifetime of the product. When a vulnerability is found in your product or in the open source it depends on, you have a process to triage, patch, and notify. The patch has to reach customers; "we fixed it in the next version" without a clear update path is not enough.

Documentation, including an SBOM. A list of the components, the dependencies, the open-source libraries, the versions, and the relationships between them. The SBOM has to be machine-readable, in a standard format, and updated when the software changes.

Security disclosure and notification. Vulnerabilities are reported to the European Union Agency for Cybersecurity (ENISA) and, depending on severity, to customers. The notification window is twenty-four hours for actively exploited vulnerabilities.

A duty of care across the supply chain. Manufacturers are responsible for the security of the components they include, even when those components are open source. "We just use Log4j" stops being a defence the moment you ship the binary.

The Log4j case is the worked example regulators keep coming back to. When Log4j2's "log4shell" vulnerability hit in late 2021, the firms that suffered most were the ones who did not know which of their products contained Log4j. Identifying the affected products took weeks. The CRA's SBOM requirement is the regulator's bet that next time, the inventory will already exist.

What an SBOM is and what an SBOM is not

An SBOM, software bill of materials, is the parts list for a piece of software. For each component it records the supplier, the component name, the version, the dependency relationship to other components, the licence, and known security issues. The two common formats are SPDX (the Linux Foundation's format) and CycloneDX (OWASP's). Both are machine-readable. The regulator does not care which you pick as long as it is one of them.

What an SBOM is not. It is not a security control. The SBOM does not stop a vulnerability; it makes the affected products findable when the vulnerability is announced. The value of having one is entirely operational. When the next log4shell hits, the firms with an SBOM run a query and produce a list. The firms without one start asking engineers to remember.

What an SBOM also is not is a one-off document. The CRA requires it to be kept current. In practice this means the SBOM is generated by a tool, on every build, as part of the software delivery pipeline. The tools that do this for free or cheaply are mature. Black Duck, Snyk, Mend, and FOSSA are the commonly named commercial ones; Syft, Trivy, and the SPDX tools are the open-source equivalents. For most SMEs an open-source generator wired into the build is the right starting point.

What a UK SME should do this year

Three steps put a small business in a defensible position before December 2027 without overcommitting.

Decide whether you are in scope, in writing. This is the 41% question from the OpenSSF survey. The answer is short: do you place a product with digital elements on the EU market, including via app stores. If yes, the CRA applies. If you genuinely cannot tell, the safe assumption is that it does. Write the answer down, with a date, and the reasoning. Auditors and customers will ask.

Generate an SBOM for each product you ship, and store it. For one product, this is a day's work with an open-source tool. For five products it is a week of integration. The output is one machine-readable file per product per version, stored where you can find it later. The SBOM is also useful before the CRA bites: customer procurement teams are already asking for it on contracts above a certain size.

Write a vulnerability-handling policy and a customer-update path. Two pages. How you accept reports, how you triage them, the time targets for confirming and fixing, how you notify customers, and how an update reaches them. The CRA prescribes most of the shape; you fill in the operational details. The notification clock starts the moment you become aware of an actively exploited vulnerability and the window is twenty-four hours to inform ENISA. That obligation cannot be met from a standing start; the process has to exist beforehand.

The shape of the bigger problem

The OpenSSF survey also surfaced a number that is worth flagging on its own. 51% of organisations passively rely on upstream open-source projects for security fixes, while maintaining an average of 86 private forks per organisation. The cost of those private forks works out to roughly $258,000 per release cycle in labour. Most firms are unaware of either number. The CRA's SBOM and vulnerability-handling requirements will surface both: you cannot manage what you cannot list.

The deeper consequence of the act is that the firms with mature SBOM and patching processes will find it cheap to comply. The firms without them will find it expensive, and a portion of them will respond by withdrawing from the EU market. That is partly the point of the regulation. The market is being asked to choose between paying the cost of security and paying the cost of staying out.

For most UK SMEs the right answer is to start the SBOM work this quarter and have it ready in twelve months, not to wait for December 2027 and a customer questionnaire arriving with a deadline.

How Steelwise can help

Working out whether the CRA applies to your products, getting an SBOM generator wired into your build, and drafting the vulnerability-handling policy is the kind of practical work we do with clients. Get in touch.