Matter: A Unified Approach to IoT Device Development

Interoperability: Devices from different brands work together seamlessly.

Simplicity: Easier setup and use for consumers.

Local reliability: Works primarily over the local network (less cloud dependence).

Security: Built-in, strong security by design.

IP-based: Runs on standard IP (Wi-Fi, Ethernet, Thread), simplifying development and scaling.

Camera support: Standardized smart cameras with live video, audio, and controls

Expanded closures: Better support for doors, garage doors, shades, gates

Energy management: Grid signals, pricing, and energy-aware device control

New sensors: Soil moisture sensors for irrigation and gardening

Improved transport: TCP and large data support for video and updates.

Learn more about the Matter 1.5 spec.

Matter improves smart home interoperability by providing a single, IP-based standard that allows devices from different brands and ecosystems to work together seamlessly. It ensures consistent device behavior, secure commissioning, and local communication across platforms like Apple, Google, Amazon, and Samsung, reducing fragmentation and simplifying both development and user experience.

The future of Matter in smart home technology is continued expansion into more device categories, richer features, and deeper energy management, while strengthening security and reliability. As adoption grows across major ecosystems, Matter is expected to become the default smart home standard, simplifying development, reducing fragmentation, and enabling more seamless, intelligent, and scalable smart home experiences.

Silicon Labs has created the Matter Developer Journey, which is a web-based tool that helps guide you through getting started, development, and even deploying your Matter product. It also includes information along the way for the key Matter ecosystems.

Silicon Labs has a Matter Selector Guide to help you select the best technology and device for your product. With guidance on which technology, Matter-over-Wi-Fi or Matter-over-Thread, is best for different applications and device types, and comparison tables of our offerings, our Matter Selector Guide will speed your decision-making when developing your Matter products.

There is no inherent limit on the number of devices that the Matter standard supports in a single fabric.

No, users will not pay a royalty for software. The Matter stack software will be released under a permissive license, and the Connectivity Standards Alliance (CSA) has RANDZ licensing from its members.

Matter makes use of UDP messages with retries to provide reliability. This is known as the Message Reliability Protocol (MRP) and is provided by the Matter stack.

Yes. Matter requires devices be fully authenticated and authorized before joining the network and to make use of industry best practices for security establishment and encryption before and after joining the fabric. Matter requires a commissioner to obtain a device-specific passcode that is used as a shared secret during a Password Authenticated Session Establishment (PASE) to first communicate with the joining device. The commissioner also checks the device’s manufacturer-specific credentials to verify the authenticity of the device to ensure it is an official product, and checks the device against a Distributed Compliance Ledger (DCL) to verify it is an officially certified device. The device generates unique credentials that are signed by the commissioner for use as an operational certificate and then used to establish future communications with valid Matter devices on the same fabric. Lastly, Matter makes use of Access Control Lists (ACLs) to determine what devices on the same fabric are allowed to communicate with one another.

PSA Crypto APIs are provided by ARM. We integrate them on our hardware to manage keys in the most secure way.

Operational certificates are generated per fabric when the Matter device joins. A device will generate a public/private key pair and send a CSR (Certificate Signing Request) to the commissioner to be signed and returned. If you use Silicon Labs' Secure Vault enabled parts generate and store the private key internally, which greatly reduces the chance an attacker can gain access to that private key.

Silicon Labs Matter chips have the flexibility to support injecting pre-generated DACs during manufacturing or by having the device generate its own Public/Private Key pair on-chip that a manufacturer can sign, and thus avoid having the private key ever leave the device. The choice of which method to use is up to the manufacturer based on the logistics and needs of their manufacturing process. Furthermore, Silicon Labs has a Custom Part Manufacturing Service (CPMS) thatcan securely provision devices with Matter security material along with a device manufacturer’s own material to make the manufacturing process secure and easier to deploy Matter-enabled products.

Silicon Labs supports all released Matter device types, either directly in sample applications or by enabling support through ZAP. You can refer to the Matter SDK extension in Simplicity Studio for a list of supported device types. As for upcoming Matter device schedules from the CSA, you would need to join the CSA Working Groups to be a part of the discussion on new device type spec additions. A full list of existing devices can be found in the Matter Device Type spec from the CSA. The CSA updates the Matter specification twice a year, so this provides plenty of opportunities to quickly add new features and devices to the standard.

Matter has bridges as a native device type, so non-IPv6 networks can be incorporated into the Matter fabric via the bridge. Examples of these include Zigbee to Matter and Z-Wave to Matter bridges that allow those existing networks to be controlled by the Matter fabric. Learn more about Matter bridges.

Yes, Z-Wave to Matter bridges exist, but Matter does not natively support Z-Wave. Interoperability is achieved through hub-based bridges that translate Z-Wave devices into Matter devices. Examples include hubs from SmartThings, Home Assistant, and other gateway vendors, where Z-Wave devices appear as Matter devices to Matter ecosystems.

