If your company places hardware or software on the EU market that connects, directly or indirectly, to a device or a network, the Cyber Resilience Act is something to deal with now. Not in eighteen months.

Most companies have a single date in mind: 11 December 2027. But the first enforceable obligation applies from 11 September 2026, and it covers products that are already on the market today.

This article is an overview of the regulation as a whole: what the CRA is, who it applies to, what it requires, and in what order to tackle it. The Article 14 reporting obligation is covered in detail in a separate article.

What the CRA is and why it exists

The Cyber Resilience Act is Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements. It entered into force on 10 December 2024.

The regulation names the problems it addresses directly: a low level of cybersecurity in products with digital elements, reflected in widespread vulnerabilities and in the insufficient and inconsistent provision of security updates - and a lack of information that prevents users from choosing secure products and using them securely.

One formal point matters more than it might seem. The CRA is a regulation, not a directive. It does not need to be transposed into national law the way NIS2 did. It applies directly and in identical wording across all Member States, so there is no national implementation to wait for.

The regulation is marked as having EEA relevance. Manufacturers outside the EU are not exempt either: what matters is not where a product is made, but whether it is made available on the EU market. A manufacturer based in Switzerland, the UK or the US that sells into the EU is in scope in the same way as one based in Germany or Poland.

CRA versus NIS2: one sentence that covers it

The CRA regulates the product. NIS2 regulates the organisation.

NIS2 tells operators in regulated sectors how to manage the risks of their networks and information systems, through national law that differs from one Member State to the next. The CRA tells manufacturers what properties a product must have before it goes on the EU market. Two different regimes, two different audiences.

They meet in the supply chain. An organisation regulated under NIS2 has to manage supplier risk - and increasingly that means asking suppliers exactly the questions the CRA asks. Even if your company falls outside NIS2 entirely, commercial pressure to comply with the CRA is likely to reach you through your customers before it reaches you through a regulator.

What counts as a “product with digital elements”

The regulation applies to products made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Hardware and software alike.

In practice that covers connected machinery and industrial equipment, control systems, IoT devices, routers and network equipment, mobile and desktop applications, operating systems, embedded software - and components that another manufacturer builds into their own product.

The word indirect matters more than it looks. If your component does not connect to a network on its own but sits inside an assembly that does, it is in scope too.

Does the CRA apply to cloud and SaaS?

Usually not - with one significant exception. The CRA covers remote data processing solutions: software designed and developed by or on behalf of the manufacturer of a product, the absence of which would prevent that product from performing one of its functions.

So a cloud service through which a user controls your device remotely is in scope. A standalone SaaS platform that is not necessary for any product to function is not covered by the CRA - though other EU rules may apply to it, NIS2 among them, where the provider meets its sectoral and size criteria. A website that does not support a product’s functionality is outside the CRA as well.

Roles: manufacturer, importer, distributor

Obligations differ by role, and most of them fall on the manufacturer. Watch for two situations in which an importer or distributor becomes a manufacturer, with the full set of Article 13 and 14 obligations attached:

• Placing a product on the market under its own name or trademark - white label and private label arrangements.
• Carrying out a substantial modification of a product already on the market.

The same applies to any other party - a system integrator, for instance - that substantially modifies a product and makes it available. They become the manufacturer for CRA purposes.

What falls outside the CRA

The regulation does not apply to products already covered by sector-specific EU law, or to certain other categories:

• Medical devices under Regulations (EU) 2017/745 and 2017/746.
• Motor vehicles and their systems and components under Regulation (EU) 2019/2144 - the area covered by type approval and UN R155.
• Aeronautical products certified under Regulation (EU) 2018/1139.
• Products developed or modified exclusively for national security or defence purposes, and products specifically designed to process classified information.
• Spare parts intended for repair, including parts for legacy products placed on the market before the regulation applies.
• Non-commercial free and open-source software. What matters is not whether the code is open, but whether it is supplied in the course of a commercial activity. Software that its developer does not monetise is not a commercial activity; accepting donations or issuing regular releases does not change that on its own.

Sector exclusions are narrower than they first appear, and automotive is the clearest example. What is excluded is what Regulation (EU) 2019/2144 covers - not everything a company supplies to the automotive industry. Diagnostic equipment, charging stations, production and test systems, and telematics modules outside type approval may well fall under the CRA. This is a question to answer product by product, not once for the whole company.

Product classes and what follows from them

The CRA sorts products into four tiers by risk. The tier determines whether you can assess conformity yourself or must involve a notified body. What decides the tier is the core functionality of the product, not whether it happens to include a security feature as a secondary capability.

