Question 1

Are manufacturers legally liable under the Cyber Resilience Act when a vulnerability occurs?

Accepted Answer

Manufacturers face regulatory liability and administrative fines under Article 64 of Regulation (EU) 2024/2847 when they breach essential requirements, fail to maintain technical documentation, or miss Article 14 statutory reporting deadlines. The regulation does not establish strict liability for the mere existence of a vulnerability. Instead, authorities penalise failures of cybersecurity diligence, absent vulnerability handling procedures, and failure to notify ENISA and designated CSIRTs within 24 hours of becoming aware of active exploitation. Completing conformity assessments and documenting ongoing vulnerability handling directly mitigates penalty exposure under statutory proportionality criteria. The CRA regulates diligence, processes, and disclosure rather than guaranteeing total immunity from security flaws. Documenting each conformity artifact is the primary legal defence.

Question 2

Do I have to use the ENISA single reporting platform to report under the CRA?

Accepted Answer

Article 14(7) leaves no alternative channel for mandatory notifications. Early warnings and the notifications that follow are submitted via the single reporting platform established under Article 16, using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where you have your main establishment in the Union, and the submission is simultaneously accessible to ENISA. Voluntary reports under Article 15 are different, going to a coordinating CSIRT or ENISA and processed through the same Article 16 procedure. The platform is due to be operational on 11 September 2026. The platform serves both the mandatory and voluntary channels, so a single filing route covers reporting duties and discretionary disclosures alike.

Question 3

Do I have to wait for the EN 40000 standards before I can comply with the CRA?

Accepted Answer

Waiting is the wrong plan. No part of the EN 40000 series has been cited in the Official Journal, so the Article 27 presumption of conformity is unavailable, and Article 32(2) escalates a Class I important product to third-party assessment precisely where a manufacturer has not applied a harmonised standard or where none exists. Compliance is owed from 11 December 2027 whatever the standards do. The series is drafted under Commission standardisation request M/606, with parts 1-1, 1-2 and 1-3 past public enquiry and awaiting approval. Applying the current drafts, and the recognised standards they build on, is the low-regret path. A technical file argued against those is far easier to migrate than one argued from scratch.

Question 4

Do I have to report the same incident under the CRA, NIS2 and GDPR?

Accepted Answer

One event can trigger all three, and none of them excuses the others. CRA Article 14 binds the manufacturer when a vulnerability in its product is actively exploited or a severe incident affects product security, filed to a coordinating CSIRT and ENISA. NIS2 Article 23 binds essential and important entities when a significant incident disrupts their own services. GDPR Article 33 binds the controller within 72 hours of a personal data breach. The triggers, the subjects and the recipients differ, so the filings run in parallel. The 24 and 72 hour rhythm is deliberately similar across the CRA and NIS2, which is what makes the two easy to confuse and dangerous to conflate.

Question 5

Does the EU Cyber Resilience Act apply to open source software and CRA open source stewards?

Accepted Answer

The Cyber Resilience Act (Regulation (EU) 2024/2847) covers free and open source software only where it is supplied for distribution or use in the course of a commercial activity. Software its manufacturer does not monetise stays outside the scope. A paid or enterprise edition is placed on the market and carries the full manufacturer obligations. Legal persons who sustain a project intended for commercial use fall under the lighter CRA open source steward regime in Article 24, which carries no CE marking and no administrative fines. The commercial activity test applies to how the software is supplied. How the project was developed or financed stays out of the assessment.

Question 6

Does the CRA cover my web application?

Accepted Answer

Generally no. Commission guidance confirms that software which executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements. A web application reached exclusively through a browser therefore falls outside the CRA, as does a website that only presents information. Two things pull you back in. Shipping a client that users install and run locally is in scope, even where it is built with web technologies. And your backend enters scope where it supports a function of some other product. Falling outside the CRA does not mean falling outside EU cybersecurity law. NIS2 covers cloud computing service providers, and DORA covers financial entities and their ICT providers.

