Zigbee, Thread and Matter Explained: How the Smart Home Stack Is Secured

Zigbee, Thread and Matter are three layers of the smart home. Zigbee is a complete low power mesh stack from the Connectivity Standards Alliance (CSA). Thread is an IPv6 mesh network from the Thread Group. Both use the IEEE 802.15.4 radio. Matter is the CSA's IP application layer over Thread, Wi-Fi and Ethernet.

That split explains most of the security story. Zigbee secures its own network and its own application layer, with a central Trust Center handing out keys. Thread secures the mesh with one network key and leaves the application to someone else. Matter adds device identity, certificates and encrypted sessions on top of IP, and its own core specification says that security "does not rely on the security of the communication technologies on top of which Matter runs" (CSA, Matter Security and Privacy Fundamentals). For a gentler introduction to Matter on its own, read what Matter is, in plain words. This post goes a layer deeper: frames, keys, commissioning flows, weakness classes, and the commands a defender can run against a hub they own.

Key takeaways

• IEEE 802.15.4 is the shared radio and MAC layer. Its physical frame is at most 127 octets, so RFC 4944 (September 2007) and RFC 6282 (September 2011) define 6LoWPAN, the adaptation layer that fragments and compresses IPv6 to fit. Thread uses 6LoWPAN; classic Zigbee does not carry IP.
• The current IEEE standard is 802.15.4-2024, approved by the IEEE SA Board on 26 September 2024 and published on 12 December 2024. It superseded 802.15.4-2020.
• Zigbee's centralized security model makes the coordinator the Trust Center, which sends each joining device the network key encrypted under a link key. If that link key is the specification's published default, the join is only as secret as the moment it happens. Install codes and a mandatory link key exchange close that gap.
• Zigbee PRO 2023 (April 2023) added Dynamic Link Key, Device Interview and Trust Center Swap Out. Zigbee 4.0 (November 2025) added frame counter synchronisation against replay, Restricted Mode and more, while staying backward compatible with Zigbee 3.0.
• Thread forms a self healing IPv6 mesh with one Leader, up to 32 routers and up to 511 end devices per router. Border routers connect it to Wi-Fi or Ethernet. Every message on the mesh is encrypted at the MAC layer. Thread 1.4 (September 2024) added Credentials Sharing and certificate based commissioning (TCAT).
• Matter commissioning runs PASE (SPAKE2+ on a setup passcode), checks a Device Attestation Certificate, installs a Node Operational Certificate, and then uses CASE (a SIGMA based exchange) for all operational traffic. IANA registers TCP and UDP port 5540 for Matter.
• The most common real weaknesses are operational, not cryptographic: old joining modes left enabled, commissioning windows left open, setup codes left readable, too many admins, and firmware that never gets updated.

What each protocol is for, the layer and the standard

The stack in one picture

+---------------------------+---------------------------+--------------------------+
|  Zigbee application       |  Matter data model,       |  Matter over Wi-Fi or    |
|  (Zigbee Cluster Library) |  interaction model        |  Ethernet                |
+---------------------------+  Secure sessions (PASE,   |  (same Matter layers)    |
|  Zigbee APS, security     |  CASE), message layer     |                          |
|  services, Trust Center   +---------------------------+--------------------------+
+---------------------------+  UDP (with MRP) or TCP    |  UDP or TCP              |
|  Zigbee NWK (mesh         +---------------------------+--------------------------+
|  routing, not IP)         |  IPv6                     |  IPv6                    |
|                           +---------------------------+                          |
|                           |  Thread mesh, MLE,        |                          |
|                           |  6LoWPAN (RFC 4944/6282)  |                          |
+---------------------------+---------------------------+--------------------------+
|  IEEE 802.15.4 MAC and PHY (2.4 GHz and Sub-GHz)       |  IEEE 802.11 or 802.3   |
+-------------------------------------------------------+--------------------------+
          Bluetooth LE is used beside the stack for setup (Matter, Zigbee Direct, TCAT)

IEEE 802.15.4: the shared radio

