Matter Protocol 2.0 Smart Home Architecture: Deep Dive (2026)

Last Updated: 2026-05-16

Architecture at a glance

Matter Protocol 2.0 Smart Home Architecture: Deep Dive (2026) — diagram — Matter Protocol 2.0 Smart Home Architecture: Deep Dive (2026)

Matter was promised in 2019 as the universal smart-home language that would make Apple HomeKit, Google Home, Amazon Alexa, and Samsung SmartThings finally talk to the same physical bulb. Four years and five point releases later, that promise has partially landed — and the parts that haven’t are exactly the parts worth understanding before you architect a home, a building, or a product on top of it. This deep dive walks through the Matter protocol 2.0 architecture layer by layer: the cluster library at the top, the IPv6 transports underneath, fabrics and Multi-Admin in the middle, plus the security handshakes (PASE, CASE, Device Attestation) that hold the whole thing together. We will close with a production reference architecture for a multi-floor home, the honest trade-offs that still bite in 2026, and the specific recommendations I give clients building Matter-native products today.

Matter Protocol: From 1.0 (2022) to 2.0 (2025) — What Actually Changed

Matter is not a single specification handed down in 2022 and frozen. It is a versioned, application-layer protocol governed by the Connectivity Standards Alliance (CSA, formerly the Zigbee Alliance), with a public reference implementation living at github.com/project-chip/connectedhomeip. Understanding the version history matters because device certifications, ecosystem support, and bug fixes all reference specific Matter versions — and in 2026 you will routinely encounter all five releases on the same network.

Matter 1.0 shipped on October 4, 2022, after multiple delays from the original 2021 target. Version 1.0 covered the obvious starter pack: lighting (on/off, dimming, color), thermostats, door locks, contact and motion sensors, window coverings, smart plugs, and bridges (for translating Zigbee or Z-Wave devices into Matter). That last category — bridges — is what allowed Philips Hue, Aqara, and SmartThings hubs to expose pre-Matter devices into Matter fabrics without re-flashing firmware on every bulb.

Matter 1.1 (May 2023) was a maintenance release: tightened the certification rules, improved support for battery-powered sleepy devices, and resolved interoperability gaps surfaced in the first wave of certified products. No new device types.

Matter 1.2 (October 2023) added nine new device categories: refrigerators, room air conditioners, dishwashers, laundry washers, robotic vacuums, smoke and CO alarms, air quality sensors, air purifiers, and fans. This was the first release that pushed Matter beyond the “lights and locks” ceiling.

Matter 1.3 (May 2024) was the energy release. EV chargers, energy management clusters, water leak/freeze sensors, and the first formal Energy Management device type landed here. The CSA framing was deliberate — Matter pivoting from convenience automation to home-energy infrastructure.

Matter 1.4 (November 2024) doubled down: enhanced battery and solar inverter support, heat-pump device types, expanded EV-charging modes, and Thread credential-sharing improvements that made multi-router Thread networks far less painful. 1.4 also introduced Enhanced Multi-Admin workflows and the first hooks for what would become Matter Casting.

Matter 2.0 specification work began in 2025 and is the foundation for what most 2026 devices ship against. The headline changes are NFC commissioning (tap-to-pair, finally), formalized Eco mode for energy-aware orchestration, Matter Casting for sending media between devices, simpler Multi-Admin re-sharing flows (the original Multi-Admin UX was so painful most users never used it), and battery-life optimizations for sleepy end devices.

The honest part: even by 2026, Matter rollout has been bumpier than the marketing suggested. Through 2023-24 users reported devices that paired with Apple Home but not Google, Thread border routers that silently lost neighbours, and commissioning failures that required factory resets. Most of those issues were ecosystem-side (Apple, Google, Amazon stacks each had their own bugs) rather than spec-side, but the user-perceived reliability gap was real. Matter 1.4 and 2.0 close most of it.

Architecture Layers: From Cluster to Network

Matter is layered, and the layers map cleanly onto OSI-style thinking. From the device firmware’s point of view, you write code against the top layer (clusters), and Matter handles everything underneath. From a network architect’s point of view, you mostly care about the bottom layers (IPv6 transport choices and security sessions). Both views are valid and you need both.

Cluster Library

