Bluetooth Mesh Explained: Flooding, Provisioning, Keys and Mesh 1.1

Bluetooth Mesh is a Bluetooth SIG standard, adopted in July 2017, that links Bluetooth Low Energy devices into one network for lighting, sensors and building control. Messages hop by managed flooding, each is encrypted under a network key and an application or device key, and devices join by ECDH provisioning. Mesh 1.1 (2023) added directed forwarding and firmware updates.

This post goes one level deeper than our explainers on Bluetooth versions and their security history, BLE GATT, pairing and bonding, Zigbee, Thread and Matter and Z-Wave. The Z-Wave post sums up Bluetooth Mesh in one table row. Here we take that row apart, using the Mesh Protocol 1.1 text the Bluetooth SIG publishes, its Mesh 1.1 feature summary, the open source Zephyr mesh stack documentation and the CERT/CC record of the 2021 provisioning findings.

Key takeaways

• Bluetooth Mesh is not a new radio. It runs on the Bluetooth LE physical layer and mostly carries its messages in ordinary LE advertising packets (the advertising bearer).
• Managed flooding lets any relay that hears a message retransmit it. A 7 bit TTL (at most 126 relays) and a mandatory network message cache keep it from echoing forever.
• Four optional node features: Relay, Proxy (lets phones join over GATT), Friend (stores messages for sleepy devices) and Low Power.
• Provisioning uses ECDH on NIST P-256, an optional out of band (OOB) authentication value, and an encrypted delivery of the network key, IV Index and address.
• A network key protects every hop, an application key protects the payload end to end, and a per node device key protects configuration. A relaying light bulb can forward a door command it cannot read.
• The Key Refresh procedure evicts removed or lost nodes in three phases.
• Mesh 1.1 added directed forwarding, remote and certificate based provisioning, private beacons, subnet bridging, an HMAC-SHA-256 provisioning algorithm and, via separate model specifications, Device Firmware Update (DFU).
• The biggest real risks are operational: "No OOB" provisioning, one application key for everything, no key refresh, and unmanaged commissioning phones.

What is Bluetooth Mesh, and where is it used?

Bluetooth Mesh is a networking layer that the Bluetooth SIG defines on top of the LE Physical Transport from the Bluetooth Core Specification. The SIG's specification page says it defines "fundamental requirements to enable an interoperable mesh networking solution for Bluetooth low energy wireless technology". Plain BLE links one device to another. A mesh lets hundreds or thousands of devices talk to each other over many hops.

The SIG's own pitch is commercial and industrial. Its mesh page says the technology "was designed to meet the strict requirements of commercial and industrial environments" and names networked lighting control as a lead application. The SIG promotes Bluetooth Networked Lighting Control (NLC), a set of mesh device profiles for luminaires, sensors and switches, and lists gateways to the DALI lighting bus. Other common uses are occupancy and environmental sensing, HVAC integration, asset tracking and emergency lighting reports. The SIG also stresses that installers can commission a network straight from a phone or tablet. That convenience is also one of the weak points.

Bluetooth Mesh needs no central controller. Intelligence lives in the nodes: a switch publishes "on" to a group address and every light subscribed to that group acts on it. No hub has to be up for the lights to work, which is a different security model from Z-Wave or Zigbee coordinators.

The 2017 specification was called the Mesh Profile; version 1.1 renamed it the Mesh Protocol. Application behaviours (generic on/off, lighting, sensors, scenes, time) live in the Mesh Model specification, now at 1.1.1 according to the SIG. Firmware update and bulk transfer live in the Mesh Device Firmware Update Model 1.0 and Mesh Binary Large Object Transfer Model 1.0 specifications.

Timeline

How is a Bluetooth mesh network put together?

The specification defines two stacks on top of Bluetooth LE: the mesh networking stack nodes use to talk to each other, and the provisioning stack used to add devices. The networking stack has seven layers:

A provisioned device is a node. Each node has one or more elements, each with its own unicast address; the specification's example is a dual socket power strip with one element per socket. Elements host models: a server model holds state (for example Generic OnOff Server), a client model changes or reads it. SIG models have 16 bit identifiers, vendor models 32 bit ones.

