CRA in robotics & drones

Why the CRA hits robotics and drone makers right in the middle

Robots and unmanned systems are the textbook example of a "product with digital elements" (PDE): a service robot, an automated guided vehicle or an industrial drone is largely software — perception and navigation stacks, firmware on motor controllers, radio and remote control, over-the-air updates, cloud connectivity for fleet management. It is exactly these products with a direct or indirect data connection that the Cyber Resilience Act (Regulation (EU) 2024/2847) addresses. Unlike the pure machinery world, it is no longer enough that the axis does not move into the operator: the CRA requires the robot to be secured against manipulation, takeover and unpatched vulnerabilities — across the entire support period.

The real pain in this industry is the layering. An AMR maker juggles machine safety (Machinery Regulation (EU) 2023/1230), functional safety (ISO 10218, ISO 13849), radio regulation (RED) and now, on top, product cybersecurity. A drone maker additionally has to watch civil aviation regulation and cleanly separate what falls under EASA type approval (then CRA-exempt) from what, as a consumer or industrial drone, does fall under the CRA. These regimes apply in parallel, not as alternatives — and many manufacturers underestimate that cybersecurity is not an appendix to the existing CE process but a separate chain of evidence with its own documentation, its own vulnerability handling and its own reporting duty.

Add to this the software reality: robotics lives on open source (ROS/ROS 2, countless libraries, ML frameworks), firmware often comes from suppliers, and fleets stay in the field for years. Anyone without a reliable overview of their components and without a defined update and reporting process will only reach the CRA deadlines under pressure. This article frames the situation for your industry — it is technical orientation, not legal advice.

Typical PDE products, likely Annex III class and conformity path

The vast majority of robotics and drone products are likely to fall into the default category — where internal conformity assessment (Module A, self-assessment) applies. A product only becomes "important" in the Annex III sense through one of the listed function classes. For robotics/drones this is usually not a core function of the robot itself but a security-critical sub-component (e.g. a VPN/PKI function in the remote control). The table below is schematic orientation, not a legally binding case-by-case ruling:

Rule of thumb: for the large majority it is Default + Module A. As soon as a component supplied in the product performs an Annex III function (typically class I via VPN/PKI), the path shifts — for class I, self-assessment remains possible only if the relevant harmonised standards are fully applied, otherwise a notified body must be involved. The technical descriptions of the important/critical categories are specified in Implementing Regulation (EU) 2025/2392.

Sector standards and delineation from adjacent regimes

For control security, IEC 62443 is the relevant standards family (security for industrial automation and control systems) — it provides the structure for secure development, hardening and vulnerability handling that the CRA requires at its core. What matters is a clean separation of protection objectives:

• Machinery Regulation (EU) 2023/1230 — functional machine safety (alongside ISO 10218 for industrial robots, ISO 13849 for control systems). It addresses that the machine injures no one; the CRA addresses that the digital elements are not compromised. Both apply in parallel — one does not displace the other.
• Civil aviation / EASA — type-approved aviation is exempt from the CRA. Many consumer and industrial drones, however, do not run via type approval but via the open/specific category and thus fall under the CRA. Clarifying this delineation case by case is the first step.
• RED / radio delegated Regulation 2022/30 — relevant for the radio interface; there are overlaps with CRA cybersecurity requirements that need delineating.
• NIS2 addresses operators of essential/important entities, not the product — a drone service provider may be subject to NIS2, while the drone manufacturer is subject to the CRA. Separate legal acts.
• AI Act — applies to AI components (perception, autonomous navigation) with its own duties; it does not replace the CRA but adds to it.

The CRA case therefore focuses on security-by-design and by-default, hardening and vulnerability handling — functional safety remains a separate, parallel track.

SBOM and supply-chain reality in robotics

Few industries have as deep an open-source stack as robotics. A typical robot combines a real-time/Linux operating system, ROS or ROS 2 as middleware, dozens to hundreds of OSS packages for navigation, perception and image processing, ML libraries, plus supplied firmware on motor, radio and sensor controllers. This is exactly where the risks sit: end-of-life components (such as a ROS distribution past support), transitively introduced vulnerable libraries and firmware blobs from suppliers for which the manufacturer nevertheless has to answer.

