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

This is the most common question – and there is no blanket answer. The CRA provides for a presumption of conformity: if a product is already covered by sector-specific regulations, these can cover the CRA in full or in part. Whether this applies in a specific case is complex, however, and has to be checked individually. One example is UN R155: for vehicles and their type approval, R155 can cover the CRA – but only under certain conditions, for example if a control unit is certified exclusively as part of the type approval; as soon as it is also supplied to other manufacturers, it needs a CE marking and falls under the CRA. IEC 62443-4-1/-4-2 cover a large part of the technical requirements, while ISO 27001, BSI IT-Grundschutz and NIS-2 concern the company, not the product. Which gap remains and whether an exception applies can, in case of doubt, only be clarified with a legal review – and this is exactly what the readiness check assesses.

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

In many cases, yes. A data connection to another device or network is enough – even locally via Bluetooth, a fieldbus or a service interface. A device without a permanent internet connection is therefore not automatically exempt.

Does the CRA also apply to the backend systems behind the product?

Yes. The CRA covers not only the device itself, but also the remote data processing and backend systems connected to it, insofar as they are necessary for the function or security of the product. Cloud services, update servers or device management platforms therefore also fall within scope – and must be considered in risk analysis, hardening and documentation of evidence.

We buy in software and modules – aren't the suppliers responsible then?

You need more from every supplier than an SBOM, a commitment to the support period and a reporting channel for vulnerabilities: if you as the manufacturer are responsible for a security requirement – such as implemented encryption – you must pass this requirement on to every relevant supplier in a detailed agreement. This belongs in the procurement contracts, and before the component is selected.

Should we wait until the harmonized standards are available?

No. A harmonized standard shifts the burden of justification, not the work on the product. The technical prerequisites – secure update paths, SBOM, fleet overview – have to be created anyway and cannot be retrofitted at short notice.

We don't have our own product security team. Can we still do it?

Yes, in mixed teams. Product security is more than software development – it extends from architecture through the development process to operations. We set up exactly this process from the start so that your own organization can continue it afterwards; we enable your engineers instead of being needed permanently as an external party. MAN Truck & Bus shows that this works: 22 development teams there now follow the secure product development process we built together.

Does the CRA effort bring anything besides compliance?

Yes. The CRA forces manufacturers to build exactly the infrastructure they need for digital services anyway: secure update paths, fleet overview, remote maintenance. Build this foundation right once, and you not only comply with the regulation – you can then maintain and develop your products remotely and monetize them with additional services.

Does MaibornWolff also handle CRA certification?

No – and that is intentional. MaibornWolff is not an accredited testing body, just as TÜV is not one for us: we build the capabilities and create the evidence, while the formal assessment is carried out by the customer or an accredited body. Whoever delivers the implementation should not sign it off themselves. This separation is common practice and a matter of trust, not a shortcoming.

Who clarifies the legal questions around roles, contracts and liability?

MaibornWolff builds the technology and the evidence. For legal questions around the CRA and regulation – such as defining the roles of manufacturer, importer and distributor, drafting contracts with suppliers or liability in the supply chain – we cooperate with the law firm Heuking in Hamburg. We arrange the contact; you commission them directly.

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

CRA consulting

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

From requirements analysis to a compliant connected product – all from a single source

The EU Cyber Resilience Act (CRA) has been EU law since December 2024. The first obligations already apply – the reporting obligation for actively exploited vulnerabilities since September 2026 – and the product requirements must be fully implemented by December 2027. It covers all products with digital elements that can exchange data with a device or network – including their backend systems. For manufacturers, this means security is no longer an optional feature but a legal obligation across the entire product lifecycle. The real challenge rarely lies in understanding the requirements, but in implementing them technically and in your processes – where firmware, update paths, the supply chain and company processes come together.

This is exactly where we come in. MaibornWolff combines regulatory expertise with real engineering depth: we don't just advise you on which obligations apply to your products – we implement them together with you, technically in the device, and in the processes of your company and your product development. This turns CRA compliance from a paper exercise into a maintainable, compliant product.

Less Technology. Better Business.

Schedule a free consultation