A cluster is a reusable bundle of attributes, commands, and events that describes one capability — OnOff, LevelControl, ColorControl, Thermostat, DoorLock, WindowCovering, EnergyEvse. Clusters are the unit of interoperability: every certified Matter light that claims LevelControl exposes the same currentLevel attribute and the same MoveToLevel command with the same arguments. The cluster library is the part of Matter that prevents vendor-specific dialects of “set brightness.”

Clusters are inherited from the Zigbee Cluster Library (ZCL) — Matter is, in a real sense, ZCL ported onto IPv6 with modern security. That heritage explains both its strengths (battle-tested semantics for lighting, HVAC, locks) and its limitations (cluster definitions are committee-driven, slow to evolve, and biased toward residential use cases).

Data Model

The Data Model layer organizes clusters into a hierarchy: a Node (the device’s identity on a fabric) contains one or more Endpoints, each Endpoint hosts a set of Clusters, and each Cluster carries Attributes (state), Commands (actions), and Events (notifications). A smart plug with energy monitoring is one node, one endpoint, three clusters: OnOff, ElectricalMeasurement, and Identify. A multi-gang switch is one node with one endpoint per gang.

The data model is also what makes Matter introspectable. A controller can walk a freshly-commissioned device, read its Descriptor Cluster, and discover exactly what it can do — no app-store download, no vendor SDK, no manual driver matching.

Interaction Model

The Interaction Model defines how controllers and devices talk: Read, Write, Invoke (command), Subscribe, and Report. Subscribe/Report is the bit that makes Matter feel responsive — a controller subscribes to OnOff.onOff with a max reporting interval of, say, 60 seconds, and the device pushes updates immediately on change and at least once per interval. No polling, no busy loops.

Subscriptions are also fabric-scoped, which becomes important when you have three ecosystems (Apple, Google, Samsung) all subscribed to the same physical sensor — each fabric gets its own subscription and its own delivery guarantees.

Transport and Security Session

Above the network layer, Matter frames messages over UDP with the Message Reliability Protocol (MRP) for retransmissions, ordering, and duplicate detection. Matter 1.4 added optional TCP transport for large transfers (firmware updates, particularly). Inside the framing, every message after commissioning runs over a CASE (Certificate Authenticated Session Establishment) encrypted session — devices are not addressable in cleartext on the LAN.

Network Layer: IPv6 over Thread or Wi-Fi

This is the line in the sand: Matter is IPv6-only. Devices get an IPv6 address either over Thread (an 802.15.4 mesh) or over Wi-Fi (any modern flavour — 4, 5, 6, 6E, 7). BLE is supported but only as a commissioning channel — a fresh-from-the-box device advertises a commissionable BLE service, the controller pairs over BLE, hands over Wi-Fi credentials or Thread network credentials, and the device drops BLE and joins the operational network. There is no “Matter over BLE” steady state.

This IPv6 commitment is non-negotiable for Matter, and it is one reason corporate networks still trip over Matter deployments — IPv6 must be enabled, mDNS must be allowed on the LAN, and Thread border routers need IPv6 routing to function. We will return to that in the reference architecture section.

Thread vs Wi-Fi: When Matter Picks Each

The first architectural decision when designing a Matter network is per-device: does this thing talk Wi-Fi or Thread? The marketing answer is “Matter abstracts that away.” The engineering answer is “no it does not, and you will care.”

Thread: 802.15.4 Mesh for Low-Power Devices

Thread is a low-power, low-bandwidth, self-healing IPv6 mesh built on 802.15.4 — the same physical layer Zigbee uses, but with full IPv6 semantics instead of Zigbee’s proprietary network layer. Theoretical throughput is around 250 kbps at the radio, far less at the application layer once mesh overhead is accounted for. Latency from a leaf device to a border router is typically 50-200 ms depending on mesh depth.

What Thread is for: door locks, contact sensors, motion sensors, leaf-and-stem battery devices that wake up briefly, send a few hundred bytes, and sleep for hours. Battery life on a Thread sleepy end device can extend to two or three years on a CR2032, comparable to Zigbee and far better than Wi-Fi.

The catch with Thread is that you need a Thread border router (TBR) on the LAN — a device that bridges between the 802.15.4 mesh and your IPv6 Wi-Fi/Ethernet network. In 2026 the common TBRs are Apple TV 4K (2022 and later), HomePod mini, HomePod 2nd gen, Google Nest Hub Max, Nest Hub (2nd gen), Amazon Echo (4th gen and Echo Hub), Samsung SmartThings Station, and a handful of dedicated TBRs from Eero, Aqara, and Nanoleaf. Without a border router, Thread devices have no path to the rest of your network. This is the single most common failure mode for first-time Matter buyers: they buy a Thread bulb, plug it in, and nothing happens because no Apple TV/HomePod/Nest Hub exists to bridge it.

