CRA Standards: What’s Coming, When It’s Coming, and Why Manufacturers Can’t Wait

The CRA Is Here - But the Rulebook Is Still Missing

When the Cyber Resilience Act entered into force, it marked a milestone for Europe: a single horizontal cybersecurity law covering everything from consumer IoT to industrial automation. Brussels delivered the regulation. The dates are fixed. The obligations are defined. But for manufacturers, clarity ends exactly where the actual work begins.

The CRA explains what companies must achieve - secure-by-design products, continuous vulnerability management, transparent support periods, verifiable documentation. What it doesn’t explain is how those requirements should be met. That technical guidance is supposed to come from harmonised standards, the norms that translate legal expectations into actual engineering practice.

And that’s the problem: those standards are still in development, while the regulatory clock keeps ticking.

Across engineering teams, compliance offices and product roadmaps, the same question echoes: “What should we implement today to be compliant tomorrow?”

It’s a reasonable concern. The first binding duties start in September 2026, full conformity in December 2027 - but the technical backbone that manufacturers rely on is still a moving target. The CRA is effectively running ahead of the standards meant to support it.

What We Actually Know: The Law Is Clear, the Details Are Not

Now that we’ve acknowledged the uncertainty surrounding the technical rulebook, the next step is to isolate what is already solid. Because despite the missing standards, there is one part of the CRA that is not shifting, debatable, or in draft: the regulation itself.

The CRA’s legal backbone is complete. It defines who is responsible at each stage of the product lifecycle and outlines the obligations manufacturers, importers, and distributors must meet. These duties don’t depend on any future standards - they are already in force.

What’s equally immovable is the timeline. The CRA entered into force, the transition period started, and the clock is running regardless of how fast the standards progress.

Manufacturers can rely on three fixed anchors:

• The CRA is legally valid today.

• In September 2026, the first real obligations kick in - most notably the reporting of actively exploited vulnerabilities.

• By December 2027, the CRA is fully in force.

These dates won’t shift. They represent the regulatory backbone against which all technical details must eventually align.

What isn’t defined yet is how, exactly, these obligations should be implemented in engineering, testing, documentation, or security operations. The CRA sets the destination but leaves the route open. It intentionally hands off the technical interpretation to European standardisation bodies - the groups now responsible for turning broad legal goals into actionable, testable requirements.

And that is where the central tension forms: Manufacturers know their obligations but lack the detailed technical benchmarks that will ultimately determine compliance.

To understand when - and how - these missing details will materialise, we have to look at the machinery responsible for creating them. That brings us to the next chapter: the complex, often invisible standardisation ecosystem now racing to build the technical foundation of the CRA.

Want to keep up with evolving CRA guidance and interpretations? Start with Tributech’s CRA Guide as your central reference point for up-to-date insights and resources.

Inside the Standardisation Engine: Europe’s Quiet Race Against Time

If the CRA itself is the skeleton, the standards are the muscle and connective tissue - the parts that give the regulation practical form. And right now, those parts are being assembled at high speed in a system that was never designed to move quickly.

Most people outside the compliance and policy world underestimate how European standards are made. They don’t emerge from a single drafting desk in Brussels. They are negotiated across dozens of committees, hundreds of experts, and months of iterative debate. Every clause must balance security needs, industry feasibility, and international alignment. In short: standardisation is slow by design.

But the CRA doesn’t care about that. Its deadlines are fixed, and the European standardisation bodies now have to adapt.

Three organisations carry the weight of translating the CRA into technical reality:

• CEN

• CENELEC

• ETSI

Supported - and in certain areas challenged - by ENISA, which contributes operational cybersecurity expertise and guidance.

Together, they are working on 41 separate standardisation projects, each addressing different slices of the CRA’s essential requirements. Some focus on horizontal cybersecurity principles, others on vulnerability management, others on product-category-specific controls for critical devices. Many involve both industry and academic experts, all trying to anticipate how CRA obligations should manifest technically.

