Matter 1.6 and 1.6.1: Groupcast, NFC Setup, Joint Fabric, Product Security 1.1

Every smart home standard eventually has to answer the same unglamorous question: how do you get a device from a cardboard box into a working network without the user giving up halfway? Matter 1.6, announced by the Connectivity Standards Alliance (CSA) on June 17, 2026, is a release that mostly spends its effort there. It adds no new device categories. It targets commissioning, shared administration, command arbitration and certificate scale, and it ships alongside a separate Product Security 1.1 specification that gives manufacturers a certifiable security baseline.

The follow-up, Matter 1.6.1, arrived quietly in September 2026 and finished a feature that 1.6 had only introduced provisionally: groupcast. Together the two releases change what firmware teams must build, what platform teams must support, and what compliance teams can point to when a regulator asks for evidence.

This guide is written for developers and product owners. You will leave with a clear model of each feature, a mechanism-level picture of how groupcast and NFC setup behave on the wire, an honest list of what is still unverified or unshipped, and a practical firmware upgrade path.

What this covers: the 1.5 to 1.6.1 timeline, groupcast mechanics, NFC commissioning, Joint Fabric, Thermostat Suggestions, certificate revocation, Product Security 1.1 and its relationship to EU rules, failure modes, and a checklist.

Context and Background

Matter is the application-layer interoperability standard maintained by the CSA, running over Wi-Fi, Thread and Ethernet, with Bluetooth Low Energy used for commissioning in most deployments. Its value proposition is that a certified light, lock or sensor works with several ecosystems at once. The standard is now on a rapid cadence. Per reporting on the 1.6.1 release, 2026 has already seen three extension releases: Matter 1.5.1 in March, Matter 1.6 in June and Matter 1.6.1 in September.

That cadence matters because the SDK and the specification are only half of the story. A feature exists for users only when three parties ship it: the device maker in firmware, the platform vendor in its controller and app, and, for commissioning-related changes, the retail and packaging chain. The CSA itself cautions that adoption timing varies by company and product, so support will depend on each vendor. Treat every feature below as “specified” rather than “available in your living room”.

If you followed the earlier arc, Matter 1.5 brought camera support with WebRTC-based streaming and further Thread work; our walkthrough of Matter 1.5 camera WebRTC and Thread 1.4 covers that base. Matter 1.6 does not extend the device catalogue. It tightens the plumbing underneath: how devices are onboarded, how several administrators share them, how commands from competing automations are weighed, and how revoked certificates are distributed.

The security side is changing in parallel. Product Security 1.1 arrives while the European Union’s Cyber Resilience Act (CRA) obligations approach, and manufacturers are looking for an attestation that maps cleanly onto legal duties. We cover the regulatory timelines in the CRA 24-hour reporting guide for industrial IoT. Nothing in a CSA certificate substitutes for legal conformity assessment, but it can supply structured evidence, and that is where the practical value lies.

For primary sources, the CSA publishes specifications and announcements at csa-iot.org, and the reference SDK lives in the project-chip GitHub organisation. Third-party reporting used for this article is linked inline and in Further Reading. Where a detail came from a single secondary source, this article says so.

What Matter 1.6 contains, in one view

The 1.6 headline items, as reported by the CSA announcement coverage, are NFC-based setup before the device is powered, an enhanced Joint Fabric for multi-administrator deployments, Thermostat Suggestions, smaller chunked Certificate Revocation Lists, standardised reporting of device capabilities and operating limits, interoperable event history for security sensors, and an “unmounted” state for smoke and carbon monoxide alarms. Groupcast appears as a provisional feature. Product Security 1.1 is released as a companion specification rather than part of Matter itself.

The 1.6.1 revision is a maintenance release. It introduces no new device types, revises the Groupcast cluster, updates the Chime device type, adds access-control optimisations whose details were not published in the coverage reviewed, and refines camera streaming and clip recording.

Matter 1.6 Reference Architecture: What Changed and Why

Matter 1.6 is best understood as four independent improvements that share a theme: fewer round trips and fewer special cases between a user’s intent and a device’s state. NFC removes a step from onboarding. Joint Fabric removes a coordination problem from administration. Groupcast removes N unicast sends from control. Thermostat Suggestions removes direct, unconditional commands from automation. Each is optional for a device to implement, so the architecture is a menu rather than a mandate.

