This is Part 1 of the CRA compliance guide. In this article, we explore the regulatory landscape and practical compliance strategies. For technical implementation details and our complete reference architecture, continue to Part 2: Building CRA-Compliant Connected Products.
The EU Cyber Resilience Act (CRA) transforms cybersecurity from an afterthought into a legal requirement for connected devices. By December 2027, manufacturers must implement secure-by-design products with robust software update mechanisms and device integrity protection. This isn’t just about compliance—it’s about turning the nightmare of insecure IoT devices into a competitive advantage through proven architecture patterns.
What You’ll Learn in This Series
In this two-part series, you’ll discover:
-
The essential CRA facts every technical team needs to know
-
Practical insights helping you accelerate your compliance journey and avoid common pitfalls
-
A step-by-step technical reference architecture for connected devices that addresses all major CRA requirements
-
Implementation guidance with real-world tools and proven solution stacks, and many links for further information
Series Structure
This first part covers: CRA fundamentals, legal requirements, compliance timelines, and strategic planning.
Part 2 dives deep into: technical architecture, implementation patterns, and concrete tooling recommendations.
The Problem: When Default Passwords Meet Critical Infrastructure
A Real Attack That Changed Everything
Picture this: You’re in the shower on a Tuesday morning in Aliquippa, Pennsylvania. Suddenly, the water stops. Not because of a broken pipe or power outage. Iranian hackers halfway around the world hacked a PLC and shut down a pump that provided drinking water to two townships.
This isn’t fiction. It happened in November 2023. How did they get in? Through a Unitronics PLC connected to the internet with its default password. Anyone could find this password in an online manual.
The Scale of the Problem
The same group compromised other PLCs across multiple countries. What’s particularly worrying: the attackers studied each device type to create custom malicious code. They disabled safety functions and implemented techniques to prevent operators from easily regaining control.
Why the CRA Changes Everything
This is the reality the EU Cyber Resilience Act aims to prevent. It recognizes a fundamental truth: in our connected world, the security of a simple device can determine the safety of entire communities. Before the CRA, only the water plant was responsible for ensuring cyber-security. Unitronics would only suffer reputational damage. With the CRA, the responsibility shifts to device manufacturers to deliver secure products from day one.
CRA Essentials and Your Compliance Journey
Let’s start with what the Cyber Resilience Act actually covers, then walk through how a typical compliance journey unfolds.
Understanding the CRA Requirements
Who Does It Affect?
While we’re focusing on connected products in this article, the law actually affects nearly every “product with digital elements.” Think everything that has software—your car’s infotainment system, your coffee machine even your child’s toys. Whether the product connects to a network doesn’t matter. The only exception applies to products like medical devices under MDR that already have comprehensive security regulations in place.
The Core Goal
The goal is pretty straightforward: cybersecurity can’t be an afterthought anymore. It needs to be baked into your products from the very first design meeting all the way through to when you finally shut them down.
The Four Key Obligations
The law brings four concrete obligations:
First: Your products need to be secure “by design and default.” No more shipping devices with “admin/admin” as the default login. Your products should be secure right out of the box, without customers having to figure out how to make them safe.
Second: You need solid processes for handling security vulnerabilities. Here’s the scary part: if hackers are actively exploiting a vulnerability in your products, you’ve got just 24 hours to report it to authorities. And yes, you’re on the hook for all those third-party libraries and components you’re using too.
Third: You need to document everything and prove you’re compliant. If you’re already dealing with CE marking for other regulations, you know the drill. Now cybersecurity joins the party as another requirement you need to check off.
Fourth: You need to provide at least five years of security support for every product you ship. That means patches, updates, and keeping things secure for half a decade after someone buys your device.
Timelines and Stakes
The timeline: The clock is already ticking—the law entered into force on December 10, 2024. Vulnerability reporting requirements become mandatory on September 11, 2026. Full compliance is required by December 11, 2027.
The stakes: Non-compliance carries severe financial penalties—up to €15 million or 2.5% of global annual turnover, whichever is higher. For large manufacturers, this could mean hundreds of millions in fines.
The Practical Implementation Journey
Here’s how a typical compliance journey unfolds: From the initial gap analysis to documented compliance.
Step 1: Gap Analysis and Product Strategy
Product Classification and ROI Analysis
You’ll start with product classification—basically making a list of everything you sell and figuring out where each product fits in the CRA’s categories. An important decision that could save you months of effort: Which products are worth making CRA-compliant, and which ones should you just phase out? In our experience, customers sitting on inventory of older products often underestimate the compliance cost. Recommendation: Run a quick ROI analysis—if compliance costs exceed the remaining product revenue, phase it out. And don’t forget to sell your stock before December 2027, or you’ll be forced to dispose of it.
Creating Security Documentation
The CRA compliance entails documenting everything about your product’s security. Start creating a “security biography” for each product, capturing design decisions, security features and processes, test results, etc. When you have assessed your status quo, you have all the information needed to process with the gap analysis and risk assessment.
Step 2: Implementation and Team Alignment
Training and Organizational Alignment
Most organizations kick off this phase with training sessions to get everyone on the same page. Your software and product development teams need to understand not just what cybersecurity is, but why it matters for their daily work.
Security Implementation Strategy
At the same time, you’ll be implementing or refining your vulnerability management processes. And of course, based on your risk analysis, you’ll need to actually improve your products’ security.
Don’t forget: perfect security doesn’t exist. You need to figure out what’s “good enough” based on the intended use of your product. A smart doorbell doesn’t need the same security as a power plant controller.
Leveraging Related Standards
Since the CRA as legal text leaves much room for interpretation, here are related laws and standards that we encounter regularly at Cumulocity:
Radio Equipment Directive (RED)
The Radio Equipment Directive Delegated Act became mandatory in August 1, 2025 for all connected devices. If you’re already RED-compliant, you’ve already handled most CRA product security requirements. Use your existing RED documentation as your CRA starting point — the EN 18031 standard can be mapped to many CRA obligations.
IEC 62443
Many of our customers target IEC 62443-4, the industrial automation security standard. Strategic advantage: IEC 62443-4 also covers vulnerability management requirements, missing mainly SBOM maintenance and authority reporting. Plus, your industrial customers often ask for this certification anyway—so you’re solving compliance and winning business simultaneously.
TR-03183
The German BSI created TR-03183, a technical guideline for CRA implementation. Implementation tip: Even if you’re not in Germany, this document provides the most concrete interpretation of CRA requirements we’ve seen. Use it as your implementation checklist—it saves weeks of legal interpretation.
For a more detailed requirement mapping you can have a look at this ENISA report that maps the CRA requirements against existing cybersecurity standards.
Step 3: Conformity Assessment
Assessment Process
The final phase is the conformity assessment, proving you’ve done everything right. Good news: In most cases, depending on the criticality of your product, you don’t need an external auditor and it is sufficient to establish an internal control procedure.
Implementation Challenges
One challenge that we see for very complex equipment: The assembly and configuration can take an entire year. Make sure you deliver any product that is not CRA-compliant before the compliance deadline passes!
What we also observe: Implementation time scales with organizational complexity, not just technical complexity. Small companies typically need much less time as compared to large enterprises due to coordination overhead.
The Technical Requirements
With the compliance framework clear, the next challenge becomes obvious: How do you actually implement these requirements in your products and processes?
The gap between “we need to be CRA compliant” and “our products are demonstrably secure with proper vulnerability management” is where most organizations struggle. It’s one thing to understand that you need secure-by-design products and vulnerability handling processes—it’s quite another to build the technical infrastructure that makes it happen.
CRA Compliance is a Cross-Organizational Effort
CRA implementation isn’t a solo mission. You’ll need coordinated effort across multiple teams, each tackling different pieces of the puzzle.
Team Responsibilities
Governance & Compliance Teams
They handle the overarching layer—product classification, risk assessments, documentation, and proving compliance to authorities. They co-ordinate the compliance effort and need to ensure everything gets properly documented.
Software Engineering and R&D Teams
Software Engineering and R&D teams build the technical foundation—the actual systems and processes for vulnerability detection, tracking, and remediation. They’re responsible for creating the infrastructure that makes ongoing security management possible.
Product Development Teams
They implement security directly into products—secure configurations, update mechanisms, integrity protection, and all the day-to-day security features that customers actually interact with.
The Technical Requirements You Need to Implement
To understand what these teams need to build, let’s examine the specific technical requirements you’re actually implementing. The CRA’s technical requirements are spelled out in ANNEX I—the CRA actually defines what “secure” means. This is what you’ll be measured against during your conformity assessment.
ANNEX I Requirements Overview
ANNEX I breaks down into two parts:
PART I: Product Security Requirements (what your devices must do):
-
(P-1) Ensure appropriate cybersecurity based on risk
-
(P-2a) No known exploitable vulnerabilities at market release
-
(P-2b) Secure by default configuration + reset capability
-
(P-2c) Vulnerabilities addressable via timely security updates (default automatic, with opt-out)
-
(P-2d) Protection from unauthorized access
-
(P-2e) Confidentiality of data at rest & in transit
-
(P-2f) Integrity of data & logic + corruption reporting
-
(P-2g) Data minimization
-
(P-2h) Availability of essential functions (even when under attack)
-
(P-2i) Minimize negative impact on other devices or networks
-
(P-2j) Limit attack surfaces
-
(P-2k) Reduce incident impact with exploitation mitigation
-
(P-2l) Record & monitor security activity (with opt-out)
-
(P-2m) Data removal & safe transfer
PART II: Vulnerability Management Requirements (what your processes must do):
-
(VH-1) Maintain SBOM & document vulnerabilities
-
(VH-2) Remediate vulnerabilities promptly
-
(VH-3) Perform regular security testing & reviews
-
(VH-4) Disclose fixed vulnerabilities with clear advisories
-
(VH-5) Enforce coordinated vulnerability disclosure (CVD) policy
-
(VH-6) Provide contact channels for vulnerability reporting
-
(VH-7) Distribute updates securely (preferably automatic)
-
(VH-8) Deliver security updates promptly & free of charge
The whole ANNEX I is only about three pages long—I’d suggest taking a peek at the original text to get a feel for what you’re dealing with.
What’s Next: From Requirements to Architecture
Understanding the CRA requirements is just the beginning. The real challenge lies in translating these regulatory obligations into concrete technical solutions that work in the real world.
In Part 2 of this series, we’ll dive deep into these challenges with a comprehensive reference architecture that addresses every major CRA requirement. You’ll see exactly how to build the four-layer security system that transforms vulnerability management from reactive scrambling into systematic protection.
We’ll also explore real-world implementation options, from open-source tool stacks to commercial platforms, complete with specific recommendations for different use cases and organizational constraints.
Continue to Part 2: Building CRA-Compliant Connected Products to see how leading manufacturers are turning CRA compliance into a competitive advantage through proven architecture patterns.