Autonomous Drones in the EU — Part I: Where Aviation Certification Ends and Product Regulation Begins

Complex law. Clear action.

Reviewed by Oleksandr Sobovyi, Founder & CEO of CORVUS AI — editorial responsibility statement below.

Autonomous unmanned aircraft are moving faster than the regulatory architecture built around them.

A modern drone may combine a flight-control computer, embedded operating system, communications stack, navigation software, neural-network inference, ground-control software, cloud-based mission management and over-the-air software or model updates. From an engineering perspective, this may be one integrated system. From an EU regulatory perspective, however, it may be several legally distinct products, components and regulated functions.

That distinction matters.

The EU Cyber Resilience Act (“CRA”), Regulation (EU) 2024/2847, introduces horizontal cybersecurity requirements for connected hardware and software. At the same time, unmanned aircraft are already subject to a specialised aviation framework under Regulation (EU) 2018/1139, Implementing Regulation (EU) 2019/947 and Delegated Regulation (EU) 2019/945.

The result is not a complete legal vacuum. It is a regulatory perimeter problem.

Before an autonomous UAS manufacturer can determine what cybersecurity assurance, conformity assessment or technical documentation is required, it may first need to answer a more fundamental question:

Which part of the system is regulated under which EU regime?

For developers of autonomous or highly automated drones, particularly those entering the EU market from outside the Union, answering that question early may become as important as the engineering itself.

Executive Summary

Five regulatory boundaries should be identified before an autonomous UAS enters the EU market.

1. Trade boundary

Can the UAS, software and related technology legally cross the relevant border, and under what military or dual-use export-control classification?

2. Product boundary

Where does the autonomous UAS end and the surrounding digital ecosystem begin?

Aviation certification of an aircraft does not automatically determine the regulatory treatment of ground-control software, cloud services, update infrastructure or separately marketed digital components.

3. Certification boundary

Which products have actually been certified under Regulation (EU) 2018/1139?

Article 2(3) CRA excludes products with digital elements that have been certified under that aviation framework. Design verification, SORA-based operational authorisation and other forms of regulatory assurance should not automatically be treated as equivalent to certification for this purpose.

4. AI and data boundary

AI Act classification may arise through more than one route.

An AI system used as a safety component of a regulated product may fall within Article 6(1). Separately, AI systems intended for biometric identification can fall within the Annex III high-risk categories through Article 6(2), independently of the aviation-product route.

Where computer vision or other sensors process information relating to identifiable individuals, GDPR may also apply.

5. Assurance and liability boundary

The same technical evidence may need to support aviation safety, CRA cybersecurity, AI Act compliance, data governance and subsequent liability defence.

The regulatory objective should therefore be to build one coherent evidence architecture rather than separate compliance files developed after the product has already been designed.

Regulatory perimeter at a glance

1. The CRA does not “certify drones”

The CRA is not an aviation certification regulation. It establishes horizontal cybersecurity requirements for products with digital elements made available on the EU market where their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

A “product with digital elements” can include both software and hardware, as well as remote data-processing solutions and software or hardware components placed on the market separately.

For a connected drone ecosystem, that definition can potentially capture a substantial part of the technical stack:

• flight-control computers;

• embedded software;

• operating systems;

• communications modules;

• navigation software;

• ground-control applications;

• update-management software;

• independently marketed software components;

• and, in some circumstances, cloud functionality.

There is, however, a major aviation-specific limitation.

Article 2(3) CRA provides that the Regulation does not apply to products with digital elements that have been certified in accordance with Regulation (EU) 2018/1139, the EU Basic Aviation Regulation.

That exclusion fundamentally changes the analysis for UAS.

The relevant sequence is:

1. what is the relevant product or component;

2. is that product within the CRA definition of a product with digital elements;

3. is it subject to certification under the EU aviation framework;

4. has it been certified in accordance with Regulation 2018/1139;

