Features

EFBs: Cyber safety

With increasing rates of connectivity and integrations, today’s advanced Electronic Flight Bags, are an inviting playground for cyber risks. Device and data integrity are crucial to remaining safe and secure

For a significant amount of time, the aviation industry’s security and safety agenda has been preoccupied on physical risks, such as mechanical failings and terrorist threats. However, as the rollout of onboard connectivity gathers pace and the connected aircraft becomes more of a reality, a new actor has been introduced into the discourse – cyber threats.

In their paper, Cyber-Security Challenges in Aviation Industry: A Review of Current and Future Trends, Ukwandu et al point out that the onboarding and integration of digital devices, as airlines migrate away from manual processes, has exposed the inherent vulnerabilities in the software tools that such platforms reside on. This is especially true of Electronic Flight Bags (EFBs).

Since their introduction over two decades ago, EFBs have evolved from being a simple digital replacement for a stand-alone paper-based flight bag or data provided to the flight crew by an operator’s “flight dispatch” organisation, to a sophisticated, technologically advanced device. These systems now consolidate a growing list of onboard documentation onto a highly accessible and digitalised device, that enhance situational awareness pre-, in- and post-flight, and deliver new levels of operational efficiency and safety.

As Julia Larsson, Director of Operations, EMEA at Web Manuals explains, operators often work with several different types of software and hardware while in flight and on the ground. With EFB apps providing real-time access to important information such as weather updates, NOTAMs and weather charts, she says that working with more interconnected systems can introduce some security risk[s]. “For example, integrated technology means critical flight data is more exposed and therefore, potentially at a higher risk of malicious attacks.”

It should be noted that, while these tools are crucial to flight safety, paragraph 6 of the Federal Aviation Administration’s (FAA) Advisory Circular (AC) 120-76E, released in June 2024, clarifies that “In order to qualify as an EFB application, the failure effect should be considered a minor hazard or have no safety effect.”

Protecting probity
Larsson identifies several security risks associated with EFB systems. One of the main risks to device integrity is unauthorised access to the system, which risks manipulation and access to sensitive flight data. Threats to data integrity could lead to misinformation or compromised safety protocols.

It’s a view subscribed to by Klaus Olsen, CEO EFB Admin Services. He states that with increased connectivity comes the greater susceptibility of EFBs to cyber threats. He adds data breaches into the cyber cauldron. “Ensuring data integrity is critical, especially in scenarios where real-time operational data is accessed mid-flight,” he says.

Ken Munro, Partner at Pen Test Partners, a provider of cyber security consulting and testing, discloses that most critical issues the company has found stem from data integrity. “By tampering with something as simple as runway length in the underlying database, engine performance will be miscalculated. A hack of an EFB puts at risk the integrity of that data resulting in errors – when these align with other factors (weather, high workload) – the Swiss cheese model – this is when the potential for incidents occurs.”

Munro continues. “There are numerous cases of mis-transposing of data from an EFB then leading to a safety incident. However, we found vulnerabilities in EFB apps that would cause the pilot to be given the wrong performance or weight & balance data.”

According to Munro, there are several threat actors, ranging from the obvious nation state, to those motivated by the various armed conflicts in progress, to those simply proving that they can hack sensitive aviation assets. “My personal view is that large sums could be made by shorting airline stock, then causing a flight safety incident to occur through a security issue in an EFB. The stock drops; profit [drops].”

Class action
To understand why these advanced EFBs present a new attack surface, a quick dive into the taxonomy of EFBs is needed.
The host platform i.e. the hardware used to run the software programs can be portable or integrated.

EFB systems were initially categorised into different hardware classes: Class 1 covered portable commercial-off-the-shelf (COTS); Class 2 covered mounted, specialised, and Class 3 covered installed EFBs. These classes were retired in AC120-76D (Oct 2017), simplified and reclassified as ‘portable’ and ‘installed’ to harmonise with EASA and ICAO guidelines.

A portable EFB is a portable EFB host platform, used on the flight deck, which is not part of the certified aircraft configuration. As per the International Civil Aviation Organization (ICAO) definition, portable EFBs are often pilot-issued and considered Portable Electronic Devices (PEDs). Other characteristics include having self-contained power and that they may rely on power and/or data connectivity to achieve full functionality. Any aircraft modifications to support portable EFB must be design approved.

Apple iPad EFB approval was obtained in 2011, and Microsoft’s MS Surface EFB approval was granted in 2014.

An installed EFB is an EFB host platform installed in the aircraft and subject to normal airworthiness requirements and design control. They are included in A/C type certificate (TC) or supplemental type certificate (STC).

