DO-326A and ED-202A Airworthiness Security Guide

Modern aircraft connect flight-critical avionics, airline operational systems, maintenance laptops and passenger networks, so certification authorities now expect applicants to show that intentional unauthorised electronic interaction cannot compromise safety. RTCA DO-326A, Airworthiness Security Process Specification, and its European twin EUROCAE ED-202A, published in 2014, define the process that type certificate and supplemental type certificate applicants use to show this. Together with DO-356A (methods and considerations) and DO-355A (continuing airworthiness), they form the "DO-326 family" that the FAA and EASA accept as means of compliance. This guide explains the regulatory hooks, the security process and its artefacts, how to integrate it with safety assessment (ARP4754A and ARP4761) and development assurance (DO-178C and DO-254), and how to carry security into operations. It is for avionics, systems and certification engineers, design organisation security leads and operators' engineering teams. For sector context see the Aviation Cybersecurity Guide.

Key takeaways

Security is treated as a safety question. The process asks whether intentional unauthorised electronic interaction (IUEI) could cause a failure condition, and assesses it with the same severity scale as safety assessment.
Europe has codified it; the US is codifying it. EASA ED Decision 2020/006/R amended CS-25, CS-27, CS-29, CS-E, CS-P and AMC-20 to add cybersecurity provisions; the FAA proposed 14 CFR 25.1319, 33.28(n) and 35.23(f) in August 2024 to replace project-by-project special conditions.
The family has three main documents: DO-326A/ED-202A (process), DO-356A/ED-203A (methods and considerations) and DO-355A/ED-204A (continuing airworthiness). RTCA now also sells DO-326B, so confirm which revision your authority accepts for your project.
Security must survive into service. The FAA proposal adds Instructions for Continued Airworthiness for maintaining security protections, and operators build an Aircraft Network Security Program from the applicant's guidance.
Interfaces are where risk lives: data loading, maintenance access, ground links, airline and passenger domains, and supply chain software all need security measures and evidence.

Regulatory basis and current status

Authority	Instrument	Status (checked 27 October 2026)
EASA	ED Decision 2020/006/R: CS-25 Amendment 25, CS-27 Amendment 7, CS-29 Amendment 8, CS-E Amendment 6, CS-P Amendment 2, CS-APU Amendment 1, CS-ETSO Amendment 15, AMC-20 Amendment 18, AMC and GM to CS-23 Issue 3, AMC and GM to Part 21	Adopted 2020. The AMC-20 amendment added AMC 20-42 on airworthiness information security risk assessment, which points applicants to the ED-202A family (confirm the current AMC text on the EASA site)
FAA	Special conditions per project	Applied since 2009, starting with the Boeing 787; 68 cybersecurity special conditions issued from 2013 to 2022
FAA	NPRM "Equipment, Systems, and Network Information Security Protection" (Notice 24-23, Docket FAA-2024-1398, 89 FR 67564, 21 August 2024)	Proposed rule; comments closed 21 October 2024. No final rule found in the Federal Register when checked
FAA	Proposed AC 20-XXX "Aircraft Systems Information Security/Protection (ASISP)"	Draft acceptable, but not exclusive, means of compliance
EU (organisations)	Commission Delegated Regulation (EU) 2022/1645 (Part-IS for organisations under Regulations 748/2012 and 139/2014)	Organisational information security management; complements, does not replace, product certification. See the EASA Part-IS Information Security Guide

The FAA NPRM defines IUEI as "a circumstance or event with the potential to affect the aircraft due to human action resulting from unauthorized access". It includes malware and the effects of external systems, and excludes physical attacks and electromagnetic jamming. The proposal would require applicants to identify and assess security risks from IUEI, mitigate them as needed for safety, functionality and continued airworthiness, and provide procedures and ICA that maintain the protections. The FAA proposes no new requirements for parts 23, 27 and 29, saying existing rules such as 23.2500 to 23.2510, 27.1309 and 29.1309 suffice, while noting EASA did codify provisions for small aeroplanes and rotorcraft.

The DO-326 and ED-202 document family

RTCA	EUROCAE	Title	Use
DO-326A (2014); DO-326B available	ED-202A	Airworthiness Security Process Specification	What the applicant must do and produce during certification
DO-356A	ED-203A	Airworthiness Security Methods and Considerations	How: threat assessment methods, security assurance, verification. Joint product of EUROCAE WG-72 and RTCA SC-216
DO-355A	ED-204A	Information Security Guidance for Continuing Airworthiness	Operation and maintenance; referenced in FAA AC 119-1 and inspector guidance 8900.1
DO-391	ED-201A	Aeronautical Information System Security Framework Guidance	Shared responsibilities across aviation stakeholders
DO-392	ED-206	Information Security Event Management	Identifying, responding to and reporting security events; developed as AMC to EASA Part-IS

RTCA's security page confirms the DO numbers and their scope. The EUROCAE numbers for ED-203A, ED-204A, ED-201A and ED-206 are given from established industry usage; check the EUROCAE catalogue before quoting them in certification documents.

The airworthiness security process

DO-326A/ED-202A runs alongside the safety and development processes of the aircraft programme. Its main activities and artefacts are:

Plan for Security Aspects of Certification (PSecAC): agreed with the authority early, like the Plan for Software Aspects of Certification. It sets scope, methods, organisation, documents and the evidence to be delivered.
Security scope definition: the assets (functions, systems, data), the security perimeter, external interfaces (ground links, data loaders, maintenance ports, wireless), and the security environment, including assumptions about operators and maintenance.
Preliminary aircraft security risk assessment: threat conditions (what IUEI could cause a safety effect) and threat scenarios (how an attacker could reach it through the interfaces), with severity taken from the failure condition classification (catastrophic, hazardous, major, minor, no safety effect).
Security architecture and measures: security measures allocated to aircraft and system levels, for example domain segregation, data-load integrity checks with digital signatures, authenticated maintenance access and filtering at domain gateways.
System-level security risk assessments: refine threat scenarios against the detailed design and confirm the measures reduce risk to an acceptable level.
Security effectiveness assurance: verification and testing that measures work as intended, including vulnerability analysis and security testing of interfaces.
Security guidance for operators: the instructions that DO-355A/ED-204A and the FAA's proposed Appendix H ICA content carry into service.
Certification summary: the PSecAC summary and compliance evidence provided to the authority.

The FAA NPRM summarises the same logic: identify threat conditions across system, architecture and interfaces; assess severity and likelihood of exploitation; mitigate with protection mechanisms or process controls; and provide continued-airworthiness procedures. The process steps above follow the published structure of DO-326A as commonly applied; the standard itself is a paid document, so use the purchased text as the authority for artefact names and content.

Aircraft domains and typical security measures

Most programmes structure the security architecture around the aircraft network domains described in ARINC 811 (one of the standards FAA AC 119-1 was built on). Threat scenarios usually start in a less trusted domain and try to reach a more critical one.

Domain	Typical contents	Typical threat scenario	Typical security measures
Aircraft control domain	Flight controls, flight management, engine control, displays	Malicious data or software reaching a flight-critical function	Strict one-way or filtered interfaces, signed loadable software, no direct external connectivity
Airline information services domain	Maintenance systems, electronic flight bag interfaces, cabin operations, ground link servers	Compromised maintenance laptop or ground network used as a stepping stone	Authenticated maintenance access, gateway filtering, logging, hardened servers
Passenger information and entertainment services domain	In-flight entertainment, cabin connectivity	Passenger device attacking cabin systems and probing towards airline systems	Network segregation, unidirectional data flows towards passengers, monitoring
Passenger-owned devices	Phones and laptops on cabin Wi-Fi	Untrusted endpoints by definition	Isolation from all aircraft domains; treat as hostile
Ground systems	Software parts libraries, signing infrastructure, airline IT, airport networks	Tampered software parts or stolen signing keys	Key protection in hardware security modules, access control on parts libraries, integrity verification before loading

Integrating security with safety and development assurance

Process	Standard	Security touchpoint
Aircraft and system development	SAE ARP4754A / ED-79A	Security requirements captured and traced like other system requirements
Safety assessment	SAE ARP4761 / ED-135	Failure condition classification feeds threat condition severity; security measures can become safety requirements
Airborne software	RTCA DO-178C / ED-12C	Security functions developed and verified at the assigned level; secure coding and vulnerability analysis evidence
Airborne electronic hardware	RTCA DO-254 / ED-80	Hardware security functions such as secure boot and key storage
Continuing airworthiness	DO-355A / ED-204A	Operator procedures, software loading, security event handling

Decision guidance: co-locate security and safety analysts in the same working group and use one hazard log with security-derived entries, rather than running a separate security programme that reports late. See the Safety and Security Co-engineering Guide and the Threat Modelling Guide.

Where identity and machine credentials fit

Many aircraft security measures depend on non-human identities and keys:

Software and data loading: loadable software parts and databases are verified with digital signatures. The signing keys, certificates and the ground systems that hold them are critical assets, and the FAA proposal explicitly covers procedures for transferring control software and data between aircraft, engines, propellers and ground systems.
Maintenance access: portable maintenance devices and ground support equipment authenticate to aircraft systems. Shared maintenance credentials and unmanaged laptops are classic weak points.
Ground connectivity: aircraft-to-ground links (for example for electronic flight bags, airline operational data and wireless ground links at the gate) rely on certificates and network credentials that operators must rotate and revoke.
Supplier access: OEM and supplier portals delivering software parts need strong identity controls, because a compromised supplier account is a route to the signing pipeline.

See the Device and IoT Identity Guide for device credential lifecycle patterns.

How to implement on a programme

Agree the certification basis: confirm with the authority whether EASA CS amendments, FAA special conditions or a future 25.1319 apply, and which revision of the DO-326 family is accepted. Record it in the PSecAC.
Define scope early: list every external interface, including those added late such as connectivity upgrades and cabin systems. Late interfaces are the most common cause of rework.
Run the preliminary assessment at architecture stage: before the domain architecture is frozen, so segregation and gateways can be designed in rather than bolted on.
Allocate and trace measures: each threat scenario maps to measures, each measure to requirements, and each requirement to verification.
Test interfaces: plan security effectiveness testing on the integration rig, including malformed input, authentication bypass attempts and data-load integrity, under authorised test conditions.
Write operator guidance as a deliverable: software loading procedures, key and certificate management, maintenance access and security event reporting.
Manage change: for each design change or STC, rerun the assessment for affected interfaces; a minor cabin change can create a path into another domain.

