Sharing a Matter device across ecosystems, and where it runs out

What sharing actually does#

Adding a device to a second ecosystem does not copy it. It enrolls it again.

A fabric is a security domain with its own root certificate authority and its own 64-bit fabric ID. Apple Home is one fabric. Google Home is another. SmartThings is a third. When a device joins a second fabric it generates a second operational key pair, receives a second node operational certificate, and gets a second node ID. The two controllers never talk to each other. They both talk to the device, over your LAN, using different credentials.

That has three consequences worth internalizing before you start clicking:

• State is shared, control is not. Both controllers read the same attributes from the same clusters, so a light turned on in one app shows as on in the other within a subscription interval. Neither can see the other's automations, rooms, names or scenes.
• Access is per fabric. The access control cluster keeps a separate list of who may do what for each fabric, so removing one ecosystem's rights cannot lock out another.
• Nothing is synchronized. Names, groups, bindings and rules all have to be set up twice. Sharing a device is not a migration path, it is a second parallel installation.

If your goal is one app that shows everything, sharing devices is the wrong tool. See running two platforms on purpose for the pattern that actually holds up.

Sharing a device, step by step#

The wording differs by app and changes between releases, so match the intent rather than the exact menu label.

1. Confirm the device is already commissioned somewhere

   Multi-admin only exists once a first controller owns the device. If it is still in factory state, this is a normal commissioning job instead, and you should pair it to the ecosystem you use most first.

2. Open a commissioning window from the first controller

   In the app that already controls the device, find the accessory settings and the option to pair, share or add it to another platform. The controller sends an open-commissioning-window command to the device and displays a new setup code, usually as a QR code plus a manual code of 11 or 21 digits.

3. Note that this code is not the one on the box

   The original code on the label is the factory passcode, and it stopped being useful the moment the device was commissioned. The new code is generated for this window only, expires in minutes, and is single use. If you lose it, close the window and open a new one.

4. Run the pairing flow in the second app

   Choose add device, then the Matter option, and scan or type the fresh code. The second controller now runs the whole sequence itself: discovery, a PASE session from the passcode, device attestation against the alliance ledger, then installation of its own root certificate and a new operational certificate.

5. Provide network credentials only if asked

   A device already on your Wi-Fi or on a Thread mesh usually does not need credentials again, because it is already reachable. Some controllers still prompt. If yours offers to move a Thread device to a different network, decline unless you are deliberately consolidating meshes.

6. Name it and place it in a room, again

   The second ecosystem knows nothing about the first one's naming. Use the same names in both to keep voice control predictable, as covered in naming and room structure.

7. Verify from both apps

   Toggle the device in each app and watch the other update. If one app shows it as unresponsive while the other works, you have a network path problem rather than a fabric problem, and the pairing failure guide applies.

The five fabric floor#

The specification requires a certified device to support at least five fabrics. Five is a floor, not a target. Some silicon vendors allocate more, most consumer products do not advertise the number, and there is no reliable way to read the limit from a box or a product page.

Five sounds generous until you count what consumes a slot:

A four-person Apple household that also wants the device in Home Assistant and SmartThings can be at the limit with two ecosystems, not six.

The unpairing problem#

This is the part that costs people an afternoon.

Removing a device inside a controller's interface is supposed to send a remove-fabric command to the device, which frees the slot and deletes that fabric's credentials. In practice that command does not reliably reach the device. The controller deletes its local record, the tile disappears from your app, and the device keeps carrying credentials for a fabric nobody is using.

Common ways to strand a slot:

• Removing the device while it is offline or out of radio range.
• Factory resetting or replacing the hub before removing the devices it controlled.
• Deleting a home or an account rather than the individual accessories.
• Uninstalling an app instead of removing its accessories first.

Once a slot is orphaned, only a factory reset of the device clears it, and a factory reset drops every fabric, so you re-pair everything from scratch. Home Assistant ships a manage-fabrics interface that lists the fabrics a device carries and lets you remove them individually, which exists precisely because the automatic path is unreliable. That interface is also the fastest way to diagnose the problem, because it shows you how many slots are actually in use.

The safe habit is simple: remove before reset, and remove while the device is online and awake. The full order of operations is in removing and re-pairing devices cleanly.

Joint Fabric, and why it is not here yet#

Joint Fabric is the alliance's answer to everything above. It replaces "one fabric per ecosystem" with one shared fabric that several controllers co-administer.

The mechanics, as specified:

• An anchor administrator owns the root certificate authority and issues intermediate certificates to the other administrators, so they all operate inside one fabric.
• One fabric slot per device, regardless of how many controllers you use. The five-slot ceiling stops mattering.
• A shared datastore cluster holds the node list, the administrator list, group keys, bindings and access control entries, with each entry carrying a state such as pending, committed, delete pending or commit failed.
• Administrators are identified in device access rules by a tag rather than a node ID, so adding or removing a controller does not require touching every device.

Two corrections to the coverage you will see elsewhere. First, Joint Fabric is not new in 1.6: the joint fabric administrator device type has existed since Matter 1.4 as provisional, and Matter 1.6 (17 June 2026) is what made it certifiable. Second, and more important, nobody has shipped it. As of September 2026 there is no announcement from Apple, Google or Amazon, and SmartThings has signaled intent without a date.

The precedent is not encouraging. Fabric Sync, the 1.4 feature that let one ecosystem expose its devices to another, was never shipped by any ecosystem in more than 19 months. Ecosystems typically take 6 to 12 months to implement a new Matter release, and Joint Fabric asks them to share administrative authority over your home with a competitor, which is a product decision as much as an engineering one. Our Matter feature gap tracker records the current state per controller.

What to do in the meantime#

• Pick a primary ecosystem and treat the others as guests. Share to at most two, and only devices you genuinely need in both.
• Bridge instead of sharing where you can. A hub that presents many devices as one Matter bridge consumes a single slot on the bridge, not one per device, at the cost of the features a bridge drops.
• Do not share sensors you only read. If a device is a trigger for automations that live in one platform, it does not need a second fabric.
• Keep a record. Note which ecosystems each device belongs to. When you replace a hub, that list is what stops you from stranding slots.