Sound EFB failure procedures start from an unglamorous premise: tablets fail. Batteries die, screens crack, an app freezes, a device overheats on a hot glareshield. The EFB framework accepts this and answers it with redundancy. A guiding principle across the guidance material is that the EFB system should have no single point of failure that would deprive the crew of information needed for the safe operation of the flight. In practice, for the functions crews rely on, that means two independent EFBs drawing on independent power sources.

Redundancy: what EFB failure procedures are built on

That principle turns a device failure into a non-event. Lose one screen and you continue on the other, applying your operator’s procedure for the degraded state — the Operations Manual and minimum equipment list define what you may do with reduced EFB capability.

Two words carry the weight: independent, and independent

The phrase is two independent EFBs drawing on independent power sources, and both halves are doing work. Two devices sharing a single charging point, a single cable run or a single powered accessory are not two independent EFBs against a power failure — they are one system with two screens. In our experience this is the most common way a redundant-looking installation quietly stops being redundant: the second device was never the problem, the shared dependency behind it was.

The same test applies to data. If both devices receive the same package from the same source at the same moment, they are redundant against hardware failure and not against corrupted content. Redundancy is always redundancy against something, and it is worth asking which failure each duplicate actually covers.

Where the operator’s own documents take over

The framework sets the principle; your Operations Manual and MEL set the consequences. That division matters because the answer to “what may we do now” is not in the regulation — it is in your own documents, and it is specific to your operation. A crew that knows the principle but not the operator’s procedure for the degraded state has the theory and none of the decision.

Total loss: pre-planned, not improvised

Total loss is rarer and must be pre-planned, not improvised: before flight the MEL tells you whether you may even depart with a function unavailable; in flight you fall back on the operator’s defined alternative means — ATC or company information, certified aircraft systems, and any required backup — and make a more conservative decision if needed, up to a diversion.

The word that matters is “defined”

The alternative means are not whatever the crew can improvise on the day. They are defined in advance, which means somebody had to decide them, write them down and train them. We would expect an inspector to test exactly that: not whether the operator has thought about total EFB loss in the abstract, but whether a line crew can say what they would fall back on, for which function, and at what point the decision becomes conservative. Fluency on that question is the evidence. A paragraph in a manual that nobody can paraphrase is not.

Security is the subtler threat

An EFB stores and displays information that flight safety depends on and increasingly connects to networks to get it, which makes its security part of its airworthiness, not an IT afterthought. If the data on your EFB can be tampered with, the chart or performance figure you trust could be wrong by design — and a plausible-looking corruption might slip past the usual gross-error check.

Why this failure mode defeats the usual defence

This is the point that deserves the most attention from anyone who has worked through the gross-error check. That defence works because errors are usually careless: they produce numbers that do not fit the situation, and a crew holding an expectation notices. Tampered or corrupted data need not be careless. It can be plausible. A figure engineered to sit just inside what a crew would accept is a different class of problem from a transposed weight, and the reasonableness check that catches the second is not designed to catch the first.

Which is why the framework treats data integrity as a condition of the device rather than a task for the crew. The crew’s expectation is a good filter against error. It is not a control against deliberate or systemic corruption, and it should never be asked to be one.

The discipline that matters most on the line

The most important discipline for a line pilot is also the simplest: the company EFB is a controlled operational tool, not a personal device. Use only approved company applications; do not install personal apps, sideload charts, or connect it to untrusted networks and accessories. Update databases only through the approved, trusted channel. Every unapproved app and every untrusted connection is a potential way for malware or corrupted data to reach a device your safety-critical applications also live on.

The myth: “one harmless app cannot matter”

This is the reasoning that undoes otherwise well-run fleets, and it is worth shattering directly. The objection assumes the risk of an application is proportionate to what that application does. It is not. The risk is a function of where it lives. An entirely benign app installed on a device that also holds performance and chart applications shares that device, and whatever route it opens is open to everything on it. The question is never whether the app is dangerous. It is whether the device is still controlled.

The same logic covers accessories and networks. A cable, a charger, a hotspot or a public network is a connection to a device that flight safety depends on. In our experience operators get further with crews by explaining this once — properly — than by publishing a longer list of prohibitions. Pilots are rigorous people; they comply readily with rules whose mechanism they understand and work around rules that look arbitrary.

The intended outcome

A secure, redundant, disciplined EFB does what the regulator intended: it makes a heavy bag light without ever making the aircraft heavier to fly. That is the whole test, and it is the same test set out in what EASA actually requires of an electronic flight bag.

Related reading

Which applications the redundancy principle is protecting is a matter of type A and type B classification, and the physical side of EFB discipline is covered in mounting, stowage and critical phases. For the approval and administration framework around the whole system, see our guide to EFB operational approval.

The rule text is available as Regulation (EU) 965/2012 on EUR-Lex and in the EASA Easy Access Rules library. If the redundancy design, the security posture and the loss-of-EFB procedures are yours to own, the Raven EFB Administrator course addresses them as one system rather than three separate problems.

Frequently asked questions