What Is DO-326A? A Practical Guide to Aviation Cybersecurity Traceability

June 22, 2026
Reading Time: 6 minutes

Listen to this blog

Nowadays, security has become a primary challenge for modern aircraft systems, and the reason is straightforward: Modern aircraft and aviation networks are widely connected with the internet and private networks, regularly exchange data with the ground stations, and have maintenance laptops that plug directly into the avionics buses. Every one of these connections expands the attack surface.

Furthermore, cyber attacks rose by 131% between 2022 and 2023 across the aviation industry, with the highest proportion of attacks focused on airspace users. This increases concerns related to aircraft security.

On the other hand, safety standards like DO-178C and DO-254 provide rules and regulations for building aircraft software and hardware and handling accidental failures, but do not offer anything to secure the digital systems of aircraft from intentional attacks. DO-326A fills that gap.

In this blog, you will cover what DO-326A is, what it covers, and why traceability is important while implementing DO-326.

What Is DO-326A and Who Needs to Comply With It?

The DO-326A, also known as the Airworthiness Security Process Specification, is a regulatory standard published jointly by RTCA (Radio Technical Commission for Aeronautics) and EUROCAE (European Organization for Civil Aviation Equipment). It defines how aircraft developers should identify, assess, and mitigate international cybersecurity threats as a part of the certification process.

It was published in 2007, and the latest revision was done in 2014. According to DO-326A, anyone deploying new digital systems into the aircraft is obligated to demonstrate the safety measures that are in place. It is not just for companies that are developing Boeing and Airbus, but if your company makes any of the components of an aircraft system, then you need to comply with DO-326A:

An in-flight entertainment (IFE) system
A Wi-Fi or satellite connectivity solution
A navigation database updater
A new flight management computer
Ground support equipment (GSE) that connects to the aircraft
An electronic flight bag (EFB) system

However, DO-326A does not offer any guidance on physical attacks (e.g., bomb threats, someone breaking into an aircraft hangar, etc.).

The DO-326A Standard Set: What Each Document Actually Does

DO-326A contains multiple documents, and each of them covers different phases of aircraft security. Most certification programs reference at least three of them, so here we have covered a few documents from them:

Document	Titre	What It Covers
DO-326A / ED-202A	Airworthiness Security Process Specification	It is a top-level framework that defines the 7-step security process, which covers the following steps: Plan for the security aspect of Certification Security scope definition Security risk assessment Risk acceptability Security development Security effectiveness assurance Communication of evidence This is the “what to do” document.
DO-356A / ED-203A	Airworthiness Security Methods and Considerations	It provides exact methods, risk assessment, and security architecture needed to protect aircraft airworthiness from intentional and unauthorized electronic interactions that could compromise safety.
DO-355 / ED-204	Information Security Guidance for Continuing Airworthiness	Takes over after entry into service. Covers software updates, maintenance access, vulnerability response, and operator security obligations throughout the aircraft’s operational life.
DO-392 / ED-206	Security Event Management	Governs incident detection, reporting, and response when a security event occurs on an in-service aircraft or system.

DO-326A vs. DO-178C, DO-254, and ARP4754A: Safety Is Not Security

DO-178C, DO-254, and ARP4754A are a must to follow while developing aircraft. DO-178C covers rules and regulations about how software development should be done for aircraft systems. DO-254 covers how airborne electronic hardware should be developed and tested. On the other hand, ARP4754A sits on top of these two, which covers how to manage safety requirements for any aircraft at the system level. All three regulations are built around one core assumption, that is, failure happens by accident.

These 3 safety standards require teams to determine the probability of component failure and, based on its consequences, develop an aviation plan. But DO-326A also forces teams to think about what a capable, motivated attacker could do and whether the system withstands it. Probability alone is not enough when the threat is intentional.

In 2015, one of the cybersecurity researchers used his laptop to successfully hack the network of a commercial flight and make it fly higher than the pilot intended by accessing the thrust system. Similarly, they can hack the whole commercial flight system and take control, and it could be very risky.

That’s why cybersecurity guidance was deliberately separated from DO-178C and DO-254, keeping in mind that security requires its own discipline, its own risk assessment process, and its own certification evidence.

Why Traceability Is the Hardest Part of DO-326A Compliance

During the regulatory submission, auditors expect the specific chain and linkage between: threat condition -> security objective -> security requirement -> design mitigation -> verification evidence. That’s why it becomes important to manage security risk assessment traceability, and here is why maintaining that chain is genuinely difficult:

- Disconnected tools: When teams use Microsoft Word documents and spreadsheets to manage DO-326A security requirements, the link between those becomes outdated when something changes, and manually handling and updating those links is next to impossible.

Teams need bi-directional traceability: DO-326A requires teams to address requirements from an epic to the test and test to top-level work items, in both directions, as one-way traceability is not enough for certification submissions.
Safety and security traceability need to run in parallel: Security assurance levels in DO-356A are tied to safety failure condition categories from ARP4754A. So changes to the safety assessment can affect security requirements. That’s why there should be a single source of truth to manage safety and security requirements and their traceability together.
14 artifacts must cross-reference each other: The 7-step security implementation process offered by DO-326A / ED-202A produces 14 specific documents. The SSRA references the ASRA. Similarly, the ASAM references the SSRA. In this case, if any cross-reference is missing or outdated, the entire evidence package can have a gap.

Building DO-326A Traceability in Azure DevOps with Modern Requirements4DevOps

Modern Requirements4DevOps is a requirement management tool that works directly within Azure DevOps and is widely used by aerospace teams working inside Azure DevOps. Here is how it helps in managing DO-326A compliance traceability:

Offers a single source of truth: Teams can use Azure DevOps to manage DO-326A-related security requirements, documents, and test cases. With that, the Modern Requirement4DevOps can be used to create live traceability metrics for thousands of work items within seconds and without switching between tools.
Trace every security requirement to a test result in one view: The horizontal traceability matrix allows teams to trace from top-level security work items like epics to low-level work items like test cases and tasks into the single interface. It can also be exported in Excel format to submit for regulatory certification. With these, teams can directly identify coverage gaps during the development process, not after.

Map coverage between any two types of work items: The intersectional traceability matrix allows teams to visualize the linkage between any two types of work items. Let’s say you want to analyze how DO-326A user stories are covered by test cases. Then, you can just directly create an intersectional matrix with a single click and analyze the gaps.

Create live traceability matrices: After updating requirements, you can directly create a new traceability matrix with updated requirements. So, the team always works based on current requirements.

Commencez dès aujourd'hui à utiliser Modern Requirements

✅ Définissez, gérez et suivez les exigences dans Azure DevOps
✅ Collaborez en toute fluidité entre équipes soumises à des réglementations
✅ Commencez GRATUITEMENT — aucune carte de crédit requise

Start Free Trial