Unlike most cyber security regulations, the EU’s Cyber Resilience Act is about product safety rather than processes or certification, extending the CE mark from the physical side of products to software, firmware, backend services, and anything with a network connection. It encodes existing best practices, enforces minimum product support lifecycles, and could mean developing stronger relationships with open source projects your organization relies on. And it comes with a deadline: by September 11 this year, you need to have vulnerability and incident reporting processes in place.

Even for organizations already using software bills of materials (SBOMs), following new CRA obligations to report an actively exploited vulnerability in a product within 24 hours, and having to deliver a full report within three days may prove hard to meet.

Although nearly everyone in SaaS alternative Cloudsmith’s recent Artifact Management Report generates SBOMs, only a quarter do that automatically rather than manually or on demand. Over half said a comprehensive report would need significant time and effort, while fewer than a third were very confident they could pass the kind of unexpected software supply chain audit the CRA’s spot checks will require.

“A lot of organizations weren’t doing software supply chain best practices,” says Alison Sickelka, VP of product at Cloudsmith. “And that’s reflected in people having to scramble to figure out how they’re going to generate SBOMs, do reporting, and have all that in place in time.” Sometimes seen as a burden slowing down software development, SBOMs and auditability are now necessities, she adds.

For a lot of CIOs, though, the CRA isn’t even on their radar. “They may think it’s almost a tick box exercise,” says Oli Venn, engineering manager at security vendor WatchGuard, rather than a broad regulation with aggressive reporting requirements covering the entire product lifecycle from planning and design, to support and maintenance.

“If you’re any kind of vendor, or you’re manufacturing or supplying any digital system, whether it’s smart thermostats, coffee machines or anything else that can be connected to the internet or a network, that falls into regulation,” he adds. “If you’ve got developers and consumers using that in any way, then you fall into scope for the CRA.”

Spheres of influence

The CRA applies to software and devices like mobile phones, embedded operating systems, databases, games, network equipment, IoT devices, and even tickets delivered through an app. However, it doesn’t apply to non-commercial open source, but open source foundations have some obligations. And if your product includes open source elements, you’re responsible for making sure they’re compliant. Pure SaaS isn’t covered but client software, appliances, or devices that use SaaS as a backend are.

“The CRA includes backend components, what we call remote data processing solutions, if you have a server side to your product,” says Daniel Ehrenberg, a standards engineer on ETSI’s Cyber EUSR committee.

Products already on sale in the EU don’t have to fully comply with the CRA, unless they get significantly updated, though companies still have to report incidents and vulnerabilities. Yet the act recognizes it may not be possible to address them. Otherwise, the only products exempt are those already covered by more stringent regulations in sectors like automotive and medical.

Product safety

The CRA says digital products have to be secure by design and default, and can’t ship with known vulnerabilities like obvious default passwords that can be exploited. They also must be updatable if such vulnerabilities are found later, as well as minimize their impact by limiting the attack surface and protecting confidentiality and integrity with encryption and reduced data collection. That amounts to a mandate that commercial software must handle them well, explains Ehrenberg, with an effective process to take bug reports.

“There’s been a lot of hope that somehow this won’t happen, but it’ll be a wake-up call to consider all the requirements, starting with a risk assessment,” he says. “When you’re putting a product on the market, you have to do an assessment of the cyber security risks, and have a continuous audit to know what your live dependencies are so you can evaluate whether you need them updated.”

That includes components from vendors. “Be sure they’re staying compliant and reporting any security vulnerabilities,” Venn says. The SBOM requirements are sensible rather than onerous, adds Nigel Douglas, head of developer relations for Cloudsmith. “Do you have visibility into package names and IDs so you can tell if the version in your software supply chain and the code base that users are consuming and paying for carry potentially malicious code that’s going to affect them,” he says. “The main thing is being able to prove you can quickly respond to an incident.”

For open source, it also means assessing projects you rely on. “The CRA mandates knowing about and understanding project health and making informed, intelligent decisions about open source projects you use,” notes Kubernetes steering committee member Kat Cosgrove. Organizations that discover and fix vulnerabilities in open source projects will be required to contribute that upstream, Venn points out. “They can no longer just be consumers of these technologies,” he says. “If they want to use it, they have to be a part of the community.”

Not like the others

Unlike traditional cybersecurity regulations, the CRA focuses not on software development practices and certifications, which Ehrenberg warns may not map to the new requirements, but on the product being sold. “Did you achieve a product that minimizes the amount of data that’s being processed in order to reduce risks related to data if it’s not properly managed?” he asks. “Are you protecting data as it’s at risk and in transit?”

CIOs need to consider the products their organization sells in a top-down way, looking at how they meet security requirements rather than whether the way they’re built checks all the boxes. “It’s a shift in responsibility,” he adds “You’re responsible for the final product, not just making sure the steps were correct.”

Requirements also mandate product support, updates, and lifecycles, in most cases for a minimum of five years of free security updates, all of which go in a declaration of conformity digital products will require from December 2027. The declaration and documentation will need to stay available for 10 years after the product goes on sale, but the SBOM doesn’t need to be public, just available to the market surveillance authorities when they ask for it.

Standards in practise

Different classes of products attract different levels of scrutiny. Most digital products get default regulation under horizontal standards for cybersecurity and vulnerability handling that’s already available in draft form from European standardization organizations.

But important products like including identity management systems, web browsers, password managers, VPNs, and internet access routers, as well as critical products such as hypervisors, PKI infrastructure, hardware security modules, and industrial firewalls, will require more stringent conformity assessments.

These are covered by vertical standards being developed to analyze specific risks, which list potential mitigations like writing a web browser in a memory-safe language. “The CRA doesn’t require you to transition to memory safe languages, nor move off COBOL or anything like that,” Ehrenberg says.

Timelines and fines

As a regulation rather than a directive, the CRA applies without individual European countries passing new laws, and the mechanisms for it to be administered are being set up this summer. “The market surveillance authorities are coming online with their ability to review and approve things, then the individual conformity assessment bodies come online,” Ehrenberg says. The European Union Agency for Cybersecurity (ENISA) will run the single platform for reporting actively exploited vulnerabilities and incidents.

Although the CRA applies fully from 11 December 2027, enforcement will come in gradually and will depend on the technical capacity of the market surveillance authorities, says Ehrenberg. They can insist products be made compliant, restrict their sale, or have them withdrawn or even recalled, as well as levy fines of up to €15 million or 2.5 % of turnover.

“There are probably going to be court battles in the future to interpret this,” Ehrenberg says, as aspects have already been criticized for being too vague and weak. But organizations relying on limited enforcement are missing an opportunity to improve their products and their own security.

Simply better security

With the rise of supply chain attacks, CRA mandates will provide real security benefits by forcing enterprises to track their open source usage and notify end users of issues promptly, says Neil Levine, SVP of products at cybersecurity vendor Anchore. He suggests adopting SBOMs by September to help you comply with reporting requirements, rather than waiting until the 2027 deadline.

Savvy CIOs can also use this as an opportunity to get the resources to deliver improvements. “Most CIOs would want to do these things anyway but just don’t have the bandwidth,” says Venn. “So this is probably a tool for them to go to the board and say they need the budget and the time.”