Figure 1: Matter release path from 1.5 through 1.6.1, showing where each 2026 feature landed and which items were provisional in 1.6.

Figure 1 shows the sequence. The long-description version: Matter 1.5.1 shipped in March 2026, Matter 1.6 in June with NFC setup, Joint Fabric, Thermostat Suggestions, chunked certificate revocation lists, a provisional groupcast and the Product Security 1.1 companion, and Matter 1.6.1 in September, which revised groupcast, updated Chime and tuned access control and cameras without adding device types.

Groupcast: one message, many devices

Direct answer: Matter groupcast lets a controller or switch send one encrypted multicast message to every member of a group, instead of one unicast command per device. In 1.6.1 the revised Groupcast cluster consolidates membership, keys and permissions, and can use a shared multicast address that members filter with their group keys.

To appreciate the change you need the pre-1.6 model. Matter has long supported group communication. A group is identified by a 16-bit group ID. Membership is held in the Groups cluster on each device endpoint, and the keys that protect group traffic live in the Group Key Management cluster, organised into keysets. The Nordic Semiconductor nRF Connect SDK documentation describes the pieces: each keyset holds epoch keys, each paired with a start time, plus a security policy, and a group key map binds a group ID to a keyset for a given fabric. Access control entries then authorise either the controller node or the group as a subject on the target endpoint.

That model works, but it is spread across several clusters and several provisioning steps. Every device needs its Groups entry, its keyset written, its key map written and a suitable access control entry, and an error at any one step produces a device that silently ignores the group. Nordic’s documentation also records the behavioural limits. Group messages are unacknowledged, so the sender cannot confirm delivery and reliability depends on the underlying network. Sleepy end devices should not be targeted because their radios are mostly off, and parent routers do not buffer multicast for their children, so a missed message is simply gone.

Groupcast, per Nordic’s documentation, extends this group model with a GCAST feature and a GroupcastAdoption attribute on the Group Key Management cluster. In Matter 1.6.0 it was provisional, disabled by default in that SDK build, and not yet certifiable, so developers were told to stay on Groups plus Group Key Management for production.

Matter 1.6.1 changes the status. According to Matter Alpha’s reporting on the release, groupcast moved out of provisional status and is now the recommended method for device groups. It consolidates the membership, encryption key and permission handling that used to span several clusters into a single system. Two addressing modes matter. Groupcast can use one shared multicast address rather than a unique address per group, with devices filtering incoming traffic by trying their secure group keys. Dedicated per-group addresses remain available for older hardware and battery-powered devices. The same coverage clarifies sender and listener roles: wall switches send, while lights, fans, thermostats and window coverings listen.

The reporting does not list the cluster identifiers or attribute layouts, and this article does not invent them. If you are implementing, read the 1.6.1 specification text and the SDK headers directly.

Why a shared multicast address is a real design change

In the traditional IPv6 mapping, each group maps to its own multicast address, so a network infrastructure device such as a Thread Border Router or a Wi-Fi access point must forward or filter a growing set of addresses. A Thread router holds multicast subscriptions, and each additional address consumes state. A shared address collapses that into one forwarding rule, and the cryptography does the discrimination. The cost is that every device listening on the shared address receives frames for groups it does not belong to and spends a decryption attempt discovering this.

For mains-powered lights that cost is trivial. For battery devices it is not, which is exactly why the specification keeps dedicated addresses for them. The trade-off is a clean illustration of a principle you will meet repeatedly in constrained networks: moving discrimination from the network layer to the application layer saves infrastructure state and spends endpoint energy. If you want the network-layer background, our guide to OpenThread Border Router and Thread mesh networking with IPv6 and 6LoWPAN explains how multicast is forwarded across a Thread mesh.

Figure 2: Groupcast data path. One sender emits a single multicast packet encrypted under the group keyset; members decrypt and act, non-members drop the frame, and Group Key Management supplies keys to all parties.

Figure 2 summarises the path. In prose: the sender and every member obtain keys through Group Key Management, the sender transmits once, members whose keyset validates the frame act on it, and devices outside the group discard it.

What this buys you in practice

