For most of the smart home’s history, buying a light bulb meant picking a side. A Zigbee bulb needed a Zigbee hub, a Wi-Fi plug needed its maker’s cloud, and the voice assistant in the kitchen only talked to products on its own certification list. Matter is the industry’s attempt to end that fragmentation with a single application-layer standard that any controller can speak.
Matter is published by the Connectivity Standards Alliance (the group that also stewards Zigbee), with Apple, Google, Amazon, Samsung and hundreds of device makers as members. Version 1.0 was released in late 2022, and the specification has been updated roughly twice a year since, each release adding device types and features.
This guide explains what Matter actually standardizes, how a device joins a home, what happens when several ecosystems control the same device, and which limits you should know before building or buying around it.
What Matter standardizes, and what it does not
Matter is an application-layer protocol. It defines a data model (how a light, a lock or a thermostat describes itself), an interaction model (how a controller reads, writes and subscribes to that data), and the security and onboarding procedures around them. It does not define a new radio.
Instead, Matter runs over IPv6 on three transports: Wi-Fi, Ethernet, and Thread, the low-power mesh built on IEEE 802.15.4. Bluetooth Low Energy is used only during setup, to pass the device its Wi-Fi or Thread credentials. Because every Matter device is an IP node, a controller can reach a Thread bulb through a border router exactly as it reaches a Wi-Fi plug: same messages, same security, different link.
That design is why Matter is often described as “the application layer Zigbee never had on IP.” Zigbee defined both the radio stack and the application profiles; Matter borrows the cluster idea from Zigbee’s data model and leaves the radio to existing IP-capable links.
The data model: endpoints, clusters and attributes
A Matter device is a tree. The root is the node; below it are endpoints, each representing one logical function. A two-gang switch exposes two endpoints, a bridge exposes one per bridged device. Each endpoint implements a device type (On/Off Light, Door Lock, Temperature Sensor, and so on) that mandates a set of clusters.
A cluster groups related attributes, commands and events. The On/Off cluster has an OnOff attribute and On, Off and Toggle commands. The Level Control cluster handles brightness. The Thermostat cluster carries setpoints and modes. Because clusters are standardized, a controller that has never seen a particular vendor’s product can still drive it correctly as long as it knows the device type.
Controllers interact with this model through reads, writes, invokes and subscriptions. Subscriptions matter most for responsiveness: instead of polling, a controller asks the device to report attribute changes within a minimum and maximum interval, which is how a dashboard shows a light turning on within a fraction of a second.
Commissioning: how a device joins a home
Onboarding in Matter is called commissioning. The user scans a QR code or types an 11-digit code printed on the device. That code carries a discriminator (to find the right device among several advertising ones) and a passcode used in a password-authenticated key exchange, so the setup channel is encrypted even over open BLE.
During commissioning the controller verifies the device’s attestation certificate, which chains to the manufacturer and ultimately to the CSA’s distributed ledger of certified products. This is the step that proves the device is a genuine certified unit rather than a clone. The controller then issues the device an operational certificate for the home’s fabric, hands over network credentials, and the device joins Wi-Fi or Thread as a full member.
The passcode is only ever used once per commissioning window; after that, every exchange is protected by the operational certificates and session keys, which is a cleaner story than many earlier smart home protocols that leaked keys during pairing.
Fabrics and multi-admin
A fabric is a security domain: one set of certificates, one administrator root. A home running Apple Home has one fabric; the same home’s Google Home has another. Matter’s multi-admin feature lets a single device belong to several fabrics at the same time. After the first commissioning, the owner can open a new commissioning window from the first app and add the device to a second ecosystem without factory-resetting it.
This is a genuine improvement for households that mix platforms, but it has limits. Each device supports a fixed number of fabrics, and automations, scenes and room assignments remain local to each ecosystem. Multi-admin shares control of the device, not the configuration around it.
Bridges and the legacy question
Nobody is going to throw away working Zigbee or Z-Wave gear. Matter handles this with bridges: a bridge is a Matter node that exposes non-Matter devices as endpoints. A Zigbee hub with a Matter bridge function presents each paired bulb as a Matter light, so an Apple or Google controller sees them natively. Bridging is also how open-source hubs such as Home Assistant can surface hundreds of integrations to a Matter controller.
Bridged devices get the standard clusters, but they do not get Matter’s end-to-end security on the legacy leg. Security stops at the bridge; the radio behind it keeps whatever protection it had before.
Where Matter still falls short
Device type coverage is the first thing to check. Lighting, plugs, locks, thermostats, sensors, blinds and media devices arrived early; appliances, robot vacuums, energy devices and cameras came later, and some categories are still waiting for a specification or for ecosystems to implement one. A product can be Matter-certified yet expose only a basic subset of what its own app offers, because the vendor-specific features have no cluster.
Thread deployments depend on border router quality and on ecosystems sharing Thread credentials, which has been uneven. Debugging commissioning failures is hard for consumers, since the error surfaces are generic. And Matter does not solve cloud dependence by itself: local control is possible and common, but a vendor can still require its own account for firmware updates or extra features.
When to choose Matter
Use Matter when you sell into homes with mixed ecosystems and want one certification path instead of four. Use it when local, low-latency control matters. Look elsewhere, or add a proprietary channel, when your product needs features the data model does not cover yet, or when you need battery-powered mesh for something Thread is not suited to, such as long-range outdoor sensing where LoRaWAN fits better.
Where to go next
- Thread explained covers the low-power mesh most Matter sensors run on.
- Zigbee explained shows where Matter’s data model came from and how the two coexist.
- The smart home, explained puts Matter in the context of ecosystems, hubs and privacy.
- AI agents for the smart home looks at what a standardized data model makes possible for assistants.
Topics: Matter, smart home, Thread, Connectivity Standards Alliance, interoperability