Cyber Resilience Act (CRA): obligations, deadlines and product readiness

Legal position and editorial perspective: 29 April 2026. This article describes obligations that will apply in stages. It distinguishes enacted legislation, implementation work in progress and our own organisational recommendations. It explains the framework; classifying a particular product requires examining its functions, how it is supplied and the relevant documentation.

The Cyber Resilience Act makes cybersecurity a condition for placing devices and software on the EU market. It connects product design, vulnerability handling, support and evidence of conformity. A penetration test, scanner or contract clause alone is insufficient.

The nearest significant deadline for manufacturers is 11 September 2026, when reporting obligations for actively exploited vulnerabilities and severe incidents will start to apply. Most product requirements will apply from 11 December 2027. Preparation should therefore follow two tracks: response readiness in 2026 and product conformity in 2027. Introducing useful practices earlier can support both, but it does not change the statutory dates.

What the CRA is and the problem it addresses

The CRA is Regulation (EU) 2024/2847 of the European Parliament and of the Council. As a regulation, it establishes directly applicable EU rules. Member States still organise supervision and enforcement, so a common legal text does not eliminate the national institutional context.

Buyers can easily compare camera resolution or router ports. Assessing dependency security and the manufacturer’s ability to fix a defect years later is harder. The cost of insecure design often falls on users and other systems attacked through the compromised product.

The CRA seeks to place more responsibility on the operator bringing the product to market. Requirements cover design, development, production and vulnerability handling. Responsibility will not end at the point of sale. Instructions, available updates and information about the support period also matter. Article 13 and Annexes I and II provide the central framework.

Conformity does not guarantee freedom from attacks: security also depends on configuration, environment and new threats. The regulation requires appropriate protection and response capability. Formal conformity and actual resilience should reinforce each other, but are not interchangeable.

Which products fall within scope

The starting point is a product with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Article 2 establishes the scope and Article 3 supplies the definitions. The scope should not be reduced to devices permanently connected to the public internet.

A product can be hardware, software or a combination of both. Examples include networking equipment, controllers, locally installed applications and components supplied separately. Firmware, the software embedded in a device, belongs within the assessment of that device’s security. A connection through a local network, a maintenance interface or another product can be just as relevant as a direct cloud connection.

A second consideration is making a product available on the market in the course of a commercial activity. Whether a particular download is paid for is not conclusive by itself. A business model can involve services, data or paid features. Conversely, simply writing a program for internal use does not automatically mean placing a product on the market. The actual supply arrangements and participants’ roles need to be described.

There are exclusions associated with separate legal frameworks, including certain medical devices, vehicles and aviation products. Specific provisions concern products developed exclusively for national security or defence and products designed to process classified information. The catalogue must be checked against Article 2 and the relevant supplementary acts. It should not be turned into a blanket assertion that an entire medical or automotive industry is exempt.

The assessment should produce a product record covering functions, recipients, the commercial model and reasons for any exclusion. The diagram structures questions rather than replacing legal classification. Resolve ambiguities before making expensive design decisions.

Who is responsible for conformity

The manufacturer is not necessarily the factory or the person who wrote the code. Commissioning the design or manufacture of a product and marketing it under one’s own name or trademark can also establish that role. A business ordering a finished device and selling it under its own brand should examine carefully whether it assumes the manufacturer’s responsibilities.

An importer places a product from a third country on the Union market. A distributor participates in its subsequent supply. Their obligations include appropriate checks, responses to non-conformity and cooperation with authorities. Articles 19-22 also address circumstances in which an importer, distributor or another person becomes a manufacturer, including certain changes of branding or substantial modifications.

A contract can allocate tasks among partners, but it does not remove a statutory role. Commissioning laboratory testing does not transfer all responsibility to the laboratory. Equally, a library supplier does not automatically take responsibility for the way a manufacturer combines that library with the rest of a system.

Microenterprises and small businesses do not receive a general exemption from the CRA. Support measures and proportionality are provided for, but the basic questions remain the product and the business’s role. In a small team, one person may perform several functions. What matters is that responsibility, a substitute and access to the necessary tools actually exist.

SaaS, cloud services and open source

A standalone software-as-a-service offering, or SaaS, is not automatically covered by the CRA merely because it uses the internet. Remote data processing solutions forming part of a product require a separate assessment. The definition captures relevant remotely performed processing designed such that the product could not perform one of its functions without it.

