Avionics Penetration Testing: Inside an F-35 System-of-Systems Assessment

Why avionics penetration testing is a different discipline

Start with the thing that trips up every team coming from web security. In an IT pentest, the crown jewel is data. In avionics penetration testing, the crown jewel is a decision — the aircraft’s belief about where it is, what is around it, and whether the thing on the radar is a friend or a threat. You are not testing whether an attacker can read a database. You are testing whether they can make a $80M aircraft trust a lie.

The F-35 Lightning II is the sharpest example on the planet. It is the most software-intensive weapons system ever fielded: north of 8.5 million lines of code, spread across more than 1,900 suppliers, fusing radar, electro-optical, and electronic-warfare data in real time. That transformation — from a mechanically-defined aircraft to a software-defined System-of-Systems — is exactly what makes it lethal. It is also what creates the paradox at the centre of this assessment.

Call it the Information Superiority Paradox. The same connectivity that grants tactical advantage introduces systemic cyber risk. Every data link that makes the jet smarter is another surface that has to be defended. You cannot have one without the other, and pretending otherwise is how programmes get surprised.

None of what follows required a hangar or a security clearance. It is built from public material: the MIL-STD-1553 and ARINC specifications, the NIST SP 800-115 testing methodology, the MITRE ATT&CK for ICS framework, and years of open DOT&E survivability reporting. That is the honest scope of an educational assessment — and, frankly, it is enough to make the point.

The point is uncomfortable. An aircraft this connected has an attack surface that no single specialist fully holds in their head. Which is precisely the argument for testing it the way an adversary would: continuously, across every domain, without assuming any part is out of reach.

The five domains avionics penetration testing has to cover

Scope is where an avionics penetration testing engagement lives or dies. Miss a domain and you have not reduced risk — you have documented a fraction of it and called it done. A credible assessment of a platform like this spans five distinct domains, each with its own physics and its own entry points.

• Ground systems — the logistics and mission-planning backbone (ALIS, and its successor ODIN), plus the portable devices that carry data to the aircraft.
• RF and wireless — the tactical data links: Link-16, MADL, and SatCom. Reachable without ever touching the airframe.
• Avionics bus — the internal networks, MIL-STD-1553B and ARINC 664/429, that carry commands between flight control, weapons, radar, and engine.
• Embedded — the RTOS partitions, FPGA IP cores, and JTAG debug interfaces down at the silicon layer.
• Sensor fusion — the AN/APG-81 radar, EOTS, DAS, and the mission-data files that decide what a detected signal actually is.

These are not equally hard to reach, and a good test says so plainly. RF and ground surfaces are the most accessible to an outside adversary; the bus and silicon usually require supply-chain or physical access. But reachability is not the same as safety, and the domains are chained — a foothold in one becomes the way into the next. That is the whole game.

Vintage pipes: where avionics penetration testing spends its budget

Here is the single most important idea in avionics penetration testing, and it is almost embarrassingly simple. The internal buses were designed for a world where physical access was the security boundary. If you could reach the wire, you were already trusted.

MIL-STD-1553 dates to the 1970s. It runs at 1 Mbps on a multi-drop topology, and it carries the most critical traffic on the aircraft: flight control, stores management, engine authority.

Its authentication model is a single word — none. Any device on the bus can impersonate the Bus Controller and issue commands to any Remote Terminal, and the receiving terminal has no way to ask “are you actually allowed to tell me this?” As the field puts it: modern warfare on vintage pipes.

ARINC 429 is not much better — its “security” is the electrical characteristics of the signal itself, which means physical-layer manipulation does not even need protocol knowledge.

ARINC 664 (AFDX) is the modern one, switched and running at 100 Mbps with virtual links, and it is meaningfully more defensible — but it still shares a platform with the older buses, and a chain is only as strong as its oldest link.

Why does this matter for an avionics penetration testing plan? Because it tells you where the money is. You do not spend your budget fuzzing the switched, partly-defended bus and skip the one with no authentication. You assume the 1553 bus is hostile from the first hour and design the test — and the defence — around that assumption.

