The CRA Is Already Here: Why 2027 Is the Wrong Deadline to Watch

Europe's Cyber Resilience Act is already testing something more fundamental than product compliance: whether manufacturers still understand the security of what they have sold.

Consider an industrial equipment manufacturer receiving a security alert on a Friday morning. Attackers are exploiting a vulnerability in a software component used across several generations of its connected controllers.

Security needs to determine whether the vulnerability can be exploited in the company's products. Engineering must identify affected firmware versions. Customer support needs to establish which customers are running them. Legal must decide whether the event triggers a regulatory reporting obligation and when the company became aware of it.

Four teams. One product. A clock that may already be running.

None of these questions can be answered by pointing to a security assessment conducted three years earlier. And none can wait for December 2027.

That is the overlooked significance of Europe's Cyber Resilience Act (CRA). Much of the discussion still focuses on the regulation's main application date, when extensive cybersecurity requirements will become mandatory for products with digital elements entering the European market.

Yet the CRA crossed its first operational threshold on 11 September 2026, when manufacturers became legally required to report certain security events affecting their products.

The obligation reaches into installed portfolios, established supply chains and software architectures designed long before the regulation existed.

The strategic question is no longer simply whether manufacturers can build compliant products for 2027. It is whether they can recognize, assess and respond to security problems in products already operating in their customers' environments.

The first regulatory deadline has already passed

The CRA, formally Regulation (EU) 2024/2847, entered into force on 10 December 2024. Its principal requirements concerning secure product design, vulnerability handling, conformity assessment and CE marking apply from 11 December 2027. The provisions governing the notification of conformity assessment bodies started applying in June 2026.

But Article 14 became applicable on 11 September 2026.

It requires manufacturers to notify two categories of events: actively exploited vulnerabilities contained in their products and severe incidents affecting product security.

The distinction matters. A vulnerability does not become reportable simply because it has been disclosed, or because its severity score is high. Active exploitation requires reliable evidence of malicious exploitation. Severe incidents are subject to separate criteria concerning their impact on the product's security.

Once a manufacturer becomes aware of a reportable event, an early warning must be submitted without undue delay and within 24 hours. A more detailed notification follows within 72 hours. For actively exploited vulnerabilities, a final report is due no later than 14 days after a corrective or mitigating measure becomes available. For severe incidents, the final report is due within one month of the 72-hour notification.

Reporting takes place through the Single Reporting Platform operated by ENISA, launched on the same September date.

The platform simplifies the regulatory interface: manufacturers submit a single notification through the system rather than contacting multiple national authorities individually. The relevant national Computer Security Incident Response Team, or CSIRT, coordinates its dissemination.

But simplifying the submission does not simplify the judgment behind it.

The initial notification may contain incomplete information. The regulation recognizes that investigations evolve. What a manufacturer cannot postpone indefinitely is the assessment of whether the available evidence has reached the threshold that makes notification necessary.

The challenge, therefore, begins well before anyone opens the reporting platform.

The legacy-product paradox

Article 69 of the CRA creates a distinction that every connected-product manufacturer should understand.

Products placed on the EU market before 11 December 2027 are generally not required to satisfy the regulation's full new product requirements retrospectively, unless they undergo a substantial modification after that date.

Article 69(3), however, extends the reporting obligations of Article 14 to those earlier products.

Consider an industrial controller launched in 2021. Its firmware incorporates third-party software, its communication functions depend on several libraries, and part of its configuration may rely on remote services. By 2026, the development team has changed, suppliers have evolved and newer product generations have absorbed most of the engineering resources.

The CRA does not automatically require that controller to be redesigned to meet every future cybersecurity requirement. But if the manufacturer becomes aware of an actively exploited vulnerability or severe incident that meets Article 14's criteria, the reporting obligation applies.

An important boundary remains: manufacturers are not required to report retrospectively active exploitation they already knew about before 11 September 2026. If they become aware of that exploitation after the reporting rules took effect, however, the obligation can apply even when the underlying vulnerability is older.