Small versus large organisations: an STC holder adding a single connected cabin product can scope the assessment to its interface and the domain it touches, using the type certificate holder's security architecture as an input. A type certificate holder runs the full aircraft-level process and must supply security guidance to every operator.

The operator side: Aircraft Network Security Program

Certification evidence is only half the job: the operator must keep the protections working. In the US, FAA AC 119-1 (30 September 2015) describes one acceptable way for operators under parts 121, 121/135, 125 and 129 to obtain operational authorisation for aircraft certified with a network security special condition. It was built using RTCA DO-355 and ARINC 811 and 827. Key points:

When it applies: an Aircraft Network Security Program (ANSP) is needed when a type certificate data sheet, STC or amended type certificate lists a special condition that requires operator instructions or action. The design approval holder submits network security guidance for approval; the operator builds the ANSP from it.
Ownership: the operator is finally responsible. The ANSP manual names a Data Security Manager, and the FAA must be told in writing within five working days of a change in that role.
Scope: prevent access by unauthorised outside devices or personnel, assess and mitigate threats, prevent inadvertent or malicious network changes (including from maintenance), and prevent unauthorised access from onboard sources.
Manual content: the AC lists twelve components, including roles and responsibilities, training, control of maintenance laptops and ground support equipment, access to airport wired and wireless networks, Loadable Software Airplane Part library access and secure parts signing, conformity to type design and parts pooling, event recognition and response, and a security environment description.
Timelines: revise the ANSP within 30 days of a revision to the design approval holder's source document; notify the certificate-holding district office at least 60 days before operations; authorisation is through OpSpec D301.
Logs and reporting: security logs are retained and analysed, threats are reported under the operator's IT policies and forwarded to the design approval holder, with A-ISAC participation noted as an alternative route. Personal storage devices are prohibited for aircraft data transfers.

The FAA NPRM would move the design-side content into Instructions for Continued Airworthiness (new H25.3(h) for "procedures and instructions necessary to maintain airplane security protections"), and the preamble notes operators would develop an ANSP based on the applicant's guidance.

Measuring the security process

Metric	Why it matters
External interfaces in scope with a completed threat scenario analysis	Coverage of the attack surface
Threat scenarios traced to measures and verification evidence	Completeness of the certification argument
Security findings from effectiveness testing closed before certification	Quality of measures
Design changes with a documented security impact assessment	Change control discipline
Signing keys and certificates with defined owners, rotation and revocation procedures	Integrity of software loading in service
Operators who have implemented the Aircraft Network Security Program guidance	Security that survives into operation

Framework mapping

Need	Aviation instrument	Cross-sector equivalent
Product security risk assessment in certification	DO-326A/ED-202A, CS-25 and AMC 20-42, proposed 14 CFR 25.1319	IEC 62443-3-2 risk assessment; ISO/SAE 21434 TARA in automotive
Security methods and assurance	DO-356A/ED-203A	IEC 62443-4-1 secure development
Security in operation and maintenance	DO-355A/ED-204A, FAA AC 119-1 ANSP	IEC 62443-2-1 asset owner programme; UNECE R155 CSMS in automotive
Organisational information security	EU Part-IS (Regulation 2022/1645 and related)	ISO/IEC 27001
Security event management	DO-392	NIST CSF 2.0 Detect and Respond functions

See the ISO/SAE 21434 Automotive Cybersecurity Engineering Guide and the IEC 62443 Guide for the parallel frameworks.

Common failure patterns

Starting after the architecture is frozen: segregation and gateway decisions cannot change cheaply, so measures become procedural workarounds.
Treating security like IT compliance: using enterprise control checklists rather than threat conditions tied to failure condition severity.
Ignoring ground systems: the aircraft is assessed, but the software signing and loading infrastructure on the ground is not.
Weak operator guidance: instructions that say "protect the maintenance laptop" without specifying credential, patching and media controls.
Unassessed modifications: connectivity retrofits and STCs that add paths between passenger and aircraft domains.
Revision confusion: mixing DO-326A and DO-326B terminology without agreeing the accepted revision with the authority.

Practitioner checklist

Confirm the security certification basis and accepted DO-326 family revision with the authority.
Prepare and agree a PSecAC early in the programme.
Define the security scope, perimeter and every external interface.
Run the preliminary aircraft security risk assessment before freezing the architecture.
Integrate security entries into the safety assessment and requirement traceability.
Protect signing keys and data-loading infrastructure as critical assets.
Plan and execute security effectiveness testing on integration rigs.
Deliver operator security guidance aligned to DO-355A/ED-204A.
Reassess security for every design change and STC.
Track the FAA 25.1319 rulemaking and EASA AMC updates.

DO-326A and ED-202A Airworthiness Security Guide: Process and Certification