ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The EU Cyber Resilience Act is the first horizontal cybersecurity law for products anywhere. It does not care what sector you sell into. If your product has digital elements and connects to anything, it applies — and the first obligations bite on 11 September 2026, not in December 2027 as most summaries suggest.
The EU CRA — Regulation (EU) 2024/2847 — entered into force on 10 December 2024. It has since been amended once, by the European Health Data Space Regulation, with effect from 26 March 2027, and four acts have been adopted under it. This guide covers what it actually requires, the four dates that matter, and the provisions manufacturers reliably get wrong.
Regulation (EU) 2024/2847 sets horizontal cybersecurity requirements for products with digital elements. “Horizontal” is the important word: unlike the NIS2 Directive, which binds organisations in named sectors, the EU CRA binds anyone who places a qualifying product on the Union market, whatever they do.
A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. The Regulation applies where the intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network.
Two parts of that definition catch people out.
Components sold separately are products in their own right. A library, a module, a chip — if it is placed on the market on its own, it is a product with digital elements and the full obligations attach to it.
Your cloud back end is part of the product. Article 3(2) brings in remote data processing where the software is designed and developed by the manufacturer, or under its responsibility, and its absence would prevent the product performing one of its functions. Not all of its functions — one. A device that still powers on but loses a headline feature when the cloud is unreachable has a remote data processing solution inside its product boundary, and every downstream obligation reaches it: the risk assessment, the essential requirements, the technical documentation, the support period, and the duty to let users delete their data.
Four instruments now sit alongside the Regulation, and all four are in force:
None of them is a harmonised standard citation, so none changes the conformity position below.
Almost every summary of the EU CRA gives two dates. There are four, and the first has already passed.
| Date | What applies |
|---|---|
| 11 June 2026 | Chapter IV — designation and notification of conformity assessment bodies. Already in force, which is what makes “book your notified body” actionable rather than aspirational |
| 11 September 2026 | Article 14 reporting obligations — and they reach products already on the market |
| 11 December 2027 | Everything else — essential requirements, conformity assessment, CE marking, user information, support periods |
| 11 June 2028 | Article 69(1): EU type-examination certificates issued under other Union harmonisation legislation cease to be valid |
The September 2026 date is the one to plan against, and it is covered in detail in the CRA reporting deadline.
Article 2 takes several categories out of scope entirely. These are exclusions, not alternative compliance routes — a product to which one applies is not an EU CRA product at all.
Article 2(5) allows sectoral rules to limit or exclude application where they achieve equal or higher protection, but it is not self-executing: it needs a Commission delegated act specifying the products and rules concerned. One has been adopted — Commission Delegated Regulation (EU) 2025/1535 of 29 July 2025, which excludes certain products within the scope of Regulation (EU) No 168/2013, the two- and three-wheel vehicle and quadricycle regulation. That is the only one. For any other product and any other sectoral rule, Article 2(5) has not been operated, and a reliance on it is a watch item rather than an exclusion.
The conformity route depends on which tier a product falls in.
| Tier | Where | Count |
|---|---|---|
| Default | Everything not listed | — |
| Important, class I | Annex III class I | 19 categories |
| Important, class II | Annex III class II | 4 categories |
| Critical | Annex IV | 3 categories |
Article 7(1) contains two rules that decide most classification questions, and they cut in opposite directions.
Classification turns on core functionality, not on a feature being present. A product that happens to contain password management is not an Annex III class I product on that basis alone.
Integration does not propagate classification upward. Article 7(1) says expressly that integrating a product which has the core functionality of an Annex III category “shall not in itself render the product in which it is integrated” subject to the third-party conformity assessment procedures. A washing machine containing an embedded operating system does not become a class I product because Annex III class I item 11 is “operating systems”. The embedded operating system is, if it is placed on the market separately. The washing machine is assessed on its own core functionality.
The full category lists and the borderline cases are in CRA product classification.
Annex I has two parts, and they are assessed separately throughout the Regulation.
Part I concerns the properties of the product. Point (1) is an unconditional obligation to design, develop and produce so as to ensure an appropriate level of cybersecurity based on the risks. Point (2) then sets thirteen specific properties — no known exploitable vulnerabilities at the point of sale, a secure default configuration with a reset capability, security updates, protection from unauthorised access, confidentiality, integrity, data minimisation, availability, limited attack surfaces, exploitation mitigation, security logging with a user opt-out, and the secure permanent deletion of all data and settings.
Those thirteen apply “on the basis of the cybersecurity risk assessment and where applicable” — so applicability is a determination, and where a property is held not to apply, Article 13(4) requires a clear justification in the technical documentation. A silent omission is a defect; a reasoned exclusion is compliance.
One of the thirteen is routinely missing from manufacturers’ evidence. Property (2)(i) requires the product to minimise its negative impact on the availability of services provided by other devices or networks. It protects third parties, not your users. A device that can be conscripted into a botnet engages it — and so does a fleet whose units all check for updates on the same schedule and flood a shared network on restart.
Part II concerns the manufacturer’s processes, and unlike Part I it has no “where applicable” qualifier. All eight requirements apply to every manufacturer of every product in scope: identify and document vulnerabilities and components including a software bill of materials; remediate without delay and separate security updates from functionality updates where technically feasible; test regularly; disclose fixed vulnerabilities publicly once an update is available; put in place and enforce a coordinated vulnerability disclosure policy; facilitate reporting including about third-party components; distribute updates securely; and disseminate them without delay and free of charge.
That last constraint is commercially significant. The only exception is an agreement with a business user for a tailor-made product. Security updates cannot sit behind a support contract, a subscription tier or a maintenance renewal.
Not the handful the summaries list. Three are missed most often because they read as administrative rather than technical.
Article 13(9) — updates outlive the product. Each security update made available during the support period must remain available for at least ten years after it was issued, or the remainder of the support period, whichever is longer. An update issued in the final month of a five-year support period must still be obtainable roughly fifteen years after the product was placed on the market. Plan the storage, and plan for the signing keys still validating.
Article 13(17) — the single point of contact. It must be easily identifiable, must let users choose their preferred means of communication, and shall not be limited to automated tools. A web form with no email address, or a chatbot with no human route, does not satisfy it.
Article 13(23) — ceasing operations. A manufacturer that winds down and can therefore no longer comply must inform the market surveillance authorities and, so far as possible, users before the cessation takes effect. An organisation that has already wound down cannot comply, so the trigger has to be the decision, not the closure.
Article 13(8) requires the manufacturer to determine a support period reflecting how long the product is expected to be in use — taking into account reasonable user expectations, the nature of the product, and relevant Union law on product lifetimes. It shall be at least five years, unless the product is expected to be in use for less, in which case it matches the expected use time.
Five years is a floor, not an answer. A product expected to be in use for eight years takes an eight-year support period.
And under Article 13(19), the end date — at least the month and the year — must be clearly specified at the time of purchase, in an easily accessible manner. A date that first appears in the documentation supplied with the product does not satisfy that.
The EU CRA treats free and open-source software carefully, and creates an actor class that exists in no other EU instrument.
Open-source software stewards — Article 24. A steward is a legal person, other than a manufacturer, that systematically provides support on a sustained basis for the development of specific open-source products intended for commercial activities, and ensures their viability. Foundations and corporate open-source programme offices will often qualify. A steward must put in place and document, in a verifiable manner, a cybersecurity policy that fosters secure development, effective vulnerability handling by developers, and voluntary reporting — and that promotes the sharing of vulnerability information within the open-source community, which is an outward-facing duty rather than an internal one.
Article 24(3) then applies only parts of the reporting regime to stewards, and each part is conditioned: Article 14(1) to the extent the steward is involved in development, and Article 14(3) and (8) to the extent a severe incident affects the network and information systems the steward provides for development — the forge, the build system, the package registry. Not the shipped library. Building a steward reporting workflow that assumes the whole of Article 14 applies would be wrong.
Article 32(5) — the self-assessment route. A product qualifying as free and open-source software which falls in an Annex III category may use any Article 32(1) procedure, including module A self-assessment, provided the technical documentation is made available to the public at the time of placing on the market. Publishing the technical file is the price of avoiding a notified body. For an open-source project that is often acceptable; for a proprietary product the route does not exist.
Separately, Article 13(5) requires due diligence when integrating third-party components — expressly including open-source components not made available on the market in the course of a commercial activity. A library pulled from a public repository with no vendor behind it is squarely within the duty, and there is no supplier to pass it to.
Default-tier products self-assess under module A. Everything in Annex III or Annex IV needs more, and on the position as at 14 August 2026 it needs a notified body — because Article 32(2)’s self-assessment route for class I is conditioned on harmonised standards that do not yet exist. That finding, and what it costs, is worked through in CRA conformity assessment.
One CE marking detail is worth stating here because it runs opposite to the habit built under other Union legislation. The notified body’s identification number follows the CE marking only where module H (full quality assurance) applies — Article 30(4). A product assessed under module B+C does not carry the body’s number after the marking, even though a notified body was involved.
For software, the marking goes either on the EU declaration of conformity or on the website accompanying the product, and the relevant section of that website must be easily and directly accessible to consumers.
Article 64 sets three tiers, each expressed as a cash maximum or a percentage of total worldwide annual turnover, whichever is higher.
| Maximum | Applies to |
|---|---|
| EUR 15,000,000 or 2.5% | The essential cybersecurity requirements in Annex I, and the obligations in Article 13 and Article 14 |
| EUR 10,000,000 or 2% | Articles 18–23, 28, 30(1)–(4), 31(1)–(4), 32(1)–(3), 33(5), and 39, 41, 47, 49 and 53 |
| EUR 5,000,000 or 1% | Supplying incorrect, incomplete or misleading information to a notified body or a market surveillance authority in reply to a request |
The first tier is worth reading twice. It covers the whole substantive core — so a missed 24-hour report, a support period that was never determined, and a single point of contact with no human route all carry the same maximum as shipping an insecure product.
The third tier is a trap of its own: it is a separate infringement. An organisation already facing a tier one problem that then answers a request carelessly adds a second one. Where a document does not exist, say so — an acknowledged gap is a compliance failure honestly reported, while a silent omission risks the tier three exposure on top of it.
These are the two comparisons people reach for, and both mislead.
NIS2 binds entities in respect of their own network and information systems. The EU CRA binds manufacturers in respect of the products they place on the market. An organisation can be both, and the same event — a compromise of the build system used to produce a product — can engage both. Where it does, both reports are due, to different recipients, under different rules. Neither discharges the other. See NIS2 requirements for the other side of that line.
An information security management system governs how you protect yourself. The EU CRA governs the security properties of what you ship. ISO 27001 certification confers no presumption of conformity under the EU CRA — only a harmonised standard cited in the Official Journal, a common specification, or a European cybersecurity certification scheme does that, and none exists yet.
An ISMS will nonetheless have built much of the evidence: risk assessment practice, vulnerability management, incident handling, supplier assessment. What it will not have built is the reporting deadlines, the support period, update availability, upstream contribution, the support end date at the point of purchase, or the duty to protect other people’s networks.
Work backwards from 11 September 2026, not from December 2027.
The EU CRA Toolkit covers all of that in 74 editable documents written against the consolidated text of 20 November 2024, with every dated and volatile fact — the harmonised standards position above all — held in one place so it can be checked in one edit rather than hunted across a pack.
August 16, 2026
August 16, 2026
August 16, 2026
August 16, 2026
August 16, 2026