Put simply, the obligations fall into four blocks: technical minimum requirements for the product, to be implemented based on risk; process-related cybersecurity requirements – in particular risk analysis, supply chain management, vulnerability management and update processes; information and reporting obligations; and documentation obligations. The manufacturer bears primary responsibility, but some obligations also apply to importers and distributors. The support period is at least five years, but must reflect the expected period of use and is well over ten years for household appliances, industrial equipment or elevators; manufacturers must state it before the product is sold – making it a promised product feature. Violations can be punished with fines of up to EUR 15 million or 2.5% of global annual turnover. The CRA also interlocks with NIS-2 and the AI Act – so a well-designed implementation often covers several requirements at once.

Existing devices are affected too: when retrofitting becomes mandatory

The CRA is not just an issue for new developments. What counts for each individual device is the day it is first placed on the EU market: if this is on or after 11 December 2027, the CRA applies in full – even to a series that has been running unchanged for years, and even to goods already produced and still in stock.

Anyone who substantially modifies a device that has already been delivered places it on the market again in legal terms. Security updates do not trigger this, but a major functional update can. This makes retrofitting security functions a prerequisite for continued market access for many manufacturers – a point that is causing a stir in mechanical and plant engineering and among household appliance manufacturers in particular.

MaibornWolff: your partner for CRA consulting and implementation

Unlike certification bodies or pure compliance consultants, we bring the technical implementation expertise that the CRA essentially demands – and we translate it into the language in which decisions are made internally. Upwards, this means preparing the need for action, timeline and effort so that management and the board can understand and approve the investment. Inwards, it means we speak the language of your hardware engineers as well as that of cloud platforms – and think about compliance from the product's perspective.

Consulting + implementation

We clarify which CRA obligations apply to your products and implement them technically – instead of stopping at an expert report. One point of contact from analysis to compliant device.

Security by Design

We build security into architecture and development processes from the start, not as an afterthought. This is an effective lever across the entire lifecycle and reduces maintenance and retrofitting costs in the long term.

Engineering depth

OTA update architectures, secure update paths, hardened architecture, vulnerability and reporting processes: we have built these components in real product fleets, not just designed them, and have more than 10 years of IoT experience.

Technology-agnostic

We have no platform product of our own and recommend, based on risk, the solution that fits your requirements, your existing architecture and the protection needs of your product – vendor-independent, honestly evaluated and thus geared towards CRA compliance.

1. CRA readiness check and impact analysis

First, we work with you to clarify which of your products fall under the CRA and which criticality class they belong to – because this determines which obligations apply and whether a conformity assessment body must be involved. We look not only at the product (firmware, update capability, supply chain), but also at the processes in your company – such as reporting channels and vulnerability management, which are not product-specific but need to be set up once across the company. This gives you a solid basis instead of planning on vague assumptions.

Find out in 2 minutes whether the CRA affects you

Whether you fall under the Cyber Resilience Act as a manufacturer of hardware, software or connected products, and how urgently you need to act, depends on your starting position. Our free online assessment shows you in around two minutes where you stand and what comes next.

To the CRA readiness check

2. Security assessment and vulnerability analysis

In a structured risk analysis (Threat & Risk Assessment), we evaluate your product architecture against the relevant threats and match it with the requirements of the CRA. We prioritize measures by risk and feasibility so that you invest your budget where it has the greatest security and compliance impact – exactly the rationale the CRA also requires for the technical documentation.

3. Security by Design in the development process

Security by Design is first and foremost a process issue: it means addressing security systematically from the design phase onwards instead of retrofitting it later. This is exactly what we offer as a secure software and product development process – built, for example, with MAN Truck & Bus. This process gives rise to the technical foundations that the CRA demands across the entire lifecycle: from secure boot and hardened communication to an updatable architecture that can be maintained in the long term.

One example is crypto agility: a device that goes on the market in 2027 and is meant to run for ten years must be updatable and, if necessary, able to change its signature method – for instance when switching to quantum-safe methods. If memory and update bandwidth are dimensioned without reserves, this switch can no longer be made later. It is only made possible by update capability – and that is one of several technical minimum requirements, not the only one. Which measures a product actually needs is determined by the threat analysis, based on risk.

4. Software bill of materials (SBOM), vulnerability management and reporting processes

