Meshtastic Explained: LoRa Mesh, Channels, Encryption and MQTT

Meshtastic is an open source firmware and app ecosystem that turns small LoRa radios into an off grid text messaging mesh: every node relays packets for its neighbours, so there are no gateways, no network server and no phone signal involved. Channel traffic is encrypted with a shared AES key, direct messages use per node public keys, and an optional MQTT bridge can link a mesh to the internet. Securing a node mostly means replacing the published default key, limiting what your position reveals, and deciding deliberately whether anything leaves the radio link.

Below we go one level deeper: the radio trade offs, how packets are routed, exactly what each key protects, what an MQTT uplink exposes, what regulators allow, and a hardening walkthrough with the official CLI. Facts come from the project's firmware 2.8 documentation, its security policy and GitHub repository, and the regulatory texts, checked on 25 October 2026.

Key takeaways

• Meshtastic is not LoRaWAN. LoRaWAN routes sensors through gateways to a network server. Meshtastic is a peer to peer flooding mesh that needs no infrastructure.
• The default channel key is public. It is the single byte 0x01, shown as AQ==, and it ships in the source code.
• Headers are never encrypted. Sender, destination, packet ID and hop counts travel in the clear so nodes can relay what they cannot read.
• Direct messages use real public key crypto since firmware 2.5: X25519 key agreement with AES-CCM.
• Firmware 2.8 adds broadcast signing and 2.8.1 adds optional authenticated channels. Both default to compatibility.
• There is no forward secrecy. Recorded traffic can be decrypted by anyone who later gets the key.
• MQTT uplinks are plaintext by default, even from channels with private keys.
• A node will not transmit until its region is set, and the firmware enforces per region power and duty cycle ceilings.

What is Meshtastic, and how is it different from LoRaWAN?

Meshtastic is a community open source project. Its firmware repository on GitHub, created on 1 February 2020 and licensed under GPL-3.0, describes it as "an open-source, off-grid mesh communication system." The project also maintains Android and Apple apps, a web client, a Python library and CLI, and the protobuf definitions they share.

A node is a microcontroller board with a LoRa radio, an antenna and usually a battery. You pair a phone or computer to it over Bluetooth, USB serial, Wi-Fi or Ethernet, type a message, and the node transmits it. Nodes in range with the same radio settings hear it and, depending on their role, rebroadcast it further. The radio settings page states plainly that Meshtastic is not LoRaWAN and uses the full LoRa frequency range of each region.

The LoRa Alliance describes LoRaWAN as a low power, wide area specification for connecting battery operated things to the internet, built from end devices, gateways, network servers and application servers. Devices never relay for each other, and each device has root keys provisioned before it joins. We covered that model in LoRaWAN explained. Meshtastic shares the modulation and nothing above it: no gateways, no network server, no provisioning, human messaging first, and internet only if you add an MQTT bridge.

What hardware does it run on?

The getting started guide groups boards by microcontroller family: Wi-Fi capable boards, low power Bluetooth only boards that update through a UF2 bootloader, and small single chip radio microcontrollers with little flash. The project separates officially supported hardware, which it tests with its partners, from community supported boards. A native Linux build also runs on single board computers with a LoRa add on.

The family affects security. Only boards with Wi-Fi or Ethernet can uplink to MQTT directly; others use the phone app's client proxy. The smallest single chip builds drop features to fit, and the encryption docs note they neither sign packets nor check signatures. Check your exact board's page before assuming a feature exists.

How does LoRa modulation work?

LoRa uses chirp spread spectrum. The transmitter sweeps its frequency linearly across the channel bandwidth; each sweep is a chirp, and data is encoded in where the chirp starts. A receiver that knows the sweep rate can correlate against it and recover signals below the noise floor, which is how LoRa reaches kilometres on milliwatts. Three settings trade range against speed, and the project's radio settings page explains each.

Spreading factor (SF). Chirps per symbol equal 2 to the power SF, so SF7 uses 128 and SF12 uses 4,096. Each step up doubles airtime and adds about 2.5 dB of link budget. Newer radio chips support SF5 and SF6; older ones stop at SF7.

Bandwidth. Each doubling costs almost 3 dB of link budget but halves the symbol time. Very narrow bandwidths need a temperature compensated crystal oscillator.

Coding rate. Error correction overhead: 4/5 adds 1.25 times the airtime, 4/8 doubles it.

Worked example: symbol time

Symbol time is chirps per symbol divided by bandwidth.