The user-visible payoff is synchronisation. Ten recessed lights addressed with ten sequential unicast commands turn on with a visible ripple, because each command takes its own round trip and the radio serialises them. One multicast frame reaches all of them within the same short window. The effect is largest on Thread, where each unicast hop adds latency, and smallest on a single Wi-Fi access point with few devices. I am not quoting a latency figure here because none of the sources reviewed publish a measured one, and a made-up number would be worse than none.

Matter Alpha also reports that existing groups, bindings and automations should remain intact after firmware updates, per the specification’s backward-compatibility guarantees, and that Home Assistant is developing native Matter group controls that would send single group commands instead of sequential ones. Scenes and direct device bindings are outside that initial scope and no release date has been announced.

NFC commissioning: setup before power

Direct answer: Matter 1.6 lets a device be commissioned over NFC before it is powered on or installed. A phone reads the device, which is energised by the NFC field, so a bulb can be provisioned before it is screwed into a fixture, and several devices can be prepared in advance and installed later.

The motivating problem is mundane. Setup codes and QR codes are printed on a label, and the label is usually hidden once the device is installed: inside a ceiling fitting, behind a switch plate, or on the back of a unit in a wall. People photograph the code before installation or lose it. Matter 1.4.1 added support for carrying the onboarding payload over NFC, but reporting on 1.6 says that approach still relied on Bluetooth Low Energy for commissioning. Matter 1.6 moves the whole commissioning process to NFC.

How the flow differs from BLE commissioning

In the standard BLE flow, the device must be powered and advertising, the phone discovers it, a PASE (Passcode-Authenticated Session Establishment) session is set up using the setup passcode, the phone sends network credentials, and the device then joins Thread or Wi-Fi and is handed an operational certificate and fabric membership via CASE (Certificate-Authenticated Session Establishment). The phone must be near, the device must be on, and a radio must be active.

In the NFC flow, the passive tag path means the device needs no battery or mains: the reader’s field supplies enough power for the exchange. The coverage reviewed does not publish the exact message sequence, so Figure 3 is an architectural sketch of the user-level flow and not a byte-level protocol trace.

Figure 3: Simplified NFC commissioning flow. The user taps a phone on an unpowered device, the phone obtains identity and credentials, hands over to the chosen controller, and the device later joins the network when installed and powered. Illustrative of the user-level flow, not a protocol trace.

The practical consequences for product teams are concrete. You need an NFC-capable secure element or tag IC with the right memory and a path to the commissioning data, antenna placement that survives the enclosure, and a factory step that writes per-device credentials. The Matter specification and the CSA certification programme define what must be supported, so confirm against the 1.6 specification before committing hardware. For electricians and installers the benefit is workflow: provision a whole carton of fixtures at a bench, then install without further setup, which is what the CSA’s “several devices in advance” language implies.

Joint Fabric: one shared network, many administrators

Direct answer: Joint Fabric extends Matter’s Enhanced Multi-Admin so that several user-authorised controllers co-administer a single shared Matter fabric. A central datastore keeps all participating controllers aware of every device, and a device counts it as just one fabric.

Matter has always allowed a device to join multiple fabrics, one per ecosystem, so a lamp can be controlled by two platforms. That is multi-admin. The cost is that each fabric is separate: each ecosystem commissions, names and stores devices on its own, a device has a finite number of fabric slots, and nothing keeps the views consistent. Matter 1.4 introduced Enhanced Multi-Admin to streamline sharing; 1.6 extends it with Joint Fabric.

The reported design uses a central datastore: any device added becomes accessible to all participating controllers, and administrators can be added or removed without touching the devices. Because the joint fabric is one fabric from the device’s perspective, a device that supports several fabrics keeps slots free for other ecosystems. The CSA suggests new-construction handovers, multi-platform households and professionally managed properties as target scenarios.

The new-build case is the clearest. A builder or integrator commissions every device into a joint fabric, then hands administrative control to the homeowner’s chosen platform, and later to a different one if the owner switches, without recommissioning hardware that is buried in walls. In a managed property, a facilities team and a tenant can both hold appropriate authority over the same devices.

Two cautions apply. The sources reviewed do not publish the trust model details, such as how the datastore is replicated, who anchors the root of trust, or how conflicts are resolved, so do not assume. And the feature only helps when platforms implement it, which today means you should not plan a product around Joint Fabric working across all large ecosystems at launch.

