We are already certified to IEC 62443, UN R155, EN 303 645, or ISO 27001—is that enough for the CRA?

That’s the most common question—and the answer is a clear “yes and no.” Existing certifications cover certain aspects, but none cover everything: R155 and R156 largely cover the process side, IEC 62443-4-1 and -4-2 cover a large portion of the technical requirements, and EN 303 645 provides the baseline for consumer IoT. ISO 27001, on the other hand, pertains to the organization, not the product, and contributes little to a device’s CRA compliance. The Readiness Check clarifies which gaps remain in a specific case.

Does the CRA also apply to products that are not connected to the Internet?

In many cases, yes. All that’s needed is a data connection to another device or network—even locally via Bluetooth, a fieldbus, or a service interface. So a device without a permanent Internet connection isn’t automatically left out.

We purchase software and modules—so aren't the suppliers responsible?

The manufacturer remains responsible for the product that bears its own name. In practice, this means that every supplier must provide an SBOM, a commitment regarding the support period, and a reporting channel for vulnerabilities. These requirements must be included in the procurement contracts—and they must be in place before the component is selected.

Should we wait until the harmonized standards are available?

No. A harmonized standard shifts the burden of proof, not the work involved in developing the product. The technical requirements—secure update channels, SBOM, fleet overview—must be established in any case and cannot be implemented on short notice.

We don't have our own product safety team. Will that still work?

Yes, in mixed teams. Since the process must subsequently run at the customer’s site, it is designed from the outset so that the customer’s own organization can carry it out independently. MAN Truck & Bus is proof that this approach works: Today, 22 development teams there follow the Secure-SDLC that was developed collaboratively.

Does the effort involved in CRA offer any benefits beyond compliance?

Yes. The CRA requires manufacturers to implement exactly the infrastructure they need for digital services anyway: secure update channels, fleet overview, and remote maintenance capabilities. Once this foundation is properly established, manufacturers not only comply with the regulation but can also remotely maintain and further develop their products and monetize them through additional services.

Does MaibornWolff also handle CRA certification?

No—and that’s by design. MaibornWolff develops the capabilities and prepares the documentation; the assessment is conducted by the customer or a designated body. Whoever delivers the implementation should not be the one to approve it. This separation is standard practice and a sign of trust, not a shortcoming.

Who addresses the legal issues surrounding roles, contracts, and liability?

MaibornWolff develops the technology and prepares the documentation. For legal issues related to CRA and regulatory matters—such as defining the roles of manufacturers, importers, and distributors; drafting contracts with suppliers; or liability within the supply chain—the company collaborates with the law firm Heuking in Hamburg. We facilitate the initial contact, but you engage their services directly.

A person in uniform is holding a stamp at a counter; in front of it are a washing machine, a robotic arm, a charging station, and a tractor, all bathed in blue and red light

CRA Consulting

Comply with the Cyber Resilience Act and implement it technically in the product

From requirements analysis to a compliant, networked product—all from a single source

The EU Cyber Resilience Act (CRA) will make cybersecurity mandatory for all connected products with digital components starting in December 2027. For manufacturers, this means that security will go from being an optional feature to a legal requirement throughout the entire product lifecycle. The real challenge rarely lies in understanding the requirements, but rather in their technical implementation within the device—where firmware, update pathways, and the supply chain converge.

This is exactly where we come in. MaibornWolff combines regulatory expertise with deep engineering know-how: We don’t just advise you on which obligations apply to your products; we work with you to implement them technically—from Security by Design (SBOM) to secure over-the-air updates. This way, CRA compliance becomes not just a paperwork process, but a maintainable, compliant product.

Less Technology. Better Business.

Schedule a free consultation

The core obligations for manufacturers include “security by design,” vulnerability management throughout the entire support period, a machine-readable SBOM, mandatory reporting, and CE marking of compliant products. The support period is at least five years—but must correspond to the expected useful life and, in the case of household appliances, industrial equipment, or elevators, is significantly longer than ten years. Manufacturers must specify this period before the product is sold; it thus becomes a promised product characteristic. Violations can be penalized with fines of up to 15 million euros or 2.5% of global annual revenue. The CRA also interacts with NIS-2, the Radio Equipment Directive (RED), and the AI Act—a well-thought-out implementation therefore often covers multiple requirements at once.

Existing Equipment Is Also Affected: When Retrofitting Becomes Mandatory

The CRA is not just an issue for new products. The decisive factor for each individual device is the date on which it first enters the EU market: If this date is December 11, 2027, or later, the CRA applies in full—even for a product line that has been in production unchanged for years, and even for goods that have already been produced and are still in inventory.

