Cyber Resilience Act (CRA) 2026–2027: what we already know, what is still missing, and how to realistically prepare your product — before harmonised standards are published

What we know for sure today (and why this is not a “2027 problem”)

The Cyber Resilience Act can look like yet another “Brussels” document that can be pushed down the road. That reaction is understandable, especially if your business runs on a project cadence: prototype, rollout, series production, service. Regulations often arrive as a “final requirement” — something you button up at the finish line. CRA changes that logic, because it is not limited to what is visible in the product on the day it is sold. It is about whether the manufacturer can keep the product secure over time and demonstrate that this was done deliberately, not by accident.

The most important fact is simple, but strategically significant: CRA is a product regulation, embedded in the mechanics of the EU market (including CE marking). The European Commission states explicitly that products are to carry the CE mark as a signal of compliance with CRA, and enforcement lies with market surveillance authorities. So this is not an “IT standard” you can treat as an internal improvement programme. It is a framework that affects your ability to sell.

Dates that bring clarity

The text of Regulation (EU) 2024/2847 itself shows phased application. CRA applies from 11 December 2027, but with clear exceptions. Article 14 (reporting) applies from 11 September 2026, and the chapter on notifying conformity assessment bodies (Chapter IV) from 11 June 2026. These are three dates worth treating as “milestones”, because they correspond to three different types of readiness: operational, institutional, and product readiness.

The Commission communicates it even more plainly: CRA entered into force on 10 December 2024, the core obligations apply from 11 December 2027, and reporting from 11 September 2026. When someone in a company says “we have time until 2027”, they are usually thinking about design requirements and conformity assessment. But reporting comes earlier and concerns events that do not wait for your schedule.

Reporting: an obligation that forces a process (not a document)

The reporting requirement is a good litmus test because it shows how CRA understands “product cybersecurity”. It is not a statement of intent or a “policy”. It is a process that must work under pressure: when an actively exploited vulnerability appears or a serious incident occurs.

The Commission describes this unambiguously: the manufacturer must report actively exploited vulnerabilities and severe incidents affecting product security. An “early warning” is required within 24 hours of becoming aware, a full notification within 72 hours, and a final report: within 14 days after a remedy becomes available for actively exploited vulnerabilities, and within one month for severe incidents.

In practice, that means an organisation needs more than a checklist. It needs a mechanism that answers three questions: how will we learn the issue exists; who determines whether it is already “actively exploited” or “severe”; and how will we organise communication and a fix within a timeframe that leaves no room for improvisation.

If training sessions descend into confusion, it is often because CRA lands in the gap between IT and the product. For IT, an “incident” may be an event in the infrastructure. For a manufacturer, an “incident” is something that affects the customer’s product — its version, configuration, and deployment method. CRA forces these worlds into a single line of responsibility.

What CRA covers: the product as a relationship with the network, not a “device on the table”

In practice, when learning machine risk assessment, we were taught that risk is not a property of the machine itself — it arises in the human–machine relationship. CRA brings a similar shift in perspective: security does not exist “inside the device”, but in the relationship between the product and its digital environment, the way it is used, and the manufacturer’s ability to respond.

In its summary of CRA, the Commission highlights the definition of “products with digital elements” and the fact that reporting obligations apply to all such products made available on the EU market — including those placed on the market before 11 December 2027. This is a crucial clarification because it removes a common myth: “it doesn’t matter for older products”. Reporting does.

What is still missing (harmonised standards) and why that should not be paralysing

W discussions about the CRA, one phrase keeps coming up: “there are no harmonised standards yet, so you can’t do anything.” It sounds logical, but there’s a hidden trap in it. Harmonised standards are a tool that makes it easier to demonstrate compliance (presumption of conformity), but they are not the only way to build genuine product security. And they are not a prerequisite for starting to design properly.

The Commission explicitly addresses standards via the “CRA Standardisation” page and states that it has adopted the standardisation request M/606, covering a set of 41 standards supporting the CRA—both horizontal and vertical (product-specific). This matters because it shows the EU understands the market reality: without standards, companies will each build compliance in their own way, and market surveillance will have a harder job.

Horizontal and vertical standards: what this means for a manufacturer

In simple terms:

• horizontal standards are meant to describe “how” to build and maintain product security regardless of category (processes, methods, a risk-based approach),
• vertical standards are meant to refine requirements for specific product classes (where risks and architectures are typical).

This distinction has practical consequences. If you build an industrial product where part of the environment is “OT” and the lifecycle is long, you will need standards that are not written for a SaaS application. That is exactly why vertical standards matter: they help you move from high-level principles down to what to control in real-world architectures.

Work schedule: standards will arrive in stages, not “as one package before 2027”

In its CRA implementation materials, the Commission shows that the CRA is being rolled out in phases, and that standards are intended to support this process over time. In terms of facts that are certain today: we have a formally adopted regulation, and we have an active standardisation mechanism (M/606).

The key practical point is to understand one sentence: even when a standard is developed by standardisation organisations, “presumption of conformity” in the legal sense only arises once the reference to that standard is published as a harmonised standard in the Official Journal of the EU. This is the common mechanics of the EU harmonisation approach: standards are the bridge between law and engineering practice, but that bridge must be formally “recognised” by the EU.

From a manufacturer’s perspective, this means that 2026–2027 will be a period in which some companies will operate based on their own methods of demonstrating compliance (risk-based + evidence), while others will already be mapping to the emerging standards. And that is normal.

“No standards” does not mean “no obligation”—it means evidence matters more