The transition is more consequential than it first appears.

Manufacturers are being asked to make timely, defensible security judgments about products whose historical technical records may be incomplete. Their original build environments may no longer be readily available. Supplier agreements may have expired. Key engineers may have moved elsewhere.

In industrial electronics, it is not unusual for products to remain in service long after the teams and processes that created them have changed.

That creates a form of product knowledge debt: the growing gap between what an organization once knew about a product and what it can still establish about that product today.

There is a further complication. The Commission's July 2026 guidance clarifies that Article 14 reporting obligations can continue even after a product's support period has ended. The obligation to handle vulnerabilities during the support period and the obligation to report qualifying events do not necessarily end at the same time.

An expired support commitment is therefore not a universal exit from regulatory responsibility.

For manufacturers of long-lived connected systems, that distinction deserves board-level attention.

Awareness is not an inbox notification

The reporting clock starts when the manufacturer becomes aware of an actively exploited vulnerability or severe incident. It does not necessarily start when the vulnerability was first discovered, when an advisory was published or when an attacker began exploiting it.

The Commission's implementation guidance links awareness to a prompt initial assessment providing a reasonable degree of certainty that the relevant event has occurred.

This creates a demanding operational problem.

A manufacturer receiving a vulnerability alert about a widely used library must determine whether the affected code is present in its product, whether the vulnerable functionality is actually exploitable in that integration, and whether reliable evidence of exploitation meets the reporting threshold.

The same library can be present in hundreds of products without presenting the same exposure in each one. Configuration, accessible interfaces, component versions and deployment conditions all matter.

A software bill of materials (SBOM) helps identify what a product contains. But an inventory of dependencies does not establish how those dependencies are used, which configurations are deployed, or whether a specific exploit can affect the finished product.

The manufacturer needs to connect several layers of evidence: component identity, product version, technical configuration, deployment context and the security information relevant to that product.

These records often exist in different systems, owned by different teams.

Engineering knows what was designed. Procurement knows which components were sourced. Security tracks emerging threats. Customer support sees incidents from the field. Product management knows which versions remain commercially active.

The problem arises when no one can connect those views quickly enough to establish a defensible conclusion.

The information needed to sell a product is often better organized than the information needed to defend it after deployment.

This is why I would introduce a different executive metric: Signal-to-Decision Time.

It measures the elapsed time between receiving a credible security signal and reaching a documented, product-specific decision on whether notification is required.

It is not a regulatory metric, and it must never be used to delay recognition of an event that already meets the legal threshold. Its value is diagnostic. It exposes how long the organization spends locating product information, obtaining technical evidence and clarifying decision authority.

A manufacturer should be able to test that capability before the next real incident occurs.

The supply chain is part of the evidence chain

Connected products are rarely developed by a single organization.

Hardware, firmware, operating systems, third-party libraries, cloud services and remote update mechanisms may come from different suppliers operating across several countries.

When a security issue emerges, technical knowledge is fragmented across the same network.

The component developer may understand the vulnerability. The integrator knows how the component is configured. The finished-product manufacturer knows the intended architecture. The customer may be the only organization observing unusual behavior in the deployed environment.

The CRA places reporting obligations on manufacturers of in-scope products. A flaw originating in a third-party component does not automatically transfer responsibility for the finished product to the upstream supplier.

Equally, every downstream manufacturer is not required to report simply because a shared component has a vulnerability. The technical conditions affecting its own product and the regulatory reporting criteria remain decisive.

This distinction makes supplier collaboration more important, not less.

A useful supplier security agreement must address more than whether patches will be provided. It should define how vulnerability intelligence is exchanged, how affected versions are identified, what technical evidence can be obtained, who coordinates investigations and how quickly information can be escalated.

The CRA also adds an international governance dimension.

Its scope depends on products being made available on the EU market, not on where the manufacturer is headquartered. A software developer in Singapore or an equipment manufacturer in the United States may therefore face the same relevant reporting duties as a European competitor.

