Is Meshtastic Encrypted? Privacy and Tracking Explained

Yes, Meshtastic encrypts the payload of every packet it sends over LoRa: channel messages with AES using the channel’s key, and direct messages (since firmware 2.5) with a key only the sender and recipient can compute. But encryption is only part of privacy. The routing header is sent in the clear, the default channel’s key is public, your position can be shared automatically, and MQTT can carry mesh traffic to the internet.

This guide explains what’s protected and what isn’t, based on the official Meshtastic Encryption docs and related pages. It is not a security audit, and LoRa Mesh Atlas is not affiliated with Meshtastic.

What is encrypted

Channel messages: AES with a pre-shared key

Each channel has a pre-shared key (PSK). Meshtastic encrypts channel messages with AES-CTR; a 16-byte key gives AES-128 and a 32-byte key gives AES-256 (Encryption docs, Channel config). Anyone with the key can read every message on the channel.

The default channel is effectively public. It uses the published key AQ==. In the docs’ words: “Anything sent on a channel with the default key can be read by anyone.” To keep a channel private, set a new key and share it only with the people you want on it.

On firmware 2.8.1 and later (an alpha release as of October 2026), a channel can switch to AES-CCM with a “Use AEAD” option, which lets nodes reject altered or forged packets. Every node on the channel must enable it, and the docs describe it as experimental.

Direct messages: public-key encryption since 2.5

Before version 2.5, direct messages used the channel key, which meant anyone on the same channel could read them, as the v2.5 blog post acknowledges. Since 2.5, each node has its own key pair. The sender combines its private key with the recipient’s public key (X25519) to derive a shared key, which encrypts the message with AES-256-CCM. Only the two nodes can read it, and the recipient knows who sent it (Encryption docs).

Caveats from the docs:

• A node won’t send a direct message to a node whose public key it doesn’t have.
• Traceroute, NodeInfo, position, and acknowledgment packets normally use the channel key even when addressed to one node.
• Keys use trust on first use. Your node trusts the first public key it hears for a node number, because there’s no central authority. A red key icon in the apps means a node’s key has changed (Known Limitations).
• “Before sending anything sensitive in a direct message, confirm the recipient’s public key with them some other way.”

Signed broadcasts (firmware 2.8, alpha as of October 2026)

Nodes on firmware 2.8 and later sign broadcasts so others can verify the sender. The default policy still accepts unsigned packets so older nodes keep working; stricter BALANCED and STRICT policies are available (Security config). As of October 2026, the project described 2.8.1 as an alpha (2.8 announcement).

What is not encrypted

The packet header

Every packet starts with a 16-byte header sent in the clear so nodes can relay packets they can’t decrypt. Per the Overview and Mesh Broadcast Algorithm, it contains:

• destination and sender node numbers,
• a packet ID,
• hop limit and original hop count,
• a flag showing whether the packet came via MQTT,
• a one-byte channel hash, and
• next-hop and relay-node bytes.

So even someone without your key can see which node sent a packet, who it’s addressed to (or that it’s a broadcast), roughly how many hops it has traveled, and when it was transmitted.

Data passed to your app

Your node decrypts packets before handing them to a connected client over Bluetooth, serial, Wi-Fi, or Ethernet. Anyone with access to your unlocked phone or paired client can read them.

Licensed (ham) mode

In licensed mode, everything is sent unencrypted, as amateur radio rules prohibit encryption. See Meshtastic legal in the USA.

Can Meshtastic be tracked?

There are several distinct ways your location or activity could be exposed.

1. Position sharing on channels

Position sharing is controlled per channel with position precision, a value from 0 to 32 bits (Channel config):

• 0 means location is never sent on that channel.
• 32 is full precision.
• In between, fewer bits mean a coarser location. For example, 13 bits is about 2.9 km (1.8 mi), 15 bits about 729 m, and 19 bits about 45 m.
• On a channel with a public key (no key, the default key, or any single-byte key), the firmware caps precision at 15 bits.

The tips page warns that if your node has GPS coordinates (from a built-in GPS or your phone), and you leave the default channel unchanged, “your location will be shared with all nodes in range that are also using the default channel.” With firmware 2.7.1 and later, you can turn location off on the primary channel and share it only on a private secondary channel.

Behavior changed in 2.8: the current Mesh Broadcast Algorithm page says position is off by default and shared only on channels with precision above 0, and the 2.8 announcement says precise position isn’t sent on public channels. If you run older firmware, check your settings rather than assuming.

2. Map reports and MQTT

If you (or a node near you) bridge to MQTT, mesh traffic can reach the internet. The optional map report feature publishes, unencrypted, your node’s names and ID, position (at configurable precision), hardware model, role, firmware version, region, preset, and primary channel name (MQTT module). The tips page adds that connecting a node to the public MQTT server “may publish the locations of all nodes in your mesh to the internet.”

The project’s public server applies some protections on the default key: it passes only imprecise positions (10–16 bits of precision) and doesn’t let packets propagate past directly connected nodes (MQTT integrations). The “OK to MQTT” setting asks other gateways not to upload your packets, but the docs stress it “is not a cryptographic solution but a polite request.” See our Meshtastic MQTT guide.

3. Radio direction finding

Any transmitter can be located by someone with the right equipment, and encryption doesn’t hide that a radio is transmitting. The Meshtastic FAQ notes that a community project has worked out how to locate a device via triangulation. The CLIENT_HIDDEN role reduces broadcasts to those needed, but no setting makes a transmitting radio invisible.

How private is Meshtastic, really?

The official docs answer directly: “Is it as secure as Wi-Fi WPA3, HTTPS TLS 1.3, or Signal? No.” They list three gaps (Encryption docs):

Property	Meshtastic status per the docs
Forward secrecy	Not provided. Recorded traffic can be decrypted later if the key leaks (“harvest now, decrypt later”).
Integrity	AES-CTR channels can be tampered with by someone who guesses message content; AES-CCM channels, signed broadcasts, direct messages, and admin messages detect this.
Authentication	Anyone with a channel key can send an unsigned packet claiming to be any node; treat the sender of an unsigned channel message “as a claim, not a proof.”

The docs also note that AES-256 is considered resistant to quantum attack, but the X25519 key exchange is not.

Practical privacy checklist

Drawn from the official recommendations:

• Use a custom key for any channel you want private, and share it only with intended members.
• Keep private groups on secondary channels, not by renaming the primary channel (which moves your frequency; see presets and frequency slots).
• Don’t put private channel keys on unattended nodes. “Physical access to a node makes the key easy to extract,” and relays don’t need the key anyway.
• Rotate channel keys from time to time.
• Set position precision deliberately on each channel, or set it to 0.
• Leave map reporting off unless you want your approximate location published.
• Verify public keys out of band before sensitive direct messages.
• Back up your keys before reflashing, since a new key means a new identity (flashing guide).
• Remote admin uses the same encryption as direct messages and is accepted only from up to three configured admin keys; the legacy admin channel is less secure and off unless enabled (Security config).

Meshtastic gives you reasonable tools to keep message content among a trusted group. It isn’t designed to hide that you’re transmitting, and it’s not a replacement for an end-to-end encrypted messenger with forward secrecy.