That assume-hostile posture is the line between real avionics penetration testing and a compliance checkbox.

The attack surface taxonomy, mapped to MITRE

Findings are only useful when they are structured. Ours map every domain to an entry point, a target, an impact, and a MITRE ATT&CK technique, so a defender can reason about them the same way they reason about IT threats. Below is the shape of it — deliberately conceptual, because the value here is the taxonomy, not a recipe.

On the ground, the entry point is the enterprise network and the target is the logistics backend; corrupt a mission data file there and the impact rides the supply chain rather than the airframe. Mapping every one of these paths is the daily work of avionics penetration testing.

Over RF, a software-defined radio becomes the entry point into Link-16, where the payoff is a false track injected into the picture. On the bus, a tap is the entry and command injection is the impact. At the silicon layer, an open JTAG port or a third-party FPGA core is the entry and a persistent backdoor is the impact. And in fusion, spoofed inputs produce confusion — the aircraft believing something that is not there, or missing something that is.

We are describing these at the level of “what class of weakness, and why it matters,” not publishing a working exploit. That is a deliberate line. This is educational research about a live defence platform, and the useful output for a defender is the map, the CVSS-weighted priority, and the countermeasure — not a payload. If you want the offensive mechanics, they live in the public academic literature this work cites.

Consolidated, the picture is a heat map, not a single headline. Bus command injection sits at the top — high likelihood of success given access, critical impact on flight-safety subsystems.

Supply-chain compromise of the logistics backend is lower-likelihood but equally critical in blast radius. Sensor-fusion false-data injection sits in the dangerous middle: not trivial, but devastating when it lands, because it corrupts the one thing the whole platform depends on — trust in its own picture.

Structured this way, avionics penetration testing hands a defender a priority order to act on — not an undifferentiated pile of findings.

How one corrupted file becomes a fleet problem

The scariest paths in avionics penetration testing are rarely the loud ones. They are quiet, they use the system’s own trusted plumbing, and they scale. The logistics kill chain is the textbook case, and it is worth walking conceptually because it reframes what “the aircraft” even means.

The insight is that the aircraft is the last step, not the first. An adversary who compromises the ground logistics environment does not need to touch a jet. They corrupt a mission data file — the library that tells the aircraft how to classify what its sensors see.

That file is then delivered through entirely legitimate channels: a technician, a portable device, a routine pre-flight upload. Every step after the initial compromise looks normal, because it is normal. The malice was injected upstream, into something the aircraft is designed to trust.

Now multiply it. A logistics backend serves a fleet, not a tail number. A single upstream corruption is a fleet-wide exposure, which is exactly why supply-chain findings score so high on impact even when their likelihood is modest.

It is also why the defensive answer is not “patch the aircraft” — it is provenance and validation for everything the aircraft ingests. This is the same lesson our connected-vehicle research found in a different industry: one broken trust assumption in a backend becomes command over an entire fleet.

Sensor fusion and the ghost-track problem

Sensor fusion is where avionics penetration testing stops being an analogy for IT security and becomes something stranger. The fusion engine aggregates radar, electro-optical, distributed-aperture, and electronic-warfare data into one coherent picture. False Data Injection attacks do not break that engine. They feed it, and let it do its job on poisoned inputs.

Picture the failure mode a pilot would actually experience. Ghost tracks — targets that are not there — appear alongside real ones, because injected data correlated cleanly with spoofed electronic-warfare signals.

Or the inverse, quieter and worse: a real threat re-classified as friendly before it is ever engaged. The cockpit glass is telling a confident, well-rendered story, and the story is wrong. That is the deepest risk in the whole assessment, because it corrupts the decision layer directly.

Here is the encouraging part, and it is where good avionics penetration testing earns its keep — this class is detectable, and the detection is not exotic. It is cross-validation.

If GPS says the aircraft is stationary but the accelerometer reports 4G of maneuvering, the physics is impossible and one of the sources is lying. If the inertial navigation system and GPS diverge beyond a sane tolerance, that gap is a signal. If a node’s response time deviates more than three standard deviations from its baseline, flag it. None of that requires trusting any single sensor — it requires refusing to.