• Long Fast (SF11, 250 kHz): 2,048 divided by 250,000 per second is 8.192 ms per symbol.
• Short Fast (SF7, 250 kHz): 128 divided by 250,000 is 0.512 ms per symbol.

Same bandwidth, sixteen times the symbol time, which matches the project's data rates of 1.07 kbps against 10.94 kbps. On a busy mesh a slow preset is not just slow for you; every message holds the shared channel sixteen times longer.

Worked example: link budget

The preset table assumes 22 dBm transmit power and 0 dBi antennas, and lists Long Fast at 153 dB. So the receiver must detect about 22 minus 153, or minus 131 dBm. A 3 dBi antenna at each end adds 6 dB, roughly doubling free space range. Height usually beats any setting change.

What do the modem presets trade off?

Nodes only hear each other on the same preset, so a local mesh standardises on one. The default is Long Fast. Figures from the project's radio settings page:

Narrowband Lite, Narrow and Tiny families serve bands where these are not permitted, including amateur allocations. The 500 kHz Turbo presets are not legal everywhere and are not offered in the 869.4 to 869.65 MHz European sub band. One trap: a US node whose region is first set from its own screen starts on Long Turbo, which cannot hear Long Fast. If you see no nodes, check the preset first.

Airtime, not range, is the real limit of a busy mesh, and the firmware admits it. Above 40 nodes seen in two hours, it stretches position and telemetry intervals by 2^SF divided by (bandwidth in kHz x 100) for each extra node. On Long Fast that is 0.08192 per node, so a 62 node mesh stretches a one hour interval to about 168 minutes.

How does Meshtastic routing work?

The mesh broadcast algorithm page describes four layers. Most of the protocol's security properties fall out of them.

The radio packet

Each packet starts with a preamble and a LoRa header whose sync word, 0x2B, separates Meshtastic from other LoRa traffic. Then comes a 16 byte Meshtastic header sent as raw bytes:

The security policy explains why: firmware runs on constrained microcontrollers "within a 256 byte LoRa packet limit." A clear header lets any node relay any packet. The cost is metadata. A listener learns who talks to whom, how often and how many hops apart.

Before transmitting, a node checks for channel activity and backs off a random number of slots if the channel is busy, much like Wi-Fi.

Acknowledgments

A sender wanting confirmation of a broadcast listens for any node rebroadcasting it and treats that as an implicit ack. The docs note this counts "whether or not it has the same encryption key", so it proves only that the packet left your radio. Reliable broadcasts are sent at most three times, direct messages at most five.

Managed flooding and next hop routing

Most traffic is flooded. A node hearing a packet with hop limit above zero decrements it and considers rebroadcasting, but first listens briefly and stays quiet if someone else rebroadcasts. Nodes that heard the packet weakly, and are probably further out, get shorter waits, so the message pushes outward. The hop limit defaults to 3 and cannot exceed 7; the docs say "Really, 3 is fine."

Since firmware 2.6, direct messages start by flooding, then nodes remember which neighbour relayed a successful exchange and use it as the next hop. A node falls back to flooding on its last retry if the next hop goes quiet.

Device roles

Current role names in the 2.8 docs:

ROUTER_CLIENT was deprecated in firmware 2.3.15. A separate Rebroadcast Mode limits what a node relays: ALL (default, including other meshes with different keys), LOCAL_ONLY (its own channels), KNOWN_ONLY (nodes already in its database), CORE_PORTNUMS_ONLY (text, position, node info, telemetry and routing) and others. For unattended infrastructure, that setting is your main lever on whose traffic you carry.

What a node sends on its own

By default a node broadcasts NodeInfo (names, node ID and public key) every three hours. Telemetry and position are off by default, and position goes only to channels whose position precision is above zero.

How are channels and keys handled?

A node has eight channel slots. Index 0 is PRIMARY; the rest are SECONDARY or DISABLED. Each has a name and a pre shared key (PSK). The primary channel's name also feeds the hash that picks the frequency slot, so renaming it moves you off your local mesh's frequency.

Channel encryption: AES-CTR with a shared key

The encryption overview says channel messages are encrypted with AES-CTR. A 16 byte key gives AES-128, a 32 byte key AES-256. The CLI accepts none, default, simple well known keys and random, which generates a fresh 256 bit key. Of the well known values the channels page says: "anyone can listen to messages encrypted by them."