IEEE 802.15.4 defines the physical layer and MAC sublayer "for low-data-rate wireless connectivity with fixed, portable, and moving devices with no battery or very limited battery consumption requirements", in the words of the IEEE SA page for 802.15.4-2024. That revision was approved on 26 September 2024, published on 12 December 2024, and superseded 802.15.4-2020. The IEEE page also lists newer amendments, including one for Ascon cryptographic algorithms and one for privacy enhancements.

The CSA's Zigbee FAQ gives the radio parameters most products use: 250 kb/s on 16 channels at 2.4 GHz worldwide, with Sub-GHz options in the Americas and Europe.

The radio layer can encrypt and authenticate frames with AES-CCM, but it does not say how keys are created, shared or rotated. RFC 4944 says this plainly: 802.15.4 "only defines the Advanced Encryption Standard (AES) modes for authentication or encryption" and "does not, in particular, specify key management". Zigbee and Thread each fill that gap in their own way.

6LoWPAN: making IPv6 fit

IPv6 requires a minimum link MTU of 1280 octets. An 802.15.4 frame is 127 octets. RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (Proposed Standard, September 2007), walks through the arithmetic: 127 octets minus up to 25 of frame overhead leaves 102, and link layer security with AES-CCM-128 costs up to 21 more, leaving 81. After a 40 octet IPv6 header and an 8 octet UDP header, 33 octets remain for application data. So RFC 4944 adds a fragmentation and reassembly layer below IP, a mesh addressing header, and a first header compression scheme (LOWPAN_HC1 and HC2).

RFC 6282, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" (September 2011), updates RFC 4944. It found HC1 and HC2 "insufficient for most practical uses" and replaced them with LOWPAN_IPHC for the IPv6 header and LOWPAN_NHC for next headers such as UDP, using shared context so routable prefixes compress too. Thread is built on this layer; the Thread Group describes its "6LowPAN foundation" based on 802.15.4.

Zigbee: a full stack from the CSA

Zigbee is a complete stack: 802.15.4 radio, the Zigbee PRO network layer (mesh routing with its own short addresses, not IP), an application support sublayer with security services, and an application layer based on the Zigbee Cluster Library. The CSA describes it as the "full stack solution from the mesh protocol to the application layer". The core specification is CSA document 05-3474. The commissioning and security behaviour that every modern device follows is in the PRO Base Device Behavior (BDB) specification, version 3.0.1, dated 28 September 2021, whose stated purpose is to "ensure profile interoperability" across application profiles.

Thread: an IPv6 mesh from the Thread Group

Thread is "a low-power wireless mesh networking protocol based on the universally supported Internet Protocol (IP)", per the Thread Group. It "addresses the networking layer: routing, commissioning and security" and deliberately does not define an application layer. That is the gap Matter fills. The current public version is Thread 1.4, described in the Thread Group's September 2024 features white paper; the Thread Group's site offers the 1.4.1 specification on request.

Matter: an application layer over IP from the CSA

The Matter core specification "defines fundamental requirements to enable an interoperable application layer solution for smart home devices over the Internet Protocol". Version 1.0 was accepted by the CSA Board on 28 September 2022. Version 1.2 followed on 18 October 2023. The CSA announced Matter 1.6 on 17 June 2026, which is the current release as of this post. Matter certification also requires certification of the underlying transport: the CSA FAQ says devices must be certified for Wi-Fi, Thread or Ethernet "as required by their governing organizations".

Matter does not bridge Zigbee natively. The CSA FAQ is direct: "there is no native interoperability between Matter and Zigbee devices". It specifies bridges instead, and borrows heavily from the Zigbee Cluster Library for its data model.

How they work on the wire

Zigbee network formation and the Trust Center

A Zigbee network has three logical device types. The BDB specification says a coordinator "SHALL also encompass the role of the Trust Center" and forms a centralized security network. Routers relay traffic and can form a distributed security network (no Trust Center) only if no network is available to join. End devices join an existing network but never route.

Every device on the network shares one network key, used to secure network layer frames. The interesting part is how a new device gets it. The BDB specification defines four kinds of link key a device can use to receive the network key:

The join sequence on a centralized network, simplified from BDB sections 8 and 10:

Existing node / hub                 Trust Center (coordinator)         Joining device
      |  Permit joining opened for at least 180 s  |                         |
      |------------------------------------------->|                         |
      |                                            |<--- 802.15.4 association|
      |              TC decides: default key or install code key?          |
      |                                            |--- APS Transport Key -->|
      |                                            |  (network key, encrypted|
      |                                            |   under the link key)   |
      |                                            |<-- APS Request Key -----|
      |                                            |--- new unique link key->|
      |                                            |  (if exchange fails and |
      |                                            |   it is required, the   |
      |                                            |   device is removed)    |

Three BDB details matter for security. First, bdbcMinCommissioningTime is 180 seconds: network steering opens permit joining for at least that long. Second, bdbTrustCenterRequireKeyExchange defaults to TRUE, so a joining device must replace its initial link key with a unique one generated by the Trust Center, which "SHALL NOT be all zeros" and must not equal the global key, or be removed. The exchange method is either APS Request Key or Certificate Based Key Exchange (CBKE). Third, bdbJoinUsesInstallCodeKey defaults to FALSE: unless the Trust Center is configured to require install codes, the default global key is accepted for the initial join.

Install codes

An install code is a 128 bit random number plus a 16 bit CRC (CRC 16 CCITT), printed on the device or its packaging as groups of four hex digits. The Trust Center derives an AES-128 link key from it with the Matyas-Meyer-Oseas hash, and must have that key and the device's EUI-64 before the device joins. The BDB specification says "All nodes SHALL support install codes", that professionally installed devices such as meters may require them, and that a Trust Center "MAY require the use of install codes for all nodes joining its network".

Zigbee frame protection

The CSA lists Zigbee's mechanisms as "AES-128 bit message encryption and authentication, certificates, out-of-band authentication, and elliptic crypto", and its FAQ specifies over the air AES-128-CCM. Zigbee PRO 2023 added Dynamic Link Key, which the CSA describes as based on public and private key pairs and "state-of-the-art security curves", so the initial key no longer has to be a shared secret at all.

Thread network formation

The OpenThread primer (OpenThread is the open source Thread implementation published by Google) describes the roles:

Thread keeps the router count between 16 and 23 when it can. If radio contact splits the mesh, each partition elects its own Leader but keeps the same credentials; OpenThread puts it as "Security credentials define the Thread network". Addresses follow IPv6 scopes: link local for one radio hop, mesh local from an fd00::/8 unique local prefix for the whole Thread network, and global or off mesh prefixes advertised by border routers.

Those credentials live in the Active Operational Dataset. The OpenThread CLI documentation shows its fields: channel, channel mask, extended PAN ID, mesh local prefix, network key, network name, PAN ID, PSKc and security policy. The network key protects MAC frames on the mesh; the Thread Group says the network uses "MAC encryption for all messages".

Thread commissioning

The Thread Group summary: a user commissions a device with a phone, tablet or computer, "a security session is established between the new device and the commissioning device to authenticate and provide credentials", and then "the device attaches to the Thread network and uses MAC encryption for all messages". In OpenThread terms, a border router runs a Border Agent; when it is active, "External commissioner can connect and establish secure DTLS sessions with the Border Agent using PSKc", the commissioning credential that the OpenThread reference says is generated from a passphrase together with the network name and extended PAN ID.

Thread 1.4 added two flows:

• Thread Credentials Sharing. A user authenticates to their border router with the vendor's own method, the router generates a one time passcode, and both sides derive an Ephemeral Pre-Shared Key for the Commissioner (ePSKc). A phone app uses it to open a DTLS session to the border router and retrieve the network credentials, so a second ecosystem can join the existing mesh instead of forming a new one.
• Thread Commissioning over Authenticated TLS (TCAT). A TLS session over Bluetooth LE between a commissioning tool (TLS client) and the device (TLS server), mutually authenticated with X.509 certificates. The device's certificate, which may be an IEEE 802.1AR IDevID, "must be provisioned immutably into the TCAT device at manufacturing time". A TCAT device supports TLS 1.2 or 1.3; a TCAT Commissioner must support both. TCAT is optional and aimed at commercial installs.

Matter commissioning, step by step

The Matter 1.2 core specification lists seven steps:

Commissioner (phone/hub)                                   Commissionee (new device)
  1. Discover over BLE, Wi-Fi or IP; read passcode from QR code, manual code or NFC
  2. PASE (SPAKE2+ with the passcode) ----------------------> session keys
  3. Device attestation: request DAC + PAI, check chain to a PAA, check DCL
  4. Configure: regulatory info, UTC time, install NOC and trusted root, network creds
  5. Device joins operational network (Thread or Wi-Fi); commissioner finds it via DNS-SD
  6. CASE (SIGMA: Sigma1, Sigma2, Sigma3) -----------------> operational session keys
  7. CommissioningComplete over the CASE session

The pieces:

• Passcode and PASE. The setup passcode is a 27 bit value encoding eight decimal digits, from 00000001 to 99999998. The specification bans trivial values such as 00000000, 11111111 and 12345678. A device with a static passcode must store only the SPAKE2+ verifier where the protocol code can reach it, never the passcode itself. PASE derives the commissioning session keys from the passcode with SPAKE2+, which the specification calls "an efficient augmented PAKE algorithm", and the PBKDF iteration count must stay within the specification's bounds.
• Device attestation. Each device carries a Device Attestation Certificate (DAC) and private key "unique to that Device", chained through a Product Attestation Intermediate (PAI) to a Product Attestation Authority (PAA). The commissioner checks the chain and the CSA Distributed Compliance Ledger (DCL), a signed, publicly readable ledger of certified product models. The CSA FAQ notes the root CAs are operated by Alliance members, not the CSA. If attestation fails, the commissioner tells the user the device is not certified.
• Operational credentials. The commissioner issues a Node Operational Certificate (NOC) for an Operational Node ID inside a fabric, which is a set of nodes sharing a trusted root CA and a Fabric ID. NOCs and fabric data are erased on factory reset or fabric removal.
• CASE. Operational sessions use Certificate Authenticated Session Establishment, built on the SIGMA protocol. A shorter resumption exchange (Sigma2_Resume) is tried first when possible.

Matter message layout and transports

Operational Matter traffic runs over UDP with Matter's Message Reliability Protocol (MRP) or over TCP; Bluetooth LE carries commissioning through the BTP transport. IANA registers port 5540 on both TCP and UDP for "Matter Operational Discovery and Communication", plus DNS-SD service names matterc (commissionable nodes) and matterd (commissioners). The message header in the 1.2 specification:

The crypto suite is fixed: AES-CCM with 128 bit keys for confidentiality and integrity, AES-CTR to hide node identifiers when privacy is on, SHA-256, and ECC on NIST P-256 for signatures and key exchange. "All unicast Node-to-Node messages are secured, authenticated, and provide replay protection," says the specification.

Versions and history

On Zigbee, the CSA says PRO 2023 features "are optional", so a device certified to the newest platform may still ship without them. Zigbee 4.0 is "fully backward compatible with Zigbee 3.0 and Smart Energy", which keeps old devices working and also means old joining behaviour stays reachable unless a hub restricts it.

Thread 1.4 is "fully backward compatible", per the Thread Group FAQ, and its white paper describes compatibility with existing 1.1, 1.2 and 1.3 devices.

The CSA notes that "the path from specification to products in users' hands will vary by company and product type". A hub that runs Matter 1.6 does not mean every device on it does.

Security properties: what each layer does and does not guarantee

First, a shared network key means any device on a Zigbee or Thread network can read and forge network layer traffic. That is why Matter puts its own sessions on top. Second, none of these protocols can stop radio jamming. RFC 4944 also notes that EUI-64 based identifiers have "no protection from duplication through accident or forgery", and that IPv6 Neighbor Discovery and mesh routing bring their own threats on these links.

Weakness classes, explained as concepts

Well known link keys in older Zigbee joining

The default global Trust Center link key is a fixed value printed in the BDB specification, by design, so that any certified device can join any centralized network out of the box. The network key is then sent to the joining device encrypted under that public key. Anyone recording the radio during that join can therefore recover the network key. The specification's mitigation is the key exchange that follows the join, which replaces the initial link key with a unique one. The risk grows when hubs keep permit joining open, allow devices to skip the key exchange, or never require install codes. The touchlink and distributed security keys have public test values for certification, which is why real products use the production values issued on certification.

Insecure commissioning windows

