Key takeaways
- The EFB risk that matters most is integrity: a wrong performance figure or an out-of-date chart can hurt more than a leaked one.
- Regulatory guidance (FAA AC 120-76, EASA AMC 20-25, Transport Canada AC 700-020) expects an operator's EFB program to address security, data integrity, configuration control and loss of the device.
- Most of the controls are mobile-device-management settings you already pay for: supervised devices, an app allow-list, enforced encryption, remote wipe, and a tested update policy.
- The connection between the EFB and the aircraft, where one exists, is the boundary the certification world cares about. Keep it read-only where you can and treat it as part of the aircraft's security scope.
- Crews need three things: a one-page procedure, a spare device, and a phone number for when the tablet misbehaves.
What an EFB is now
An Electronic Flight Bag started as a replacement for paper: charts, manuals, checklists. Today a portable EFB on a commercial tablet also runs performance and weight-and-balance applications, receives weather and NOTAMs in flight over cellular or satellite links, exchanges data with dispatch, and on many aircraft connects through an aircraft interface device to avionics data such as position, fuel and flight-plan information. The regulatory vocabulary distinguishes portable from installed EFBs and classifies applications by their effect on safety (the FAA's Type A and Type B software categories; the older Class 1/2/3 hardware terms have been retired), and every regime expects the operator to run an EFB program with an administrator, configuration control and procedures.
That program is where cybersecurity lives. The FAA's Advisory Circular 120-76, EASA's AMC 20-25 and Transport Canada's Advisory Circular 700-020 (check the current revisions) all expect the operator to address the security of the EFB system: protection from unauthorised access and malicious software, the integrity of the data the crew relies on, and what happens when a device is lost, fails or is compromised.
Where the risk actually sits
It is tempting to think of EFB security as protecting company documents. The safety case is about something else: the crew acting on data that is wrong. Takeoff performance errors from mis-entered or wrong data have featured in a long list of incidents and accidents; an EFB that delivers a corrupted performance database or a tampered chart produces the same outcome by a different route. The table below lists where the risk enters and what to do about it.
| Where the risk enters | What can go wrong | Control |
|---|---|---|
| The device itself | Consumer tablet, personal apps, jailbroken or out-of-date OS, shared PIN. | Operator-owned, supervised devices under mobile device management; enforced passcode and encryption; OS versions controlled and tested against the EFB apps before rollout; no personal apps, or a separate managed profile. |
| Applications | Unvetted apps with broad permissions; malicious look-alikes; abandoned apps no longer patched. | An app allow-list; installation only through the management system; a named person who evaluates each app and each major update; vendor security statements on file. |
| Data and updates | Charts, performance databases and manuals corrupted, stale or replaced in transit. | Updates only from the vendor's authenticated channel; effective-date checks in the pre-flight procedure; a way to confirm the active database revision; no side-loading from email or USB. |
| Connectivity | Public Wi-Fi at hotels and FBOs; hostile networks; man-in-the-middle on unencrypted app traffic. | Cellular preferred for updates; a VPN or per-app VPN for company data; apps verified to use encrypted transport; automatic joining of open networks disabled. |
| The aircraft interface | A data link from the EFB into avionics is a path an attacker could use; even read-only interfaces have had vulnerabilities. | Read-only where the function allows; the interface device and its firmware in the aircraft's security scope (DO-355A and the type certificate holder's instructions); no ad-hoc cables or third-party adapters. |
| Loss, theft and failure | A lost device with company data and cached credentials; a failed device on a dark ramp with no paper fallback. | Remote lock and wipe; short auto-lock; a reporting procedure; spare devices and a defined minimum fallback (paper or a second device) in the operations manual. |
| Accounts | Shared logins to EFB portals, weak passwords, no multi-factor authentication. | Individual accounts, MFA on all portals, access removed when crew leave. |
| Everything around the EFB | Dispatch laptops, the flight-planning provider, the content server, the administrator's own PC. | These are part of the EFB system; include them in the program and in your incident plan. |
Building the security part of the EFB program
Name the administrator and write down the configuration
Regulators expect an EFB administrator; give that person the security responsibilities too. The baseline configuration (device model, OS version, allowed apps and versions, management settings) should be a document that is updated with every change, because when something goes wrong the first question is "what changed?".
Use the management tools you already have
Every major tablet platform supports supervised, managed devices with an allow-list, enforced encryption, remote wipe, controlled updates and per-app network rules. The cost is a licence per device and a few days of setup. Most small operators have already bought this capability and use a tenth of it.
Test updates before the crews see them
An operating-system update that breaks the performance app is a safety problem as well as a nuisance. Hold one device back as a test unit, apply the update, run the apps, then release the update to the fleet. Write the interval down; "when the vendor says so" is not a policy.
Decide what the aircraft connection may do
If your EFBs connect to the aircraft, get the type certificate holder's guidance on the interface, know which direction data flows, and treat any write path as a matter for the aircraft's continuing-airworthiness security instructions. If nobody can tell you what the interface does, that is the finding.
Plan for the bad day
A device is lost in a hotel; a crew member reports the app "looks different"; the content server is unreachable on a Monday morning. Each needs a two-line procedure and a phone number. The incident response guide covers the organizational side.
Crew guidance on one page
Pilots do not need to understand certificates and management profiles. They need a short list they can follow and a way to get help.
- Use only the company device for flight duties; do not install anything on it.
- Before flight, confirm the chart cycle and performance database are current, as the checklist requires.
- Update over cellular or the company network, not hotel or airport Wi-Fi.
- Never connect an unknown cable, adapter or storage device to the EFB or the aircraft interface.
- If the device is lost, stolen or behaves strangely, report it immediately to the EFB administrator; do not try to fix it.
- Know where the spare device or the paper fallback is, and how to dispatch without the EFB.
- Lock the device when it leaves your hands, including in the crew room.
A ten-minute self-check for the operator
| Question | If no |
|---|---|
| Are all EFBs operator-owned, supervised and under management? | Enrol them; personal devices are the weakest link. |
| Is there an app allow-list and a person who approves changes to it? | Create both this week. |
| Can you wipe a lost device remotely, and has anyone tested it? | Test it on a spare. |
| Do you test OS updates before fleet-wide rollout? | Keep one device back as the test unit. |
| Do crews know the fallback if the EFB fails at the aircraft? | Write it into the operations manual and brief it. |
| Do you know what the aircraft interface allows the EFB to do? | Ask the type certificate holder; document the answer. |
Questions I get asked
What is the biggest cybersecurity risk in an EFB program?
Integrity, not confidentiality. A wrong performance figure, an outdated chart or a tampered weight-and-balance calculation can affect the flight; a leaked document usually does not. Configuration control and a tested update process matter more than encrypting the library.
Which regulatory guidance covers EFB security?
FAA AC 120-76, EASA AMC 20-25 and Transport Canada AC 700-020 all expect an operator's EFB program to address security, data integrity, configuration control and loss of the device, with the rigour matched to the EFB's functions and any connection to the aircraft.
What controls do we actually need?
Mostly mobile-device-management settings you already pay for: supervised devices, an app allow-list, enforced encryption and passcode, remote wipe, a tested update policy, and a rule for the aircraft connection where one exists. Plus a one-page crew procedure and a spare device.
Can crews use personal tablets as EFBs?
Some programs allow it, but the operator remains responsible for the configuration. A personally owned device that the operator cannot supervise, wipe or keep updated is hard to justify to an authority; a company-owned, supervised device is simpler to defend.
How I can help
EFB security is part of my security program and readiness assessment for operators: I review the EFB program, the devices, the apps and the aircraft interface alongside the rest of your systems, and you get a prioritized risk register and a 90-day roadmap. I can also write the crew procedure and the administrator's configuration baseline.
Ask about an EFB review
Founder of Mevocopter Aerospace. M.Sc. in Aviation and Aerospace Sustainability with a specialization in Aviation Cybersecurity from Embry-Riddle; earlier career in computer support and network security. Publications · ORCID
References
- FAA Advisory Circular 120-76 (current revision), Authorization for Use of Electronic Flight Bags.
- EASA AMC 20-25 (current revision), Airworthiness and operational consideration for Electronic Flight Bags.
- Transport Canada Advisory Circular 700-020 (current revision), Electronic Flight Bags.
- RTCA DO-355A / EUROCAE ED-204A, Information Security Guidance for Continuing Airworthiness.
- NIST SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise.