Securing the EFB: DO-326A, Hardening and Defense-in-Depth

EFB SERIES · PART 7 OF 8 — Technology, Security & Safety · Series Hub · ← Part 6 · Part 8 → (publishes Sep 11)

TL;DR — How do you secure an EFB? In five layers — hardened devices under MDM, signed applications and data, an AID-enforced aircraft-network boundary, a controlled ground/supply chain, and detection-plus-response — governed on the certified side by the DO-326A/ED-202A airworthiness-security family and, for operators, increasingly by EASA Part-IS. The practical deliverable is the 20-control operator checklist at the end of this post.

Part 6 drew six red figures on the EFB’s map and proved each one represents a real, researched attack class. Today every red figure gets its green counterpart. The organizing principle is defense-in-depth: no single control is load-bearing, because Part 6’s attack trees were all AND-chains — the attacker must win every node, while the defender only needs to break one per path. Stack enough independent breaks and the economics collapse in your favor.

The organizing rulebook is a family of three documents — DO-326A/ED-202A and its companions — that turned aviation security from folklore into certification discipline. We’ll start there, walk the five layers with concrete controls, and end with the checklist you can audit yourself against.

The Rulebook: Airworthiness Security Standards Explained

DO-326A/ED-202A is the process standard that made cybersecurity certifiable in aviation — a loop, not a checklist.

Table T7.1 — The DO-326A family interlock

The family’s logic runs: define the security scope (what assets, what zones, what interactions — effectively Part 6’s attack-surface map, done formally); assess security risk (threats mapped against those assets); develop and verify with security assurance (the DO-178C-style discipline, extended for adversarial failure); then — the part that distinguishes aviation from most industries — keep monitoring for the aircraft’s whole life, because adversaries improve after your certificate is issued. DO-326A/ED-202A became the accepted means of compliance for airworthiness security on both sides of the Atlantic, which is why every “how do I certify a connected aircraft system” conversation since the mid-2010s routes through it.

Where does the EFB sit in this? Split by Part 2’s boundary: installed/interfaced Type C-class systems ride the full DO-326A certification path; portable Type B estates mostly live on the operational side — where Part 5’s Part-IS (Regs (EU) 2022/1645 + 2023/203, applicable from October 2025 / February 2026) now obliges operators to manage information-security risk formally. Same ideas, different legal instrument.

Table T7.2 — for the security engineer: mapping to NIST CSF 2.0

Layer 1: Device Hardening and MDM — the Fleet’s Control Plane

Every guarantee downstream depends on the device being the device you think it is.

The controls are enterprise-standard, aviation-enforced: supervised/zero-touch enrollment (Apple DEP / Android enterprise equivalents) so devices are corporate-owned from first boot; full-disk encryption with PIN/biometric policy; app allow-listing with no sideloading — enterprise-signed applications only; accessory/USB restrictions that kill the juice-jack and malicious-cable classes from Part 6; per-app VPN so sync traffic can’t wander; and remote lock/wipe with a rehearsed lost-device procedure. Baselines exist for the taking — CIS Benchmarks and DISA STIGs for the mobile OSes — and Part 7’s checklist leans on them.

The genuinely aviation-specific tension is the patch paradox: consumer OS patches arrive weekly; an EFB program’s application and data versions were validated together (Part 4’s two-axis lock). Blind auto-updates could desync the axes; frozen devices accumulate vulnerabilities. Mature programs resolve it with a tested patch pipeline — staged OS updates validated against current and upcoming cycle formats, on a deadline measured in days, not quarters. If your program has no answer to “how fast do we patch a critical mobile-OS vulnerability fleet-wide?”, it doesn’t have a Layer 1.

Layer 2: Application and Data Integrity

Part 6’s poisoning tree had to defeat signatures — this layer is the signatures, done properly.

Application integrity first: code signing end-to-end — developer identity, enterprise or store distribution, on-device signature enforcement (the APK v2/v3 / iOS equivalents). No unsigned code runs; no repackaged app installs.

Then the data, which is where aviation’s version of this discipline gets interesting:

• Signed packages: every chart dataset ships with a detached signature or signed manifest — Part 4’s D4.4 flow, now armored.
• Pinned keys: the verifying keys ship inside the approved application build. Not fetched, not negotiable — which is what makes the aircraft’s offline status tolerable (Part 4’s PKI wrinkle: you can’t OCSP-check at 38,000 feet, so make revocation rare-by-construction: long-lived keys, HSM-protected, two-person release, rather than reachable-but-fragile).
• Hash manifests / hash trees over deltas: the device re-verifies every chunk it assembles locally — closing the “compromise one delta flight” gap.
• Anti-rollback: monotonic version counters so an attacker can’t serve the fleet a validly-signed old cycle as if current. Old signatures never expire; version logic must.

Get these four right and Part 6’s most-feared attack (subtle poisoning) needs a signing-key compromise to proceed — which moves the battle to Layer 4, where key compromise is hardest.

Layer 3: Aircraft Network and AID Isolation

Part 2’s border checkpoint becomes a security gateway: filter, whitelist, enforce one-way, watch the door.

The AID’s control list: label whitelisting (re-publish only the ARINC 429 parameters the EFB needs — nothing more); rate and behavior filtering on its outputs; secure boot and signed firmware on the AID itself (a gateway running poisoned firmware is a hollow defense); no write path, enforced — the one-way property as a design invariant, not a convention; and logging as an IDS source — the AID sees every parameter it serves; anomalies there are telemetry gold for Layer 5.

Around it: network segregation — cockpit-domain sync separated from cabin Wi-Fi and passenger systems; 802.1X / WPA3-Enterprise on ground sync so the rogue-AP class from Part 6 can’t even offer itself; and — the direct lesson of the 737 research — physical access control: locked and monitored hatches and ports, tamper-evident seals, ramp discipline that treats the data path as part of the security perimeter. Part 6 said physical access is a cyber boundary; this is that sentence implemented.

Layer 4: Ground Infrastructure and Supply Chain

Own the signing keys and the backend like the crown jewels they are — because they are.

Controls: HSM-held keys with two-person release — no single human can sign a fleet-wide package; least-privilege backend administration with per-device authentication for sync endpoints; signed releases from CI with reproducible builds where feasible (audit gold: anyone can rebuild the artifact and compare hashes); SBOMs (SPDX/CycloneDX) for EFB applications and AID firmware — the “are we running the poisoned build?” question answered in minutes; and a vendor security cadence — questionnaires, disclosure handling, patch SLAs — treating the chart vendor and the AID manufacturer as the critical suppliers they are. This layer is where this series rejoins this site’s existing supply-chain canon: the SolarWinds and xz lessons were general-purpose; the EFB estate simply raises the consequence.

Layer 5: Detection and Response

Assume someday something gets through — engineer the fleet to notice and revert.

Detection: fleet telemetry on the verification pipeline — signature-failure counts, update-adoption curves, sync-source anomalies. Part 6 observed that a poisoned push has a shape: unusual origin, unusual hash lineage, unusual timing. SIEM alerting on those shapes catches what Layers 1–4 slow down.

Response — the poisoned-dataset runbook: freeze the rollout; quarantine affected devices; revert the fleet to last-known-good cycle (which is why dual-cycle storage from Part 4 is a security feature, not just an AIRAC convenience); bridge operations with paper quick-reference items (Part 8’s reversion policy, weaponized for security); then report — internally to the accountable manager, externally to the NAA and the sector via A-ISAC. An operator that has rehearsed this runbook has a security program; one that would improvise it has a prayer.

The Operator Security Program: 20 Controls

Table T7.3 — the 20-control EFB security checklist (the printable version ships with the series PDF)

Breaking the Chain: The Series in One Image

Lay Part 6’s attack tree next to this post’s layers and the arithmetic appears: deliver a poisoned package dies at Layers 2 and 4; defeat integrity checks dies at pinned keys and anti-rollback; survive the activation window dies at dual-cycle storage plus telemetry; even the terminal node — crew acts on falsified data — meets the last green cut of cross-check culture and paper reversion, which is where Part 8 picks up the baton. Security controls and safety procedures are not two disciplines stitched together; on the EFB they are one system wearing two uniforms.

Tomorrow, Part 8 closes the series where the regulator’s hazard register always said it ends: batteries that burn, failure policies, the humans in the loop, the common-mode trap — and what the EFB becomes next.

Key Takeaways

