Digital twins and cybersecurity: the new asset that also needs protecting

Cyber Resilience Act (CRA): Europe’s cybersecurity framework for digital products

3 de September de 2026

On September 11, 2026, any manufacturer with a connected product on the European market will have 24 hours to notify ENISA and the competent national CSIRT of an actively exploited vulnerability. That deadline isn’t a best-practice recommendation: it’s an obligation under Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), and it also applies to products that are already sold and in operation, with no exception for age.

For a manufacturer, that fact changes a design question that used to be optional. How many different systems would my team have to check to know, in under a day, whether a vulnerability affects a critical asset? The more heterogeneous pieces (VPN, RDP, endpoint agents, scattered credentials) make up access to that asset, the harder it is to respond in time. That’s the real technical problem the CRA puts on the table, and it’s where this article starts.

What is the Cyber Resilience Act (CRA)?

The CRA is the European Union’s first horizontal regulation setting mandatory cybersecurity requirements for any “product with digital elements” (hardware or software) sold in the EU, throughout its entire lifecycle. It entered into force on December 10, 2024, but its application is staggered:

December 10, 2024 — the Regulation enters into force.
June 11, 2026 — the provisions on notification of conformity assessment bodies start to apply.
September 11, 2026 — the notification obligations kick in: actively exploited vulnerabilities and serious incidents must be reported to ENISA and the competent national CSIRT.
December 11, 2027 — full application: no product with digital elements may be sold in the EU without complying with the CRA and carrying the corresponding CE marking.

According to INCIBE, manufacturers have up to 36 months from the regulation’s entry into force to adapt to compliance, which explains this staggered timeline rather than a single entry-into-force date.

Unlike NIS2 (which regulates operators of essential services) or ENS (which regulates the Spanish public sector), the CRA regulates the product’s manufacturer: whoever designs it, integrates it, and places it on the market under their brand (including selling under a private label, which counts as manufacturing for CRA purposes). It’s a deliberate paradigm shift: it moves the responsibility for security onto whoever places the product on the market, not onto whoever uses it.

Manufacturer vs. the company using the solution: who does what

This is the point that causes the most confusion, so it’s worth separating clearly:

The manufacturer (whoever designs, develops, or commissions the development of the product and markets it under their brand) is the party directly obligated: they must build in security by design, maintain the SBOM, support the product with updates during the support period, and are the ones who notify ENISA and the national CSIRT within the 24h/72h/14-day deadlines when they detect an actively exploited vulnerability or a serious incident in their product. They’re also the ones who answer for penalties and any eventual withdrawal of the product from the market.

The company using the product (the bank, the hospital, the public administration deploying a third-party solution) is not obligated to notify ENISA under the CRA, that burden falls on the manufacturer. Its role is to apply the security updates the manufacturer publishes, and to report to the manufacturer, through the coordinated vulnerability disclosure (CVD) channel the manufacturer must maintain, any vulnerability it detects. If that company is also an essential or important entity under NIS2, or falls within the scope of ENS, it keeps its own incident notification obligations as an operator, but those are obligations under those regulations, not under the manufacturer’s CRA. One nuance: if that company resells the product under its own brand or substantially modifies it, it becomes considered the manufacturer of that version, with the obligations that entails.

The notification process, step by step

Article 14 of the CRA sets out three deadlines, all of them the manufacturer’s responsibility:

Deadline	What must be reported	Who does it
24 hours	Early warning as soon as the exploited vulnerability or serious incident becomes known	The manufacturer, to ENISA and the competent national CSIRT, via the single notification platform
72 hours	Full notification, with a description, exploitation methods, and corrective measures taken	The manufacturer
14 days	Final report once the vulnerability has been fixed or the incident has been handled	The manufacturer

Alongside this notification to the authorities, the manufacturer must inform affected users and customers, along with recommended mitigation actions. That’s the point where the company deploying the product enters the process: it receives the alert and applies the update or mitigation, it doesn’t generate or file the regulatory notification.