Addresses are 16 bits. A unicast address (0x0001 to 0x7FFF) belongs to one element, which caps a network at 32,767 elements. Virtual addresses (0x8000 to 0xBFFF) come from 128 bit label UUIDs, and group addresses fill the rest, including fixed groups such as all-proxies (0xFFFC), all-friends (0xFFFD) and all-relays (0xFFFE). Communication is publish and subscribe: each model instance has one publish address and can subscribe to several groups. The specification's example is a light subscribed to the bedside, bedroom, upstairs and house groups. The commissioning tool writes every publish address, subscription and key binding, which is why it matters so much.

How does managed flooding work?

Managed flooding is the original relaying method and still the default. The specification says messages are delivered over multiple hops "by re-broadcasting the message at each hop to all neighboring nodes". There is no routing table. Any node with Relay enabled that hears a valid message for someone else can send it on. Five mechanisms stop that becoming a broadcast storm.

1. The advertising bearer. Messages ride in LE advertising packets, so any scanning node can hear them without a connection. No link setup per hop keeps latency low for switching lights.

2. Time to live (TTL). Every Network PDU carries a 7 bit TTL:

The originator sets the starting value and so decides how far the message spreads. A node that receives TTL 0 knows the sender is one radio hop away.

3. The network message cache. Every node must keep a Network Message Cache and discard any PDU it has already seen, before checking its security. The specification requires at least two entries and "highly" recommends sizing it for the network's density. Because TTL and the network MIC change at each hop, nodes must ignore both when matching, so stacks usually key the cache on source address and sequence number.

4. Retransmit settings. Advertising is unacknowledged, so nodes send each PDU several times. In the Zephyr stack the shell exposes a relay retransmit count of 0 to 7 and an interval of 10 to 320 milliseconds, defaulting to 2 and 20 ms.

5. Choosing who relays. You do not have to enable Relay on every mains powered node. In a dense ceiling grid, installers pick a subset with enough overlap to cover the floor. That is the main tuning lever, and the reason the SIG added directed forwarding for large sites.

Worked example: the TTL hop budget

A corridor has relays every 10 metres and a sensor must reach a controller 75 metres away, so the message needs at least 8 relays. Sent with TTL 10, the eighth relay receives 3 and sends 2, and the controller gets it. With TTL 5, the fifth relay receives 1 and the message stops after about 50 metres. Set too high, a message to a building wide group can travel far beyond where it is useful and burn airtime on every floor.

Worked example: traffic from one message

A floor has 60 relays, each sending every relayed PDU three times. In the worst case, where every relay hears the message, one switch press creates up to 60 x 3 = 180 extra advertising transmissions. The cache stops each relay forwarding the same PDU twice but does not stop the first round. Halving the relays to 30, placed for coverage, cuts that ceiling to 90. That arithmetic, not cryptography, usually limits a managed flooding network's size.

GATT proxy: how a phone talks to the mesh

Many phones cannot freely send and receive the advertising packets the mesh uses. A Proxy node accepts a GATT connection from a Proxy Client (the commissioning or control app) and copies Network PDUs between that link and the advertising bearer. Proxy traffic stays encrypted under the network and application keys, so the proxy is a radio bridge, not a point where application data is decrypted.

What do relay, proxy, friend and low power nodes do?

Every node can send and receive. Four optional features add roles, and the Configuration Server model switches them on or off.

Friend nodes and low power nodes

A battery sensor cannot listen all day. But if it never listens, it misses configuration and security updates such as a key refresh or IV Index change, and the specification warns it may "eventually drop off the network". Friendship fixes this.

The Low Power node (LPN) sends a Friend Request, nearby Friend nodes reply with offers, and the LPN picks one within a single hop and in the same subnet. The Friend keeps a Friend Queue of messages for the LPN. When the LPN wakes, it sends a Friend Poll and the Friend answers within a negotiated window with a queued message or a Friend Update carrying the current IV Index and key refresh state.

Two numbers matter. The PollTimeout is counted in 100 millisecond units from 0x00000A to 0x34BBFF, that is from 1 second to just under 96 hours, and the specification says an LPN "should collect all stored messages at least once every 96 hours" or the Friend may discard them. Friendship traffic uses its own friendship security material, derived from the network key and both nodes' identities, so other nodes cannot inject messages into it. In buildings, battery sensors depend on mains powered friends: plan friend coverage like relay coverage.

How does provisioning work?