The technical descriptions of each category are set out in Implementing Regulation (EU) 2025/2392. If your product’s classification is arguable, that is the first document to open.

Which companies this hits hardest

Unlike NIS2, which targets operators in defined sectors, the CRA lands on a different population entirely. Typically:

• automotive suppliers shipping connected components outside type approval,
• industrial automation, machinery, control and measurement system vendors,
• IoT and smart home device manufacturers,
• software vendors selling on-premise products and mobile applications,
• companies that resell someone else’s product under their own brand.

What these have in common is that most of them have never been subject to cybersecurity regulation before. The owner of the problem is not the IT department or the CISO - it is engineering, product management and quality.

What the CRA requires

1. Security requirements for the product itself

Annex I, Part I sets out the essential requirements a product must meet when placed on the market. Among them:

• the product ships without known exploitable vulnerabilities,
• a secure by default configuration, with the option to reset to a secure state,
• protection from unauthorised access, including authentication and identity management,
• protection of the confidentiality and integrity of stored, transmitted and processed data,
• processing only the data that is necessary for the product to function,
• minimisation of the attack surface, limitation of incident impact, and logging of security-relevant events,
• the ability to address vulnerabilities through updates, automatically in the case of consumer products.

The requirements are written in outcome terms, not as a technical specification. Which of them are relevant to your product is determined by your risk assessment - and where one is not relevant, you have to justify that in the technical documentation.

2. Cybersecurity risk assessment

The product risk assessment is the core of the technical file. It is not a one-off document: it has to be updated throughout the support period and account for both the intended and the reasonably foreseeable use of the product.

3. Due diligence on third-party components

If you integrate third-party components, including open-source ones, you have to exercise due diligence. The regulation gives examples: checking whether the component already bears CE marking, whether it receives regular security updates, whether it is listed with a vulnerability in the European vulnerability database or other publicly accessible databases - or carrying out additional security testing.

If you find a vulnerability in a component, you are expected to inform whoever manufactures or maintains it, remediate the vulnerability, and where applicable share the fix with them.

4. SBOM

Manufacturers must identify and document the components contained in the product and draw up a software bill of materials in a commonly used machine-readable format, covering at least the top-level dependencies.

Good news if confidentiality is a concern: you are not required to publish the SBOM to users. A market surveillance authority may request it in certain cases; where a Union-wide assessment of software dependencies is carried out, the relevant information is passed on in anonymised and aggregated form.

5. Support period and security updates

The support period should reflect the time the product is expected to be in use, and it may not be shorter than five years - the only exception being a product with a shorter lifetime. Where a product is typically in use for longer, as with network equipment, operating systems or industrial control systems, the support period should be correspondingly longer.

Security updates must be free of charge and, where technically feasible, provided separately from functionality updates. Users must also be told when the support period ends.

The Commission’s July 2026 guidance addresses how support periods should be determined. If you make long-lived products, that section is worth reading closely - five years is a floor, not a recommendation.

6. Vulnerability handling and coordinated disclosure

Throughout the support period the manufacturer has to handle vulnerabilities: test and review the security of the product effectively and regularly, remediate vulnerabilities through updates without delay, and publish information about fixed vulnerabilities including a description and guidance for users.

Two organisational obligations come with this, and most manufacturers do not have either today: a coordinated vulnerability disclosure policy and a single point of contact through which anyone can report a vulnerability to you. That contact point cannot rely on automated tools alone.

7. Reporting obligation

From 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products. You report once, through the single reporting platform operated by ENISA, to the CSIRT designated as coordinator where your main establishment is, and simultaneously to ENISA. The clocks start differently in each case:

• Actively exploited vulnerability: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report no later than 14 days after a corrective measure becomes available.
• Severe incident: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of that notification.

This is the only obligation already in force, and we cover it in detail in a separate article.

8. Conformity assessment, CE marking and documentation

Compliance is demonstrated through conformity assessment, an EU declaration of conformity and CE marking. Without it, a product may not be made available on the EU market. The technical documentation and the declaration of conformity have to be kept at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period, whichever is longer.

A substantial modification means conformity must be verified again and, where applicable, a new conformity assessment carried out. A security update that does not change the intended purpose of the product is not a substantial modification.

What real products look like today

The Annex I requirements read as abstractions on paper. In practice they describe precisely the flaws we have been finding in product tests for years.

At Citadelo we have been running penetration tests on IoT devices for a long time, and almost every device we test contains at least one vulnerability rated high or critical. The same five problems keep coming up:

What changes is that from December 2027 these findings stop being technical debt. They mean the product does not meet the essential requirements of the regulation. And if someone exploits one of them, from September 2026 that becomes a reportable event on a 24-hour clock.

The deadlines that apply

Alongside this, a set of harmonised standards is being developed under standardisation request M/606, accepted by CEN, CENELEC and ETSI. Applying them in full gives a presumption of conformity - for class I products that is the difference between self-assessment and having to involve a notified body.

Penalties, and what actually hurts

The regulation sets three tiers of fines:

• up to EUR 15 million or 2.5 % of worldwide annual turnover for breaching the Annex I essential requirements and the obligations in Articles 13 and 14,
• up to EUR 10 million or 2 % of turnover for breaching other obligations,
• up to EUR 5 million or 1 % of turnover for supplying incorrect or misleading information to notified bodies and market surveillance authorities.

For most manufacturers, though, a different consequence matters more. Market surveillance authorities can order corrective action, restrict availability, or take a product off the market. For a company that exports into the EU, that is not an accounting risk - it is a stop on sales.

What to do, in order

Inventory your products. Which products do you make available on the EU market, which of them connect directly or indirectly, and what role do you hold for each. Do not overlook products you sell under your own brand, and those you no longer actively develop but still sell.

1. Classify them. Default, important class I or II, critical. This decision determines whether self-assessment is enough or a notified body is required - and therefore how much time and budget to plan for.
2. Build the SBOM. Without visibility into components you cannot meet the due diligence requirement or the 24-hour reporting window. The most practical starting point is generating the SBOM in the build pipeline.
3. Produce the risk assessment and technical documentation. For each Annex I requirement, document how you meet it - or why it does not apply to your product.
4. Stand up a vulnerability handling process. Coordinated disclosure policy, single point of contact, monitoring of vulnerabilities in components, and a plan for shipping fixes across the whole support period.
5. Verify it independently. The CRA does not mandate a penetration test. Annex I does require the manufacturer to test and review the security of the product effectively and regularly, and the due diligence provisions explicitly contemplate additional security testing. Independent testing is the most direct way to evidence that the requirement is met - not because the law prescribes it, but because self-assessment without technical verification is only an assertion.
6. Rehearse the response. One tabletop exercise on the scenario “a vulnerability in our product is being exploited in the wild” will tell you more about readiness than a documentation audit. Can the product team decide within 24 hours whether this is reportable, and does anyone know who makes that call on a Friday night?

Frequently asked questions (FAQ)

Does the CRA require penetration testing?

Not explicitly. Annex I requires the manufacturer to test and review the security of the product effectively and regularly; the form of testing is not prescribed. For most products independent testing is the most practical way to meet and evidence that requirement, but it is not a legal obligation in itself.

We are ISO 27001 certified. Is that enough?

No. ISO 27001 assesses an information security management system inside an organisation. The CRA assesses the properties of a product you place on the market. An established management system will make the work easier, but it does not replace the product risk assessment, the SBOM, the technical documentation or the conformity assessment.

We supply a component. Does the CRA apply to us?

If you make the component available on the market in the course of a commercial activity, yes - you are its manufacturer. On top of that, the manufacturer of the finished product has a due diligence obligation towards your component, so expect the questions to come from that direction as well.

We no longer develop a product, but it is still on sale. What now?

The reporting obligation from 11 September 2026 applies to products already on the EU market. For products still on sale after 11 December 2027, full compliance will apply too. This is typically the point at which to decide whether to bring the product into compliance or withdraw it from the EU market.

Does the CRA apply to our cloud backend?

If the product cannot perform one of its functions without it, and you or someone acting on your behalf developed it, it is a remote data processing solution and falls within the scope of the CRA. If it is a standalone service independent of any product, the CRA does not apply to it.

We are based outside the EU. Does the CRA still apply?

Yes, if you make products available on the EU market. The CRA follows the product, not the manufacturer’s address. Manufacturers established outside the EU also need to consider the requirement to designate an authorised representative where applicable, and importers and distributors in the EU carry their own obligations in relation to your product.

Where to start

The difference between the two deadlines is simple: December 2027 is about being able to demonstrate, September 2026 is about being able to respond. Companies that start by preparing to report will build a product inventory, an SBOM and a vulnerability handling process along the way - which is most of what they will need for conformity assessment a year later.

If you need independent verification that your product holds up against the Annex I requirements, at Citadelo we test:

• firmware and hardware interfaces, including debug ports,
• mobile, web and API interfaces of the product,
• cloud backends and remote data processing solutions,
• authentication and access control mechanisms,
• update mechanisms and signature verification,
• vulnerabilities in third-party components and dependencies.

The point is not to hold a document saying the product is secure. The point is to be able to verify its security technically.

Legal note: this is an informational overview, not legal advice.