What held, what didn’t: the survivability picture

A test that only reports what broke is marketing, not research. The honest survivability picture from open reporting is mixed, and the mix is the finding.

What has improved: the perimeter. Programme investment in hardening the outward-facing surfaces has measurably paid off, and that deserves to be said. What has not improved enough: internal propagation.

The recurring assessment result is that once an adversary is inside, they move — and Red Teams operating under a realistic “persistent adversary” doctrine consistently achieve mission degradation after the initial breach. The wall got taller. The inside stayed flat.

Layered on top is modernization risk. The TR-3 hardware and software transition has been openly described in oversight reporting as immature and insufficiently tested, and from a security standpoint instability is not a separate problem from vulnerability — it is one. Systems that behave unpredictably are systems whose security properties you cannot prove.

And there is a structural tempo mismatch underneath all of it: certification takes years, exploit development takes days. The defenders are running a process built for a slower adversary than the one they have.

This is the same structural gap we documented in what manual pentests miss — a point-in-time, human-paced assessment cannot keep up with a surface that changes faster than the test cycle. On an airframe with an eight-million-line codebase, that gap is not academic.

Closing it is exactly what continuous avionics penetration testing exists to do.

Zero-trust avionics: the defensive mandates

This is the part that matters, and it is where an avionics penetration testing programme should spend most of its energy. Finding the breaks is the easy half. Engineering the platform so the breaks are contained is the work. Five mandates fall out of the assessment.

Assume the breach. Design for detection and containment, not prevention alone. The logistics backend will eventually fail somewhere; the question is whether the aircraft notices what it was handed.

Treat the bus as hostile. This is the concrete one. Hardware bus guardians sit on critical Remote Terminals and do three things a 1970s protocol cannot do for itself: monitor the electrical layer for physical anomalies, enforce a protocol allow-list, and lock out a “babbling idiot” node that has started injecting.

It is authentication bolted on at the only layer where you can still add it.

Validate continuously. Cross-source sensor validation — the kinematic and divergence checks above — turns the fusion engine from a single point of failure into a self-auditing system. A Z-score on node response times catches the rogue device that a signature never will.

Secure the supply chain. Hardware provenance for every FPGA IP core, because a logic bomb in a third-party controller is invisible to every runtime defence you deploy above it.

Train for degraded operations. The human in the cockpit is a security control. A pilot trained to recognise when the glass is lying — to fly the aircraft, not the display — is the last and most resilient validation layer the system has.

Taken together, these five mandates are what avionics penetration testing is ultimately for: not the breaks, but the containment around them.

How SelfHack AI approaches avionics penetration testing

Everything above is why we built SelfHack AI the way we did. A platform with five domains, eight million lines of code, and a trust boundary that runs through a 1970s bus is not a target a human team can hold in scope for two weeks and call covered.

It is a reasoning problem at a scale that punishes checklists — the case for autonomous avionics penetration testing in a single sentence.

SelfHack AI is an autonomous penetration testing system that treats an assessment the way this research was actually conducted — not as a fixed list of tests to execute, but as a boundary to interrogate. It maps the surface continuously, generates hypotheses about how a trust assumption could break, tests them in isolation, and — critically — corrects itself when the evidence says it was wrong. That continuous, self-correcting loop is what avionics penetration testing becomes when a human clock stops bounding it.

The same engine that found the attestation binding gap in confidential computing reasons about a data bus the same way: what does this component trust, and what happens when that trust is misplaced?

That autonomy is the point. It is what lets one assessment span the ground backend, the RF links, the bus, the silicon, and the fusion layer without pretending any of them are out of scope.

It is also what makes continuous validation — the thing the survivability picture demands — actually feasible, instead of a once-a-year snapshot of a system that changes weekly. If avionics is the extreme case, it is also the clearest argument for the approach: you cannot manually keep pace with a software-defined weapon, and you should not pretend to.

The same reasoning applies far outside aerospace. The identical trust-boundary logic drives our work on external attack surfaces and on AI and LLM applications — different systems, same question about where trust is assumed and never verified.

