QUESTIONS ON THE CRA

No. Entry into force and application are two different things. The regulation entered into force on 10 December 2024 (Art. 71(1)), but the manufacturer obligations start later and in stages (Art. 71(2)).

The first date that hits manufacturers directly is 11 September 2026 — from then Art. 14 and its reporting obligations apply. The rest of the regulation, including the essential requirements, conformity assessment and the CE marking, applies from 11 December 2027. What happens in the meantime on the side of the Commission and the Member States, and why the intermediate date of 11 June 2026 is a rule for the authorities and not for you, is covered in the guide section on entry into force and application.

The practical consequence: today there is no duty to have a CE marking or technical documentation under Annex VII, but it is the last moment to have a working reporting process.

Art. 14 becomes applicable, that is, two reporting obligations of the manufacturer: actively exploited vulnerabilities in the product and severe incidents having an impact on the security of the product. Reports go simultaneously to the CSIRT designated as coordinator and to ENISA, within 24 hours and 72 hours, with a final report within 14 days for a vulnerability and within one month for an incident.

Nothing else changes on that day. The essential requirements of Annex I, conformity assessment, the EU declaration of conformity and the CE marking do not start applying on 11 September 2026 — those arrive on 11 December 2027.

What exactly goes into each report, when each deadline starts and who the report is submitted to is set out in the guide section on reporting.

Not because of the essential requirements. Products placed on the market before 11 December 2027 are subject to them only if they undergo a substantial modification after that date (Art. 69(2) in conjunction with Art. 3 point 30).

The reporting obligation is expressly carved out of that rule: Art. 14 applies to products placed on the market earlier as well (Art. 69(3)). So from 11 September 2026 you report actively exploited vulnerabilities across the whole portfolio you have on the Union market, not only in the new products. The transitional provisions, including what counts as a substantial modification, are covered in the guide.

That leads to a task that is often overlooked: keeping an up-to-date list of everything you have on the market, with the version, the components and the owner for each item. Without it the 24-hour deadline cannot be met, because there is no way to work out within it which products a vulnerability affects.

Yes, two, and both are already published:

• Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 (published on 1 December 2025) — the technical description of the categories of important and critical products from Annexes III and IV. For classifying a specific product this is the main document today.
• Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 (published on 20 April 2026) — the conditions under which the dissemination of a notification between CSIRTs may be delayed on cybersecurity grounds under Art. 16(2).

On top of that, the Commission issued its first guidance on the application of the CRA on 27 July 2026 (communication C(2026) 5252) — scope, remote data processing solutions, open source, substantial modification, support period, reporting. The guidance is not binding, but it is currently the best indication of how the Commission reads the regulation.

Where each of them sits in time is shown by the timeline in the guide.

Waiting is not a strategy. A presumption of conformity only arises once the reference to a harmonised standard is published in the Official Journal (Art. 27(1)), and as of 8 August 2026 none is cited — the standards are still being drafted under standardisation request M/606. The state of standardisation and its effect on documentation is described in the guide section on categories and conformity.

Two things follow from that, in short. In the technical documentation you currently write a description of your own solution and the reason why it meets Annex I, instead of a reference to a standard (Annex VII point 5). And for class I important products the standards cannot be “fully applied”, so the route leads through a notified body (Art. 32(2)).

What the citation of standards will not change at all: the cybersecurity risk assessment under Art. 13(2) and (3), the vulnerability handling processes from Annex I Part II, and the support period. Those will be needed in every scenario, so there is nothing to be saved by waiting here.

Yes, being bespoke does not remove the obligations. Making available on the market means the supply of a product for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge (Art. 3 point 22). A single customer is a market too. A frequent misunderstanding: “but that is their system, not our product” — if you developed it and supplied it under your own name, you are the manufacturer under Art. 3 point 13.

There are exactly two reliefs and neither of them is an exclusion from scope: for the secure by default configuration (Annex I Part I point 2(b)) and for security updates being free of charge (Annex I Part II point 8) you may agree otherwise with a business user. Both are covered in the guide section on roles.

Everything else applies just as it does for an off-the-shelf product: risk assessment, SBOM, coordinated vulnerability disclosure policy, support period, reporting.

Pure cloud models — SaaS, PaaS, IaaS — fall under the NIS2 Directive, not under the CRA (recital 12). In the Czech Republic that means Act No. 264/2025 Coll., if you meet its criteria.

The boundary, though, is not where people usually look for it. Alongside the product itself, the CRA also covers a remote data processing solution — the server-side part without which the product would not perform one of its functions and which the manufacturer built itself (Art. 3 point 2, delimited in the guide).

