RTCA DO-326A / EUROCAE ED-202A – Tutorial (about 60 minutes)

RTCA DO-326A and its European twin EUROCAE ED-202A describe the process an aircraft or equipment designer follows to show an aviation authority that deliberate electronic attacks cannot make the aircraft unsafe. Airframers, avionics and engine suppliers, modification companies, security engineers and certification specialists use it whenever a design connects aircraft systems to networks, data links, portable devices or maintenance tools. After this tutorial you will be able to explain why airworthiness security exists, walk through the seven-step airworthiness security process, read a security risk assessment and recognise what an authority expects to see before it approves a connected design.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: RTCA DO-326A and EUROCAE ED-202A, Airworthiness Security Process Specification, are technically identical documents dated August 2014, produced jointly by RTCA Special Committee SC-216 and EUROCAE Working Group WG-72. The first edition (DO-326) appeared in 2010. A newer revision, ED-202B / DO-326B, was published in October 2024 (EUROCAE lists ED-202B as published; RTCA offers DO-326B for sale). At the time of writing, the European Union Aviation Safety Agency (EASA) still names the A revision, together with ED-203A / DO-356A and ED-204 / DO-355, as the recognised standards in its acceptable means of compliance AMC 20-42 (EASA community note of 30 July 2026). In the United States the Federal Aviation Administration (FAA) has used project-specific special conditions and, in August 2024, proposed permanent cybersecurity rules for transport aeroplanes, engines and propellers (Notice 24-23); no final rule had been published when this was checked. This tutorial teaches the A revision, which is the edition named in the course title and in current regulatory guidance; it does not detail what changed in the B revision, so check with your authority which revision your project must follow. Verified 2026-10-29 against the EUROCAE WG-72 page, the RTCA security page, the EASA community note on ER-042, EASA Decision 2020/006/R and the FAA proposed rule in the Federal Register.

Who it is for: systems, software and hardware engineers in aerospace; cybersecurity professionals moving into aviation from IT, automotive, rail or industrial control; safety engineers; certification and compliance staff; and project managers or buyers who must understand what a supplier's "DO-326A compliance" claim actually means.

Prerequisites: none. A rough idea of how aircraft are certified and what a cyber threat is will help, but every aviation and security term is explained the first time it is used.

By the end of this tutorial:

• You will be able to explain what problem DO-326A / ED-202A solves and how it differs from ordinary IT security and from safety assessment.
• You will be able to define the core vocabulary: intentional unauthorised electronic interaction, asset, security perimeter, threat scenario, threat condition, level of threat, security measure and security assurance level.
• You will be able to describe the seven steps of the airworthiness security process and the main documents each step produces.
• You will be able to explain how the companion documents DO-356A / ED-203A and DO-355A / ED-204A fit around DO-326A.
• You will be able to follow a security risk assessment from threat scenario to acceptability decision and selected measures.
• You will be able to describe how authorities assess compliance and why there is no such thing as a "DO-326A certified company".
• You will be able to relate airworthiness security to ARP4754, ARP4761, DO-178C, Part-IS and other cybersecurity standards.

Lesson 1 – Why aircraft need airworthiness security

From isolated boxes to connected aircraft

For most of aviation history, the electronic systems on an aircraft were closed. A flight management computer talked to a handful of other boxes over dedicated wires, software was loaded by a technician with a special device, and the only "network" a passenger could reach was the cabin reading light. Safety engineers worried about random hardware failures, design errors and lightning, but nobody seriously expected a person to attack the avionics electronically, because there was simply no electronic path to reach them.

That changed in the 2000s. Aircraft gained shared data networks, satellite and cellular links to the airline's ground systems, electronic flight bags (tablets or installed computers that replace paper manuals and charts), wireless maintenance access, field-loadable software and in-flight entertainment and Wi-Fi for hundreds of passengers. Each of these brings real benefits, such as better maintenance data, less paper and happier passengers, but each also creates a path by which someone might send unexpected data or commands towards systems that keep the aircraft flying.

Authorities first answered this on a project-by-project basis. When a new aircraft design connected passenger systems to the aircraft network, the FAA issued special conditions, extra certification requirements written for one design because the existing rules did not cover the novel feature. The FAA's 2024 proposed rule notes that it issued 68 cybersecurity special conditions between 2013 and 2022. Writing the requirement again for every project was slow, and industry needed a shared way to show compliance. That shared way is the subject of this course.

What "airworthiness security" means