According to Olsen, portable EFBs, particularly those brought off the aircraft, carry higher risks due to varied environments and Wi-Fi connections. “Operating system-specific vulnerabilities exist, with iOS generally seen as more secure due to its controlled ecosystem, while Android and Windows devices may require additional layers of security and are more prone to exploits,” he says.

Munro agrees. “The operating system in use can have a significant bearing on the security of the EFB. iOS is relatively straightforward to secure, owing to the walled garden of Apple operating systems. Android can be somewhat more straightforward to compromise, as can Windows. That said, any of these operating systems can be locked down and made very secure.”

In most cases today, the EFB leaves the cockpit and goes home with the pilot, or to their layover hotel, says Munro. “EFBs are critical devices, given they calculate weight and balance and take-off and landing performance and alongside access to corporate data. Their security should be given equal attention when compared with flight deck and avionic component security, yet this is often overlooked by smaller operators.”

The European Union Aviation Safety Agency (EASA) and other regulatory agencies have outlined specific guidelines detailing how EFBs should be classified, what software is approved, and certification requirements.

EFB applications are categorised as Type A or B, depending upon the applications loaded on the host and can be hosted on either portable or installed components.

As per EASA definitions in its AMC 20-25A Airworthiness considerations for Electronic Flight Bags (EFBs), Type A applications are EFB applications whose malfunction or misuse have no safety effect. They may be hosted on either portable or installed EFBs and do not require any approval.

Type B applications are applications whose malfunction or misuse are limited to a minor failure condition, and which do neither substitute nor duplicate any system or functionality required by airworthiness regulations, airspace requirements, or operational rules. They may be hosted on either portable or installed EFBs; require an operational assessment and do not require an airworthiness approval. They are authorised as part of the operator’s authorised EFB program and listed in the operator’s EFB program catalogue.

In its AC 120-76E, the FAA clarifies that “the appropriate level of EFB security depends on the criticality of the usage of the EFB application (e.g., an EFB which only holds a list of fuel prices may require less security than an EFB used for performance calculations). Beyond the level of security to ensure the EFB can properly perform as intended, the appropriate level of security ultimately depends on the capabilities of the EFB, including connections to other systems. Security impacts of connections to aircraft systems should be addressed, and special conditions may need to be addressed.”

Mixed report card
EASA’s regulatory framework also emphasises the importance of cybersecurity measures to protect data on EFBs from unauthorised access. The agency also supports the European Centre for Cybersecurity in Aviation (ECCSA) initiative which aims to increase collaboration and information sharing amongst aviation stakeholders, a key enabler for implementing a resilient aviation cyberspace.

“I believe more work is required to address cyber threats,” says Larsson, “and as always, a joint effort from industry experts, regulatory bodies, lobbying organisations and associations are the best mix.” This mix includes the AEEC/IATA EFB Users Forum which recently met in Portugal. The EFB Users Forum is a joint activity with IATA that enables airlines and other aircraft operators to state their preferences in the evolution of EFB hardware, software applications, and connectivity to the ground. This ensures operational benefit to the flight deck crew and the economic benefit to the airlines. Flight Operations, Information Technology, Engineering, and Maintenance disciplines are represented among the participants of the Forum.

The ‘could do better’ opinion is shared by Munro and Olsen.

Although both EASA and the FAA have issued general guidelines on EFB security, Olsen believes they remain focused on broader compliance rather than prescriptive, granular security protocols. “As threats evolve, there may be a need for these bodies to adopt a more standardised, stringent policy approach to ensure all operators adhere to consistent cybersecurity practices. However, flexibility in security measures allows operators to tailor solutions based on specific needs.”

For Munro, while installed EFBs that are a permanent fixture in the cockpit are adequately covered by regulation, portable EFBs are not so well covered. “FAA regulations are weak for portable EFBs,” he asserts. “EASA regulations for portable EFBs are significantly more robust but could still be improved.”

The weakest link
Regulators may be responsible for setting general cybersecurity frameworks for aviation businesses to comply with, but OEMs and operators are not absolved of accountability.

The responsibility of risk mitigation, on the other hand, must lie with both OEMs and air operators that develop the technology and have a real understanding of how EFBs are applied during operations, says Larsson.

It’s a view shared by all those spoken to for the purpose of this article. “While regulatory bodies set baseline standards, the primary responsibility for risk mitigation often lies with OEMs and operators. OEMs design security features within devices, but airlines must also implement strict operational protocols, given the variability of threats and differing device usage scenarios across operators. A collaborative approach between OEMs, operators, and regulators is essential for robust EFB cybersecurity,” states Olsen.

Munro believes that installed EFBs are well covered, and OEMs are doing a good job in installed EFB space. “Semi-portable EFBs, such as those found in the A350, is an interesting case as they have integration with flight displays but can be removed from the cockpit.

