The EU Cyber Resilience Act (CRA): All You Need to Know in 2026

eBPF vs. Service Mesh: Why Kubernetes Access Control Needs Rethinking

Traditional service meshes like Istio or Linkerd are too slow for multi-hop requests. A recent study shows how eBPF enables real-time, kernel-level access control — with 10x less latency.

The EU Cyber Resilience Act (CRA): All You Need to Know in 2026

Bottom line up front: The Cyber Resilience Act (Regulation (EU) 2024/2847) turns cybersecurity into a legal requirement for nearly every product with digital elements sold in the EU — hardware and software alike. It entered into force on 10 December 2024, the main obligations bite on 11 December 2027, and vulnerability/incident reporting already starts on 11 September 2026. If you develop, sell, or integrate software or connected hardware for the EU market, this law applies to you — and so do fines of up to €15 million or 2.5% of global turnover, whichever is higher.

⚡ Key idea: Until now, "security by design" was a best practice. With the CRA, it is a legal obligation. You cannot legally place an insecure product on the EU market after the transition period ends — and you don't ship a product, you ship a lifecycle including updates, vulnerability handling and incident reporting.

What is the CRA?

The CRA is a horizontal EU regulation (directly applicable in all member states, no national transposition needed) that imposes mandatory cybersecurity requirements on manufacturers, importers and distributors of products with digital elements — in other words, any hardware or software whose intended or foreseeable use includes a direct or indirect connection to a device or a network.

It is the "product" half of the EU's cybersecurity strategy. Its sibling, the NIS2 Directive (EU) 2022/2555, regulates the operators (companies running critical and important services); the CRA regulates the products themselves. Together they form the EU's answer to an attack surface that grows with every connected device.

Why now? The Commission estimates that ransomware, IoT botnets and supply-chain attacks cost the EU economy billions each year. Most connected products today ship with insecure defaults, no update path and no coordinated vulnerability disclosure. The CRA rebalances responsibility: it is no longer the user's job to stay safe — the manufacturer must carry the duty of care across the product's whole life.

The timeline (this is what matters for planning)

So even though "the CRA" feels like a 2027 topic, the reporting duty is one year away as of today — and the infrastructure (notified bodies, national authorities) is being stood up right now. As of 2026, audits and conformity checks are already possible against the requirements framework.

Who is affected?

The CRA addresses economic operators:

• Manufacturers — the person placing/distributing the product under their name or trademark. This includes software-only products distributed in the EU.
• Importers — businesses established in the EU that place products from outside the EU on the market.
• Distributors — anyone in the supply chain making a product available in the EU.
• Authorised representatives — EU-based entities mandated by non-EU manufacturers.
• "Open-source software stewards" — foundations/commercial backers that systematically support a FOSS project (see open-source section).

Critically, the CRA covers software updates too: pushing an update is making the product available on the market. A SaaS that only you operate is not a "product made available"; an on-premise application, embedded firmware, or a tool you distribute and monetise is.

Scope trigger: the product must be made available on the market — supplied for distribution or use in the course of a commercial activity (Art. 3(22)). That single phrase is the hinge that keeps non-commercial open source out of most obligations.

What is explicitly excluded

• Medical devices (MDR, IVDR), aviation (Reg. 2018/1139), vehicles (Reg. 2019/2144), marine equipment
• Products for national security / defence / classified data
• Spare parts made to identical specifications by the original manufacturer
• Products developed exclusively for one's own use (internal, not place on the market)

The core obligations

All covered products must meet the essential requirements in Annex I, split into two parts:

Part I — Security-by-design properties of the product

• Security throughout the entire lifecycle: risk assessment, secure defaults, minimal attack surface
• Protection of confidentiality, integrity and availability of data and functions (incl. against unauthorised access)
• Authentication, identity and access-control management; control of access of software/hardware components
• Data security: encryption, integrity checks, secure deletion
• Limitation of attack surface and exposure (least privilege, minimal interfaces)
• Automated and manual incident handling (detect, log, report, alert)
• Transparency and ease of use: users can securely set up, configure and monitor the product; security-relevant info available in clear language

