Client Alert: The EU Cyber Resilience Act

A Brief Guide for Compliance

OVERVIEW: The Cyber Resilience Act makes cybersecurity a mandatory, enforceable product requirement for software and connected hardware sold in the EU by manufacturers anywhere, including those in the US who sell or distribute into the EU. Vulnerability and incident reporting obligations begin September 11, 2026; full compliance is required by December 11, 2027. Penalties for non-compliance can be severe.

What It Is?

The Cyber Resilience Act is the EU’s first horizontal, cross-sector cybersecurity regime for “products with digital elements.” It replaces a patchwork of sector-specific rules with lifecycle-long obligations enforced through a CE-marking regime under the EU’s New Legislative Framework (a CE mark asserts legal compliance). In short: if a product runs software or connects to a network and is sold in the EU, the CRA likely applies, and security is now a legal product requirement rather than a marketing choice. Products placed on the EU market before December 11, 2027 do not need to be brought into CRA conformity unless they are substantially modified afterwards (Article 69(2)); under the Commission’s draft guidance, the manufacturer must be able to show that a later update is not a substantial modification. Products already in the marketplace before that date, however, will be subject to certain reporting obligations September 11 of this year.

Who Is Covered?

Coverage turns on one question: does a company place a “product with digital elements” on the EU market in the course of commercial activity? That category is intentionally broad: consumer apps, business software, firmware, operating systems, security tools, and software components supplied on their own. It also reaches cloud-based functions that a covered product needs in order to operate and that the manufacturer builds or commissions (“remote data processing solutions”). Standalone SaaS with no accompanying product is generally understood to fall outside scope, but the boundary is unsettled and Commission guidance is still developing; SaaS providers should not assume exclusion without a fact-specific analysis. In practical terms, two conditions must both be met: the item is a product with digital elements, and it has a direct or indirect data connection to a device or network. Purely offline products that never communicate are therefore outside scope. Stand-alone SaaS typically falls outside the CRA unless it is a “remote data processing solution” for a covered product (Art. 3(2)); such cloud services are governed primarily by NIS2, DORA and the GDPR.

“Manufacturer” is defined functionally, not geographically. A U.S. company selling into the EU, directly or through distributors, is a manufacturer subject to the full regime, and so is a company that brands a third party’s product as its own (relevant to OEM and white-label deals). Importers and distributors carry independent verification and due-care duties, and EU partners will push CRA compliance and indemnity terms upstream by contract.

An entity that markets a product with digital elements under its own brand, or makes a “substantial modification” affecting cybersecurity before placing it on the market, is itself treated as the manufacturer with the full Article 13 and 14 obligations — a point to check carefully in OEM, white-label and integrator structures.

As a result of extensive efforts by open source software advocates to educate European policy makers, individuals and entities that are “open-source software stewards” (Article 3(14)) have a special status under the CRA. An OSS steward is a legal person, other than a manufacturer, that sustainably and systematically supports the development of open-source products intended for commercial use (typically a foundation or similar body) without itself commercialising them. Stewards carry only the lighter Article 24 duties: maintaining a cybersecurity policy, cooperating with market surveillance authorities, and reporting actively exploited vulnerabilities and severe incidents. They are not subject to conformity assessment, CE marking or technical documentation requirements, and are exempt from the Article 64(3)–(9) fines (Article 64(10)), though the Article 64(2) fines still apply. Individual contributors of bug fixes and the like are not considered to be OSS Stewards.

While non-commercial open source stays outside the CRA, commercialized open source (paid support, SLA-backed hosting, SaaS delivery, professional services, dual licensing, or integration into a paid product under one’s own name) makes the actor a manufacturer with full obligations. Note that one organization can be both: a steward for the upstream project and a manufacturer for a commercial distribution it ships.

Contact Us Today:

Name *

First

Last

Phone Number *

Name Number URL

Email *

How Can We Help?

Department:

• Corporate & Tax
• Litigation & Employment
• Consortium & Open Source
• Intellectual Property

How did you hear about us?Select an answerSearchSocial mediaReferral

Referral Name

Sent from Page URL

Submit

Core Obligations:

Secure by Design