Thermostat Suggestions: arbitration instead of obedience

Direct commands from many automations are a classic source of conflict. A presence automation turns the heat up while a utility demand-response event is asking for reduced load, and a user’s manual change gets silently overwritten. Matter 1.6’s Thermostat Suggestions give ecosystems a standard way to recommend rather than command. As reported, “a controller submits a time-limited suggestion linked to one of the thermostat’s supported presets”, and the thermostat decides whether to act based on user preferences, recent activity and environmental conditions. If it declines, it can return a standardised explanation.

This is a small feature with a large design lesson: put the policy at the actuator. A thermostat configured to prioritise energy savings can reject an automation that would override that setting, and the rejecting party can say why, so the calling app can tell the user instead of failing mysteriously. For developers building automations, it means treating a thermostat call as a request that may be refused, with a path to display the reason.

Chunked Certificate Revocation Lists

Matter’s device attestation relies on certificates, and a certificate that has been revoked, for example because a vendor key was compromised, must be distributable to commissioners. Matter 1.4.2 added CRL support, and 1.6 improves it by splitting revocation data into smaller partitions that update independently. The announcement frames this as scalability: one monolithic list grows with every certified device and every revocation, while independent chunks let a client fetch only what changed.

For a commissioner this reduces bandwidth and storage on constrained hubs. For a manufacturer it limits the blast radius of an update cycle. The coverage does not describe partition schemes or size limits, so I will not.

Product Security 1.1 and the Regulatory Picture

Product Security 1.1 is a separate CSA specification, released with Matter 1.6, aimed at unifying various international cybersecurity standards so manufacturers can show a baseline more easily. Per the Privacy Guides report of the CSA announcement, it defines two levels. Level 1 is a supplier self-assessment reviewed by an Authorized Test Laboratory (ATL). Level 2 requires an independent assessment and functional testing by an ATL.

The requirements as listed in that report include unique passwords per device, anti-brute-force mechanisms, no critical security parameters embedded in source code, best-practice cryptography, support for erasing user data, removal of unused interfaces including test interfaces, input validation, removal of unused functionality, a recommended secure boot process, automatic software updates, verification of update integrity, and isolated processing. Note the hedged wording: “recommended” secure boot is how the report words it; check the specification for the normative strength of each item.

Mapping to the EU Cyber Resilience Act

The CRA places obligations on manufacturers of products with digital elements, including security-by-design requirements, vulnerability handling and reporting duties. A CSA Product Security certificate is not a CRA conformity assessment and does not confer CE marking. What it can do is structure evidence. Table 1 shows a pragmatic mapping that you should treat as an engineering aid, not legal advice. The mapping is my own analysis, not a statement by the CSA or the EU.

Product Security 1.1 theme	Evidence it can feed on the CRA side	Gap you still own
Unique per-device credentials, anti-brute-force	Secure-by-default configuration, no shared default passwords	Documented risk assessment
Secure boot, update integrity verification	Update authenticity and integrity controls	Support period and update policy
Automatic software updates	Security updates delivered without friction	Defining and publishing the support period
No test interfaces, minimal functionality	Reduced attack surface	Technical file and SBOM
Data erasure support	Data protection by design	Privacy documentation
ATL review or testing	Third-party evidence of controls	Vulnerability handling and 24 hour reporting workflow

The last row is the important one. The CRA’s reporting duties for actively exploited vulnerabilities, covered in our CRA 24-hour reporting guide, are organisational processes. No certificate gives you an incident-response team or a coordinated disclosure policy, and a Level 2 badge does not tell a regulator how fast you would notify them.

Figure 4: Product Security 1.1 levels feed shared control evidence, which supports CRA technical documentation and vulnerability handling, while CE marking remains the manufacturer’s own duty.

The figure’s long description: both levels converge on the same control families, which then provide evidence for the technical file and for vulnerability handling, and both of those feed the manufacturer’s CE marking responsibility.

Deeper Analysis: Building and Upgrading for 1.6.1

The features above are only useful if you can build against them. This section covers the software landscape, what a groupcast integration looks like, how to reason about reliability, and how to plan a firmware upgrade.

The software landscape in late 2026