5. if so, does Article 2(3) CRA remove that product from the CRA;

6. and what happens to connected components or services that remain outside the aviation certificate?

That is where the regulatory boundary begins.

2. A UAS is not necessarily one regulatory object

Under Delegated Regulation 2019/945, an unmanned aircraft system consists of the unmanned aircraft and its control and monitoring unit. The Regulation separately recognises equipment used to control an unmanned aircraft remotely, including software necessary for safe operation.

The architecture of an autonomous UAS can extend much further.

Consider a commercially realistic system.

On-board layer

Flight controller
→ embedded operating system
→ navigation engine
→ computer-vision module
→ neural-network inference
→ obstacle avoidance
→ autonomous mission replanning.

Communication layer

Command-and-control link
→ radio modem
→ encryption
→ remote identification
→ satellite or cellular connectivity.

Ground layer

Ground-control station
→ operator interface
→ fleet-management application.

Remote layer

Cloud mission-management system
→ map and geospatial services
→ telemetry storage
→ AI model-management infrastructure
→ update servers.

Lifecycle layer

Firmware update system
→ software dependency management
→ vulnerability-management process
→ AI-model update pipeline.

An aviation approval may not cover every element of that architecture in exactly the same manner.

The certification boundary and the CRA product boundary may not be identical.

A manufacturer cannot safely assume that because the drone is subject to aviation regulation, every software service connected to it falls outside the CRA.

Nor should every connected component automatically be treated as independently subject to CRA conformity assessment.

The perimeter must be mapped.

3. Cloud functionality can become part of the regulated product

The CRA extends beyond software installed physically on a device.

Its definition of a product with digital elements includes certain remote data-processing solutions. These are remote-processing functions designed and developed by, or under the responsibility of, the manufacturer where their absence would prevent the product from performing one of its functions.

For autonomous UAS this is highly relevant.

Suppose a drone relies upon a manufacturer-controlled platform for:

• mission authorisation;

• route generation;

• geofencing;

• AI inference;

• fleet coordination;

• cryptographic authentication;

• safety-critical map updates;

• or autonomous mission replanning.

The legal question becomes whether the drone can perform the relevant function in the absence of that remote-processing solution.

If not, the cloud component may form part of the CRA regulatory perimeter unless another exclusion applies.

“Edge-to-cloud cybersecurity” is therefore not a formal CRA category, but it describes a genuine compliance problem.

The manufacturer must identify where the regulated product ends.

4. Aviation law remains the first classification layer

For UAS, the CRA analysis should not be conducted independently from aviation law.

Regulation 2018/1139 establishes the EU's fundamental aviation safety framework and covers unmanned aircraft, their design, production, maintenance, operation, parts, equipment and remote-control equipment.

The operational framework distinguishes between three principal categories:

• open;

• specific;

• certified.

Under Implementing Regulation 2019/947, open-category operations are limited, among other conditions, to unmanned aircraft with an MTOM below 25 kg. Operations in the specific category normally require operational authorisation or operate under one of the recognised declarative mechanisms. Certified-category operations require certification of the UAS and the operator and, where applicable, licensing of the remote pilot.

The fact that a UAS is large, autonomous, commercially operated or technically sophisticated does not by itself establish whether the CRA applies.

The relevant issue is its precise aviation regulatory route.

5. “Heavy drone” is not itself a legal certification category

Commercial discussions often refer to “heavy drones”.

EU law does not use that expression as a standalone certification category.

Weight is highly relevant — particularly because the open category is limited to UAS below 25 kg — but mass is only one part of the regulatory analysis.

Under the current Article 40 framework of Delegated Regulation 2019/945, certification is required, among other situations, where the UAS:

• has a characteristic dimension of at least three metres and is designed to operate over assemblies of people;

• is designed to transport people;

• is designed to transport dangerous goods requiring a high degree of robustness;