The CRA requires a machine-readable SBOM as part of the technical documentation — in CycloneDX version 1.6 or later, or SPDX version 3.0.1 or later (cf. BSI TR-03183-2). It must cover at least the top-level dependencies with components, versions and supplier, and is the basis for knowing within hours whether and which products are affected by a new CVE. There is no general obligation to publish the SBOM — it belongs in the documentation, not necessarily in the datasheet. An industry-specific open question is whether embedded AI models must be included in the SBOM; this has to be decided and documented. And: update capability is mandatory but must not undermine operational and machine safety — security updates must be rolled out so that conformity under the Machinery Regulation remains untouched.

Reporting capability and PSIRT: the Article 14 cascade, correctly

From 11 September 2026 the reporting and notification duty under Art. 14 applies — the first hard manufacturer obligation of all. For robotics and drone makers this means: a working PSIRT process (Product Security Incident Response Team) and a coordinated vulnerability disclosure policy must be in place before the product requirements fully apply. The cascade must be observed precisely:

• 24 hours — early warning from becoming aware of an actively exploited vulnerability or a severe security incident.
• 72 hours — full notification, including the corrective and mitigating measures taken or planned.
• 14 days — final report for an actively exploited vulnerability, counted from the availability of a corrective measure.
• 1 month — final report for a severe security incident, counted from the 72-hour notification.

Reporting runs via the ENISA Single Reporting Platform (SRP), to be made available by the deadline, to the CSIRT of the main establishment and ENISA. The blanket mnemonic "24h/72h/14 days" is wrong: the 14-day deadline applies only to the actively exploited vulnerability; for severe incidents it is one month.

Which deadline counts first: 11 Sept 2026 before 11 Dec 2027

For prioritisation the order is decisive. First, on 11 September 2026, the reporting and notification duty (Art. 14) applies — here the PSIRT/CVD process must be running. Only on 11 December 2027 do the full product requirements (security-by-design, SBOM, technical documentation, EU declaration of conformity, CE) become applicable. So anyone who has to prioritise sets up the reporting process first and builds full product conformity toward the clear 2027 target date. Technical documentation must be kept for ten years after placing on the market; the support period follows the expected lifetime with a guideline of at least five years — a realistic figure for robotics field fleets.

Worked scenario: an AMR manufacturer

A mid-sized maker of autonomous mobile robots (AMRs) for intralogistics ships its vehicles with a ROS 2-based stack, fleet-management software and OTA updates. Schematically played through, this would mean: the affectedness analysis shows the AMR falls under the CRA as a PDE, the core controller sits in the default category (Module A), but the integrated VPN remote maintenance needs checking as a class I candidate. For the SBOM, the ROS 2 stack including transitive OSS and ML dependencies is captured in CycloneDX 1.6 and coupled to the CI pipeline, so every new CVE is automatically matched against the field fleet. The security case (IEC 62443-oriented) is documented cleanly separated from functional safety (ISO 13849/10218, Machinery Regulation). By 11 September 2026 the PSIRT/CVD process is in place; if an actively exploited vulnerability in the remote maintenance becomes known, the 24-hour early warning, 72-hour notification and 14-day final report run via the SRP. Security updates are rolled out so that machine conformity under Reg. 2023/1230 remains untouched. By 11 December 2027 the full technical documentation including the declaration of conformity is complete.

What Blackfort Technology does for you

Blackfort Technology UG (haftungsbeschränkt) supports robotics and drone manufacturers along exactly this chain — practical, close to the manufacturer, and without replacing legal advice:

• Affectedness and scope analysis: which of your products are PDE, what falls under EASA type approval, where Default/Module A applies and where an Annex III class I classification may loom via sub-components.
• SBOM setup: building machine-readable SBOMs (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) for ROS-based stacks, integration into the build pipeline and linkage with vulnerability matching.
• PSIRT & CVD: setting up the reporting process under Art. 14 with the correct cascade (24h/72h/14 days or 1 month) and connection to the SRP.
• Risk assessment & threat modeling: the risk assessment required as documentation under Art. 13 and Annex I, methodically as threat modeling for your robotics/drone architecture.
• Technical documentation: building the documentation to be kept for ten years, separating security and safety evidence, EU declaration of conformity and CE.

The pragmatic entry point is our affectedness check. Smaller manufacturers should look at the SME perspective; the overall framework is explained on the Cyber Resilience Act page. If you would like to discuss your specific situation, reach us via contact.