Building a Matter smart home device requires coordinated decisions across product architecture, hardware, firmware, setup, security, applications, testing, certification, and lifecycle support. Decisions made early can affect development cost, time to market, product reliability, and the customer’s setup and ownership experience.

This guide reflects Matter 1.6, released in June 2026. Release-specific capabilities and support across commercial ecosystems continue to evolve, so product teams should verify current Connectivity Standards Alliance (CSA) and platform requirements before finalizing product requirements.

Where Matter Fits in the Product Architecture

Matter sits at the application layer of a connected product. It defines how supported device functions are described and controlled across compatible smart home ecosystems. Matter relies on IPv6 networking, which can be carried over Wi-Fi, Thread, or Ethernet.

During setup, a commissioner authenticates the device and adds it to a Matter fabric, a trusted environment that allows Matter devices to securely communicate and access shared services. Controllers can then read device status and send commands for the functions supported by both the product and the ecosystem.

Define the Product Experience and Matter Scope

Product planning should begin with the experience the manufacturer wants to deliver. That includes deciding which functions customers should be able to use through common smart home platforms and which capabilities will remain in the manufacturer’s application, cloud services, or device interface.

Matter can expose shared controls and status information that compatible smart home platforms use in automations. Product differentiation may come from advanced configuration, diagnostics, analytics, specialized workflows, premium services, or features that are not represented by the Matter data model.

This distinction helps determine what must be implemented in the device firmware, what belongs in the mobile and cloud architecture, and which product functions must be tested across each target ecosystem. It also prevents the assumption that adopting Matter will automatically expose every feature consistently across all platforms.

Engineers then map interoperable functions to Matter device types and clusters, which define how those functions are represented. They also assess whether the selected hardware, SDK, and target ecosystems support the intended experience. Gaps may require a companion application, proprietary service, different architecture, or revised product requirements.

Select the Operational Network and Hardware Platform

Once the product scope is defined, hardware and operational-network choices affect development cost, power consumption, installation, commissioning, certification, and the capacity to add features over time.

The appropriate design can vary across a product family. A battery-powered sensor has different processing, memory, and connectivity requirements from an in-wall control, camera, gateway, or touchscreen panel. More capable products may require an application processor and a separate connectivity module, while simpler devices may run on a single wireless MCU or SoC.

Matter devices can operate over Thread, Wi-Fi, or Ethernet. Thread is commonly suited to low-power products that benefit from mesh networking. Wi-Fi supports devices with greater bandwidth needs or direct LAN connectivity. Ethernet, including Power-over-Ethernet designs, can provide stable networking and power for fixed or professionally installed products.

Teams should evaluate processing capacity, flash and RAM, radio support, RF and antenna design, secure credential storage, hardware cryptographic acceleration, power requirements, diagnostics, and firmware-update capabilities. They should also assess the maturity of the Matter SDK and the silicon vendor’s platform support, documentation, tooling, update roadmap, and technical support.

Some existing products can adopt Matter through firmware. Others require new hardware because of limitations in connectivity, memory, security, processing, or update architecture. Identifying those constraints early avoids committing to a software migration that the installed product cannot support reliably.

Design the Setup and Installation Experience

Setup is the customer’s or installer’s first direct experience with a Matter product. Its design must account for how the device is packaged, powered, installed, connected, and transferred to its eventual owner.

Matter products can provide onboarding information through QR codes, manual codes, or NFC. The commissioning exchange may use Bluetooth Low Energy, Wi-Fi Unsynchronized Service Discovery (USD), or, in Matter 1.6 and later, bidirectional NFC, depending on the hardware, Matter revision, commissioner, and target ecosystem.

Behind that visible setup flow, a commissioner discovers and authenticates the device, provides any required network credentials, and securely adds it to a Matter fabric. These stages affect firmware, mobile applications, manufacturing data, installation procedures, and recovery behavior.

Product teams should define the primary setup path, installer and consumer workflows, recovery from interrupted setup, and a fallback method when the preferred option is unavailable. Each supported path must be validated across the intended phones, hubs, networks, and smart home ecosystems.

A technically compliant device can still create support costs and customer frustration when it is difficult to install, recover, or transfer.

