Matter

Matter defines device communication, identity and commissioning. Check the required device types and supported features against the exact products involved.

Overview#

Matter is an application layer interoperability standard for connected devices. It uses IPv6 and a common data model across supported IP networks; it is not a radio, link layer, or replacement for WiFi, Ethernet, or Thread. Bluetooth Low Energy is commonly used during discovery and commissioning, not as the ordinary operational application transport. MATTER SPECS

The Connectivity Standards Alliance announced Matter 1.6 on 17 June 2026. A product still needs an exact specification version, supported device types and clusters, certification record, ecosystem compatibility statement, and firmware baseline. A generic “Matter compatible” claim doesn't establish support for cameras, bridges, Joint Fabric behaviour, or any particular security feature. MATTER 16

Architecture and roles#

commissioner ---- secure onboarding ---- commissionee
     |                                      |
     +-------- fabric credentials ----------+

controller ===== CASE-secured IPv6 session ===== node
     |                                             |
 ecosystem / administrator                   endpoints + clusters

Thread node --- Thread border router --- IPv6 infrastructure
Wi-Fi/Ethernet node --------------------- IPv6 infrastructure

Matter discovery commonly uses DNS SD/mDNS, while Thread devices depend on one or more border routers for IP reachability beyond the mesh. Discovery output is untrusted metadata, not authorisation. Constrain multicast domains, validate advertised service data, and bind each interaction to the authenticated operational node and fabric. A hostname, product label or discovered address is insufficient for this identity check.

Data model and interaction contract#

Matter represents application behaviour through endpoints and clusters. Clusters can expose attributes, commands, and events; feature maps and revision metadata indicate supported subsets. An integration inventory should preserve:

• vendor/product identity and certified model/firmware record;
• fabric identifier and operational node identity without publishing sensitive credentials;
• endpoint, device type, cluster, cluster revision, feature map, and accepted command set;
• attribute/event data type, unit, range, null/unknown behaviour, quality, and timestamp provenance;
• subscription limits, reporting intervals, liveness expectations, and resubscription behaviour;
• bridge path and native device identity where a bridge is involved;
• required privilege and intended physical consequence for every command;
• authoritative post command feedback and timeout.

Don't infer physical state from successful protocol delivery. A command response can report application handling while a motor, contact, latch, camera privacy mechanism, or bridged subsystem remains delayed, obstructed, faulted, or independently overridden. Confirm important outcomes through an authoritative sensor/attribute/event and surface indeterminate state.

Commissioning and operational sessions#

Commissioning establishes a product in a fabric. The process includes discovery, proof of possession, device attestation, provisioning of operational credentials, network configuration where applicable, and installation of fabric policy. Matter distinguishes commissioning security from routine operational sessions:

• PASE establishes a password authenticated commissioning session from setup information;
• CASE establishes certificate authenticated operational sessions between fabric members;
• operational certificates and fabric scoped keys identify nodes after commissioning;
• group communication has different key, replay, membership, and feedback properties from unicast interaction.

Setup codes and QR payloads are onboarding secrets. Keep them out of screenshots, issue trackers, telemetry, public asset records, and long lived application logs. Commission only during an authorised window, identify the intended physical product independently, reject unexpected fabrics, and close the commissioning window after use.

Decommissioning must remove fabric membership, revoke or age out credentials as the applicable ecosystem permits, clear sensitive local state, and reconcile any bridge or cloud record. A factory reset changes trust state and may disrupt every ecosystem attached to the node; it isn't a routine troubleshooting step.

Device attestation isn't authorisation#

Matter device attestation uses a Device Attestation Certificate chain and associated certification declarations to support product origin and certification checks during commissioning. Its decision inputs and trusted Product Attestation Authority roots require lifecycle management.

Attestation can help answer whether a commissionee presents an acceptable certified product identity. It does not establish:

• that the person commissioning it is authorised for the site;
• that the product is physically installed at the claimed location;
• that its current firmware is vulnerability free;
• that a controller should receive access to a door, camera, relay, or occupancy signal;
• that a later command produced the intended physical outcome.

Record attestation result, policy version, certificate identifiers, certification declaration result, exception approval, and firmware/product baseline separately from application authorisation.

Fabric access control#

Matter access control entries are fabric scoped and express privilege, authenticated subject, and target constraints. Exact fields and behaviour are version dependent, but the engineering rules are stable:

• grant the minimum privilege needed for the required endpoints and clusters;
• use distinct identities for administrators, automation controllers, bridges, and observability collectors;
• avoid broad node, group, or CASE Authenticated Tag grants without a documented membership lifecycle;
• protect access control and operational credential management as administrative functions;
• reconcile policy after node replacement, ecosystem removal, bridge migration, or fabric changes;
• treat group commands as potentially wide actuation with limited per recipient confirmation;
• log policy changes and denied high impact commands without disclosing keys or setup payloads.

Matter policy is one layer. A security platform still needs tenant/site/resource authorisation, operator role, purpose, schedule, emergency override, separation of duties, and local safety interlocks. Don't translate a broad ecosystem role directly into unrestricted physical security control.

