EFB Safety & Human Factors: Battery Fires, Failure Policy and the Future

EFB SERIES · PART 8 OF 8 — Technology, Security & Safety · Series Hub · ← Part 7

TL;DR — Is the EFB safe? The device is the smallest part of the risk. The real EFB safety case lives in three places: lithium-battery thermal runaway procedures, failure-and-redundancy policy (where “two tablets” can still mean one shared failure), and human factors — head-down time, automation bias, mode errors. Every cyber scenario from Parts 6–7 lands here as a safety case: on the EFB, security events are safety events.

Seven posts ago, this series made a promise: that replacing paper with software makes data integrity a flight-safety property, and that security and safety converge on the EFB. Part 7 ended with the last green cut on the attack tree — cross-check culture and paper reversion — which are safety procedures, not security controls. This final post completes the circle: it covers the residual risks the certification system always knew about (batteries, failures, humans), reveals the trap hiding inside every “redundant” EFB installation, and then looks forward to what this device becomes next.

Lithium Battery Thermal Runaway: Chemistry First, Then Procedure

A tablet is a few hundred grams of tightly packed lithium-ion chemistry sitting inside arm’s reach of both pilots — and thermal runaway is an immediate-action event, not a monitor-and-see event.

Table T8.1 — Thermal runaway stages (approximate, chemistry-dependent — verify ranges against current battery-safety literature and your authority’s guidance)

The mechanism in one paragraph: lithium-ion cells store energy in electrodes separated by an ultra-thin separator, with a passivation layer (the SEI) on the anode. Abuse the cell — heat, damage, overcharge, internal short — and the SEI begins decomposing around 90–120 °C in an exothermic reaction that raises temperature, which accelerates the reaction: thermal runaway. The cell vents flammable electrolyte vapor; ignition can follow; and because a tablet packs many cells tightly with limited thermal isolation, one cell’s event propagates to its neighbors. Service triggers seen in the real world: physical damage (a tablet dropped between seat rails), swelling batteries, charging faults, and heat soak — a tablet left on a glareshield in a parked aircraft can start its day already deep in the danger curve.

The procedural doctrine follows the chemistry: immediate-action class. Disconnect power (if charging), isolate the device (don’t keep using a swelling tablet to “finish this leg”), deploy the fire-containment bag where carried, expect and manage smoke, and treat the event as reportable — the device never flies again. Prevention is the boring half that works: attended-charging policies, heat-soak avoidance, spare-battery carriage limits, and (where MDM reports it) fleet battery-health telemetry as an early-warning metric.

EFB Failure Policy and Redundancy

The paper chart’s great virtue was that it never needed a failure policy. The EFB needs a whole chapter — and the word “independent” does most of the work in it.

Table T8.2 — Redundancy policy elements

The anatomy of a failure procedure is phase-gated: a device failure in cruise is an inconvenience (cross-fleet to the PM’s EFB, continue, monitor); the same failure on the taxiway or during an approach briefing is a reversion decision with the aircraft’s energy state in mind. The policy exists precisely so nobody makes that judgment call fresh at 200 feet. And the battery policy — the 130–150% endurance norm, the low-battery stages — is the quiet twin of the thermal-runaway section above: the same chemistry, managed from the other end.

Human Factors on a Digital Flight Deck

The EFB changed the cockpit’s error profile, not just its luggage: head-down time, automation bias, mode errors, and a glowing rectangle competing for attention.

Table T8.3 — HF issues × phases × mitigations

The case every discussion of cockpit distraction cites. On October 21, 2009, Northwest Flight 188 overflew its destination Minneapolis by more than 100 miles while the crew, per the NTSB investigation, was absorbed in a laptop conversation about scheduling. Nobody died; an industry’s assumptions did. The NTSB’s finding — loss of situational awareness from personal laptop use in cruise — predates the fleet-wide EFB, but it remains the canonical demonstration that a compelling screen in the cockpit is a fatigue-and-attention hazard regardless of what software it runs. The modern lesson isn’t “ban tablets”; it’s that disciplined, procedural use of a purpose-built tool is a different creature from undisciplined absorption — and the difference is written into policy (Part 5’s training slice) or it isn’t real.

Automation bias deserves its own word because it attacks the Type B safety case at its root (Part 3): the classification assumes crews detect and mitigate wrong answers. Complacency erodes exactly that. The mitigations are cultural and procedural — cross-check norms, raw-data confirmation habits, treating the moving map as a floor beneath which attention cannot sink — and they are the reason a security-minded series keeps insisting that its final defense layer is a human practice (Part 7’s last green cut).

