Airline cyber losses happen on the ground while the aircraft stays unmonitored, according to Eliran Almog, CEO of Cyviation. In an interview with Help Net Security, Almog explains that when boards discuss cyber risk, they tend to merge two distinct problems: where money is lost and the small chance of a safety event. By loss, it is not close. Almost everything realized happens on the ground — reservations, ground handling, MRO IT, crew scheduling, and airport operations. That is where ransomware lands and where the next incident will come from. No aircraft has caused a material cyber loss for a carrier yet.
The cinematic version of a cyberattack on a plane involves someone grabbing flight controls in the air, a scenario that deserves skepticism. The real version is duller. The aircraft consumes data from the ground constantly — nav databases, performance data, EFB content, and loadable software. It is the endpoint of a supply chain nobody monitors. Almog argues that the budget mistake isn’t spending on the aircraft; it’s spending on the wrong question. Knowing what software is running on a fleet matters more than pen-testing an avionics bus.
Related: New cybersecurity tools hit the market
Attacker behavior in aviation environments over the past two years often breaks the mental model of a seasoned enterprise SOC analyst. The one that surprises them the most is GNSS interference. A SOC analyst lives in packets, endpoints, and identity, and none of that sees spoofing or jamming. It has 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 is no authentication to bypass. Almog’s team disclosed CVE-2026-1579 in PX4 Autopilot, the flight-control software running on a huge installed base of drones and UAVs. The US Cybersecurity and Infrastructure Security Agency issued advisory ICSA-26-090-02, scoring it 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.
The Electronic Flight Bag is underrated, but mostly as a symptom. It is 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 is 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.
Related: Pilot Protocol launches agent economy platform
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 is the case for a digital twin. Cyviation models 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 the 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. Almog says he sits between those parties by not becoming a pipeline. Operational data exposes utilization, maintenance practice, route economics, and airlines have good reason to keep that from an OEM or lessor. The operator keeps ownership and controls disclosure. He runs 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.
Related: Lenovo Advances Past AWS in Round 2
For a carrier with 30 aircraft and two people in IT security, a credible security program requires ruthless prioritization. Two people can’t hunt threats, engineer detection, and cover the aircraft all at once. The first step is inventory and dependencies, aircraft included — what software is on the fleet, what feeds it, who touches it. That is dull, but nothing works without it, and it is achievable at that size. Second, focus on the ground, because that is where the loss is: MFA everywhere, tight admin and vendor access since that is how most of them get breached, and backups you have actually restored rather than just watched run. Third, buy 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.
