Key takeaways
- Airworthiness security is a certification deliverable. Authorities point applicants to DO-326A/ED-202A (the process) and DO-356A/ED-203A (the methods), and attach information-security requirements to eVTOL certification bases through special conditions.
- The process is a security twin of the safety assessment you already know: threat conditions are classified by the same severity scale as failure conditions, and the security measures must be shown to work.
- The eVTOL/UAS attack surface is wider than the airframe: the command-and-control link, GNSS, the ground control station, software updates, maintenance interfaces, cloud fleet tools and Remote ID all belong in scope.
- Analysis of NTSB uncrewed-aircraft accident reports shows system and component failures as the leading category. From the outside, a security failure and a reliability failure look the same, which is why the two assessments should share evidence.
- The cheapest time to fix a security finding is before the architecture is frozen. The most expensive is during flight test.
Why security is now a certification question
For decades, airworthiness meant showing that an aircraft would keep flying safely when parts failed at random. Since the late 2000s, as aircraft became networked (data loading, connected maintenance, passenger connectivity, and now fleets of electric aircraft managed from the cloud), authorities have added a second question: what happens when someone deliberately makes a system fail?
The answer was standardized in RTCA DO-326A / EUROCAE ED-202A, the Airworthiness Security Process Specification, and its companions DO-356A/ED-203A (methods) and DO-355A/ED-204A (continuing airworthiness). EASA recognizes them through AMC 20-42 on airworthiness information security risk assessment; the FAA has applied the same expectations to new type designs through special conditions for years and in 2024 proposed codifying them in the airworthiness rules. For electric VTOL aircraft, whose certification bases are built largely from special conditions and purpose-written airworthiness criteria, information security arrives as part of that package.
The practical consequence for a start-up is that "we'll harden it later" is no longer an option. The authority will ask for a plan early, and every security finding after the architecture is frozen costs a redesign, a retest, or both.
The DO-326A process in plain language
DO-326A does not tell you which controls to use. It defines a process that runs alongside the safety process (ARP 4754A / ARP 4761) and produces evidence. The table below is the process as I explain it to engineering teams that have never seen it.
| Step | What you actually produce | When |
|---|---|---|
| Plan for Security Aspects of Certification (PSecAC) | A document agreed with the authority that says how you will do all of the below, who is responsible, and what evidence you will deliver. | Concept phase, before the certification basis is fixed. |
| Security scope definition | The security perimeter: which systems, interfaces and data flows are in scope; the assets you are protecting; the external connections. In eVTOL and UAS this is where the ground segment gets pulled in. | Preliminary design. |
| Security risk assessment | Threat conditions (what an attacker could cause to happen to the aircraft) classified on the same severity scale as failure conditions: catastrophic, hazardous, major, minor, no safety effect. Threat scenarios (how it could be done), the attacker's assumed capability, and the security measures that reduce the risk to acceptable. | Preliminary design, refined through detailed design. |
| Security development | Security requirements flowed into system, hardware and software requirements, and an architecture that implements the measures (segregation, authentication, integrity checks, monitoring). | Detailed design. |
| Security effectiveness assurance | Evidence that the measures work as claimed, proportionate to an assigned Security Assurance Level (DO-356A defines SAL 0–3): analysis, testing, penetration testing where warranted. | Verification. |
| Security verification and closure | Test results, vulnerability assessment, residual-risk acceptance and the compliance summary the authority signs off. | Certification. |
| Continuing airworthiness (DO-355A/ED-204A) | Instructions for operators: how updates are approved and loaded, what logs to keep, how security events are reported and handled (DO-392/ED-206 covers security event management). | Entry into service and after. |
Two features of the process trip teams up. First, severity is about the aircraft, not the data. A leaked telemetry log is a privacy problem, not an airworthiness one; an attacker who can command a motor controller is catastrophic. Classify accordingly and you avoid over-engineering the wrong things. Second, assurance is proportionate. A threat condition with no safety effect gets SAL 0 and a sentence; a catastrophic one gets the full treatment. Argue the classification with evidence and the authority will usually accept it.
The eVTOL and UAS attack surface
Conventional aircraft security scope was mostly the aircraft. For an electric VTOL or an uncrewed aircraft the scope is a system of systems, and the authority will expect you to have thought about all of it.
| Element | What can go wrong | What good looks like |
|---|---|---|
| Command-and-control (C2) link | Hijack, replay, jamming, loss of link handled badly. | Mutual authentication, encryption, replay protection, link-loss behaviour that is designed, tested and independent of GNSS timing. |
| GNSS | Jamming (no position) and spoofing (wrong position). See my GNSS and ADS-B guide for what the data shows. | Sensor fusion with inertial and other sources, plausibility checks on position jumps, defined behaviour when sources disagree, tested "wrong position" cases rather than only "no position". |
| Ground control station | A laptop or tablet with commodity OS, shared credentials, open ports, USB. | Treated as part of the type design: hardened build, managed accounts, signed software, logging. |
| Software and firmware updates | Unsigned images, updates over untrusted networks, no rollback control. | Signed, versioned, authenticated updates with an approved loading procedure and an audit trail, as DO-355A expects. |
| Maintenance and data-loading interfaces | Debug ports, JTAG, Wi-Fi maintenance access, default passwords. | Disabled or authenticated in production configuration; access logged. |
| Telemetry, cloud and fleet management | Cloud account compromise leading to commands or configuration pushed to aircraft. | Separation between monitoring (read) and command (write) paths; strong identity on the cloud side; the aircraft treats the cloud as untrusted input. |
| Remote ID and detect-and-avoid inputs | Broadcast Remote ID and ADS-B In are unauthenticated; false traffic can trigger avoidance manoeuvres. | Never build safety-critical logic that trusts an unauthenticated broadcast without cross-checking. |
| Supply chain and COTS | Autopilots, radios and open-source flight stacks with known vulnerabilities; components with unverifiable provenance. | A bill of materials for software as well as hardware, vulnerability tracking, and a process for security patches that fits your configuration control. |
What the accident data says
It is tempting to treat security as a separate universe from safety. The accident record argues against that. In Utilizing artificial intelligence for National Transportation Safety Board unmanned aerial vehicle accident analysis and categorization (International Journal of AI for Materials and Design, 2025), João Garcia and I used a language model to classify NTSB uncrewed-aircraft accident reports from 2006 to 2023 into standard occurrence categories. The leading categories were system or component failure not related to the powerplant, and abnormal contact on landing, together accounting for about 37% of the accidents in the set. The reports are plotted on an interactive map you can filter by category and year.
Two lessons for a developer. First, the components that fail on their own (navigation, links, controllers) are the same components an attacker would target, so a good security architecture and a good reliability architecture share the same redundancy and monitoring. Second, when an aircraft loses control today, investigators cannot always tell why, because the data to distinguish a fault from an attack was never logged. Designing in the logging that DO-355A asks for also improves your own safety investigations.
The scale of the problem is growing with the fleet: the professional UAV fleet in the United States grew by 731% between 2016 and 2023 according to the FAA figures we compiled for that study. A design flaw that affects one prototype today affects a fleet tomorrow.
The UAS regulatory picture, briefly
Airworthiness security sits inside a wider regulatory frame that is still being harmonized. In Development of global regulations for Uncrewed Aircraft Systems – Europe and beyond (IEEE ICNS 2025, with Christian Janke and Maarten Uijt de Haag), we surveyed civil aviation authorities in 30 EASA member states and compared the results with a 2022 survey. The headline is growth: registered UAS, remote-pilot certificates and operator IDs all rose sharply, with Germany alone reporting 642,281 registered UAS and 385,050 A1/A3 certificates. The specific category (SORA-based operations, standard scenarios, PDRAs) is actively used, while the Light UAS Operator Certificate that lets an operator self-authorize remains rare.
For a developer the implications are practical. In Europe, your customers' operational approvals under Regulation (EU) 2019/947 depend on a risk assessment (SORA) that asks about your aircraft's containment, link loss and navigation behaviour, so your security design feeds their approvals. In the United States, Remote ID (14 CFR Part 89) is mandatory and beyond-visual-line-of-sight rules are being expanded. In Canada, Transport Canada's RPAS regulations in CARs Part IX were amended in 2025 to open more complex operations. Each regime asks slightly different questions; a single, well-documented security case answers most of them.
Before your first meeting with the authority
Authorities respond well to applicants who arrive with a structure. Have these ready, even in draft:
- A system boundary diagram showing every external interface of the aircraft and its ground segment, with the data that crosses each one.
- A first-pass list of threat conditions with a proposed severity for each. Expect to discuss loss of control, unauthorised commands, corrupted navigation, unauthorised software, and denial of the C2 link.
- Your proposed security assurance levels and the reasoning behind them.
- A draft PSecAC, even two pages long, naming who owns security in the program.
- Your update and logging concept: how software gets onto the aircraft after delivery and what records exist afterwards.
- Your position on COTS and open-source components: what you use, what you know about it, and how you track vulnerabilities.
You will not have all the answers. The authority is checking that you have the right questions and a process to close them.
Questions I get asked
Do I need DO-326A for a small UAS or an eVTOL prototype?
If you are seeking a type certificate or an equivalent approval for an aircraft with connected systems, the authority will expect an airworthiness security process, and DO-326A/ED-202A is the accepted means. Operational rules for small UAS, such as Part 107 or the Canadian basic and advanced operations, do not require DO-326A, but the same threat thinking still applies to your command-and-control link and ground station.
When should we start the security assessment?
Before the architecture is frozen. Threat conditions are cheapest to address in the requirements phase and most expensive to fix during flight test. A first Plan for Security Aspects of Certification and a system boundary diagram at the concept stage is enough to open the conversation with the authority.
What is in scope besides the airframe?
The command-and-control link, GNSS and other navigation inputs, the ground control station, software update paths, maintenance interfaces, cloud fleet tools and Remote ID. Anything that can change what the aircraft does, or what people believe about it, belongs in the security scope.
How does airworthiness security relate to the safety assessment?
It mirrors it. Threat conditions are classified with the same severity scale as failure conditions, and security measures must be shown to be effective, just as safety mitigations are. Running the two assessments together, with shared evidence, avoids duplicated work and contradictions.
How I can help
I write threat models and security requirements for C2 links, GNSS, ground stations and software updates, structured to line up with DO-326A/ED-202A so your certification team is not surprised late. You get a threat model, a requirements set and my review notes, and I can support the first conversations with the authority.
Discuss your program
Founder of Mevocopter Aerospace. Led the concept design of a hybrid eVTOL air ambulance at Uniqopter, now a Ph.D. researcher in Data Science at the University of Essex working on aviation surveillance integrity. Publications · ORCID
References
- RTCA DO-326A / EUROCAE ED-202A, Airworthiness Security Process Specification; DO-356A / ED-203A, Airworthiness Security Methods and Considerations; DO-355A / ED-204A, Information Security Guidance for Continuing Airworthiness; DO-392 / ED-206, Guidance on Security Event Management.
- EASA AMC 20-42, Airworthiness information security risk assessment.
- Pik, E., Garcia, J. S. D. (2025). Utilizing artificial intelligence for National Transportation Safety Board unmanned aerial vehicle accident analysis and categorization. International Journal of AI for Materials and Design. DOI: 10.36922/ijamd.8544 · PDF
- Janke, C., Uijt de Haag, M., Pik, E. (2025). Development of global regulations for Uncrewed Aircraft Systems – Europe and beyond: a continued survey and evaluation of progress. 2025 Integrated Communications, Navigation and Surveillance Conference (ICNS). DOI: 10.1109/ICNS65417.2025.10976863 · PDF (accepted version)
- Pik, E. (2024). Commercial and Recreational Active UAV Fleet in the U.S. 2016–2022. Dataset, DOI: 10.5281/zenodo.10573915
- Pik, E., Berra, M., Yearwood, J., Garcia, J. S. D. (2025). GPS Anomalies in Aviation. Journal of Aerospace Information Systems, 22(7). DOI: 10.2514/1.I011527 · PDF (accepted manuscript)