The Dirty Secret: Common-Mode Failures

Two EFBs are not two independent systems — and drawing the shared dependencies honestly is the most important picture in this series.

Draw two tablets — Captain’s and First Officer’s — and then draw the lines to everything they share: the same OS build, the same application version, the same data cycle, the same MDM profile and backend, the same charging hub (the classic dual-dead-battery story), and — on interfaced installs — the same AID feed. Every shared line converts an ostensible dual failure into a single common-mode one. The practical policies follow directly: independent power sources, staged OS updates across the fleet so both pilots of a given flight aren’t simultaneously on a fresh build, charging discipline that never puts both devices on one path overnight.

Now the convergence this series promised, stated one final time: a poisoned data cycle (Part 6) is a common-mode failure. It travels the “same data cycle” edge — invisible to every device-level redundancy policy, defeated only by the signing chain (Part 7) and the crew’s cross-check culture (this post). Security events become safety events through exactly this mechanism. The two disciplines were never separate; they were the same risk wearing different uniforms, and the EFB is where the uniforms come off.

The Future of the EFB (2026→)

The EFB’s future is more connected, more assistive, and more regulated — which is a security sentence as much as a feature list.

Table T8.4 — Trends, enablers, and their security implications

The AI row deserves blunt treatment, because this site covers AI-agent security daily: an LLM that summarizes your NOTAMs and answers “what’s the localizer minimum at our alternate?” is a component that consumes untrusted text and produces crew-consumed output — the textbook injection surface. The defensible pattern is already clear from Part 7’s architecture: AI output as advisory layer, clearly labeled, never between the crew and signed primary data, with the classic integrity chain untouched beneath it. The EFB of 2030 should be a better advisor, not a new single point of truth.

Building an EFB Program That Survives Audits and Incidents

The series’ whole arc compresses into one implementation roadmap:

1. Pilot (Part 1-2 thinking): scope the replacement — which paper, which fleets, portable/interfaced architecture.
2. Evaluate (Parts 2–4): hardware and AID selection; application types and their procedural containment; the data pipeline end-to-end.
3. Assess (Parts 5–6): the SMS hazard register — including the security scenarios — and the risk matrix that drives mitigations.
4. Approve (Part 5): program documentation, NAA authorization, OpSpec/acceptance.
5. Operate (Part 8): training, failure procedures, battery discipline, HF policies.
6. Monitor (Parts 4, 7, 8): update adoption, signature-failure telemetry, battery-health curves, head-down reports — feeding back into step 3’s register forever.

Eight posts, eight lessons: the system concept (1), the certified boundary (2), failure-effect classification (3), the data supply chain (4), the rulebook (5), the attack surface (6), the defense architecture (7), and the human/operational layer where it all lands (8).

Glossary

AID (Aircraft Interface Device) — Gateway filtering certified avionics data (ARINC 429 et al.) to the non-certified EFB, enforcing one-way isolation.
AIRAC — ICAO’s fixed 28-day aeronautical-data amendment rhythm; ~13 effective dates per year.
AIXM 5.1 — Modern XML exchange format for aeronautical information.
AMC — Acceptable Means of Compliance (EASA guidance document class).
ARINC 424 — Navigation-database interchange format (records for airports, procedures, navaids).
ARINC 429 — Dominant avionics bus: 32-bit words, 12.5/100 kbps, unidirectional, no authentication.
ARINC 653 — Partitioned-RTOS standard enabling mixed-criticality software on one platform.
Automation bias — Over-trusting tool output; erodes the Type B detect-and-mitigate safety case.
A-ISAC — Aviation Information Sharing and Analysis Center.
Common-mode failure — One cause failing nominally independent systems simultaneously (shared OS, data cycle, charger, feed).
DAL — Design Assurance Level (DO-178C): A (catastrophic) to E (no effect).
DO-160G — Environmental qualification standard for airborne equipment (EMI sections 20/21 among others).
DO-178C — Airborne-software design-assurance standard.
DO-326A / ED-202A — Airworthiness-security process standard family (with DO-355, DO-356A).
Dual-cycle storage — Device holding current and next AIRAC databases across the cutover window.
EFB — Electronic Flight Bag: the display/compute/store/sync system replacing the paper flight bag.
Effective, not received — AIRAC principle: data validity runs from the effective date regardless of download timing.
EOFB — Electronic flight bag as installed/carried per operator configuration; dual-EOFB = both pilots’ devices.
GCI / zones — DO-326A vocabulary for ground-configuration and security-zone definitions.
Geo-referencing — Calibrating chart plates to WGS-84 so own-ship position can be drawn on them.
HIRF — High-Intensity Radiated Fields (EMI environment category).
IWXXM — XML weather-exchange format (complementing TAC METAR/TAF).
LMC — Last-Minute Change (weight-and-balance update window).
MDM/EMM — Mobile device/enterprise management: the fleet’s control plane.
Moving map — Chart display with own-ship position — Type B’s flagship feature.
NOTAM — Notice to Airmen: operational-change notices, digitalizing via Digital NOTAM/AIXM.
OpSpec — Operations specification: the FAA instrument authorizing EFB use.
Own-ship position — The aircraft’s rendered position on a geo-referenced chart.
Part-IS — The paired EU information-security regulations — 2022/1645 (organization requirements) and 2023/203 (authority requirements) — applicable from October 2025 / February 2026.
PKI / pinned keys — Public-key infrastructure; pinning embeds verification keys in the app build.
SBOM — Software Bill of Materials (SPDX/CycloneDX): component inventory per build.
SMS — Safety Management System (ICAO Doc 9859).
STRIDE — Threat taxonomy: Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation.
Thermal runaway — Self-accelerating lithium-cell failure: SEI decomposition (~90–120 °C) → venting → ignition → propagation.
Type A/B/C — EFB software classes by failure effect: none / minor / major-or-worse.
WGS-84 — The reference coordinate system tying plates, databases, and position together.

Key Takeaways

• The residual EFB risks are physical (lithium thermal runaway), architectural (failure policy, independence), and human (head-down time, automation bias, mode errors).
• Thermal runaway is an immediate-action event: onset chemistry begins ~90–120 °C; prevention is charging and heat-soak discipline.
• “Independent” redundancy must be designed: separate power, staged builds, disciplined charging — or two tablets share one failure.
• Common-mode failure is where security becomes safety: a poisoned data cycle defeats device redundancy by design; only the signing chain and cross-check culture answer it.
• Human factors are the final control layer — the last green cut on Part 7’s attack tree.
• The future (dynamic data, AI assistance, EFB-as-sensor, Part-IS audits) raises integrity stakes; AI output belongs inside the advisory boundary, never between crew and signed data.
• The program loop — pilot → evaluate → assess → approve → operate → monitor — is where all eight posts become one auditable system.

FAQ

Can an EFB battery catch fire in the cockpit?
Yes — any lithium-ion device can enter thermal runaway when damaged, overheated, or faulty; the risk is managed with charging discipline, heat-soak avoidance, and immediate-action procedures including fire-containment bags.

What happens if both EFBs fail?
Approved programs define reversion: cross-loading to any surviving device, retained paper quick-reference items, and dispatch/continue decisions by phase of flight — decided on the ground, never improvised at 200 feet.

Do airlines still carry paper charts as backup?
Most retain a defined minimum on paper — briefing documents and quick-reference items — sized by their risk assessment; full-paper reversion kits persist in some operations. The exact mix is operator policy.

What is EFB automation bias?
The tendency to over-trust EFB output (moving map, performance numbers), eroding the detect-and-mitigate assumption that Type B classification depends on. Countermeasures are cultural: cross-checks, raw-data confirmation, standard calls.

Will AI replace the EFB?
More precisely, AI is joining it: semantic chart queries, LLM-assisted briefings, dynamic data. The defensible pattern treats AI output as untrusted advisory layered above the signed-data chain — an assistant, never a new single point of truth.

What is a common-mode failure?
One cause failing multiple nominally independent systems at once — e.g., both EFBs sharing one OS build, data cycle, MDM profile, charging hub, or AID feed. Security events (poisoned data) exploit exactly these shared edges.

How long should EFB batteries last?
Typical operator policy requires 130–150% of planned flight time at departure with staged warnings — a program rule, not a universal regulation; the governing text is the operator’s approved EFB program.

References

1. NTSB, Northwest Airlines Flight 188 incident report (October 2009 — cockpit distraction finding)
2. FAA guidance on in-flight lithium-battery fires (SAFO-class advisories — confirm the current numbers applicable to your operation); FAA AC 120-76E (battery and failure-policy expectations)
3. ICAO, Doc 9859 — Safety Management Manual (hazard/risk methodology behind Part 5’s register)
4. Battery-safety literature on lithium-ion thermal-runaway stages [verify representative citation]
5. ICAO, Doc 10020 — EFB Manual (human-factors and failure-management guidance)
6. ScienceDirect, electronic vs. paper chart response-time study (Part 1’s reference, closing the loop)
7. Parts 1–7 of this series

[← Part 7: Securing the EFB] · [Series Hub — all 8 parts + PDF]

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