Airworthiness security
DO-326A airworthiness-security support for airborne systems
DO-326A airworthiness-security support helps an avionics or equipment supplier show that a system addresses intentional unauthorized electronic interaction the way the airworthiness security process requires. It is used by systems teams whose security assessment was added later than the safety case and may not connect to the architecture or the security measures actually implemented. The work reviews the security scope and perimeter, the security risk assessment and its threat scenarios, the security measures and their effectiveness, and the verification evidence and security guidance carried into continued airworthiness. You receive a security-process gap assessment, a threat-scenario to measure traceability view, and a prioritized list of the security evidence to close.
When this review is needed
- A system with external connectivity is heading for review and the airworthiness security evidence has to be checked against the process.
- The security assessment was added after the design closed and the threat scenarios do not yet map to the architecture as built.
- Security measures were specified but their effectiveness against the identified threat conditions has not been demonstrated.
- Field-loadable software, maintenance interfaces, or data links create attack paths the original assessment did not consider.
- A supplier wants an independent read of the security case before it feeds a wider certification submittal.
The problem
Airworthiness security is newer than the safety discipline beside it, and it is usually bolted on after the architecture is set rather than developed with it. The security scope and perimeter get drawn loosely, threat scenarios are listed without being tied to the assets and entry points that matter, and security measures are named without evidence that they actually reduce the risk to an acceptable level. The link to the safety assessment, where a security threat can become a safety effect, is often missing entirely.
What gets reviewed
- The security scope and the perimeter that bounds what the assessment covers
- Asset identification and the entry points exposed to intentional unauthorized electronic interaction
- The security risk assessment and the threat scenarios and conditions it identifies
- Security measures and the evidence that each reduces its threat condition to an acceptable level
- The link between security threat conditions and the safety effects they could cause
- Security verification and the records that demonstrate the measures work as claimed
- Security guidance carried into continued airworthiness and the operator and maintainer
What gets validated
- The perimeter and scope are defined and bound the assessment consistently
- Each threat scenario traces to an asset, an entry point, and the threat condition it creates
- Every threat condition has a measure and evidence that it is reduced to an acceptable level
- Threat conditions with a possible safety effect are linked to the safety assessment
- Verification records demonstrate the measures behave as the assessment claims
- Field-loadable software, data links, and maintenance access are treated as entry points
- Continued-airworthiness security guidance reaches the operator and maintainer who need it
Evidence normally required
- The scope and perimeter definition and the architecture it covers
- The risk assessment, including the asset list and threat scenarios
- The measures specified and any effectiveness evidence assembled so far
- Verification records and security test results
- The safety assessment, so threat conditions can be linked to safety effects
- Any in-service guidance drafted for operators and maintainers
Common discrepancies
- A perimeter drawn loosely, leaving entry points outside the assessed scope
- Threat scenarios listed without a trace to the assets and entry points they exploit
- Measures named with no evidence they reduce the threat condition to an acceptable level
- Threat conditions with a safety effect that were never linked to the safety assessment
- Field-loadable software or a maintenance interface omitted as an entry point
- Verification that exercises the measure but not the threat condition it must counter
- In-service security guidance missing from the package entirely
What is at stake
When the security risk assessment does not close the threat conditions it identifies, the review cannot accept the security case, and a system that is otherwise mature stalls on the security process alone. A missed attack path that reaches a safety-related function can force architecture changes or added measures late in the program, and the security guidance gap then follows the system into service as an unaddressed continued-airworthiness obligation.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Bound the scope
Confirm the security perimeter, the assets, and the entry points the assessment must cover for the installation.
Trace the threats
Map each threat scenario to its asset and entry point and to the threat condition it creates.
Test the measures
Check that each measure has effectiveness evidence and link any safety-relevant threat condition to the safety assessment.
Package the gaps
Produce a security-process gap assessment and a prioritized closure list, including the continued-airworthiness guidance.
What the buyer receives
- A security-process gap assessment against the airworthiness security process
- A threat-scenario to security-measure traceability view with effectiveness evidence flagged
- A list of threat conditions with a safety effect that need linking to the safety assessment
- A prioritized list of the security evidence and guidance to close before review
Who uses the output
- Certification leads preparing the airworthiness security submittal or review
- Security and systems engineering teams closing the assessment and measure gaps
- Continued-airworthiness teams building the security guidance for service
How the work fits into the transaction or program
The support strengthens the airworthiness security case and ties it back to the safety assessment, so a security threat that could become a safety effect is treated rather than missed. It pairs with safety-assessment and development-assurance support, since the security and safety processes share the architecture and inform each other.
Start with a single asset
Confirm requirements trace through verification.
Aircraft-specific considerations
The threat surface depends on how the system connects in a given aircraft, so the same equipment can need different security treatment across installations. A unit on an isolated bus carries fewer entry points than the same unit with a wireless data link or a shared maintenance interface, and connectivity to a more critical function raises the consequence of a successful attack, so the security risk assessment has to be argued against the actual installation rather than a generic connectivity model.
Regulatory limits
Endeavor Elements supports the applicant's airworthiness security data. It does not act as the authority or a delegate, make compliance findings, issue any approval, make airworthiness determinations, or guarantee acceptance. The applicant and the authority keep their roles, and the security risk acceptance remains the applicant's, supported by the assessment.
What this review does not cover
- Making official compliance findings, airworthiness determinations, or acting as the authority
- Issuing any approval, authorization, or design approval
- Performing penetration testing or building the security measures themselves
Specific to this review
- DO-326A addresses intentional unauthorized electronic interaction, a deliberate threat, which is a different concern from the random failures the safety process analyzes.
- The airworthiness security process runs in parallel with the safety process, and the link between them matters because a security threat condition can produce a safety effect.
- Security risk in DO-326A is assessed against threat scenarios tied to assets and entry points, so a perimeter drawn too loosely leaves real attack paths unassessed.
- Security guidance for continued airworthiness is part of the process, so a unit can be assessable in design yet incomplete because the in-service security instructions are missing.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Airworthiness security process objectives for aircraft systems exposed to intentional unauthorized electronic interaction.
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
Frequently asked questions
How is airworthiness security different from the safety assessment?
The safety process analyzes random and systematic failures. The airworthiness security process analyzes deliberate, intentional unauthorized electronic interaction. The review checks the security case on its own terms and confirms the link where a security threat could cause a safety effect.
Do you perform the penetration testing?
No. The review checks that the security risk assessment, the measures, and the verification evidence close the threat conditions the applicant identified, and it flags where the effectiveness evidence or the continued-airworthiness guidance is missing.
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.
Walk through your situation with an engineer who has done this work.