In this interview with Help Net Security, Eliran Almong, CEO of Cyviation, explains why airline cyber losses happen on the ground while the aircraft stays unmonitored. He walks through GNSS jamming that leaves no trace in a SIEM, and a PX4 Autopilot flaw his team disclosed where drone command channels accept unsigned messages.
He argues the Electronic Flight Bag matters less than the data loading chain behind it, makes the case for digital twins, and sets out what a 30 aircraft carrier with two security staff should do first.
When you brief a board, how does aviation cyber risk split between the aircraft and everything on the ground? Does the industry’s fascination with “hacking a plane” divert budget from where losses are occurring?
I split it into two conversations that boards tend to merge: where money is lost, and the small chance of a safety event. By loss, it’s not close. Almost everything realized happens on the ground — reservations, ground handling, MRO IT, crew scheduling, airport operations. That’s where ransomware lands and where the next incident will come from. No aircraft has caused a material cyber loss for a carrier yet.
But “hacking a plane” being overhyped doesn’t make the aircraft irrelevant. The cinematic version, someone grabbing flight controls in flight, deserves the skepticism. The real version is duller: the aircraft consumes data from the ground constantly — nav databases, performance data, EFB content, loadable software. It’s the endpoint of a supply chain nobody monitors.
So, my framing to a board is that the ground is where you’ll lose money, fund it accordingly, and the aircraft is where you’re blind, which is a separate problem. The budget mistake isn’t spending on the aircraft; it’s spending on the wrong question. Knowing what software is running on your fleet matters more than pen-testing an avionics bus.
What attacker behavior have you observed in aviation environments over the past two years that would surprise a seasoned enterprise SOC analyst?
The one that breaks their mental model is GNSS interference. A SOC analyst lives in packets, endpoints, and identity, and none of that sees spoofing or jamming. It’s been routine across the Eastern Mediterranean, Black Sea, and Persian Gulf for two years now, with crews getting false position fixes and inertial systems degrading enough to need maintenance on landing. No log, no alert, nothing in the SIEM. The first sign is a pilot writing it up. An analyst used to detection engineering finds the total absence of telemetry hard to accept.
The other surprise is how often nothing is being exploited. A lot of the ecosystem — ACARS, ADS-B, parts of the data loading chain — was built when the medium itself was the access control, so there’s no authentication to bypass. Our own research illustrates it. In April we disclosed CVE-2026-1579 in PX4 Autopilot, the flight-control software running on a huge installed base of drones and UAVs. CISA issued advisory ICSA-26-090-02, scored 9.8. The problem was simply that MAVLink message signing ships off by default, so the command channel accepts unsigned commands and an attacker on the network can fly the aircraft. No clever exploit chain. The system did exactly what it was designed to do.
That’s the adjustment: in IT you hunt for the bypass; here you more often find a safety-critical channel that never authenticated anyone. And that wasn’t a one-off — we’re extending the research into other flight control platforms.
Is the Electronic Flight Bag the most underrated entry point in aviation, or does focusing on it distract from loadable software parts and the data loading chain?
The EFB is underrated, but mostly as a symptom. It’s a commodity tablet, often with mixed personal use, holding performance data and charts, updated over networks the airline doesn’t control, carried into the cockpit by hand. It’s the most visible piece of ground-to-air data flow, so it gets the attention. The real exposure is the chain behind it, which is the same chain that delivers loadable software parts. What matters is whether you can verify integrity and provenance when data loads, and reconstruct what loaded afterward. Most operators can’t do either.
Some of that is structural. You can’t test an aircraft like an enterprise network — pen-testing an airframe would cost you its airworthiness, so it isn’t done, and documentation ends up standing in for evidence. That’s the case for a digital twin. We model the aircraft’s subsystems and communication paths well enough to do on the twin what you can’t do on the airframe: test a loadable part against hostile input before it reaches a fleet or replay an event to work out whether it was cyber or a fault.
Mapped against our AV-ATT&CK framework, an aviation extension of MITRE ATT&CK covering things like GPS spoofing and TCAS manipulation, it shows which devices are reachable by which technique. EFB and data loading stop being things you attest to and become things you can test.
Airlines guard operational data from manufacturers for commercial reasons. How do you sit between those parties without becoming a pipeline nobody trusts?
By not being one. Operational data exposes utilization, maintenance practice, route economics, and airlines have good reason to keep that from an OEM or lessor. So, the operator keeps ownership and controls disclosure. We run isolated per-customer infrastructure precisely so one airline’s fleet data never touches another’s, analysis happens under their control, and only what they choose to release leaves.
The useful output is usually a specific finding or indicator, not a feed. A vendor that becomes a way for OEMs to harvest fleet data has destroyed its own value, and airlines spot that fast. It also helps to keep security telemetry and operational data separate rather than collecting everything just because you can.
What does a credible security program look like for a carrier with 30 aircraft and two people in IT security?
Ruthless prioritization, starting from the fact that two people can’t hunt threats, engineer detection and cover the aircraft all at once. First, inventory and dependencies, aircraft included — what software is on the fleet, what feeds it, who touches it. Dull, but nothing works without it, and it’s achievable at that size. Second, the ground, because that’s where the loss is: MFA everywhere, tight admin and vendor access since that’s how most of them get breached, and backups you’ve actually restored rather than just watched run. Third, aircraft visibility, which at that scale you buy rather than build — the expertise is too scarce to hire for two seats.
What you need is the ability to answer “what happened on that aircraft” without a six-week investigation, which is again the argument for a shared twin. Skip the bespoke threat-intel program and any framework pursued for its own sake. And write the incident response plan, because at 30 aircraft the difference between a bad week and a disaster is usually whether someone thought through the first few hours ahead of time.
Read more:
- Airbus CSO on supply chain blind spots, space threats, and the limits of AI red-teaming
- United Airlines CISO on building resilience when disruption is inevitable
- Southwest Airlines CISO on tackling cyber risks in the aviation industry