A Matter Compliant Platform (MCP) is a development environment - SDK plus hardware - that has been formally certified by the Connectivity Standards Alliance (CSA) for core Matter functionality. MCPs provide device makers with a certified foundation, including pre-tested commissioning, networking, and security features. By building on an MCP, manufacturers inherit these validated components, which reduces certification scope, lowers cost, accelerates time-to-market, and simplifies future recertification. Matter Compliant Platforms are essential because they ensure trust, interoperability, and faster innovation across the Matter ecosystem.

Silicon Labs helps certify a new Matter product by providing Matter-certified hardware platforms, production-ready SDKs, and pre-tested software stacks that align with CSA requirements. They also support developers with reference designs, compliance tools, interoperability testing guidance, and ecosystem expertise, helping reduce risk, speed up development, and streamline the Matter certification process.

This is called Multi-admin or Multi-fabric in Matter. This is a required function in the current Matter spec and implementation to allow for a device to be controlled by multiple ecosystems. There is ongoing work in the CSA working groups to improve the user experience for multiple admin scenarios.

This is permitted by the Matter Standard. It ultimately depends on the device’s capabilities, such as available Flash, RAM, and some other logistics (such as how the manufacturer can convey the Matter QR Code so it can be commissioned, when the product has already been shipped without one). We already see examples of this for deployed devices in the field for Matter-over-Thread and Matter-over-Wi-Fi. In addition, many hubs (Zigbee for example) are being upgraded in the field to bridge their non-Matter devices to Matter and they use their own mobile apps to facilitate that.

It is possible to design a product outside the list of specified Matter device types, or extend an existing device type, but that would only work if you are building both the controller and the end device sides. The new device type or feature wouldn’t work with the other released controllers due to proprietary devices and features from existing ecosystems.

A border router is a device defined by the Thread protocol that routes IP traffic from the Thread network to other IP networks like Wi-Fi or ethernet. This is different from a typical IoT gateway because it does not stop the traffic and translate at the application level, it simply takes the Thread packet and IP address and puts it into the other IP network format to seamlessly pass the packet through. Learn more about OTBRs.

Ecosystems like Google Home, Apple Home, Samsung SmartThings, and Amazon Alexa are ready to develop Matter devices today. They provide platforms and guides to build and test. If you use our Dev Kit with your own Matter sample apps, or use one of our many Matter sample apps that are provided in the Matter SDK in Simplicity Studio, then you can use a device like the Nest Hub and the Google Home app to test and control. Our Matter Developer Journey can help.

Devices that are upgraded in the field to Matter would need a means to install a DAC onto the device, as well as install the Matter Passcode. This could be done in a couple of different ways, though this is outside the Matter specification. Two examples: a device could use a manufacturer’s own mobile App via Bluetooth LE, or the device could reach out to a manufacturer’s cloud service to securely generate or download the DAC and private key.

Yes, devices that meet security requirements and have sufficient resources available can be OTA updated to Matter. We already see examples of this for deployed devices in the field for both Thread and Wi-Fi devices that can be upgraded to support Matter.

Silicon Labs supports field upgrade of manufacturing certificates if using our Provisioner Firmware component included embedded within the Production Firmware. The specific details of how certificates are conveyed to the Matter device are not standardized within CSA and thus would be up to the manufacturer to manage. In other words, they would have to handle the communication mechanism to transfer the certificates to the device (Bluetooth LE, IP, etc.) and the generation of the unique data for each device (certificate, passcode, and discriminator).

Yes, Silicon Labs products fully support Matter clusters through their Matter-ready wireless SoCs and SDKs. Silicon Labs’ Matter software stack implements the standard Matter clusters and device types, enabling developers to build, customize, and certify interoperable Matter devices across Thread, Wi-Fi, and Ethernet platforms.

The main challenges with cross-fabric Matter communication include managing multiple fabrics securely, synchronizing device state across ecosystems, and handling differing platform policies and feature support. Devices must maintain separate credentials and access controls per fabric, which increases complexity, memory usage, and testing effort while ensuring consistent behavior across Apple, Google, Amazon, and other Matter fabrics.

The main challenges with Matter’s multi-admin include managing multiple fabrics and credentials, higher memory and storage requirements on devices, and increased complexity in access control and state consistency. Supporting multiple administrators also adds commissioning, testing, and user-experience complexity, especially when different ecosystems expose or handle features differently.

Matter-over-Thread generally provides equal or better battery life than Zigbee. Thread is designed for low-power, IP-based networking with efficient sleep modes and optimized routing, while Matter adds minimal overhead on top. In practice, battery life depends more on device design and usage, but Thread is typically better suited for long-lived, battery-powered Matter devices.