We integrate the creation of a machine-readable software bill of materials into your build process and establish continuous vulnerability management including CVE tracking. We also help you map the reporting obligation that applies from September 2026 cleanly in your processes.

The reporting obligation is less a compliance issue than an engineering issue: it has three stages – an early warning within 24 hours, a detailed notification within 72 hours and a final report within 14 days after a fix becomes available. The 24-hour deadline runs in calendar time, not working days. If you learn of an actively exploited vulnerability on a Friday evening, you have to report it on Saturday.

The prerequisite is being able to detect an incident in the first place: you have to notice that a vulnerability is being actively exploited – which requires functioning incident management. For the notification to succeed, three things must be clarified in advance: a designated role, reachable outside business hours, with a mandate to report; a reporting channel for security researchers, customers and your own support, including continuous monitoring of the components used; and device management that can tell you at any time which devices are in the field with which software version. Most manufacturers get stuck on the last point – and this is exactly the capability MaibornWolff helps to build.

5. Secure OTA updates across the lifecycle

The CRA requires security updates over many years. We build the over-the-air update infrastructure this requires, with staging, rollback and fleet analytics – proven in product fleets of more than one million devices. This lets you close vulnerabilities reliably instead of having to send technicians 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 previous 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 rollback path, a failed update can overrun the maintenance window and bring the plant to a standstill. That is exactly why MaibornWolff designs the rollback path into the architecture from the start.

6. Evidence and the path to CE marking

Mechanical and plant engineering – connected machines with long service lives, often requiring retrofits.
Household appliances and consumer IoT – connected mass-market products with app connectivity and OTA capability.
Energy and building technology – PV/storage, charging infrastructure, building automation, in some cases close to NIS-2.
Industrial and safety technology, sensors – connected, partly safety-critical devices.
AgTech and veterinary technology – connected agricultural machinery and devices for the veterinary sector. Unlike medical devices for humans, they are not regulated otherwise and therefore fall directly under the CRA.

Still need to convince people internally? We provide the factual basis to make the need for action clear to management and the board – from the timeline to the effort involved.

A clear sequence has proven itself for implementation: first, the internal line of argument on which the need for action and the effort can be decided. Then the process work at company level – risk analysis, reporting channels, vulnerability and update processes. Building on this, a risk-based evaluation determines which security measures each product actually needs. Only then comes what depends on the hardware and cannot be added later via an update, such as the bootloader, memory layout and key storage. Each step can be commissioned individually, you can exit after any step, and the source code and documentation belong to the customer.

And the effort pays off twice: the CRA forces manufacturers to build exactly the infrastructure they need for digital services anyway. Build it right once, and you not only comply with the regulation – you can then maintain and extend your products remotely and monetize them with additional services.

Your benefit: compliance that is technically sound

Market access secured

Timely CRA compliance secures your access to the EU market and CE marking – without approval risks shortly before the deadline.

Security in the product

Security anchored in architecture, update paths and processes genuinely protects your products throughout their lifecycle, not just on paper.

Predictable costs

A prioritized roadmap makes effort transparent. Setting the right course early avoids costly retrofits and field service calls later.

One partner instead of many

Consulting, engineering and operations from a single source: fewer interfaces, clear responsibility, faster implementation.

Our case studies and projects

MaibornWolff has already implemented what the CRA requires in concrete security projects – from a certifiable secure product development process (Secure SDLC) and threat and risk analyses to platform hardening in the field. The approach targets not just software development but product security as a whole – and enables the customer's teams to continue it on their own.

To all case studies

MAN: Efficient threat analysis for control units

See MAN reference

CybersecurityIoTEmbedded & Robotics

Goal

Protection of digitalized trucks against virtual attacks
See MAN reference

Solution

Risk analysis based on 4x6 methodology, ThreatSea, ISO21434
See MAN reference

Benefit

Quick identification of relevant threats for immediately effective security measures
See MAN reference
Miele domestic appliances are networked worldwide

See Miele reference

CloudIoTEmbedded & Robotics

Goal

Further development of the IoT platform for connected home appliances
See Miele reference

Solution

Container-based architecture, open standards, modular design
See Miele reference