Thread 1.3 (the version current Matter devices target) supports multiple border routers on the same network, with the routers sharing credentials and offering redundant uplinks. Matter 1.4 made this multi-router story dramatically more reliable by tightening the credential-sharing flow across ecosystems.

Wi-Fi 6 / 6E / 7 for High-Bandwidth Devices

Wi-Fi is the obvious pick for anything that needs throughput or is mains-powered with no battery constraint: cameras, smart TVs, displays, refrigerators, robotic vacuums, hubs, voice assistants. Matter over Wi-Fi runs over standard IPv6 on the same SSID as everything else; there is no separate Matter network. mDNS (multicast DNS-SD) handles discovery, which is why a Wi-Fi network that blocks mDNS will silently break Matter commissioning and operational discovery.

Wi-Fi 6 (and 6E, and now Wi-Fi 7 increasingly shipping in routers in 2026) helps Matter mostly through Target Wake Time (TWT) — battery-powered Wi-Fi sensors can sleep aggressively while staying associated. But for the “battery sensor” use case Thread is still usually a better fit.

BLE: Commissioning Only

Bluetooth Low Energy is used only during the commissioning window, typically lasting 15 minutes by default. The fresh device advertises a Commissionable Node Advertisement, the controller (your phone or the ecosystem hub) connects, performs the PASE handshake, provisions network credentials, and the device joins the operational network. After that, BLE is off (or reused only for re-commissioning if the user resets the device). There is no production data path over BLE in Matter.

Picking Per Device

For every device on your network, the decision flow is: is it battery-powered or low-bandwidth (sensor, lock, switch, bulb)? Use Thread, and make sure a border router exists. Is it high-bandwidth or mains-powered with heavy data (camera, TV, hub, fridge)? Use Wi-Fi. If you have neither and you’re starting from scratch, buy a Thread border router first.

Fabrics are the Matter concept that most directly maps to “who is allowed to control this device.” Get this layer right and three ecosystems will share one bulb gracefully; get it wrong and your spouse will be unable to turn on the kitchen light from her phone because it was commissioned on yours.

What a Fabric Actually Is

A fabric is a security trust domain identified by a 64-bit Fabric ID and rooted in a Root Certificate Authority (Root CA). When you commission a device into Apple Home, Apple’s stack generates an operational certificate (a Node Operational Certificate, or NOC) signed by Apple’s root CA. That NOC is what the device uses for every CASE handshake afterwards. The device’s fabric membership is, technically, the NOC sitting in its non-volatile storage plus the Apple Root CA it trusts for verification.

Each ecosystem runs its own fabric. Apple Home is one fabric (one root CA), Google Home is another, Amazon Alexa another, SmartThings another. Within one ecosystem you can also have multiple fabrics — for instance, a HomeKit “home” in your house is a separate fabric from your parents’ home, even though both use Apple’s root CA.

Multi-Admin: One Device, Multiple Fabrics

Multi-Admin is the Matter feature that lets a single physical device belong to several fabrics simultaneously. A Matter bulb can be commissioned first into Apple Home, then “shared” into Google Home, then “shared” again into SmartThings. The bulb stores three separate NOCs (one per fabric), trusts three separate root CAs, and accepts CASE sessions from any of them. Each ecosystem sees the bulb as a full first-class device and can subscribe, command, and update it independently.

The 2022-23 UX for sharing across fabrics was the part Matter genuinely fumbled. The flow was: open Apple Home, find the device, tap “Turn On Pairing Mode,” get an 11-character setup code, open Google Home, tap “Add Device,” enter the code, wait, hope it works. Half the time the second ecosystem could not discover the device on the local network. Matter 1.4 and 2.0 simplified this significantly with QR-based re-sharing and the new Enhanced Multi-Admin flows.

Fabric Limits and Operational Cost on the Device

Devices have a finite number of fabric slots. The Matter spec mandates a minimum of 5 fabric slots per device, and most current devices ship with 5-16. Each fabric slot stores an NOC, an Intermediate CA (optional), the Root CA, and per-fabric ACL entries — a few kilobytes total. Devices also have a per-fabric operational cost at runtime: each fabric typically maintains its own CASE session and its own subscriptions, so a single sensor in 5 fabrics is doing 5x the work of a single-fabric sensor. For battery-powered devices this matters; for mains-powered devices it does not.

Why Fabrics Matter for Architecture

If you are building a Matter device, fabric capacity is a hardware design constraint — flash size and RAM budget have to accommodate the slot count you commit to. If you are designing a home, fabric strategy determines whether the household can use multiple ecosystems gracefully. The common architecture pattern I recommend is: pick one primary fabric (the one that owns Thread border routing and serves as commissioning authority for new devices), and use Multi-Admin to mirror critical devices into one or two secondary fabrics for redundancy and family-member preference.

Matter Casting and Eco Mode

Two of the headline features Matter 2.0 brings into general availability deserve their own section because they push Matter from “device control” into territory previously owned by AirPlay, Chromecast, and bespoke cloud orchestration.

Matter Casting

Matter Casting is a standardized way to send media from a phone or tablet to a Matter-capable display — smart TV, projector, large smart display. The architecture defines a Casting cluster that exposes commands for content negotiation (URL, codec, DRM), playback control (play, pause, seek, volume), and session lifecycle. Matter Casting is intentionally codec-agnostic; the cluster carries metadata and references, the actual streaming happens over standard protocols (HLS, DASH, RTSP) that the receiver pulls from the source.

The interesting architectural piece is that Matter Casting works inside a fabric — your phone and the TV are both members of the same Matter fabric, so the session is authenticated and encrypted with CASE, no separate pairing, no QR codes. From a developer perspective this is materially simpler than AirPlay or Chromecast SDK integrations, which require their own auth and discovery layers.

Matter Casting is not a replacement for Apple AirPlay or Google Chromecast in 2026 — both still have richer ecosystems and better quality-of-service tuning. But for cross-ecosystem casting (Android phone to a TV that only speaks HomeKit, for example), Matter Casting is the only standard that works.

Eco Mode

Eco mode is Matter 2.0’s framework for energy-aware device orchestration. It defines clusters for Device Energy Management (DEM), Electrical Energy Measurement, and Energy Preference, plus an orchestration model where a controller (the energy manager) can request devices to shift load, defer non-urgent operations, or run at reduced capacity during high-tariff windows.

A practical example: your EV charger is mid-charge at 7 kW, the grid signal pushes a high-tariff alert, the energy manager broadcasts an Eco mode request, and Matter-enabled appliances respond — the dryer postpones its cycle by 30 minutes, the HVAC widens its setpoint band by 1°C, the EV charger throttles to 3 kW until the tariff drops. Each device’s response is governed by its own Energy Preference settings; the user retains ultimate override.

Eco mode is the strongest sign yet that Matter is being positioned not just as a smart-home protocol but as the residential-energy coordination layer for the next decade. The CSA worked closely with utility groups and the European Commission’s Smart Readiness Indicator team during the 1.4 and 2.0 cycles, and the device-type definitions reflect that.

Production Smart Home Reference Architecture

Here is the architecture I deploy when a client asks me to “do Matter properly” in a multi-floor home. It is deliberately conservative — redundant border routers, isolated commissioning network, and Multi-Admin only where it adds real value.

Network Foundation

Start with IPv6 enabled end-to-end. Most modern routers ship with IPv6 on by default, but ISP-provided routers in some regions still ship with IPv6 disabled or in pass-through-only mode. Verify with a quick ping6 google.com from a wired client; if it fails, fix it before buying a single Matter device. mDNS (and the underlying multicast routing) must be allowed across all VLANs that will host Matter devices and controllers — Matter discovery is mDNS-only, no cloud fallback.

Use Wi-Fi 6E or Wi-Fi 7 if you can. Not because Matter requires it, but because the 6 GHz band and Multi-Link Operation give you headroom for the dozens of Wi-Fi Matter devices the home will accumulate over time.

Thread Border Router Placement

Place at least two Thread border routers on different floors. The 2026 sweet spot is one TBR per 1,500-2,000 sq ft, on different mains circuits (so a circuit trip doesn’t take both down). Diagram 5 shows three TBRs covering three floors plus garage — an Apple TV 4K as the primary on the main floor, a HomePod mini upstairs, and a Nest Hub 2nd gen in the garage covering the EV charger and outdoor lights.