Every one of these protocols has a moment when a device is willing to trust something new. In Zigbee it is permit joining. In Thread it is an active commissioner session or Border Agent. In Matter it is a commissioning window, either the initial one or one opened later by an administrator. Matter bounds this: a commissionable device "SHALL NOT announce for a duration longer than 15 minutes" and not less than three, must exit commissioning after 20 failed attempts, and after the first commissioning "subsequent Commissioning SHALL only be triggered by an Administrator". The weakness class is a window that is longer, more frequent or easier to open than the user realises, combined with a setup code that someone else can read.

Exposed or static setup codes

A Matter passcode on a sticker is a password printed on the device. The specification's best practices say the setup code "SHOULD NOT be photograph-able or visible when installed" where practical, and that devices exposed to physical tampering, such as doorbells, cameras and locks, should keep the commissioning button and code away from an attacker. It also says manufacturers should only implement the Basic Commissioning Method, which reuses the original passcode, for devices that secure that passcode well. The Enhanced Commissioning Method, which is mandatory, has the administrator pick a new random passcode and send only the verifier.

Over privileged admins and bridges

Multi-admin is a feature: several ecosystems can control the same device. It also means several parties hold Administer privilege. The specification warns that Matter access control "does not provide a way to grant privileges to only a single endpoint (Bridged Device)" of a bridge, so anything granted to a bridge is in effect granted to every device behind it. A Zigbee to Matter bridge therefore makes the weaker Zigbee side reachable from the Matter fabric with whatever privileges the bridge holds.

Update integrity

Matter requires nodes to support over the air updates and to "validate the authenticity and integrity of the firmware prior to installation". The OTA cluster says software images "SHALL be signed by a private key used by the Vendor", but the signature format is out of scope and so is how the device gets the signer's public key. The real exposure is in the vendor's process: code signing keys that are not held in an HSM, devices without verified boot, and products whose support period ends. The specification recommends a public vulnerability reporting process and verified boot from an immutable root of trust.

Shared credentials across ecosystems

Thread network credentials grant full membership of the mesh. Before Thread 1.4, sharing them between ecosystems was awkward enough that some setups formed separate networks, which the Thread Group says "could weaken the overall mesh". Credentials Sharing fixes that with a one time key, but it also creates a new administrative action that should be rare and deliberate.

Secure configuration, with defender side check commands

Only run the commands below against hubs, border routers and devices you own or are authorised to administer. They read configuration and state; none of them attack anything.

1. Zigbee: check how your hub admits devices

There is no single standard command line for Zigbee hubs; each hub exposes these settings in its own app or admin page. Using the BDB specification as the checklist, confirm:

• Permit joining is closed except when you are adding a device, and you know how long your hub opens it (the minimum is 180 seconds).
• The hub requires the Trust Center link key exchange after join. The BDB default is TRUE; make sure it has not been relaxed for an old device.
• Install codes are required where your hub and devices support them. The BDB default is not to require them.
• The hub runs current firmware and is certified to a recent Zigbee platform. If it supports Zigbee 4.0 features such as Restricted Mode or Unique Link Key Monitoring, find out whether they are on.
• You have retired devices that only join with the default key and cannot do the key exchange.

2. Thread: inspect an OpenThread Border Router

OpenThread's border router guide says ot-ctl "exposes the OpenThread CLI commands", started with sudo ot-ctl on a native host or docker exec -it otbr ot-ctl in Docker. The command reference documents each of these:

# Start a CLI session on an OpenThread Border Router you administer
sudo ot-ctl

# Inside the session:
state                  # this node's role: leader, router, child, detached, disabled
dataset active -ns     # active dataset with the network key and PSKc redacted
router table           # routers in this partition, with link quality and age
child table            # attached end devices and their timeouts
commissioner state     # active, disabled or petition
ba state               # Border Agent: Disabled, Inactive or Active

Use dataset active -ns rather than dataset active. The OpenThread reference says -ns will "redact the sensitive values, including the network key and PSKc fields". Without it the output contains the network key, which should never be pasted into a ticket or chat. Look for routers and children you do not recognise. Expect commissioner state to be disabled except while you are adding a device. If ba state is Active, an external commissioner with the PSKc can open a DTLS session, so the PSKc's source passphrase needs to be strong and private.

3. Matter: list commissionable devices and check fabrics