Provisioning turns an unprovisioned device into a node. The Provisioner, usually a commissioning app or gateway, gives the device a network key, the current IV Index and a unicast address, and both sides end up sharing a device key. It runs over three bearers: PB-ADV (advertising), PB-GATT (a GATT connection, for phones), and, new in 1.1, PB-Remote, which provisions through the existing mesh so nobody has to stand next to the device.

Afterwards the Configuration Manager (often the same app) reads Composition Data, sends application keys under the device key, binds them to models and sets publication, subscription and features. Provisioning gets a device onto the network. Configuration decides what it can do.

Out of band authentication methods

A device can declare it supports only OOB authenticated provisioning, in which case weaker paths must fail. For remote provisioning the specification says provisioning "should not be done using Authentication with No OOB" and should use an OOB public key.

Worked example: what an AuthValue is worth

A blink count of 1 to 9 has about 3.2 bits of entropy. A 6 digit displayed number, such as the specification's example 019655 (encoded as 0x4CC7), has 10^6 values, about 20 bits. A random 16 byte static value has 128 bits, and under the Mesh 1.1 HMAC-SHA-256 algorithm the AuthValue is 256 bits wide, so a 32 byte static value fills it. Anyone who can test a million guesses a second offline exhausts 20 bits in about a second. That is why fresh values per attempt and long static values matter, and it is the heart of the 2021 findings below.

How are keys used in Bluetooth Mesh?

The specification says all messages are "encrypted and authenticated using two types of keys", one for the network layer and one for application data, plus device keys for configuration. It builds on AES-128: AES-CCM for authenticated encryption and AES-CMAC for key derivation, with HMAC-SHA-256 added for provisioning in 1.1.

Relays need only the NetKey to check and forward, and the payload is sealed again under an AppKey. In the specification's words, "a light bulb acting as a Relay node should not be able to unlock doors."

Application keys, subnets and guests

AppKeys are bound per model, up to 251 per model. The specification's example is a Light Lightness Server with admin, user and guest keys bound, while the Configuration Server accepts only the admin key. A building might use separate AppKeys for lighting, access control and HVAC sensors. The Configuration Manager can hold up to 4,096 NetKeys and 4,096 AppKeys, addressed by 12 bit global key indexes.

A subnet is the set of nodes sharing one NetKey; the specification's example is isolated hotel room subnets in a hotel network. Temporary guest access gives a guest its own NetKey and AppKeys bound only to the models it may use, and is revoked by key refresh. Mesh 1.1 subnet bridging lets a node pass traffic between subnets for configured addresses, while "attempts to reach unauthorized addresses are blocked".

Sequence numbers and the IV Index

Each Network PDU carries a 24 bit sequence number. With the 32 bit IV Index and the source address it forms the AES-CCM nonce, so it must never repeat. It also drives replay protection: receivers keep the last valid IV Index and sequence number per source and discard anything equal or lower.

Worked example, using the specification's numbers: 24 bits give 16,777,216 sequence numbers. An element sending 2 messages a second uses them in 16,777,216 / 2 = 8,388,608 seconds, about 97 days. The IV Update procedure then increments the IV Index and resets sequence numbers. A node may start one after 96 hours of normal operation and must stay "in progress" for at least 96 and under 144 hours, so a full cycle takes at least eight days. At 2 Hz, the specification says, the IV Index stretches the network's life to "billions of years". A device that loses its sequence counter at power loss, or is cloned, can repeat nonces or be rejected, which is why good stacks persist counters to flash.

Obfuscation and private beacons

Each Network PDU header (CTL, TTL, sequence number, source address) is obfuscated with AES under the PrivacyKey "to make tracking nodes more difficult". It is privacy, not secrecy: anyone with the NetKey can undo it. The original Secure Network beacon carries a Network ID derived from the NetKey that stays fixed for the key's life. Mesh 1.1 Mesh Private beacons carry a 13 byte random value and an obfuscated payload, and the SIG says they ensure "no static information in beacon messages is visible to devices outside of the network". Private proxy advertising and an On-Demand Private Proxy complete the set.

The Key Refresh procedure

The specification says key refresh is used "when the security of one or more network keys and/or one or more of the application keys has been compromised or could be compromised", with node removal as the main case. It defends against the "trash-can attack": keys recovered from a discarded device. It works because new keys reach each remaining node under that node's own device key, so the evicted node never gets them.

Each NetKey refreshes independently, an AppKey changes only if given a new value, and key refresh and IV Update can overlap.

Node removal and ownership