• or is intended for operations in the specific category and the competent authority determines that the operational risk cannot adequately be mitigated without UAS certification.

The competent authority can therefore move an operation towards certification because of risk, not simply because a numerical weight threshold has been crossed.

This matters for autonomous cargo drones, BVLOS platforms, infrastructure-inspection aircraft and logistics UAS.

6. The “specific” category is not legally equivalent to certification

A sophisticated UAS operating in the specific category should not automatically be treated as a fully aviation-certified product.

EASA maintains a distinct design-verification framework for UAS operating in the specific category. For higher-risk operations, a Design Verification Report may become necessary, while other routes rely on operational authorisation, SORA-based assessment, recognised means of compliance and defined technical mitigations.

This creates a particularly important CRA question:

Does a particular EASA design-verification or operational-authorisation process amount to the product having been “certified in accordance with Regulation (EU) 2018/1139” for the purposes of Article 2(3) CRA?

Article 2(3) refers specifically to products that have been certified under Regulation 2018/1139. Certification should therefore be distinguished from other forms of regulatory assurance, verification, declaration or operational authorisation.

This distinction may determine whether the CRA remains applicable.

For developers of sophisticated UAS in the specific category, this is likely to become one of the most commercially important perimeter questions.

7. Cybersecurity already exists inside aviation regulation

Cybersecurity does not enter the drone sector for the first time through the CRA.

UAS aviation safety already depends upon system integrity, command-and-control reliability, containment, failure management, communications resilience and protection against unsafe system behaviour.

EASA has developed a substantial technical framework around UAS design verification and Special Condition Light-UAS.

The regulatory regimes nevertheless pursue different primary objectives.

Aviation regulation is principally safety-driven.

The CRA is a horizontal product-cybersecurity regime.

A compromised navigation module may simultaneously:

• create an aviation safety hazard;

• represent a product cybersecurity vulnerability;

• create a data-security risk;

• compromise operational continuity;

• and, in an autonomous AI system, affect the reliability of automated decision-making.

The same technical defect can therefore generate different legal consequences under different regimes.

8. NIS2 can regulate the operator even where the product falls outside the CRA

The CRA is primarily a product-regulation instrument. NIS2 operates at a different level.

Directive (EU) 2022/2555 requires essential and important entities within its scope to implement appropriate and proportionate technical, operational and organisational cybersecurity risk-management measures.

Article 21 includes:

• risk analysis and information-system security;

• incident handling;

• business continuity;

• supply-chain security;

• security in acquisition, development and maintenance;

• vulnerability handling;

• cryptography and encryption;

• access control.

A logistics operator, infrastructure operator, digital provider or other organisation operating a UAS fleet may fall within the national implementation of NIS2 if it qualifies as an essential or important entity.

A drone may therefore fall outside the CRA because the relevant product is aviation-certified, while the entity operating the surrounding digital infrastructure remains subject to NIS2.

Product exclusion does not equal operational cybersecurity exclusion.

9. CRA compliance is lifecycle compliance

CRA compliance cannot be reduced to a cybersecurity audit immediately before CE marking.

The Regulation creates lifecycle obligations.

Manufacturers must address cybersecurity risk, known exploitable vulnerabilities, secure-default configurations, confidentiality, integrity, availability and attack-surface reduction.

The manufacturer must also establish vulnerability-handling processes.

For UAS, the lifecycle may include:

• firmware revisions;

• updated navigation databases;

• modified cryptographic libraries;

• revised AI models;

• third-party software updates;

• ground-station updates;

• over-the-air deployment of new functionality.

The compliance object is therefore the manufacturer's secure development and vulnerability-management system across the support lifecycle.

10. A software bill of materials becomes strategically important

CRA vulnerability-management requirements create a direct link with software supply-chain governance.

A typical autonomy architecture may incorporate:

• embedded operating systems;

• autopilot software;

• open-source cryptographic libraries;

• communications firmware;

