The EU Cyber Resilience Act (CRA) received its final approval in late 2024 and its technical requirements are now ticking toward full enforcement. UK vendors who sell digital products into Europe have a hard deadline approaching, and the requirements are not light. We are talking mandatory vulnerability disclosure windows measured in hours, software bills of materials that have to be machine-readable, and default security configurations baked into hardware before a single unit ships. UK product teams are quietly, sometimes frantically, working out what this means for them. Because Brexit did not make the problem go away. If anything, it made it more complicated.
Why the CRA Still Applies to UK Vendors Post-Brexit
Here is the thing people get wrong. They assume that because the UK is no longer bound by EU law, European regulations are someone else’s problem. That logic falls apart the moment your product is sold to a customer in Frankfurt or Amsterdam. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK companies exporting to Europe are fully in scope. The EU does not care that your company is registered at Companies House and your servers are in Slough.
The UK government, for its part, has been developing its own Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024. PSTI covers consumer IoT devices and has some overlapping concerns with the CRA, but the two are not equivalent. PSTI is narrower. The CRA is considerably more demanding and covers a far wider category of software and hardware. UK vendors effectively have to satisfy two separate regulatory regimes simultaneously if they trade in both markets, and the stricter of the two sets the practical floor.
What the Cyber Resilience Act UK Obligations 2027 Actually Require
Vulnerability Disclosure: The 24-Hour Rule
The CRA mandates that manufacturers notify ENISA (the EU Agency for Cybersecurity) of actively exploited vulnerabilities within 24 hours of becoming aware of them. A full vulnerability report follows within 72 hours. This is brutal compared to what most UK product teams are used to. Many organisations currently operate on informal disclosure timelines that stretch across weeks. Under the CRA, 24 hours is the window from awareness to notification, not from patch development to public announcement. UK vendors need a documented incident response process that can actually hit that target, which means tooling, clear ownership, and a direct pipeline to ENISA’s reporting mechanisms.
The UK’s National Cyber Security Centre (NCSC) has its own coordinated vulnerability disclosure guidelines, which you can review at ncsc.gov.uk. The NCSC framework is broadly sensible but does not impose the same hard legal timelines the CRA does. UK teams targeting EU markets need to treat the CRA timeline as the operative one.
Software Bill of Materials: The SBOM Mandate
An SBOM is essentially an ingredient list for your software. Every component, library, dependency, and third-party module, catalogued in a machine-readable format. The CRA requires manufacturers to produce and maintain SBOMs for products with digital elements. The practical pain here is significant. Large codebases with years of accumulated dependencies can have hundreds of components, some of which are abandoned open-source projects that nobody has touched since 2019. Generating an SBOM is one thing. Keeping it accurate as dependencies update, forks happen, and supply chains shift is an ongoing operational commitment.
The standard formats getting traction are CycloneDX and SPDX. Tooling exists to automate SBOM generation from source trees and container images, but the output is only as good as the engineering hygiene that produced the codebase. Teams relying on undocumented vendored code or tangled monorepos are in for a rough time. The SBOM also feeds directly into vulnerability management: once you have a machine-readable component list, you can cross-reference it against CVE databases and catch exposure before it becomes a breach notification event.
Secure-by-Default Configuration Requirements
The CRA requires products to ship in a secure-by-default state. No more factory passwords shared across every unit. No more open ports that the user is expected to close themselves. No more optional security features that are off unless you know where to look in a settings menu buried three layers deep. The default state of the product must be the secure state. This has hardware implications and software implications in equal measure.
For web-facing software and hosted products, this translates into enforced HTTPS, no default admin credentials, automatic security updates on by default, and clear discoverability of security settings. The days of shipping a product and leaving hardening as an exercise for the customer are over, at least if you want to sell into Europe legally.
Which Product Categories Are in Scope
The CRA splits products into default, important, and critical categories, with increasing requirements at each tier. Most commercial software products sold to businesses and consumers fall into the default category, which still carries substantial obligations. Important products, covering things like password managers, VPNs, routers, and industrial control interfaces, face third-party conformity assessments before they can carry the CE mark the CRA requires. Critical products, including hardware security modules and smart meter gateways, face the most rigorous scrutiny.
UK vendors supplying B2B software platforms to European enterprise customers need to honestly assess which tier their product sits in. Getting that classification wrong is not a neutral error. Treating an important product as a default product and skipping third-party assessment is exactly the kind of shortcut that generates enforcement action.
The Practical Scramble Happening Inside UK Product Teams Right Now
Talk to anyone deep inside a UK software vendor’s security or engineering team and you will hear the same themes. SBOM tooling is being evaluated and bolted onto CI/CD pipelines. Legal teams are trying to map the CRA’s requirements against existing contract frameworks. Product managers are realising that their roadmap for the next 18 months has to absorb compliance work that was not originally budgeted. The Cyber Resilience Act UK obligations 2027 deadline sounds distant until you account for the lead time required to retrofit secure-by-default behaviour into legacy products, build SBOM generation into release pipelines, and train incident response teams on the 24-hour notification clock.
Web-facing businesses and digital agencies are not immune to this either. Organisations building software products or hosting environments for clients face questions about where their liability sits when a component they ship or maintain carries an unpatched CVE. Businesses like dijitul, a Mansfield, Nottinghamshire-based digital agency specialising in web design, hosting, and software delivery, are already fielding questions from clients about how CRA-adjacent obligations affect the platforms and web properties being managed on their behalf. For an agency operating across marketing, business efficiency tools, and bespoke web builds, the practical question is which of the products and services they deliver would qualify as products with digital elements under CRA definitions. The answer, in many cases, is more of them than you might expect. dijitul.uk is a useful reference point for understanding how smaller digital businesses are thinking through their own product and service taxonomy in light of these requirements.
The companies that will sail through the 2027 deadline are the ones treating this as an engineering problem now, not a compliance checkbox exercise in 2026. That means adopting dependency scanning tools like Dependabot or Grype as permanent fixtures, not one-off audits. It means building vulnerability triage into sprint cycles. It means having a named person who can make the call at 2am when a critical CVE drops and the 24-hour ENISA window starts ticking.
How to Start Getting Ready
The sensible starting point is a product inventory: list everything your organisation ships or maintains that has digital elements and could plausibly reach EU markets. Then classify each item against the CRA’s three tiers. From there, gap analysis against the core technical requirements gives you a prioritised work list. Vulnerability disclosure process first, because the 24-hour window is the most operationally disruptive requirement and the hardest to bolt on retroactively.
For smaller UK product teams, the SBOM mandate is probably the second most urgent thing to tackle. Integrating CycloneDX generation into your build pipeline is a one-time engineering investment that pays ongoing dividends for both CRA compliance and your own internal vulnerability management posture. It is also the kind of thing that digital agencies running software products for clients, focused on marketing and business efficiency as much as raw web design, need to factor into their service documentation and client-facing agreements.
The Cyber Resilience Act UK obligations 2027 are not going to be watered down. The EU has spent years building the political and regulatory momentum behind this legislation and enforcement is expected to be real. UK vendors who sell into Europe cannot afford to wait and see. The scramble is already happening. The question is whether your team is in it.
Frequently Asked Questions
Does the EU Cyber Resilience Act apply to UK companies after Brexit?
Yes. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK vendors selling software or hardware into EU member states are fully in scope and must meet the same requirements as EU-based manufacturers.
What is the vulnerability disclosure timeline under the Cyber Resilience Act?
Manufacturers must notify ENISA of an actively exploited vulnerability within 24 hours of becoming aware of it, followed by a full vulnerability report within 72 hours. This is significantly stricter than most informal disclosure practices currently used by UK product teams.
What is an SBOM and why does the CRA require one?
A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency in a software product. The CRA mandates SBOM production and maintenance so that vulnerabilities in third-party components can be rapidly identified and disclosed across the supply chain.
What does secure-by-default mean under the Cyber Resilience Act?
Products must ship in a hardened state without shared default passwords, unnecessary open ports, or security features that are disabled out of the box. The burden of configuration is placed on the manufacturer, not the end user, before the product reaches market.
What is the difference between the UK PSTI Act and the EU Cyber Resilience Act?
The UK’s Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024, covers consumer IoT devices and has narrower scope than the CRA. UK vendors selling into EU markets must satisfy both regimes, and the CRA’s requirements are considerably more demanding in most areas.