You have set up two or three Meshtastic devices, the first messages are coming through, and now someone in your group asks the obvious question: can anyone else read this? The honest answer about Meshtastic encryption is that your message content is protected with AES-256, but out of the box it uses a key the whole world knows. Your traffic only becomes private once you create your own channel with a random key, distribute that key carefully and make deliberate choices about MQTT and remote administration.
Since firmware 2.5, direct messages between two nodes also use public key cryptography, which makes them better protected than group channels. Even so, the system has limits worth knowing before you trust it with anything sensitive: there is no perfect forward secrecy, channel messages are not checked for tampering, and the header of every packet stays readable.
Is Meshtastic encrypted by default?
Technically yes, practically no. Every new Meshtastic device starts with a primary channel that encrypts the payload of each packet with AES-256 in CTR mode. The key for that default channel, however, is a publicly documented one-byte value that apps usually display as “AQ==”. It ships in the firmware source code, so anyone with a Meshtastic device on factory settings can read everything sent on that channel. On the default channel, encryption only keeps a generic LoRa receiver without Meshtastic software from seeing the text in the clear.
Two more points apply no matter which key you use. First, the packet header is never encrypted, because nodes need it to relay packets they are not able to decrypt themselves. Anyone listening can see the sender and destination node IDs, the packet number and routing details such as the hop limit, even when the content is protected. Second, the device decrypts messages before passing them to your app over Bluetooth, USB or Wi-Fi. An unlocked phone paired with your node reveals just as much as the key itself.
The default setting is not a bug but a design choice: it lets strangers’ devices find each other in a public mesh and relay each other’s packets without any coordination. For a group that wants to keep its conversations to itself, though, it is the wrong place to talk.
How to create a Meshtastic private channel
A Meshtastic device has eight channel slots, numbered 0 to 7. Slot 0 is the primary channel, which the device also uses for its periodic telemetry and device info broadcasts, while slots 1 to 7 are secondary channels. Active channels have to sit next to each other without gaps. For a private group, add a new channel in the app, give it a short name (under 12 bytes) and let the app generate a random key. The “random” option creates a 256-bit key, which gives you real AES-256. The only other allowed key sizes are empty (no encryption), 16 bytes for AES-128 or 32 bytes for AES-256.
Stay away from the so-called simple keys, “simple0” through “simple254”. Each is a single byte stored in the source code, which makes them just as public as the default key. A channel using one of them looks private in the app but is not.
A common pitfall sits at the radio level. All channels on a device share the same modem preset, and the name of the primary channel is hashed to pick the frequency slot. Rename the primary channel and your devices may end up on a different frequency from the rest of the local mesh unless you set the slot explicitly. For most groups, the simpler approach is to leave the public channel as primary and add the private channel as a secondary one. Your node stays part of the wider network and keeps relaying, while your group messages use their own key.
For two devices to talk on a private channel, the name and the PSK have to match exactly. Test this with two devices side by side before you hand the configuration to everyone, and check in the app that the private channel is easy to tell apart from the public one.
Meshtastic channel key: how do you share the PSK safely?
The Meshtastic apps share channels as a QR code or a link. Both are convenient, and that convenience is exactly the risk: the QR code contains the channel name and the full PSK. Anyone with a photo of it is a member of your group. Treat it like a password, not like a setup picture.
The safest method is scanning the QR code straight from one screen to another when you meet in person. If the key has to travel remotely, use a messenger with its own end-to-end encryption and delete the message afterward. Typical leaks are surprisingly mundane: a screenshot of the channel settings in a forum post, a setup photo in a club group chat, an exported configuration file in a shared cloud folder. If you need help troubleshooting, black out the key before you upload anything.
Pay attention to what exactly you are sharing, too. Many apps can export either a single channel or the device’s entire channel set as one QR code. Your hiking group does not need the key to your family channel.
Finally, keep a short private list of which people and which devices received the key. That list is what lets you respond later when a device goes missing or someone leaves the group.
Are Meshtastic direct messages end-to-end encrypted?
Since firmware 2.5, yes, with caveats. Every node generates its own key pair made up of a public and a private key. A direct message is encrypted with the recipient’s public key and signed with the sender’s private key. This public key cryptography adds two things group channels lack: only the recipient can read the message, even if others share the same channel, and integrity is checked, so a message altered in transit is detected.
Before version 2.5, a direct message was simply a channel message with a recipient field, readable by anyone holding the channel key. That still applies today whenever one of the two nodes runs firmware 2.4.3 or older: the direct message is then not protected. Make sure every device in your group is on current firmware.
The second caveat concerns identity. Public keys are distributed over the mesh, and a familiar display name does not prove that the right person is on the other end. When it matters, compare the public key once in person or through another trusted route. Direct messages also still reveal which node talks to which and when, because the packet header is unencrypted. And unlike the AES-256 part, the key exchange is not considered quantum-resistant.
Meshtastic MQTT: can your messages end up on the internet?
Yes, and through devices that do not have to belong to you. A node with a Wi-Fi or phone connection can act as a gateway and forward packets to an MQTT server, such as the project’s public server. Whether a channel is forwarded is controlled by the “uplink” and “downlink” options, which are set per channel and are off by default. With uplink on, packets from that channel leave the radio network.
The “encryption enabled” setting in the MQTT module matters more than most people realize. It is off by default, and according to the documentation all messages are then sent to the broker unencrypted, even if the channel has its own key. JSON output is always unencrypted. So if you turn on MQTT for a home automation setup or a dashboard, know exactly who has access to that broker. The same goes for map reporting: when it is enabled, the node sends an unencrypted report every hour with its name, hardware, firmware, region and the name of the primary channel.
Channels using the default key have an “OK to MQTT” option. When it is off, your packets ask other gateways not to forward them to the internet. Official firmware honors that request, but it is not a cryptographic barrier. Channels with a custom key ignore the option; what protects you there is mainly that other people’s gateways can only upload your packets in encrypted form without your PSK. “Ignore MQTT” additionally keeps your device from showing messages that passed through MQTT somewhere along the way.
What can others see on the public Meshtastic LongFast channel?
LongFast is the default modem preset, and the factory primary channel usually shows up in the apps under that name. Because its key is public, everyone within radio range can see what happens there, and so can anyone reading along when a gateway forwards the channel to the internet. That includes text messages, your node’s short and long names, its hardware model and the telemetry the device sends regularly over the primary channel, such as battery level and uptime.
That leads to a simple rule of thumb: only post in LongFast what you would pin to a public bulletin board. Pick a node name that does not give away your full name or address. Whether and how precisely your device sends position data on a channel is configured per channel, which is a separate topic with its own pitfalls.
The public channel still has its uses. It shows you which nodes are reachable nearby, and your device helps the local network by relaying traffic. Many groups use it for testing and move anything personal to a secondary channel with its own PSK.
Meshtastic admin key: how do you secure remote administration?
By default, a Meshtastic node only accepts admin commands over a direct USB, Bluetooth or network connection. For devices mounted on a roof or mast, firmware 2.5 introduced remote administration over the air. You add the public key of your controlling device as an admin key in the remote node’s security settings. Each node can store up to three admin keys, although the web client currently accepts only one. Admin messages between devices on 2.5 or newer use stronger encryption and session IDs, and are protected against replay of captured commands.
Older firmware handled this through a secondary channel named “admin”. Any node holding its key could manage all the others. You can still enable this legacy admin channel on new firmware, but it is off by default and only meant for managing old devices. Leave it off unless you really need it.
There is also “managed mode”. With it enabled, apps can only read the configuration, and changes go exclusively through remote administration. That protects an unattended device from someone changing its settings over Bluetooth on site. Make sure remote administration works before you turn managed mode on, or you will lock yourself out. Note that there is no command to remove a single admin key; you can only clear the whole list and fill it again.
Meshtastic channel key leaked: what should you do?
A device is gone, a screenshot went public, or someone left the group on bad terms. In all three cases the old key is burned. Generate a new random PSK, distribute it to the remaining members and confirm with a test message that everyone has switched. Removing a node from your node list does not delete the key from that other device.
The uncomfortable truth behind this: Meshtastic offers no perfect forward secrecy. Anyone who recorded your radio traffic and later obtains the old key can decrypt the old messages too. Changing the key only protects what you send from now on. On top of that, anyone with the channel key can send messages under someone else’s node ID, because channel messages are not authenticated. After a leak, be suspicious of instructions that arrived only through the group channel.
Three habits, all recommended in the project documentation, help prevent the worst case. Rotate channel keys regularly. Do not put private channels on unattended nodes such as rooftop relays, since they forward packets without needing to decrypt them anyway. And always assume that anyone who gets hold of the key at some point can read the channel traffic that came before.
Where can you buy Meshtastic devices?
For a secure group, the form factor matters less than how well you can manage the device. Make sure it supports current firmware from version 2.5 onward, since that is what brings protected direct messages, admin keys and secured remote administration. Think about how you will set up channels: a screenless device such as the WisMesh Tag LW010-R is configured entirely through the app, which makes sharing by QR code easy but assumes a well-protected phone. Decide whether a node will run unattended. If so, it should carry no private channel, but it should have an admin key and possibly managed mode. And before first use, check whether MQTT, uplink or map reporting are active, so your group’s Meshtastic encryption does not end at someone’s gateway. If you are looking for a suitable device, you can find our models in the Meshtastic category.
Meshtastic Encryption FAQ
What encryption does Meshtastic use?
Channel messages are encrypted with AES-256 in CTR mode, or AES-128 if you set a 16-byte key. From firmware 2.5 on, direct messages and admin commands also use public key cryptography with one key pair per node. In both cases, the packet header stays unencrypted.
Can Meshtastic messages be intercepted?
Anyone with a Meshtastic device can read the public default channel, because its key is known. A private channel with a random 256-bit key cannot be decrypted without the PSK, although outsiders can still see which nodes transmit and when. Someone who records the traffic and later obtains the key can read the old messages after the fact.
Is Meshtastic secure enough for confidential communication?
For group coordination, meeting points or status updates, a private channel with a strong key is good enough. Meshtastic is not meant for credentials, business secrets or anything that must never come out later: it lacks forward secrecy and authentication of channel messages. The project itself states that it does not reach the security level of Signal or TLS 1.3.