Multi admin and Joint Fabric boundaries#

Traditional multi admin behaviour allows a product to participate in more than one fabric, giving each ecosystem its own credentials, node identity, access control state, subscriptions, and lifecycle. Matter 1.6 also introduces Joint Fabric capabilities intended to improve multi ecosystem sharing. Treat Joint Fabric as an explicit capability with ecosystem and product specific support, not as a property of every Matter 1.6 deployment. MATTER 16

For either model, define:

• which administrator owns initial onboarding, removal, update policy, and recovery;
• whether identities and policy are independent, synchronised, or jointly administered;
• how duplicate automations, events, and commands are prevented;
• what one ecosystem can learn about another ecosystem or its users;
• what happens when one administrator removes the node or becomes unavailable;
• how audit records correlate fabric scoped identities without creating an unnecessary global identifier.

Shared control increases the need for deterministic precedence. Two valid ecosystems can issue conflicting commands without either being malicious.

Cameras and physical security boundaries#

Matter 1.5 introduced camera support; Matter 1.5.1 refined camera performance and device flexibility. The CSA catalogue lists Matter 1.6.1 specifications as of 29 September 2026. The 1.6 feature announcement remains a separate historical source; the patch listing alone does not establish new features or product support. MATTER SPECS A camera integration must therefore pin the exact product and cluster revision rather than infer a uniform “Matter camera” capability. MATTER 15 MATTER 151 MATTER 16

Matter camera support doesn't automatically provide:

• ONVIF profile conformance or ONVIF service behaviour;
• VMS recording, retention, evidence export, chain of custody, or legal hold;
• universal browser, codec, WebRTC gateway, or NAT traversal compatibility;
• a complete event taxonomy, analytics model, or alarm monitoring contract;
• authorisation suitable for privacy zones, microphone use, PTZ, or recording access.

Maintain separate media session authorisation, codec/transport limits, privacy and recording policy, event provenance, and evidence controls. A Matter bridge or controller shouldn't become an unreviewed path around the camera/VMS security model.

Bridging and cross domain automation#

A bridge translates identity, state, command, timing, and failure semantics between Matter and another protocol. It can't manufacture guarantees absent on the native side. Record native identifiers and quality, distinguish cached from observed state, cap translation queues, expose partial failure, and avoid silently mapping unknown values to a safe looking default.

Keep fire/life safety control, access decisions, lock release, lift control, and other certified behaviour outside ordinary consumer automation unless the complete approved system design explicitly includes that path. Matter scenes, routines, occupancy, and presence are convenient automation inputs; they aren't authoritative access decisions or emergency system states.

Failure and recovery cases#

• commissioner loses connectivity after operational credentials are installed but before the UI reports completion;
• node belongs to a fabric but network provisioning, DNS SD, or border routing is unavailable;
• Thread border router failover changes path or reachability;
• operational certificate, trust root, group key, or ecosystem account is rotated or removed;
• subscriptions lapse and cached attributes appear current;
• bridge is reachable while one or more bridged devices are stale or absent;
• two fabrics issue conflicting commands or maintain inconsistent policy;
• firmware update changes endpoint composition, feature maps, or behaviour;
• factory reset leaves stale inventory, cloud, automation, or evidence records.

Recovery should reconcile fabric membership, endpoint/cluster inventory, policy, subscriptions, bridge mappings, and authoritative physical state. Avoid blind replay of commands after an indeterminate disconnect.

Design and evidence checklist#

• Matter specification, product firmware, certification record, device types, clusters, revisions, and feature maps pinned
• Operational network/bearer and Thread border router dependencies documented
• Commissioner, administrator, controller, bridge, and observability identities separated
• Setup payloads, attestation roots, operational certificates, group keys, and rotation/removal lifecycle protected
• Attestation policy kept distinct from user authorisation and site acceptance
• Fabric ACLs mapped to tenant/site/resource policy with least privilege
• Multi admin or Joint Fabric ownership, synchronisation, privacy, conflict, and removal behaviour defined
• Attribute freshness, subscription gaps, bridge quality, and unknown state preserved
• Commands have idempotency/replay policy and authoritative post condition feedback
• Camera media, privacy, recording, event, evidence, and ONVIF boundaries documented separately
• Fire/life safety, lock, gate, lift, relay, and other high impact paths require approved system level controls
• Commissioning, policy changes, fabric membership, firmware, and administrative actions produce reviewable audit evidence

Sources#

• MATTER SPECS, Matter specification downloads, Connectivity Standards Alliance, accessed 25 August 2026. Complete specification packages may require an access request or licence acceptance.
• MATTER 16, Matter 1.6 enables more intuitive setup, multi ecosystem experiences, and context driven control, Connectivity Standards Alliance, 17 June 2026.
• MATTER 151, Matter 1.5.1: enhancing camera performance and expanding device flexibility, Connectivity Standards Alliance, 31 March 2026.
• MATTER 15, Matter 1.5 introduces cameras, closures, and enhanced energy management capabilities, Connectivity Standards Alliance, 20 November 2025.

Section overview · Wiki home