A practical distinction: if the customer buys access to a service, it is NIS2. If they buy a product (an application, a device, a box) and your backend is the thing without which the product would not work, it is the CRA, including that backend. One entity can have both — a service offering and a product — and then deals with each regime separately.

You are. A manufacturer is not only the party that develops or manufactures the product, but also the party that has it manufactured and markets it under its own name or trademark (Art. 3 point 13). White label therefore means manufacturer, with all the obligations including conformity assessment, technical documentation and reporting under Art. 14; the same applies to importers and distributors who place a product on the market under their own name or substantially modify it (Art. 21, the roles broken down in the guide).

In practice this is the most unwelcome finding, because the obligations land on someone who has no technical visibility into the product. They cannot be transferred by contract — a contract can secure the supplier's cooperation, but responsibility towards the market surveillance authority stays with the manufacturer.

The things you genuinely need from the supplier: the SBOM, the support period of its components, a channel for security updates, and a commitment to inform you about vulnerabilities before it informs customers.

It depends on what you do with the product, and the boundary is a substantial modification under Art. 3 point 30 — a change that affects compliance with the essential requirements of Annex I, or that modifies the intended purpose of the product (the context is in the guide).

• You supply a third-party product without touching its properties and under its brand — you are a distributor with the obligations under Art. 20: verify the CE marking, the EU declaration of conformity and the information for users, and do not supply a product you know, or have reason to believe, does not meet the requirements.
• You add your own firmware, change the configuration in a way that changes the security properties, or offer the solution under your own name — you are a manufacturer.

It is not worth leaving this to be decided by an inspection. It helps to go through the portfolio of engagements and write one sentence for each about the role you have there and why — with a reference to what specifically you changed. You will reach the same answer two years later, and it doubles as the material you put in front of the market surveillance authority. Borderline cases are described in the Commission guidance of 27 July 2026, which works with 67 examples aimed at smaller companies.

What decides is monetisation, not the way the software is developed. Free and open-source software supplied outside a commercial activity falls outside the scope of the regulation, and contributing source code to someone else's project does not create manufacturer obligations (recital 18).

Conversely, a party that provides sustained support for the development of specific free software intended for commercial use, and keeps it viable, may fall into the lighter role of an open-source software steward (Art. 3 point 14 and Art. 24) — without the CE marking and without administrative fines (Art. 64(10)). What that role involves is summarised in the guide section on roles.

Where it does break the other way: if you build an open source component into your commercial product, you are responsible for it within that product — including due diligence when integrating it and the duty to report a vulnerability you find to whoever maintains the component (Art. 13(5) and (6), in detail in the guide). “We take and never give back” stops being a sustainable model at this point.

The regulation applies to products made available on the market (Art. 2(1)), and making available on the market is defined as supply for distribution or use in the course of a commercial activity (Art. 3 point 22). An internal tool you supply to nobody falls outside the scope.

Two things are worth watching, though. First, this changes easily — supplying it to a single customer, delivering it to a sister company, or offering the tool outside the organisation flips the situation, and the fact that it is free of charge makes no difference (Art. 3 point 22). Second: if you are at the same time a regulated entity under Act No. 264/2025 Coll., your in-house development does not lose its obligations, they are simply handled by different legislation — there it is about the security of your service, not about the properties of a product on the market.

Borderline cases inside a group of companies are addressed by the Commission guidance of 27 July 2026; before you reach for it, it pays to have written down clearly what counts as an internal tool and what is already a supply.

No. Only an actively exploited vulnerability is reported, that is, one for which you have reliable evidence of exploitation in a real system without the permission of its owner (Art. 3 point 42). A scan finding, a vulnerable library version in the SBOM or a publicly published CVE without evidence of exploitation do not fall under that definition.

That does not mean nothing happens with them — Annex I Part II puts them into the ordinary vulnerability handling process: remediate without delay and, once the fix is released, disclose information about the vulnerability and about how the user removes it. They are simply not reported to the ENISA platform. The difference between the two regimes is covered in the guide section on SBOM and vulnerability handling.

Where the practical problem lies: someone has to be able to make the “this is actively exploited” call quickly and defensibly, because the 24 hours run from it. We recommend writing down in advance who decides, from which inputs (telemetry, a customer report, a CSIRT advisory, public sources) and how the decision is recorded.

In short, it is an incident that negatively affects the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or may lead to the execution of malicious code in the product or on a user system (Art. 14(5); the full definition and typical examples are in the guide).

