Claims about modifying the F-35’s software raise legitimate sovereignty questions. But cybersecurity architecture, cryptography, and sustainment realities define strict limits on what can and cannot be done.
As we reported in detail in a previous story, on Feb. 15, 2026, talking to the BNR Nieuwsradio Podcast, Dutch State Secretary for Defence Gijs Tuinman suggested that the F-35’s software could theoretically be “jailbroken,” drawing a comparison with modifying an iPhone.
“I’m going to say something I should never say, but I’ll do it anyway. Just like your iPhone, you can jailbreak an F-35. I won’t say more about it.”
Needless to say, his remarks made the news, reigniting debate about software sovereignty, operational independence, and control over 5th generation aircraft, something we have often commented here at The Aviationist.
Generally speaking, comparing it to a popular smartphone is effective in capturing the public imagination (and this Author has used the analogy before to explain basic concepts behind modern combat aircraft to the general public), but it becomes misleading when taken too literally.
In fact, the Lockheed Martin F-35 Lightning II is (quite obviously) not a smartphone and its software architecture was never designed to allow operator-level modification in the first place.
While the detailed internal implementation of the F-35’s mission systems remains classified, the cybersecurity and avionics engineering principles used to protect systems of this kind are very well known. These principles allow us to do a reality check and establish realistic boundaries around what could, and more importantly what could not, be achieved through attempts to modify, bypass, or independently control the aircraft’s software.
General public often forget that the aircraft is not simply a fighter, but a secure, software-defined combat system (often referred to as a “system of systems”) built around cryptographic trust, controlled software supply chains, and tightly integrated sustainment infrastructure.
The F-35 is not a consumer device
A quick search will tell you that jailbreaking is the act of removing software restrictions imposed by the manufacturer to gain full control over the operating system. On consumer devices, this allows users to install unauthorized apps, tweak the interface, and remove pre-installed software, effectively bypassing the vendor’s built-in safeguards.
That concept exists because consumer devices are designed to allow a certain level of user interaction with their software environment.
The F-35 is not.
We do not know the classified details of the aircraft’s cybersecurity architecture, but we do not need to. Modern military avionics handling sensitive mission data and weapons integration are built around well-established secure system design principles. It is reasonable to assume the F-35 meets, and likely exceeds, those standards.
These systems rely on hardware-rooted trust, cryptographic authentication, hardcoded keys, and tightly controlled software loading mechanisms to ensure that only authorized code can run. Software is not simply “installed.” It must be authenticated, verified, and accepted by the system before execution.
Without access to the trusted signing infrastructure, cryptographic credentials, and authorized deployment pipelines, independently installing or modifying mission system software would be extraordinarily difficult.
This is not unique to the F-35; it reflects standard practice across modern military platforms, secure communications systems, and critical infrastructure. In these environments, trust is enforced cryptographically, not physically.
Why access to the aircraft alone is not enough
The F-35’s software is made by millions of lines of code (+8M according to most sources), lines that enable sensor fusion, electronic warfare, mission management, and weapons integration. But complexity alone does not secure the system (quite the opposite!). Critical components are most probably protected through digital signing, encryption, and hardware-based trust anchors (the equivalent of Hardware Security Modules or HSMs, used in the IT world) that ensure software authenticity and integrity.
Even if someone managed to extract software binaries, modifying and redeploying them in an operational aircraft would probably require access to:
- Cryptographic signing and encryption keys
- Software build environments
- Integration and validation systems
- Trusted software distribution pipelines
Without these, any modification would fail authentication or risk making the system unstable or inoperable. This reflects a core cybersecurity principle: possession does not equal control. Trust must be established, verified, and continuously validated, never assumed. This principle is the foundation of what in cyber security is known as the Zero Trust security paradigm.
Someone suggested the Dutch State Secretary for Defence may have used the wrong term, as he might have been referring to reverse engineering the F-35 rather than “jailbreaking” it. Generally speaking, software can be analyzed through reverse engineering, with the purpose of understanding its structure, logic, and function. However, understanding how the code works is not the same as safely modifying and operating it. The latter would be an extraordinarily complex and risky task. Does this mean the F-35 can’t be hacked? Probably not, but this is not the point here.
The Dutch State Secretary’s remarks may have referred less to hacking and more to the broader question of software sovereignty: can operators independently update, modify, and sustain the aircraft without relying on the original manufacturer or U.S.-controlled sustainment infrastructure?
This is a legitimate strategic question; still, fundamentally different from “jailbreaking.”
Modern combat aircraft software is not just the code we mentioned above. It is developed and run within a controlled software supply chain that includes development environments, validation frameworks, and secure distribution systems.
Replicating the same ecosystem independently would require building a complete sovereign software sustainment capability, not simply accessing or modifying onboard systems. And, last but not least, attempting to independently modify software outside official support channels could create legal, technical, and operational consequences, including potential loss of vendor/manufacturer support and sustainment access. In other words, the operator would break what we normally call the Terms of Service of the system.
The role of ODIN
As explained multiple times, the F-35 is not a standalone system. Just like all most modern combat aircraft, it depends on constant access to spare parts, maintenance support, component repair, software updates, and threat intelligence integration. That’s why another critical aspect that has often come under the spotlight is the role of the aircraft’s infologistic system, originally known as ALIS, now replaced by ODIN (Operational Data Integrated Network).
ODIN serves as the aircraft’s global software and sustainment infrastructure, managing maintenance data, mission planning support, configuration control, and software updates. Aircraft and support systems exchange data with national and centralized infrastructure that enables fleet-wide software updates, configuration integrity, and sustainment planning.
This architecture ensures operational consistency, safety, and cybersecurity across the global fleet. For this reason, independent software modification would require not just access to onboard systems, but the ability to replicate or replace key elements of this infrastructure, most of those are not even in country but managed by the U.S.
In 2019, we interviewed Davide Marzinotto, the Commander of the 32° Stormo (Wing) of the Italian Air Force, the first unit in Italy to operate the F-35. Here’s what he told us about ALIS (this helps understanding the role it played the infologistic system, now replaced by ODIN and the concerns around data sovereignty of U.S. allies):
“The architecture of ALIS provides an approach to logistics and global support that is innovative for the military world. On the one hand there is the need to satisfy the needs of logistic support, making economies of scale, sharing spare parts or resupply processes; on the other hand there is the need to guarantee the containment of information (including logistics information). Imagine the case that one of my aircraft is grounded, waiting for a spare part: it is quite normal that I need to expose the need if I want to access a warehouse that resides outside of Italy. At the same time I must protect information that is not inherent or relevant to the logistics sphere and that is not appropriate to be conveyed outside national borders. ALIS is an “infostructure” in great evolution that is preparing to serve the needs of all nations and international partners. In a few months, we will be the first outside the United States, to receive a series of packages that will allow us to regulate, on the basis of a purely national choice, certain information that is aimed at satisfying logistic needs and others that have no reason to be included within this extra-national basin. The changes to ALIS that allow each partner to customize the information flow, selecting what to share and what not to share are being experimented, tested and certified, with the release scheduled for the first half of the year. On the same subject, it should also be remembered that one of the initial requirements of the program was the use of a PHM (Prognostics and Health Management) system which envisaged the possibility that the F-35s in flight would communicate certain aspects of diagnostics or prognostics to the base, in order to prepare the planned maintenance interventions or the start the provisioning of the spare parts: a capacity that is considered not relevant at the moment, but which could be implemented in the future.”
Capability dependency
In the end, the same design choices that make the F-35 exceptionally resilient against tampering, reverse engineering, or unauthorized modification also ensure that its most advanced capabilities remain dependent on a controlled and continuously maintained software and support framework.
While the often-repeated claim that the United States could simply disable partner’s F-35s via a remote “kill switch” is an oversimplification that does not reflect how the aircraft actually operates, the F-35 is, in the end, a “software-defined” platform whose effectiveness depends heavily on continuous access to U.S.-managed updates, mission data files (MDFs), and the broader sustainment and logistics ecosystem.
In other words, the aircraft can’t be abruptly switched off remotely, but its long-term combat value is strictly dependent on the continued access to the ecosystem that sustains it: the result of “disconnecting” the F-35 is not an immediate shutdown or inability to fly, but a gradual erosion of capability. The aircraft transitions from a fully networked 5th gen. platform into something progressively less survivable and less effective against modern threats.
Here’s where the comparison between an F-35 and an iPhone really works: if you stop updating your smartphone, it doesn’t suddenly stop working as you can still make calls, send messages or use the apps already installed on it. But over time, it becomes outdated, unable to support new apps or update the existing ones, security patches, or advanced functionalities, or interact with other, more recent, smartphones. Eventually, it reaches a point where it can only perform the most basic tasks, making it irrelevant…
What adversaries would realistically seek from access to an F-35
One might wonder: if the F-35 can’t be “jailbroken” why are all the operators worried it could be studied by Russia or China? Indeed, in the past, we have reported on the efforts undertaken by the U.S. and partner nations to recover F-35 airframes that had crashed at sea before they could fall into enemy hands. Notable examples include the complex recovery of a British F-35B that crashed into the Mediterranean Sea in 2021 and the race to retrieve a U.S. Navy F-35C that went down in the South China Sea in early 2022. These recovery operations, carried out at significant technical and financial cost and often under intense time pressure, were conducted to protect the airframe itself rather than the “source code” running on it. The airframe embodies decades of research, testing, and engineering refinement.
If an adversary were ever to gain access to one (in good shape), the most valuable insights would likely come not from attempting to rewrite its code, but from studying its physical and electronic architecture. Sensor integration alone, including radar arrays, distributed aperture systems, and electronic warfare hardware, would offer significant clues about how the aircraft achieves its situational awareness and survivability. Low observable coatings, structural shaping, and material composition would be carefully analyzed to better understand signature management across radar and infrared spectrum. Parts of the intakes and of the Pratt & Whitney F135 engine, usually closely guarded from photography at close distance under certain circumstances (something we have experienced first hand multiple times over the last few years, at F-35 based in Italy and U.S.), would all represent high-value intelligence targets.
Historically, when advanced aircraft have been captured or obtained through defections, exploitation efforts have focused primarily on hardware characteristics, materials science, propulsion performance, and aerodynamic behavior. As far as we know, software takeover has never been the primary objective. Instead, the goal has been to understand design philosophy, identify potential weaknesses, and inform countermeasure development or future indigenous programs. We were in a different era, when aircraft were less “software-defined” than they are today, but it’s safe to believe that access to the aircraft would indeed matter, but mainly not for the reasons suggested in the “jailbreak” narrative.