Anyone who makes a significant modification to a device that has already been delivered is, for legal purposes, placing it on the market anew. Security updates do not trigger this, but a major functional update can. As a result, retrofitting security features is becoming a prerequisite for continued market access for many manufacturers—an issue that is causing quite a stir, particularly in the machinery and plant engineering sectors as well as among home appliance manufacturers.

Consulting + Implementation

We determine which CRA requirements apply to your products and implement them technically—rather than simply providing an expert opinion. A single point of contact from analysis through to a compliant device.

Security by Design

We embed security into the architecture and development process from the very beginning, not as an afterthought. This meets the CRA’s core requirement and reduces long-term maintenance and retrofitting costs.

Level of Engineering Expertise

OTA update architectures, Secure Boot, SBOM in the CI/CD pipeline: We’ve built these components into real-world product fleets—not just designed them—with over 10 years of IoT experience.

Technology-independent

We do not have our own platform product and recommend the solution that best fits your needs and existing architecture—based on a vendor-neutral and honest evaluation.

1. CRA Readiness Check and Impact Analysis

First, we’ll work with you to determine which of your products fall under the CRA and which risk class they belong to. We’ll assess the current status of your firmware, update capabilities, and supply chain, and pinpoint exactly where action is needed. This gives you a solid foundation for planning, rather than relying on guesswork.

Determine Your CRA Status in 2 Minutes

Whether you, as a manufacturer of hardware, software, or connected products, are subject to the Cyber Resilience Act—and how urgent the need for action is—depends on your current situation. Our free online assessment shows you in about two minutes where you stand and what your next steps should be.

Go to the CRA Readiness Check

2. Security Assessment and Vulnerability Analysis

3. Security by Design in Product Architecture

We embed security where it belongs: in the architecture. From Secure Boot to hardened communications to crypto-agile update signing (keyword: post-quantum readiness), we design the technical foundations required by the CRA throughout the entire lifecycle.

Crypto-agility clearly demonstrates why this matters: The BSI has set the deadline for migration to quantum-secure methods at 2030 for operators of critical infrastructure and 2032 for everyone else. A device that enters the market in 2027 and is expected to operate for ten years must be capable of both—being updated and switching signature schemes in the process. The new schemes use significantly larger keys. Anyone who designs storage and update bandwidth without a margin will not be able to make this switch later—an argument that a pure certifier does not provide.

4. SBOM, Vulnerability Management, and Reporting Processes

We integrate the creation of a machine-readable software bill of materials into your build process and establish a continuous vulnerability management system, including CVE tracking. In addition, we help you implement the reporting requirement—which takes effect in September 2026—in a well-structured manner.

The reporting requirement is less a compliance issue than an engineering one: it consists of three stages—an early warning within 24 hours, a detailed report within 72 hours, and a final report within 14 days after a solution becomes available. The 24-hour deadline is calculated in calendar days, not business days. Anyone who learns of an actively exploited vulnerability on a Friday evening must report it on Saturday.

To ensure this happens, three things must be clarified in advance: a designated role—accessible even outside business hours—with the authority to report; a reporting channel for security researchers, customers, and the company’s own support team, including ongoing monitoring of the deployed components; and a device management system that can at any time identify which devices are in the field and at what software version. Most manufacturers struggle with this last point—and it is precisely this capability that MaibornWolff is building upon.

5. Secure OTA Updates Throughout the Product Lifecycle

The CRA requires security updates for years. We build the necessary over-the-air update infrastructure—including staging, rollback, and fleet analytics—which has been proven effective in product fleets with over a million devices. This allows you to reliably patch vulnerabilities without having to send technicians out into the field.

Whether an update path can be retrofitted at all depends on three things: free flash memory for a second firmware image, a bootloader that allows a rollback to the old version, and a way for the update to reach the device even if it is rarely online. This also explains why security updates are often not installed in practice: Without a fallback path, a failed update can exceed the maintenance window and shut down the system. That’s exactly why MaibornWolff incorporates the fallback path into the architecture from the very beginning.

6. Documentation and the Process for Obtaining CE Marking

Machinery and Plant Engineering — networked machines with a long service life, often requiring retrofitting.
Home Appliances and Consumer IoT — connected mass-market products with app integration and OTA capability.
Energy and Building Technology — PV/Storage, Charging Infrastructure, Building Automation, some of which are related to NIS-2.
Industrial and safety technology, sensor technology — networked devices, some of which are safety-critical.
AgTech and veterinary technology — connected agricultural machinery and equipment for the veterinary sector. Unlike medical devices intended for human use, they are not regulated under any other framework and therefore fall directly under the CRA.