Plan for Multi-Ecosystem Operation and Ownership

Multi-ecosystem behavior depends on the functions each platform supports and how the manufacturer has implemented them. Product teams should identify the ecosystems they intend to support and define the controls, status information, and setup flows that must work consistently across them.

Matter’s Multi-Admin capability allows the same device to be commissioned onto separate fabrics managed by different ecosystems. Joint Fabric, introduced in Matter 1.6, lets authorized controllers co-administer a shared fabric. Because implementation varies among SDKs and commercial ecosystems, Joint Fabric should be included in product requirements only after target-platform support is confirmed. The choice depends on the product, ownership model, and deployment context, such as a private home, managed property, or new-construction project.

The product strategy must also address fabric removal, factory reset, recommissioning, and transfer to a new owner or property manager. Poorly designed transitions can leave devices inaccessible, duplicated across platforms, or difficult to recover.

Decide Whether the Product Needs a Border Router or Matter Bridge

A Thread product reaches the home’s wider IP network through a Thread Border Router. Product teams must decide whether to rely on compatible Thread Border Router infrastructure already present in the target environment or include Border Router functionality in another powered product. That choice affects installation assumptions, network recovery, and the environments the company can support.

A Border Router routes IP traffic between Thread and networks such as Wi-Fi or Ethernet. It does not translate the Matter application model. A Matter bridge serves a different purpose: it exposes supported functions from devices using non-Matter technologies, such as Zigbee or Z-Wave, as Matter endpoints, allowing them to appear as controllable devices in compatible ecosystems.

Bridging can help manufacturers bring an existing installed base into Matter ecosystems without replacing every deployed product. For companies managing several product generations, the roadmap may combine native Matter devices and bridged products. Each bridged product still requires a decision about which functions Matter can represent and which remain available only through the manufacturer’s application or system.

Build Firmware and Companion Applications as One Product System

The software architecture must connect the Matter implementation with the product’s local controls, companion applications, cloud services, diagnostics, and update mechanisms. Customers experience the resulting system as one product.

A companion application can play several roles, including commissioning devices, controlling them directly, managing advanced configuration, supporting diagnostics, or connecting users with account and cloud services. The exact role depends on the product strategy and on what platforms such as Apple Home, Google Home, Amazon Alexa, and Samsung SmartThings already provide.

The architecture also needs clear rules for synchronizing settings and device state across the product, manufacturer application, cloud platform, and external ecosystems. It must define what happens when internet connectivity is unavailable and which system remains authoritative when commands or configurations conflict.

These decisions affect firmware architecture, APIs, data ownership, recovery behavior, and long-term maintenance. Unresolved synchronization and ownership issues often surface during late-stage testing or after deployment.

Design Security and Manufacturing Provisioning

Matter security begins with the identity and credentials assigned to each manufactured device before it reaches the customer. Manufacturers need a controlled process for generating, protecting, and provisioning those credentials while preventing private keys and other sensitive information from being exposed through manufacturing or service workflows.

Matter device attestation relies on a Device Attestation Certificate (DAC), which is signed by a Product Attestation Intermediate (PAI) and ultimately chains to a trusted Product Attestation Authority (PAA). Each certified device is provisioned with its unique DAC, corresponding private key, and Certification Declaration. The PAA serves as the commissioner’s trust anchor and is not provisioned to the device. Manufacturers and production partners must therefore establish secure processes for issuing, protecting, and provisioning per-device attestation credentials throughout manufacturing and across product generations.

The product must provide a secure firmware-upgrade mechanism and protect its device credentials. Product security should also include signed firmware verification, protected key storage, access control, and, where supported by the selected platform, secure or verified boot. Manufacturers should also have a process for attestation-certificate lifecycle management, including handling compromised or invalid DACs and, where applicable, revoking them, and should define how long security updates and vulnerability responses will be provided after launch.

The Connectivity Standards Alliance’s Distributed Compliance Ledger (DCL) publishes compliance, provenance, and attestation-trust information used by the Matter ecosystem. It is not a fleet-management or operational registry for individual deployed devices.

Engineering and production teams need to design these controls together. Weaknesses discovered late can force hardware changes, delay certification, disrupt manufacturing, or create expensive remediation after devices are already deployed.

