Before the CRA arrives: What you should be prepared for

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:

However, the CRA journey starts even before 2027. The first key checkpoint came on September 11, 2026. Since then, manufacturers of products with digital elements have been required to report actively exploited vulnerabilities or severe incidents affecting product security through the EU Single Reporting Platform (SRP). This includes products that were already on the EU market.

Once the deadlines are applied, non-compliance becomes costly. Penalties depend on how serious the breach is. Fines under the regulation 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. Note that the regulation is product-focused, not company-focused. Therefore, assess each product individually, since part of your portfolio may fall outside its scope. 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?
Any direct or indirect connection counts, whether via Wi-Fi, Bluetooth, USB, the cloud, or another device. 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:

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 notified 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. Among those products are:

• Medical devices and in vitro diagnostics (Medical Device Regulation and the In Vitro Diagnostic Regulation)
• Motor vehicles (the General Safety Regulation)
• Civil aviation products (the EASA Basic Regulation)
• Marine equipment (the Marine Equipment Directive)
• Products developed exclusively for defence or national security purposes
• Non-commercial open-source software developed and supplied outside a commercial activity
• Spare parts that replace identical components to the same specification

If your product belongs to this list, then you are outside the CRA, but not outside regulation. Your industry’s own cybersecurity framework still applies. In case it’s unclear which regulation applies to your product, for example, because it falls within the scope of both the CRA and another regulation, contact the market surveillance authority (MSA) in your Member State for clarification.

Before that, also check the European Commission’s guidance and FAQs to prepare your own conclusion on applicability and classification, along with the reasoning behind it. Keep in mind that neither the MSA nor the Commission will issue a binding ruling on whether your product is in scope, so the assessment remains your responsibility. Here’s an overview of confirmed and reported CRA authorities across the EU:

The first CRA obligation is already in effect

While most CRA requirements will apply from December 2027, reporting obligations for actively exploited vulnerabilities and severe security incidents are already in effect starting from September 2026. The obligation applies to all products in scope, including those already on the market. This means that if your product is in scope of the Cyber Resilience Act, setting up an incident reporting process has become the first priority.

Under this requirement, once an organization becomes aware of an actively exploited vulnerability or a severe incident, it must submit an early warning within 24 hours, followed by a notification within 72 hours and a final report within the timelines specified by the regulation.

While the obligation focuses on reporting, effective compliance requires more than submitting a notification. Organizations need a clear process for determining whether a vulnerability or incident meets the CRA reporting criteria, who is responsible for that decision, what information must be collected, and how notifications are prepared and approved within the required timeframes.

The following steps can help put the incident process in place:

1. Assign representatives
   On the Single Reporting Platform, an assigned representative (AR) submits reports on behalf of the manufacturer. Each manufacturer designates one primary assigned representative and may appoint secondary assigned representatives as backups. This platform role differs from the authorized representative defined in the CRA.
2. Prepare Single Reporting Platform (SRP) access
   ARs sign in with a personal EU Login account protected by multi-factor authentication. Accounts set up in advance prevent delays when a report is due. ENISA’s registration guidance helps navigate the process.
3. Establish an internal reporting process
   Teams rarely have the full picture at the start, yet the 24-hour reporting window leaves no time to wait for it. The good news is that the first notification isn’t the final word: companies still submit an intermediate and a final report, and the conclusions can change as the investigation moves forward. So it’s safer to over-report than under-report.A tabletop or simulation exercise comes in handy here. It shows whether the reporting process works in practice: everyone knows their role, and nothing slows the report down. If the exercise uncovers gaps or delays, companies can address them before a real incident requires regulatory reporting.

Build a foundation for compliance

Once you know your product is in scope, the next step is to define what getting compliant would actually involve. As the necessary processes, controls, and documentation take time to build, businesses need a structured plan to prioritize activities, allocate resources, and prepare for compliance in a coordinated way.

Map the scope of CRA inside your organization

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 risk assessment for the product

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 type of assessment will help you carefully examine 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:

• How likely the risk may occur?
• What potential impact may it have on business and users?
• What security controls exist to reduce the risk?
• What additional measures may be needed?

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. Under the CRA, the risk assessment also justifies your design and development choices. If a regulator asks why a certain control was picked, the risk assessment becomes your answer.

If any gaps are identified, prioritize them by risk and deadline, sequence the work toward full compliance in December 2027, and budget realistically for both engineering effort and conformity assessment.

Embed security across the product lifecycle

The CRA expects cybersecurity to be considered throughout the entire product lifecycle, from design and development to release and ongoing maintenance. That is why security cannot be treated as an afterthought in a final testing step but must be integrated into everyday product development activities.

For example, this may include using threat modeling during product design, secure development practices during implementation, security testing in CI/CD pipelines, and secure-by-default configurations in released products.

If you already follow ISO 27001, some of this work can be reused. However, certification under this standard doesn’t prove that a specific product in your portfolio meets CRA requirements.

At a minimum, you will need to cover the requirements specific to the CRA:

• Develop and implement a coordinated vulnerability disclosure policy
• Generate and maintain SBOMs for every product in CRA scope
• Establish incident and vulnerability reporting processes
• Implement secure-by-design practices, including threat modeling, which may not be part of your current practice
• Conduct regular security testing, such as vulnerability scanning and penetration testing
• Collect and maintain the evidence needed to demonstrate compliance for each product
• Review and, where needed, improve the user documentation so that it covers all required security aspects: secure installation and configuration, update and patch handling, support period, and the other information the CRA requires users to receive
• Invest additional effort in building product-specific risk assessments and risk registers, since ISO 27001 focuses on the organization as a whole.

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 risk assessment or vulnerability handling, needs to exist on paper in a form that regulators can review and verify that your product was developed, maintained, and monitored in a secure way.

In practice, documentation spans several key areas:

• How you identify and manage risks
• How you write and verify code
• How you track and update components
• How you handle incidents and communicate with users

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. These components must be listed in a software bill of materials (SBOM), which the CRA requires for every product in scope. You can find more about how SBOMs work and how to build one in our article.

Follow official updates from the Commission and ENISA

The CRA compliance guidance is still evolving, with new clarifications and reporting requirements being published over time. So, it’s a good practice to monitor updates from the European Commission and ENISA, especially on product scope, risk classification, and reporting obligations. When making compliance decisions, document the guidance you relied on and periodically review those decisions to ensure they remain aligned with the latest requirements.

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 cybersecurity 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 with our Cyber Resilience Act compliance services.

• #Cybersecurity