The challenge? These groups are operating under unprecedented time pressure. The CRA compresses a process that normally spans five to seven years into roughly two. Drafts must be produced, reviewed, updated, and validated - all while ensuring consistency across dozens of parallel workstreams.

That’s why this phase is the real bottleneck of CRA implementation. Not politics. Not enforcement. Standards. They are the missing layer between law and engineering, and their slow, consensus-driven development clashes directly with the CRA’s fast, regulatory timeline.

To understand what manufacturers can realistically expect - and when - we now turn to the roadmap ahead: the concrete, already-planned schedule for the publication of CRA-related standards.

The Architecture of Future CRA Standards: Three Layers, One Goal

Once you step inside Europe’s standardisation machinery, one thing becomes clear: the output won’t be a single, monolithic “CRA standard.” Instead, manufacturers will have to navigate an interconnected structure of norms - each addressing a different dimension of the regulation’s essential cybersecurity requirements.

To keep this complexity manageable, the CRA standardisation request organizes the upcoming standards into three layers, each serving a distinct purpose:

Layer 1: Type A - Horizontal Security Principles

These are the foundation. Type A standards define the overarching security-by-design concepts that every product - no matter its complexity or category - must follow. They outline methodological expectations: secure development lifecycles, risk analysis frameworks, security controls that apply broadly across technologies. For manufacturers, this layer acts as the baseline: the “minimum hygiene” that every CRA-compliant product must demonstrate.

Layer 2: Type B - Cross-Cutting Requirements & Vulnerability Handling

The second layer goes deeper into operational processes. Type B standards will establish the concrete expectations for vulnerability handling - largely aligned with ISO 29147 and ISO 30111 - and other generic requirements that span all CRA product classes. These standards are central because they define how manufacturers must detect, triage, report, patch, and document vulnerabilities across the entire support period. In practice, Type B will shape how your PSIRT (Product Security Incident Response Team) works and how you structure your lifecycle documentation.

Layer 3: Type C - Product-Specific Norms for Critical Categories

This is where things get highly tailored. Type C standards will apply only to certain “critical” or high-impact products - routers, firewalls, network equipment, industrial components, and other devices listed in Annex III and IV of the CRA. These standards translate broad requirements into technical, category-specific expectations. Think: authentication requirements for networking gear, cryptographic controls for secure elements, or update mechanisms for IoT endpoints.

What makes this architecture especially important is that each layer becomes relevant depending on what you build. A manufacturer of consumer IoT devices may draw heavily on Type A and Type B. A company producing industrial gateways or network components will need to integrate Type C on top of those.

Together, the three layers form a coherent system: principles → processes → product-category-specific requirements.

In other words, Europe is not writing one CRA standard - it is writing an entire stack of standards that will collectively define how CRA compliance is achieved and assessed. With this structure in mind, we can now look at the question every manufacturer is asking: When will these standards actually be available?

That’s the focus of the next chapter - the timeline from 2026 to 2027.

So When Will It Get Concrete? A Realistic Timeline for 2026–2027

Now that we understand how the CRA standards ecosystem is structured, the next question is the one every manufacturer is asking: When will all of this actually materialise?

The answer isn’t a single date, but a sequence - a progression from drafts to near-final texts to fully harmonised standards. Below is the clearest view of what to expect between now and the moment the CRA becomes fully enforceable.

Late 2024 – Beginning of 2026: Visibility Without Finality

This phase is where the groundwork is being laid. Almost all CRA-related standards are in active development, spread across dozens of working groups inside CEN, CENELEC, ETSI and ENISA.

Manufacturers won’t get final standards - but they will get something valuable: early drafts that reveal the direction of travel.

Throughout this period, companies can expect:

• The first committee drafts (CDs) outlining the structure of Type A, Type B and Type C standards

