GUIDE TO THE CRA

What the CRA is and what it sets out to achieve

The Cyber Resilience Act (commonly "CRA", in Czech akt o kybernetické odolnosti), Regulation (EU) 2024/2847, is horizontal legislation about products, not about sectors. It covers hardware and software made available on the Union market whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)). Such a product may be made available on the market only where it meets the essential cybersecurity requirements of Annex I and where the processes put in place by the manufacturer meet the vulnerability handling requirements (Article 6).

From a security perspective, the regulation targets two things that are the most common cause of avoidable incidents in practice. The first is a product shipped with settings that are convenient for deployment and bad for operations. The second is a vulnerability that has been fixed but where the fix never reaches the user — the manufacturer has no channel to push it through, no overview of what is actually inside the product, and no address where someone outside could report a vulnerability in the first place.

The CRA turns those into enforceable obligations: secure default configuration, a software bill of materials, a coordinated vulnerability disclosure policy, secure distribution of updates.

The regulation is directly applicable and is not transposed into Czech law. The member state adds only enforcement and penalties — in the Czech Republic that is the subject of a draft implementing act discussed in the last section. And do not confuse the CRA with the Czech Cybersecurity Act: Act No. 264/2025 Coll. regulates service providers, the CRA regulates product manufacturers. One company can fall under both, and the obligations do not merge — a regulated entity under the Czech act that also develops a product deals with each set separately.

We do not reproduce the text of the regulation on this page. Every statement carries a reference to the article or annex where you can read the binding wording yourself — the list of links is at the end of the page.

Entry into force is not the same as application

This is the most common source of confusion. The CRA entered into force on 10 December 2024 — on the twentieth day after its publication in the Official Journal on 20 November 2024 (Article 71(1)). Entry into force means the act legally exists and that everything which has to happen before it applies is now under way: Commission implementing and delegated acts, the standardisation request, the designation of authorities. It does not mean products have been assessed against it since December 2024.

Application is staggered and governed by Article 71(2). The regulation applies from 11 December 2027, with two blocks earlier — Chapter IV (Articles 35 to 51, notification of conformity assessment bodies) from 11 June 2026 and Article 14 (reporting obligations of manufacturers) from 11 September 2026.

The second trap is the transitional provisions in Article 69. Products placed on the market before 11 December 2027 are subject to the regulation only if they undergo a substantial modification after that date (Article 69(2)) — and a substantial modification is defined in Article 3(30) as a change that affects compliance with the essential requirements or that modifies the intended purpose. There is one explicit carve-out from that rule: the reporting obligation under Article 14 also applies to products placed on the market before 11 December 2027 (Article 69(3)).

• 11 Jun 2026 — Chapter IV applies, member states may designate notifying authorities and notify conformity assessment bodies. The indirect message for manufacturers: notified body capacity is only now being built up.
• 11 Sep 2026 — Article 14 applies. Actively exploited vulnerabilities and severe incidents having an impact on the security of the product must be reported, including for products already on the market today.
• 11 Dec 2027 — the regulation applies in full. From that day products go on the market with a conformity assessment, an EU declaration of conformity, the CE marking and technical documentation under Annex VII.

The practical consequence for planning: documentation and conformity assessment are a 2027 horizon, but the reporting process has to work this September. Those are two different pieces of work with different owners inside the company.

Reporting from 11 September 2026 — the nearest deadline

Article 14 applies from 11 September 2026 and brings two separate reporting obligations for the manufacturer. The first covers every actively exploited vulnerability contained in the product that the manufacturer becomes aware of (Article 14(1)). Actively exploited means there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner (Article 3(42)) — so not every CVE you find, but the vulnerability you know is actually being used.

The second obligation covers every severe incident having an impact on the security of the product (Article 14(3)). Under Article 14(5) an incident is severe where it negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in the network and information systems of its user.

Reports go simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform that ENISA sets up under Article 16. Which CSIRT is yours follows from your main establishment in the Union — the member state where decisions about the cybersecurity of your products are predominantly taken (Article 14(7)). Manufacturers with no establishment in the Union follow the cascade in the same paragraph (authorised representative, importer, distributor, number of users).

In the Czech Republic, reports under Articles 14 and 15 are to be received by NÚKIB, the national cyber security agency — that is what the draft implementing act says, but as of 8 August 2026 it has not been adopted. ENISA is building the platform incrementally and, according to its own information, it is to be used for mandatory reporting from 11 September 2026; registration of manufacturer representatives is handled in advance. None of that changes the deadlines — the 24 hours run from the moment you become aware of the matter, not from the moment you have an account on the platform.