A camera and a cloud service, for example, are not always two independent purchases. If the manufacturer designs remote analysis, or has it designed under its responsibility, as part of a camera function, that processing may fall within the product boundary. This does not mean that the entire infrastructure of any cloud provider automatically becomes that manufacturer’s product. Function and responsibility must both be analysed.

The Commission published draft guidance on 3 March 2026. It addresses remote processing, open-source software and support periods, among other issues. From this article’s April perspective, it is supporting material at draft stage, not a final binding interpretation replacing the regulation.

Free and open-source software made available outside a commercial activity benefits from an exclusion. That is not an exemption for every program with a public repository. Licensing, funding arrangements, the entity’s role and the activity surrounding the product need to be considered together. Publishing the source code alone does not settle either inclusion or exclusion.

The CRA also establishes a distinct role for open-source software stewards. Article 24 sets tailored obligations for these entities, including a cybersecurity policy and cooperation with authorities. A steward should not be equated with every volunteer contributing a patch. Similarly, a manufacturer using an open library in a commercial product cannot assume that an exclusion available to the library’s author extends to the whole product it sells.

Timeline: three distinct preparation stages

The CRA entered into force on 10 December 2024. This does not mean that all its obligations have applied since that date. Article 71 separates the application dates of different provisions. From April 2026, three significant milestones still lie ahead.

The September reporting requirements do not bring all of Annex I into application in September. Nevertheless, reliable reporting is difficult if a company cannot identify the product versions it has sold or the person responsible for analysing incoming reports. Starting inventory and response processes early is therefore an operational recommendation, not a change to the legal deadline.

Standardisation also takes time. Commission request M/606, adopted in 2025, initiates development of standards supporting the CRA. A draft standard, a published standard and a harmonised standard whose reference appears in the Official Journal are different stages. A claim that work follows a standard must not obscure the need to check the requirements and presumptions of conformity that it actually covers.

Changes to product design and maintenance

Article 13 and Annex I connect requirements with a cybersecurity risk assessment. The manufacturer needs to understand the intended purpose, reasonably foreseeable use and potential threats. In practical terms, this means describing trust boundaries, interfaces, privileges, data and the consequences of losing availability or integrity. Purchasing a tool cannot replace those decisions.

Requirements address secure default configuration, protection against unauthorised access, data confidentiality and integrity, reduced attack surfaces and the ability to remove data securely, among other matters. Their application reflects the product’s risks and properties. Every product does not need an identical package of controls, but decisions to omit a relevant control need a defensible explanation.

Placing a product on the market without known exploitable vulnerabilities is not a promise of complete freedom from software defects. It requires understanding actual exposure. A scanner’s alert list is neither a finished risk assessment nor automatic proof of non-conformity. The team needs to check versions, reachability of vulnerable code, exploitation conditions and consequences, retaining the reasoning behind its decision.

A software bill of materials, or SBOM, helps identify what is inside a product. Annex I Part II requires identification and documentation of components and vulnerabilities, including a machine-readable inventory covering at least top-level dependencies. This is not an automatic requirement to disclose all source code publicly or publish a complete SBOM for every recipient.

An SBOM file alone rapidly becomes stale. A useful process connects it with a particular release, configuration and component inventory. When a vulnerability is disclosed, the company must identify affected products, assess risk, produce a fix and check delivery. SPDX and CycloneDX can support data exchange, but choosing a format does not itself establish conformity with the CRA.

Vulnerability handling includes regular security testing and review, coordinated disclosure and a contact point. A product security incident response team is often called a PSIRT. A small company may not need a separate department, but it does need a decision-maker, a way to receive reports and cover when the responsible person is away.

The update mechanism should be designed together with the product. For a device, consider package authenticity, power loss during installation, recovery and signing-key protection. Signed updates and controlled rollback are examples of technical measures, not a universal requirement to adopt one architecture. In industrial installations, arranging a maintenance window may be as important as downloading the fix.

Technical documentation under Annex VII should reflect the real product and the work performed. Connecting each requirement, risk, control and piece of evidence in one register is useful. Such a register supports supplier changes, incident investigations and subsequent releases. Documentation assembled only a day before an assessment often reveals missing information that cannot be reconstructed quickly.

Support periods and the end of product life

The support period should reflect the expected period of use and the criteria in Article 13(8). In general it must be at least five years; where expected use is shorter, the period corresponds to that expected use. Five years is not an automatic maximum or a universally defensible choice for industrial equipment.