Node Removal (Config Node Reset) tells a node to delete its keys and provisioning data. That only works on a reachable, honest node; a stolen or broken one never hears it, so removal must always be followed by key refresh. A Provisioner may reuse a removed node's addresses only after an IV Index update. Mesh 1.1 also adds Device Key Refresh, Node Address Refresh and Node Composition Refresh over PB-Remote. The specification states that the network key and device keys "constitute the ownership of the network", and the SIG summary says regenerating all device keys enables "the secure transfer of ownership".

What went wrong with provisioning, and what changed?

On 24 May 2021 CERT/CC published VU#799380, covering findings by researchers at ANSSI against the Bluetooth Core and Mesh Profile specifications. Four CVEs concern Mesh Profile 1.0 and 1.0.1 provisioning. At concept level:

Every finding sits in the provisioning moment, and every mitigation is either real OOB authentication or a stack update. Mesh 1.1 then added the BTM_ECDH_P256_HMAC_SHA256_AES_CCM algorithm through the Enhanced Provisioning Authentication change request, with 256 bit random values and a 256 bit AuthValue folded into the confirmation key. A device "shall" advertise it, a Provisioner "should choose the strongest algorithm", and it "shall not" use the older CMAC algorithm if the device supports the new one. Certificate based provisioning then delivers the out of band public key CERT/CC recommended.

What did Mesh 1.1 add?

The revision history lists the change requests in 1.1: certificate based provisioning, remote provisioning, directed forwarding, private beacons, subnet bridge, minor enhancements and enhanced provisioning authentication. The SIG summary also covers the new firmware update models.

Directed forwarding versus managed flooding

The SIG calls managed flooding "effective, reliable, flexible, and low-maintenance" and says directed forwarding "in some situations is more efficient". The originator chooses per message. A directed relay keeps a forwarding table per subnet and retransmits only messages matching a path it belongs to. In the specification's example, eight nodes support directed relay but only two sit on the path from a low power node to its destination, and the rest do not relay even when they overhear. Flooding stays simplest for small networks and group messages that must reach everywhere; directed forwarding pays off in large, dense sites with predictable flows.

Device Firmware Update in practice

DFU uses the BLOB Transfer models to move images in chunks. In the Zephyr documentation's description, an Initiator (usually the phone or gateway that provisions) uploads an image and metadata to a Distributor inside the mesh, which then updates any number of Target nodes concurrently while the Initiator disconnects. The SIG highlights multicast updates for "lighting networks consisting of many identical devices", applied "outside office hours". One detail matters for reviews: Zephyr describes the firmware metadata format as vendor specific and notes "typical metadata information can be image signatures". Whether a target rejects an unsigned image is up to the vendor's metadata check and bootloader, so ask.

How does Bluetooth Mesh compare with Thread, Zigbee and Z-Wave?

Bluetooth Mesh's strengths are no single controller to fail, direct phone access and a clean split between network and application keys. Its weaknesses are no native IP, the airtime cost of flooding at scale, and heavy reliance on whoever holds the commissioning database.

Step by step: secure the Bluetooth mesh networks in your buildings

Most building teams use a lighting vendor's commissioning app and gateway, not a mesh stack. The steps are written for that reality, with Zephyr mesh shell commands to show what each step means at protocol level in a test lab. Do not run lab commands on a production network outside your vendor's procedure.

Step 1: Inventory every mesh network

Treat the network database export as a secret. Whoever has it owns the network.

Step 2: Require out of band authentication

Buy devices that support per device static OOB (often a QR code), OOB public keys or certificate based provisioning, and set the commissioning tool to refuse No OOB. In the Zephyr shell, the Provisioner picks the method before provisioning:

# Lab only. On your workstation, generate a fresh 16 byte value per device:
openssl rand -hex 16

# In the Zephyr mesh shell on the Provisioner board: static OOB with that value
mesh prov auth-method static <32-hex-digit-value-from-the-device-label>

# Or output OOB if the device can display a number (4 = display number, 6 digits)
mesh prov auth-method output 4 6

Zephyr documents mesh prov auth-method none as "the default behavior", which is exactly why production tools must change it.

Step 3: Split application keys by function

# Lab only: give node 0x0010 two different application keys on NetKey 0
mesh target dst 0x0010
mesh models cfg appkey add 0 0 <new-random-lighting-key>
mesh models cfg appkey add 0 1 <new-random-sensor-key>