On July 27, 2026, the European Commission published its official guidance on the Regulation’s scope of application, and has proposed pushing back the technical standardization timeline by two months: the horizontal vulnerability-management standards are now expected by late October 2026, and the product-specific vertical standards throughout December 2026. It’s worth checking the status of the harmonized standards before finalizing any compliance plan, since the timeline is still shifting.

The manufacturer’s core obligations

Beyond notification, the CRA requires:

Security by design and by default, not as a layer bolted on at the end of development.
An up-to-date SBOM (Software Bill of Materials), at least at the package level, available to competent authorities upon request.
Vulnerability management throughout the product’s entire support period, not just at launch.
Risk assessment documentation, kept for a minimum of 10 years.
Security updates available throughout the product’s declared lifecycle.

Non-compliance is punishable by fines of up to €15 million or 2.5% of worldwide turnover for the previous financial year, whichever is higher.

Classifying the product by risk

Not every product faces the same level of scrutiny. According to INCIBE, the CRA distinguishes four categories:

Unclassified: products with no critical vulnerabilities identified, subject to periodic self-assessment.
Important — Class I and Class II (Annex III): require a robust level of security, with increasing demands depending on the risk.
Critical (Annex IV): the highest level of scrutiny, generally involving a notified body.

The security support period, absent a different justification, has a general minimum of 5 years or the product’s expected useful life if shorter, a relevant data point when deciding which manufacturer to work with long-term.

Why does architecture matter?

Most content on the CRA stops at listing the manufacturer’s obligations. But the CRA doesn’t relieve the customer of responsibility, it changes its nature. Instead of having to detect and report a vulnerability itself, its role becomes receiving the manufacturer’s alert and acting fast: applying the update, assessing whether the critical asset is exposed, and, if it’s an entity under NIS2 or ENS, handling its own notification obligation as an operator. The more heterogeneous systems (VPN, RDP, endpoint agents, scattered credentials) make up access to that asset, the slower and harder it is to respond to that alert in time, whatever deadline its own regulation sets.

Cosmikal, a Spanish technology manufacturer, already applies this security-by-design philosophy in its own development processes, which positions Cosmikal as a company fully adapted to the practical application of the Cyber Resilience Act’s principles.

In summary

The Cyber Resilience Act cements a principle that will shape the next decade of European regulation: the security of a connected product is no longer assumed, it’s demonstrated through documentation, traceability, and verifiable response capacity. For the manufacturer, it means building security into the design process itself, as a condition of market access rather than a later requirement. For the organization adopting connected technology, it means examining how rigorously its vendors sustain that responsibility over time, and how quickly its own structure lets it act when an alert arrives.

The December 2027 horizon may seem distant. Experience with other European regulatory frameworks suggests otherwise: organizations that approach this transition early are the ones that reach each new regulatory milestone with security as an advantage, not a contingency.

Frequently asked questions about the CRA

Who does the Cyber Resilience Act apply to?

Manufacturers, importers, and distributors of products with digital elements (hardware and software) sold in the EU. Limited exclusions apply to sectors already covered by equivalent legislation.

When do the CRA’s obligations start to apply?

The vulnerability notification obligations take effect on September 11, 2026. The remaining obligations, including CE marking, apply from December 11, 2027.

Does the CRA affect products already on the market?

Yes. The 24-hour notification obligation also applies to products already on the market, with no transitional period or exception for age, as long as they still receive support from the manufacturer.

What’s the difference between the CRA and NIS2?

NIS2 regulates operators of essential and important services; the CRA regulates the manufacturer of the digital product those operators use. They’re complementary, not equivalent.

What is an SBOM, and why does the CRA require it?

An SBOM (Software Bill of Materials) is the inventory of a product’s software components. It makes it possible to identify libraries and dependencies in order to react quickly when a vulnerability affects a third-party component, something the CRA itself turns into a documentary obligation.