The CHIP Tool is the reference controller in the open source Matter SDK (project-chip/connectedhomeip), and its official guide documents these commands:

# Which devices on this network are currently advertising as commissionable?
./chip-tool discover commissionables

# Firmware and identity of a device you have commissioned
./chip-tool basicinformation read vendor-name NODE_ID 0
./chip-tool basicinformation read product-name NODE_ID 0
./chip-tool basicinformation read software-version NODE_ID 0

# List the commands and attributes a cluster supports
./chip-tool operationalcredentials

A device you believe is set up should not appear in discover commissionables unless someone opened a window on purpose. The guide also documents the generic read pattern for any cluster. The Matter specification defines a Fabrics attribute on the Node Operational Credentials cluster that "describes all fabrics to which this Node is commissioned"; reading it shows how many ecosystems administer the device. Remove fabrics you do not use, from the controller that owns each one.

When you share a device with another ecosystem from the CHIP Tool, the guide's pattern is pairing open-commissioning-window with option 1 for the Enhanced Commissioning Method and 0 for the Basic method, plus a timeout in seconds. Prefer option 1 and a short timeout, then confirm the device no longer advertises.

4. Physical and lifecycle hygiene

• Keep Matter and Zigbee setup codes off the outside of installed devices, especially locks, cameras and doorbells. Store them somewhere you control.
• Factory reset devices before you sell or dispose of them. The Matter specification requires reset to remove "all security- and privacy-related data and key material created during or after commissioning".

Where NIST and the US Cyber Trust Mark fit

NIST IR 8425, "Profile of the IoT Core Baseline for Consumer IoT Products" (September 2022), lists the capabilities a consumer IoT product should have: asset identification, product configuration, data protection, interface access control, software update and cybersecurity state awareness, plus the manufacturer side activities of documentation, information and query reception, information dissemination, and product education and awareness. The FCC says its voluntary Cyber Trust Mark program for wireless consumer IoT products "is based largely on criteria established by" NIST, and that a QR code on the label links to a registry of security details. The registry is meant to show details such as "the support period for the product and whether software patches and security updates are automatic". The protocols supply identity, data protection, access control and signed updates; the rest depends on the manufacturer.

Zigbee vs Thread and Matter vs Wi-Fi vs BLE for a new product

The Thread Group describes Matter as built around three technologies: Bluetooth LE for setup, Wi-Fi for high bandwidth uses such as streaming video from a security camera, and Thread for low bandwidth devices such as door locks and motion sensors. That is a sensible default split for a new consumer device. Zigbee remains a sound choice where the ecosystem around the product is already Zigbee. If you choose it, design for install codes or Dynamic Link Key from the start.

Common mistakes

• Treating "it is on the mesh" as authorisation. Every Zigbee and Thread node holds the network key. Network membership proves very little about a device. Matter's per fabric ACLs and CASE sessions are what grant authority.
• Leaving permit joining or a commissioning window open. Hubs and apps often keep these open longer than needed during setup. Close them when you are done and check that devices stop advertising.
• Keeping old Zigbee devices that force insecure joining. If one legacy sensor needs the hub to skip the link key exchange, every later join is weaker. Replace it.
• Printing setup codes where anyone can see them. A Matter QR code on the outside of a door lock is a standing invitation. The specification itself recommends hiding it.
• Assuming Matter certification covers firmware support. Certification covers protocol conformance. Support periods and patch delivery depend on the manufacturer.

FAQ

What is the difference between Zigbee, Thread and Matter?

Zigbee is a complete stack, radio to application, that does not use IP. Thread is an IPv6 mesh network layer with no application layer of its own. Matter is an application layer and security framework over IP that runs on Thread, Wi-Fi or Ethernet.

Does Matter use Zigbee?

No. Matter borrows from the Zigbee Cluster Library for its data model, and Thread uses the same 802.15.4 radio as Zigbee, but the CSA states there is "no native interoperability". Zigbee devices join Matter through a bridge.

What port does Matter use?

IANA registers TCP and UDP port 5540 for Matter operational communication. Discovery uses DNS-SD with the service names matterc and matterd. Commissioning often starts over Bluetooth LE.

Is Thread encrypted?