Still need to win over internal stakeholders? We provide the factual basis you need to clearly demonstrate the need for action to management and the board—from the timeline to the effort involved.

There’s a clear order for implementation: First come the elements tied to the hardware that can’t be updated later—bootloaders, memory layout, and key storage. Next come the SBOM and fleet overview, because vulnerability assessment and reporting deadlines depend on them. Documentation comes last, as it results from the measures taken previously. Each step can be commissioned individually; it’s possible to opt out after any step, and both the source code and documentation belong to the customer.

And the investment pays off twice: The CRA compels manufacturers to adopt exactly the infrastructure they need for digital services anyway. Once built correctly, this infrastructure not only complies with the regulation but also allows manufacturers to remotely maintain and expand their products and monetize them through additional services.

Your Benefits: Compliance That Holds Up Technically

Market Access Secured

By ensuring timely CRA compliance, you secure access to the EU market and the CE marking—without the risk of non-approval just before the deadline.

Product Safety

Security by Design, SBOM, and secure updates truly protect your products throughout their entire lifecycle—not just on paper.

Predictable Costs

A prioritized roadmap makes costs transparent. Setting the course early on helps avoid costly retrofits and field deployments later on.

One partner instead of many

Consulting, engineering, and operations all from a single source: fewer points of contact, clear accountability, and faster implementation.

Why In-Depth Engineering at CRA Makes the Difference

Compliance rarely fails due to a lack of will, but rather due to implementation issues. According to the MaibornWolff Technology Efficiency Study 2026 (n = 305 IT managers), overly complex software hinders productivity for 61% of respondents. Applied to the CRA, this means: Those who merely document security requirements but fail to properly integrate them into architecture and update processes end up creating extra work without providing any protection. It is precisely this integration that is our core competency.

FAQ: Frequently Asked Questions About the Cyber Resilience Act

We are already certified to IEC 62443, UN R155, EN 303 645, or ISO 27001—is that enough for the CRA?

That’s the most common question—and the answer is a clear “yes and no.” Existing certifications cover certain aspects, but none cover everything: R155 and R156 largely cover the process side, IEC 62443-4-1 and -4-2 cover a large portion of the technical requirements, and EN 303 645 provides the baseline for consumer IoT. ISO 27001, on the other hand, pertains to the organization, not the product, and contributes little to a device’s CRA compliance. The Readiness Check clarifies which gaps remain in a specific case.
Does the CRA also apply to products that are not connected to the Internet?

In many cases, yes. All that’s needed is a data connection to another device or network—even locally via Bluetooth, a fieldbus, or a service interface. So a device without a permanent Internet connection isn’t automatically left out.
We purchase software and modules—so aren't the suppliers responsible?

The manufacturer remains responsible for the product that bears its own name. In practice, this means that every supplier must provide an SBOM, a commitment regarding the support period, and a reporting channel for vulnerabilities. These requirements must be included in the procurement contracts—and they must be in place before the component is selected.
Should we wait until the harmonized standards are available?

No. A harmonized standard shifts the burden of proof, not the work involved in developing the product. The technical requirements—secure update channels, SBOM, fleet overview—must be established in any case and cannot be implemented on short notice.
We don't have our own product safety team. Will that still work?

Yes, in mixed teams. Since the process must subsequently run at the customer’s site, it is designed from the outset so that the customer’s own organization can carry it out independently. MAN Truck & Bus is proof that this approach works: Today, 22 development teams there follow the Secure-SDLC that was developed collaboratively.
Does the effort involved in CRA offer any benefits beyond compliance?

Yes. The CRA requires manufacturers to implement exactly the infrastructure they need for digital services anyway: secure update channels, fleet overview, and remote maintenance capabilities. Once this foundation is properly established, manufacturers not only comply with the regulation but can also remotely maintain and further develop their products and monetize them through additional services.
Does MaibornWolff also handle CRA certification?

No—and that’s by design. MaibornWolff develops the capabilities and prepares the documentation; the assessment is conducted by the customer or a designated body. Whoever delivers the implementation should not be the one to approve it. This separation is standard practice and a sign of trust, not a shortcoming.
Who addresses the legal issues surrounding roles, contracts, and liability?

MaibornWolff develops the technology and prepares the documentation. For legal issues related to CRA and regulatory matters—such as defining the roles of manufacturers, importers, and distributors; drafting contracts with suppliers; or liability within the supply chain—the company collaborates with the law firm Heuking in Hamburg. We facilitate the initial contact, but you engage their services directly.