Matter — the connectivity standard backed by the Connectivity Standards Alliance (CSA) and adopted by Apple, Google, Amazon, and Samsung — changed consumer IoT security in one specific way that separates it from every Wi-Fi or Bluetooth device standard that preceded it: it made per-device cryptographic identity mandatory, not optional. Every Matter device that ships must have a unique Device Attestation Certificate (DAC) issued through a PKI hierarchy that the CSA approves. For OEMs building their first Matter product, understanding that PKI hierarchy is not optional background reading — it's a prerequisite for certification.
The Matter Certificate Hierarchy
Matter defines a three-level certificate hierarchy, and each level has specific operational responsibilities that OEMs need to account for.
Product Attestation Authority (PAA) — the trust anchor. PAAs are root CAs approved and listed by the CSA. They sign Product Attestation Intermediate (PAI) certificates. OEMs do not typically operate a PAA; they use a PAA operated by a CA provider that has been approved by the CSA. The PAA's certificate is embedded in Matter controller devices (phones, hubs) so that during commissioning, the controller can verify the full chain.
Product Attestation Intermediate (PAI) — the OEM-level intermediate. A PAI is typically one per product line or vendor ID, signed by a CSA-approved PAA. The PAI is what most OEMs interact with operationally. Critically, the PAI certificate embeds the Vendor ID (VID) — a CSA-assigned identifier — which ties all DACs issued under that PAI back to the specific OEM. OEMs may operate their own PAI private key (requiring an HSM and proper key ceremony) or have a CA service operate it on their behalf.
Device Attestation Certificate (DAC) — the per-device leaf certificate. Each physical unit gets its own DAC, containing the VID, the Product ID (PID, assigned per SKU), and a unique public key corresponding to a private key stored on the device. The DAC is issued by the PAI and is what the commissioner verifies during device onboarding.
The Attestation Flow at Commissioning Time
When a user adds a Matter device to their home controller — by scanning a QR code, NFC tap, or Bluetooth pairing — the commissioner (the phone or hub) kicks off the Device Attestation Procedure (DAP). The steps, per the Matter specification, are:
- The commissioner requests the device's DAC and PAI certificate over the in-progress PASE (Passcode Authenticated Session Establishment) session.
- The commissioner verifies the DAC is signed by the presented PAI, and the PAI is signed by a PAA that appears in the CSA's distributed list.
- The commissioner verifies that the VID in the DAC matches the VID in the PAI, and that both match the VID in the device's Basic Information cluster.
- The commissioner issues an Attestation Challenge — a fresh nonce — and requests a signed Attestation Information blob. The device signs this blob with its DAC private key. The commissioner verifies the signature against the DAC's public key.
- If all verifications pass, commissioning proceeds to CASE (Certificate Authenticated Session Establishment) and operational credentials are issued.
Step 4 is the proof-of-possession step. It proves the device actually holds the private key corresponding to the DAC, not just that it has a copy of the certificate. This is the difference between "I have a certificate" and "I am the entity the certificate was issued to."
What OEMs Need to Implement Before Shipping
The Matter certificate requirements create several engineering decisions that need to be resolved before the first production run.
How will the DAC private key be protected? The Matter specification does not mandate hardware storage for the DAC private key, but the security model assumes that the key cannot be extracted. On constrained microcontrollers, this typically means using a secure enclave, a dedicated security IC, or at minimum the MCU's provisioned OTP fuse region to restrict read-back. A DAC private key stored in plaintext flash is technically spec-compliant but violates the security intent — and CSA auditors may flag it during certification review.
When and how will DACs be injected? There are two common provisioning points: factory injection (during PCB assembly or final test, before the device is sealed) and first-boot provisioning (the device generates its key pair on first power-up and calls a provisioning service to get its DAC issued). Factory injection is more operationally complex — it requires a secure network segment on the manufacturing floor, an HSM or signing service reachable from the test jig, and per-unit traceability — but it is preferred for high-volume production because the certificate is baked in before the device leaves the factory.
Who operates the PAI? This is the most consequential decision. If the OEM self-operates the PAI key, they control the full provisioning pipeline but take on the operational burden of key custody, HSM management, and key ceremony documentation (required by CSA). If they delegate to a CA service, they lose some operational control but reduce the key management overhead significantly. Either way, the PAI key must be protected; a compromised PAI key means every DAC issued under it must be considered suspect.
A Scenario: A Taiwan-Based Smart Lock OEM, 2024
Consider a mid-size consumer electronics ODM preparing its first Matter-certified smart lock line for the North American retail market. They have Vendor ID assigned by CSA, they've completed the protocol stack porting, and their first certification submission is six weeks out. The engineering team has been assuming they could inject DACs using a Python script and a softcopy of the PAI private key on a provisioning workstation. The security review surfaces the problem: that approach stores the PAI key in a workstation filesystem, accessible to any operator with local admin rights. A single workstation compromise could exfiltrate the PAI key and allow unlimited fake device provisioning under the OEM's VID.
The fix — migrating PAI key operations to an HSM appliance on the manufacturing floor, with operator authentication and audit logging — added three weeks to the schedule and approximately $15,000 in infrastructure cost. The alternative was re-keying the entire PAI after launch, which would require reissuing every DAC already manufactured. The HSM investment was the obviously correct call, but it only became visible when someone asked "where does the PAI private key live?" explicitly.
DAC Validity Period and Revocation Considerations
Matter DAC certificates are typically issued with long validity periods — often matching or exceeding the expected device lifetime, sometimes as long as 20-40 years. This is intentional: commissioning flows depend on the DAC being valid, and a device with an expired DAC cannot be onboarded without a factory re-provisioning step that most consumers cannot perform. The consequence is that DAC revocation, rather than expiry, becomes the primary mechanism for handling compromised devices.
Matter defines a Certificate Declaration (CD) as a separate artifact — a CMS-signed structure attesting that the device's firmware has been certified by the CSA for the declared VID/PID. The CD is distinct from the DAC chain; compromised firmware can be addressed by invalidating the CD without revoking the device's DAC. This separation allows OEMs to update product certification without re-provisioning hardware.
We're not saying DAC revocation is impossible — the CSA maintains a Distributed Compliance Ledger (DCL) that controllers can query for revoked certificates. But the operational reality is that most consumer Matter controllers do revocation checks opportunistically, not on every commissioning, and the latency between a compromise being reported and controllers updating their revocation knowledge can be hours to days. This is a known tradeoff in the standard, not a defect that OEMs can engineer around unilaterally.
Vendor ID and Product ID Assignment
A practical point that trips up first-time Matter implementers: VIDs and PIDs are not free and are not self-assigned. VIDs are allocated by the CSA and are associated with CSA membership. PIDs are assigned per product SKU by the OEM under their VID namespace. Both must be registered in the CSA's DCL before a device can pass certification. The VID/PID pair is embedded in the PAI and DAC certificates, in the device's basic information cluster, and in the QR code payload — any mismatch is a certification failure.
Start the CSA membership and VID application process before any PKI infrastructure decisions. Waiting until after the firmware is feature-complete to get your VID allocated has caused at least one production delay for every first-time Matter OEM that has gone through it.
Looking Beyond Consumer IoT
Matter's approach — mandatory per-device certificates, CSA-approved CA hierarchy, attestation challenge-response at commissioning — is the clearest public articulation of what device PKI for mass-market IoT looks like. Industrial protocols like IEC 62443 and automotive standards under UN R155 have analogous certificate-based identity requirements, adapted for their respective operational environments. The architectural patterns are the same even when the specific certificate formats and revocation mechanisms differ.
For OEMs whose products span both consumer (Matter) and industrial (IEC 62443-compliant) applications, designing a single provisioning infrastructure that can issue both DAC-format certificates and IEC 62443-style device identity certificates from the same CA hierarchy is achievable — and worth planning for before the first product launch locks in the provisioning architecture.