Question 7

How do I prepare for the 11 December 2027 CRA deadline?

Accepted Answer

Article 71(2) sets three dates rather than one, and the order they arrive in dictates the sequence. Classify every product first, because that decides whether a notified body is involved and third-party assessment is scheduled in quarters. Stand up vulnerability intake and deadline tracking before 11 September 2026, when Article 14 applies. Run the risk assessment and close the Annex I requirements with evidence through 2026 and 2027. Assemble the technical documentation, declaration of conformity and CE marking ahead of 11 December 2027. The awkward part of the ordering is that the reporting duty binds 15 months before the disclosure process that feeds it becomes formally mandatory.

Question 8

How many EU reporting clocks does one medtech security incident start?

Accepted Answer

Four regimes can bind one medtech organisation at once, and the CRA and the MDR never bind the same product. CRA Article 2(2)(a) excludes any product to which Regulation (EU) 2017/745 applies, so CRA Article 14 reaches the surrounding software and connected products from 11 September 2026. MDR Article 87 sets 2, 10 or 15 day deadlines by severity. NIS2 Article 23 sets 24 hours. GDPR Article 33 sets 72 hours. The exclusion attaches to a product rather than to a company, so a manufacturer holding one device certificate and one connected accessory carries both regimes across its portfolio.

Question 9

Is my software update a substantial modification under the CRA?

Accepted Answer

Ask four questions from Commission guidance point 110. Does the update introduce new threat vectors, enable new attack scenarios, change the likelihood of previously identified attack scenarios, or change their impact? Where all four are negative and the assumptions in your risk assessment still hold, the update is unlikely to be substantial. Any single yes makes it substantial, as does a change to the intended purpose the product was assessed against. The size of the change is irrelevant. A substantially modified product is newly placed on the market, which triggers a fresh conformity assessment and its own declared support period. Conformity work may focus on the modified parts where the change does not harm the product's cybersecurity as a whole.

Question 10

Is there a CRA harmonised standard for my product category yet?

Accepted Answer

A draft or a work item exists for every Annex III category, and none of it is cited in the Official Journal, so the Article 27 presumption of conformity is unavailable for every product category without exception. Standardisation request M/606 splits into horizontal standards covering all products and vertical standards covering one category each. ETSI drafts most verticals as the EN 304 6xx series, where the number is 304 600 plus the mandate line item. CEN and CENELEC hold the semiconductor, smartcard, identity and metering categories. Knowing which committee drafts your category tells you which work programme to watch. It does not change your conformity assessment route today, because nothing in either family is cited.

Question 11

What do I actually have to do to comply with the Cyber Resilience Act?

Accepted Answer

Compliance runs as an ordered sequence where each step feeds the next. Confirm the product is in scope and that you are its manufacturer, then classify it as default, Annex III important class I or II, or Annex IV critical. Run the Article 13(2) risk assessment, which determines which Annex I Part I requirements apply. Build to those, meet the Part II vulnerability handling requirements, compile Article 31 technical documentation, complete the Article 32 conformity assessment, draw up the EU declaration of conformity, affix the CE marking, and report under Article 14. The order matters. The risk assessment sets the scope of everything downstream, and the conformity assessment route depends on the classification settled before it.

Question 12

What documents and reports does the Cyber Resilience Act require me to produce?

Accepted Answer

The Cyber Resilience Act requires six artefacts. Technical documentation under Article 31 and Annex VII, which contains the risk assessment. An EU declaration of conformity under Article 28 and Annex V. A software bill of materials and a coordinated vulnerability disclosure policy, both under Annex I Part II. Information and instructions to the user under Annex II. Then the Article 14 filings once reporting begins. Technical documentation and the declaration are kept available to market surveillance authorities for at least 10 years or the support period, whichever is longer. Only the Annex II user information and the CE marking travel with the product. Everything else is held and produced on request, which is why the retention rule matters as much as the drafting.

