Encryption and Privacy

PKC Direct Messaging (v2.5+)
Meshtastic v2.5 introduced Public Key Cryptography (PKC) encrypted direct messages - a significant security upgrade that makes DMs genuinely end-to-end encrypted rather than just channel-scoped. 

 Note on terminology: This feature is officially called "PKC Direct Messages" or "encrypted direct messages" in Meshtastic documentation. It was introduced in firmware v2.5 , not v2.5 as some sources incorrectly state. 

 Before v2.5: How DMs Worked 
 Prior to v2.5, "direct messages" in Meshtastic were standard channel messages with a to field set to the recipient's node ID. Anyone on the same channel with the channel key could decrypt and read all DMs. There was no per-recipient encryption. 

 v2.5+: PKC Encrypted Direct Messages 
 From v2.5 onward, direct messages use per-node asymmetric encryption: 
 
 Key exchange: X25519 ECDH - each node has an X25519 public/private key pair 
 Encryption: AES-CCM - using the derived shared secret as the key 
 Only the intended recipient can decrypt the message - the channel key is not used 
 Node public keys are distributed automatically via NodeInfo packets 
 

 Backward Compatibility 
 If you send a PKC-encrypted DM to a node running firmware 2.4.3 or older, Meshtastic automatically falls back to the legacy channel-based method. The sender's app indicates which method is being used. 

 Requirements 
 
 Both sender and recipient must be running Meshtastic firmware v2.5 or later 
 Both nodes must have exchanged NodeInfo packets (public keys are included automatically) 
 Compatible with Android, iOS, and Python CLI clients that support v2.5+ 
 

 Source: meshtastic.org/docs/overview/encryption/ and meshtastic.org/blog/introducing-new-public-key-cryptography-in-v2_5/. Verified 2026-05-03.

Meshtastic Managed Mode and Admin Channels
For deployed infrastructure nodes - community repeaters, fixed gateways - you want to prevent unauthorized configuration changes while still being able to administer the node remotely. Meshtastic provides two tools for this: Managed Mode and Admin Channels. 

 Managed Mode 
 When Managed Mode is enabled, the node ignores configuration packets from the local Bluetooth connection unless they come from an authorized admin. This prevents anyone who walks up to the repeater and pairs their phone from changing the configuration. 
 meshtastic --set device.role MANAGED 
 With Managed Mode active: 
 
 Local BLE configuration is blocked (requires admin channel for config changes) 
 USB serial connection can still configure the device (physical access = admin) 
 The node continues to route and relay normally 
 

 Admin Channel 
 The Admin Channel is an encrypted control channel that allows authorized administrators to configure any node in the mesh remotely - even nodes that are out of direct radio range (configuration packets are relayed through the mesh). 

 Setting Up an Admin Channel 
 
 Create a channel with a random PSK and name it "admin" (or any name you choose) 
 Add this channel to all nodes you want to manage 
 Only administrators should have the admin channel PSK 
 
 meshtastic --ch-set name "admin" --ch-index 1
meshtastic --ch-set psk random --ch-index 1 

 Remote Configuration via Admin Channel 
 Once an admin channel is configured, you can send configuration commands to remote nodes via the app's remote admin feature. The command is encrypted with the admin channel PSK, relayed through the mesh, and executed on the target node. The target node responds with its updated configuration. 

 Security Considerations 
 
 The admin channel PSK is the master key for your infrastructure - guard it carefully 
 Distribute admin channel credentials only to trusted operators 
 Consider a separate admin channel per node, or per geographic cluster, to limit blast radius if a key is compromised 
 USB serial access always overrides Managed Mode - physical access to the hardware is always root access