Benefit

Quick availability & scalability of digital services, high added value for users
See Miele reference
MAN: Secure Software Development Life Cycle

See MAN reference

CybersecurityIT ConsultingQuality Engineering

Goal

Protection of digitalized vehicles against virtual attacks & digital threats
See MAN reference

Solution

SSDLC in vehicle backend systems (UNECE R155), cybersecurity management system
See MAN reference

Benefit

Guidelines, methodologies & tools for independent risk identification, assessment & treatment by employees
See MAN reference

Why engineering depth makes the difference with the CRA

Compliance rarely fails for lack of will, but in implementation. According to the MaibornWolff Technology Efficiency Study 2026 (n = 305 IT decision-makers), overly complex software slows down productivity for 61% of respondents. Applied to the CRA, this means: if you only document security requirements but don't translate them properly into architecture and update processes, you create effort without protection. This translation is exactly our core competence.

FAQ: frequently asked questions about the Cyber Resilience Act

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

This is the most common question – and there is no blanket answer. The CRA provides for a presumption of conformity: if a product is already covered by sector-specific regulations, these can cover the CRA in full or in part. Whether this applies in a specific case is complex, however, and has to be checked individually. One example is UN R155: for vehicles and their type approval, R155 can cover the CRA – but only under certain conditions, for example if a control unit is certified exclusively as part of the type approval; as soon as it is also supplied to other manufacturers, it needs a CE marking and falls under the CRA. IEC 62443-4-1/-4-2 cover a large part of the technical requirements, while ISO 27001, BSI IT-Grundschutz and NIS-2 concern the company, not the product. Which gap remains and whether an exception applies can, in case of doubt, only be clarified with a legal review – and this is exactly what the readiness check assesses.
Does the CRA also apply to products that are not connected to the internet?

In many cases, yes. A data connection to another device or network is enough – even locally via Bluetooth, a fieldbus or a service interface. A device without a permanent internet connection is therefore not automatically exempt.
Does the CRA also apply to the backend systems behind the product?

Yes. The CRA covers not only the device itself, but also the remote data processing and backend systems connected to it, insofar as they are necessary for the function or security of the product. Cloud services, update servers or device management platforms therefore also fall within scope – and must be considered in risk analysis, hardening and documentation of evidence.
We buy in software and modules – aren't the suppliers responsible then?

You need more from every supplier than an SBOM, a commitment to the support period and a reporting channel for vulnerabilities: if you as the manufacturer are responsible for a security requirement – such as implemented encryption – you must pass this requirement on to every relevant supplier in a detailed agreement. This belongs in the procurement contracts, and before the component is selected.
Should we wait until the harmonized standards are available?

No. A harmonized standard shifts the burden of justification, not the work on the product. The technical prerequisites – secure update paths, SBOM, fleet overview – have to be created anyway and cannot be retrofitted at short notice.
We don't have our own product security team. Can we still do it?

Yes, in mixed teams. Product security is more than software development – it extends from architecture through the development process to operations. We set up exactly this process from the start so that your own organization can continue it afterwards; we enable your engineers instead of being needed permanently as an external party. MAN Truck & Bus shows that this works: 22 development teams there now follow the secure product development process we built together.
Does the CRA effort bring anything besides compliance?

Yes. The CRA forces manufacturers to build exactly the infrastructure they need for digital services anyway: secure update paths, fleet overview, remote maintenance. Build this foundation right once, and you not only comply with the regulation – you can then maintain and develop your products remotely and monetize them with additional services.
Does MaibornWolff also handle CRA certification?

No – and that is intentional. MaibornWolff is not an accredited testing body, just as TÜV is not one for us: we build the capabilities and create the evidence, while the formal assessment is carried out by the customer or an accredited body. Whoever delivers the implementation should not sign it off themselves. This separation is common practice and a matter of trust, not a shortcoming.
Who clarifies the legal questions around roles, contracts and liability?

MaibornWolff builds the technology and the evidence. For legal questions around the CRA and regulation – such as defining the roles of manufacturer, importer and distributor, drafting contracts with suppliers or liability in the supply chain – we cooperate with the law firm Heuking in Hamburg. We arrange the contact; you commission them directly.