The difference from the Czech Cybersecurity Act (ZKB) and NIS2 lies in what the incident concerns. The ZKB deals with the impact on your regulated service, the CRA with the impact on the security of the product you placed on the market. An outage in your office is not an incident under Art. 14, however unpleasant it is for you.

One incident can fall under both regimes at once, and the deadlines run separately. If you are also a regulated entity under the ZKB, you report under the ZKB within 24 h / 72 h / 30 days (the recipient depends on the regime, via the NÚKIB portal) and under the CRA within 24 h / 72 h / 1 month via the single reporting platform — and it is worth making sure these are not two independent processes that know nothing about each other.

Reports go simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform under Art. 16. Which CSIRT is yours is determined by your main establishment in the Union; if you have none in the Union, the cascade in Art. 14(7) applies (set out in the guide). In the Czech Republic notifications are to be received by NÚKIB, so far only under a draft implementing act that has not been adopted.

On the platform: according to ENISA it is to be used for mandatory reporting from 11 September 2026, and the agency has published guides for registering manufacturer representatives (updated on 31 July 2026).

So sort out your access before you need it — registration has no effect on how the deadlines run. And keep a fallback procedure for the case where the platform happens to be down at that moment.

The deadline runs from the moment the manufacturer becomes aware of the vulnerability or the incident, and is met “without undue delay and in any event within 24 hours”. A round-the-clock shift is not what is needed — what is needed is a decision made in advance on who holds the deadline and how the information reaches them.

The minimum that works in practice:

• One inbound channel for external vulnerability reports (Annex I Part II point 6 requires it) and a clear rule on who watches it outside working hours as well.
• Decision criteria for “actively exploited” and “severe incident” written down beforehand, not at the moment of the decision.
• A named role with escalation and a deputy, including a contact for someone who can approve external communication.
• Pre-drafted texts for the early warning and the notification with the static details filled in (manufacturer identification, products, contacts), so that within the 24 hours only the description of the situation has to be added.
• A dry run — walk the whole procedure through on a made-up case and measure how long it would take for the first warning to go out.

What is critical is not the tooling but the fact that someone walks the procedure through once and finds the point where it jams. We run that exercise over a specific product.

The reporting obligation applies in the same way — microenterprises and small enterprises are not exempt from it. The difference is in the penalty, and it is narrower than is often stated: under Art. 64(10)(a) no fine is imposed on them for missing the deadline for the early warning within 24 hours (Art. 14(2)(a) and (4)(a)). The exemption does not cover the 72-hour deadline or the final report — a fine can be imposed there.

That does not mean the deadlines can be ignored. The duty to report remains and failing it remains an infringement of the regulation; only the fine for late submission falls away. And above all: the point of the 24-hour deadline is for the CSIRT and ENISA to learn about an actively exploited vulnerability before it spreads to further customers. That is in the manufacturer's interest, not just an obligation.

The regulation offers smaller companies further concessions — a simplified format of the technical documentation under Art. 33(5) (the form is to be set by the Commission in an implementing act) and support measures from the Member States under Art. 33, including regulatory sandboxes. The remaining exemptions from penalties are summarised in the guide section on penalties.

You do not. You must have a software bill of materials in a commonly used machine-readable format, covering at least the top-level dependencies of the product (Annex I Part II point 1), but publishing it is not required.

It goes out in two directions only: to a market surveillance authority upon a reasoned request when compliance is being checked, and to the user when the manufacturer decides so. Where exactly the SBOM belongs in the documentation, and what the Commission may still add to it, is described in the guide section on SBOM.

A practical note: “machine-readable” matters more in this context than “complete”. An SBOM that nobody can match automatically against a vulnerability database satisfies the letter and serves no purpose. A useful SBOM is generated during the build, versioned with the product, and feeds into vulnerability management — not a document produced once before an audit.

The floor is five years. A shorter period is permissible only for a product expected to be in use for less than five years; the support period then equals that expected time in use (Art. 13(8)).

A separate deadline runs alongside it: security updates you have already issued must be kept available for ten years, or for the remainder of the support period if that is longer (Art. 13(9)). This gets confused with the support period, but it is a different thing — not about issuing new fixes, but about keeping the issued ones available.

How the length of support is derived, why it is not a free judgement call and what caps it for products with integrated components is covered in the guide section on the support period.

Note that this is a decision taken before placing the product on the market: the month and year on which support ends must be stated at the time of purchase (Art. 13(19)), and after that it is hard to change.