How to scope an avionics penetration testing engagement

If you own a connected aircraft, an avionics subsystem, or the ground infrastructure behind one, a real avionics penetration testing engagement starts with three honest questions.

First, which of the five domains are actually in scope, and which are being quietly excluded because they are hard? An assessment that skips the bus because bus access is difficult is testing the easy half. That is not avionics penetration testing; that is a demo.

Second, does the test exercise the seams — the ground-to-air delivery path, the sensor-to-fusion trust chain — or only the components in isolation? The chained paths are where the real impact lives. Third, is it a point-in-time snapshot or continuous? For a system that changes faster than it can be certified, only continuous coverage tells the truth.

None of this is exclusive to the F-35. Business jets, UAVs, and the avionics supply chain share the same protocols and the same 1970s trust assumptions. The platform is extreme; the lesson is general. If you want to see what an autonomous assessment surfaces on your own systems, talk to our team.

FAQ

Is this real F-35 vulnerability data?

No — and that distinction matters. This is an educational assessment built entirely from public sources: open standards (MIL-STD-1553B, ARINC 664/429), the NIST SP 800-115 testing methodology, MITRE ATT&CK, and publicly released DOT&E survivability reporting. No classified information is involved and no live system was accessed.

It is marked UNCLASSIFIED // EDUCATIONAL SIMULATION for exactly that reason. The value is in the methodology and the defensive engineering, not in operational detail.

What is avionics penetration testing, in one sentence?

It is the practice of assessing an aircraft’s electronic systems — its buses, data links, embedded computers, and sensor fusion — the way an adversary would, to find where the platform can be made to trust false information before someone hostile does. Unlike IT penetration testing, the objective is protecting the integrity of decisions, not just the confidentiality of data.

Why is MIL-STD-1553 considered insecure?

Because it was designed in the 1970s for a threat model where physical access to the wire was the security boundary. It has no authentication: any device on the bus can impersonate the controller and issue commands that critical subsystems will obey. That was a reasonable assumption when the bus was sealed inside an airframe. It is a dangerous one now that the airframe is a connected System-of-Systems.

Can this kind of attack be detected and prevented?

Yes, and most of this page is about how. Hardware bus guardians add the authentication and lockout that the protocol lacks. Cross-source sensor validation — kinematic consistency, INS/GPS divergence, statistical anomaly detection — catches false data injection without trusting any single sensor. Supply-chain provenance closes the FPGA and logistics paths. Detection is very achievable; the gap is deploying it consistently across every domain.

How does an autonomous system help with avionics penetration testing?

Scale and continuity. A platform with five domains and millions of lines of code is too large for a human team to cover comprehensively in a fixed window, and it changes faster than an annual test cycle. An autonomous system like SelfHack AI maps the full surface, reasons about trust boundaries across every domain at once, and validates continuously — turning a point-in-time snapshot into ongoing coverage.

The verdict

The line this research keeps returning to is not a slogan, even though it reads like one: cyber security is flight safety. Once a weapons system is defined by software, an attacker who corrupts the software corrupts the mission — and the aircraft cannot tell the difference between a legitimate command and a well-formed lie unless someone engineered it to.

That is the whole case for avionics penetration testing done properly: not IT compliance stapled onto an airframe, but a survivability discipline that assumes breach, treats the bus as hostile, validates continuously, and trusts nothing it did not verify. The F-35 is the sharpest illustration because it is the most connected. Every platform behind it inherits the same problem on a smaller scale.

SelfHack AI exists to test that boundary — on aircraft, on infrastructure, and on the AI systems that are becoming the next software-defined attack surface. If you are responsible for something that has to be trusted when it matters most, let’s talk about testing it before an adversary does.

Sources & further reading: NIST SP 800-115, Technical Guide to Information Security Testing; MITRE ATT&CK for ICS; CISA Industrial Control Systems guidance. Avionics standards MIL-STD-1553B and ARINC 664/429 referenced from their public specifications; survivability findings from open DOT&E annual reporting. Educational simulation only.