The most important fact in this article: the default primary channel key is AQ==, a single published byte. It lets strangers talk on a community mesh out of the box and gives no confidentiality against anyone with a Meshtastic radio. The firmware treats any channel with no key, the default key or a single byte key as public, and caps position precision there at 15 bits, about 729 metres.

The project documents three limits of AES-CTR channels openly:

1. No authentication. Anyone holding the key can send a packet claiming to be any node.
2. No integrity. The IV comes from the sender's node number and packet ID. The known limitations page explains that someone who knows a message's exact plaintext could, under narrow conditions, alter or forge one without the key; the project calls this "of limited use."
3. No forward secrecy. Recorded traffic can be decrypted by whoever later gets the key, through careless sharing, a stolen node or a bug.

Authenticated channels: AES-CCM from 2.8.1

On firmware 2.8.1 and later a channel can turn on Use AEAD, switching to AES-CCM with a 12 byte tag so nodes reject packets altered or forged by anyone without the key. It is experimental, off by default, and must be on for every node on the channel, because nodes with and without it cannot read each other. It stops outsiders tampering, not insiders impersonating each other.

Direct messages: X25519 and AES-CCM since 2.5

Direct messages were once just channel messages addressed to one node. The limitations page records that the new system "was rolled out with Meshtastic 2.5." Each node generates a key pair once its region is set. The sender combines its private key with the recipient's public key using X25519 and encrypts with AES-256-CCM, so only the two nodes can read the message and the recipient knows who sent it.

Details that matter:

• Public keys arrive in NodeInfo broadcasts, which travel under the channel key.
• Without the recipient's key, the firmware does not fall back to channel encryption; the send fails.
• Traceroute, NodeInfo, position and acknowledgment packets still normally use the channel key.
• From 2.8.1, an ack can carry a proof made with the shared key, so someone with only the channel key cannot forge delivery.

Node identity and trust on first use

A node's number is a CRC-32 of its public key. There is no certificate authority, so the security policy describes trust on first use: the first key heard for a node number is the one bound to it. The node database holds 120 nodes on most hardware and older entries roll off, so a flood of fake nodes can push a real one out, after which a new claim to its number cannot be checked. Mitigations: favourited nodes never roll off, apps auto favourite anyone you message, most hardware keeps a warm store of rolled off keys, and apps flag key changes with a warning icon. The docs' advice is right: confirm a contact's public key some other way before sending anything sensitive.

Signed broadcasts: XEdDSA in 2.8

Firmware 2.8 signs broadcasts with XEdDSA, producing Ed25519 style signatures from each node's existing X25519 key pair. A signature adds 66 bytes, so oversized broadcasts go unsigned. A node always drops a packet whose signature does not match the sender's known key, and accepts a signed NodeInfo's key only if its CRC matches the claimed node number. The Packet Signature Policy decides what happens to unsigned packets:

Admin and the local trust boundary

Remote administration uses direct message encryption. A node accepts admin messages only from up to three listed admin keys, and each change must carry a session passkey issued within the last five minutes, limiting replay. The legacy admin channel is off by default. Managed Mode blocks client apps from writing configuration and requires at least one admin key.

The security policy draws a boundary every operator should read. Anything connected over Bluetooth, USB serial, Wi-Fi or Ethernet has full local API access: it can read decrypted traffic, send as the node, change configuration (subject to managed mode) and read the private key. The project treats "a shared LAN, a USB cable to an untrusted host, a paired phone" as part of the node. It also warns that administering a Wi-Fi board over an untrusted network exposes that traffic, credentials included.

Is it as secure as Signal or TLS 1.3?

The project answers no. Those protocols add forward secrecy and rekeying that do not fit in a LoRa packet or a small microcontroller. AES-256 is considered quantum resistant, but the X25519 exchange is not. For how the double ratchet and MLS handle this on the internet, see end-to-end encrypted messaging explained.

Which key protects which traffic?

What does MQTT bridging do, and what does it leak?

