The smart home industry has made great progress with more products carrying the Matter certification. But obtaining the certification does not mean that the product is ready for commercial use.
While many products have obtained the Matter certification, they still may face many issues, including engineering and deployment after launch, such as:
- Insufficient hardware scalability
- Diverse operation within ecosystems
- Failures in device commissioning
- Problems with OTA updates
- Security breaches
The real objective for engineering leaders is to deliver a product that:
- Works reliably from day one
- Interoperates seamlessly across ecosystems
- Maintains security throughout its lifecycle
- Supports scalable manufacturing
- Enables long-term device management and updates
To get to this level of readiness, manufacturers need to examine their production line from start to finish. They should review everything, including their devices’ hardware, secure the identity of their devices, and evaluate device data models, interoperability between devices, and other lifecycle management processes.
To make this process easier, we have come up with a Matter Certification Checklist- a list of key engineering checks that can be performed by every smart home manufacturer before they are enabled to start certifications for Matter and scalling production of products.
The process begins with the most essential thing any OEM of a Matter device should do: pick the right device architecture.
Device Classification & Hardware Sizing
Two key decisions include choosing the proper Matter device category and sizing the hardware platform properly; both will determine the success of the certification, degree of interoperability, and future scalability of the product.
✔ Ensure that the product is properly mapped to the right Matter device category.
Choosing the appropriate device type for the Connectivity Standards Alliance (CSA) is an important process since the device type affects how the ecosystem controllers identify and handle the functionality of the product.
Consider endpoints to be like virtual ports:
- Endpoint 0 is dedicated solely for root system management functions (like node identification and Over-the-Air (OTA) upgrades),
- Endpoints 1 and above provide the real application features, such as smart lighting, sensing, and motor control.
It is important to evaluate whether building a native Matter device or using a Matter Bridge for existing Zigbee or Z-Wave products is the better choice.
Wrong device classification can lead to a negative user experience on Apple Home, Google Home, Amazon Alexa, and Samsung SmartThings.
The next important step after choosing an appropriate device category is to make sure that the actual silicon/hardware components can withstand such demands.
Device Classification & Hardware Sizing
✔ Confirm the hardware platform is sized for Matter, not just compatible with it.
Now let us talk about the hardware platform. To choose an appropriate Matter-ready chipset from companies such as Espressif, Nordic Semiconductor, NXP Semiconductors, Silicon Labs, or Telink is just the first step.
The platform must offer enough processing, memory, and security features for both the current implementation and the future Matter frameworks, particularly:
- Processing Power: The required specifications include a 32-bit MCU (usually ARM Cortex-M33, Cortex-M4, or RISC-V) functioning at around 80-160 MHz to perform Matter-related cryptography functions (PASE/CASE, ECC/AES tasks) and maintain local application processes without being slowed down.
- Flash Memory: For standard Matter end-devices, a memory range of 2 to 4 MB is required (a stack of the Matter SDK, device credentials, and an A/B dual bank memory for hassle-free OTA upgrades is included). If a complex Matter Bridge or Gateway device is used, the memory will range from 16 MB to 32 MB.
- Hardware security features that utilize crypto acceleration technology for ECC P256, AES 128 CCM, key storage, device attestation, and certificate verification to prevent bottlenecks during commissioning.
Designing sufficient computing, memory, and security bandwidth is important from the very beginning of the design process. This way, there will be much fewer chances for hardware redesign, certification will take less time, and there will be no obstacles for future updates of software and the Matter specification.
Now that the device’s architecture and hardware base have been validated, the next important stage is to ensure reliable networking, secure commissioning, and a consistent level of cryptographic trust across the Matter ecosystem.
Transport Layer & Security Architecture
Once the hardware foundation is defined, the next task is to determine how the device communicates within the Matter ecosystem and builds trust. At this point, OEMs must look beyond connectivity.
The transport technology should be suitable for the environment in which the product will work. Likewise, the security architecture must ensure that every device has been authenticated before it can connect to the Matter fabric.
✔ Ensure the transport layer is aligned with the product’s use case.
Matter incorporates several IPv6 transport technologies, and each of them is designed for different deployment scenarios, so it is important to choose the right one as early as possible to avoid unnecessary redesigns in the future.
- Thread (IEEE 802.15.4) technology is designed to run low-energy devices like smart locks, smart/doors/windows, and environmental sensors. The Thread Border Router serves as a bridge connecting these devices with a home IP network.
- Wi-Fi (IEEE 802.11) is preferable for devices powered by the main electricity, such as smart plugs, lighting controls, and other devices that require a lot of data.
- Bluetooth Low Energy (BLE) is essential, as Matter depends on BLE to communicate with the device during initial discovery, onboarding, and credentials transfer while switching to the main IPv6 transport afterwards.
The wrong transport layer or neglecting BLE commissioning may render a certified product unconfigurable through the typical smartphone onboarding tools.
The next step, after confirming that the communication channel is working, involves ensuring that all devices that join the network in question can authenticate themselves.
Transport Layer & Security Architecture
✔ Implement Matter’s mandatory security framework from the beginning.
Matter’s security strategy depends upon a public key infrastructure (PKI) based chain of trust.
Each device receives a valid identity before authorities of the ecosystem let it interface with Matter. So, for the whole system to function correctly, all these parts need to come together:
- There’s the Product Attestation Authority (PAA); basically, it’s the certification authority that you trust.
- Product Attestation Intermediate (PAI) is a certificate issued for certain vendors or a group of vendors.
- Device Attestation Certificate (DAC) provides each device with its own X.509 v3 certificate, which is based on an ECC P256 key pair.
- Certification Declaration (CD) is responsible for linking the vendor ID (VID) and product ID (PID) to the CSR certification record.
It is also necessary to secure these credentials. The private keys of DACs must be kept safe, using secure elements, eFuses, or PUF-based storage to keep them secure. Other security measures such as Secure Boot, Flash Read Out Protection (RDP), and hardware advancements in cryptography will ensure that firmware is secure to facilitate safe commissioning.
In case there is any breach or missing part of this chain of trust, the device pairing will be blocked by the ecosystem controllers regardless of the functioning of the application software.
Now that networking and security are done, it’s time to shift from getting the devices talking to checking that those devices perform as intended after they ship. This includes verifying Matter software functionality, compatibility with different ecosystems, and readiness for mass production.
Software Implementation, Interoperability, & Manufacturing
Now that the device is connected and secure, the next step of the Matter certification checklist is the software that will run on the device. Having established connectivity should no longer be the highest priority, as being able to use Matter should be only the first step on the way to achieving the firm’s goals.
✔ Confirm the firmware fully implements the required Matter data model.
It is important to understand that a Matter-compliant device is as much about its software as it is about its hardware. The firmware must implement the clusters, attributes, and commands as expected for the appropriate device type while also adhering to the defined Matter data model.
As part of verifying that the above is true, engineering teams must ensure that:
- Mandatory clusters such as On/Off, Level Control, Color Control, Thermostat, and Basic Information have been put in place where needed.
- ZCL Advanced Platform (ZAP) is used to configure cluster attributes, commands, and bindings correctly.
- Overall application logic retains a modular and independent nature from the Matter protocol stack, so protocol upgrades do not have any effect on the special functions of certain devices.
Even a slight mistake, like an omitted required feature or a wrongly configured cluster, can lead to immediate failures during Authorized Test Lab (ATL) compliance testing.
If the firmware meets the Matter specification now comes the next stage is to check how the implementation works in the real world.
Software Implementation, Interoperability & Manufacturing
✔ Validate interoperability across major Matter ecosystems.
Just because a device passes certification doesn’t mean its user experience is guaranteed to be hassle-free. These devices need to be tested in actual environments, where there are multiple ecosystems and multiple fabrics, and many types of networks.
As such, the full validation process should consider these elements during its testing:
- Testing with multiple admins of Apple Home, Google Home, Amazon Alexa, and Samsung SmartThings.
- Supporting multi-fabric syncing, so that state changes remain in sync with every connected controller.
- Conflict resolution for any tasks performed by a user manually, as well as conflicts that may arise from local automations.
- Testing under normal conditions of reconnecting devices, RF interference conditions, as well as conditions of the use of multiple vendor Thread Border Router devices.
Solving these problems before the launch helps avoid synchronization issues, delays in automation, inconsistent application behavior, and making unnecessary returns of the product.
After validating how software behaves in different ecosystems, the very last step would be checking whether the product can smoothly transition from the engineering validation stage to the mass manufacturing stage.
✔ Prepare for certification and manufacturing provisioning.
Being a production-ready Matter device is about much more than just passing the firmware validation process. In fact, certification workflows and manufacturing processes need to work together to ensure that a newly shipped device will be ready for successful commissioning.
Before moving to the production stage, OEMs need to ensure that the following checks are completed.
- Compliance testing using an Authorized Test Lab (ATL) has been completed successfully.
- Registration in the Distributed Compliance Ledger (DCL) is complete, including the certificate of PAI, VID, PID, and firmware information.
- Economy-specific verifications have been completed. For example, the product is confirmed to work with Google Home.
- The manufacturing line securely provisions unique DAC key pairs with the help of Hardware Security Modules (HSMs).
- Internal device credentials are consistent with the generated setup passcodes and printed Matter QR codes before products can leave the factory.
A mismatch among the device credentials, the DCL data, as well as information about packaging can stop the customer from picking a device straight out of the box and making it operational, and turn the certified devices into a support issue.
This is how original equipment manufacturers can greatly minimize the chances associated with the rollout of the concerned devices and start commercial manufacturing much more confidently.
So, in summary, all the engineering checkpoints should be combined into a repeatable product development plan to provide a systematic plan from initial design to successful market product development.
MosChip has extensive expertise in areas such as hardware design, software development, and smart home connectivity. This enables consumer electronics OEMs to convert their Matter certification checklist into a practical engineering process. MosChip supports OEMs in using the right chipsets, validating the security of their operation, applying necessary firmware functionalities, and ensuring compatibility with other systems to make sure they achieve their Matter certification and production readiness.
To know more about MosChip’s capabilities, drop us a line, and our team will get back to you.