MatterODM by Shenan YangguangWhat Matter certification actually is
Matter certification is the process by which a product is tested against the Matter specification and, if it passes, granted a Certification Declaration (CD) by the Connectivity Standards Alliance (CSA) — the body that publishes and governs the standard. The grant allows the product to carry the Matter logo, be listed in the CSA's public product list and the Distributed Compliance Ledger, and be commissioned into Matter fabrics.
It is worth separating four things that customers routinely conflate:
- Matter certification — conformance to the application-layer specification and the right to use the logo.
- Transport certification — proof that the underlying network layer (Wi-Fi, Thread or Bluetooth Low Energy) is itself certified in the configuration you use.
- Regulatory market access — CE, UKCA, FCC, RoHS and similar. These are separate from Matter entirely; see our compliance checklist.
- Ecosystem onboarding — individual smart home platforms may layer their own additional checks on top of Matter. Certification is the floor, not the ceiling.
The five certification paths
Not every product goes through the full suite. The CSA defines several routes, and picking the right one early is the cheapest decision available to a hardware brand.
| Path | What it means | When it applies |
|---|---|---|
| Full certification | Full test against the specification at an authorized test provider | A first product, or any product with new clusters or a new radio configuration |
| Product family (PFC) | Variants sharing the same device type, base hardware and software as a fully tested parent | Colour, styling, enclosure or regional variants of one design |
| Certification by Similarity (CbS) | A derived product with a different functional purpose but the same Matter software as a certified parent | Extending a certified platform into a new product role |
| Certification Transfer (CTP) | Re-badging a product certified by another member, with no hardware or software change | Brands selling an existing third-party product as-is |
| Recertification | Re-approval after a change that breaks the original certificate | SDK updates, security fixes, functional change |
One clarification matters for anyone judging a supplier. CTP exists to re-badge somebody else's certified product. A manufacturer that actually designs and certifies its own hardware does not need it — the product is certified in its own right, under its own vendor ID. When you read a certification claim, ask which of the five paths produced it. It tells you something about who really built the device.
Why CbS is the path most alarm brands end up using
A door contact, a PIR detector and a small combined siren hub usually share one radio module, one firmware base and one security model. They differ in the device type they expose and the cluster set they implement. That is precisely the shape CbS was designed for: certify the hardest product fully, then extend the same software into sibling products by documenting the similarity rather than rebuilding the test evidence each time. It only works if the parent is certified first and the software really is the same — a "small firmware tweak" to the cluster implementation is exactly what disqualifies the claim.
What actually gets tested on a sensor product
The test scope is driven by the device types and clusters a product declares. For a security sensor that typically means the contact or occupancy sensing behaviour, the alarm and battery clusters it exposes, identify, and the commissioning experience itself — how the device behaves when a phone pairs it, hands it credentials, and moves it onto a fabric.
Before any lab time, the manufacturer completes a PICS (Protocol Implementation Conformance Statement): a declaration of which parts of the specification the product implements. The test plan is generated from the PICS, which is why the PICS is also the most common place for a project to fail — it is a promise about behaviour, and the test cases check the promise.
Security is assessed alongside the functional tests. Each Matter device carries a DAC (Device Attestation Certificate), and DACs hang off a three-level chain: a Product Attestation Authority (PAA), an intermediate PAI, and the per-device DAC. In production the manufacturer either uses an existing PKI provider's PAA or operates its own. The Certification Declaration blob is then injected into each unit, so the device can prove its certification status to a network when a user tries to add it.
The sequence, end to end
- Membership and vendor ID. Certification requires at least a CSA Adopter membership, and the company obtains a Vendor ID for its products.
- Transport certification. Evidence that the network layer — Wi-Fi, Thread or BLE — is certified in the configuration being shipped.
- PICS and pre-test. Declare the implementation, then test against it internally before paying for lab hours. Pre-testing on a real test harness is where the cheapest bugs are found.
- Testing at an authorized test provider. The provider issues a final test report to the applicant and to the CSA.
- Application and review. Submitted through the CSA certification tool, including the declared device types, the product's vendor and product IDs, the PICS, a Declaration of Conformity and the transport attestations. The CSA certification team reviews and either approves or returns a list of items to resolve.
- Grant and production. On approval the applicant receives a certificate of compliance, logo rights, the CD blob, and a record in the Distributed Compliance Ledger — then the attestation and CD material move into the production line.
Where schedules actually slip
Rather than quote a number that will not hold, it is more useful to name the variables. Two of them dominate every project we run.
The first is the module question. If a product is built on an already-certified connectivity configuration and that configuration is unchanged, the hard part is done. If the manufacturer changes the antenna, the enclosure shielding, the pin usage or the firmware in ways the module's certificate does not cover, the existing evidence stops applying and the work grows. This is the single most common misunderstanding in the whole process: a certified component is not a certified product.
The second is endpoint count. A composed device — one housing that presents a contact sensor, an occupancy sensor and an alarm as several endpoints — has to select one overall device type for the certification application even though it exposes multiple endpoints. That decision has to be made before the paperwork, and changing it later means reworking the PICS and, potentially, the test plan.
Timelines and cost therefore depend on membership level, the number of device types and endpoints, how much of the stack is genuinely unchanged, and how many review cycles the application needs. We confirm both per project in writing rather than publishing a figure that would not apply to your product.
What the factory owns
Shenan Yangguang builds these products ourselves: schematic and PCB design (画板), prototyping and board bring-up (打板), firmware and product R&D (研发), certification cooperation (配合认证), and mass production (大面积出货). Connectivity is integrated as a standard CSA-certified Matter connectivity module — a purchased component, treated exactly like the MCU or the PIR element — and the certification is taken in our own name for the finished product.
That is the substantive difference between designing a product and re-badging one. The vendor ID, the attestation chain and the Certification Declaration belong to the party that built and tested the device, and they follow the product through its life — including any recertification a future firmware update requires.