There are two relevant stacks. The first is the CSA’s reference SDK, connectedhomeip, which most silicon vendors wrap in their own toolchains. The second is matter.js, an independent TypeScript implementation that is not developed by the CSA. According to the matter-smarthome.de report of October 2026, matter.js 0.18.0 implements Matter 1.6.1 across all software clusters and data types, introduces a new controller API, overhauls groupcast and enables it by default, and automatically checks each device endpoint for required clusters and mandatory elements. Its lead developer, Ingo Fischer, described it as the most specification-compliant version to date. The same report says the Open Home Foundation Matter Server, whose core is built on matter.js, has a beta with 1.6.1 support, so the features are expected to reach Home Assistant soon.

On the Nordic side, documentation for the nRF Connect SDK’s Matter add-on describes groupcast as disabled by default, enabled through a Kconfig option, and provisional and not certified at 1.6.0. Check whether your vendor SDK branch has since been updated to 1.6.1 before you build a product on it, because that single flag determines whether you can ship the feature with a certification.

What a groupcast integration involves

I could not verify a complete, runnable matter.js groupcast snippet against the 0.18.0 API within this run, and publishing an API call from memory risks sending you to a method that does not exist. So rather than fabricate code, here is the verified conceptual sequence, followed by the documented chip-tool pattern from Nordic’s group communication page for the pre-groupcast model, which remains valid for groups on earlier firmware.

The steps for any group, regardless of SDK, are these. First, the controller creates a keyset with epoch keys and a security policy. Second, it writes the keyset to each member device and to every sender that will transmit to the group. Third, it binds the group ID to the keyset through the group key map on each device. Fourth, it adds the group to each member endpoint using the Groups cluster. Fifth, it writes access control entries so that the group, or the sending node, is authorised for the relevant clusters. Sixth, the sender transmits a command addressed to the group ID.

For the classic model, Nordic’s page shows commands of this shape, with node IDs, group IDs and endpoints replaced by your own values:

# Illustrative pattern, adapted from the nRF Connect SDK group communication page.
# Verify exact syntax against your chip-tool version before use.
chip-tool groups add-group 0xdcba "Lights" <node-id> 1
chip-tool groupsettings show-keysets
chip-tool onoff on 0xffffffffffffdcba 1     # destination is the group target

The final line reflects the page’s example of sending to 0xffffffffffffdcba for group ID 0xdcba, though the page does not explain how that destination value is formed, and neither will I. What matters for design is the shape: one provisioning phase touching every device, and one cheap send phase.

With the 1.6.1 Groupcast cluster, the reported intent is to fold the membership, key and permission steps into a single coherent system and let a shared multicast address stand in for per-group addresses. Your integration code should therefore be structured so that group provisioning lives behind one interface in your application. When you migrate from classic groups to groupcast, you replace that interface’s implementation rather than touching every call site.

Reliability: multicast is not acknowledged

The most important thing to internalise about groupcast is that it trades confirmation for speed. Group messages are unacknowledged, the sender cannot confirm that all members received them, and sleepy devices are not good targets. For a lighting scene this is acceptable: a light that misses a frame stays in its previous state and the user notices. For a lock, a valve or a heating call with safety implications it is not.

The usual pattern is send then verify. Send the group command, wait a short period, then read the relevant attribute from each member, or rely on subscriptions that report state changes, and retry unicast only for devices that did not change. This keeps the common case at one multicast send and moves the unicast cost to the exceptions. Design your telemetry so that a “group send” is recorded as intent and each device’s reported state is the evidence.

A rough capacity argument illustrates the gain. If a room has N devices and each unicast needs a request and an acknowledgement, a unicast scene costs about 2N transmissions before any retries. A multicast send costs one transmission plus the optional verification reads, which are only needed for devices you cannot observe through subscriptions. This is a model, not a measurement. Real Thread meshes also retransmit multicast a configurable number of times for reliability, so the saving is smaller than the arithmetic suggests, but the scaling behaviour, constant versus linear, is robust.

Firmware upgrade path from 1.5 and 1.6

Upgrades come in three tracks, and mixing them up causes most of the pain.

Track one is the device firmware. A Matter device advertises its supported specification revision through its data model and certification record, so moving from 1.5 to 1.6.1 means taking the new SDK, rebuilding, retesting and, if you want the new feature set on the label, recertifying. Reporting on 1.6.1 says existing groups, bindings and automations should survive firmware updates under the specification’s backward-compatibility guarantees. Treat that as a claim to test, not a guarantee: build a regression suite that provisions groups and bindings on the old firmware, performs an over-the-air update, and asserts that they still work.

