Matter and Thread are frequently mentioned in the same breath, and product teams sometimes treat "supporting Matter" as a single checkbox. It isn't — the two are different layers of the stack, they impose different requirements on hardware and firmware, and adopting them is a real architectural commitment, not a software update applied late in development. Understanding what each one actually does is the first step to deciding whether and how to adopt them.
Thread is the network, Matter is the application layer
Thread is a low-power, IPv6-based mesh networking protocol — it's concerned with how devices form a network, route data hop-to-hop, and stay connected reliably at the radio and networking level. Matter is an application-layer standard that sits above the network layer and defines how devices describe themselves and their capabilities (a light, a lock, a thermostat) in a common way, so that a controller from one company can understand and control a device from another. Matter is explicitly designed to work over more than one network transport — Thread is one of them, and Wi-Fi is another, particularly for devices that need more bandwidth or are already mains-powered. The relationship, in short: Thread can carry Matter traffic, but Matter doesn't require Thread, and Thread has uses (including in other ecosystems) beyond just carrying Matter.
What supporting either one changes about the hardware and firmware
Adding Thread support means the product needs an 802.15.4-capable radio — either a dedicated Thread/Zigbee-class radio or a multiprotocol SoC that can run Thread alongside other stacks — which is a silicon selection decision made early, not something layered onto an existing design. Supporting Matter adds a certification and compliance path on top of whatever transport is chosen: Matter devices go through a formal certification process to earn the ability to claim Matter compatibility, which means budgeting real engineering time and calendar time for that process, not just implementation time. Firmware architecture is affected too — Matter's device model and commissioning flow (the process by which a new device joins a network and is claimed by a controller) has to be implemented against the standard's specification, which is a meaningfully different firmware surface than a proprietary pairing and control protocol built in-house.
Early adoption versus staying proprietary — a real tradeoff, not a foregone conclusion
Building against Matter and Thread from the outset buys interoperability with a growing set of controllers and ecosystems, and reduces the risk of building a product that becomes an isolated island as the industry consolidates around shared standards. But the standards and their supporting tooling are still maturing, and building against a moving target has real costs: certification requirements and reference implementations continue to evolve, and a team building early sometimes has to rework parts of an implementation as the specification and tooling stabilize. Staying with a proprietary or existing protocol avoids that churn and can mean faster time to market for a first product, at the cost of not getting the interoperability story that's becoming increasingly expected by both retail buyers and other ecosystem players. There isn't a universally correct answer here — it depends on the product's timeline, how much the target customer segment currently cares about cross-ecosystem interoperability, and how much engineering capacity the team can dedicate to tracking a standard that's still moving.
Practical takeaway
Deciding whether to build on Matter and Thread is a hardware, firmware, and certification-timeline decision that needs to be made together, early, with eyes open about the standards' maturity rather than treated as a marketing checkbox. See our embedded hardware and firmware work for how we think through that tradeoff on real products.