Airworthiness is the condition of an aircraft being safe to fly: it conforms to its approved design and is in a condition for safe operation. Airworthiness security narrows the broad field of cybersecurity to one question: can a deliberate, unauthorised electronic action make the aircraft less safe? It is not about protecting airline revenue, passenger privacy or the reputation of the manufacturer, all of which matter but are handled by other means. It is about safety effects: misleading information on a pilot's display, loss of a needed function, an unwanted command to a control system, corrupted navigation data or loaded software that behaves differently from the approved version.

The documents use the phrase intentional unauthorised electronic interaction, usually abbreviated IUEI. Each word matters. "Intentional" separates attacks from random failures, which the safety process already covers. "Unauthorised" means the action is not permitted by the aircraft's design or the operator's procedures. "Electronic" means the action uses data, signals, software or networks; physical tampering with a crowbar and electromagnetic jamming are outside the scope. The goal of DO-326A is to show that IUEI cannot cause an unacceptable safety effect.

Who wrote it and how it became a means of compliance

RTCA is a United States not-for-profit organisation that writes consensus guidance for aviation, much of which the FAA then recognises. EUROCAE plays the same role in Europe. Their joint committees, RTCA SC-216 and EUROCAE WG-72, produced a family of airworthiness security documents so that a manufacturer selling aircraft on both sides of the Atlantic could follow one process. DO-326A / ED-202A is the process specification at the centre of that family: it says what activities and evidence are needed. Its companion DO-356A / ED-203A, Airworthiness Security Methods and Considerations, explains how to carry out those activities, and DO-355A / ED-204A gives guidance for the in-service phase, called continuing airworthiness.

A document like DO-326A is not law. It becomes binding in practice when an authority accepts it as an acceptable means of compliance with a legal requirement. In Europe, EASA Decision 2020/006/R (1 July 2020) added cybersecurity provisions to several certification specifications, including large aeroplanes (CS-25), rotorcraft (CS-27 and CS-29), engines (CS-E), propellers (CS-P) and equipment authorisations (CS-ETSO), and added AMC 20-42, which points to the ED-202A family. In the United States, special conditions and issue papers have referred to the same documents, and the proposed rule of August 2024 would add permanent requirements to the airworthiness standards for transport aeroplanes, engines and propellers.

Scope in one paragraph

