It didn’t take long to end up staring at the control traffic. Unsurprisingly, it was MAVLink. Lightweight, chatty, flexible, and largely built around the assumption that everyone on the link is friendly. That isn’t a criticism so much as a design reality. MAVLink is optimised for low bandwidth, low latency links between constrained devices. Authentication, confidentiality, and strong integrity guarantees are explicitly not first-class concerns in most deployments. For a £90 drone flown from a phone app, that’s entirely reasonable.

What made it interesting was the wider context. We now see this exact class of hardware and protocol used in operationally serious environments. Sometimes the ground control station is a ruggedised laptop in the field. Sometimes it’s something far more sensitive, connected to other systems, networks, and data flows that absolutely do matter. In those cases, the threat model changes completely.

At that point the problem is no longer “what if someone attacks the drone?”. It’s “what if the drone becomes an ingress path into the control system?” or the inverse: “what if a compromised or malfunctioning GCS issues technically valid but operationally dangerous commands?”. MAVLink doesn’t distinguish between sensible and dumb. If the message is well-formed it will be accepted.

That line of thinking led me to my day job (of course). Mavlink Security Gateway. Not a firewall. Not a packet filter. Not “just add encryption” or “ZERO TRUST OVERLAY!!!11”. A Cross Domain Solution, sort of: something that understands the data model of the protocol, is configured according to an information handling model and data taxonomy, enforces explicit policy at a trust boundary, and fails closed. In my initial experiments the boundary is just localhost, but there is nothing about the idea that doesn’t scale to radio links, network segments, or physically separate domains.

A high level over view of what a CDS (sort of) does

The core idea is a small gateway that sits between two MAVLink endpoints, on a more trusted network segment and mediates everything. It parses messages, tracks state, and makes an explicit allow/deny decision for each message based on policy. That immediately opens up a much richer control surface than most people realise they need.

For example: allow and deny lists for message types are the obvious start, but they’re not sufficient. Many MAVLink messages are overloaded or context-dependent. A PARAM_SET is very different depending on which parameter is being touched and what value is being written. A MISSION_ITEM upload might be acceptable in one phase of operation and completely unacceptable in another. Heartbeats and attitude updates are benign until they’re used as a covert signalling channel.

So the gateway needs to do more. Sanity checking fields and ranges, not just structure. Enforcing replay protection by tracking sequence numbers and timing. Being able to block entire classes of behaviour: parameter enumeration, parameter writes, log downloads, mission uploads, debug and status text. All of these are perfectly valid MAVLink features. All of them are also excellent ways to leak data, influence behaviour, or create side effects across a trust boundary.

I ended up with a simple JSON-based policy schema to describe what “normal” looks like. Which messages are expected, in which direction, at what rate, with what value ranges. Everything else gets dropped by default. It’s deliberately boring and explicit. That’s the point. Implicit trust is replaced with explicit permission.

The concept of the security gateway, kinda

Here's an example of some of the fun stuff you can block, or allow, or exploit if you're so inclined

Common Command IDs

Digging into some of the above, ARM_DISARM, Yes obviously critical. But mostly because “arm” and “disarm” are treated as moral opposites when only one of them is actually exciting. Disarm at the wrong time is rude. Arm at the wrong time is a career-limiting move.

NAV_RETURN_TO_LAUNCH - Calling this “Medium” assumes your home position is correct, trustworthy, and not set by someone who hates you. If home is wrong, this is just “fly enthusiastically to the wrong place”.

DO_FLIGHTTERMINATION - This is a fun one. To borrow an excerpt from PX4's documentation. “There is no way to recover from flight termination. After triggering you should unplug the battery as soon as possible. You will need to reboot/power cycle the vehicle before it can be used again. When Flight termination is activated, PX4 simultaneously turns off all controllers and sets all PWM outputs to their failsafe values.”. So, it’s the big red button.

As you can see there’s clearly a defensive angle to consider for the airframe as well as keeping the system controlling it safe. If your control system is compromised, misconfigured, or simply buggy, MAVLink will quite happily forward commands that are legal but stupid: extreme parameter values, nonsensical missions, mode changes at the wrong time. A gateway that encodes basic operational expectations can prevent a surprising amount of damage without needing to trust the sender at all. It becomes a safety layer as much as a security one.

None of it feels dangerous in isolation. In aggregate, across a boundary between domains with different trust assumptions, it very much is. The project itself is very much a prototype. It is not production ready, and it is not pretending to be. But it was a useful exercise, and a useful reminder. A lot of cyber-physical systems rely far too heavily on the assumption that the other end of the wire is well-behaved. When that assumption fails, the protocol will not save you.

All of this was kicked off by a cheap Christmas drone, a bit of curiosity, and me looking for an excuse to get my laptop out. “How can I make a CDS for it?” has turned out to be a surprisingly effective way of learning new things.

The project is here if you’re interested and want to go on a deep dive into what the gateway can block, allow and how you can use it. This little overview is super high level and there’s a million little fun details about MAVlink not covered: https://github.com/samb4secure/mavlink-security-gateway