MAVLink 2 message signing lets a vehicle or ground station verify that a message came from a trusted source. A signed packet carries 13 extra bytes: a link ID, a timestamp and a 48 bit signature made from a SHA-256 hash and a shared 32 byte secret key. It is authentication, not encryption.
How a signed packet is built
Per the MAVLink guide, a signed packet sets the 0x01 bit in the incompatibility flags and appends 13 bytes. Those are an 8 bit link ID, a 48 bit timestamp and a 48 bit signature.
The signature is the first 48 bits of a SHA-256 hash taken over the packet header, payload, CRC, link ID and timestamp, with the 32 byte secret key appended. Libraries that do not support signing must drop signed packets, because the incompatibility flag tells them they cannot handle the packet.
The secret key
The key is 32 bytes and shared by both ends of a link. It can come from a user passphrase run through SHA-256, or from a random generator. It is sent with the SETUP_SIGNING message, which should go only over a secure link such as USB or wired Ethernet. It must never be broadcast or forwarded automatically.
The key belongs in persistent storage. It must not appear in parameters or logs. The guide says signatures are stripped from telemetry logs, and SETUP_SIGNING secrets are omitted or overwritten, so attackers cannot collect signature data or the key from them.
Timestamps and replay
Each stream, identified by system ID, component ID and link ID, needs strictly increasing timestamps in 10 microsecond units counted from 1 January 2015. A receiver rejects a signed packet if its timestamp goes backward or is more than one minute behind the local timestamp.
A timestamp from an incorrectly signed packet must never update the local link timestamp. That detail stops an attacker from pushing the clock forward with junk packets. Devices with no reliable clock should persist the timestamp regularly and resync from GPS or system time when they can.
Unsigned packets are still allowed by design
This is the part to read twice. Libraries should allow conditional acceptance of unsigned packets, using rules such as a parameter, a secure transport or a specific message type. RADIO_STATUS is suggested as always accepted. Incorrectly signed packets can be accepted for uses like locating a lost vehicle, as long as the system clearly warns that the connection is insecure.
So enabling signing is not the same as rejecting everything unsigned. Check how your autopilot and ground station are configured, and test what happens when an unsigned command arrives.
What the guide does not say
The page has no threat model. It points to a separate proposal document for replay and offline attack analysis, which I did not read. It does not describe encryption, so assume a signed link is still readable by anyone who can listen. The reference libraries support one key per link, which the page calls a library choice and not a protocol limit.
A short checklist
- Generate the key randomly, and load it over USB or a wired link.
- Keep it out of config files, parameter dumps and chat messages.
- Decide which unsigned messages you accept, and write the list down.
- Test a spoofed command from an unsigned source on the bench.
- Plan how to rotate the key for a fleet.
Quick check
Does MAVLink signing encrypt telemetry?
No. The guide describes authentication of messages with a signature, and does not describe encryption.
Can a system still accept unsigned packets after signing is on?
Yes. Libraries should allow conditional acceptance based on rules such as a parameter, a secure transport or a message type.
Sources
- MAVLink guide, Message Signing: packet format, key handling, timestamps, unsigned packet rules.
Last reviewed: 19 October 2026.