The manufacturer should clearly state the end of support and justify the period chosen. Its financial model needs to account for testing fixes, maintaining build environments, retaining expertise and working with suppliers. Sales late in a model’s life require particular attention: the customer purchases a specific product, not the manufacturer’s historical maintenance plan.

Developing new fixes must be distinguished from keeping previously issued updates available. Article 13(9) requires issued security updates to remain available for at least ten years after issue or for the remainder of the support period, whichever is longer. An update archive and its distribution infrastructure are therefore a separate operational commitment.

Security updates should be disseminated without delay and generally free of charge. Annex I permits a particular exception where otherwise agreed for a tailor-made product supplied to a business user. That exception should not be extended to every business-to-business product. Where technically feasible, security updates should also be separated from functional changes.

Ending support does not create a universal instruction to switch off every device automatically. Users should nevertheless understand the risk of continued use. The company should plan communication, migration, secure data removal and dependence on remote services. Releasing source code at end of support may be considered, but the CRA does not impose it as a universal obligation.

Product categories, conformity assessment and CE marking

Not all products follow the same assessment route. The CRA identifies important products in Annex III, divided into classes I and II, and critical products in Annex IV. Other products still have to meet requirements if they fall within scope. Classification concerns product functionality, rather than the importance of a customer or the manufacturer’s turnover.

Implementing Regulation (EU) 2025/2392 specifies technical descriptions of the categories. Classification requires comparing those descriptions with the CRA annexes and the product’s actual core functionality. The presence of an important component does not invariably transfer its category to the entire device.

Article 32 provides different procedures. For products outside the special categories, internal control is one available route. For class I, access to that route depends on meeting the specified conditions, including appropriate use of standards or other instruments provided for in the regulation. Class II normally requires third-party involvement. Article 32(5) provides a special route for free and open-source software products in Annex III: where technical documentation is publicly available at market placement, the procedures in paragraph 1, including internal control, may be used. Critical products and European cybersecurity certification schemes have additional specific rules.

For example, Annex III places password managers and standalone browsers in class I, and firewalls and intrusion detection or prevention systems in class II. Annex IV includes smartcards and similar devices, including secure elements. A commercial name is insufficient: the full category description must be checked.

In practice, the route needs to be checked against the standards, implementing measures and assessment body’s scope relevant at the time. A company should not promise a ready-made “CRA certification” without identifying the procedure and category. Claiming that every manufacturer will have to purchase an external certificate would be equally misleading.

CE marking indicates conformity with applicable EU harmonisation legislation. It is supported by an EU declaration of conformity and documentation. CE is not a security ranking, a guarantee of no vulnerabilities or a separate quality award invariably issued by an authority. A product subject to several acts needs coordinated requirements and evidence, rather than a separate conceptual sticker for each regulation.

Reporting vulnerabilities and incidents

From 11 September 2026, Article 14 will require reporting of actively exploited vulnerabilities and severe incidents affecting product security. These are different events. A scan indicating a possible vulnerability is not, by itself, evidence that the vulnerability is being actively exploited.

Notifications will be addressed simultaneously to the appropriate CSIRT designated as coordinator and ENISA through the single reporting platform provided for in Article 16. A CSIRT is a computer security incident response team; ENISA is the EU Agency for Cybersecurity. From our April perspective, this describes the legal destination, not an assumption that a production reporting interface is already operating.

The 72-hour period does not mean another 72 hours after the early warning. Both initial deadlines start from awareness. Fourteen days is not a universal remediation deadline, and one month should not automatically be converted into thirty days. Article 14 avoids requiring information already supplied to be repeated; the coordinator can also request further status information.

A severe incident is not limited to theft of personal data. The statutory conditions include actual or potential adverse effects on the product’s ability to protect important data or functions, and the introduction or execution of malicious code. A CVSS score, a technical measure of vulnerability severity, does not replace this legal assessment.

Manufacturers also have obligations towards affected users: information about the vulnerability or incident and available measures. Informing an authority does not replace a communication that helps a customer protect a device. At the same time, exploitation details should not be released without control. Communication needs coordination with remediation and the relevant response teams.

Consider an exercise in which information arrives on a Friday evening, the responsible person is on holiday and the affected versions came from a subcontractor. Who assesses the reporting trigger, finds the versions and prepares the notification? The deadlines do not become working days. This is an organisational problem that creating a security@ address alone will not solve.

Existing products and substantial modifications

