The EU Cyber Resilience Act: what hardware startups need to know

If your product has a chip, firmware, or an app that talks to it, the Cyber Resilience Act (Regulation (EU) 2024/2847, "the CRA") applies to you. It is one of the broadest pieces of EU product legislation in years, and unlike most CE directives, it covers the entire lifecycle of the product, including how you handle vulnerabilities after it has shipped. The good news for a startup planning today is that the deadlines are further out than most of the coverage implies, and they are staged rather than a single cliff edge.

What counts as "a product with digital elements"

The CRA's scope is broad by design: any product whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network, plus any software or hardware component placed on the market separately. That covers a smart plug, a fitness tracker, a router, a desktop application, a firmware update mechanism, and most of what a modern hardware startup builds. It also, unusually for EU product law, covers standalone software.

There are exclusions: products already covered by their own sector-specific cybersecurity rules (in-vehicle systems under existing type-approval, medical devices, certain aviation and marine equipment) are generally out of scope, on the basis that equivalent rules already exist. If your product could plausibly sit in one of those excluded categories, that is worth verifying against the regulation's actual exclusion list rather than assuming.

The dates that matter, in order

The CRA entered into force in December 2024, but almost nothing was due immediately. The obligations are staged:

• 11 June 2026: the provisions for notifying and accrediting conformity assessment bodies (Chapter IV, Articles 35 to 51) start to apply. This mostly matters to the assessment ecosystem, not to individual manufacturers, but it is the first sign the enforcement infrastructure is switching on.
• 11 September 2026: the reporting obligations in Article 14 apply. From this date, manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements to ENISA and their national CSIRT, with an early warning required within 24 hours of becoming aware. This is the first obligation that lands directly on product teams, and it is worth building the internal process for it well before the date, not after.
• 11 December 2027: the CRA applies in full. From this date, in-scope products need to meet the essential cybersecurity requirements, go through the appropriate conformity assessment route for their risk category, and carry CE marking against the CRA specifically (in addition to, not instead of, any other applicable CE legislation).

If you are planning a product launch any time from mid-2026 onward, the practical implication is: build the vulnerability handling and reporting process now, because 11 September 2026 arrives well before most product roadmaps expect a "compliance deadline", and it applies to products already on the market, not just new ones.

What the essential requirements actually ask for

At a high level, the CRA's essential requirements (Annex I) split into two groups: security properties the product itself must have (no known exploitable vulnerabilities at the time of placing on the market, secure by default configuration, protection against unauthorised access, minimised attack surface, and so on), and vulnerability handling obligations that continue for the product's defined "support period" (a coordinated vulnerability disclosure policy, a way for security researchers to report issues, and free security updates without unreasonable delay). The support period itself is meant to reflect how long the product is expected to be used, which for many consumer devices will be longer than a typical warranty period, so it needs deciding deliberately rather than defaulted to whatever is convenient.

If you white-label or private-label a product

A common hardware startup pattern is sourcing a near-finished product from a contract manufacturer or ODM and selling it under your own brand. Under EU product law generally, and the CRA specifically follows this same pattern, putting your own name or trademark on a product makes you the legal manufacturer for compliance purposes, whatever the factory's own marketing materials claim about "CE ready" or "CRA compliant" status. That means the essential requirements, the vulnerability handling and disclosure obligations, and the Article 14 reporting duty land on you, not on the factory, unless you have a specific, documented arrangement that genuinely keeps the factory as the manufacturer of record and you as a distributor. Before committing to a private-label hardware product with any connectivity at all, ask the factory directly for their actual CRA-relevant documentation (vulnerability handling process, software bill of materials, security architecture notes), not just a general assurance.

Software bill of materials and third-party components

A significant part of the CRA's effort in practice, separate from any single test, is knowing what is actually inside your product's software: which open-source libraries, which third-party SDKs, which firmware components, and which of those have known vulnerabilities. The regulation expects manufacturers to have effective processes for identifying vulnerabilities in components they use, which in practice means maintaining a software bill of materials (SBOM) as living documentation, not a one-time snapshot taken at launch. If your product ships firmware updates over its lifetime, the SBOM needs to be kept current as those updates change what is actually running on the device.

How this interacts with what you already have to do

If your product has a radio (Wi-Fi, Bluetooth, cellular), it is likely already subject to the Radio Equipment Directive's own cybersecurity delegated act, which became applicable on 1 August 2025 and covers network protection, personal data safeguards and fraud protection for a narrower set of radio equipment categories. The CRA is broader in scope and stricter in detail, and the Commission's intention is for RED's overlapping cybersecurity provisions to eventually be absorbed into the CRA framework rather than run two parallel regimes indefinitely, but until that transition is formally settled, treat both as live and check which currently applies to your specific product.

What to actually do now, in 2026

For a startup at the funding or early-production stage, the practical order of operations is: confirm whether your product is in scope, build a basic vulnerability disclosure and patching process well ahead of the September 2026 reporting deadline (even a simple documented process beats none), and start tracking the essential requirements against your product architecture so the December 2027 conformity assessment is a documentation exercise rather than a redesign. None of this needs to happen through us. Read the regulation's text directly, and treat any secondary summary, including this one, as a starting point rather than the final word for a specific product decision.