• Consolidation of existing security frameworks (ISO/IEC, ETSI, IEC 62443) into CRA-aligned drafts

• Increasing clarity on how vulnerability handling, secure development, documentation, and lifecycle processes will be interpreted

• Early signals on what category-specific requirements (Type C) might look like

These documents are not yet harmonised and carry no legal weight - but they allow manufacturers to begin aligning internal roadmaps.

2025 was the observation year. You saw the blueprint forming.

2026: The First Tangible Standards - and the First Real Obligations

If 2025 provides visibility, 2026 provides substance. This is the year where CRA standardisation moves from theory to deliverables.

Mid 2026: The First Near-Final Standards

By mid-2026, several key outputs will emerge:

• Consolidated drafts of the horizontal Type A standard

• Consolidated drafts of the cross-cutting Type B standard

• Finalisation steps for the first Type C standards

• A stable text for the vulnerability handling standard

These are the documents manufacturers will begin using as practical guidance.

August 2026: Vulnerability Handling Standard

One of the most consequential standards - defining how to manage, document and remediate vulnerabilities - is scheduled for publication around August. This will become the operational backbone of CRA-aligned PSIRT processes.

September 2026: CRA Obligations Start

This is the first regulatory milestone that directly affects manufacturers:

• Mandatory reporting of actively exploited vulnerabilities

• Mandatory reporting of severe security incidents

The key point: These duties start even if all standards are not final yet.

Late 2026: The First Harmonised Standards May Appear

By the end of 2026, the earliest CRA standards could be published in the Official Journal of the EU.

These may include:

• The first Type C standards for critical product categories

• Select Type B elements (especially vulnerability handling)

• Possibly selected horizontal principles

When published, these standards will finally provide presumption of conformity - the clearest route to fulfilling CRA obligations.

2026 is the transition year where guidance becomes concrete, obligations take effect, and the first harmonised standards begin to surface.

2027: Completion, Harmonisation, Full CRA Applicability

2027 is the year when the CRA framework becomes fully operational - legally and technically.

Early–Mid 2027: Completion of the Standards Stack

By mid-2027, manufacturers can expect:

• The final horizontal Type A standard

• The final cross-cutting Type B standard

• The complete set of Type C standards for critical product categories

At this point, the full architecture of CRA standards should exist in stable, publishable form.

Autumn 2027: Harmonised Standards Enter the Official Journal

Throughout autumn, the Commission is expected to list the completed CRA standards in the Official Journal.

From that moment on, manufacturers gain:

• A recognised pathway to CE-marking

• A defensible technical basis for conformity

• A stable compliance benchmark for engineering and documentation

11 December 2027: Full CRA Applicability

This is the final regulatory milestone.

From this date forward:

• All new products placed on the EU market must comply fully with the CRA

• Market surveillance authorities can enforce non-compliance

• The transitional period ends

2027 is the year everything locks into place.

The Bottom Line of the Timeline

• 2025: Drafts and directional clarity - no final standards

• 2026: First real standards + first obligations

• 2027: Full standards stack + legal enforcement

Manufacturers who wait for complete harmonised standards will find themselves preparing in 2027 - the very year they are expected to already be compliant. 

The Compliance Gap: Obligations Start Before the Standards Exist

The most uncomfortable truth about the CRA is also the simplest: manufacturers must comply before the standards that define compliance are fully available.

The regulation creates a sequencing mismatch that is unusual - even by EU regulatory standards. Legal obligations start on fixed dates, but the technical guidance needed to meet those obligations arrives afterwards or only shortly before the enforcement deadline. This creates a structural gap that every IoT manufacturer needs to understand.

The first obligation arrives in September 2026 - with no full standards stack in place

By autumn 2026, manufacturers must report:

• Actively exploited vulnerabilities, and

• Severe security incidents

Within strict timelines via the EU’s new single reporting platform. An early warning within 24 hours and a vulnerability notification within 72 hours.