“Risk mitigation for a portable EFB comes from both the software developers providing the various applications, through to the operator securing the EFB, together with giving and enforcing good training and guidance around EFB use.”

The FAA agrees. In its AC120-76E, it emphasises that “the operator is responsible for ensuring security controls are in place to mitigate against the risk of IUEI [Intentional Unauthorised Electronic Interaction] to an EFB’s OS architecture, its specific hosted applications, and any of the databases or data links used to enable its hosted applications. The operator is also responsible for protecting the EFB from possible contamination from malware. Evidence should be provided, through analysis, testing, or a combination of both, to ensure EFB security is effective. The operator should define the processes and procedures to maintain the security level of the EFB during its entire operational life cycle.”

In the UK, the Civil Aviation Authority (CAA) must review the risk assessment, procedures, testing and approve the application.

Prime technique
There are several measures operators can take to secure EFBs. For Larsson, best practice includes frequently installing the latest software updates. She also advances encrypting the data, requiring a strong password and restricting app access to authorised personnel. According to Olsen, effective EFB security also requires regular security audits and risk assessments, policies that enforce strict data access and storage protocols, and ensuring all data transmitted between the EFB and airline systems is encrypted and that the devices are secured when outside the aircraft environment.

An EFB provider should also have a resilient and robust cybersecurity structure in place. As Larsson explains, Web Manuals’ apps utilise encrypted data transfer, secure login functions that use tokens, and store customer data in app-only storage. Operators must also employ cybersecurity measures to their devices, such as multi-factor authentication (MFA).

“Additional functions such as MFA are important as there is only so much the app can do on its own,” she says. Olsen agrees that MFA is a necessary measure as it adds a layer of security beyond passwords.

Furthermore, Olsen says that a cybersecurity structure should include end-to-end encryption for the protection of sensitive data during transmission, a network security, to ensure connections (e.g., onboard Wi-Fi) are monitored and secured. While not a software supplier, EFB Admin Services we maintain close relationships with leading EFB software providers to ensure it can support a wide array of EFB suites and applications. This includes Mobile Device Management (MDM) solutions such as Intune, Kandji, and Miradore that enable centralised control over device security, user permissions, and updates.

Munro judges MDMs to be an important part of securing a mobile device against misuse by the user. He believes an EFB is a safety critical device, and therefore should be treated as such. Pilots shouldn’t be using these devices to watch Netflix or use personal email, he insists. “Operator IT departments should not turn on every single restriction available to them in an MDM as these can have unintended impacts on the flight deck. A careful approach needs to be taken,” he says.

MDM solutions enhance security and operational efficiency by enabling remote management, security updates, and policy enforcement. They allow administrators to control access, update software, and monitor device status. Using an MDM, airlines can ensure regulatory compliance and maintain device integrity across varied operational contexts. They also help reduce security risks on devices by limiting human interaction, for example, by limiting browser usage. MDMs also contain data lost through remote device locking and wiping.

Web Manuals’ Reader App, for example, supports MDM configuration per device by predefining the customer, username and password, and locking the configuration to the device.

Can we fix it?
Gremlins can appear in an EFB. If an efficient reporting and escalation system is in place, a quick resolution is feasible. Once a bug is identified, immediate actions include disabling vulnerable components, issuing updates, or deploying patches. Airlines should coordinate closely with OEMs and software providers to ensure vulnerabilities are addressed without delay, particularly in mission-critical software, advises Olsen.

Larsson elaborates further. “The general process of remediation is to confirm the bug, develop a new solution, test it, create a public test version – and once all feedback and checks have been resolved – share to the app store. This process will vary in time depending on the type of bug/weakness found, and the level of urgency will impact how long it takes to be resolved.”

Munro argues it’s not realistic to expect a quick resolution. “Safety critical code such as that found on an EFB will need to be recertified after a change. Whilst a vulnerability might only take a day to fix, recertifying the code can take months. That certification process is really important – we need to be certain that a code change doesn’t result in the EFB failing at a critical point.”

Having discovered vulnerabilities in various EFB platforms over the years, Munro says that without pointing fingers, some OEMs are more receptive than others, though all have improved over the last few years. He advises testing an EFB after every significant change, such as the addition of a new package, new functionality/connectivity or a change of hardware.

“Flying is safe,” he assures, “owing partly to years of learning from mistakes. Cyber security evolves far faster, changing overnight in some cases (e.g. Heartbleed). At times like this, safety can be seen to get in the way of cyber. Careful risk assessment is the way forward, balancing the risk of an immediate fix versus the status quo.” 

By Alex Preston