Before the CRA Arrives: What you should be prepared for - Sigma Software

Before the CRA Arrives: What you should be prepared for

When the European Cyber Resilience Act entered into force in December 2024, it set out to significantly change the cybersecurity rules for products with digital elements on the market. The regulators gave businesses time to adapt before full compliance became mandatory in December 2027. But that transition period is moving quickly. The first regulatory milestone is only a couple of months ahead. In this article, we'll walk you through what the CRA covers, whether your product falls in scope, and how to get ready before the deadlines arrive.

The Cyber Resilience Act (CRA) is the new EU cybersecurity law for products with digital elements. If your product contains software, runs code, or connects to another device, it probably falls under the CRA. The regulation covers a wide range of devices, from smart cameras and fitness trackers to business software, industrial equipment, and the components inside them.

The core requirement of the Cyber Resilience Act is to make products secure by design and by default. That is how the regulators aim to make digital devices more resilient against cyber threats and raise the baseline of cybersecurity across the whole EU market. In practice, this comes down to five domains businesses need to cover:

Another key aspect of the Cyber Resilience Act is that it is directly linked to CE marking – a product’s ticket to the European market. Without the CE mark, a product cannot be sold in the EU, and from December 2027, products with digital elements will not be able to obtain it unless they comply with the CRA.

However, the CRA journey does not start in 2027, the first key checkpoint comes much earlier. Already in September 2026, businesses have to notify authorities of two things: actively exploited vulnerabilities in their products and severe incidents affecting product security. Notifications go to ENISA and the national cybersecurity authority through a single reporting platform.

Once the deadlines are applied, non-compliance becomes costly. Penalties depend on how serious the breach is. Fines under the regulations are either a fixed maximum or a percentage of worldwide annual turnover, whichever is higher. Major violations can reach €15 million or 2.5%. Lesser breaches sit at up to €10 million or 2%, and misleading information to authorities up to €5 million or 1%. On top of that, regulators can even recall a product from the market.

The stakes are high, and the earlier your compliance journey begins, the easier it is for your business in the long run. First, spot your starting point. Below, we break down how to find it.

Check whether your product falls under the CRA

This is where every compliance journey begins. While the CRA covers a broad range of products with digital elements, applicability to the regulation depends on several additional factors. The questions below are a good place to start working out whether your products apply:

1. Does your product include software or hardware with digital elements?
The CRA covers products that contain code or process digital information, from operating systems and mobile apps to smart devices and industrial equipment. If your product runs software, connects to a mobile app, has an interface, or contains a chip, it qualifies.

2. Does your product connect to a network or another device?
Wi-Fi, Bluetooth, USB, cloud, or another device, direct or indirect connection counts. A fully standalone product with no interfaces is more likely to sit outside the scope.

3. Is your product available for users in the EU market?
No matter where the manufacturer is based. If your product reaches European customers, the regulation applies to your product.

4. Which category does your product likely fall into?
The CRA sorts products into four categories:
Default Important,
Class I
(listed in Annex III)		 Important,
Class II
(listed in Annex III)		 Critical
(listed in Annex IV)
Everyday products that do not perform a specific cybersecurity function and are not listed in the CRA’s higher-risk annexes. For example, consumer electronics, software applications, and home IoT devices. Products with a cybersecurity function, such as password managers, browsers, VPNs, network management systems, and smart home devices with security features. Products that perform sensitive security functions inside a system, filtering traffic, isolating workloads, or resisting tampering. Examples include firewalls, hypervisors, and tamper-resistant microprocessors. Products that protect other systems or sensitive data. Their failure can have wide consequences across other devices and networks. For example, hardware security modules, smart meter gateways, and secure smartcards.

Where a product sits in this list determines how it is checked for compliance. Default-category products are self-assessed, while important and critical products will require a review by a regulatory body.

5. Does your product fall under another sector-specific legislation?
Some products already have their own cybersecurity rules and are excluded from the CRA. These include:

If yours is one of them, you are outside the CRA, but not outside regulation. Your industry’s own cybersecurity framework still applies.

In other cases, here is a quick rule: if your product has digital elements, connects to something, and reaches the EU market, it’s almost certainly in the scope. The next section walks you through what to do about it.

Build foundation for compliance

Once you know your product is in scope, the next step is to define what getting compliant would actually involve. The journey may seem complex, but it begins with three key steps. Getting these right early makes the rest of the work much easier.

Map the scope of CRA inside your organisation

Start by creating a clear inventory of the products and services affected by the CRA. For each product, identify key components and dependencies, establish its classification, and determine the teams responsible for the compliance process.

One area that organizations often overlook at this stage is cloud services. The CRA covers not only the physical or downloadable part of a product but also the remote data processing services needed for its core functionality. If your product relies on cloud components, those are in scope of the regulation too.

Even when your product components come from third-party suppliers, you remain accountable for the security of the final product. Thus, it’s important to identify all your vendors and define whether their components or services meet the required security standard.

Run a cybersecurity risk assessment across the product lifecycle

The CRA requires businesses to understand and manage cybersecurity risks throughout the product lifecycle, not just before its launch. Thus, a good starting point is to assess how your product could be attacked using a practice known as threat modeling. This means carefully examining the product and all the systems it interacts with, including supporting cloud services, APIs, or external dependencies. Building on that, you can identify potential threats, such as unauthorized access, insecure interfaces, vulnerable third-party components, and weak authentication mechanisms.

Note that threat modeling needs to reflect the specifics of your business, since the same technical risk can have a very different impact depending on how the product is used.

The next stage is the risk assessment itself, where each identified threat is examined more closely by answering the following questions:

The outcome of the assessment should inform your product decisions. For example, it may lead to stronger authentication requirements, encryption of sensitive data, additional monitoring capabilities, or more secure software development practices. Also, under the CRA, the risk assessment is how you justify your design and development choices. If a regulator asks why a certain control was picked, the risk assessment becomes your answer.

That is why a cybersecurity risk assessment cannot be a one-time exercise. It should be conducted throughout the product’s lifecycle as the product evolves and new security risks emerge.

Set up a vulnerability handling and reporting process

This step is tied directly to the milestone set by CRA for September 2026. From that date, manufacturers must be able to detect, manage, and report actively exploited vulnerabilities and severe incidents in their products, including those that are already on the market.

This means having an established process to identify vulnerabilities, apply security updates during the support period, and notify authorities within the CRA’s reporting windows: an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days (or a month, in the case of severe incidents). It also includes keeping users informed about vulnerabilities, security updates, and incidents that may affect products.

Prepare documentation for compliance

The CRA requires manufacturers to prepare technical documentation before placing a product on the EU market. Every requirement in the previous steps, like the risk assessment or the vulnerability handling, needs to exist on paper in a form that regulators can review and verify your product was developed, maintained, and monitored in a secure way.

In practice, documentation spans several areas:

It also covers how long you will support the product with security updates, and how the third-party and open-source components inside it were reviewed for security.

Note that it’s important to keep your documentation current. It needs to reflect where the product is today, not where it was at launch. While your product evolves, the documentation has to keep pace with it, capturing every new risk, patch, and decision.

How Sigma Software guides the compliance process

The CRA is a broad and detailed regulation, and this article is only a starting point. Each section discussed here is backed by dozens of pages of legal text, technical requirements, and practical decisions that depend on the specifics of the product and business context. There is no one-size-fits-all path to compliance, each strategy should be shaped individually.

At Sigma Software, we support businesses across sectors with cybersecurity, secure product development, and regulatory readiness. If you are unsure whether the CRA applies to your product, need help mapping your compliance landscape, or want a reliable partner to walk you through the entire process end-to-end, we are here to support you.