This leads to an important consequence: if there are no standards that provide the simplest route to demonstrating compliance, the importance increases of what is always decisive in audit practice: a consistent decision trail.

What risks did we assess? Which scenarios did we treat as realistic? How did we select protective measures? How do we manage vulnerabilities? How long do we support the product? How do we inform the customer? The CRA does not require a manufacturer to “guess future EN standards.” It requires the manufacturer to be able to show that decisions were not arbitrary, but based on risk and the state of the art.

How to realistically prepare a product for the CRA (a roadmap for manufacturers and integrators)

The greatest value of the CRA is that it forces maturity: cybersecurity stops being an add-on to the product and becomes one of its inherent properties. But maturity doesn’t come from declarations. It comes from a process that is precise enough to work in practice, and simple enough that engineering doesn’t start working around it.

In machine risk assessment, the best design decisions appear when we stop asking “what hazards does the machine have” and start asking “in which tasks and states is a person exposed.” With the CRA, it’s analogous: we stop asking “what vulnerabilities does the product have” and start asking “under what conditions does the product become exposed, and what can the manufacturer do then.” This shift brings order to the work.

Step 1: Define the product as a system (not as a device)

Start by defining what, in your case, is a “product with digital elements.” Not only the hardware and firmware, but also what is often overlooked because it doesn’t fit in the box: components, libraries, update mechanisms, services without which the product cannot perform its function. In the CRA, this matters because the manufacturer’s responsibility covers what is placed on the market as a product—not only what the mechanical department built.

This is also the first point where integrators should be honest with themselves: if you integrate components and configure them in a way that creates a “final product” in the customer’s eyes, you are not just an “implementation provider.” You are a co-creator of risk and a co-creator of responsibility.

Step 2: Carry out the CRA risk assessment so it becomes a decision-making tool

It’s not about a “matrix” on a slide deck. It’s about a risk assessment that drives design decisions and can be repeated consistently.

In practice, a solid approach to CRA starts with a simple question: what are the real misuse scenarios in the customer’s environment—not just in the lab? Who has service access? What does the network look like? How often do we update? What are the consequences of downtime? In industry, these questions are more uncomfortable than in IT, because the answers are often: “we can’t update every week” or “we don’t have telemetry”. And that’s exactly why you need to ask them. CRA is law, but its impact is on design.

Krok 3: Build “vulnerability handling” as a production process, not a crisis response

The reporting deadlines described by the Commission (24h/72h/14 days/month) are unforgiving for an organization that doesn’t have a process. If you want to be ready for 11 September 2026, you need to treat “vulnerability handling” as part of the product lifecycle—not as “the security team’s task”.

That means:

• a single intake channel for reports (CVD policy + contact),
• triage with a clear owner and defined criteria,
• a mechanism to build and deliver security updates,
• a customer communication model that isn’t improvised,
• readiness to report (who reports, with what data, how fast).

All of this can sound like “organizational” work. In reality, it’s product work, because it affects versions, compatibility, update architecture, and the support strategy.

Krok 4: Choose the support period as a business decision, not a minimum requirement

If your products remain in industrial use for 10–15 years, the support period is strategic. CRA forces support to be more than an unfunded promise. That means the support period should come from an analysis: how long the product will be used, what the component supply chain looks like, and how long you will be able to deliver fixes. In practice, the support period starts to “pull” the entire ecosystem with it: supplier agreements, availability of the build environment, maintenance of toolchains, and even decisions about whether the product has remote features or is isolated.

If you treat the support period as a formality, by 2027 at the latest you’ll run into a conflict: the customer expects support, and you no longer have the resources or dependencies to provide it. CRA doesn’t create this problem—CRA only exposes it.

Krok 5: Get the supply chain in order: supplier conversations are part of compliance

There’s no “magic” in CRA that will make third-party components secure. If your device relies on libraries, communication modules, an operating system, an SDK, or hardware components, your risk depends directly on the quality of the supplier’s practices.

That’s why it’s worth starting now with conversations about things that don’t sound like marketing, but like engineering:

• whether the supplier can disclose vulnerabilities in a predictable way,
• their response time,
• whether they have a patch release process,
• whether they can maintain the component for a period that aligns with your support period.

This is where CRA truly hits the business: a supplier who can’t handle vulnerabilities isn’t “cheaper”. They’re a regulatory risk.

Krok 6: Build documentation as a coherent trail: law → risk → decision → evidence

In compliance audits, consistency always wins. If the risk assessment shows that a given interface is critical, but the documentation doesn’t explain how you secure it; if you claim updates are secure, but can’t show how you ensure package integrity; if you say you have a vulnerability handling process, but can’t show how you triage reports—this isn’t “missing paperwork”. It’s missing evidence that the process works.

Under CRA, in the absence of harmonized standards, this trail is especially important. Because it will be the basis for discussions with the market surveillance authority, an enterprise customer, and in some product categories also with the conformity assessment body. And just as importantly: it will be the basis for internal stability. The team knows why we do something, not just “that we have to”.

Conclusion: CRA as a new design requirement, not a “compliance project”

If I had to leave you with one thought that ties all three parts together: CRA is not a problem to solve at the end. It’s a framework that changes how you think about the product. Just as ISO 12100 teaches that risk arises in the human–machine relationship, CRA teaches that cybersecurity arises in the product–environment–manufacturer lifecycle relationship.

Harmonized standards will come and simplify certain paths. But their absence is not a reason to stand still. It’s a reason to focus on what CRA always evaluates: decisions, evidence, and the ability to operate in the real world—not in a presentation.