ENISA's guidance also explains that a manufacturer is expected to submit one notification per qualifying event, even when the organization operates through multiple EU branches or subsidiaries, or has a parent company outside the Union.

Coordinating that response across the corporate structure remains the manufacturer's responsibility.

In other words, reporting may be centralized at the regulatory interface, but the evidence required to support it can be distributed across the world.

The manufacturer that has not decided which legal entity coordinates the assessment, which CSIRT is appropriate and who is authorized to submit a notification has left important decisions for the least convenient possible moment.

The real preparation for 2027 starts with the products already deployed

December 2027 remains a major regulatory milestone.

Manufacturers placing applicable products on the EU market will need to demonstrate conformity with the CRA's essential cybersecurity requirements. These include risk-based security measures, vulnerability-handling capabilities, technical documentation and the appropriate conformity assessment procedures.

The regulation also requires manufacturers to define a support period reflecting expected product use, generally at least five years unless the product is expected to be used for less.

For industrial equipment designed to operate over a decade or longer, this makes cybersecurity part of the product's long-term economics.

Security maintenance affects development budgets, architecture choices, supplier contracts, update mechanisms and future product margins.

But the immediate priority is not to launch another documentation program.

It is to establish whether the manufacturer possesses three capabilities.

First, product visibility: a sufficiently reliable view of the products and versions concerned, their important dependencies and the teams responsible for them, including legacy portfolios.

Second, decision readiness: a process that can connect security signals to technical evidence, determine whether the reporting criteria are met and authorize timely action.

Third, execution readiness: trained representatives, access to ENISA's reporting platform, a designated coordinating CSIRT and tested internal escalation procedures.

These capabilities should be tested together.

Imagine a supplier warning that a software component is being exploited in the wild. The affected library exists in several product generations, including one no longer supported. Some customers operate highly customized configurations. The responsible engineering teams are distributed across time zones.

Can the manufacturer establish which products are affected? Can it identify what remains uncertain? Can it determine whether the notification threshold has been reached and act within the applicable deadlines?

The answer will reveal more about CRA readiness than a policy document alone.

It will also indicate what needs to change in the design and maintenance of the next generation of products.

This becomes increasingly important as industrial systems incorporate more connected services, software-defined capabilities and AI-enabled functions. Not every AI system falls within the CRA's scope, but AI-enabled products with digital elements can introduce further dependencies that manufacturers must understand and manage.

Every additional layer of software increases the importance of maintaining an accurate relationship between what was built, what was delivered and what is running in the field.

The advantage belongs to manufacturers that retain product knowledge

The CRA is often described as another European compliance burden. That interpretation misses part of its significance.

The regulation is also changing what responsible ownership means in a software-dependent product economy.

For decades, manufacturers have optimized development around performance, cost, reliability and time to market. Cybersecurity has progressively joined those priorities, but it has often been concentrated around product release, periodic assessments or responses to incidents.

The CRA more explicitly connects product cybersecurity to what happens afterward.

The ability to retain technical knowledge, understand dependencies, evaluate new evidence and coordinate decisions across suppliers is becoming part of the manufacturer's operational capability.

That capability can reduce uncertainty during an incident. It can help customers assess supplier resilience. And it can inform better engineering decisions long before the next product reaches the market.

Not every vulnerability is reportable. Not every legacy product must be redesigned. December 2027 remains the principal milestone for full product conformity.

But the first meaningful test has already begun.

December 2027 will test whether manufacturers can demonstrate the security of the products they bring to market. September 2026 began testing whether they still understand the security of the products they have already sold.

The second challenge is not simply regulatory. It is a test of how well the industrial organization remembers its own products.

And that may be the more difficult problem to solve.

Sources

1. Regulation (EU) 2024/2847, Cyber Resilience Act, particularly Articles 13, 14, 64, 69 and 71.
2. European Commission: CRA reporting obligations.
3. European Commission: CRA legislative summary.
4. European Commission: CRA implementation guidance, 27 July 2026.
5. ENISA: Single Reporting Platform and implementation guidance.
6. ENISA: Single Reporting Platform FAQs.