Article 69 provides that products placed on the market before 11 December 2027 will generally become subject to CRA requirements if substantially modified after that date. Article 14 is treated separately: reporting obligations will also cover earlier products that fall within the regulation’s scope.

This should not be interpreted as exempting every future unit of a model designed in 2025. Product law distinguishes the launch of a model from placing an individual product on the market. A new batch supplied after the requirements start to apply may need full conformity even though the design is several years old.

Substantial modification is a legal concept linked, among other things, to changes affecting conformity with requirements or changing the intended purpose. Not every bug fix automatically becomes such an event. Adding remote control to a previously local device, however, deserves a different assessment from correcting a minor interface description.

Maintaining a release register and records of modification decisions is useful. These should identify functions, interfaces, effects on risk and the responsible operator. The record makes it possible to reconstruct why an update was treated as maintenance or why a new conformity assessment was initiated. Calling a major change a patch does not determine its legal status.

How the CRA relates to other legislation

The CRA does not replace the entire body of cybersecurity law. The same entity may have obligations concerning its product, organisational operations, personal data and a particular sector. A shared event register helps, but classification and deadlines can remain different.

Conformity with ISO/IEC 27001 or an established NIS2 programme can provide useful building blocks, but does not automatically demonstrate CRA conformity of a particular product. Similarly, CE marking based on earlier requirements does not settle future satisfaction of CRA obligations.

Sharing work makes sense: inventories, access control, supplier management and incident handling can support several processes. Each obligation should nevertheless be mapped to its own legal basis. One event can trigger more than one reporting requirement. The assumption that one submitted form has resolved every duty needs verification rather than intuition.

Five practical examples

The following cases are hypothetical. They illustrate an assessment approach, not a final classification of every similarly named product. Functions, supply arrangements and the parties’ responsibilities are decisive in each case.

1. An IoT sensor with an app and cloud service. A company sells a flood sensor, an application and a notification service. It should describe the product boundary, assess the role of remote processing and account for updates to both device and app. If its cloud-provider contract ends, it needs to know what happens to user functions. The important preparation outcome is a coherent support plan covering dependencies, rather than three disconnected team statements.

2. Industrial equipment with a maintenance interface. A controller operates on an isolated network without continuous internet access. That alone does not exclude the CRA. Assessment includes foreseeable connections, service access and potential process impacts. Updates require an agreed shutdown, so the manufacturer should consider mitigating measures pending installation. A hypothetical ten-year period of use needs a reasoned maintenance model; choosing five years of support simply because that period appears in the legislation would be inadequate reasoning.

3. An application installed at a customer’s premises. A supplier sells production-management software that communicates with a server and imports files. Not supplying a physical device does not exclude software from analysis. The company needs release identification, dependency documentation and a channel for delivering fixes. Contracts should explain installation responsibilities and supported configurations, but cannot replace manufacturer duties. A key question is whether a security fix can be installed without forcing purchase of an unrelated feature.

4. A standalone room-booking SaaS. Customers use a browser and receive no separate device from the supplier. The business should determine whether the service stands alone or is a remote element of another product. Even where the service itself falls outside the CRA, contractual duties, GDPR and potentially sectoral rules remain. If the company later adds a terminal for sale or an installed agent, scope should be assessed again. Exclusion of one offering does not become a permanent company-wide exemption.

5. An open-source library inside a commercial device. Volunteers develop a library and a manufacturer uses it in a router. The status of the project and the status of the router must be assessed separately. The manufacturer needs version information and a response plan if maintenance ends. It can fund a fix, maintain a branch or replace the component. Transferring all risk to an author without an agreement or resources does not create maintenance capability. A tested dependency-update procedure is useful evidence.

Benefits, costs and difficulties

For users, the value is greater predictability: available support, safer settings and the ability to obtain fixes. For business purchasers, common requirements may make suppliers easier to compare. These are expected benefits, not a guarantee that every purchase becomes simple or that attacks disappear.

A manufacturer with mature security practices may turn existing capabilities into an advantage. Better documentation and dependency knowledge also help outside formal assessment: they shorten diagnosis, reduce reliance on one individual and support customer discussions. Common market rules may reduce some divergent procurement demands.

The costs are real, however. They include engineering work, testing, maintaining releases, documentation, responding to reports and potentially external assessment. Fixed process costs can account for a larger share of revenue in a small company. There is no defensible universal price for implementing the CRA without knowing the product and the organisation’s maturity.