A node with internet access (Wi-Fi, Ethernet, or the phone app's client proxy) can uplink packets to an MQTT broker and downlink broker packets onto the radio. The integration page says the device "simply uplinks and/or downlinks every raw protobuf MeshPacket that it sees", including packets from other nodes. For MQTT's own security model see MQTT and OPC UA: what the specs say about security and MQTT topic ACL patterns.

Uplink and downlink are set per channel. Topics look like msh/US/2/e/LongFast/!abcd1234: region, channel name and gateway node ID. Optional JSON output publishes text, position, telemetry and other packet types under msh/REGION/2/json/.

The privacy problems

Plaintext by default. Encryption Enabled in the MQTT module defaults to false, and the docs warn that messages go to the broker unencrypted "even when your uplink channels have encryption keys set."

Metadata always goes. Even encrypted, the broker sees topics and headers: who was active, when, and through which gateway.

Map reports. Since firmware 2.3.2 a node can publish an unencrypted map report with its names, ID, position (default precision about 1,459 metres), altitude and whether it is reachable on the default channel. It is off unless enabled.

Other people's packets. A gateway uplinks everything it hears on uplink channels. The "OK to MQTT" setting (default false) asks others not to uplink your packets, but the docs call it "not a cryptographic solution but a polite request", and it only covers channels on the built in default or event keys.

Downlink into the radio. Downlink lets broker traffic reach your mesh, widening exposure from people in radio range to anyone who can publish on that topic. Nodes on 2.2.19 or later can set Ignore MQTT to drop packets flagged as having come via MQTT. Several firmware advisories have involved MQTT handling; the live posts on CVE-2025-24797 and CVE-2025-55293 cover two firmware issues.

Public server or private broker?

The firmware's MQTT defaults point at the project's public server with published shared credentials. That server applies a zero hop policy (its traffic reaches directly connected nodes but spreads no further), allows a short list of packet types on the default key, and passes only position packets with 10 to 16 bits of precision. The docs recommend against the default key on a private broker, because private brokers do not enforce zero hop. Private brokers are for private channels.

Hardening a private broker

If you run your own broker, treat each gateway node as an untrusted client that may one day be stolen from a hilltop. The open source Mosquitto broker is a common choice, and its configuration manual documents the controls you need: allow_anonymous to refuse clients without a username, password_file for credentials (the manual warns to use network encryption with it, or passwords are "vulnerable to interception"), and acl_file with topic and pattern rules that limit what each user can read and write. A minimal shape:

# mosquitto.conf
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

# /etc/mosquitto/acl
user gw-hilltop
topic write msh/US/2/e/MyTeam/#
topic read msh/US/2/e/MyTeam/#

Give each gateway its own username, scope it to the channel topics it actually serves, and do not grant write on the JSON topic unless you want downlink from it. Pair this with Encryption Enabled on the node so the broker stores ciphertext, and your broker compromise becomes a metadata leak rather than a message leak.

What do the regional rules say about frequency, duty cycle and power?

A node with no region set will "not transmit any packets." Once set, the firmware applies a frequency, duty cycle and power ceiling, which the docs stress "is the ceiling the firmware applies, not your national limit."

United States: 47 CFR 15.247

Section 15.247 covers frequency hopping and digitally modulated radiators in 902 to 928 MHz. Digital modulation needs a 6 dB bandwidth of at least 500 kHz, with a 1 watt conducted limit, a power spectral density cap of 8 dBm per 3 kHz, and power reductions for antennas above 6 dBi. Hopping systems get 1 watt with at least 50 hopping channels, and paragraph (f) covers hybrids. Most Meshtastic presets use 250 kHz on one slot, so which rule a radio module was certified under, and at what power, comes from that module's FCC grant. Check it rather than assuming 30 dBm is legal for your build. A transmit power setting of 0 uses the hardware's default maximum legal continuous power, which the docs recommend.

Europe: SRD rules and duty cycle

EU radio equipment falls under the Radio Equipment Directive (2014/53/EU), and short range device bands are harmonised through CEPT's ERC Recommendation 70-03, first adopted on 6 October 1997 and revised regularly, with national implementation tracked in the ECO database. The project chose 869.4 to 869.65 MHz because it allows +27 dBm ERP with a 10% duty cycle; at 433 MHz the limit is +10 dBm ERP. The firmware enforces duty cycle over a rolling hour and stops a node at the limit. Ten percent is 360 seconds of airtime an hour: a person chatting will not hit it, but a router relaying a busy mesh can. An override exists; the docs warn "you might violate regulations."

Amateur radio

The 2 m, 1.25 m and 70 cm amateur regions are selectable only in licensed mode. Encryption is not permitted and you must transmit your call sign; in licensed mode nodes send unencrypted and sign what fits. Never enable it on a node that carries private traffic.

How does Meshtastic compare with LoRaWAN, Wi-SUN FAN and satellite messaging?

Details: Wi-SUN FAN explained and Zigbee, Thread and Matter explained. LoRaWAN and Wi-SUN start from an identity provisioned before deployment. Meshtastic deliberately has none, so its security rests on how users handle shared keys.

Step by step: flash, configure and secure a Meshtastic node

These steps use the official Python CLI over USB serial; the apps and web client expose the same settings. Run them only against your own node.

Step 1: get firmware only from official sources

Use the project's web flasher at flasher.meshtastic.org or a release from the meshtastic/firmware repository; low power boards take a UF2 file. Avoid builds from chat groups or file sharing links: firmware holds your private key and every channel key.

Know what you install. As of 25 October 2026 the security policy lists only 2.8.x as supported, while the newest 2.8 build (2.8.1, published 1 October 2026) is tagged alpha and two 2.8.0 builds are marked revoked. Read the release notes before choosing. Features marked 2.8 or 2.8.1 here need that version on every node involved.

Warning: a full erase deletes the node's key pair, and a new key means a new node number. Back up first (step 9) and confirm the board and serial port in the flasher before erasing.

Step 2: install the CLI and read the configuration

pip3 install --upgrade "meshtastic[cli]"
meshtastic --info

Check the firmware version, region, preset, role, channels and enabled modules.

Step 3: set region, preset, hop limit and role

meshtastic --set lora.region US --set lora.modem_preset LONG_FAST
meshtastic --set lora.hop_limit 3 --set device.role CLIENT

Use your real region code and your local mesh's preset. Chain settings because the device may reboot after each command. Use ROUTER or REPEATER only for a well sited, always on node, after asking your local mesh; too many routers make floods worse.

Step 4: add a private channel with a random key

Keep the primary on the default key if you want the public mesh, and put your group on a secondary channel:

meshtastic --ch-add MyTeam
meshtastic --ch-set psk random --ch-index 1

Share it in person by QR code; the channel URL contains the key. To go fully private, also run --ch-set psk random --ch-index 0, knowing you leave the public mesh. Do not put private channel keys on unattended nodes: they relay without the key, and physical access makes keys easy to extract.

Step 5: limit what your position reveals

Precision runs from 0 (none) to 32 (exact). Ten bits is about 23.3 km, 13 bits 2.9 km, 15 bits 729 m, 19 bits 45 m.

meshtastic --ch-set module_settings.position_precision 13 --ch-index 0
meshtastic --ch-set module_settings.position_precision 32 --ch-index 1

That shares an approximate area publicly and an exact fix with your group. For a home node with a fixed position, use a nearby public point rather than your door.

Step 6: decide on MQTT

If you do not need it, leave the module off and enable Ignore MQTT in LoRa settings. If you do:

meshtastic --ch-set uplink_enabled true --ch-index 1
meshtastic --ch-set uplink_enabled false --ch-index 0
meshtastic --ch-set downlink_enabled false --ch-index 0
meshtastic --set mqtt.enabled true --set mqtt.encryption_enabled true --set mqtt.tls_enabled true

Point it at your own broker with your own credentials, keep JSON off unless a consumer needs it, and leave Map Reporting off.

Step 7: lock down administration

• Add your admin public key in Security settings, test remote admin, then enable Managed Mode. Managed Mode without a working admin key locks you out.
• Keep Admin Channel Enabled off.
• On 2.8, consider meshtastic --set security.packet_signature_policy BALANCED.
• Disable unused interfaces: meshtastic --set network.wifi_enabled false, and on unattended nodes meshtastic --set security.serial_enabled false. Never provision Wi-Fi credentials over an untrusted network.

Step 8: harden unattended infrastructure nodes and rotate keys

Rooftop and hilltop nodes face a different threat: physical access. The project's guidance covers most of it. Keep only the default primary channel on an infrastructure node, since nodes relay packets they cannot decrypt. Set an admin key and Managed Mode so a passer by with the phone app cannot reconfigure it, turn off Wi-Fi and the serial console if you administer it over the mesh, and choose a Rebroadcast Mode of LOCAL_ONLY or KNOWN_ONLY if you do not want it carrying foreign meshes. Record each node's node number and public key when you deploy it, so a later key change warning means something.

The encryption docs also advise changing channel keys from time to time. Rotate after anyone leaves the group or any handheld is lost, since a lost node is a leaked key, and remember that rotation does not protect traffic already recorded.

Step 9: back up keys and keep firmware current

meshtastic --export-config > node-backup.yaml

This file contains your private key. Store it encrypted and offline, never in a shared folder or repository. Restore with meshtastic --configure node-backup.yaml. Then watch releases and security advisories: as of 25 October 2026 the repository lists 16 published advisories covering malformed packet handling, MQTT, key handling and the project's own CI. Updating every node, especially unattended routers, is the best control after key hygiene.

Common mistakes

• Chatting on the default key. AQ== is public; that chat is a broadcast.
• Assuming encrypted direct messages make everything private. Position and node info still travel under the channel key, and headers are always clear.
• Exact positions on a public channel. A home node at full precision publishes your address to the mesh and maybe to public maps via MQTT.
• MQTT uplink with Encryption Enabled off. The default sends decrypted private channel traffic to the broker.
• The default key on a private broker. No zero hop rule, so you risk exposure and flooding.
• Private keys on rooftop routers. They do not need them, and a stolen router gives them away.
• Unofficial firmware. A modified build can log keys or ignore OK to MQTT.
• Erasing without a key backup, which turns you into a stranger and trains contacts to ignore key warnings.
• Licensed mode for range. It disables encryption and requires a call sign.

FAQ

Is Meshtastic encrypted?

Yes, but strength depends on the key. Payloads are always encrypted; on the default channel the key is public. A random 256 bit channel key limits reading to key holders, and direct messages on 2.5 and later use per node keys. Headers are never encrypted.

What is the default Meshtastic channel key?

The single byte 0x01, shown as AQ== in Base64. It ships in the source code, so anyone with Meshtastic can read it.

Can people see my location on Meshtastic?

Only on channels where you set position precision above zero. Public key channels are capped at about 729 metres. MQTT uplinks and map reports can carry positions to the internet.

Does Meshtastic need the internet or cell service?

No. Nodes relay over LoRa. The internet is involved only if you enable the MQTT bridge.

What is the difference between Meshtastic and LoRaWAN?

Both use LoRa modulation. LoRaWAN sends sensor data through gateways to a network server with pre provisioned keys. Meshtastic is a peer to peer mesh with no infrastructure or provisioning, built for people messaging.

How far can Meshtastic reach?

Height, antennas and terrain matter most. Long Fast has a 153 dB link budget at 22 dBm with 0 dBi antennas, and the default three hops extend that further.

Is Meshtastic legal to use?

Generally yes on the unlicensed bands the firmware supports, with the correct region set and limits respected. National rules and your module's certification still apply, and amateur bands need a licence and forbid encryption.

Should I set my node to ROUTER?

Usually not. ROUTER suits a well sited, always on node; too many increase collisions. Ask your local mesh first.

Why supply chain hygiene still matters here

Meshtastic is open source end to end, and its firmware, apps and Python library pull in many other open source components. Safeguard does not analyse radios, firmware images or RF traffic, so the fit is indirect: it applies to software your team builds around a mesh, such as an MQTT bridge service, a tool built on the Python library, or a dashboard container that consumes broker data.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency scanning and remediation, not radio or mesh monitoring; Safeguard will not tell you whether a node is on the default key. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the repository or image for an MQTT bridge or mesh dashboard your team runs, the same scan lists the packages and versions inside and their known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and advisory, edit package.json to lodash 4.17.21, and run npm install and npm test. It asks before any command that changes something and pushes nothing. The same flow applies when you bump a vulnerable dependency in a Python or Node.js service that consumes Meshtastic packets from your broker.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Meshtastic: Encryption overview
• Meshtastic: Known limitations of Meshtastic's encryption
• Meshtastic: Encryption technical reference
• Meshtastic: Mesh broadcast algorithm
• Meshtastic: Radio settings and presets
• Meshtastic: LoRa configuration
• Meshtastic: Device configuration and roles
• Meshtastic: Channel configuration
• Meshtastic: Position configuration
• Meshtastic: Security configuration
• Meshtastic: Network configuration
• Meshtastic: User configuration and licensed mode
• Meshtastic: MQTT module configuration
• Meshtastic: MQTT integrations overview
• Meshtastic: Getting started
• Meshtastic: Python CLI installation
• Meshtastic: Python CLI guide
• Meshtastic web flasher
• meshtastic/firmware repository on GitHub
• meshtastic/firmware security policy
• meshtastic/firmware security advisories
• meshtastic/firmware releases
• LoRa Alliance: What is LoRaWAN
• eCFR: 47 CFR 15.247
• CEPT ECO documentation database: ERC Recommendation 70-03
• Wi-SUN Alliance: Wi-SUN FAN
• Eclipse Mosquitto: mosquitto.conf manual

Last reviewed: 25 October 2026.