No. MAVLink 2 signing does not encrypt drone data. It lets a receiver check a message against a shared secret and detect changes, while signing timestamps support replay protection. The payload remains readable wherever no separate encryption protects it. Confidentiality therefore needs another control, such as an encrypted transport covering the exposed part of the connection. The MAVLink signing specification makes this distinction explicit.
For an integrator, “signing enabled” answers only part of the security question. You also need to know which incoming messages are accepted without verification, where encryption starts and ends, and which computers hold signing authority.
On This Page
- What authentication, integrity, and replay protection mean
- Match each threat to a control
- Draw where encryption stops
- Unsigned-message policy differs between implementations
- Build an acceptance record that separates the controls
- Verify the complete connection before deployment
What authentication, integrity, and replay protection mean
Message authentication establishes that a message was produced by a holder of the shared signing secret. Integrity lets the receiver detect modification of the protected packet. Neither property conceals the content. A valid signature establishes possession of that secret; it does not distinguish individual operators among devices sharing it.
MAVLink 2 adds a 13-byte signing block: a one-byte link ID, a six-byte timestamp, and a six-byte signature derived using SHA-256. The shared secret is 32 bytes. These sizes describe the protocol format, not an encryption strength rating.
Replay protection concerns a previously valid message arriving again. The mavgen C signing documentation describes timestamp tracking for each combination of system, component, and link identity. It requires shared signing-stream state across channels and makes persistent timestamp storage an integrator responsibility.
That matters during reboot and redundant-link operation. A system must preserve the state needed to distinguish old traffic, and independent sending links need appropriate identities. Reusing an identity across independent ground-station instances can cause legitimate packets to be rejected when their timestamps conflict.
The signing timestamp is also not an application deadline. Specify separately how old a command or observation may be when used. A message can be authentic without being appropriate to the vehicle's current mission or state.
Match each threat to a control
The following table is an engineering synthesis of the MAVLink mechanism, the PX4 hardening guidance, and the IETF IPsec architecture. Controls are complementary; no row certifies a complete aircraft installation.
| Concern | Control to specify | Remaining boundary |
|---|---|---|
| Unauthorized or modified commands | Enforced signature verification and restricted unsigned acceptance | A trusted key holder still needs appropriate application authority. |
| Repeated old messages | Replay-state handling, persistent timestamps, and correct link identities | Application expiry and mission-state checks remain separate. |
| Someone reading telemetry or missions | Encryption covering every exposed segment | Plaintext still exists at encryption endpoints. |
| Compromised ground or onboard computer | Restricted access, protected secrets, maintained software, and physical protection | A valid signature cannot establish that its originating computer is uncompromised. |
| Link interruption or resource exhaustion | Network isolation and a defined lost-link response | Authentication does not guarantee communication availability. |
For example, protecting command acceptance while leaving mission coordinates observable satisfies a different requirement from protecting both. Write those requirements separately so an integration demonstration cannot substitute one for the other.
Draw where encryption stops
IPsec supplies security at the IP layer and can operate in hosts or security gateways. Its architecture includes confidentiality, authentication, and integrity services, with the actual protection determined by configuration. Specify an authenticated, encrypted configuration rather than assuming any tunnel supplies confidentiality. It is one possible transport design for IP-carried MAVLink, not a feature automatically enabled by selecting MAVLink 2.
Consider this illustrative layout. Arrows represent a bidirectional connection; the diagram is a design example, not a tested product configuration.
[A: Ground control application]
Signing/verifying endpoint; plaintext in memory
down / up
Signed MAVLink, still readable
down / up
[B: Ground encryption gateway]
down / up
ENCRYPTED IP TRANSPORT OVER EXPOSED NETWORK
down / up
[C: Onboard encryption gateway / companion computer]
down / up
Signed MAVLink, readable again
down / up
[D: Flight controller]
Signing/verifying endpoint; command checks
Signing boundary: A <----------------------> D
Encryption boundary: B <-------------------> C
Endpoint protection required: A, B, C, and D
The diagram assumes the gateways forward signed MAVLink packets unchanged. A gateway that creates replacement messages and signs them becomes a new signing endpoint.
In this arrangement, encryption protects B-to-C traffic. The A-to-B and C-to-D segments need their own protection or a justified trusted physical boundary. Moving the encrypted connection's endpoints changes that coverage. A serial radio path cannot be assumed to inherit an IP tunnel's protection unless the architecture actually carries that traffic through the tunnel.
A companion computer that terminates encryption can see the recovered traffic. If it also originates signed commands, it holds signing authority and needs corresponding access controls. Treat its exposed services and interfaces as part of the aircraft system.
Trace the operator, computer, radio, and payload paths in the same drawing. Include separate video or payload streams; the MAVLink label alone says nothing about their encryption.
Unsigned-message policy differs between implementations
MAVLink signing support does not prescribe one universal receive policy. The C library provides a callback through which applications can accept unsigned or incorrectly signed packets. Integration work therefore includes reviewing that callback's policy, not merely setting the outgoing-signing flag.
PX4: all-link enforcement with an allowlist
The current PX4 main signing guide says a provisioned SD-card key activates signing on all links, including USB. Without a key, signing is inactive. With signing active, the documented unsigned allowlist includes HEARTBEAT, RADIO_STATUS, ADSB_VEHICLE, and COLLISION.
Those exceptions mean that an accepted message is not necessarily authenticated. Software consuming allowlisted data must account for its trust level.
PX4 documents rejection of signing-configuration changes while armed and requires existing-key authentication for remote changes once signing is active. Its guide also notes that abrupt power removal can leave the stored timestamp at the last provisioning value, whereas graceful shutdown persists the current value. Include power-cycle behavior in verification of the actual firmware.
These statements describe the main documentation checked on September 9, 2026. Check the installed release and vendor modifications before applying them.
ArduPilot: check the serial protocol and USB distinction
The current ArduPilot Copter signing guide describes signing for MAVLink 2 serial links while leaving USB access unaffected. It requires the telemetry serial protocol to use option 2, MAVLink2; a MAVLink 1 port is not protected by signing.
The documented Mission Planner workflow uses its MAVLink Signing panel to provision signing and its connection statistics to check the link. Telemetry can still arrive when the ground station lacks the active key, even though signed command requests are required on the protected serial link.
Thus a moving map or live telemetry display does not prove command authorization, encrypted telemetry, or the USB policy described for PX4. Verify each property separately on the chosen stack.
For mixed components, define an agreed implementation scope: the messages, software versions, receive policies, and security settings that must work together.
Build an acceptance record that separates the controls
An integration team can turn the connection diagram into an acceptance matrix instead of recording a single signing checkbox. The following method is an engineering interpretation of the MAVLink receive-policy specification and PX4's production hardening guidance. It describes proposed checks, not experiments performed for this article.
Start with one command path in a disarmed bench installation or simulation. Name its sender, every forwarding component, the receiving interface, and the application expected to act on it. Record whether each intermediate computer merely forwards a packet or produces a replacement. This prevents a valid signature at the final receiver from being mistaken for evidence about a different upstream sender.
| Property under examination | Evidence to retain | Conclusion the evidence does not establish |
|---|---|---|
| Authorized command acceptance | The configured receiver accepts the intended signed command on the named interface. | Other interfaces enforce the same policy. |
| Rejection policy | A controlled negative case is rejected for the intended reason, with the exception policy recorded. | Every accepted telemetry message is authenticated. |
| Confidentiality coverage | The documented encrypted segment covers the exposed path and its endpoints are identified. | Logs, maintenance interfaces, and separate payload streams have equivalent protection. |
| Lifecycle consistency | The same acceptance criteria are checked after the specified restart or link change. | An untested firmware or gateway replacement behaves identically. |
Keep the expected result separate from the observed result. If an unauthenticated command is accepted, first determine whether an explicit exception applies, the message arrived on a different interface, or the receiver policy was configured differently than expected. Do not turn an unexplained acceptance into a passing result merely because another command was rejected. Equally, a rejected command is not proof of signing enforcement unless the rejection reason distinguishes authentication from an unrelated application or vehicle-state restriction.
For confidentiality, identify the observation point in the record. Traffic readable inside a deliberately trusted encryption endpoint is a different finding from plaintext on a segment that the design says must be encrypted. That distinction helps locate the missing control without claiming that signing itself has failed.
Finally, preserve configuration references and software versions with the result, while keeping actual signing secrets out of screenshots and reports. The C signing guide assigns receive-policy and timestamp-state responsibilities to the integration. Revisit the relevant matrix rows when those responsibilities move between a ground station, companion computer, or flight controller. A narrowly stated, repeatable result is more useful than an unqualified claim that the whole vehicle is secure.
Verify the complete connection before deployment
Use the following as proposed integration checks, performed in simulation or a disarmed, controlled bench setup. They are not reported test results.
- Record the exact combination. Identify firmware and ground-station versions, companion software, every active interface, and which components originate or verify signed messages.
- Establish the receive policy. Confirm acceptance of authorized traffic, rejection of unauthorized command traffic, and the documented treatment of exceptions. Check each link and direction, including maintenance connections.
- Exercise lifecycle behavior. Verify reconnects, multiple ground stations, redundant links, and power cycles. Record signing-state and timestamp behavior without exposing secrets. Check command age and mission validity separately from signature acceptance.
- Verify confidentiality independently. Establish where encryption terminates, which traffic enters it, and whether any telemetry, payload, logging, or backup path leaves the protected boundary.
- Protect provisioning and endpoints. Use trusted provisioning connections, restrict network exposure, and protect key storage and physical access. PX4's hardening guide specifically calls for segmentation, firewalls or VPNs, and review of companion-computer bindings.
- Define loss of communication. Confirm the vehicle's configured response when authenticated communication becomes unavailable. The failsafe design guide explains how to connect a detected failure to a deliberate response.
A useful handover record names the messages that must authenticate, the exceptions that remain, the segments that encrypt, and the components responsible for each control. That gives an operator or maintainer something concrete to verify after a firmware, radio, or ground-station change.
Sources
- MAVLink: Message Signing. Protocol documentation for authentication, packet signing, and key management.
- MAVLink: C Message Signing. Implementation documentation for receive policy, timestamps, and link identity.
- PX4: MAVLink Message Signing. Main-branch documentation for activation, exceptions, and persistence.
- ArduPilot: MAVLink2 Signing. Copter documentation for serial-port configuration, Mission Planner, and USB behavior.
- PX4: MAVLink Security Hardening. Official guidance on network exposure, provisioning, and physical access.
- IETF RFC 4301: Security Architecture for IP. Standards-track architecture for IP-layer security and its endpoint boundaries.
Last checked: September 9, 2026.