Yes. The Thread Group says devices are authenticated before joining and the network uses MAC encryption for all messages, keyed by the network key in the active dataset. Applications such as Matter add their own end to end encryption on top.

Is Zigbee secure?

Zigbee uses AES-128-CCM and supports install codes, certificate based key exchange and, since PRO 2023, Dynamic Link Key. How secure a network is depends on the joining mode the hub allows. A network that still accepts the published default link key with joining left open is much weaker than one that requires install codes.

What is a Thread border router?

A function, not a device type, that forwards IPv6 traffic between a Thread mesh and another network such as Wi-Fi or Ethernet. A network can have several. The Thread Group notes that some Wi-Fi access points have it built in.

What are PASE and CASE in Matter?

PASE (Passcode-Authenticated Session Establishment) uses SPAKE2+ and the setup passcode to secure commissioning. CASE (Certificate Authenticated Session Establishment) uses operational certificates and a SIGMA based exchange to secure all later traffic.

What is a Matter Device Attestation Certificate?

A certificate and private key unique to each device, chained through a Product Attestation Intermediate to a Product Attestation Authority. The commissioner checks it, and the CSA Distributed Compliance Ledger, to confirm the device is a genuine certified product.

Can I use Matter devices with more than one smart home app?

Yes. Multi-admin lets a device belong to several fabrics, each with its own administrator. Matter 1.4 added Enhanced Multi-Admin and Matter 1.6 added Joint Fabric. Review which fabrics a device belongs to and remove any you do not use.

Fix it without waiting for upstream

Protocol weaknesses in the smart home rarely live in the radio. They live in software: the Matter SDK built into a hub or companion service, an OpenThread border router image, a Zigbee stack in gateway firmware, or the TLS, DTLS and crypto libraries those depend on. Where you build that software from source or ship it in container images, Safeguard's software composition analysis, generally available, inventories those components with their full transitive dependencies, alongside SBOM generation in SPDX and CycloneDX and container image scanning; findings are enriched with EPSS and CISA KEV data and ranked with reachability analysis, all generally available. Safeguard does not inspect, filter or block Zigbee, Thread or Matter traffic.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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 radio or smart home traffic monitoring. 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 then scans from the terminal. Pointed at the container image for a border router or hub service you build, or at the repository for a device's companion backend, the same scan lists the open source components inside with their versions and any known vulnerabilities.

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

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a crypto or protocol library pinned in a hub service's manifest.

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. Once connected, you can ask in plain language which of your projects include a particular library version, 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

• IEEE SA: IEEE 802.15.4-2024, Standard for Low-Rate Wireless Networks
• RFC 4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks, September 2007
• RFC 6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks, September 2011
• IANA: Service Name and Transport Protocol Port Number Registry
• CSA: Zigbee
• CSA: Zigbee FAQ
• CSA: PRO Base Device Behavior Specification v3.0.1, 28 September 2021
• CSA: Zigbee Security and Privacy Fundamentals
• CSA: Zigbee PRO 2023 improves overall security while simplifying experience, 12 April 2023
• CSA: Zigbee 4.0 and Suzi announcement, 18 November 2025
• CSA: Matter
• CSA: Matter FAQ
• CSA: Matter Specification Version 1.0, 28 September 2022
• CSA: Matter Specification Version 1.2, 18 October 2023
• CSA: Matter Security and Privacy Fundamentals, March 2022
• CSA: Matter 1.6 announcement, 17 June 2026
• CSA: Distributed Compliance Ledger
• CSA: Product Security Certification
• Thread Group: What is Thread
• Thread Group: Support, specifications and FAQ
• Thread Group: Thread 1.4 Features White Paper, September 2024
• OpenThread: Node roles and types
• OpenThread: IPv6 addressing
• OpenThread: External commissioning
• OpenThread: Form a Thread network with the border router (ot-ctl)
• OpenThread: CLI command reference
• project-chip/connectedhomeip: CHIP Tool guide
• NIST IR 8425: Profile of the IoT Core Baseline for Consumer IoT Products, September 2022
• FCC: Cyber Trust Mark

Last reviewed: 23 October 2026. Hub settings, Matter releases and Zigbee platform features change often; check the documentation for the hub, border router and SDK version you run.