A batch of in-wall switches may need to be identified and provisioned before the installer can power them. After the apartments are handed over, a different question emerges: can the resident and an authorized property operator both manage the devices without sharing one permanent administrator account? Matter 1.6 introduces a mechanism for each problem, but adopting one does not require adopting the other.
NFC-Based Commissioning moves the full commissioning exchange onto a bidirectional NFC channel, potentially before the device is fully powered. Joint Fabric lets multiple user-authorized controllers co-administer one shared Matter fabric. These are capabilities in a released standard, not evidence that a particular phone, controller, device firmware, or commercial ecosystem already supports the complete workflow. The Connectivity Standards Alliance (CSA) release announcement explicitly notes that product adoption will follow each company's own timeline.
Separate the installation problem from the ownership problem
NFC changes the near-field interaction used to bring a device onto a network. Joint Fabric changes the relationship among controllers after devices have been added. A project can need one and not the other. Treating both as a single “upgrade to Matter 1.6” requirement makes it difficult to tell what the supplier has actually delivered.
| Field problem | Feature worth evaluating | What the feature does not prove |
|---|---|---|
| A QR code or BLE exchange is awkward after installation | NFC-Based Commissioning | Every phone, NFC component, firmware build, and controller supports a full NFC exchange |
| Devices must be prepared before their final installation or power-up | NFC commissioning plus a traceable installation record | Any unpowered device can be commissioned in the same way |
| A resident, property operator, and service provider need continuing access | Joint Fabric | Existing commercial ecosystems automatically share membership and permissions |
| One party must be removed later | Joint Fabric membership and credential lifecycle | Revocation and recovery require no product or operational design |
The distinctions below draw on the CSA release announcement, its specification index, and public SDK guidance; this article does not claim to have verified the full specification text. No target phone, device prototype, commercial ecosystem combination, installation time, or cost has been measured. The recommendations are an evaluation sequence, not a compatibility claim.
NFC becomes a commissioning path, not just another way to read a code
Matter 1.4.1 allowed an onboarding payload to be stored on an NFC tag, while the subsequent commissioning exchange still relied on BLE. Matter 1.6 takes a different step: the entire exchange can happen through bidirectional NFC. That is why pre-installation setup becomes a plausible separate path instead of a QR-code replacement that still needs Bluetooth. The version distinction comes from the CSA's Matter 1.6 announcement.
The delivery change is in the sequence of work
For an in-wall switch, an installer might identify and authorize the unit before fixing its faceplate, then check network discovery and control after power is available. The standard's near-field capability makes such a workflow worth investigating. It does not make a pre-installation form equivalent to a powered acceptance test. The record should connect device identity, intended location, authorized controller, commissioning state, and the later verification result. Otherwise, a failure still leaves the team searching through visually identical devices.
Check four boundaries independently. Can the chosen hardware provide the necessary NFC interaction in the intended power state? Has the device firmware implemented that commissioning path? Can the actual phone or installation tool act as the commissioner? After installation, do discovery, network credentials, and application control work under project conditions? A failure in the latter checks should not automatically be blamed on NFC radio. A failure in the former should not be hidden by adding a QR label and calling the NFC path complete.
Battery devices, metal faceplates, and hard-to-reach mounting positions introduce further questions about proximity and tool placement. Those questions require a representative assembly, not an assumption about NFC range. This article offers no measured read distance, installation speed, battery behavior, or commissioning success rate, so it cannot support a labor-savings forecast.
A usable fallback matters more than a successful demo
Until target ecosystem support has been confirmed, NFC should not be the only field path. Define what happens when the device supports only the existing QR/BLE procedure, when an NFC exchange is interrupted, and when another party has already claimed the device. Can the installer identify whether the attempt is incomplete, safely retryable, or requires an authorized reset? The answer belongs in a test using the chosen SDK, controller version, and prototype logs—not in a marketing checkbox labelled “Matter 1.6 compatible.”
Pre-installation commissioning and post-power verification are separate acceptance points. The exception branch is a proposed fallback policy, not a report that this prototype has passed testing.
If the existing setup path is already unreliable, isolate network, controller, and device-state failures first. The Matter/Thread commissioning failure guide is a useful reference for the current path, not a substitute for an NFC pilot.
Joint Fabric changes controller membership, not the physical setup step
Matter's earlier multi-admin approach lets devices participate in different ecosystem fabrics. The CSA describes Matter 1.4 Enhanced Multi-Admin as a way to automate sharing with one user consent while retaining separate fabrics. Matter 1.6 Joint Fabric offers another relationship: multiple user-authorized controllers can co-administer a single fabric coordinated through a central Datastore. According to the CSA, participation consumes one fabric slot on the device, while the device can also join traditional ecosystem fabrics. That is a statement about the standard's model; it does not prove that a given device or controller combination can be deployed this way today.
“Both phones can turn on the light” is an incomplete handover test
Consider apartments provisioned by an integrator before move-in. Residents will later use their own interfaces, while an authorized property operator may need access for maintenance. Sharing one administrator account among these parties makes it hard to revoke the integrator, trace who issued a command, or replace the property operator. Joint Fabric points toward independently adding or removing authorized controllers in a shared network rather than distributing a permanent password.
The image illustrates the people and records involved in a handover; its phone screens do not show a tested ecosystem result.
Sharing a fabric also creates an ownership question. Who approves a controller? Who runs the Datastore and associated credentials? Who restores access when an administrator fails? Who verifies that removing one party leaves the others operational? The official Joint Fabric Guide describes control and administrator example applications, PKI responsibilities, and a Datastore. Those examples establish an implementation path to investigate, not a turnkey property-management product.
Access scope cannot be settled merely by saying “all parties are on one fabric.” A delivery design still needs an authorization request, user consent, an audit trail, revocation, and a recovery owner. Without them, shared connectivity may work in a demonstration while the operational handover remains unresolved.
When the existing multi-admin path is enough
If the customer only needs a few devices added to two established ecosystems and the existing flow meets that requirement, introducing shared-fabric governance may add work without solving a real problem. Joint Fabric merits a prototype when several parties truly need continuing, coordinated access and the present sharing, revocation, or fabric-capacity arrangement is a constraint.
If the team has not yet decided whether the product needs multiple consumer ecosystems at all, settle the Tuya + Matter product-path decision first. That is an entry-point choice, not the shared-administration decision examined here.
It should not be sold as a guaranteed reduction in setup steps. How many actions are saved, whether an administrator can be removed cleanly, and what happens during a Datastore outage all depend on actual controller implementations and operational rules. No such outcome is measured here.
Choose among three delivery paths before budgeting an upgrade
The useful choice is rarely “all of Matter 1.6 or none of it.” Identify which work step is painful, then evaluate only the capability that could change it. This is a review framework, not a performance ranking.
| Primary constraint | Path to test first | New burden or risk | Cost of staying put |
|---|---|---|---|
| Provisioning before power-up or at an awkward mounting point | End-to-end NFC commissioning | Device/tool/controller version fit; interruption recovery; powered recheck | Installers retain the existing close-access setup step, potentially creating rework |
| Continuing access and later revocation across organizations | Joint Fabric | Administrator credentials, central coordination, membership lifecycle, recovery ownership | Independent fabrics or manual sharing remain; multi-party operations may be fragmented |
| A small home deployment already works with QR/BLE and conventional sharing | Keep the tested process | Continue supporting its current compatibility path | The new features are unavailable, but no known project requirement is left unmet |
“Potential rework” is not a quantified result. Compare installation time, failure records, and support cost in the same site conditions before claiming that NFC offsets added hardware or tooling. Similarly, the prospect of less repetitive sharing does not erase the cost of operating credentials and a Datastore. Put these unknowns in the pilot budget instead of turning a standards announcement into a return-on-investment calculation.
If both problems matter, test them in separate stages. First, prove that a representative device can be commissioned within the actual installation sequence and verified after power-up. Then use explicit two- or three-party roles to exercise joining, consent, removal, and recovery. If the second stage fails, the team can investigate governance rather than treating the entire delivery chain as an undefined “NFC problem.”
Assign an owner to the failure path
An interrupted NFC attempt needs a visible recovery state. An installer should be able to tell whether the device remains unclaimed, was already accepted by a controller, or requires an authorized reset. “Try again” alone can create duplicate ownership attempts. When one Joint Fabric member leaves, the platform owner needs a way to confirm the remaining members' access and to recover from a credential or Datastore failure. The target SDK and pilot must establish how these states are observed and recorded.
If a supplier cannot demonstrate version support and the recovery procedure, keep the project status at “not yet validated.” The cost of deferring the feature can be measured after a pilot. Promising an unverified path to a customer converts a technical unknown into a delivery obligation.
Turn the standard into four separate verification records
A version number is a starting point, not an acceptance record. The Matter Handbook development table lists both the official SDK and the JavaScript SDK as conforming to Matter 1.6, yet it also warns that the JavaScript SDK has not implemented every protocol feature. SDK version alignment alone therefore does not establish a complete NFC or Joint Fabric path, let alone support from Apple, Google, Amazon, or a customer application. Verify the specific feature and release for each target ecosystem.
Keep four records distinct during evaluation:
- Standard and implementation boundary. Record the exact specification, device and controller SDK versions, required features, and known gaps. The CSA specification index lists both 1.6 and 1.6.1. A later correction or implementation update is a reason to recheck the exact version used, not to cite only the launch announcement.
- Pre-installation to in-service handoff. With representative devices and the actual phone or tool, capture NFC discovery, authorization, interrupted exchange, and discovery and control after power-up. Repeat in the intended enclosure, mounting position, and power condition.
- Shared administration lifecycle. In the chosen controller combination, exercise authorized joining, shared access, removal of one participant, replacement of an administrator, Datastore unavailability, and recovery. Record device visibility and control after each transition. A customer who does not need shared administration need not fund this entire experiment.
- Delivery and support responsibility. Name the holder of credentials, the approver for additional controllers, and the party responsible for a device reset or field recommissioning. The standard does not allocate these duties among the integrator, resident, and property operator.
Without those tests, this is a research and pilot plan, not a passed compatibility matrix. Do not put “Matter 1.6 support” into a procurement requirement as a blanket promise for every ecosystem, phone, and mounting location.
For the product decision, ask two independent questions. Is the installation sequence actually constrained by when and how the device can be reached? Do multiple parties truly need continuing access and revocation after handover? If only the first is true, investigate NFC hardware, tools, and fallback. If only the second is true, investigate Joint Fabric controller support and governance. If neither is true, retain the already validated process and revisit adoption when target ecosystem support is clear.
This article interprets the CSA announcement, specification index, and public SDK guides. It does not contain NFC prototype, commercial ecosystem, performance, security, cost, or production delivery tests. Product compatibility and operational gains still require evidence from the chosen device, controller releases, and project acceptance records.