• What the incident has to concern — not an incident in your corporate infrastructure, but one touching the security of the product; typically a compromise of the environment from which signed artefacts or updates are distributed to customers.
• Early warning within 24 hours of the manufacturer becoming aware of the vulnerability or incident, without undue delay. For an incident it also states whether there is a suspicion of unlawful or malicious acts (Article 14(2) and (4), point (a)).
• Notification within 72 hours with general information about the product, the nature of the exploitation or the incident, the measures taken and the measures users can take. This is also where the sensitivity of the information is flagged (Article 14(2) and (4), point (b)).
• Final report — for a vulnerability no later than 14 days after a corrective or mitigating measure becomes available; for an incident within one month of the notification under point (b) (Article 14(2) and (4), point (c)).
• Informing users — the manufacturer informs the affected, or where relevant all, users about the vulnerability or incident and about the measures available, where possible in a structured, machine-readable format (Article 14(8)).
• Microenterprises and small enterprises do have to report. They are not fined for a missed 24-hour early warning (Article 64(10)(a)), but that exemption does not extend to the 72-hour deadline or to the final report.

Reporting under Article 14 is best treated as the product-side counterpart of incident response: it has to be clear who decides that a vulnerability is actively exploited, who holds the 24-hour deadline outside office hours, who writes the text of the report and who talks to customers. We build that process and rehearse it in exercises, because the first run should not be the real one.

Who the regulation turns into a manufacturer

A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately (Article 3(1)). It comes into scope because its intended or reasonably foreseeable use includes a data connection (Article 2(1)). A library, firmware, a mobile app, an industrial gateway, a network appliance — all of them are products with digital elements.

A manufacturer is anyone who develops or manufactures a product, but equally anyone who has it designed, developed or manufactured for them and markets it under their own name or trade mark — whether for payment, for monetisation in another form, or free of charge (Article 3(13)). White labelling therefore makes you a manufacturer. And an importer or distributor becomes a manufacturer, with all the obligations that follow, the moment they place a product on the market under their own name or trade mark, or substantially modify a product already placed on the market (Article 21).

• We build custom software for a single customer. Making available on the market means any supply for distribution or use in the course of a commercial activity (Article 3(22)) — being bespoke does not remove the obligations. The regulation accounts for it in exactly two places: the secure default configuration may be agreed otherwise with a business user (Annex I, Part I, point 2(b)), and security updates for a product made to order need not be free of charge (Annex I, Part II, point 8).
• We run SaaS, not a product. Pure cloud models (SaaS, PaaS, IaaS) fall under the NIS2 Directive, not under the CRA (recital 12). What the CRA does cover is a remote data processing solution designed and developed by the manufacturer of the product and without which the product would not perform one of its functions (Article 3(2)). A mobile app relying on your API or database is therefore in scope, including that server-side part.
• We do open source. What decides is monetisation, not the development model. Free and open-source software supplied outside a commercial activity is out of scope, and contributing source code alone does not make you a manufacturer (recital 18). For legal persons that provide systematic, sustained support for the development of such software intended for commercial activities there is a lighter regime — the "open-source software steward" (Article 3(14) and Article 24, further explained in recital 19) — a cybersecurity policy, cooperation with the authorities and limited reporting obligations, but no CE marking.
• We buy hardware and add firmware, or we integrate systems. If you offer the result under your own name, you are a manufacturer (Article 3(13)). If you merely supply someone else's product without touching its properties, you are a distributor with the obligations of Article 20. The dividing line is "substantial modification" under Article 3(30), and it is worth settling before an inspection settles it for you.
• We are not based in the EU. The obligations attach to making the product available on the Union market. The practical roles are the authorised representative (Article 18) and the importer, who may not place a product on the market without a conformity assessment and documentation (Article 19).

Conversely, products covered by other regimes are excluded from scope: medical devices under Regulations 2017/745 and 2017/746, vehicles under Regulation 2019/2144, products certified under Regulation 2018/1139 (aviation), marine equipment under Directive 2014/90/EU, spare parts manufactured to the same specifications, and products exclusively for national security, defence or classified information (Article 2(2) to (7)). Excluded from the CRA does not mean free of cybersecurity requirements — those sit in the relevant sectoral legislation.

Security by design: what Annex I, Part I requires

The core of the regulation is not the CE marking but the cybersecurity risk assessment. The manufacturer has to carry it out and take its outcome into account during the planning, design, development, production, delivery and maintenance of the product (Article 13(2)). The assessment is documented and updated throughout the support period, and it has to show whether and how the individual requirements of Annex I, Part I, point 2 apply to the product and how they have been implemented (Article 13(3)). Where a requirement does not apply, the technical documentation has to carry a clear justification (Article 13(4)).

The requirements themselves are written as properties of the product, not as specific technologies. Point 2 of Part I contains thirteen of them, (a) to (m). Below they are summarised in our own words, with the letter in brackets so you can find them in the official text — that text is in Annex I, Part I, and only it is binding.