DO-326A applies to the type certification of aircraft, engines, propellers and airborne equipment, and to changes to them such as supplemental type certificates (approvals for a third party's modification of an existing design). It covers the development and certification part of the life cycle and hands over to continuing airworthiness guidance once the product is in service. It addresses safety effects only. It does not prescribe particular technologies such as firewalls or encryption algorithms; it asks the applicant to analyse risk and justify whatever measures they choose.

Lesson 2 – Key concepts and vocabulary

Airworthiness security borrows words from both the safety world and the IT security world, and sometimes gives them a more precise meaning. Learn these terms well; the rest of the tutorial uses them constantly.

• Airworthiness security – protection of the aircraft's safety from intentional unauthorised electronic interaction. It is a subset of cybersecurity limited to safety effects.
• IUEI (intentional unauthorised electronic interaction) – a deliberate human action that uses electronic means, such as data, software, networks or malicious code, to affect the aircraft without permission. Physical attacks and jamming are excluded.
• Asset – anything in the scope that has value for safety and could be the target or the path of an attack: a function, a piece of equipment, a data item such as navigation data, a software image or an interface.
• Security perimeter – the boundary of what is being assessed. Everything inside is under the applicant's design control; everything that crosses the boundary is an interface that must be analysed.
• Security environment – the people, systems, networks and conditions outside or around the perimeter that can interact with it: ground networks, passengers, maintenance staff, portable devices, other aircraft systems.
• Threat source – the origin of a possible attack, such as a passenger with a laptop, a compromised ground system or an insider in a maintenance shop. Considering who could attack, and with what capability and access, shapes the likelihood of attack.
• Vulnerability – a weakness in the design, implementation or operation that a threat source could exploit, for example an unauthenticated data load function or an unpatched operating system in a cabin server.
• Attack vector – the route by which an attacker reaches a vulnerability: a Wi-Fi network, a USB port, a data link from the ground, a maintenance connector.
• Threat scenario – a description of how a threat source could use an attack vector and vulnerabilities, step by step, to produce an effect on an asset. It is the "story" of an attack.
• Threat condition – the resulting state of the aircraft or a function, described in safety terms, for example "erroneous altitude shown to both pilots" or "loss of engine thrust control". It is the security counterpart of a failure condition in safety assessment.
• Severity – the classification of a threat condition's effect on safety, using the same scale as safety assessment: no safety effect, minor, major, hazardous and catastrophic.
• Level of threat – the rating used in DO-356A for how likely it is that a threat scenario succeeds, from very high down to extremely low. It plays the role that probability plays for random failures.
• Security risk – the combination of severity and level of threat for a threat condition. The process decides whether each risk is acceptable or must be reduced.
• Security measure – a technical, procedural or architectural protection that prevents, detects or limits an attack: a one-way data gateway, authentication of loaded software, separation of networks, a maintenance procedure.
• Security assurance level (SAL) – in DO-356A, a level from 0 to 3 that says how much rigour must go into developing and verifying a security measure. SAL 3 is the most demanding.
• PSecAC (Plan for Security Aspects of Certification) – the plan the applicant agrees with the authority, describing the scope, process, methods, organisation and evidence for airworthiness security. Its closing counterpart is the PSecAC Summary, which reports what was done.
• Security effectiveness assurance – the activities that show the chosen measures really work as intended and cannot easily be bypassed: analysis, testing, vulnerability scanning and attempts to defeat the measures.

Three distinctions beginners often blur

Threat scenario versus threat condition. The scenario is the path of the attack, and the condition is its effect on safety. One threat condition, such as misleading airspeed, may be reachable by several different scenarios, and the assessment must consider all credible ones.

Safety failure versus security threat. Safety assessment estimates how often a component fails at random, using failure rates. Attackers do not behave randomly; they look for the weakest point and try again. That is why airworthiness security uses a level of threat built from attacker capability and exposure rather than a probability per flight hour.

Development assurance versus security assurance. DO-178C gives design assurance levels to software based on safety effects. A SAL is different: it applies to the security measures themselves and says how strongly their correctness and resistance to attack must be demonstrated.

Lesson 3 – Structure of the documents

The process in seven steps

DO-326A organises airworthiness security as a process with a planning step at the start, a reporting step at the end, and a loop in the middle that repeats until every risk is acceptable. Industry papers commonly present it as seven steps:

1. Plan for Security Aspects of Certification (PSecAC). Agree with the authority how security will be handled on this project.
2. Security scope definition. Draw the perimeter, describe the environment, list assets, interfaces and assumptions.
3. Security risk assessment. Identify threat conditions and threat scenarios, rate their severity and level of threat.
4. Acceptability decision. Compare each risk with the acceptability criteria. If all are acceptable, go to the final step; if not, continue to security development.
5. Security development. Change the architecture or add measures, write security requirements and develop the measures with the rigour their SAL demands.
6. Security effectiveness assurance. Verify that the measures are effective, then feed the result back into the risk assessment so the residual risk is re-evaluated.
7. Communication of evidence (PSecAC Summary). Present the outcome, evidence and any open items to the authority, including the guidance operators will need in service.

Steps 3 to 6 form the loop: an unacceptable risk leads to new measures, the measures are verified, and the risk is assessed again with the measures in place. Each pass may also change the architecture, which can create new interfaces and therefore new scenarios. The loop only ends when the risk assessment shows every threat condition at an acceptable level.

Aircraft level and system level

The process runs at two levels, mirroring the safety assessment approach of SAE ARP4761. At aircraft level, the aircraft manufacturer looks at the whole aircraft: which aircraft functions could be affected, which external connections exist and which threat conditions matter. At system level, each system or equipment developer looks inside its own box or network. Both levels have a preliminary assessment early in the design and a final assessment once the design is mature. The names commonly used are preliminary aircraft security risk assessment (PASRA) and aircraft security risk assessment (ASRA) at aircraft level, and preliminary system security risk assessment (PSSRA) and system security risk assessment (SSRA) at system level. Results flow both ways: aircraft-level threat conditions become security objectives allocated to systems, and system-level findings are rolled back up to show that the aircraft as a whole is protected.

What the companion methods document adds

DO-326A deliberately says little about specific techniques. DO-356A / ED-203A (2018) fills that gap with methods and considerations, including:

• How to identify assets, threat sources, vulnerabilities and attack vectors, and how to model threat scenarios.
• How to rate the level of threat for a scenario, from very high to extremely low, considering factors such as exposure and the capability an attacker would need.
• A risk acceptability matrix that sets which combinations of severity and level of threat are acceptable. The pattern is intuitive: the more severe the threat condition, the lower the level of threat must be. A catastrophic threat condition is only acceptable when the level of threat is extremely low, while threat conditions with no safety effect or a minor effect are acceptable at any level.
• Security assurance levels 0 to 3 for measures, with objectives for each level covering development and security-specific verification.
• Considerations for security architecture, security requirements, verification, configuration management, tool security and continued effectiveness after entry into service.

Security assurance levels in plain words

DO-356A uses four levels. SAL 3 is the strongest: all of the document's assurance objectives apply. SAL 2 keeps the same security-specific objectives (such as attempts to defeat the measure) but asks for noticeably less development rigour. SAL 1 is minimum assurance, suitable for measures that add hardening or resilience on top of stronger ones. SAL 0 means the item gives no protective effect that is relied on; only the initial assessment applies. A measure protecting against a severe threat condition with a high level of threat will usually need a higher SAL than one that adds a second layer behind an already strong barrier.

The continuing airworthiness document

DO-355A / ED-204A (2020) covers what happens after certification: operation, support, maintenance, administration and decommissioning. It gives guidance to design approval holders and operators on keeping the security measures effective, for example managing software and data loads, handling security events and keeping maintenance laptops and ground systems trustworthy. DO-326A's final step must therefore produce instructions that the operator can actually follow in service.

Other parts of the family

The family has grown. RTCA lists a framework guidance document for aeronautical information system security (DO-391), guidance on information security event management (DO-392), and a process standard for the security certification and declaration of ground air traffic management systems (DO-393). In 2026 EUROCAE also published ER-042 (identical to RTCA RR-003), a set of frequently asked questions and discussion papers that clarify the methods document. You do not need these to understand DO-326A, but you should know they exist when a project touches ground systems or in-service event handling.

Lesson 4 – How the process works in practice

Step 1 – Planning

The PSecAC is the contract between applicant and authority. It describes the product and its intended connectivity, the security scope at a high level, the process and methods (usually by reference to DO-356A), the acceptability criteria, who is responsible for what across the aircraft manufacturer and suppliers, the evidence that will be produced, and how independence and configuration management will be handled. Like the plan for software aspects of certification in DO-178C, the PSecAC is a living document: it is submitted early, discussed with the authority, and updated if the project changes. A weak or late plan is the single biggest cause of painful surprises later, because the authority cannot agree to an approach it has never seen.

Step 2 – Scope definition

Scope definition answers three questions: what are we protecting, where does our responsibility end, and what surrounds us? The team identifies the aircraft functions involved, the equipment and software that implement them and the data they rely on. It draws the security perimeter and lists every interface that crosses it: data buses to other systems, network ports, wireless links, removable media, maintenance connectors and data loaders. It describes the security environment: the passengers, crew, maintenance organisations, airline ground networks, satellite service providers and manufacturers' support systems that might interact with the system. It also records assumptions, such as "the airline's ground loading station is operated under its security programme". Assumptions are legitimate, but each one becomes a requirement or guidance item for someone else, and the authority will ask how it is enforced.

Many projects use the well-known split of the aircraft network into domains: an aircraft control domain (flight-critical and safety-related functions), an airline information services domain (operational and administrative functions such as maintenance and flight bags) and a passenger information and entertainment domain (cabin entertainment, connectivity and passenger devices), plus the passenger's own devices outside the aircraft's design control. These domains come from industry aircraft network practice rather than from DO-326A itself, but they are a helpful way to see where trust changes. Traffic from less trusted domains towards more trusted ones is where most analysis effort goes.

Step 3 – Risk assessment

Risk assessment has two halves that eventually meet. The top-down half starts from aircraft functions and asks which unwanted states would affect safety: these are the threat conditions, and each receives a severity from the same scale used by the safety assessment. Often the safety team's functional hazard assessment already describes similar failure conditions, and security engineers reuse its severity classifications. Some threat conditions, however, have no safety counterpart, for instance an attacker deliberately causing two independent systems to fail at the same moment, which random failure analysis would treat as extremely unlikely.

The bottom-up half starts from the scope: assets, interfaces, threat sources and vulnerabilities. Engineers construct threat scenarios that link an entry point to a threat condition through a chain of steps. For each scenario they rate the level of threat, considering how exposed the entry point is (anyone on board, only maintenance staff, only someone with physical access to an equipment bay), what knowledge and tools an attacker would need, and what measures already stand in the way. The result is a list of threat conditions, each with its scenarios, severity and level of threat, which together give the security risk.

Step 4 – Deciding acceptability

Each threat condition is placed on the acceptability matrix agreed in the PSecAC, normally the one from DO-356A. If the combination is acceptable, the risk is recorded with its justification. If it is not, the team has two broad options: reduce the level of threat by adding or strengthening measures, or reduce the severity by changing the architecture, for example by removing a data path or limiting what a command can do. Accepting an unacceptable risk because it is "unlikely in practice" is not an option the process allows; the matrix is the agreed rule.

Step 5 – Security development

Measures are turned into security requirements and developed like any other part of the design, alongside the normal system, software and hardware processes. Typical measures include network segregation, one-way data flow devices, filtering gateways, authentication and integrity checks on loaded software and data, protection of maintenance functions behind authenticated access, logging that supports detection, and procedures for operators. Each measure gets a SAL, and the development of that measure follows the objectives for that SAL. Because many measures are implemented in software or complex hardware, their development also falls under DO-178C or DO-254, and the two sets of objectives are coordinated rather than duplicated.

Step 6 – Security effectiveness assurance

Ordinary verification asks whether a requirement is met. Security effectiveness assurance asks a harder question: does the measure actually stop the threat scenarios it was meant to stop, and can it be bypassed? Activities include reviewing the architecture for paths that skip the measure, testing security requirements, testing with malformed and hostile inputs, scanning for known vulnerabilities in commercial components, and security refutation, a structured attempt by people with an attacker's mindset to defeat the measures (penetration testing is one form of it). The results feed back into the risk assessment. If testers find a bypass, the level of threat goes back up, and the loop runs again.

Step 7 – Communicating evidence

The PSecAC Summary tells the authority what was done compared with the plan, lists the risk assessment results and residual risks, summarises verification and refutation results, records deviations and open problems, and identifies the security guidance for operators: the instructions for continued airworthiness, maintenance procedures, configuration limits and assumptions the operator must uphold. This last item is the hand-over to DO-355A and to the operator's security programme. A design whose protection depends on, say, the airline never connecting an unmanaged laptop must state that clearly, or the protection will quietly disappear in service.

Roles and artefacts

Role	Typical responsibilities	Main artefacts
Applicant (aircraft or modification design holder)	Owns the PSecAC, aircraft-level scope and assessments, final compliance statement	PSecAC, PASRA / ASRA, PSecAC Summary, operator guidance
System and equipment suppliers	System-level scope, assessments and measures, evidence for their items	System security plans, PSSRA / SSRA, verification and refutation reports
Safety team	Severity classifications, consistency with safety assessment	Functional hazard assessment inputs, cross-references
Security verification and refutation team	Testing, vulnerability analysis, attempts to defeat measures	Test procedures and results, refutation reports
Authority or its designees	Agree the plan, review evidence, make the compliance finding	Certification review items or issue papers, findings

Lesson 5 – Assessment, approval and compliance

Approval happens through certification, not a certificate

There is no certification scheme that awards a company or a product a "DO-326A certificate". Compliance is shown as part of an aircraft, engine, propeller or equipment approval: a type certificate, a change or supplemental type certificate, or a European technical standard order authorisation. The applicant proposes DO-326A / ED-202A as the means of compliance with the applicable security requirement, the authority agrees, and the authority (or people it has authorised) reviews the evidence before making a finding of compliance. A supplier may say that its equipment was "developed in line with DO-326A and DO-356A", which is useful, but the final finding is made for the installation on a specific aircraft, because risk depends on how the equipment is connected and used.

How authorities set the requirement

In the European Union, the 2020 EASA decision introduced paragraphs in the certification specifications that require information security risks to safety to be identified, assessed and mitigated and that require guidance for continued airworthiness; for large aeroplanes this is CS-25.1319. AMC 20-42 explains how applicants can meet those requirements and recognises the ED-202A family. When a project has unusual features, EASA records the agreed approach in a certification review item. In the United States, the FAA has applied special conditions and issue papers to individual projects. Its 2024 proposal would add a general requirement for transport aeroplanes (section 25.1319) and similar requirements for engine and propeller control systems, supported by a new advisory circular. Until a final rule appears, check the special conditions and issue papers for each project.

What reviewers look for

• A plan agreed early. The PSecAC submitted at the start, with the scope, acceptability criteria, SAL approach and supplier responsibilities clearly stated.
• A complete scope. Every external interface identified, including maintenance and data loading paths, which are easy to forget.
• Traceability. A visible chain from threat condition to threat scenarios, from scenarios to measures, from measures to requirements and from requirements to verification and refutation results.
• Credible levels of threat. Ratings justified by exposure and attacker capability, not by optimism.
• Effective measures. Evidence that measures were tested against attack, not only against their functional requirements.
• Consistency with safety. Severity classifications that match the safety assessment, and a clear explanation where security threat conditions have no safety counterpart.
• Usable operator guidance. Instructions that an airline can follow, with assumptions turned into concrete procedures.

Reviews during the project

Authorities rarely wait until the end. Typical practice is a series of involvement points: review of the plan, a review of the scope and preliminary risk assessment while the architecture can still change, reviews of development and verification evidence, and a final review of the PSecAC Summary. The depth of involvement depends on novelty, the severity of the threat conditions and the applicant's track record. Large organisations may use authorised designees, such as engineers in an FAA organisation designation authorisation or staff in an EASA-approved design organisation with privileges, but the regulatory responsibility stays with the authority.

After approval

Compliance does not end at certification. New vulnerabilities in commercial software are found every month, attackers learn, and operators change their ground systems. DO-355A / ED-204A provides guidance for managing that change: monitoring vulnerabilities, assessing their impact, updating software in a controlled way and handling security events. In Europe, organisations in many aviation domains must also run an information security management system under the Part-IS regulations, which apply from 2025 and 2026 depending on the type of organisation. Together these mean that the design holder and the operator share responsibility for keeping the protection effective over decades of service.

Lesson 6 – Worked example: adding passenger connectivity to an in-service airliner

NorthWind Aero Modifications (a fictional design organisation) is developing a supplemental type certificate to install a cabin connectivity system on a fleet of narrow-body airliners. The system has a satellite terminal, a cabin server, wireless access points for passengers and a moving map that shows the aircraft's position. To draw the map, the server needs position and altitude from the aircraft's avionics. The airline also wants to use the same server to send maintenance messages to the ground. Here is how NorthWind applies the seven steps.

Step 1 – Plan

NorthWind drafts a PSecAC before detailed design. It states that the project follows DO-326A / ED-202A with methods from DO-356A / ED-203A, adopts the DO-356A acceptability matrix and SAL approach, and identifies the satellite terminal supplier and the cabin server supplier as responsible for system-level assessments of their equipment. It names an independent internal team for security refutation. The authority reviews the draft and asks NorthWind to add the maintenance laptop used to load server software to the scope; the plan is updated.

Step 2 – Scope

The security perimeter includes the cabin server, access points, satellite terminal, the interface between the server and the aircraft's avionics data source, and the software loading path. The security environment includes up to 180 passengers with their own devices, the satellite service provider's ground network, the airline's maintenance ground system and the maintenance laptop. Assets include the avionics interface (because it is the bridge to the aircraft control domain), the server software image, the maintenance messages and the moving-map display function. A key assumption is recorded: the existing avionics are approved and are not changed by this modification.

Step 3 – Risk assessment

Working top-down with the aircraft manufacturer's safety data, the team identifies three threat conditions of interest:

• TC-1: corrupted data injected through the avionics interface causes misleading information on flight-deck displays. The safety assessment for similar conditions supports a hazardous severity.
• TC-2: false maintenance messages lead the airline to defer a real defect or perform unnecessary work. After analysis with the airline's maintenance experts, the team classifies the potential effect as minor, because crews and maintenance procedures check defects independently.
• TC-3: loss or corruption of the passenger service and moving map. Classified as no safety effect.

Working bottom-up, the team writes threat scenarios. The most important one for TC-1: a passenger joins the cabin Wi-Fi, exploits a vulnerability in the server's web portal, gains control of the server and sends crafted messages through the avionics interface. Because the entry point is open to any passenger and attack tools for web servers are widely available, the team rates the level of threat as high for the initial design, which used a two-way network connection to the avionics.

Step 4 – Decision

A hazardous threat condition with a high level of threat falls in the unacceptable area of the matrix. TC-2 (minor) and TC-3 (no safety effect) are acceptable as they stand, and their reasoning is recorded.

Step 5 – Development

NorthWind changes the architecture rather than relying on server hardening alone. A hardware unidirectional gateway is placed between the avionics and the cabin server, so data can only flow from the avionics to the server, never back. Behind it, the server is hardened, the passenger portal runs in a separate partition, and software loading requires a digitally signed image checked by the server before installation. The team assigns a SAL to each measure: the unidirectional gateway is the main barrier against TC-1 and is developed at a high SAL; server hardening and the separate partition are additional layers with a lower SAL. Security requirements are written for each measure and traced to the threat scenarios they address.

Step 6 – Effectiveness

The gateway is analysed to show that its hardware cannot pass data in the reverse direction, and it is tested with hostile traffic. The refutation team, acting as passengers, attacks the portal, tries to escalate privileges on the server and then tries to send anything back towards the avionics. They find a configuration error that exposed a debug service on the passenger network; it is fixed, the test is repeated, and the finding is recorded. With the gateway shown to be effective, the level of threat for TC-1 is re-rated as extremely low, because the only remaining routes require physical access to the equipment bay, which is outside the electronic scope and controlled by the operator.

Step 7 – Evidence and hand-over

The PSecAC Summary records the final risk table, the measures and their SALs, the refutation results including the fixed finding, and the residual risks. It includes operator guidance: the maintenance laptop must be a managed device with the airline's security controls, signing keys must be protected by the airline and the supplier, server software must be updated through the approved signed process, and suspected security events must be reported to NorthWind. These items feed the airline's continuing airworthiness security programme under DO-355A / ED-204A guidance. The authority reviews the evidence and makes its finding as part of the supplemental type certificate.

What the example teaches

The decisive improvement came from architecture, not from patching: the one-way gateway removed the attack path for the most severe threat condition, which is far stronger than trying to make a passenger-facing server perfect. The example also shows how assumptions become operator obligations, why maintenance paths must be in scope from the start, and why refutation finds problems that functional testing misses.

Lesson 7 – Relationship to other standards and frameworks

DO-326A does not stand alone. It was written to slot into the existing aviation development and certification framework, and it shares ideas with cybersecurity standards in other industries. The table compares the main neighbours.

Standard or framework	Focus	Relationship to DO-326A / ED-202A
DO-356A / ED-203A	Methods for airworthiness security	Companion that explains how to perform the DO-326A activities: levels of threat, acceptability matrix, SALs, refutation
DO-355A / ED-204A	Security during continuing airworthiness	Picks up the operator guidance and keeps measures effective in service
SAE ARP4754A/B and ARP4761	Aircraft and system development assurance and safety assessment	Provide the development framework and the severity classifications that security risk assessment reuses; DO-326A mirrors their aircraft and system levels
DO-178C / ED-12C and DO-254 / ED-80	Assurance of airborne software and complex hardware	Govern how security measures implemented in software or hardware are developed; coordinated with SAL objectives
EU Part-IS regulations	Organisational information security management for aviation organisations	Covers the organisation and its processes; DO-326A covers the product design
ISO/SAE 21434	Cybersecurity engineering for road vehicles	Similar risk-based logic in the automotive sector, with its own terms and assurance levels
IEC 62443	Security of industrial automation and control systems	Shares zones, conduits and security levels ideas; used for ground and industrial systems rather than aircraft type certification
Common Criteria (ISO/IEC 15408)	Evaluation of security products against protection profiles	DO-356A refers to it as a non-aviation security standard and relates some of its objectives to Common Criteria classes, but an evaluation is not a substitute for the airworthiness process

Security and safety working together

The most important relationship is with safety assessment. Security engineers depend on the safety team's understanding of which aircraft functions matter and how severe their loss or corruption would be. Safety engineers, in turn, need security results, because security measures can affect availability and because some threat conditions combine failures in ways random-failure analysis does not consider. Many organisations hold joint reviews and keep shared identifiers so that a threat condition and its related failure condition can be traced to each other.

Security and development assurance

A software component can carry both a DO-178C level and a SAL. The level says how much rigour the software needs because of its safety role; the SAL says how much rigour is needed for its security role. Planning both at the same time avoids duplicate reviews and conflicting evidence. For example, security requirements for a loading function can sit in the same requirements database as functional requirements, with attributes showing their security origin and SAL.

Product security versus organisational security

Engineers new to aviation sometimes assume that an organisation-wide information security management system, such as one based on ISO/IEC 27001 or Part-IS, covers aircraft design. It does not. Organisational frameworks protect the company's information and processes; DO-326A shows that a particular aircraft design is protected against electronic attack. A mature company needs both: the organisational controls protect, for example, the signing keys and the development environment that the product's security measures depend on.

Lessons from other sectors

If you come from automotive or industrial security, much will feel familiar: asset identification, threat scenarios, risk ratings and assurance levels. The differences are the certification context (an authority must agree the approach and find compliance), the explicit link to the safety severity scale, the long service life of aircraft and the strict separation between safety effects, which DO-326A covers, and other security concerns such as privacy or commercial data, which it does not.

Common pitfalls and best practices

Pitfalls seen on real projects:

• Starting security after the architecture is frozen. The cheapest and strongest mitigations are architectural; once the design is fixed, only add-on measures remain.
• Forgetting maintenance and loading paths. Teams model passenger and ground links but miss the laptop, USB port or data loader that has direct access to critical software.
• Treating the level of threat like a failure probability. Arguing that an attack is "rare" ignores that attackers choose their target and repeat attempts.
• Testing only functions, not defeat. Showing that a firewall rule exists is not the same as showing that a determined tester cannot get around it.
• Leaving assumptions unenforced. An assumption such as "only trusted staff connect to this port" means nothing unless it becomes operator guidance and a procedure.
• Claiming that equipment is "DO-326A certified". There is no such certificate; compliance is found for an installation within an approval.
• Mixing safety and non-safety concerns. Inflating the assessment with privacy or revenue risks hides the safety-relevant ones; handle them in separate processes.

Best practices:

• Agree the PSecAC early and revisit it when the design or supplier responsibilities change.
• Prefer architectural measures such as segregation and one-way data flow for the most severe threat conditions, then add layers.
• Keep end-to-end traceability from threat conditions to scenarios, measures, requirements, verification and refutation results.
• Use independent, attacker-minded refutation and feed its findings back into the risk assessment.
• Work jointly with the safety team on severity classifications and on threat conditions that have no safety counterpart.
• Write operator guidance as concrete procedures and confirm with an airline that they are practical.
• Plan for the service life: vulnerability monitoring, signed updates and an event reporting route from day one.

Summary and key takeaways

• DO-326A / ED-202A is the joint RTCA and EUROCAE process specification for showing that intentional unauthorised electronic interaction cannot make an aircraft unsafe.
• Its scope is safety effects only; physical attacks, jamming, privacy and commercial risks are outside it.
• The process has seven steps: plan, define scope, assess risk, decide acceptability, develop measures, assure their effectiveness and communicate evidence, with a loop until all risks are acceptable.
• Risk combines the severity of a threat condition, taken from the safety scale, with a level of threat for the scenarios that could cause it.
• DO-356A / ED-203A supplies the methods, including the acceptability matrix and security assurance levels 0 to 3; DO-355A / ED-204A carries security into service.
• Compliance is found by an authority within a type or supplemental type certificate or equipment approval; there is no stand-alone certificate.
• Strong designs remove attack paths architecturally, keep traceability, test measures against attack and turn assumptions into operator procedures.
• A B revision (ED-202B / DO-326B) was published in 2024, while current EASA guidance still cites the A revision, so confirm the required revision with your authority.

Reflection questions

1. Think of a connected system you know (in aviation or another industry). Where would you draw the security perimeter, and which three interfaces would you analyse first?
2. Pick one threat condition for an aircraft function you understand. Describe two different threat scenarios that could lead to it and explain which would have the higher level of threat and why.
3. In the worked example, the team chose a one-way gateway instead of hardening the server further. What would the residual risk discussion have looked like if they had relied on hardening alone?
4. Which assumptions in a design you work on depend on how an operator or customer behaves, and how would you turn them into guidance they can follow?
5. How would you organise joint reviews between safety and security engineers so that severity classifications stay consistent as the design changes?

Further reading and official sources

• Aeronautical Information Systems Security (SC-216) and the DO-326 family – RTCA
• ED-202B / DO-326B Airworthiness Security and WG-72 documents – EUROCAE
• ED Decision 2020/006/R – Aircraft cybersecurity – European Union Aviation Safety Agency
• ER-042 published: discussions related to AISS standards – EASA Community
• Equipment, Systems, and Network Information Security Protection (proposed rule) – FAA, Federal Register
• A Security Strategy for Avionics Systems – Wind River

Original tutorial by xOps School (DevOpsSchool Private Limited), written from public sources about RTCA DO-326A / EUROCAE ED-202A. Not affiliated with or endorsed by the standard's owner; standard names are trademarks of their owners. Buy the official standard from its publisher for the authoritative text.