• third-party GNSS modules;

• machine-learning frameworks;

• commercial computer-vision libraries;

• cloud APIs;

• mapping SDKs.

The manufacturer may need sufficient contractual rights to obtain:

• vulnerability information;

• security patches;

• component identification;

• lifecycle-support commitments;

• incident cooperation;

• evidence for conformity assessment.

A supplier agreement that was commercially adequate before the CRA may therefore become legally insufficient after it.

11. The CRA does not impose a mandatory external source-code audit on every drone

There is no general CRA rule requiring every connected product to undergo a third-party source-code audit before being placed on the EU market.

The conformity-assessment route depends on product classification.

Many ordinary products with digital elements can use internal control.

The CRA creates stricter routes for specified important products with digital elements and critical products with digital elements.

An autonomous drone is not itself an Annex III category.

Nor does the mere presence of a neural network transform a drone into an important CRA product.

A UAS may, however, incorporate components that themselves fall within Annex III, particularly if those components are separately placed on the market.

The manufacturer must therefore perform product-by-product and component-by-component classification.

12. Radio equipment remains subject to the RED

The CRA does not replace the Radio Equipment Directive as the general EU market-access regime for radio equipment.

Directive 2014/53/EU continues to govern relevant radio equipment, including:

• command-and-control radio links;

• radio modems;

• remote-identification equipment;

• telemetry equipment;

• wireless ground-control interfaces.

Commission Delegated Regulation (EU) 2026/339 repeals Delegated Regulation (EU) 2022/30 with effect from 11 December 2027, when the CRA becomes fully applicable.

Accordingly:

until 10 December 2027

→ RED continues to apply, including applicable cybersecurity requirements introduced through Delegated Regulation 2022/30;

from 11 December 2027

→ those specific RED cybersecurity requirements are repealed to avoid overlap with the CRA;

throughout

→ RED remains relevant to the other essential requirements applicable to radio equipment.

Part II of this analysis examines the remaining layers identified above: AI Act classification, GDPR, product liability, export control and the practical regulatory architecture roadmap for autonomous UAS entering the EU market.

Disclaimer

This article has been prepared by CORVUS AI for general informational and educational purposes only. It is intended to make complex legal and regulatory developments easier to understand.

It does not constitute legal advice and does not create a professional adviser–client relationship. The information should not be relied upon as a substitute for advice based on the specific facts, circumstances and applicable law relevant to your organisation or project.

The article reflects our understanding of the law and regulatory framework as of the date of publication. Legislation, case law, regulatory guidance and administrative practice may subsequently change. While reasonable care has been taken in preparing this article, CORVUS AI does not warrant that the information is complete or remains current after the date of publication. We do not undertake to update this content.

To the fullest extent permitted by applicable law, CORVUS AI excludes liability for loss arising from reliance on this article. Nothing in this article constitutes an offer or solicitation to provide regulated legal services in any jurisdiction where doing so would be unlawful.

AI-assisted preparation: This article was prepared with the assistance of AI tools. Its legal analysis, conclusions and final text were subject to human review and editorial control and were reviewed and approved prior to publication by Oleksandr Sobovyi, Founder & CEO of CORVUS AI. CORVUS AI retains editorial responsibility for the published content.

For advice tailored to your organisation, project or specific circumstances, please contact CORVUS AI.

Key sources

• Cyber Resilience Act — Regulation (EU) 2024/2847

• Basic Aviation Regulation — Regulation (EU) 2018/1139

• Implementing Regulation (EU) 2019/947 on UAS operations

• Delegated Regulation (EU) 2019/945 on UAS

• NIS2 Directive — Directive (EU) 2022/2555

• Radio Equipment Directive — Directive 2014/53/EU

• Delegated Regulation (EU) 2022/30 — RED cybersecurity requirements

• Delegated Regulation (EU) 2026/339 — repeal of Delegated Regulation 2022/30