Matter 1.3 Protocol Overview: Architecture, Device Types and Commissioning Flow
Matter is an application-layer protocol standardised by the Connectivity Standards Alliance (CSA) that runs natively over IPv6 on Thread, Wi-Fi and Ethernet — giving smart building devices a single, secure, vendor-interoperable communication model without gateway translation. Matter 1.3 expanded the device type library to include energy reporting, microwave ovens and water valves; the core architecture, data model and commissioning flow described here apply from Matter 1.0 onwards.
Protocol stack and transport layers
Matter sits at the application layer and is transport-agnostic: the same Matter message can travel over a Thread mesh (UDP/IPv6 over IEEE 802.15.4), a Wi-Fi network (UDP/IPv6 over 802.11), or a wired Ethernet segment. Bluetooth Low Energy (BLE) is used exclusively for the initial commissioning step — it is not used for ongoing device communication. The core transport is UDP with CASE (Certificate-Authenticated Session Establishment) providing session security at the application layer.
| Layer | Protocol | Notes |
|---|---|---|
| Application | Matter (CSA spec) | Clusters, attributes, commands, events |
| Session security | CASE / PASE | Certificate-based session establishment; PASE for commissioning only |
| Transport | UDP (MRP — Message Reliability Protocol) | Retransmission, duplicate detection, acknowledgement |
| Network | IPv6 | Thread: 6LoWPAN compression; Wi-Fi/Ethernet: native IPv6 |
| Data link (Thread) | IEEE 802.15.4 2.4 GHz | 250 kbit/s, 2 km LOS range, AES-128 MAC security |
| Data link (Wi-Fi) | IEEE 802.11 2.4 / 5 GHz | Standard Wi-Fi; no special Matter AP firmware required |
| Commissioning only | Bluetooth LE | Used for QR code onboarding; not used post-commission |
Thread vs Wi-Fi choice for building sensors: Thread devices are typically battery-operated (Sleepy End Devices) and benefit from the mesh self-healing and low-power MAC layer. Wi-Fi Matter devices are mains-powered and connect directly to existing Wi-Fi infrastructure. In commercial buildings, Thread is preferred for sensor and actuator density; Wi-Fi for high-bandwidth or fixed devices such as thermostats and displays.
Device types
Matter defines device types in the CSA Device Library specification. Each device type specifies which clusters are mandatory and which are optional. A Matter commissioner (Apple Home, Google Home, Amazon Alexa, Home Assistant) uses the device type to present the correct UI and accept the correct control commands.
| Device type | Device type ID | Mandatory clusters |
|---|---|---|
| On/Off Light | 0x0100 | OnOff, Identify, Groups |
| Dimmable Light | 0x0101 | OnOff, LevelControl, Identify, Groups |
| Color Temperature Light | 0x010C | OnOff, LevelControl, ColorControl (CT mode) |
| On/Off Plug-in Unit | 0x010A | OnOff, Identify |
| Thermostat | 0x0301 | Thermostat, Identify, TemperatureMeasurement |
| Window Covering | 0x0202 | WindowCovering, Identify |
| Door Lock | 0x000A | DoorLock, Identify |
| Contact Sensor | 0x0015 | BooleanState, Identify |
| Occupancy Sensor | 0x0107 | OccupancySensing, Identify |
| Temperature Sensor | 0x0302 | TemperatureMeasurement, Identify |
| Bridge | 0x000E | BridgedDeviceBasicInformation on each bridged endpoint |
| Energy EVSE (1.2+) | 0x050C | EnergyEVSE, PowerTopology |
Data model: clusters, attributes and commands
The Matter data model is the functional equivalent of KNX group objects and data point types. A Matter node (physical device) contains one or moreendpoints; each endpoint implements one or more clusters. A cluster bundles related attributes (readable state), commands(writable actions) and events (asynchronous notifications) into a versioned specification unit. The CSA assigns numeric IDs to all standard clusters; vendor clusters use IDs in the 0xFC00–0xFFFE range.
Matter data model hierarchy
Node (physical device, one IPv6 address)
└── Endpoint 0 (Root Node — always present)
│ └── BasicInformation cluster (vendor, model, serial, firmware)
│ └── GeneralCommissioning cluster
│ └── OperationalCredentials cluster (fabric membership, NOC)
└── Endpoint 1 (primary device function)
│ └── OnOff cluster (0x0006)
│ Attribute: OnOff (bool) — current on/off state
│ Command: On (0x01), Off (0x00), Toggle (0x02)
│ └── LevelControl cluster (0x0008)
│ Attribute: CurrentLevel (uint8, 0–254) — brightness
│ Command: MoveToLevel, Move, Step, MoveToLevelWithOnOff
└── Endpoint 2 (secondary function, e.g. colour)
└── ColorControl cluster (0x0300)
Attribute: CurrentHue, CurrentSaturation, ColorTemperatureMireds
Command: MoveToHue, MoveToSaturation, MoveToColorTemperatureKNX equivalence: A Matter cluster maps closely to a KNX functional block. A cluster attribute is analogous to a KNX group object with a defined DPT. A Matter command is analogous to writing a KNX group address. The key difference: Matter attributes are read directly from the device node (unicast), whereas KNX group objects use broadcast. This makes Matter significantly more scalable for large sensor deployments.
Commissioning flow
Matter commissioning is the process of adding a device to a fabric (a logical trust domain) controlled by a commissioner (Apple Home, Google Home, etc.). The process uses BLE for the initial out-of-box connection, PASE (Password-Authenticated Session Establishment) for the first encrypted channel, and CASE for all subsequent sessions.
Matter commissioning sequence
Step 1 — Discovery Commissioner (phone app) scans QR code or taps NFC tag on device QR code encodes: discriminator (12-bit), setup PIN (27-bit), vendor ID, product ID, device type, commissioning flow flags Step 2 — BLE connection (for most devices) Commissioner connects to device via BLE Alternative: devices already on IP network use DNS-SD discovery Step 3 — PASE session Commissioner and device establish PASE using the setup PIN from QR code PASE uses SPAKE2+ protocol (SRP variant) — PIN never transmitted Encrypted channel established over BLE (or UDP for IP-only devices) Step 4 — Device Attestation verification Commissioner requests Attestation Information from device: - Device Attestation Certificate (DAC) — device-unique leaf cert - Product Attestation Intermediate (PAI) — manufacturer intermediate CA - Certified Declaration (CD) — CSA certification assertion Commissioner validates: DAC → PAI → PAA (Product Attestation Authority) PAA root certs are distributed with commissioner firmware If DAC chain invalid: commissioning REJECTED Step 5 — Network provisioning (Thread devices) Commissioner sends Thread Operational Dataset (OTDS) to device OTDS contains: network name, channel, PAN ID, master key, extended PAN ID Device joins Thread mesh using OTDS Step 6 — Node Operational Certificate (NOC) issuance Commissioner's fabric CA issues NOC to device (unique per fabric) NOC encodes: Node ID (64-bit), Fabric ID (64-bit), device public key Device stores NOC in secure storage (hardware-protected if available) CASE sessions use NOC for mutual authentication going forward Step 7 — Device added to fabric Commissioner stores ACL (Access Control List) on device ACL defines which fabric members can read/write which clusters Device appears in commissioner app with correct device type UI
Multi-admin: multiple ecosystems on one device
Matter’s fabric model allows a single device to be simultaneously commissioned into multiple independent fabrics — for example, the same door lock can be added to both Apple Home and Google Home without either ecosystem needing to trust the other. Each fabric has its own Fabric ID, its own NOC for the device, and its own ACL entries. This is fundamentally different from Zigbee or Z-Wave where a device can only belong to one coordinator at a time.
| Multi-admin aspect | Detail |
|---|---|
| Max fabrics per device | Minimum 5, typically 16 (device-specific, check datasheet) |
| Fabric isolation | Each fabric has independent NOC, ACL and session keys — no cross-fabric data sharing |
| Adding second fabric | Open Commissioning Window (OCW) on device from first fabric, then commission from second ecosystem |
| OCW method | Enhanced Commissioning Window with 180-second window; uses PASE with one-time PIN |
| Removing a fabric | Each commissioner can independently remove itself; does not affect other fabrics |
| Attribute state | Shared — OnOff state is single source of truth read by all fabrics |
Device Attestation Certificate chain
Every Matter device must carry a Device Attestation Certificate (DAC) provisioned at the factory. The DAC chain proves the device is a genuine, CSA-certified product from a specific manufacturer. A commissioner that cannot verify the full chain to a trusted PAA root must refuse commissioning — this prevents counterfeit or uncertified devices from joining a Matter fabric.
DAC trust chain
PAA (Product Attestation Authority) Root CA operated by CSA or major ecosystems (Apple, Google) PAA certs embedded in commissioner firmware CSA maintains PAA registry (publicly accessible) PAI (Product Attestation Intermediate) Issued by PAA to manufacturer One PAI per product family or manufacturing batch Stored on device, sent to commissioner during attestation DAC (Device Attestation Certificate) Issued by manufacturer's PAI CA to individual device at factory Contains: device public key (unique key pair per device) Contains: Vendor ID (VID) + Product ID (PID) matching the device Private key stored in secure storage on device — never exported DAC serial number provides revocation capability (future CRL) Certified Declaration (CD) Signed by CSA, attests product passed Matter certification testing Contains: VID, PID list, device type IDs, certification ID Embedded in device firmware as a CBOR-encoded blob
Development vs production devices: Matter SDK development builds use test PAA certificates that are NOT trusted by production commissioners (Apple Home, Google Home). Devices built with the test DAC chain will fail attestation on production ecosystems. Only devices with a valid production DAC from the CSA-registered PAA trust chain can be commissioned on consumer and commercial systems.
Matter vs Zigbee vs Z-Wave comparison
For building automation engineers evaluating protocol selection, the key differences between Matter, Zigbee and Z-Wave determine suitability for specific installation types, device densities and integration requirements.
| Attribute | Matter + Thread | Zigbee 3.0 | Z-Wave LR |
|---|---|---|---|
| Standard body | CSA (formerly Zigbee Alliance) | CSA | Silicon Labs / Z-Wave Alliance |
| Radio / PHY | IEEE 802.15.4 2.4 GHz | IEEE 802.15.4 2.4 GHz | 868/908/916 MHz sub-GHz |
| Network layer | IPv6 (6LoWPAN) | Proprietary mesh | Proprietary mesh |
| IP-native | Yes — end-to-end IPv6 | No — requires coordinator translation | No — requires hub translation |
| Max range (mesh hop) | ~10 m indoor per hop, unlimited hops | ~10 m per hop, 20+ hops | LR: ~300 m LOS, mesh 4 hops |
| Max nodes (network) | Thread: 250+ per Border Router | ~200 per coordinator | Z-Wave LR: ~4000 |
| Multi-admin | Yes — up to 16 fabrics per device | No — one coordinator per device | No — one controller |
| Wi-Fi support | Yes (same Matter app layer) | No | No |
| Ecosystem support | Apple, Google, Amazon, Samsung | Philips Hue, IKEA, Aqara, others | Fibaro, Ring, Aeotec, others |
| Commissioning | QR / NFC → BLE → CASE | Touchlink / Network steering | SmartStart QR |
| Security | CASE (TLS-like), DAC attestation, ACL | AES-128 CCM, trust center | S2 (AES-128-CCM + ECDH) |
| KNX bridge support | Yes — Matter Bridge device type | Via Zigbee2MQTT + KNX plugin | Via Z-Wave JS + custom bridge |
Need Matter devices commissioned in your building project?
We design and commission Matter-based smart building systems — Thread mesh planning, multi-fabric commissioning across Apple Home and Google Home, KNX bridge integration and full attestation-verified device onboarding with project documentation.
Request a quote →