Short Answer: The Best First Controller Depends on Radio, Features, and Which Phone Already Knows the Thread Network

There is no magical permanent "primary controller" in Matter. Matter devices can join multiple controller fabrics, so the better question is not "Who owns the device forever?" but "Which onboarding path will be cleanest for this specific device?"

For most new Matter-over-Wi-Fi devices, pair directly to Home Assistant first, then share out to Apple Home or Google Home if the household wants those interfaces too. For Matter-over-Thread devices, start with whichever ecosystem already has the working Thread credentials on your phone and in the home, then share to the other controller. And if the product already has a strong native local Home Assistant integration, do not assume a Matter bridge is the better path just because it sounds more universal.

Tara's practical rule: let Home Assistant be the automation brain, but let the first pairing follow the most reliable radio and phone-credential path you actually have today.

Why This Question Keeps Coming Up

This is not a theoretical corner case. As of June 20, 2026, the Home Assistant Matter/Thread category was still full of active onboarding and commissioning threads, including topics like Can not commission matter device (Matter integration broken?), HA unable to pair Level Lock which is connect to Apple Home, and Unable to pair IKEA Matter devices to HA. On May 13-14, 2026, a Home Assistant Community thread asked the exact question out loud: should Home Assistant or Google/Apple be the first Matter controller?

Reddit is using nearly the same language. Recent threads ask about Matter via Apple Home and THEN Home Assistant and whether dual pairing across HomeKit and Home Assistant is better than bridging. Owners are not debating whether Matter is local. They are trying to figure out which commissioning path wastes the least time.

The official Home Assistant guidance reflects that confusion. The Matter docs split onboarding into two separate paths: adding a new device and adding a device that is already in use by another controller. That split exists because direct commissioning and multi-admin sharing are different workflows with different failure modes.

Home Assistant's own story around Matter changed materially over the last year. On March 10, 2025, Home Assistant announced its Matter certification and framed Matter as a fully local, multi-ecosystem standard. On April 1, 2026, Home Assistant 2026.4 added direct user and PIN management for Matter locks, and the June 3, 2026 release referenced that Matter work again when bringing similar credential management to Z-Wave locks. That does not mean every commissioning problem is solved. It does mean Home Assistant is now mature enough that the HA-first option is worth taking seriously instead of treating it like a science experiment.

First Principle: Matter Uses Fabrics, Not a Permanent Boss Controller

The official Matter docs describe multi-fabric support as one of the standard's key features: the same device can join multiple controllers, including Home Assistant, Apple Home, and Google Home. Home Assistant's docs also separate each controller into its own fabric, which is the real unit that matters here.

That means the common idea of a permanent primary controller is mostly the wrong mental model. Inference from the docs: the first controller mainly affects the commissioning path, the Thread credentials available on your phone, and the platform-specific features that might still live outside the generic Matter surface. It is not a one-time throne selection that decides the rest of the device's life forever.

If your situation is... Start here Why
New Matter-over-Wi-Fi device and Home Assistant will run the automations Pair directly to Home Assistant No Thread dependency, simple commissioning path, and you can share the device out later if the house also wants Apple Home or Google Home.
Matter-over-Thread device and Apple Home or Google Home already has the working Thread network on your phone Often Apple or Google first, then share to Home Assistant The current Thread onboarding path still depends heavily on which credentials the mobile device can actually use during commissioning.
Bridge product or ecosystem with a rich local Home Assistant integration Compare the native integration before using Matter Matter can simplify interoperability, but it can also flatten the feature set down to the common denominator.

When Pairing Directly to Home Assistant First Is the Right Move

For Wi-Fi-based Matter devices, Home Assistant first is usually the cleanest default. The Matter docs are explicit that Home Assistant can add a new device directly through the companion app, and you do not need Thread hardware for Wi-Fi Matter. You need the latest Home Assistant release, the Matter integration and Matter server, the latest companion app, Bluetooth on the phone, and the phone close to the device during commissioning.

This path is especially clean when Home Assistant is the actual brain of the house: naming, rooms, automations, dashboards, and presence logic will all live there anyway. In that case, it is usually better to commission into Home Assistant first and share the device to Apple Home or Google Home afterward if you want voice control, shortcuts, or a familiar family-facing app.

Home Assistant's docs support that flow directly. After a device is in Home Assistant, you can use the Share device action from the Matter device page to join the same hardware to another controller. The benefit is operational clarity: Home Assistant owns the automations, but the household still gets the other front-end if it wants it.

This is also the most honest route if your goal is a local-first home. Home Assistant's Matter docs say Matter products run locally and do not require cloud control at the protocol level. Commissioning directly to Home Assistant keeps that structure obvious from day one.

Local smart home hub server with wired and radio connectivity for Home Assistant
In a Tara-style home, Home Assistant is usually the logic layer and long-term operating surface, even when Apple Home or Google Home still exist as secondary interfaces for residents.

When Apple Home or Google Home First Is the Smarter Move

Thread changes the answer. Not because Apple or Google become more powerful controllers, but because the current commissioning flow still depends on your phone and on which Thread credentials it already has available.

The Thread docs spell this out very plainly. Before you can add Matter-over-Thread devices, your phone needs to know the Thread network credentials. If Home Assistant created the Thread network, Android owners need to run Sync Thread credentials in the companion app, while iPhone owners need to use the Thread integration's Send credentials to phone action. If Apple or Google already created the Thread network, Home Assistant can import those credentials and make that network preferred.