As a rule, no. Annex I Part II point 8 requires security updates to be disseminated without delay and free of charge, accompanied by an advisory message providing users with the relevant information, including the action to be taken. Functionality updates can be charged for, security updates cannot.

There is one exception and it is narrow: for products made to order, a different arrangement with a business user is possible. It does not apply to off-the-shelf products or to consumers.

A related requirement is often overlooked: where technically feasible, security updates should be separate from functionality updates (Annex I Part II point 2; the other process obligations in Part II are in the guide). The reason is operational — a customer who has to accept a change in the behaviour of the product in order to get a security fix will postpone it. If your release strategy does not allow for that, it is a change in your release architecture, not in the documentation, and it does not get done in a month.

It is the first requirement of Annex I Part I point 2, letter (a): the product is made available on the market without known exploitable vulnerabilities. It does not mean “without vulnerabilities” — that could not be met. It means that where a vulnerability is known and exploitable, you know about it and removed it before the product went to market.

In practice this pushes on two things in development. The first is knowing what is in the product — without an SBOM and its automatic evaluation against vulnerability databases there is no way to claim that no known exploitable vulnerability is present. The second is a pre-release gate: the decision on which findings block a release and who may grant an exception is made in advance, not during the release.

Letter (a) is only one of the thirteen requirements in point 2, and above them stands the general point 1 — an appropriate level of security based on the risks. The full list, and what the market surveillance authority asks about it, is in the guide section on security in design. With clients we usually build that pre-release gate together with the way scan findings are evaluated in the product.

Yes. Annex I Part II point 5 requires you to put in place and enforce a coordinated vulnerability disclosure policy, and point 6 a contact address for reporting vulnerabilities, including information on where the policy is published.

The regulation does not prescribe the contents in detail, but they can be derived from the other points of Part II: how to report a vulnerability, what the reporter can expect and in what time, how the overlap with the fix is handled, and when and what gets disclosed (an overview of the Part II points is in the guide).

The policy is best treated as an operational document, not a legal one. If it states a deadline you cannot hold, it will hurt you more than its absence. A useful minimum: an address that is genuinely read, an acknowledgement of receipt, one accountable role, and an internal rule that an external report goes into the same process as a finding from your own testing.

The regulation works with three levels:

• Default product — everything that is not in Annexes III and IV.
• Important product — Annex III, class I: among others operating systems, browsers, password managers, VPNs, SIEM, identity and privileged access management, routers and switches, network management systems, microprocessors and microcontrollers with security-related functionalities, smart home products with a security function, internet connected toys and personal wearables for health monitoring.
• Important product — Annex III, class II: hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers.
• Critical product — Annex IV: hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing, and smartcards or similar devices including secure elements. A note for anyone working from the Czech text: the second Annex IV item is rendered there as wording about secure receipt of cryptocurrency payments — it is the same point, only translated badly from “secure cryptoprocessing”; in substance it is secure cryptographic processing, not payments.

What decides is the core functionality of the product as a whole (Art. 7(1)) — an integrated component does not turn the product into an important product; there is an example in the guide section on categories and conformity.

The annexes describe the categories by name only. The technical description was added by Implementing Regulation (EU) 2025/2392 and for classifying a specific product this is the main document today. Our recommendation: write the classification down, justify it and date it. It is the first thing the market surveillance authority will ask you for, and the second thing it will want to challenge.

It depends on the category (Art. 32; the link to product categorisation is in the guide):

• Default product — internal control, module A, is enough. The manufacturer carries out the assessment itself, on its own responsibility.
• Class I important product — internal control is possible, but only if you have fully applied harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least “substantial”. Otherwise EU type-examination (module B followed by module C) or full quality assurance (module H) is required — that is, a notified body.
• Class II important product — a third party always, that is, module B + C, module H, or a European cybersecurity certificate.
• Critical product — the Commission may, by delegated act, require a European cybersecurity certificate at assurance level at least “substantial” (Art. 8(1)); until such an act exists, the class II regime applies.

The practical effect for 2026: because no harmonised standard is cited as of 8 August 2026, class I products cannot rely on “full application” of a standard and the route leads through a notified body, whose capacity is only being built up (Chapter IV applies from 11 June 2026). Anyone who will need a third party has a reason to deal with it before 2027.

The scope is set by Art. 31 and Annex VII. It can be read as three blocks:

• What the product is — the description, the intended purpose, the versions affecting conformity and the information for users under Annex II.
• How it was built and how it is maintained — design, development and production, vulnerability handling processes, the SBOM, the coordinated disclosure policy, the contact address for reporting, secure distribution of updates.
• What evidences it — the risk assessment under Art. 13, the material behind the support period, the standards applied or a description of your own solutions, test reports and the EU declaration of conformity.