Track two is the OTA mechanism itself. Matter defines an OTA Software Update Provider and Requestor model. You will want staged rollout, rollback on failed boot and a cryptographic check of image integrity, which also happens to be what Product Security 1.1 lists under update verification. If you are adding NFC hardware, that is a new hardware revision and cannot arrive by OTA, so plan the SKU split.

Track three is the ecosystem. Both the end device and the platform must support a new Matter release, and widespread adoption may take months or years. Your 1.6.1 device must still behave on a 1.4 or 1.5 controller. Practically, that means testing every new feature in a mode where the controller does not use it, and confirming that a device which supports groupcast still honours the classic Groups cluster. The specification keeps dedicated per-group addresses available for older hardware and battery devices, which is the compatibility lever.

A sensible order of operations is: update the SDK branch in a feature branch, run the existing certification test cases, enable groupcast behind a build flag, add the Chime speaker endpoint if you make a doorbell, add the NFC hardware in the next board revision, and submit for certification when the platform ecosystem you target has shipped a matching controller.

Chime sounds and the doorbell use case

Matter Alpha describes the 1.6.1 Chime change as adding an optional speaker endpoint that separates the audible chime from visual alerts. Muting silences only the sound, so flashing LED notifications stay active. Volume uses level controls and muting uses the standard on and off commands. Mechanical chimes can be muted by blocking the striker. Matter-smarthome.de adds that the type was updated to play preinstalled sounds such as a gong, benefiting audio and video doorbells. The practical caveat from Matter Alpha: manufacturers must ship firmware updates and platforms must add the controls to their apps, so the user value arrives only when both have moved.

Decision matrix: which features to adopt first

Not every product needs every 1.6 feature. The following matrix is my own prioritisation, based on the mechanisms above, and reflects engineering effort against user value.

Product type	Groupcast	NFC setup	Joint Fabric	Thermostat Suggestions	Product Security 1.1
Mains lighting, switches	High value	High value for fixtures	Medium	Not applicable	Medium
Battery sensors and locks	Avoid targeting sleepy nodes	Medium, depends on BOM	Medium	Not applicable	High, safety relevant
Thermostats and HVAC	Medium	Medium	Medium	High value	High
Video doorbells and cameras	Low	Low	Medium	Not applicable	High, plus Chime
Building and managed property gear	Medium	High for pre-staging	High value	Medium	High

Trade-offs, Gotchas, and What Goes Wrong

Provisional means not shippable. Groupcast was provisional in 1.6.0 and not certified in the Nordic documentation. Teams that built on it in the summer need to confirm which spec revision their SDK tracks, because behaviour was revised in 1.6.1. The CSA moved the cluster to a recommended state in 1.6.1, so that is the stable target.

Shared multicast means more wasted wake-ups. A shared address means every listener sees frames for groups it does not belong to, and each must attempt decryption to find out. On mains devices this is negligible. On battery devices it burns energy, which is why dedicated addresses are retained. Do not enable shared-address listening on a sleepy node without measuring its energy impact.

Unacknowledged delivery hides failures. If your product UI shows “done” the moment a group command is sent, users will see lights that did not change. Pair every group command with state verification.

NFC is a hardware commitment. Antenna tuning inside a metal or foil-lined luminaire is hard, and NFC reads fail at oblique angles. Prototype in the final enclosure early. Because the benefit is largest for fixtures installed behind ceilings, that is also where the RF environment is worst.

Joint Fabric is only as good as platform support. Until major platforms interoperate on it, a joint fabric may be operable by only some of the controllers your customers use. The trust-model details were not available in the coverage reviewed, so security reviewers should read the specification text before approving a design.

Security labels are not compliance. Level 1 is a self-assessment reviewed by a lab. Do not market it as independent testing, and do not describe either level as CRA conformity. The CRA’s duties around vulnerability reporting and support periods remain yours.

Thermostat Suggestions can be ignored. An integrator who assumes a suggestion changes the setpoint will ship a broken automation. Always handle the declined path and the returned explanation.

Ecosystem lag is the real schedule risk. The CSA’s own caveat that both device and platform must support a release means your 1.6.1 firmware may sit unused for months. Budget for that in marketing claims.