• Made available with no known exploitable vulnerabilities (point (a)).
• A secure by default configuration, including the possibility to reset the product to its original state (point (b)).
• Vulnerabilities must be fixable through security updates — where applicable automatic, enabled by default, with a clear opt-out mechanism and the option to postpone installation (point (c)).
• Protection from unauthorised access by appropriate control mechanisms, including authentication and identity management, and reporting on possible unauthorised access (point (d)).
• Confidentiality of stored, transmitted or otherwise processed data, among other means through encryption using state-of-the-art mechanisms (point (e)).
• Integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against unauthorised manipulation or modification, and reporting on corruption (point (f)).
• Data minimisation — the product processes only data that is necessary in relation to its intended purpose (point (g)).
• Availability of essential functions after an incident, with resilience against denial of service attacks (point (h)).
• Minimising its own negative impact — neither the product nor the devices connected to it should disrupt the availability of services provided by other devices or networks (point (i)).
• Limiting attack surfaces, including external interfaces (point (j)).
• Reducing the impact of an incident through appropriate exploitation mitigation techniques and mechanisms (point (k)).
• Security logging of relevant internal activity including access to and modification of data, with an opt-out for the user (point (l)).
• The ability to securely and permanently delete data and settings, and to transfer them elsewhere securely (point (m)).

Point 1 of Part I is the general one — a level of security appropriate to the risks. That is exactly where the authorities will ask about architecture and where a list of tools is not an answer. The fastest way to see where you stand is a threat model built on the real product plus testing under Annex I, Part II, point 3; in our work that is part of the secure development review.

SBOM and vulnerability management: Annex I, Part II

Part II of Annex I does not impose properties of the product but processes of the manufacturer. The basis is the software bill of materials (SBOM) — a formal record of the components in the software elements of a product and their supply chain relationships (Article 3(39)). Under Annex I, Part II, point 1 it has to be in a commonly used machine-readable format and cover at the very least the top-level dependencies of the product.

Publishing the SBOM is not mandatory. It is provided to the market surveillance authority upon a reasoned request where it is necessary to verify compliance (Annex VII, point 8), and it is made available to users only if the manufacturer chooses to do so (Annex II, point 9). The Commission may specify the format and elements of the bill of materials in an implementing act (Article 13(24)).

• Address and remediate vulnerabilities without delay, among other means by providing security updates; where technically feasible, separately from functionality updates (point 2).
• Test and review the security of the product regularly (point 3).
• Once a fix is released, publish information about the vulnerability, its impact and severity and about how the user remedies it; publication may in justified cases be delayed until users have had the chance to apply the fix (point 4).
• Put in place and enforce a coordinated vulnerability disclosure policy (point 5) and provide a contact address for reporting vulnerabilities (point 6).
• Have mechanisms for the secure distribution of updates, automatic where possible (point 7).
• Disseminate security updates without delay and free of charge, together with an advisory message for users (point 8); the exemption from "free of charge" applies only to products made to order, by agreement with the business user.

Third-party components have their own regime: they are integrated with due diligence, including open-source components that were never placed on the market (Article 13(5)). When you find a vulnerability in a component, you report it to the person manufacturing or maintaining it, and where you have developed a fix, you provide them with the code or the documentation (Article 13(6)). In practice this turns the relationship with upstream from "we take and never give back" into a process that someone has to own.

Support period and expected time in use

The support period is the period during which the manufacturer has to ensure that vulnerabilities in the product are handled in line with Annex I, Part II (Article 3(20)). The manufacturer sets it, but not arbitrarily: it has to reflect the length of time the product is expected to be in use, taking account of reasonable user expectations, the nature of the product including its intended purpose, and Union law determining the lifetime of products (Article 13(8)). Support periods of comparable products on the market and the support periods of integrated third-party components may be taken into account as well.

The floor is five years. A shorter support period is possible only where the product is expected to be in use for less than five years — in which case it matches the expected time in use (Article 13(8), third subparagraph). Alongside that runs a separate obligation: security updates that have been issued must remain available for at least ten years after their release, or for the remainder of the support period if that is longer (Article 13(9)).

The support period is also an information obligation. The month and year in which it ends have to be stated clearly and in an easily accessible manner already at the time of purchase — on the product, on its packaging, or by digital means (Article 13(19)). Where technically feasible, the manufacturer notifies users when support ends. The technical documentation has to contain the inputs you used to set the support period (Annex VII, point 4), and the information for users has to state the type of support offered and the date support ends (Annex II, point 7).

The practical effect: the support period is a commercial decision taken before the product goes on the market, because afterwards it is printed on the packaging and in the documentation. For industrial equipment that a customer will run for twelve years, five years will not stand up against reasonable user expectations. For products with embedded components, the limiting factor is the support period of those components, not your preference.

