MAVLInk encryption

MAVLink
1

Hello MAVLink maintainers and community members,

I have been working closely with MAVLink in security-sensitive UAV applications and wanted to understand the design rationale behind the absence of a native, end-to-end encrypted MAVLink protocol version.

While MAVLink 2.0 introduced important improvements such as message signing (authentication and integrity), it still does not provide payload confidentiality. In practical deployments—especially defense, government, and critical infrastructure UAV systems—unencrypted telemetry and command channels pose serious security risks (eavesdropping, traffic analysis, replay preparation, etc.), even when signing is enabled.

Many users currently implement external encryption layers (VPNs, TLS tunnels, custom AES/HMAC wrappers, radio-level encryption, etc.), but this leads to:

  • Fragmented, non-standard security implementations

  • Increased integration complexity across GCS, autopilot, and companion computers

  • Inconsistent security guarantees across MAVLink ecosystems

From a protocol design perspective, I would appreciate clarification on the following:

  1. Is the absence of native encryption a deliberate architectural decision?
    (e.g., due to low-bandwidth links, MCU constraints, backward compatibility, or regulatory/export concerns)

  2. Are there any ongoing or planned discussions about an encrypted MAVLink variant or optional encrypted transport mode?

  3. Would the MAVLink team consider a standardized approach (e.g., negotiated session keys, encrypted payload frames, or pluggable crypto backends) while preserving lightweight operation?

  4. What is the recommended long-term security model for MAVLink in hostile or contested RF environments?

Given the increasing use of UAVs in security-critical missions, having a standardized, protocol-level encryption option could significantly strengthen MAVLink’s adoption and trust in such domains.

Any insights, references to prior discussions, or future roadmap pointers would be greatly appreciated.

Thank you for your time and for maintaining such a widely used and impactful protocol.

Best regards,
Ajeet
Electronics & Communication Engineer
(UAV Security / MAVLink Developer)

2

Thanks for your thoughtful comments and questions. You’re spot on, encryption is currently left to the transport layer, such as a VPN, tunnel, radio, etc..

I don’t know the full history but my hunch is that there wasn’t a strong push to “roll our own encryption” yet, so not do it ourselves, but instead rely on other trusted ways to do so.

That being said, you are correct that this leads to fragmentation and integration challenges.

This would probably go towards a MAVLink 3 protocol, which would open a whole can of worms, or rather wishlist of many items, protocols, and ideas…

In any case, it’s something worth discussing. It could also be brought up in an upcoming MAVLink dev call (at some point after the holidays).

I’m mentioning @hamishwillee and @auturgy who might have better comments than mine.

3

Thanks @Ajeet1 @JulianOes

It is certainly possible to add encryption layers to MAVLink 2 - in fact it was already done in a student project at one point and the branch is available - just search. This particular implementations has know limitations and should be considered an academic experiment rather than a “solution”.

It does highlight the main problem and reason why encryption is deferred to the transport layer. If we are going to support encryption, along with all the certificate management chains that it requires, then we need to do it robustly. The MAVLink team does not have the expertise to provide an implementation, to validate it if provided by someone else, or maintain it - such as responding to security advisories.

At one point there was thinking that we might endorse a transport layer for IP links and leverage the existing solutions to these issues developed for the internet. This requires a whole lot more testing and experimentation to even be put to the broader stakeholders for consideration - not just because of resource limitations, but because it all looks nice in pure IP environments and then falls over when you get to the lower bandwidth radio link.

In summary, there isn’t any strong push for this problem to be solved in the MAVLink layer, and if there ever is, it is going to require a massive investment to support. I doubt it will happen.

1 Like
4

Hello @JulianOes, @hamishwillee, and MAVLink team,

Thank you both for the detailed and candid responses — I really appreciate the transparency around the historical context, technical constraints, and maintenance realities.

Your points about deferring encryption to the transport layer, the risks of “rolling our own crypto,” and the long-term maintenance burden (validation, advisories, key management, bandwidth constraints on RF links) are well taken. I completely agree that doing encryption incorrectly at the protocol level would be far worse than not doing it at all.

At the same time, as you noted, the current approach does lead to fragmentation and uneven security guarantees across deployments, especially in non-IP or constrained radio environments. That gap is what initially motivated my questions.

For my part, I’m currently exploring this problem space from an applied research and engineering perspective — looking at practical, lightweight approaches that can coexist with MAVLink 2, leverage existing cryptographic libraries, and remain realistic for low-bandwidth and MCU-constrained systems. This is not intended as a drop-in “solution,” but rather as an investigation into what might be feasible without undermining MAVLink’s core strengths.I fully understand that anything beyond experimentation would require significant community buy-in, expertise, and long-term commitment — likely at the scale of a future MAVLink 3 discussion, as Julian mentioned.I’ll continue following existing discussions and, if I reach any insights that may be useful to the broader community (even at an academic or experimental level), I’ll be happy to share them for feedback. I’m also very open to participating in a future dev call if this topic comes up again.

Thanks again for taking the time to engage on this — and for maintaining such a widely used and well-engineered protocol.

Best regards,
Ajeet
Electronics & Communication Engineer
UAV Security / MAVLink Developer

2 Likes