# Bind AppKey 0 only to the Generic OnOff Server (model 0x1000) on element 0x0010
mesh models cfg model app-bind 0x0010 0 0x1000

Always pass an explicit random key. Zephyr's shell documentation says that if the key is omitted, "the default key value is used": fine on a bench, dangerous anywhere else.

Step 4: Remove nodes properly, then run key refresh

Run key refresh whenever a node is removed, replaced, stolen or sent for repair, and whenever a commissioning phone is lost.

Warning: mesh models cfg reset and mesh cdb node-del permanently remove a node. Before each, confirm the address against your inventory with mesh cdb show and mesh target dst, and check you are on the right network database.

# Lab only. 1) Confirm the node you are about to remove
mesh cdb show
mesh target dst 0x0023

# 2) Tell it to forget its keys (only works if it is reachable and honest)
mesh models cfg reset

# 3) Remove it from the configuration database so it gets no new keys
mesh cdb node-del 0x0023

# 4) Phase 1: new NetKey and AppKeys to every remaining node, one at a time
mesh target dst 0x0010
mesh models cfg netkey upd 0 <new-random-netkey>
mesh models cfg appkey upd 0 0 <new-random-lighting-key>
# ...repeat for every remaining node

# 5) Phase 2: switch to the new keys
mesh models cfg krp 0 0x02

# 6) Phase 3: revoke the old keys
mesh models cfg krp 0 0x03

Zephyr's documentation lists phases 0x00 to 0x02 for krp, while the specification defines transition 0x03 as the step that revokes old keys, so check your stack before step 6. Low power nodes learn of Phases 2 and 3 through their friend's Friend Update, so allow at least their poll interval. In vendor tools this is usually one "rotate keys" or "remove device securely" action; if yours has none, ask for it in writing.

Step 5: Track and apply firmware through DFU

# Lab only: Zephyr Firmware Update Client on the Distributor
mesh models dfu cli target 0x0030 0      # add Target node 0x0030, image index 0
mesh models dfu cli target-imgs          # list its images and firmware IDs
mesh models dfu cli target-check 0 0     # will it accept slot 0, and with what effect?
mesh models dfu cli send 0 0xC001        # distribute slot 0 via group 0xC001
mesh models dfu cli progress
mesh models dfu cli apply                # apply at a planned time
mesh models dfu cli confirm              # confirm targets run the new image

Record firmware IDs from target-imgs in the inventory, and ask your vendor how images are signed and verified before approving a rollout.

Step 6: Manage commissioning devices and watch health

The commissioning phone often holds, or can download, every key in the building. Put it under device management, require a screen lock and one account per installer, remove accounts when a project closes, and treat a lost phone as a lost master key: run Step 4. Use Heartbeat publication (mesh models cfg hb-pub and hb-sub in Zephyr) and the Health models to spot nodes that went silent, for example after missing a key refresh.

Common mistakes

• Provisioning with No OOB. It stops passive listening but not an active impersonator. Use per device static OOB, OOB public keys or certificates.
• Short or shared static OOB values. A value shared by every device of a model is a password everyone knows.
• Never rotating keys. Every removed fixture and departed installer since installation day still knows the original keys.
• Removing a node without key refresh. A discarded device keeps its keys: the trash-can attack the specification names.
• One application key for every function. A compromised lighting node should never hold the key for doors.
• Default keys from development tools. Check that no production network was built with lab defaults.
• Commissioning apps on unmanaged phones. A personal phone with a cached network database is the master key.
• Relay on everywhere, and TTL by guesswork. Both waste airtime or drop messages; plan them from real hop counts.
• Ignoring friend coverage, and no firmware plan. Removing a mains node can orphan sensors, and stacks with old provisioning weaknesses stay in ceilings for years without DFU or a vendor process.

FAQ

Is Bluetooth Mesh the same as Bluetooth Low Energy?

No. It is a separate SIG specification on top of the Bluetooth LE physical layer, with its own network, transport, access and model layers. A device needs a mesh stack, not just a BLE stack, to join.

How many devices can a Bluetooth mesh network have?

Unicast addresses run from 0x0001 to 0x7FFF, so up to 32,767 elements; multi element devices use several. In practice airtime, relay planning and the commissioning tool limit you sooner.

What is managed flooding in Bluetooth Mesh?