Question 13

What does the Cyber Resilience Act require in a cybersecurity risk assessment?

Accepted Answer

Article 13(2) of the Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to assess the cybersecurity risks of a product with digital elements and to carry the outcome through the planning, design, development, production, delivery and maintenance phases. Article 13(3) requires that assessment to be documented, kept updated across the support period, and to state which Annex I Part I point 2 requirements apply and how they are met. It forms part of the technical documentation under Article 31 and Annex VII, and the duty applies from 11 December 2027. Products placed on the market before 11 December 2027 sit outside that duty unless they undergo a substantial modification, although the Article 14 reporting obligations still reach them.

Question 14

What specific violations trigger administrative fines and penalties under CRA Article 64?

Accepted Answer

Administrative fines under Article 64 follow a three-tier statutory structure based on the category of infringement. Tier 1 imposes fines up to €15,000,000 or 2.5% of worldwide turnover for breaches of Annex I essential requirements, Article 13 obligations, or Article 14 statutory reporting duties. Tier 2 applies penalties up to €10,000,000 or 2% for non-compliance with conformity assessment procedures, CE marking rules, technical documentation mandates, or distributor obligations. Tier 3 levies up to €5,000,000 or 1% for providing false or misleading information to market surveillance authorities. Fines are issued by Member State market surveillance authorities under national procedural law and must remain proportionate to company scale and breach severity.

Question 15

When does the CRA reporting clock start?

Accepted Answer

The clock starts when you become aware, and Commission guidance now defines that moment. On detecting a suspicious event or receiving a report from a researcher, customer or authority, assess it immediately. You become aware once that initial assessment gives you a reasonable degree of certainty that a vulnerability in your product is being actively exploited, or that a severe incident has compromised your product's security. Receiving a report does not by itself start the clock, and neither does a vague suspicion you have not yet examined. The Commission deliberately aligned this test with the NIS2 implementing regulation and the EDPB breach-notification guidelines, so a manufacturer caught by several regimes can apply one awareness standard rather than three.

Question 16

Which CRA product class is my product in?

Accepted Answer

Your class turns on core functionality. Where a product has the core functionality of a category listed in Annex III it is an important product, class I or class II as that annex divides them. Where it has the core functionality of an Annex IV category it is critical. Everything else is default. Default and class I products can use internal control under module A, class I only while harmonised standards cover every applicable requirement. Class II and critical products always need a third party. The classification decides only the conformity assessment route. The Annex I essential requirements themselves apply identically across all four tiers.

Question 17

Which CSIRT do I report to under the CRA, and how does the ENISA single reporting platform work?

Accepted Answer

Article 14(7) of the Cyber Resilience Act routes every notification to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment in the Union, meaning where decisions about the cybersecurity of its products are predominantly taken. A manufacturer with no establishment in the Union follows a four-step fallback based on authorised representative, importer, distributor, then users. One submission through the ENISA single reporting platform reaches that CSIRT and ENISA simultaneously, and the deadlines run from 11 September 2026. The determination is made once and recorded, because the 24-hour clock leaves no room to work out the routing after a vulnerability is already being exploited.

Question 18

Which products are outside the scope of the CRA?

Accepted Answer

Article 2 carves out six groups. Medical devices under Regulations 2017/745 and 2017/746, motor vehicles under Regulation 2019/2144, products certified under the aviation Regulation 2018/1139, and marine equipment under Directive 2014/90/EU are excluded outright. So are spare parts manufactured to the same specifications as the identical components they replace, and products developed or modified exclusively for national security or defence, including anything specifically designed to process classified information. Everything else made available on the Union market with a data connection is in scope from 11 December 2027. Each exclusion exists because another instrument already carries the cybersecurity duty, so an excluded product is regulated elsewhere rather than unregulated.

Cyber Resilience Act FAQ

Scope and applicability