Thread 1.3’s multi-BR support means all three border routers share credentials and the Thread network heals gracefully across them. Matter 1.4 introduced the Thread credential-sharing improvements that make cross-ecosystem TBR sharing (Apple TBR + Google TBR + Amazon TBR on the same Thread network) actually work — pre-1.4 this was theoretically possible but practically miserable.

Hub Strategy and Redundancy

For each ecosystem you commit to, deploy at least one operational hub that doubles as a Thread border router. In a typical home this is Apple TV 4K (for Apple Home), Google Nest Hub Max (for Google Home), and SmartThings Station (for Samsung). Avoid using a phone as your only Home Hub — phones move, lose power, and lose network state. A wired or always-on hub anchors the fabric.

Critical devices (door locks, smoke alarms, water leak sensors) should be commissioned into the primary fabric and mirrored via Multi-Admin into a secondary fabric. That way a Google Home outage does not take out your front door lock if it was commissioned through Google.

Ecosystem Clouds — Optional but Useful

The dashed lines in diagram 5 are cloud uplinks. Matter is fundamentally a local-first protocol — all device control happens on the LAN, no cloud round-trip — but each ecosystem also offers a cloud uplink for remote access, voice control on first-touch, and cross-home automation. Treat the clouds as nice-to-haves, not hard dependencies. A correctly architected Matter home keeps working when the WAN drops.

Commissioning Network

For sensitive deployments (small offices, vacation rentals), consider a separate commissioning SSID that is online only during onboarding. New devices get joined to this SSID, the controller provisions them with the production SSID’s credentials, and the device migrates over. This pattern eliminates the “guest with a Matter device pollutes your fabric” risk.

Logging and Health

Run a small home-server process that polls each TBR’s neighbour table and writes the results to a time-series database — Home Assistant’s Thread integration does this out of the box. Sudden neighbour-count drops are the earliest signal that a TBR has gone partially blind, often before any device starts misbehaving visibly.

Security: PASE, CASE, Device Attestation

Matter’s security model is one of the parts the CSA got most right. It is also one of the parts that gets the least attention from buyers, who reasonably assume security is the vendor’s problem.

PASE — Commissioning

Password Authenticated Session Establishment is the handshake used during commissioning. The device’s setup code (the 11-digit number or QR code on the box) is the shared secret. PASE uses SPAKE2+ to derive a session key from that code without ever sending the code over the air. The result is a short-lived encrypted channel over BLE, used only long enough to provision the operational certificate and network credentials.

PASE is single-use per commissioning event. The setup code is meant to be on the device packaging, not regenerated, which means a recovered setup code is a permanent commissioning back door — physical security of the device or its box matters.

CASE — Operational

Certificate Authenticated Session Establishment is what every Matter message rides inside after commissioning. CASE uses the device’s NOC (signed by the fabric’s root CA) and the controller’s NOC to derive a forward-secure session key per session. The cryptography is standard ECDH on P-256 plus AES-CCM for the messages. There is no “Matter password” at the operational layer — authentication is certificate-based, mutually authenticated, and fabric-scoped.

Device Attestation

When a device is commissioned, the controller verifies a Device Attestation Certificate (DAC) chain that goes back to a Product Attestation Authority (PAA) root operated by the CSA. The DAC chain proves the device is a legitimate, CSA-certified product from a known vendor (encoded by Vendor ID and Product ID). A controller that finds a Matter device with no valid DAC chain rejects it (or warns the user, depending on ecosystem policy). This is the mechanism that prevents counterfeit “Matter-compatible” devices from infiltrating fabrics — the DAC chain is hardware-rooted (the DAC private key lives in a secure element or eFuse) and cannot be cloned without breaking the silicon.

In 2026, every certified Matter device ships with a DAC. The PAA chain is publicly auditable at the CSA, and ecosystems publish their attestation policy (some reject unknown vendor IDs by default, some warn).

Trade-offs and Limitations in 2026

Matter is the best smart-home protocol we have, and it still has rough edges worth being honest about.

Multi-Admin is better, not painless. The 2.0 re-sharing flows are a real improvement, but cross-ecosystem fabric transfers still occasionally fail and require the user to factory-reset the device. Plan for it.

Cluster evolution is slow. New device categories take 12-18 months from CSA working-group proposal to a 1.x release. If your product is in a category not yet covered by Matter (high-end AV, professional building automation, niche medical), you are either bridging or waiting.