Product categories, conformity assessment and the state of standards

The regulation works with three levels. A default product — the manufacturer runs the conformity assessment itself through internal control (module A, Article 32(1)). An important product from Annex III, split into class I and class II. A critical product from Annex IV. What decides is the core functionality of the product as a whole (Article 7(1)) — embedding a browser in a news application does not turn that application into an important product.

The category determines the conformity assessment procedure under Article 32. For class I, internal control is enough only where you have applied harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level "substantial" in full; otherwise EU-type examination (module B + C) or full quality assurance (module H) is required, meaning a notified body. For class II, a third party is mandatory in every case.

For critical products, the Commission may require a European cybersecurity certificate at assurance level at least "substantial" through a delegated act (Article 8(1)); until such an act exists, the class II regime applies (Article 32(4)). The categories in Annexes III and IV are described by name only — the technical description was added by Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025, published on 1 December 2025. For classifying a specific product, that is today the main document.

And now the part that matters for 2026: the presumption of conformity only arises once the reference to a harmonised standard is published in the Official Journal (Article 27(1)). As of 8 August 2026, according to the Commission page on CRA standardisation, no harmonised standard has been cited; work is running under standardisation request M/606, which covers 41 standards. Anyone preparing documentation today therefore cannot rely on the presumption and has to describe in the technical documentation which solutions they chose and why those meet Annex I (Annex VII, point 5). For class I there is a second consequence: standards cannot be "applied in full", so the route leads through a notified body.

• Technical documentation under Article 31 and Annex VII: description of the product and its intended purpose, versions affecting conformity, information and instructions to the user under Annex II.
• A description of the design, development and production and of the vulnerability handling processes — including the SBOM, the coordinated vulnerability disclosure policy, evidence of the contact address and a description of the secure distribution of updates.
• The cybersecurity risk assessment under Article 13 and the inputs you used when setting the support period.
• A list of the standards applied and common specifications, or a description of the solutions you chose where no standards were applied.
• Test reports and a copy of the EU declaration of conformity (model in Annex V, simplified version in Annex VI).
• The CE marking under Article 30: for software it is affixed to the EU declaration of conformity or to the website accompanying the product, where it has to be easily and directly accessible.

Microenterprises and small enterprises may provide the elements of the technical documentation in a simplified format; the form is to be set by the Commission in an implementing act (Article 33(5)). Documentation also cannot be written retrospectively — the risk assessment under Article 13(3) is meant to come out of the development process. That is why we build it together with the threat model, not as a standalone document at the end.

Fines and who will enforce the CRA in the Czech Republic

The tiers are set by Article 64 and depend on what has been breached. Failure to comply with the essential requirements of Annex I and the obligations under Articles 13 and 14 carries an administrative fine of up to EUR 15 000 000 or up to 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 64(2)).

Breaches of the other obligations (importers and distributors, the EU declaration of conformity, the CE marking, technical documentation, conformity assessment procedures, obligations of notified bodies) are capped at EUR 10 000 000 or 2 % (paragraph 3). Incorrect, incomplete or misleading information supplied to notified bodies and market surveillance authorities is capped at EUR 5 000 000 or 1 % (paragraph 4).

Two exemptions are worth remembering (Article 64(10)): microenterprises and small enterprises are not fined for a missed 24-hour early warning under point (a) — but they are for a missed 72-hour deadline or final report — and open-source software stewards are not subject to administrative fines under this regulation at all. When the amount is set, the nature, gravity and duration of the infringement, previous fines and the size of the economic operator are taken into account (Article 64(5)).

The regulation does not assign the market surveillance authority — that is a matter for the member state (Article 52). In the Czech Republic this is to be settled by the implementing act; the draft was sent by the Ministry of Industry and Trade into the interministerial comment procedure on 3 July 2026 (comments due 23 July 2026). What the draft contains:

• NÚKIB, the national cyber security agency, is the notifying authority under Chapter IV of the regulation and at the same time receives the reports under Articles 14 and 15.
• Market surveillance is to be split among the existing market surveillance authorities according to their sectoral remit; the bulk of the agenda — software and consumer electronics — is to go to the Czech Trade Inspection Authority.
• The information and instructions to the user and the EU declaration of conformity are to be in the Czech language.

As of 8 August 2026 this is a draft, not law in force — the exact split of surveillance may still change. It changes nothing about your obligations: the regulation is directly applicable and the deadlines in Article 14 apply from 11 September 2026 regardless of which Czech authority ends up checking them.

CRA timeline

Dates per Articles 71 and 69 of Regulation (EU) 2024/2847 and the follow-up Commission acts. Each row states what actually changes on that day.

Official sources

This guide is informative and does not replace the text of the legislation. All the information above comes from these sources, as of 8 August 2026.