The original relaying method: any relay that hears a valid message for someone else retransmits it on the advertising bearer. TTL caps the hops at 126, and a network message cache stops repeats.

What is a friend node in Bluetooth Mesh?

A mains powered node that stores messages for a battery powered Low Power node, hands them over when polled, and passes on key refresh and IV Index updates.

Is Bluetooth Mesh secure?

The design is sound: AES-CCM with separate network, application and device keys, replay protection and ECDH provisioning. Known weaknesses have been in provisioning without strong OOB authentication and in operations such as never rotating keys.

What changed in Bluetooth Mesh 1.1?

The Mesh Profile became Mesh Protocol 1.1 (adopted 12 September 2023) with directed forwarding, remote and certificate based provisioning, private beacons, subnet bridging and an HMAC-SHA-256 provisioning algorithm. DFU and BLOB Transfer arrived as separate model specifications.

Does Bluetooth Mesh need a hub, and can a phone control it directly?

No hub is needed for local operation, because control logic lives in the nodes and switches publish straight to lights. A phone can join through any node with the Proxy feature over a normal GATT connection. A gateway is only needed to reach the mesh from IP systems, the cloud or a building management system.

What is the key refresh procedure?

A three phase process that replaces a network key and its application keys on every node that stays: distribute under each device key, switch, then revoke the old keys. Nodes left out never learn the new keys.

Does NIST guidance cover Bluetooth Mesh?

Not directly. NIST SP 800-121 Rev. 2 (May 2017, updated January 2022) covers Bluetooth 1.1 to 4.2, including low energy, but not mesh. Its advice on inventory, pairing security and patching still applies.

Where Safeguard fits

Safeguard does not monitor mesh radio traffic, manage NetKeys or AppKeys, provision devices, scan device firmware or manage commissioning phones; those belong to your building vendor's tools and your device management. The honest fit is the software around the mesh. Gateways, building management integrations, commissioning back ends and stacks such as Zephyr are software projects with open source dependencies and container images. Safeguard can scan those repositories and images, list the components and versions inside, match them against vulnerability data, show which projects carry a given package version, apply policies and gates in CI, and open fix pull requests when you switch autonomous remediation on.

A mesh gateway rebuilt after a failure pulls its dependencies again, and its services, cloud connectors and mesh stack all ship open source components that receive fixes on their own schedule. That is why software supply chain hygiene still applies to a building network made of radios, even though device firmware itself must come from each vendor.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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, SBOM and remediation workflows, not mesh radio monitoring, key management or firmware analysis. 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 container image of a mesh gateway or building integration service, the same scan lists the open source packages and versions inside and their known vulnerabilities, so you know what to rebuild after an advisory.

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

This demo is a real CLI session: you ask it to fix the lodash CVE in a repository, and it reads the finding and the advisory, asks before any command that changes something, moves lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies when a Node.js commissioning back end or gateway dashboard needs a dependency bump.

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 or images ship a given package version, for example in your gateway builds, and get the answer from your own scan data rather than from memory.

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

Quick check

Sources

• Bluetooth SIG: Mesh Protocol specification page (Mesh Protocol 1.1)
• Bluetooth SIG: Mesh Protocol 1.1 specification, HTML
• Bluetooth SIG: Mesh Model specification page (Mesh Model 1.1.1)
• Bluetooth SIG: Mesh Device Firmware Update Model
• Bluetooth SIG: Mesh Binary Large Object Transfer Model
• Bluetooth SIG: Bluetooth Mesh feature enhancements summary (September 2023)
• Bluetooth SIG: Bluetooth Mesh networking
• Bluetooth SIG: Mesh security overview
• Bluetooth SIG: Core Specification
• CERT/CC: VU#799380
• NVD: CVE-2020-26556
• NVD: CVE-2020-26557
• NVD: CVE-2020-26559
• NVD: CVE-2020-26560
• NIST SP 800-121 Rev. 2 (with updates): Guide to Bluetooth Security
• Zephyr Project: Bluetooth Mesh
• Zephyr Project: Bluetooth Mesh shell
• Zephyr Project: Bluetooth Mesh Device Firmware Update
• Thread Group: What is Thread
• Connectivity Standards Alliance: Zigbee
• Z-Wave Alliance: About Z-Wave

Last reviewed: 26 October 2026. Bluetooth SIG specifications receive errata and new versions; check the specification pages above for the versions your devices implement.