Difficult decisions may involve retiring an older line, reducing supported configurations or changing prices. Those outcomes should be considered business risks, not inevitable effects of every implementation. Appropriate automation can reduce repeated work, but it does not replace responsibility for decisions or compensate for inaccessible supplier code.

Another difficult balance concerns rapid reporting and protection of sensitive information about vulnerabilities that have not yet been fixed. Faster coordination is a potential benefit; secure information handling and work under time pressure remain challenges. Reasoned criticism of process design should be distinguished from an assumption that reporting itself solves the underlying technical problem.

Open source may benefit from greater interest in funding maintenance. It also faces the risk of disproportionate expectations being passed down to communities. Sensible preparation should strengthen supplier and maintainer relationships rather than consist only of questionnaires demanding blanket declarations of conformity.

Supervision and consequences of non-compliance

Market surveillance authorities will be able to request information, assess conformity and require corrective action. Depending on the situation, measures can include restrictions on availability, withdrawal or recall. From a business perspective, interrupted sales and remediation costs can matter as much as a financial penalty.

Article 64 sets different maximum penalty levels: up to EUR 15 million or 2.5% of worldwide annual turnover for specified major infringements; up to EUR 10 million or 2% for other listed obligations; and up to EUR 5 million or 1% for certain incorrect information. For an undertaking, the higher corresponding amount applies. These are ceilings, not an automatic tariff for every mistake.

Circumstances, severity, duration and the operator’s size matter when determining a penalty. The provision also contains specific exclusions concerning open-source software stewards and failure by micro or small manufacturers to meet the early-warning deadline. These must not be interpreted as a general exemption from duties, all reporting deadlines or every consequence. Detailed sanctions advice needs the full Article 64 and the applicable national provisions.

Preparation plan: the first 30, 60 and 90 days

The following is an organisational recommendation for starting in late April 2026. It is not a statutory timetable or a guarantee of conformity. Its purpose is to produce verifiable results before September reporting begins and establish the product programme for 2027.

First 30 days: establish scope and responsibility. The product owner and engineering team list products, versions and sales models. The person responsible for legal matters helps identify roles and exclusions. Management appoints a process owner and substitute and allocates a budget. Outcomes should include scope records, preliminary classification and an inventory of missing information, rather than only a training presentation.

By day 60: connect the product to response operations. Engineering links releases to dependencies and update mechanisms. Procurement or the supplier owner establishes support periods and security contacts. The team creates a process for receiving reports, assessing triggers and preparing information for authorities and users. It identifies products that cannot currently be updated without hardware changes.

By day 90: exercise the process and approve the change programme. The team runs a vulnerability or incident exercise, records the point of awareness and prepares mock notifications. It does not send fictional incidents to a production reporting channel. Management approves priorities, resources and the schedule for bringing products into line with the 2027 requirements. The team checks potentially relevant standards and assessment routes.

Common misunderstandings should be tested in review: the company is too small, its product has no internet connection, it uses open source, it has ISO certification or it can wait until 2027. None of these statements settles the duties by itself. Equating every scanner alert with a notification to ENISA is equally mistaken, as is treating fourteen days as the deadline to fix all vulnerabilities.

Conclusion

In late April 2026, the most useful sequence is to establish scope, prepare reporting and start a product conformity programme. Teams should also follow the development of standards and guidance while preserving the distinction between a draft and an applicable rule. Preparation succeeds when the company can develop and maintain the product securely, and its documentation accurately describes that capability.

Sources

• Regulation (EU) 2024/2847. In particular Articles 2-3, 13-16, 19-24, 27-32, 64, 69 and 71, and Annexes I-IV and VII. Official Polish PDF.
• Implementing Regulation (EU) 2025/2392, technical descriptions of important and critical product categories, 28 November 2025.
• Delegated Regulation (EU) 2025/1535, exclusion of certain products covered by Regulation 168/2013; not a whole-industry exemption.
• European Commission: draft CRA guidance, 3 March 2026. Evidence of work in progress, not final guidance.
• European Commission: CRA legislative summary, updated 3 December 2025. A navigation aid; the legal text remains authoritative.
• Rolling Plan for ICT Standardisation 2026: cybersecurity, context for standardisation request M/606.
• NIS2 Directive, 2022/2555, GDPR, 2016/679, RED, 2014/53/EU, DORA, 2022/2554 and AI Act, 2024/1689. Sources for the scope comparison, not comprehensive application guides for each act.