Cyber Resilience Act compliance stops being a 2027 problem in less than a month. On 11 September 2026 the reporting duties in Article 14 of Regulation (EU) 2024/2847 switch on, and any UK software company whose product reaches the European market inherits a 24-hour clock it probably has no process for. The rest of the regulation follows on 11 December 2027.
Most UK software businesses have filed Cyber Resilience Act compliance under “European hardware rules”. That reading is wrong in a way that gets expensive. The regulation governs products with digital elements, and software sold on its own is squarely inside that definition. If you ship a SaaS-adjacent installable, a mobile app, a library, an on-premise server product or firmware, Cyber Resilience Act compliance is a market-access condition for the EU, not an optional badge.
Leaving the European Union did not move UK vendors outside this. The test is where the product is placed on the market, not where the company is registered. A Manchester development shop with three German customers is in the same position as a Berlin one, minus the convenience of being established inside the Union. Our guide to NIS2 compliance for UK suppliers covers the operator-side regime that sits alongside this one; the CRA is the part that attaches to the thing you sell.
This guide sets out what Cyber Resilience Act compliance actually demands of a UK software company: which products are caught, how the classification tiers change your conformity route, what the essential requirements in Annex I mean in engineering terms, how the SBOM and vulnerability handling duties work, the support period trap, the three reporting clocks, the penalty ceilings, and a twelve-month programme that gets you to a defensible position without stopping feature work. Where it touches your wider IT security posture, we have flagged the overlap.
If you have already been through an EU procurement cycle, some of this will feel familiar — but the CRA is a different animal from a customer questionnaire. It is enforced by market surveillance authorities with the power to order a product off the market, and Cyber Resilience Act compliance is assessed against the product, not against your answers about it.
Table of contents
- What Cyber Resilience Act Compliance Actually Requires
- Why Cyber Resilience Act Compliance Reaches UK Software Companies
- The Cyber Resilience Act Compliance Deadlines That Matter
- How Product Classification Changes Cyber Resilience Act Compliance
- The Essential Requirements Behind Cyber Resilience Act Compliance
- SBOM and Vulnerability Handling for Cyber Resilience Act Compliance
- The Support Period Rule Most Teams Underestimate
- Cyber Resilience Act Compliance Reporting: 24 Hours, 72 Hours, 14 Days
- Cyber Resilience Act Compliance Penalties and Who Pays
- Cyber Resilience Act Compliance Next to NIS2, DORA and UK Rules
- A 12-Month Cyber Resilience Act Compliance Programme
- Cyber Resilience Act Compliance Mistakes UK Software Companies Keep Making
- Cyber Resilience Act Compliance Questions Answered
- References
What Cyber Resilience Act Compliance Actually Requires
The regulation behind Cyber Resilience Act compliance
The Cyber Resilience Act is Regulation (EU) 2024/2847. It is a regulation, not a directive, which matters more than it sounds: unlike NIS2, it does not need transposing into twenty-seven national laws. It applies directly and identically in every Member State. There is no Belgian version to comply with and no German variant to argue about. That removes the patchwork problem, and it also removes the delay — you cannot wait to see how your customer’s country implements it.
Products with digital elements: a deliberately wide net
The regulated object is a “product with digital elements”, meaning a software or hardware product and its remote data processing solutions. The phrasing was chosen to be hard to escape. Standalone software is explicitly included. So is firmware, so are components placed on the market separately, and so are the remote processing functions a product depends on to work. The narrow carve-outs are for products already regulated elsewhere — medical devices, motor vehicles, civil aviation, certain marine equipment — and for pure cloud services caught by NIS2 instead.
Why “software company” almost always means “manufacturer”
Under the regulation a manufacturer is whoever develops or has developed a product and markets it under their own name or trademark, whether for payment, for monetisation or free of charge. That last clause catches more UK firms than any other sentence in the text. If you give away a free tier, ship a community edition, or distribute an SDK under your brand as part of a commercial strategy, you are a manufacturer for Cyber Resilience Act compliance purposes. Charging money is not the trigger. Placing it on the market under your name is.
The two halves of Annex I
Annex I splits into Part I and Part II, and they ask for genuinely different things. Part I lists the security properties the product itself must have — secure configuration by default, protection of confidentiality and integrity, minimised attack surface, the ability to receive security updates. Part II lists the vulnerability handling processes the manufacturer must run for the whole support period — an SBOM, a disclosure policy, timely remediation, free security updates. Passing Part I is an engineering result. Passing Part II is an operating commitment that outlives the release.
What CE marking means for a software product
The end point of Cyber Resilience Act compliance is a CE mark, an EU declaration of conformity and a technical file. UK software teams often find this the strangest part, because CE marking has historically meant a physical label on a physical object. For software, the mark goes on the product, its packaging, or the accompanying documentation and the declaration of conformity. It is a legal claim that the product meets Annex I, and asserting Cyber Resilience Act compliance without the evidence behind it is itself an offence.
| Role | Who this is for a UK software company | Core duty under the regulation |
|---|---|---|
| Manufacturer | You, if the product carries your name or trademark | Meet Annex I, run conformity assessment, keep the technical file, report under Article 14 |
| Authorised representative | An optional EU-established appointee acting on your written mandate | Hold documentation, cooperate with market surveillance authorities |
| Importer | Your EU reseller or subsidiary that first places the product on the market | Verify the CE mark, declaration and technical file exist before selling |
| Distributor | EU channel partners further down the chain | Act with due care, stop distribution on evidence of non-conformity |
| Open-source steward | A foundation or entity sustaining an open project used commercially | Documented cybersecurity policy, cooperation, Article 14 reporting |
Why Cyber Resilience Act Compliance Reaches UK Software Companies
The market-access test, not the establishment test
The regulation applies to products with digital elements made available on the Union market. Nothing in that test refers to the manufacturer’s nationality or place of establishment. A UK company that lets an Irish customer download its installer has made the product available on the Union market. Cyber Resilience Act compliance therefore turns on distribution, not incorporation, and the honest question for a UK software business is not “does this apply to us” but “which of our products already reach an EU buyer”.
Brexit changed the paperwork, not the exposure
There is a persistent assumption in UK boardrooms that EU product regulation became somebody else’s concern in 2021. What actually changed is that UK firms lost the internal-market conveniences — they are now third-country manufacturers, which means the compliance burden sits more heavily on them, not less. UKCA marking does not substitute for CE marking here, and there is no domestic scheme against which Cyber Resilience Act compliance can be claimed as equivalent.
Where the importer and distributor obligations land
If you sell into the EU through a reseller or a local subsidiary, that entity is likely the importer, and importers carry real duties: they must check that the CE mark, the EU declaration of conformity and the technical documentation exist before placing the product on the market. In practice this is how Cyber Resilience Act compliance pressure reaches most UK vendors first — the channel partner refuses to ship until you hand over the paperwork, because their own liability now depends on it.
The authorised representative question
Unlike some EU product regimes, the CRA does not force a third-country manufacturer to appoint an EU authorised representative. Appointment is by written mandate and it is voluntary. That said, going without one leaves you with no established point of contact inside the Union when a market surveillance authority comes asking, and it makes the single reporting platform harder to work with in practice. Most UK vendors of any size should treat an authorised representative as a practical necessity rather than a legal one.
The contractual route that arrives first
Long before a regulator writes to you, your EU customers will. Enterprise buyers subject to NIS2 must manage supply chain security, and the cleanest way for them to evidence that a bought-in product is safe is to require CE marking under the CRA. Expect Cyber Resilience Act compliance clauses to appear in renewals from late 2026 onward, well ahead of the 2027 enforcement date. Our guide to supplier contract security requirements covers how those clauses are typically drafted and where to push back.
The Cyber Resilience Act Compliance Deadlines That Matter
11 September 2026: reporting goes live
This is the date UK teams keep missing. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products. It is not phased by product class and it does not wait for the rest of the regulation. If you ship software into the EU and a vulnerability in it is being exploited in the wild, the clock starts whether or not you have done any other Cyber Resilience Act compliance work.
11 December 2027: the full regime
The substantive obligations — Annex I essential requirements, conformity assessment, CE marking, technical documentation, the support period rules — apply from 11 December 2027. Products placed on the market before that date are generally not caught retrospectively unless they undergo a substantial modification afterwards, which for a continuously delivered software product is a distinction that erodes quickly.
11 June 2026: notified bodies
The provisions covering notification of conformity assessment bodies applied from 11 June 2026. That date has already passed. It matters because it starts the queue: if your product falls into a class that needs third-party assessment, the pool of notified bodies competent to assess it is still forming, and capacity is the constraint everyone underestimates.
What the phasing means for a UK release schedule
Read together, the phasing gives a UK software company roughly sixteen months to reach full Cyber Resilience Act compliance and roughly four weeks to stand up incident reporting. Those are very different projects, and the short one is the one nobody has resourced. Treat reporting readiness as a separate, immediate workstream rather than the first milestone of the larger programme.
| Date | What applies | What a UK software company must have ready |
|---|---|---|
| 10 December 2024 | Regulation entered into force | Nothing enforceable — the transition clock starts |
| 11 June 2026 | Notification of conformity assessment bodies | Notified body shortlist, if your product is Class I or II |
| 11 September 2026 | Article 14 reporting obligations | 24/72-hour process, named owners, platform access, rehearsed once |
| 11 December 2027 | Full obligations, CE marking, Annex I | Technical file, declaration of conformity, SBOM, support period published |
The gap between those last two dates is where most planning goes wrong. Here is the same picture measured in days from today.
How Product Classification Changes Cyber Resilience Act Compliance
The default category and Cyber Resilience Act compliance by self-assessment
The great majority of software products sit in the default category, and for them Cyber Resilience Act compliance is a self-assessment exercise. You apply the internal control procedure, produce the technical documentation yourself, draw up the EU declaration of conformity and affix the CE mark. No external body is involved. This is genuinely lighter than most UK teams fear, but “self-assessed” is not “unevidenced” — the file has to exist and stand up to inspection.
Important products, Class I
Annex III Class I is where a lot of B2B software lands, and the list reads like a catalogue of ordinary enterprise tooling: identity management and privileged access management software, browsers, password managers, antimalware, VPN products, network management systems, SIEM systems, boot managers, public key infrastructure and certificate issuance software, operating systems, and routers and switches. Class I products can still use self-assessment, but only if you apply the relevant harmonised standards or a European cybersecurity certification scheme in full. Otherwise a notified body is required.
Important products, Class II
Class II is shorter and stricter: hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. For these, third-party conformity assessment is mandatory. Self-assessment is not available at any level of standards adoption. If you build container tooling or network security software, this single paragraph is the most consequential part of your Cyber Resilience Act compliance planning, because it puts a notified body on your critical path.
Critical products under Annex IV
Annex IV covers hardware devices with security boxes, smart meter gateways, and smartcards and similar devices including secure elements. The Commission may require these to hold a European cybersecurity certificate at assurance level “substantial”. Very few pure software companies are affected, but component vendors sometimes are, and the lead times here are measured in quarters.
The harmonised standards dependency
Cyber Resilience Act compliance by self-assessment leans on harmonised standards that are still being written, largely through CEN and CENELEC. This creates an awkward planning problem: the cheapest conformity route depends on documents that may land late. The practical answer is to build against the Annex I text directly and treat standards as a mapping exercise you do later, rather than waiting for a standard to tell you to sanitise inputs.
| Category | Typical software examples | Conformity route | Notified body needed? |
|---|---|---|---|
| Default | Most business applications, mobile apps, SDKs, line-of-business tools | Internal control, self-assessment | No |
| Important, Class I | Identity and access management, password managers, VPNs, SIEM, browsers, operating systems | Self-assessment only if harmonised standards applied in full | Conditional |
| Important, Class II | Hypervisors, container runtimes, firewalls, intrusion detection and prevention | Third-party assessment or equivalent certification | Yes |
| Critical | Security boxes, smart meter gateways, smartcards and secure elements | May require a European certificate at assurance level substantial | Yes, plus certification |
The Essential Requirements Behind Cyber Resilience Act Compliance
Secure by design: the Cyber Resilience Act compliance baseline
Part I of Annex I opens with the requirement that products are designed, developed and produced so they deliver an appropriate level of cybersecurity based on the risks. It then requires a secure-by-default configuration, including the ability to reset the product to its original state. For a software company this means shipping with the restrictive configuration rather than the convenient one — no default credentials, no permissive CORS, no debug endpoints live in the production build.
No known exploitable vulnerabilities at release
Products must be made available without known exploitable vulnerabilities. This is the single requirement most likely to change how a UK development team works, because it converts dependency scanning from a hygiene activity into a release gate. It does not demand perfection; it demands that you know what is in your product and that you do not knowingly ship something exploitable.
Attack surface, confidentiality, integrity, availability
The remaining Part I properties are familiar to anyone who has done secure development: protect confidentiality with encryption at rest and in transit, protect integrity of data and configuration, process only data that is adequate and relevant, protect availability including resilience against denial of service, minimise attack surface, and mitigate the impact of incidents through exploitation mitigation techniques. Also required is the recording and monitoring of relevant internal activity — security logging, in other words.
Security update delivery
Part I requires that products can be updated, that updates can be distributed securely, and that security updates are delivered automatically where technically feasible with a clear opt-out for the user. Where a product can be updated, the mechanism itself becomes part of the assessed surface. A silent auto-update channel with weak signing is a Cyber Resilience Act compliance failure even if the product it updates is flawless.
The vulnerability handling half
Part II is the operating half and it applies across the whole support period: identify and document components and vulnerabilities including an SBOM, address vulnerabilities without delay, apply effective and regular tests, publicly disclose fixed vulnerabilities with descriptions and remediation guidance, operate a coordinated vulnerability disclosure policy, provide a contact address for reporting, distribute updates without delay and free of charge, and ship security updates separately from feature updates where possible. Regular penetration testing is the usual way UK teams evidence the testing requirement.
SBOM and Vulnerability Handling for Cyber Resilience Act Compliance
What the SBOM requirement actually says
The regulation requires manufacturers to identify and document components contained in the product, including by drawing up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies. Note what it does not say: it does not require you to publish the SBOM, and it does not require full transitive depth. It requires you to have one, keep it current, and produce it for the authorities on request.
Top-level dependencies is a floor, not a target
Top-level dependencies is the legal minimum, and it is a weak one for anything running on a modern package ecosystem, where the interesting vulnerabilities usually sit three levels down. Most teams pursuing Cyber Resilience Act compliance seriously will generate full transitive SBOMs anyway, because the same artefact drives the “no known exploitable vulnerabilities” gate. Generating at build time in CycloneDX or SPDX and storing the SBOM as a release artefact is the low-friction pattern.
Coordinated vulnerability disclosure policy
You must have a published policy telling researchers how to report a vulnerability to you, and a contact address for it. This is cheap to satisfy and frequently missing. A security.txt file, a published mailbox and a written internal triage path covers the requirement. What it must not be is a form that routes into a general support queue where it ages for a fortnight.
The open source question in Cyber Resilience Act compliance
Free and open-source software supplied outside the course of a commercial activity is not caught. The dividing line is commercial activity, not price. A hobby project on a public repository is out of scope. The same code, packaged and offered by your company as a supported product, is in scope — and so, importantly, is open source you consume, because your product’s SBOM and vulnerability duties cover components you did not write.
Open-source software stewards
Cyber Resilience Act compliance is lighter for legal entities that systematically sustain open projects intended for commercial use. Stewards must operate a documented cybersecurity policy, cooperate with market surveillance authorities, and from 11 September 2026 report actively exploited vulnerabilities affecting the products they steward. They do not carry full manufacturer obligations. If your UK company runs a foundation-style entity behind an open project, this is the regime to read closely.
The Support Period Rule Most Teams Underestimate
Five years, or the expected product lifetime
Manufacturers must determine a support period during which vulnerabilities are handled, and that period should be at least five years unless the product’s expected lifetime is shorter. Five years of guaranteed security maintenance is a commercial commitment as much as a technical one, and for a small UK software house selling perpetual licences it can be the most expensive line in the whole regulation.
Ten years of update availability
There is a second, longer clock that gets less attention. Once you have issued a security update, you must keep it available for at least ten years after issuance, or for the remainder of the support period if that is longer. This is an artefact retention obligation: the binaries, the signing infrastructure and the distribution endpoint all have to survive a decade.
What this does to your maintenance backlog
Read together, these rules mean a product released in 2028 with a five-year support period can still owe you update-hosting obligations into 2043. Teams doing Cyber Resilience Act compliance planning properly are using this to force decisions they have avoided — retiring old major versions, narrowing supported platform matrices, and moving customers off bespoke builds that nobody wants to patch for five years.
Communicating the support period to buyers
The support period must be communicated clearly to users at the point of purchase. That turns an internal maintenance policy into a published commercial term, which in turn makes it a negotiating point. Publishing a defensible five-year period and holding it is far better than publishing an ambitious one you quietly breach in year three.
Cyber Resilience Act Compliance Reporting: 24 Hours, 72 Hours, 14 Days
The single reporting platform for Cyber Resilience Act compliance
From 11 September 2026, reports go through a single reporting platform established by ENISA. You notify the CSIRT designated as coordinator in the Member State of your main establishment, and the information is made available simultaneously to ENISA. You report once, not to every affected country — a genuine simplification compared with the fragmented picture under other regimes.
The 24-hour early warning
Within 24 hours of becoming aware of an actively exploited vulnerability, you must submit an early warning. Twenty-four hours is not an investigation window. It is an alerting window, and the report is expected to be thin — what you know, that exploitation is occurring, and that you are working on it. Building Cyber Resilience Act compliance around a 24-hour clock mainly means deciding in advance who is authorised to file without waiting for a full picture.
The 72-hour vulnerability notification
Within 72 hours you must submit a fuller notification: the vulnerability, its severity and impact, and where available any corrective or mitigating measures. This is the report that requires actual triage, and it is the one that fails when the security contact is on leave and nobody else has platform credentials.
The final report
For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure is available. It covers the vulnerability, its severity, root cause, and the fix applied. For severe incidents affecting the security of the product the equivalent final report is due within one month of the 72-hour notification.
Severe incidents run a separate clock
Article 14 covers two triggers, not one: actively exploited vulnerabilities, and severe incidents having an impact on the security of the product. The 24-hour and 72-hour stages apply to both. Only the final deadline differs. Teams scoping Cyber Resilience Act compliance frequently build a process for the vulnerability path and forget the incident path entirely.
| Stage | Deadline | Actively exploited vulnerability | Severe incident |
|---|---|---|---|
| Early warning | 24 hours from awareness | Required | Required |
| Notification | 72 hours from awareness | Severity, impact, available mitigations | Nature and impact of the incident |
| Final report | 14 days / 1 month | 14 days after a corrective measure is available | 1 month after the 72-hour notification |
| User notification | Without undue delay | Inform affected users, and on corrective measures | Inform affected users of the incident |
Expressed in hours, the disparity between the stages is what makes the first one hard to staff.
Cyber Resilience Act Compliance Penalties and Who Pays
The three Cyber Resilience Act compliance penalty tiers
The regulation sets three bands of administrative fine. Breaching the Annex I essential requirements or the manufacturer obligations in Articles 13 and 14 carries up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Breaching other obligations, including those of importers and distributors and the declaration of conformity requirements, carries up to €10 million or 2%. Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities carries up to €5 million or 1%.
Market withdrawal is the sharper risk
For most UK software companies the fine is not the real exposure. Market surveillance authorities can require an operator to bring a product into conformity, restrict its availability, withdraw it from the market or recall it. A withdrawal order against a product that carries your European revenue is a far worse outcome than a fine, and it arrives faster. Cyber Resilience Act compliance is therefore best argued internally as revenue protection rather than as penalty avoidance.
How fines interact with turnover
The “whichever is higher” construction is what makes the percentages matter. For a UK software business turning over £40 million, 2.5% is roughly £1 million — well under the €15 million cap, so the cap is the binding number. For a company turning over £800 million the percentage becomes the larger figure. Small firms should read the euro ceilings as theoretical and the enforcement actions as the real risk.
| Breach | Fine ceiling | Percentage of worldwide turnover |
|---|---|---|
| Annex I essential requirements, Articles 13 and 14 | €15,000,000 | 2.5%, whichever is higher |
| Other obligations under the regulation | €10,000,000 | 2%, whichever is higher |
| Incorrect or misleading information to authorities | €5,000,000 | 1%, whichever is higher |
Cyber Resilience Act Compliance Next to NIS2, DORA and UK Rules
NIS2 governs operators, the CRA governs products
The cleanest way to hold these apart is by what they attach to. NIS2 regulates organisations running essential and important services, and reaches UK suppliers mostly through customer contracts. The CRA regulates the product you place on the market and reaches you directly. A UK software company can easily be inside both — contractually bound by a customer’s NIS2 duties and independently liable for Cyber Resilience Act compliance on its own product.
DORA and financial services software
If you sell into EU financial services, DORA adds a third layer covering ICT risk management and third-party providers. It does not displace the CRA. A product sold to a European bank may need CE marking under the CRA while the vendor relationship is separately governed by DORA contractual requirements.
The UK Cyber Security and Resilience Bill
The UK’s own reform is closer to NIS2 than to the CRA — it extends regulatory coverage of operators and managed service providers rather than regulating products. There is no UK product-security equivalent of the CRA beyond the narrower consumer connectable-products regime. Our explainer on the Cyber Security and Resilience Bill covers what it does change for UK businesses.
Running one control set
The practical recommendation is the same one that applies whenever regimes overlap: run a single control set and map it outward. Most of what Cyber Resilience Act compliance requires — secure development, dependency management, vulnerability handling, incident response, logging — is already in an ISO 27001 management system. Certification does not grant conformity, but it means the evidence you need mostly already exists in some form. This is ordinary cybersecurity practice being made legally mandatory for products, and treating it as a wholly new discipline wastes the work you have already done.
| Regime | What it regulates | How a UK software company is caught | Key deadline |
|---|---|---|---|
| Cyber Resilience Act | Products with digital elements | Directly, by placing a product on the EU market | 11 Sep 2026, then 11 Dec 2027 |
| NIS2 | Essential and important entities | Contractually, via EU customers’ supply chain duties | Already in force nationally |
| DORA | ICT risk in EU financial entities | As an ICT third-party provider to EU financial firms | Already applying |
| UK Cyber Security and Resilience Bill | UK operators and managed service providers | As a UK-regulated entity, if in scope | In progress |
A 12-Month Cyber Resilience Act Compliance Programme
Months 1 to 3: scope and classify for Cyber Resilience Act compliance
Start with an inventory of every product, component and free tier that reaches an EU buyer, then classify each against Annex III. Confirm who the manufacturer is for each — white-labelled and OEM arrangements are where this gets genuinely ambiguous. Decide whether you need an authorised representative. Most importantly, treat reporting readiness as an immediate carve-out from this phase rather than a month-three deliverable, because the September 2026 date will not wait for your Cyber Resilience Act compliance scoping to finish.
Months 4 to 6: engineering foundations
Get SBOM generation into the build pipeline for every shipped artefact. Add a dependency vulnerability gate to release. Fix the secure-by-default gaps — default credentials, permissive configurations, verbose error handling. Establish signed update distribution if you do not have it. This phase is where actual engineering effort goes, and it is the part that cannot be compressed at the end.
Months 7 to 9: documentation and conformity route
Draft the technical documentation against Annex VII, write the risk assessment that underpins the Annex I claims, and produce the EU declaration of conformity template. If any product is Class I without full standards coverage, or Class II, engage a notified body now — capacity is the constraint that turns a comfortable Cyber Resilience Act compliance timeline into a late one.
Months 10 to 12: rehearse reporting and sign off
Run a tabletop exercise against the 24-hour clock with the actual people who would be on call. Publish the support period and the coordinated vulnerability disclosure policy. Complete the conformity assessment, affix CE marking, and sign the declaration. Then set the review cadence, because Cyber Resilience Act compliance is a continuing obligation across the support period, not a one-off certification.
Cyber Resilience Act Compliance Mistakes UK Software Companies Keep Making
Assuming December 2027 is the only date
It is the date in every headline, and it is not the first one that binds. The reporting duties arrive fifteen months earlier and apply regardless of how far along your broader programme is.
Treating it as a documentation exercise
The technical file is the output of Cyber Resilience Act compliance, not the work itself. A beautifully written Annex VII document describing a product that ships with known exploitable dependencies is a false declaration, and false declarations sit in the highest penalty band.
Missing the free-of-charge and open source edges
Free tiers, community editions and SDKs distributed under your brand as part of a commercial strategy are in scope. So are the open source components inside your product. Cyber Resilience Act compliance scoping that only counts paid SKUs will be wrong.
Ignoring the support period commercially
Five years of security maintenance, and ten years of update availability after issuance, are costs that belong in pricing and in end-of-life policy. Costing Cyber Resilience Act compliance product by product without a portfolio view is how small vendors end up maintaining six major versions.
Waiting for harmonised standards
The standards are still landing. Building directly against the Annex I text now and mapping to standards later is strictly faster than the reverse, and there is no version of the timeline where waiting improves your position.
Forgetting substantial modification
Products placed on the market before December 2027 are largely grandfathered — until they are substantially modified. For continuously delivered software that grace period is shorter than it looks, and assuming an existing product is permanently exempt is a common and expensive misreading.
Cyber Resilience Act Compliance Questions Answered
Does the Cyber Resilience Act apply to UK companies after Brexit?
Yes. The regulation applies to products with digital elements placed on the EU market regardless of where the manufacturer is established. A UK software company selling to EU customers carries manufacturer obligations directly.
Is SaaS in scope for Cyber Resilience Act compliance?
Pure software-as-a-service delivered as a service is generally addressed by NIS2 rather than the CRA. However, remote data processing solutions integral to a product’s function are in scope, so a hybrid product with an installed client and a hosted backend usually is caught.
Do we need an EU authorised representative?
Not as a legal requirement — appointment is voluntary under the regulation. In practice, most UK vendors of any scale should appoint one so there is an established contact inside the Union for market surveillance authorities.
What happens on 11 September 2026 specifically?
The Article 14 reporting duties begin. From that date you must report actively exploited vulnerabilities and severe incidents through the single reporting platform, with a 24-hour early warning and a 72-hour notification.
Does ISO 27001 or Cyber Essentials satisfy the CRA?
No. Neither grants conformity, because both certify management systems and organisational controls rather than product security properties. They do supply much of the underlying evidence, which shortens the work considerably.
How much of our product portfolio is likely to need a notified body?
For most UK software companies, none of it. The default self-assessment category covers the majority of business software. The exposure concentrates in security and infrastructure tooling — identity, VPN, SIEM, firewalls, hypervisors and container runtimes.
What is the minimum Cyber Resilience Act compliance work to do this month?
Name an owner for Article 14 reporting, confirm which products reach EU buyers, write a one-page triage procedure covering the 24-hour and 72-hour clocks, and publish a vulnerability disclosure contact. That is achievable before 11 September 2026 and it is the part that is already overdue.
References
European Commission: Cyber Resilience Act
European Commission: Summary of the Cyber Resilience Act legislative text
European Commission: Cyber Resilience Act reporting obligations
NCSC: Secure development and deployment guidance
CEN-CENELEC: Cybersecurity and data protection standardisation
CycloneDX SBOM specification overview
FIRST: Common Vulnerability Scoring System
ISO/IEC 27001 information security management
Directive (EU) 2022/2555 (NIS2)
