The EU Cyber Resilience Act: A Practical Guide for U.S. Manufacturers

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for hardware and software products sold in the EU, across their whole life ^[1]. If your US company sells connected products, equipment, controls or instruments into Europe, the CRA probably applies to some of them. Its main obligations apply from 11 December 2027, and its vulnerability and incident reporting duties already apply ^[1][2].

This guide is written for engineering teams, not lawyers. It covers who the CRA applies to, the dates, the product classes, and what the obligations mean as engineering work. It’s the flagship page of our EU requirements hub, and it ends with a Cyber Resilience Act resources list of every related guide and tool on this site.

Key dates

Re-verified against EUR-Lex and the European Commission on 2026-11-10 ^[1][2][3].

The Commission’s implementation page also lists planned milestones, such as standardisation deliverables, and published non-binding guidance on 27 July 2026 ^[3][4]. Our EU regulatory timeline tracks these dates with sources and a change log.

Products already on the market. Products placed on the EU market before 11 December 2027 only fall under the CRA’s requirements if they’re substantially modified from that date. The Article 14 reporting obligations, however, apply to all in-scope products, including those placed on the market before 11 December 2027 ^[1]. So reporting already covers your installed base.

Does it apply to you?

Products in scope

The CRA applies to "products with digital elements" made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network ^[1]. A product with digital elements is a software or hardware product and its remote data processing solutions, including components placed on the market separately ^[1].

For most connected equipment, that’s a short test:

• Does the product contain software or programmable hardware?
• Can it connect, directly or indirectly, to another device or a network (Ethernet, wireless, fieldbus, USB, a gateway)?
• Is it made available on the EU market?

If all three are yes, treat it as likely in scope and confirm with counsel.

Exclusions (Art. 2)

The CRA doesn’t apply to ^[1]:

• medical devices and in vitro diagnostic medical devices under Regulations (EU) 2017/745 and 2017/746;
• vehicles under the type-approval Regulation (EU) 2019/2144;
• products that hold a certificate under the EU aviation safety Regulation (EU) 2018/1139;
• marine equipment under Directive 2014/90/EU;
• spare parts made to the same specifications to replace identical components;
• products developed or modified exclusively for national security or defence, or designed to process classified information.

The CRA also allows its application to be limited or excluded where other EU rules give the same or a higher level of protection, through delegated acts ^[1]. Check whether any apply to your product category on publish day.

You’re the "manufacturer" even if someone else builds it

The CRA’s "manufacturer" includes a company that has products designed, developed or manufactured by others and markets them under its own name or trademark ^[1]. Outsourcing firmware or production doesn’t move the obligations. A US company without an EU establishment can appoint an authorised representative by written mandate, but core design and vulnerability-handling obligations can’t be delegated to that representative ^[1]. Importers and distributors have their own duties ^[1].

The Cyber Resilience Act applicability checker will walk through these questions with article references.

Product classes

Most products are in the default category and can use self-assessment (internal control) ^[1]. Two lists change that:

• Important products (Annex III), classes I and II. Products whose core functionality matches a listed category ^[1]. Examples relevant to US equipment makers include boot managers, operating systems, routers and switches, network interfaces, and microprocessors and microcontrollers with security-related functionality (class I), and firewalls and tamper-resistant microcontrollers (class II) ^[1]. Integrating such a component doesn’t, on its own, make your whole product an important product ^[1].
• Critical products (Annex IV). For example, smart meter gateways and smartcards or similar devices including secure elements. The Commission can require a European cybersecurity certificate for these through delegated acts ^[1].

Class I products can self-assess only if they apply harmonised standards, common specifications or a relevant certification scheme in full. Otherwise, and for class II, a notified body is involved (EU-type examination or full quality assurance) ^[1]. See Cyber Resilience Act product classes for the full map.

What the Cyber Resilience Act requires, as engineering work

The obligations sit in Article 13 (manufacturer obligations), Article 14 (reporting) and Annex I (essential requirements, Part I for the product and Part II for vulnerability handling) ^[1]. Here is how they translate into workstreams.

Obligations → engineering workstreams

Our original mapping. It’s a planning aid, not a legal checklist.

The workstream and evidence columns are examples to adapt, not a complete list.

Reporting

Since 11 September 2026, manufacturers must notify actively exploited vulnerabilities, and severe incidents affecting product security, simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform ^[1][5]:

• an early warning within 24 hours of becoming aware;
• a notification within 72 hours;
• a final report within 14 days after a fix or mitigation is available (for vulnerabilities), or within one month after the incident notification (for severe incidents) ^[1].

US manufacturers without an EU main establishment report to the CSIRT designated as coordinator in a Member State chosen by a set order: where your authorised representative is, then your importer, then your distributor, then where most of your users are ^[1]. Work out which applies to you before you need it. See Cyber Resilience Act reporting workflow and our guide to setting up a PSIRT.

Support period and updates

The support period is the engineering commitment most US teams underestimate. It must reflect how long the product is expected to be in use, and be at least five years unless the product’s expected use is shorter ^[1]. The CRA’s recitals note that industrial products such as industrial control systems are often in use for much longer ^[1], and the Commission’s guidance says five years isn’t a default ^[4].

That means planning kernel and BSP maintenance, signing-key lifetimes and update infrastructure for the full period. See the Cyber Resilience Act support period guide and our secure firmware update architecture.

Overlaps

Machinery, radio equipment and connected products may also be covered by the Machinery Regulation, the Radio Equipment Directive and the EU Data Act. The Commission’s guidance explains how certain existing certificates under the Machinery Regulation remain valid for the cyber risks they cover, but not beyond 11 June 2028 ^[4]. See Cyber Resilience Act vs. NIS2, RED, the Machinery Regulation and the Data Act, and our EU Data Act guide.

Where to start

1. Inventory. List every product line you sell in the EU, with its software, connectivity and expected service life.
2. Scope and class. Apply the scope test and exclusions; flag anything that might be an important or critical product. Confirm with counsel.
3. Reporting first. It already applies. Make sure you can detect, triage and report an actively exploited vulnerability within 24 hours.
4. Gap analysis by workstream. Use the table above. Our free Secure Update Readiness Assessment covers the update and lifecycle rows.
5. Plan the support period per product before 11 December 2027.
6. Work through the Cyber Resilience Act readiness checklist.

If you need outside engineering capacity for any of these workstreams, our guide to evaluating firmware development companies sets out what to ask. You can also request an introduction.

If you’re introduced to a partner firm and hire them, that firm may pay us a referral fee.

Cyber Resilience Act resources

Every Cyber Resilience Act guide and tool on this site:

Guides

• How to set up a PSIRT for connected products
• SBOM generation for embedded products
• Secure firmware update architecture

News

• Cyber Resilience Act reporting obligations now apply

Tools

• EU regulatory timeline and tracker
• Secure Update Readiness Assessment

Terms

• Glossary

Spotted an error? Report it to our corrections log. Read our editorial methodology.