These are operational, high-stakes requirements - especially for organisations without mature vulnerability management processes. Yet at that point, only a handful of CRA-related standards will exist, and even fewer will be harmonised.

The CRA’s message is clear: you can’t wait for harmonised standards

For manufacturers, the compliance gap means that waiting is not a viable strategy. The CRA timeline is fixed; the standards timeline is compressed. There is no “safe moment” where everything arrives neatly lined up.

Instead, organisations must:

• Act based on drafts

• Build on established international standards

• Stabilise internal processes proactively

• Design “CRA-ready” product architectures

• Prepare documentation before the rulebook is final

The companies that treat compliance as a moving target - and begin early - will handle the transition smoothly. Those that wait for perfect clarity will hit the 2027 deadline unprepared.

The next chapter explains what manufacturers can do right now, even with the gaps and uncertainties: a practical playbook for building CRA-ready processes before the final standards land.

What Manufacturers Should Do Today (Even Without Final Standards)

If the CRA’s biggest challenge is the timing mismatch between obligations and standards, then the obvious question becomes: What can manufacturers realistically do now?

The answer isn’t “wait for harmonised standards.” It’s the opposite. Early preparation, even in imperfect conditions, is the only strategy that scales into 2027 without panic. What follows is the set of actions that manufacturers can start immediately - actions that remain valid no matter how the final standards evolve.

Start with existing, internationally recognised security standards

Even though the CRA-specific standards are still taking shape, the technical DNA behind them is not mysterious. The committees drafting CRA standards are building on proven frameworks, especially:

• ISO 29147 (vulnerability disclosure)

• ISO 30111 (vulnerability handling processes)

• ETSI EN 303 645 (consumer IoT baseline)

• IEC 62443-4-1 (secure product development lifecycle)

These are not placeholders - they are the actual foundations being used inside the CRA standardisation working groups. Building on them now ensures that your processes will be directionally correct and require minimal adjustment later.

Build or strengthen a Product Security Incident Response Team (PSIRT) - before reporting becomes mandatory

A Product Security Incident Response Team isn’t optional under the CRA. By September 2026, manufacturers must:

• Identify vulnerabilities quickly

• Assess severity

• Document root causes

• Deploy patches

• Notify CSIRTs and ENISA

• Inform users

• Produce corrective measures

And they must do all of this under strict timelines.

Setting up a functioning PSIRT requires people, tooling, processes, documentation flows, and coordinated disclosure mechanisms - none of which can be assembled overnight. Start now, refine later.

Create CRA-ready development and lifecycle processes

Even without harmonised standards, the direction is clear: products must be secure from design through end-of-support.

This includes:

• Embedded vulnerability scanning

• Secure coding practices

• Continuous testing

• SBOM generation and maintenance

• Clear documentation across all lifecycle stages

• Traceability of design decisions and updates

These capabilities take time to mature. Draft standards will refine them, not reinvent them.

Treat Type C product requirements as a future overlay

If you build networking gear, industrial gateways, secure elements, or other Annex III/IV products, your compliance load will be heavier. But you don’t need final Type C standards to start the work.

Focus now on:

• Modular architecture

• Authenticated update mechanisms

• Robust access control models

• Clear separation of trusted components

This makes it far easier to integrate category-specific controls once they are finalised.

Document everything - even if you don’t yet know the final format

The CRA requires extensive documentation for conformity assessment, including:

• Security design decisions

• Vulnerability management processes

• Support periods

• Test coverage

• Update mechanisms

• Risk analyses

• Change history

Start capturing this now.

Documentation can be structured and refined later - but missing documentation cannot be reconstructed easily under pressure.

Think “CRA-ready,” not “CRA-perfect”

A common trap is waiting for the final standards to avoid rework. But in reality, the delta between current best practice and future CRA standards is small. The standards are designed to codify industry norms, not surprise manufacturers with radical new requirements.

