Guarding the Digital Gateway
How Aircraft Interface Devices are Reshaping EFB Data Governance
As aviation has increasingly embraced digital technology, Aircraft Interface Devices (AIDs) have evolved from simple hardware adapters into central avionics hubs. Today, AIDs are serving as the digital bridge between certified aircraft systems—such as Flight Management Systems (FMS) and ARINC data buses—and commercial-off-the-shelf Electronic Flight Bags (EFBs) or personal devices (bring your own devices, aka BYOD). In this role, AIDs feed real-time positional, atmospheric, and operational data directly to flight crews. They also provide moving-map displays, automated flight logging, and dynamic performance calculators, with their future capabilities pointing toward onboard edge computing (processing data locally on the aircraft) and real-time air-to-ground synchronization.
The growing capabilities of AIDs come with significant engineering and operational challenges. Connecting commercial mobile hardware to safety-critical avionics can lead to complex cybersecurity issues, requiring strict domain isolation and defense-in-depth protocols. Operators also face steep integration challenges when retrofitting legacy fleets that were never designed for IP-based networks, as well as compatibility issues caused by proprietary software interfaces and vendor lock-in. Additionally, as data volumes explode, the aviation industry’s primary concern has shifted from physical connectivity to data governance—ensuring that every bit of data interacting with the cockpit is secure, authorized, and operationally sound.
To explore how aircraft operators can navigate these complex technical, regulatory, and security challenges, Aerospace Innovation spoke with Klaus Olsen, CEO and EFB Administrator at EFB Admin Services Int. AS. With more than two decades of operational experience in aviation technology, Olsen provides independent assistance to ensure that airline programs remain audit-ready, and supports operators across major global frameworks including EASA and the FAA.
Aerospace Innovations: Please begin by telling us about your company’s work on interfacing EFBs and other BYODs with aircraft interface devices (AIDs).
Klaus Olsen: EFB Admin Services supports airlines with the implementation, regulatory approval and continuing operation of Electronic Flight Bag programs. Our work includes portable and installed EFB solutions, operational evaluations, safety risk assessments, EFB policies and procedures, application governance, mobile device management, cybersecurity, training and coordination between operators, avionics suppliers, software vendors and aviation authorities.
We do not manufacture Aircraft Interface Devices. Our role is to help operators ensure that the complete end-to-end interface between the aircraft, the AID, the EFB hardware and the EFB applications is operationally suitable, secure, supportable and correctly documented.
This distinction is important. An AID may be technically capable of delivering aircraft data to an EFB, but the operator must still determine which applications are authorized to receive that data, how it may be used, what happens when it is unavailable or incorrect, and how configuration changes are controlled throughout the operational lifecycle.
The industry has largely solved the problem of connecting systems. The next challenge is governing the information that flows between them.
Aerospace Innovations: What is the current state-of-the-art in AIDs these days, in terms of the devices they can connect to aircraft systems and the degree of information swapping they can support?
Klaus Olsen: The state-of-the-art has moved well beyond the AID being a simple one-way data converter.
Modern AIDs can interface with multiple aircraft data sources, including ARINC 429, ARINC 717, discrete signals, serial data, avionics Ethernet and, depending on the aircraft architecture, higher bandwidth IP based networks. They can then securely distribute selected data to installed systems, airline controlled tablets, portable EFBs, maintenance devices and, in some cases, ground systems through cellular or satellite connectivity.
Typical data delivered to EFB applications include aircraft position, altitude, heading, groundspeed, airspeed, wind, outside-air temperature, fuel information, weight and balance data, flight phase, engine parameters and selected FMS information.
The most important development, however, is not simply the amount of available data. It is the ability to manage data according to its source, integrity, latency, authorized destination and intended operational use.
Aerospace Innovations: Are these data exchanges fully bidirectional, or are they restricted for safety reasons?
Klaus Olsen: Most portable EFB integrations remain predominantly aircraft-to-EFB rather than genuinely bidirectional.
That is deliberate. Sending information from a portable or commercially developed device back into safety-critical aircraft systems creates a very different certification and cybersecurity exposure. Bidirectional exchange is possible in controlled architectures, but it requires strong separation, validation and explicit system authority.
FAA guidance distinguishes between operational EFB applications and aircraft-installed equipment and directs installation-related connectivity considerations to the applicable airworthiness approval process.
Aerospace Innovations: As AIDs become the central hub connecting core aircraft systems to Electronic Flight Bags (EFBs), how are you ensuring these data transfers remain entirely secure from external cyber threats?
Klaus Olsen: I would be cautious about describing any connected system as “entirely secure.” The appropriate objective is to reduce risk to an acceptable level, maintain defense in depth and ensure that a compromise of an external device cannot propagate into safety-critical aircraft domains.
The fundamental controls should include strict segregation between aircraft control domains, airline information systems, and passenger or public networks; controlled and preferably one-way data flows where bidirectional communication is not operationally necessary; and the allow-listing of permitted data, applications, devices, and services.
Operators must also ensure authenticated and encrypted communications, implement certificate and cryptographic-key lifecycle management, and utilize secure boot alongside signed software and controlled firmware updates. Further measures require restricted physical and maintenance access, active network monitoring with event logging and anomaly detection, and comprehensive vulnerability management and continuing-airworthiness processes. Finally, these controls must include tightly managed EFB devices using mobile device management and application controls.
Aerospace Innovations: So once the AID has been certified and the AID has been installed, the operator is off the hook?
Klaus Olsen: No. The operator’s responsibility does not end when the AID is certified and installed. Security assumptions made during aircraft certification must remain valid in service. That means controlling the EFB operating-system version, application versions, device enrollment, certificates, connectivity profiles and supplier changes.
It also requires cooperation between the aircraft design approval holder, AID manufacturer, application provider, EFB Administrator, IT security function, maintenance organization and flight operations department. Cybersecurity is a shared lifecycle responsibility, not a feature that can be assigned to one piece of equipment.
Current airworthiness-security practice is structured around standards including RTCA DO-326/ED-202, DO-356/ED-203 and DO-355/ED-204. EASA AMC 20-42 specifically addresses the identification of assets, attack paths, safety consequences, mitigations, residual risk and continued protection after entry into service.
Aerospace Innovations: What specific data points from the Flight Management System (FMS) are pilots demanding most on their EFBs today, and how do AIDs facilitate that real-time translation?
Klaus Olsen: The greatest demand is for data that removes repetitive manual entry and improves situational awareness without introducing ambiguity.
Depending on the aircraft type, application, and approved interface, the most commonly requested data from the FMS and associated aircraft systems include present position, track, heading, altitude, and groundspeed; active flight-plan information and route progression; as well as origin, destination, and alternate information. Pilots also frequently require estimated times, distance-to-go, and fuel predictions; aircraft gross weight and fuel-on-board information; alongside wind and temperature data. Lastly, demand is high for departure and arrival runway information, and aircraft state or flight-phase information.
These data can support moving-map applications, airport situational awareness, chart positioning, weather applications, turbulence reporting, flight-log automation, electronic operational flight plans and performance-related workflows.
Aerospace Innovations: Beyond simply converting the physical protocols, what role does the AID play in managing this data?
Klaus Olsen: The AID performs more than physical protocol conversion. It may need to acquire data from different avionics buses, identify and validate the relevant parameters, apply scaling and engineering-unit conversion, timestamp the information, filter it according to the approved data set and make it available through a controlled interface that the EFB application can understand.
Pilots naturally want increasing levels of automation, but the operational question must always be: What is the source and integrity of the data, how current is it, and what may the pilot safely use it for? Automatically populating an advisory application is very different from permitting that application to influence a certified aircraft function.
Aerospace Innovations: What are the primary installation and integration challenges when retrofitting older fleets with modern Aircraft Interface Devices compared to forward-fitting them on next-generation aircraft?
Klaus Olsen: Retrofitting is significantly more complex because the aircraft was not originally designed around a connected digital ecosystem.
Common challenges include limited access to suitable avionics data sources, older ARINC 429 or analog architectures with limited bandwidth, and incomplete or aircraft-specific interface documentation. Integrators also face differences between individual aircraft within the same fleet, restricted space, cooling capacity, electrical power, and wiring routes, alongside electromagnetic compatibility and environmental qualification requirements.
Additional hurdles involve antenna placement and wireless-coverage limitations, certification through an STC or approved design change, and the creation of maintenance access and continuing-airworthiness documentation. Finally, there is a critical need to avoid unintended effects on existing certified systems.
Mixed fleets are particularly demanding. An airline may operate several variants of the same aircraft type with different avionics standards, software loads and modification statuses. A solution that appears common at application level may therefore require different installation designs and data mappings on each subfleet.
Forward-fit installations allow segregation, processing capacity, connectivity, power, cooling and future growth to be incorporated into the aircraft architecture from the beginning. Retrofit programs must find safe ways to introduce those capabilities into an established design, usually with tighter physical, technical and commercial constraints.
FAA AC 20-173 addresses certification considerations for installing EFB components and aircraft-connectivity provisions, while EASA’s security guidance also applies to supplemental type certificates and changes to existing products.
Aerospace Innovations: With the sheer volume of data generated by modern aircraft increasing exponentially, how is the architecture of Aircraft Interface Devices evolving to handle future bandwidth and processing requirements?
Klaus Olsen: The architecture is evolving from dedicated interface boxes towards secure edge-computing platforms.
Rather than simply forwarding every available parameter, future AIDs will increasingly need to aggregate, normalize, filter and prioritize data onboard. They may perform local processing, event detection, compression and secure buffering before delivering selected information to the EFB or transmitting it to the ground.
We are also seeing a gradual transition from point-to-point interfaces towards IP-based architectures, modular software services and publish-and-subscribe data distribution. This allows multiple authorized applications to consume standardized information without each application requiring a separate physical aircraft interface.
Aerospace Innovations: As AIDs take on more processing power, how do you prevent them from becoming a vulnerable bottleneck?
Klaus Olsen: Increased processing capability must not result in an uncontrolled concentration of functions. The AID’s role, software configuration, data rights and security boundaries must remain clearly defined. Otherwise, the central hub can become both a performance bottleneck and a high-value cyber target.
Future architectures will therefore need scalability together with partitioning, data governance, deterministic behavior where required, remote health monitoring and an effective mechanism for maintaining security throughout a much longer aircraft lifecycle than that of the connected consumer devices.
Another important trend is that connectivity no longer ends at the AID. Once aircraft data reaches the EFB environment, airlines increasingly expect multiple authorized applications to consume the same trusted data without requiring separate proprietary integration for every combination of applications and software vendors. This is where emerging interoperability standards such as ARINC 840A have the potential to play an important role. By providing a common framework for application-to-application data exchange within the EFB environment, they can reduce integration complexity while supporting appropriate governance and security controls.
Aerospace Innovations: What pain points remain between external devices, AIDs, and aircraft systems?
Klaus Olsen: One of the largest remaining pain points is fragmentation.
Aircraft manufacturers, AID suppliers and EFB application vendors may use different interfaces, data definitions and proprietary software development kits. The same parameter may be represented differently across aircraft types or may not be available with the same integrity, update rate or metadata.
Other recurring issues include limited transparency concerning which aircraft parameters are genuinely available, inconsistent documentation and data dictionaries, and proprietary interfaces leading to supplier lock-in. Operators also struggle with application updates that unintentionally affect compatibility, unclear responsibility when several suppliers are involved, and complex certificate, key, and software-lifecycle management. Lastly, the industry faces long aircraft certification cycles compared with rapid mobile-device development, difficulty reproducing aircraft data environments during testing, and insufficient end-to-end monitoring of the complete data chain.
Aerospace Innovations: What can be done to relieve these pain points?
Klaus Olsen: The solution is greater interoperability, but interoperability must not mean unrestricted access.
The industry needs standardized and semantically consistent data interfaces, clearly defined data-quality attributes, stable APIs, representative integration test environments and contractual clarity concerning configuration control and continued support.
Operators must also treat the EFB, AID and connected applications as one operational ecosystem. Every change to an operating system, application, AID software load, aircraft configuration or security certificate should be assessed for its effect on that ecosystem.
I believe the future EFB Administrator will increasingly become the Guardian of Trust, ensuring that data moving between aircraft systems, Aircraft Interface Devices and EFB applications remains accurate, secure, authorized and operationally appropriate throughout its lifecycle.
The aim should not be to connect everything simply because it is technically possible. The aim should be to provide the right information to the right authorized application, at the right time and with a clearly understood level of integrity.
Aerospace Innovations: Overall, how well has the aviation industry dealt with the challenge of connecting EFBs to aircraft, and what do you foresee happening next?
Klaus Olsen: The industry has made significant progress in connecting aircraft to EFBs, but the next challenge is connecting the EFB ecosystem itself. Airlines should not be forced into proprietary application silos simply because each vendor uses different interfaces. Open, well-governed interoperability standards, combined with robust cybersecurity and clear operational ownership, will allow operators to choose the applications that best support their operation while maintaining the integrity of trusted aircraft data. I believe this will be one of the defining developments in EFB architecture over the next decade.
Aircraft Interface Devices are rapidly becoming the digital gateway between certified aircraft systems and the airline’s operational ecosystem. Their success will ultimately be measured not by how much data they can transfer, but by how securely, reliably and intelligently that data can be governed throughout its operational lifecycle.
Within the next decade, I believe the industry will move away from isolated EFB applications towards integrated digital ecosystems where trusted aircraft data can be securely shared between multiple authorized applications through standardized interfaces.
By James Careless