Before placing a product on the market, the manufacturer must perform a cybersecurity risk assessment and ensure the product meets the essential requirements in Annex I to the CRA. Those requirements include secure-by-default configuration, no hard-coded default passwords, protection of the confidentiality, integrity, and availability of data, a minimized attack surface, secure update mechanisms, and documented vulnerability disclosure. The standard is risk-based management of known vulnerabilities, not a zero-vulnerability condition. Because the regime is risk-based, the Annex I requirements must be applied and documented product by product against the cybersecurity risk assessment, rather than as a uniform checklist.

Vulnerability Reporting

From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to the designated national Computer Security Incident Response Team (CSIRT) and to ENISA, the European Union Agency for Cybersecurity, through a single reporting platform. Reports follow a three-stage timeline: an early warning within 24 hours of awareness, a detailed notification within 72 hours, and a final report. This obligation reaches products already on the EU market, so reporting infrastructure must be operational before the deadline rather than put in place in response to the first incident. The duty attaches to the manufacturer’s actual knowledge and applies alongside (not instead of) NIS2 and GDPR reporting, so a single event can trigger parallel deadlines. Reporting is filed once through ENISA’s Single Reporting Platform (from September 11, 2026), which routes it to the coordinating CSIRT, set by the manufacturer’s main establishment, or its EU authorised representative if it is not EU-established (Article 14(7)), and to ENISA; beyond the 24-hour and 72-hour steps, the final report is due within 14 days of a fix for a vulnerability or one month after the 72-hour notification for a severe incident, and third-party-component vulnerabilities must still be reported.

Support Period and Updates

Manufacturers must provide free security updates throughout the product’s support period. Under Article 13(8), that period must reflect the product’s expected use time and must be at least five years, unless the product is expected to be in use for a shorter period (in which case it tracks that shorter life). For longer-lived products, such as much industrial equipment, the period must be correspondingly longer. Manufacturers should therefore document a defensible support period for each product. The expected lifetime and its justification should be documented for each product line; for long-lived equipment such as industrial or networking gear, the period will often run well beyond five years.

Component Responsibility

Manufacturers are responsible for the security of the entire component stack, including third-party and open-source libraries, and cannot rely solely on upstream maintainers. The CRA requires a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the product’s top-level dependencies, though it does not prescribe a specific standard. Technical documentation must be available to market surveillance authorities on request. Selecting third-party and open-source components will require documented due diligence (e.g., CE conformity where relevant, updated history and known-vulnerability databases) and SBOMs are expected in common formats such as SPDX or CycloneDX.

Conformity Assessment and CE Marking

In order to comply, manufacturers must prepare technical documentation, issue an EU Declaration of Conformity, and affix the CE mark. The assessment route depends on classification: most products self-assess; “important” Class I products (e.g., password managers, identity management software) can self-assess where harmonized standards are applied, otherwise a notified body is required; “important” Class II products (e.g., firewalls, intrusion detection systems) and “critical” products (e.g., hardware security modules, smartcards) require notified-body assessment. Building to harmonized standards earns a presumption of conformity, a meaningful operational advantage.

Penalties

National market surveillance authorities enforce the CRA in three tiers (Article 64), with the higher of the two figures applying:

• Up to €15 million or 2.5% of worldwide annual turnover: for breach of the essential requirements (Annex I) or the core manufacturer obligations, including vulnerability handling and reporting (Articles 13 and 14). This also applies to open-source software stewards
• Up to €10 million or 2%: for violating other obligations, including importer and distributor duties, conformity assessment, and CE marking.
• Up to €5 million or 1%: for supplying incorrect, incomplete, or misleading information to authorities or notified bodies.

Cyber Resilience Act compliance status will also be a material factor in any civil-liability analysis under the revised EU Product Liability Directive (Directive (EU) 2024/2853), which extends liability to software defects and AI-related harms. A failure to meet CRA security requirements is an important factor that courts must weigh when assessing whether a product is “defective” (Article 7(2) of the Product Liability Directive); conversely, documented CRA compliance strengthens the manufacturer’s defence, so CRA compliance is also a matter of liability management.

Beyond Fines

The administrative penalties above are only the starting point of CRA exposure. Non-compliance can also trigger regulatory enforcement, loss of EU market access, civil liability and significant commercial fallout:

• Market surveillance measures. Authorities can order corrective action, require a product to be brought into conformity, and restrict, prohibit, withdraw or recall it from the EU market (Articles 52–56 Cyber Resilience Act; Regulation (EU) 2019/1020) — including where a product is CE-marked but still presents a significant cybersecurity risk.
• Loss of market access. Without a valid CE marking a product may not lawfully be placed on the EU market, and border authorities can refuse its entry into free circulation.
• Civil product liability. Under the revised EU Product Liability Directive (2024/2853), software and digital elements are expressly covered by strict, no-fault liability, and unpatched vulnerabilities or defective or missing security updates can themselves constitute a product defect.
• Presumption of defect / eased burden of proof. Failure to meet Cyber Resilience Act requirements — e.g. omitting mandated security updates during the support period — can trigger a rebuttable presumption that the product is defective; recoverable damage now also includes the destruction or corruption of data.

Interaction With Other EU Regimes

The Cyber Resilience Act runs alongside, and does not displace, the NIS2 Directive (separate incident reporting for essential and important entities), the Radio Equipment Directive cybersecurity delegated act (overlapping duties for wireless products), and the revised Product Liability Directive. Compliance with one regime does not satisfy another; companies subject to more than one need parallel, coordinated processes. Product-specific cybersecurity rules, such as with respect to medical devices, motor vehicles, aviation and machinery, can take precedence over the CRA in whole or in part, shifting rather than removing obligations; cloud and SaaS providers sit primarily under NIS2, DORA and the GDPR.

What to Do Now?

The December 2027 deadline allows meaningful lead time; the September 2026 reporting deadline does not. Priorities:

• Audit the product portfolio. Identify every product reaching EU customers and classify each under Annexes III and IV. Analyze SaaS and cloud components carefully rather than assuming exclusion.
• Stand up 24-hour reporting infrastructure before September 2026, as the CRA reaches products already on the market.
• Map dependencies and build SBOM discipline across third-party and open-source components, including mitigation processes where upstream patches lag.
• Define and document support periods product by product; five years is the statutory floor for most products, not a ceiling for longer-lived ones.
• Track and build against harmonized standards to earn the presumption of conformity.
• Determine the conformity-assessment route and engage notified bodies early. Notified-body capacity will likely tighten as 2027 approaches. The CRA’s provisions on conformity-assessment bodies (Chapter IV) already apply from June 11, 2026, so notified-body capacity should be secured early.
• Address authorized-representative and distribution-chain obligations. Decide whether to appoint an EU authorized representative, which is optional under the Cyber Resilience Act (Article 18) but can serve as the regulatory point of contact, and review distribution and OEM agreements for allocation of CRA obligations and liability. Appointing an EU authorised representative remains optional as a matter of law (Article 18), but is advisable from a practical standpoint.
• Run a scope check per product line. Cover exemptions, sector-specific rules and the legacy-product versus substantial-modification distinction, so effort is not spent on out-of-scope or grandfathered products.
• Decide early on European cybersecurity certification. Assess whether certification (e.g. EUCC) is worthwhile to ease conformity and market access in sensitive sectors.
• Build integrated reporting governance. Span CRA, NIS2, GDPR and, where relevant, DORA, with clear roles, 24/7 reachability and templates so the 24-hour and 72-hour deadlines can realistically be met.

Compliance Timeline — Key Dates and What Must Be Done

The Cyber Resilience Act phases in over three years; the reporting infrastructure — not full conformity — is the first hard operational deadline. Key dates:

How We Can Help?

Gesmer Updegrove LLP advises software companies, standards developers, and open-source foundations on regulatory compliance, product terms, supply chain contracting and risk management. Working with our EU law-firm network partners, we can assist with Cyber Resilience Act product classification and scope analysis, conformity-assessment planning, harmonized-standards mapping, vulnerability-disclosure program design, EU-compliant license terms, authorized-representative arrangements, and commercial agreements that allocate CRA-driven obligations across your distribution and OEM chain.

We are grateful for the assistance of Roman Ronneburger of the law firm S.E.S Berlin for assistance in preparing this client alert.

Note: This alert provides general information and does not constitute legal advice. Gesmer Updegrove LLP is a United States law firm and is not admitted to practice law in any EU jurisdiction. CRA requirements continue to evolve through implementing regulations, harmonized standards, and Commission guidance; this summary reflects the law and available guidance as of June 2026. Please contact us to discuss your specific situation.

Meet the AuthorAndrew UpdegrovePartner