Item by item, this is set out in the guide section on conformity assessment. Microenterprises and small enterprises may in addition provide elements of the documentation in a simplified format, the form of which is to be set by the Commission in an implementing act (Art. 33(5)), and notified bodies have to accept it.

One thing in the documentation cannot be made up after the fact: under Art. 13(2) and (3) the risk assessment has to come into being during planning, design, development and maintenance, not after them, and a document written a week before an inspection will not evidence that (the context is in the guide). That is why in engagements we start with how the team decides about risk, not with a document template.

The fines are set by Art. 64 and there are three bands depending on what is infringed. In each case the higher of the two figures applies, and turnover means worldwide annual turnover for the preceding financial year:

• EUR 15 000 000 or 2.5 % of turnover — the essential requirements of Annex I and the obligations under Art. 13 and 14, that is, product properties, risk assessment, support period and reporting (paragraph 2).
• EUR 10 000 000 or 2 % of turnover — the obligations of authorised representatives, importers and distributors (Art. 18 to 23), the EU declaration of conformity (Art. 28), the CE marking (Art. 30), technical documentation (Art. 31), conformity assessment procedures (Art. 32) and the obligations of notified bodies (Art. 39, 41, 47, 49 and 53) — paragraph 3.
• EUR 5 000 000 or 1 % of turnover — incorrect, incomplete or misleading information supplied to notified bodies and market surveillance authorities in response to their request (paragraph 4).

There are two exemptions, both in Art. 64(10): microenterprises and small enterprises are not fined for missing the deadline for the early warning within 24 hours (point (a); the exemption does not extend to the 72-hour deadline or the final report), and open-source software stewards are not subject to administrative fines under the regulation at all. What determines the amount of a fine in a particular case is in the guide section on penalties.

The designation of market surveillance authorities is left to the Member States (Art. 52). In the Czech Republic this is to be settled by an implementing act, the draft of which was sent by the Ministry of Industry and Trade for interministerial comments on 3 July 2026. Under the draft, NÚKIB is the notifying authority and the recipient of notifications under Art. 14 and 15, market surveillance is to be split by sector, and the main part of the agenda including software and consumer electronics is to go to the Czech Trade Inspection Authority.

As of 8 August 2026 this is a draft, not a law in force, and the split of supervision may still change. It changes nothing about manufacturer obligations — the regulation is directly applicable.

It helps as a foundation, but it does not create a presumption of conformity. That arises solely from applying a harmonised standard whose reference has been published in the Official Journal (Art. 27(1)) — and as of 8 August 2026 no such standard exists for the CRA. A certificate under ISO/IEC 27001 or IEC 62443 therefore does not by itself evidence conformity with Annex I.

What genuinely carries over from existing systems: vulnerability handling processes, asset and component records, change management and testing can be mapped onto Annex I Part II. The secure development lifecycle under IEC 62443-4-1 covers a large part of what Annex I Part II asks of the manufacturer.

What you will not find in them and will have to add: the product-level risk assessment under Art. 13(2) and (3) (ISO 27001 deals with organisational risk, not with the properties of a product on the market), the support period and the evidence behind it, the SBOM in a machine-readable format, the reporting process under Art. 14 and the technical documentation under Annex VII, including the EU declaration of conformity and the CE marking. The difference from the Czech Cybersecurity Act is substantial: there your management system is assessed, here the properties of the product and the evidence of how they came about.

No, the regulation deals with this situation. Under Art. 12, products with digital elements that fall within the scope of the CRA and are at the same time classified as high-risk AI systems under Art. 6 of Regulation (EU) 2024/1689 are deemed to comply with the cybersecurity requirements in Art. 15 of the AI Act, provided they meet the essential requirements of Annex I Part I, the manufacturer processes meet Part II, and the level of protection achieved is documented in the EU declaration of conformity.

It does not work the other way round and it does not cover the whole AI Act — only cybersecurity under its Art. 15. The AI Act requirements on data, transparency, human oversight and AI risk management remain separate.

The boundary towards other regimes is arranged in a similar way: products covered by sectoral legislation are excluded from the scope of the CRA — medical devices, vehicles, aviation, marine equipment, spare parts produced to the same specifications, and products exclusively for national security, defence or classified information (Art. 2). Excluded from the CRA does not mean free of cybersecurity requirements. The list with references to the specific legislation is in the guide section on roles.