Practical Recommendations

If you build lighting or switching products, adopt groupcast first. It has the clearest user benefit, it is now recommended rather than provisional, and the old group model remains available as a fallback. Structure your provisioning behind a single interface so that migration costs one module. Keep unicast verification for anything that matters.

If you build battery devices, keep them out of shared-address listening unless measurement shows an acceptable energy cost, keep the dedicated address option, and invest your effort in Product Security 1.1 and OTA integrity instead.

If you commission devices at scale, whether as a builder, installer or integrator, watch for NFC-capable hardware and Joint Fabric support in the platforms you deploy. Both change workflow more than technology: bench pre-staging and clean hand-over. Pilot them on one project before standardising.

If you carry regulatory exposure in the EU, treat Product Security 1.1 as an evidence generator. Map each requirement to your technical documentation, decide your support period and update policy, and build the vulnerability reporting process independently of any certificate.

A short checklist to close:

Confirm your SDK branch tracks Matter 1.6.1, and check the groupcast flag and its certification status.
Build a regression suite for groups, bindings and automations across an OTA update.
Add state verification after every group send.
Keep sleepy end devices out of multicast targets.
Decide whether NFC hardware belongs in the next board revision and split the SKU accordingly.
Read the Joint Fabric trust model in the specification before committing.
Map Product Security 1.1 requirements to your CRA technical file and name an owner for vulnerability reporting.
Test every new feature against a controller that does not support it.
Do not claim support on a platform until that platform has shipped it.

Frequently Asked Questions

What is new in Matter 1.6?

Matter 1.6, announced on June 17, 2026, adds no new device categories. Its headline items are NFC-based setup before a device is powered, an enhanced Joint Fabric for shared administration, Thermostat Suggestions, smaller independently updated certificate revocation lists, standardised reporting of device capabilities and limits, interoperable security-sensor event history, and an unmounted state for smoke and carbon monoxide alarms. Groupcast also appears as a provisional feature, and Product Security 1.1 ships alongside as a separate specification.

What changed in Matter 1.6.1?

Matter 1.6.1, published in September 2026, is a maintenance release with no new device types. It revises the Groupcast cluster, which consolidates group membership, keys and permissions and supports a shared multicast address, updates the Chime device type to support preinstalled sounds and a separate speaker endpoint, optimises access control, and refines camera streaming and clip recording. The matter.js 0.18.0 library implements it, and an Open Home Foundation Matter Server beta supports it.

How does Matter groupcast work?

A controller or switch sends one encrypted multicast message addressed to a group, and every device holding the matching group key acts on it. Keys live in keysets managed through Group Key Management, and membership is tracked per endpoint. Delivery is unacknowledged, so reliability depends on the network, and sleepy devices should not be targeted. In 1.6.1, a shared multicast address can replace per-group addresses, while dedicated addresses remain for older and battery-powered hardware.

Does Matter 1.6 NFC setup replace QR codes?

Not in the sources reviewed. NFC setup adds a path that works before a device is powered or installed, solving the hidden-label problem for items like bulbs in fixtures. QR codes and manual setup codes remain part of the onboarding story, and NFC requires hardware with a suitable tag or secure element, so it will appear first on new product revisions. Existing devices cannot gain NFC through a firmware update.

What is Joint Fabric in Matter?

Joint Fabric extends Matter’s Enhanced Multi-Admin so that multiple user-authorised controllers co-administer one shared fabric. A central datastore makes each added device accessible to all participating controllers, administrators can change without touching devices, and the shared fabric counts as one fabric slot on a device. The CSA points to new-build handovers, multi-platform homes and managed properties. Platform support determines real availability.

Is Product Security 1.1 the same as EU CRA compliance?

No. Product Security 1.1 is a CSA specification with two levels: Level 1, a supplier self-assessment reviewed by an Authorized Test Laboratory, and Level 2, an independent assessment plus functional testing. It lists controls such as unique device passwords, secure update verification and removal of test interfaces. These can serve as evidence, but the CRA also imposes vulnerability handling, reporting and documentation duties that a certificate does not satisfy.

Matter 1.6 and 1.6.1: Groupcast, NFC Setup, Joint Fabric, Product Security 1.1 (2026)