What is a Thread border router, and do you need one?

A Thread border router is the gateway between a Thread mesh and every other network. OpenThread states that a Thread network requires a border router to connect to other networks, such as Wi-Fi or Ethernet, and lists what OpenThread Border Router does:

• Routes IP traffic both ways between Thread and Wi-Fi or Ethernet.
• Bridges service discovery, using mDNS on Wi-Fi or Ethernet and SRP on the Thread side, so a controller on Wi-Fi can find a Thread device by name. Google’s Matter primer describes the border router publishing discovery records on behalf of Thread devices.
• Merges Thread partitions over IP links, called Thread over infrastructure.
• Lets an external commissioner, such as a phone app, authenticate and add a new Thread device.
• Connects to IPv4 networks through NAT64, and obtains IPv6 prefixes for the Thread network through DHCPv6 prefix delegation.

Inside the mesh, routing is done by Thread routers and a leader that the network elects for itself, as OpenThread’s node roles describe. The border router is the node on the edge. What is a gateway in a mesh network? covers the pattern in general.

Only Matter devices that use Thread need a border router. Matter runs over Wi-Fi, Thread or Ethernet, and the maker chooses which. A Matter plug on Wi-Fi joins your Wi-Fi directly and needs no border router. A Matter door sensor on Thread cannot reach your phone or controller without one.

The platforms say the same. Apple says Thread-enabled Matter accessories require a Thread-enabled home hub, such as HomePod mini or Apple TV 4K (3rd generation) Wi-Fi + Ethernet. Amazon says Thread-enabled Echo and eero devices act as border routers to provision and secure Thread networks, and that Alexa passes the Thread network credentials to a new Matter device over Bluetooth LE during setup. How does Matter commissioning work? covers that setup step.

Check the device’s packaging or listing for the network it uses. “Matter over Thread”, “Thread” or the Thread logo means you need a border router.

To find out whether you already own a border router, check your devices against their makers’ lists, or look for the service every border router announces. These are the products each vendor’s own page named as Thread border routers in October 2026:

Product lists change, so check the vendor’s current page before you buy. Then, depending on what you run:

1. Apple Home: open the Home app, tap More, then Home Settings, then Home Hubs & Bridges. Apple says the active hub appears at the top. If it is a HomePod mini, a HomePod (2nd generation) or an Apple TV 4K with Thread, you have a border router.
2. Google Home: compare your speakers, displays, Wi-Fi points and streamers with the “Wi-Fi and Thread” list on Google’s hub page.
3. Alexa: compare your Echo and eero devices with Amazon’s list.
4. Home Assistant: go to Settings, then Connectivity, then Thread. Home Assistant discovers every Thread border router on the network over mDNS and groups them by Thread network, whichever brand made them.
5. Any computer on the home network: OpenThread notes that the Thread specification requires every border router to publish a _meshcop._udp service. On a Mac, dns-sd -B _meshcop._udp local lists each border router that answers.

A Thread network can have more than one border router, and that helps. The Thread Group says adding border routers to the same network makes the mesh stronger, farther reaching and more reliable, and OpenThread’s node roles note that a Thread network can have several. Home Assistant puts it as reducing the risk of a single point of failure.

The catch is the words “the same network”. Two border routers only back each other up if they run the same Thread network with the same credentials. The next section covers why that often does not happen by default.

Thread networks from different brands often stay apart because each vendor tends to form its own Thread network, with its own credentials, when you first set up its products. Home Assistant’s documentation says you can end up with a Home Assistant, an Apple and a Google Thread network in one home, and that devices cannot roam between them. You then have three meshes that each need their own border routers, instead of one stronger mesh.

The fix is credential sharing, and the standards and platforms now provide it:

• Thread 1.4 lists credential sharing first among its features. The Thread Group says it standardises how devices and border routers, whatever the manufacturer, recognise and trust each other, and that Thread 1.4 is fully backward compatible.
• Apple’s ThreadNetwork framework keeps a database of Thread network credentials. Its THClient class lets apps request the credentials for a network or for the preferred network, which Apple describes as the default Thread network the framework chooses for a home.
• Google’s Thread Network SDK lets Android apps request the preferred Thread credentials from Google Play services, and Google tells border router makers to use them so devices end up on a single Thread network where possible.
• Matter 1.4 defined home routers and access points that include a Thread border router, with secure storage and sharing of Thread network credentials.
• Home Assistant can import your phone’s preferred Thread network through its Companion app, so its own border router can join that network. Home Assistant notes that its border router joins the preferred network only if it has not already formed a Thread network of its own.

In practice, set up your main ecosystem’s border router first, then let other border routers join its network through these sharing paths rather than forming their own.

When a border router goes offline, Thread devices lose their link to the rest of the home network, unless another border router on the same Thread network takes over. Controllers on Wi-Fi or Ethernet reach Thread devices only through a border router, so with none available, apps and voice assistants cannot control them.

The mesh itself does not depend on the border router to exist. Apple’s ThreadNetwork documentation describes Thread meshes as having no single, centrally defined router and as maintaining communication when some devices go offline, and the leader role is self-elected for fault tolerance. Traffic between Thread devices and anything off the mesh still has to wait for a border router.

Three habits keep this from becoming an outage:

1. Run at least two border routers on the same Thread network, in different rooms.
2. Put border routers on backup power if Thread devices such as locks must keep answering during a power cut.
3. After a border router restarts, check in your app that Thread devices respond again before relying on them.

A phone usually cannot talk to Thread devices directly. It reaches them over IP through a border router. The Thread Group says Thread does not need to be in your phone to connect to Thread products, because both are on the same IP network once a border router links them, and Apple’s ThreadNetwork documentation describes the border router as what enables iOS devices to communicate with Thread devices.

Some phones do have a Thread radio. Apple lists “Thread networking technology” in the iPhone 15 Pro’s specifications. Apple’s developer documentation still routes everyday Thread control through border routers, so plan on owning one either way.

A Thread border router is the gateway pattern: one device bridges a low-power mesh to the IP network, and everything off the mesh depends on it. Phones running an app-level mesh work differently. With Offline Protocol, apps on phones discover each other and relay messages over Bluetooth LE themselves, and use a local network or an internet relay when one is there, so there is no border router to buy or lose. That is a different job from bringing Thread devices onto a home network. Offline Protocol does not speak Thread, does not act as a border router, and does not control Thread or Matter devices.