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. Alongside machine safety, 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 aviation regulation: exempt from the CRA are products certified under Regulation (EU) 2018/1139 (Article 2(3)). These regimes apply side by side - and cybersecurity forms a separate chain of evidence within them 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 may come from suppliers, and fleets stay in the field for years. A reliable overview of your own components and a defined update and reporting process are therefore the basis for meeting the CRA deadlines. 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

Robotics and drone products without an Annex III core function 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 if its core function corresponds to one of the listed categories (Article 7(1)). A built-in component with an Annex III function does not, by itself, raise the robot's classification (Article 7(1), second sentence). The table below is schematic orientation, not a legally binding case-by-case ruling:

Rule of thumb: without an Annex III core function it is Default + Module A. An embedded VPN or PKI component does not raise the robot's classification; class I only becomes relevant if you place such a component, for example a remote-maintenance box or software with a VPN function, on the market as a product of its own. For such a class I product, self-assessment remains possible only if harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”) are fully applied, otherwise a notified body must be involved (Module B+C or H). 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 (alongside ISO 10218 for industrial robots, ISO 13849 for control systems): it governs machinery safety, including protection against corruption and the safety of control systems (Annex III sections 1.1.9 and 1.2.1); the CRA governs the cybersecurity of the digital elements. Both apply side by side; CRA evidence can help meet those requirements (recital 53).
• Aviation / EASA - exempt are products certified under Regulation (EU) 2018/1139 (Article 2(3)). Whether this also covers class-marked drones in the open category is a question of interpretation to be settled case by case. Clarifying this delineation is the first step.
• RED / radio delegated Regulation 2022/30: relevant for radio interfaces through which the device communicates with the internet; until it is repealed with effect from 11 Dec 2027 there are overlaps with CRA cybersecurity requirements that need delineating.
• NIS2 addresses essential and important entities, not the product - a drone service provider may be subject to NIS2, while the drone manufacturer is subject to the CRA. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. Separate legal acts.
• AI Act - applies in addition to the CRA as soon as an AI system is built in (perception, autonomous navigation); the scope of duties depends on the risk level.

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

Robotics builds on a deep open-source stack. 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 software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. With components, versions and supplier, the SBOM 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

Since 11 September 2026 the reporting and notification duty under Art. 14 has applied, 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 already be in place now, well before the product requirements fully apply. The cascade must be observed precisely:

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
• 14 days - final report for an actively exploited vulnerability, counted from the availability of a corrective or mitigating measure.
• 1 month - final report for a severe incident, counted from the 72-hour notification.

Reporting runs via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to 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 counts. First, on 11 September 2026, the reporting and notification duty (Art. 14) began to apply; since then 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 retained for at least ten years after placing on the market or for the longer support period (Article 13(13)); the support period follows the expected period of use, as a rule at least five years, shorter only where the expected period of use is shorter (Article 13(8)) - 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 and sits in the default category (Module A). The integrated VPN remote maintenance does not raise the AMR's classification; if the maker also sells the remote-maintenance box separately as a product of its own, that box must be assessed as a class I product (Annex III No. 5). 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). Since 11 September 2026 the PSIRT/CVD process must be in place; if an actively exploited vulnerability in the remote maintenance becomes known, the early warning (without undue delay, within 24 hours at the latest), the notification (within 72 hours at the latest) and the 14-day final report run via the single reporting platform. 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 supports robotics and drone manufacturers along exactly this chain - practical, close to the manufacturer, and without replacing legal advice:

• Affectedness and scope analysis: a technical assessment of which of your products are PDE, where the aviation exemption may apply, where Default/Module A applies and which separately sold components fall under Annex III class I.
• SBOM setup: building machine-readable SBOMs, for example in CycloneDX or SPDX, 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 (early warning, notification, final report after 14 days or 1 month) and connection to the single reporting platform.
• 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 under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)), with security and safety evidence kept separate.

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.