DO-326A flight deck
DO-326A airworthiness security evidence support for flight-deck equipment
This support checks a flight-deck equipment item's airworthiness security evidence against the DO-326A process before submittal or during a finding. It is run by the equipment supplier or the modifier installing the unit, once the item is understood to sit inside the aircraft security perimeter. The work examines the security scoping, the threat conditions identified, the security measures and their effectiveness argument, and how the flight-deck interfaces and data loading paths were assessed. You get a standards map to the DO-326A objectives, an evidence gap list ranked by what blocks the finding, and a closure sequence.
When this review is needed
- A flight-deck unit is being submitted and its airworthiness security scope has not been checked against DO-326A.
- An authority raised a security finding because the equipment's connectivity was not reflected in the security scoping.
- A maintenance data-loading port or wireless interface was added and its threat conditions were never assessed.
- The item was scoped as not security-relevant, but a new interface pulls it inside the aircraft security perimeter.
The problem
The hardest DO-326A question for flight-deck equipment is the first one: is this item in scope at all. A unit that once stood alone now carries a maintenance loading port, a database uplink, or a shared bus, and each interface can move it inside the aircraft security perimeter. Suppliers who scoped the item out early keep a security assessment that says nothing about the connection the authority is now asking about, and reopening the scope late means the threat conditions, measures, and effectiveness argument all get built under finding pressure.
What gets reviewed
- Security scoping deciding whether the flight-deck item sits inside the aircraft security perimeter
- Threat conditions identified for the unit's interfaces and data paths
- Security measures and the effectiveness argument that supports each
- Data-loading, database-update, and maintenance-access paths and their controls
- Shared-bus and connectivity interfaces that couple the item to other systems
- Security-related derived requirements fed back to the equipment requirements set
What gets validated
- The scoping decision reflects every current interface, including maintenance and update paths
- Each identified threat condition maps to a security measure with a stated effectiveness argument
- Data-loading and database paths have controls consistent with the threat conditions they carry
- Security-related derived requirements appear in the equipment baseline and trace to verification
- The item's coupling to other systems over shared buses is reflected in the threat model
Evidence normally required
- The DO-326A plan for security aspects of certification and the security scoping rationale
- The threat condition and security risk assessment for the equipment
- Interface control documents covering data loading, updates, and shared buses
- Security measure descriptions and their effectiveness substantiation
- The equipment requirements baseline and its trace to security-derived requirements
Common discrepancies
- An item scoped out of DO-326A despite a maintenance or update interface that connects it
- A threat condition with no security measure mapped to it
- A data-loading path whose controls do not match the threat conditions it carries
- Security-derived requirements that never reached the equipment requirements baseline
What is at stake
A flight-deck item scoped out of DO-326A that turns out to be connected leaves the aircraft-level security case with an unassessed entry point. The finding response then has to establish the threat conditions, justify the security measures, and argue their effectiveness from a standing start, which is slow when the design is frozen and the schedule is not.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Settle the scope
Confirm whether the flight-deck item is inside the aircraft security perimeter against all current interfaces.
Map threats to measures
Check each identified threat condition maps to a security measure with an effectiveness argument.
Trace the data paths
Verify data-loading, update, and shared-bus controls match the threat conditions they carry.
Sequence the closure
Rank the gaps and flag where a scoping change forces downstream rework.
What the buyer receives
- A standards map to the DO-326A objectives for the flight-deck item
- An evidence gap list ranked by what blocks the finding or the submittal
- A closure sequence noting where a scoping change reopens downstream evidence
Who uses the output
- Certification leads deciding and defending the item's DO-326A scope
- Security and systems engineers mapping threat conditions to measures
- Compliance managers responding to a security finding on the flight-deck unit
How the work fits into the transaction or program
This review connects the flight-deck item's security assessment to the aircraft-level security case that DO-326A governs. It confirms the scoping decision holds against the item's real interfaces, so the unit enters the compliance matrix with a security position that will not be reopened by an interface the authority notices first.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
EASA references the DO-326A security process explicitly in its special conditions, and the FAA reaches the same objectives through its own issue papers. The map notes where the two authorities word the security scope differently so a package built for one reviewer does not stall on terminology with the other.
Regulatory limits
This work maps and checks the airworthiness security evidence against DO-326A. It does not perform penetration testing, decide the item's security scope for the authority, or make an airworthiness determination. Those decisions stay with the applicant and the certifying authority.
What this review does not cover
- Penetration testing or vulnerability scanning of the equipment
- Authoring the threat assessment or security measures from scratch
- Any determination that the flight-deck equipment is airworthy or approvable
Specific to this review
- The scoping decision, whether the item is inside the aircraft security perimeter, drives everything else in a DO-326A case and is the most common thing done wrong on flight-deck equipment.
- A maintenance loading port is the quiet interface that pulls an otherwise standalone unit into scope, and it is easy to leave out of the threat model.
- Reopening scope late is expensive because the threat conditions, measures, and effectiveness argument all have to be built at once against a frozen design.
Sources
RTCA. Airworthiness security process objectives for aircraft systems exposed to intentional unauthorized electronic interaction.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Our unit was scoped out of security years ago. Why revisit it now?
Scope follows connectivity. If the item gained a maintenance loading port, a database uplink, or a shared bus since the original assessment, it may now sit inside the aircraft security perimeter. The review checks the scoping decision against the item's real interfaces before an authority does.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.