Meshtastic 2.8: Packet Signing, Location Privacy and What Changes for Existing Nodes

Meshtastic 2.8 changes how nodes establish identity, authenticate packets and share location. Existing users should treat it as a migration, not a routine flash-and-forget update: remove the revoked 2.8.0 firmware, back up each node separately, check the release channel and verify privacy and messaging behaviour before changing an operational mesh.

As checked on 30 October 2026, the release information identifies 2.8.1 as an alpha. The project's announcement advises most users to wait rather than deploy it widely. That distinction matters more than the version number: a new security capability can be worth testing without being ready for every unattended router, field team or community installation.

What changed, and who should act now?

The original 2.8.0 signing implementation was revoked. Its signatures are incompatible with 2.8.1, so leaving one node behind is not a useful compatibility strategy. By contrast, older 2.7 nodes do not sign broadcasts and can still communicate with 2.8.1 under an accepting policy. These are different compatibility cases.

Packet signing establishes identity, not secrecy

A digital signature lets a receiver check a packet against the sender's known public key. It helps distinguish a message associated with that identity from a packet that merely claims a familiar name. It does not, by itself, hide the message, prevent radio interference or establish that the key belongs to the person you think it does.

For a team, exchanging identities through a trusted process remains important. Compare the intended node's key during commissioning and record which physical device belongs to which operator. A convincing display name is not an identity check, and possession of a shared channel key should not be confused with a verified individual sender.

The 2.8 announcement also describes verified direct-message delivery when the participants hold each other's keys. Test that workflow with your actual clients. A local “sent” indication, a radio acknowledgment and confirmation by the intended person answer different operational questions.

Signing and encryption should therefore be assessed separately. A public conversation can be authenticated while remaining readable. A private channel can protect content from people without its key while still requiring thoughtful key distribution. Neither setting makes a radio transmission physically invisible.

Choose a signature policy for the mesh you actually have

The security configuration offers Compatible, Balanced and Strict policies. Compatible is the default and accepts unsigned packets, which helps mixed-version meshes. Balanced applies stronger expectations to nodes already known to sign, with qualifications for broadcasts that can carry signatures. Strict accepts verified signed packets and encrypted direct messages, rejecting unsigned traffic.

Strict is not an automatic “best” setting for every installation. The documentation warns that unsigned channel acknowledgments can be rejected, causing a direct message to appear undelivered even when it arrived. Older firmware and builds without signing, including STM32WL-based builds, also need consideration.

For an existing community mesh, first inventory the participating firmware and hardware. Then test a normal broadcast, a direct message, a reply and the acknowledgment indication through the real relay path. Change one policy at a time. Otherwise, a policy rejection can easily be mistaken for poor range or a broken antenna.

Location privacy starts with the broadcast path

The release announcement says position and device-telemetry broadcasts are off by default, and precise location is not sent on public channels. That is a useful change in starting behaviour, but it is not a substitute for checking the configuration of an upgraded node, its paired phone and any internet integration.

GPS acquisition and position broadcasting are separate actions. A node can know its coordinates without needing to send them to everyone. Conversely, a board without its own GNSS receiver may receive position from a paired client. Review the source of location, the channels carrying it and the precision configured for each channel.

Default or widely known channel keys do not create a private group. If you need exact team positions, use an appropriately secured private channel and distribute access deliberately. Decide whether every member needs exact coordinates or whether less precise information is sufficient for the task.

Also check MQTT and map-report settings separately. Turning off one radio broadcast does not prove that no software, stored recording or internet-connected dashboard contains location. Test the complete information path, including what another ordinary node can actually see, rather than relying only on your own screen.

Node numbers change, so integrations need attention

In 2.8, a node's number is derived from its public key. The migration from 2.7 can therefore make a familiar physical device appear as a new node. Old entries can remain visible until they age out, which can look like duplicate hardware even when only one radio is present.

Review favourites, inventory records, MQTT topics and dashboards that use the previous number. Record an old-to-new mapping during commissioning. For a field team, update the device list used by operators so that a stale identifier is not mistaken for a missing person or an offline asset.

Back up each node's identity separately. A full erase can regenerate keys and change identity again. Restoring a node's own verified backup is different from copying one backup onto several radios: cloning identity material makes accountability and troubleshooting harder. Protect exported files because they may contain private keys and channel secrets.

A staged upgrade and recovery procedure

1. Record the current firmware, exact board target, radio band, region, modem preset and essential integrations.
2. Export configuration and securely retain the identity material for that individual node.
3. Update the client software needed to configure the new firmware.
4. Use an accessible spare or noncritical node for the first trial.
5. Flash the correct supported image and inspect its release status.
6. Review settings rather than assuming every old field restored with identical meaning.
7. Test messaging, acknowledgments, remote management and intended position sharing.
8. Keep the previous supported recovery files and physical access available during the trial.

The release notes identify a filesystem-format change and recommend a full erase and flash if an upgrade produces bootloops or repeated crashes. Do not erase first and discover afterwards that the only copy of a private key was on the radio. If restoring configuration recreates a fault, return to a minimal setup and reintroduce settings gradually.

For an unattended node, verify cold startup, reconnection to the client, battery operation and recovery after an ordinary power interruption. A successful USB flash does not establish that a rooftop or solar installation will remain manageable after you leave.

Radio settings and hardware still determine who you hear

The new US first-setup default is Long Turbo rather than Long Fast. That is not a new European default and does not mean an existing node's preset changes simply because it was upgraded. Nodes on incompatible modem presets will not hear each other even when their application version and channel names match.

For European installations, retain the correct hardware band and regional configuration. Packet signing does not make a 433 MHz assembly interchangeable with an 868 MHz assembly, nor does a firmware menu guarantee that a board's RF frontend supports every listed option.

Our LILYGO T-Beam Supreme listing offers distinct radio and GNSS options. Confirm the selected variant and current firmware target. Use our Meshtastic setup guide for the underlying region, channel and antenna checks.

Other changes worth evaluating after the essentials

The announcement includes memory-dependent node databases, congestion-related traffic management, geofenced waypoints and additional display and hardware support. Those can improve particular workflows, but they do not provide a universal node-count capacity or range guarantee. More memory and new routing behaviour cannot remove the airtime limits of the selected radio settings.

Check removed targets and integration changes before updating specialised equipment. The release also limits long names to 24 bytes, which is not necessarily 24 visible characters in every language. Keep operational names short, unambiguous and recognisable on the smallest screen in the team.

Frequently asked questions

Should every existing node move to 2.8 immediately?

No. Nodes on revoked 2.8.0 need attention, but the checked replacement remains alpha. Working deployments should use a staged decision based on the current release guidance.

Does a signed message become encrypted?

No. Authentication and confidentiality are separate properties. Review both the signature policy and channel or direct-message security.

Can 2.7 nodes remain in a trial mesh?

They can communicate under compatible conditions, but they do not provide the new signing behaviour. Strict policies change that compatibility.

Will disabling position broadcasts turn off the GPS?

Not necessarily. Acquiring a position and transmitting it are different settings and should be checked separately.

Do I need a new LILYGO board?

Not solely because 2.8 exists. Check the exact target, memory and features your current hardware supports before replacing it.

For additional nodes, compare our T-Beam hardware guide and use the SDRstore quotation process to specify matching bands and variants. Firmware preparation and a validated migration should be agreed explicitly rather than assumed.