Test Across Devices, Networks, and Ecosystems

Matter conformance is only one part of product validation. A device also needs to behave reliably across the phones, hubs, routers, Border Routers, mobile platforms, and smart home ecosystems included in the product’s support plan.

Testing should cover the complete operating lifecycle: commissioning, network changes, multiple administrators, resets, recommissioning, firmware updates, connectivity loss, and recovery. It should also cover older controllers, changes or replacement of Border Routers, optional Matter features, and interaction with the manufacturer’s companion application.

Products intended for several ecosystems should be validated for differences in setup, controls, status reporting, and feature availability. A support matrix can then document the platforms, Matter versions, commissioning paths, network configurations, companion applications, and product capabilities tested together. That matrix provides a firmer basis for launch decisions, support commitments, and future updates while exposing interoperability gaps before launch.

Prepare for Matter Certification

Matter certification belongs in the development plan from the beginning. The product’s device model, supported features, network technology, and implementation choices determine what must be tested and documented.

Using certified components or platforms may reduce the certification testing required for qualifying products, so available inheritance paths should be considered when selecting the hardware platform and Matter SDK.

Depending on the go-to-market plan, manufacturers may also need ecosystem-specific qualification or “Works With” programs. Those requirements remain separate from Alliance Matter certification.

Early certification planning exposes gaps while firmware and architecture can still be adjusted. Certification verifies conformance with the applicable Matter requirements, but it does not replace the broader ecosystem and real-world validation needed to support the product after launch.

For the formal certification process, documentation, inheritance options, and recertification requirements, see Matter Certification.

Plan for Updates and Product Lifecycle

A Matter product continues to evolve after certification and launch.

Over-the-air (OTA) update capability should be designed in from the beginning so deployed products can receive defect fixes, security patches, and functionality updates. Each release still requires validation across the product’s supported networks, applications, and smart home platforms.

New Matter specifications also require product-level decisions. Some capabilities may fit existing hardware and be introduced through firmware, while others may require new silicon, additional resources, recertification, or support that is not yet available in the target ecosystems.

Software changes can also have certification implications, so significant SDK or firmware releases should undergo a certification-impact review. Recertification requirements and available streamlined paths depend on the nature of the product change.

The lifecycle plan should define the security-support period and software-maintenance responsibilities. It should also specify supported Matter revisions, ecosystem/controller versions, companion-application compatibility, and the criteria for moving new capabilities into a future hardware generation.

Matter Development Services

Krasamo helps product companies move Matter-enabled devices from early architecture through implementation, testing, certification preparation, and post-launch support.

Our teams work across embedded firmware, connectivity, companion applications, cloud integration, commissioning, security, and interoperability testing. We can also evaluate hardware platforms and Matter SDKs, map product functions into Matter, and design setup and multi-ecosystem behavior around the intended customer experience.

For existing products, Krasamo can assess whether Matter can be introduced through software or whether hardware, memory, security, or connectivity limitations require a revised design. For new products, the work can extend from architecture and prototyping through manufacturing integration, ecosystem validation, and certification readiness.

Post-launch support can include SDK migrations, OTA releases, security updates, regression testing, and Matter capability updates across future product generations.

Build a Matter Product with Krasamo

Planning a new Matter product, adding Matter to an existing device family, or migrating a deployed product to newer Matter capabilities? Krasamo can support architecture, implementation, manufacturing integration, certification readiness, and post-launch evolution.

Talk to Our Matter Development Team

Sources and Further Reading

• Connectivity Standards Alliance — Matter 1.6 Enables More Intuitive Setup, Multi-Ecosystem Experiences, and Context-Driven Control
• Connectivity Standards Alliance — Certification Process / Why Certify
• Connectivity Standards Alliance — Matter Compliant Platform Certification
• Connectivity Standards Alliance — Distributed Compliance Ledger
• Connectivity Standards Alliance — Alliance Interop Lab and FastTrack Recertification
• Thread Group — Certification
• Silicon Labs — Matter Device Attestation
• Silicon Labs — Matter Secure Manufacturing
• Connectivity Standards Alliance — Matter 1.4.2: Enhancing Security and Scalability for Smart Homes