The companies that begin preparation early will simply adapt drafts into final standards. The companies that wait will need to scramble.

What Could Still Change: Delegated Acts and Europe’s Emergency Brake

For all the structure the CRA provides, there is one remaining variable manufacturers must keep in view: the possibility that the European Commission steps in to fill gaps if the standards arrive late, fail to align, or don’t cover the essential requirements adequately. This is not the default plan - but it is part of the regulatory architecture. And understanding it matters, because these fallback mechanisms can materially change what compliance looks like.

Delegated Acts: Adjusting the Framework When Needed

The Commission has the power to issue Delegated Acts to modify certain parts of the regulation when new risks emerge or when specific categories of products require clarification.

This could include:

• Adjusting product categorizations in Annex III or IV

• Defining or updating technical descriptions for critical product classes

• Setting minimum support periods for specific product categories

• Refining how certain cybersecurity requirements must be applied

Most manufacturers will never interact with Delegated Acts directly - but they shape the regulatory terrain over time, especially as market conditions evolve. In practice, Delegated Acts function like targeted updates: they don’t rewrite the CRA, but they can sharpen or extend its scope.

Common Specifications: The Commission’s Last-Resort Technical Rulebook

Far more consequential for manufacturers is the Commission’s power to issue Common Specifications (CS) - a kind of emergency technical standard.

The Commission may activate this option if:

• Standardisation bodies miss deadlines,

• The delivered standards don’t fulfil the CRA request, or

• References cannot be published in the Official Journal within a “reasonable” timeframe.

Common Specifications act as temporary harmonised standards, providing presumption of conformity until the official standards arrive.

The implication is significant: manufacturers could be required to comply with Commission-defined technical specifications that bypass the slower consensus-driven standardisation process. While this isn’t the preferred route - the Commission only activates CS when the system fails - the CRA is explicit that Europe must not enter 2027 without a functional compliance pathway.

In other words: if the standards aren’t ready in time, Brussels will not let the system stall. It will step in.

Why This Matters for Manufacturers

Manufacturers don’t need to predict Delegated Acts or Common Specifications - but they do need to design processes that tolerate regulatory fluctuations. The lesson is simple: If you prepare early, align with known international standards, and build CRA-ready processes, you’ll be resilient to whichever path Europe takes.

If you wait, you’re exposed.

The Bottom Line: The CRA Timeline Is Fixed - Your Preparation Can’t Wait

After breaking down the structure, the standards, the timeline, and the gaps, one conclusion becomes impossible to ignore: the CRA is moving on a fixed schedule - and manufacturers don’t have the luxury of waiting for perfect clarity.

The regulation is already in force. The first obligations begin in 2026. Full compliance becomes mandatory in December 2027.

None of this will shift, regardless of how fast the standards progress. Standards will arrive in stages - drafts in 2025, substantial documents and first harmonised standards in 2026, full coverage in 2027. But the regulatory system doesn’t pause to accommodate engineering timelines. By the time the entire standards stack is complete, companies will already be expected to comply.

This is why “waiting for harmonised standards” is the riskiest possible strategy. The organisations that prepare early - that build on existing security frameworks, establish PSIRTs, introduce secure development processes, document their lifecycle decisions, and monitor the evolving drafts - will transition into CRA compliance almost naturally.

Those that wait will face a scramble.

The CRA is not designed as a point-in-time exercise. It is a structural shift in how Europe expects connected products to be built, maintained, supported, and secured. It establishes cybersecurity as a lifecycle obligation - not an optional add-on. The companies that internalise this early will gain more than compliance. They’ll gain predictability, operational maturity, and a competitive advantage in a market where regulatory trust will soon matter just as much as technical capability.

Europe has set the direction. The next two years will determine which manufacturers keep pace - and which fall behind.

Explore our CRA Knowledge Hub for detailed guidance, cross-media resources and updates, or book a free meeting to discuss your regulatory readiness.