Part II — Vulnerability handling (the manufacturer's duty of care)

• Track and document vulnerabilities, incl. via a Software Bill of Materials (SBOM)
• Remedy vulnerabilities, including via security updates, free of charge, during the support period
• No known exploitable vulnerabilities allowed when a product is placed on the market
• Coordinated Vulnerability Disclosure (CVD) policy and point of contact for researchers
• Security updates separated from feature updates where technically feasible — and enabled by default (users may opt out)
• Update mechanisms that split security from functionality and don't break the product
• Share vulnerability information (aggregated where appropriate) with downstream manufacturers

The SBOM deserves emphasis for DevOps readers: you will need a machine-readable inventory of every component in your software — the same discipline good supply-chain security already requires (e.g. for dependency scanning).

Conformity assessment — which "class" is your product?

Products are divided by cybersecurity importance. The conformity assessment (how you prove compliance) depends on the class:

For the default category — which covers the large majority of software — the CRA is comparatively gentle: an internal control procedure, a documented security process, and the technical file. This is deliberate: the EU does not want to drown startups in third-party audits for a mobile game. But "self-assessment" is not "no work": the documentation must exist, be truthful, and withstand later market-surveillance scrutiny (which can request documents and run checks at any time).

Outputs you must have:

• Risk assessment + technical documentation (kept for 10 years after the product was placed on the market, or the end of the support period — whichever is longer)
• EU declaration of conformity (Annex V)
• CE marking affixed to the product (by the manufacturer)
• Authorised representative in the EU (for non-EU manufacturers)
• Traceability info to reach manufacturers/importers (10 years after purchase)

Reporting obligations (from 11 September 2026)

A manufacturer that becomes aware of either of the following must report to the CSIRT coordinator and to ENISA via the single reporting platform (Art. 14):

Actively exploited vulnerabilities (in the product):

• 24 hours → early warning (which member states are affected)
• 72 hours → vulnerability notification (nature, exploit, mitigations)
• ≤ 14 days after a fix is available → final report (severity, impact, any threat actor, the update)

Severe incidents affecting the security of the product:

• 24 hours → early warning
• 72 hours → incident notification (nature, initial assessment, mitigations)
• within 1 month → final report (detailed description, root cause, measures taken)

These deadlines run from when the manufacturer "becomes aware" — so processes for detection and internal escalation need to exist before the duty starts. Vendors who ship products to businesses inside NIS2 sectors will find this overlaps with NIS2's own reporting chains; the single platform is designed to reduce double reporting.

Open source and the CRA — the part everyone argues about

The CRA's relationship with Free and Open-Source Software (FOSS) was the most contested issue during drafting. The compromise that landed is deliberately oriented around monetisation:

• The CRA applies to economic operators only for products made available on the market in the course of a commercial activity (Art. 3(22) + recital 18).
• Non-commercial FOSS — including projects that accept donations without profit intent, receive vendor funding, or put out regular releases — is not "made available on the market". Individual contributors are explicitly out of scope.
• Merely financing or contributing to a FOSS project does not make you a CRA manufacturer for it (recital 18).
• Monetised FOSS is in scope: if you sell your software or a paid support/commercial service beyond cost recovery, or monetise via a platform — you are a manufacturer under the CRA like any vendor.
• Not-for-profit development organisations are not considered to be acting commercially if all earnings after costs go back into the not-for-profit objectives.
• Open-source software stewards (foundations, commercial backers that systematically sustain a FOSS product intended for commercial use) face a light-touch regime: they are on the hook mainly for vulnerability handling and reporting (Art. 13n), not the full conformity machinery.
• Redistributors of open source generally only face distributor duties.

Practical reading for maintainers: hobby projects and community software: out. Consulting product you sell: in. You "sell" a T-shirt as a lie to dodge it: still in — commercial intent is judged on substance, not labels.

Support periods

Manufacturers must determine a support period that reflects the expected useful life of the product (user expectations, nature of the product, component lifetimes). Rules:

• Minimum 5 years (or the expected use time, if shorter)
• Security updates issued during the support period must remain available for at least 10 years after release (or the rest of the support period, whichever is longer)
• The Commission can raise the minimum for specific categories via delegated acts

"One and done" is gone: after 2027, placing a product on the EU market is a commitment to maintain it.

Penalties

Member States set the fine framework, and the regulation caps it (Art. 64):

Administrative fines do not apply to non-commercial open-source developers (Art. 64(10)). Beyond fines, market surveillance authorities can withdraw or recall products, and order non-conformance corrected.

What you should do now (checklist)

If you make (or plan) a product for the EU market:

1. Determine your role — manufacturer, importer, distributor, or possibly "steward". Write it down with your legal counsel.
2. Do the cybersecurity risk assessment today; map it to Annex I Part I requirements. It is also your design blueprint.
3. Build an SBOM and a dependency/component inventory now — retrofitting it later is painful.
4. Set up vulnerability handling: a contact point, a CVD policy, a triage process, and a fix-release pipeline. Expect this to be joined-up with your incident management.
5. Decide your conformity class honestly. If you're Class I/II, line up a notified body (few are designated yet — early movers get appointments).
6. Prepare the technical file: risk assessment, design/architecture, test evidence, traceability — 10 years retention.
7. Plan reporting from 11 Sep 2026: internal escalation must produce an "awareness" timestamp faster than 24h.
8. Publish a support-period commitment and the promised update/availability terms.
9. For products in NIS2 sectors, harmonise CRA and NIS2 reporting so you don't duplicate work.
10. Watch the standards: harmonised standards and the Commission's 27 July 2026 guidance give you the "how".

Open-source maintainers & foundations: document that your project is non-commercial (or step into the steward role consciously), publish a CVD/SECURITY.md if you monetise, and — like everyone — keep the SBOM mindset.

Businesses buying products: use the CRA as procurement leverage — ask for CE-marked, CRA-compliant products, the SBOM, and the support-period commitment. From 2027 this is also your compliance story under NIS2 and contract law.

How the CRA fits with other EU rules

• NIS2: regulates operators of essential/important services (reporting of significant incidents, supply-chain security). CRA products often sit inside NIS2 entities — the single reporting platform reduces friction.
• RED delegated acts (Radio Equipment Directive): cybersecurity for internet-connected radio equipment applied from 1 Aug 2025 for new devices — CRA will largely supersede this overlap for those products.
• AI Act / Machinery Regulation / GPSR: separate but overlapping product-safety regimes; the CRA explicitly recognises synergies where sectoral rules already cover the same risks.

Resources

• Legal text: Regulation (EU) 2024/2847 on EUR-Lex (CELEX 32024R2847)
• Commission: Cyber Resilience Act page + practical guidance (published 27 July 2026)
• ENISA: single reporting platform for vulnerability/incident notifications
• This article reflects the regulation as of August 2026 — check delegated acts and harmonised standards regularly, they are moving fast.

Last updated: 27 August 2026.