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 well understood. 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.
Understanding why requires looking at the aircraft not simply as a fighter, but as 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 simple online search will show that jailbreaking refers to the process of removing software restrictions imposed by the manufacturer in order to gain full root access to the operating system. This allows users to install unauthorized applications, customize the user interface, and remove pre-installed software, effectively bypassing the vendor’s built-in security mechanisms.
That concept applies to consumer devices because those devices are designed to support user-level software installation and developer access.
The F-35 is not.
Even without detailed knowledge of the F-35’s cybersecurity architecture, it is reasonable to assume it is at least on par with, if not more advanced than, modern military avionics systems handling sensitive mission data and weapons integration. These systems rely on state-of-the-art hardware-rooted trust mechanisms, cryptographic authentication, and tightly controlled software loading processes designed to ensure that only authorized and validated software can execute.
In practice, this means software components must be authenticated and verified before being allowed to run, preventing unauthorized or modified code from being introduced into mission-critical systems.
Without access to trusted software signing infrastructure, cryptographic credentials, and authorized software deployment pipelines, independently installing or modifying operational mission system software would be extraordinarily difficult.
This approach is not unique to any single aircraft. It reflects standard security practices used across modern military platforms, secure communications systems, and critical infrastructure, where trust is enforced through cryptographic assurance and controlled software supply chains rather than physical access alone.
Why access to the aircraft alone is not enough
The F-35’s software comprises millions of lines of code (+8M according to most sources), enabling sensor fusion, electronic warfare, mission management, and weapons integration. But complexity alone does not secure the system (quite the opposite). Critical components are 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 software binaries were extracted, 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 rendering 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 forms the foundation of what is known as the Zero Trust security model.
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, revealing 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 undertaking.
The Dutch State Secretary’s remarks may have referred less to hacking and more to the broader question of software sovereignty: whether operators can 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 code. It exists within a controlled software supply chain that includes development environments, validation frameworks, and secure distribution systems.
Recreating 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 manufacturer support and sustainment access.
The role of ODIN
As explained, the F-35 is not a standalone system. As all most modern combat aircraft, it depends on sustained 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, and now replaced by ODIN (Operational Data Integrated Network).
ODIN functions 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 trusted sustainment and software distribution infrastructure, most of those are not even in country but managed by the U.S.
Capability dependency
Ultimately, 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 notion that the United States could simply disable foreign-operated F-35s via a remote “kill switch” is an oversimplification that does not reflect how the aircraft actually operates, the F-35 is fundamentally 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 inseparable from 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 front-line, fully networked fifth-generation 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 work: if you stop updating your smartphone, it doesn’t suddenly stop working as you can still make calls and send messages. But over time, it becomes outdated, unable to support new apps, security patches, or advanced functionalities, or interact with other, updated, 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, 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.