Thread border routers are still vendor-specific bottlenecks. Even with multi-BR support, individual TBR firmware bugs can degrade an entire Thread network. Mixing brands of TBR helps but has its own coordination cost.

No native cloud-to-cloud. Matter is local-first by design. If you want a Matter device to push to AWS IoT Core or Azure IoT Hub, you need a bridge process (Home Assistant, a custom controller, or an ecosystem cloud’s API). Industrial users who want Matter-style semantics in a cloud-first deployment end up writing this glue layer themselves.

Energy clusters are still maturing. Eco mode in Matter 2.0 is a great foundation, but the device-type coverage is uneven — heat pumps and EV chargers are well-defined, residential storage batteries less so, grid-interactive water heaters not yet.

Commissioning still requires a phone. The “tap a button on the device” flow is theoretically supported but rarely shipped. In practice every commissioning event in 2026 requires a smartphone with the ecosystem app installed.

Practical Recommendations

For a homeowner starting fresh in 2026, the playbook is: commit to one primary ecosystem first (pick whichever phones your household uses), invest in two Thread border routers from that ecosystem, and prefer Thread-capable devices for sensors and locks, Wi-Fi for cameras and displays. Add Multi-Admin only for the handful of devices the rest of the household needs to control independently. Run a Home Assistant instance on a Raspberry Pi or mini-PC as a neutral observer and automation layer — it speaks Matter as a controller and gives you visibility into TBR health that no ecosystem app exposes.

For a product builder, the playbook is: target Matter 1.3 minimum (energy and EV clusters), prefer Matter 1.4 for Thread credential-sharing benefits, budget for at least 8 fabric slots in flash, ship with NFC commissioning if your bill of materials allows it, and certify against the CSA’s current test plan rather than skipping to “Matter-compatible” claims.

For a system integrator in commercial or multi-dwelling settings, the playbook is: treat Matter as a residential-grade protocol — it does not yet replace BACnet, KNX, or proprietary commercial-automation stacks. Use Matter at the unit/apartment level and bridge upward into your commercial system. The economics will shift over the next two to three years, but in 2026 commercial-grade certification and SLAs are not yet there.

FAQ

Is Matter 2.0 backwards-compatible with Matter 1.0 devices?
Yes. Matter 2.0 controllers are required to support the cluster set and interaction model from 1.0 onward. A 2022-vintage Matter 1.0 bulb will commission and operate normally on a 2026 Matter 2.0 hub.

Do I need to replace my router to use Matter?
Only if your current router does not support IPv6 or blocks mDNS. Any Wi-Fi 5 router from the last seven years with IPv6 enabled will work. Wi-Fi 6E or Wi-Fi 7 is a nice upgrade for headroom but not required.

Can I use Matter without a Thread border router?
Yes — but only for Wi-Fi Matter devices. Any Thread Matter device (most sensors, locks, low-power bulbs) needs at least one Thread border router on the network. If you buy a Thread device with no TBR, it will appear to be defective.

Does Matter work without the internet?
Yes, for all local device control. Subscriptions, commands, and automations execute on the LAN with no cloud round-trip. Remote access (controlling the home while you are away) and some voice features do require ecosystem cloud connectivity.

How many ecosystems can share one Matter device?
The spec mandates a minimum of 5 fabric slots; most certified devices ship with 5 to 16. In practice this means 5+ ecosystems can hold concurrent operational certificates on the same device.

References

Connectivity Standards Alliance (CSA), Matter Specification 1.4 — csa-iot.org/all-solutions/matter (the authoritative source for cluster definitions, interaction model, and security).
Project CHIP, connectedhomeip reference implementation — github.com/project-chip/connectedhomeip (the open-source SDK Matter products are built against).
Thread Group, Thread Specification 1.3 — threadgroup.org (Thread network layer, border router behaviour, credential-sharing).
Apple Developer, Matter Support in HomeKit — developer.apple.com/apple-home (Apple’s commissioning and Multi-Admin behaviour).
Google, Matter on Google Home — developers.home.google.com/matter (Google’s ecosystem and certification policy).
Amazon Developer, Matter on Alexa — developer.amazon.com/alexa/matter (Alexa Matter integration, commissioning flows).
Samsung SmartThings, Matter Hub Devices — developer.smartthings.com/matter (SmartThings hub and fabric architecture).
CSA, Matter 1.4 Release Notes (November 2024) — energy management, Thread credential-sharing, Enhanced Multi-Admin.