There is an important nuance in the current docs: the preferred network function is not completely implemented yet, and when adding Matter devices through the companion apps, the mobile device's preferred network may still be used. That means your controller choice is partly a phone-credential choice whether you like it or not.

Inference from the current docs plus current issue traffic: if Apple Home or Google Home already has the Thread mesh working on your phone and in the home, pairing there first and then sharing the device to Home Assistant is often the path of least resistance. This is not because Home Assistant is inherently the wrong controller. It is because a known-good Thread path beats a cleaner architectural ideal every time.

This is also where people confuse border routers with controllers. Home Assistant's Matter docs note that third-party Thread border routers can be used by Home Assistant without forcing you to adopt those ecosystems as the permanent device owner. A HomePod Mini or Nest Hub can be the radio path while Home Assistant still acts as one of the Matter controllers.

Practical translation: you can use Apple or Google because that is where the Thread mesh already works, not because you want Apple or Google to run the whole house forever.

Sometimes the Right Answer Is Neither: Use the Native Integration Instead of Matter

The Matter docs also caution against assuming that the most interoperable path is the best path. Home Assistant gives Philips Hue as the clearest example: the local native Hue integration exposes more features than adding the Hue bridge via Matter. The same general rule applies to other bridge-centric ecosystems. Matter may make the device easier to share across platforms, but it can also flatten the feature set down to the common denominator.

That is why the real decision tree is not only Home Assistant first versus Apple/Google first. Sometimes the better answer is native Home Assistant integration first, with Matter used only where it adds something real.

If your goal is specifically to make Home Assistant entities appear in Apple Home, that is a separate architecture question again. In many homes, HomeKit Bridge is still cleaner than trying to force every device relationship through Matter.

The Gotchas That Make the Wrong First Controller Feel Broken

1. "Your device requires a Thread border router" usually means credentials, not philosophy

A current Android issue shows a deeply confusing failure mode: the error says a Thread border router is required even though Home Assistant already is the Thread border router. The issue description points to the phone not actually holding the right Thread credentials during pairing. In plain English, the radio may exist, but the onboarding path still does not know how to use it.

2. Thread credentials can look synced while Matter still disagrees

A current Home Assistant Core issue describes a case where the companion app appears to pass Thread credentials, but Matter diagnostics still report that Thread credentials are false and commissioning fails. This is one reason people conclude that Apple-first or Google-first is more reliable. Sometimes that conclusion is not architectural at all; it is just the result of a credential-sync bug.

3. If the device joins Thread but cannot be reached, check IPv6 before resetting everything

The Thread docs remind users that Thread is an IPv6-only protocol. If a device joins the mesh but then becomes unreachable, the failure may be in IPv6 routing, forwarding, or container/VM networking instead of in the QR code, the border router, or the controller choice. If your network is segmented, also remember that Matter still prefers a very boring local network. Tara's own main LAN vs IoT VLAN guide explains why overly clever segmentation often becomes the hidden saboteur.

4. Installation type still matters

The official Matter docs say the supported path is Home Assistant OS, while container-based Matter setups are possible but effectively at-your-own-risk. If you are already debugging multi-admin, Thread credentials, and border routers, adding an unsupported install pattern can turn a simple pairing question into three overlapping problems.

Tara's Recommendation

For a real house, I would use this rule set:

  • Wi-Fi Matter device: pair it to Home Assistant first, then share it outward if the home also wants Apple Home or Google Home.
  • Thread Matter device with an existing Apple or Google Thread mesh: use whichever ecosystem already has the working phone credentials and border-router path, then share it to Home Assistant.
  • Bridge device or ecosystem with a rich local integration: compare the native Home Assistant integration before defaulting to Matter.

The goal is not ideological purity. The goal is a home that pairs cleanly, stays local, and still lets Home Assistant centralize the automations. Matter is at its best when it gives you choice, not when it tricks you into rebuilding a stable device path just to satisfy a diagram.

For locks, garage doors, and other entry points, test every fabric and app path before relying on it. A device being visible in multiple controllers is not the same as every household workflow being proven under real use.

If you are deciding where Matter, Thread, Apple Home, and Home Assistant should meet, these guides cover the adjacent pieces that usually decide the final architecture.

FAQ

Is there a real primary Matter controller?

Not in the way most people mean it. Matter devices can join multiple fabrics, and Home Assistant's docs explicitly support both direct commissioning and sharing from another controller. The first controller mainly changes the onboarding path, available Thread credentials, and sometimes the easiest access to platform-specific extras.

Should I pair Wi-Fi Matter devices directly to Home Assistant first?

Usually yes. Wi-Fi Matter does not need Thread hardware, and Home Assistant's direct commissioning flow is straightforward once the Matter integration, Matter server, and companion app are current. If the household also wants Apple Home or Google Home, share the device out afterward.

When should I add a Matter device to Apple Home or Google Home first?

Usually when it is a Thread device and that ecosystem already has the working Thread network on your phone, or when the household depends on that platform's onboarding or device-side features. Pair there first, then add Home Assistant as another controller using the already in use flow.

Why does Home Assistant say a Thread border router is required when I already have one?

Because the problem is often the phone's Thread credentials, not the physical existence of the router. Current Home Assistant issues show that the companion app can fail to use or propagate the right credentials even when the Thread network itself exists.

Is a Matter bridge always better than a native Home Assistant integration?

No. Home Assistant's Matter docs warn that some native local integrations, such as Hue, expose more features than the same ecosystem through Matter. Use Matter when interoperability is the win, not by default.