• Defense-in-depth is economic, not aesthetic: Part 6’s AND-chains mean every independent control layer collapses an attacker’s probability.
• The rulebook: DO-326A/ED-202A (process) + DO-356A (methods) + DO-355 (continuing monitoring) — the loop that makes security certifiable; Part-IS carries operator-side obligations from 2025–2026.
• Layer 1 is MDM discipline plus a tested patch pipeline resolving the aviation patch paradox.
• Layer 2 is the signing chain: signed packages, pinned keys (offline-tolerant), hash trees over deltas, anti-rollback counters.
• Layer 3 turns the AID into a security gateway — whitelist, secure boot, enforced one-way — and the 737 lesson into physical access control.
• Layer 4 owns keys and vendors like critical infrastructure: HSM, two-person release, SBOMs.
• Layer 5 assumes breach: telemetry, anomaly shapes, and a rehearsed revert runbook — the 20-control checklist operationalizes all five.

FAQ

What is DO-326A?
RTCA DO-326A (EUROCAE twin: ED-202A) is the Airworthiness Security Process Specification — the accepted means of compliance for certifying cybersecurity in aircraft systems. It defines the security scope → risk assessment → assurance → continuous-monitoring loop, supported by DO-356A (methods) and DO-355 (continuing airworthiness security).

How are EFB updates protected from tampering?
Well-implemented pipelines cryptographically sign every chart package, verify signatures against keys pinned inside the application, validate hash manifests over deltas, and enforce anti-rollback version counters — so forged, modified, or stale-but-signed data fails activation.

What is an aircraft security gateway?
The AID operating as a security boundary: label-whitelisting the avionics parameters it re-publishes, rate-filtering, running signed firmware with secure boot, enforcing the one-way no-write path, and logging anomalies for fleet monitoring.

Do EFBs use encryption?
Yes, in two distinct places: full-disk encryption on devices, and transport encryption (HTTPS/per-app VPN) for sync — plus, critically, signing (integrity) rather than secrecy for the data packages themselves, since the crown jewel is truth, not confidentiality.

Who is responsible for EFB security — airline or vendor?
Shared, and split along the boundaries: vendors own product security (signed builds, secure firmware, disclosure handling); the operator owns the program — MDM hardening, backend protection, procedures, monitoring — and regulators (via Part-IS/OpSpec conditions) make that split auditable.

What is an SBOM and why does aviation care?
A software bill of materials (SPDX/CycloneDX formats) listing every component in a build. When the next supply-chain disclosure lands, an SBOM answers “are we running the affected build?” in minutes instead of weeks — the difference between a patch and a grounding.

How would an airline respond to poisoned chart data?
Freeze distribution, quarantine affected devices, revert the fleet to the last-known-good data cycle (dual-cycle storage makes this possible), bridge with paper quick-reference procedures, and report to the NAA and A-ISAC — rehearsed in advance as a tabletop exercise, not improvised.

References

1. RTCA, DO-326A / EUROCAE ED-202A — Airworthiness Security Process Specifications (Afuzion technical overview: afuzion.com/do-326a-ed-202a-aviation-cyber-security/)
2. RTCA, DO-356A — Airworthiness Security Methods; DO-355 — Continuing Airworthiness Security [verify revisions]
3. Modern Requirements, “What is DO-326A? A Practical Guide” (modernrequirements.com)
4. Jama Software, “Cybersecurity in the Air: DO-326A” (jamasoftware.com)
5. Commission Regulations (EU) 2022/1645 & 2023/203 (Part-IS); NIST Cybersecurity Framework 2.0; CIS Benchmarks / DISA STIGs (mobile OS baselines)
6. OWASP CycloneDX / Linux Foundation SPDX (SBOM formats)
7. Parts 2, 4, and 6 of this series — the AID architecture, the data pipeline, and the threat models this post defends against

[← Part 6: EFB Cybersecurity Threats] · [Series Hub] · Part 8: EFB Safety, Human Factors & the Future → (publishes Sep 11)

Parts publish daily through September 11 — bookmark the series hub for the full run.

Current as of September 2026 · standards verified against the latest revisions.
Educational reference only — always follow your operator’s approved EFB program and your NAA’s current guidance.
Author: hmmnm.com editorial team · hmmnm.com

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy