DAC Provisioning Pipeline: The PKI Chain That Kills Production

Nothing triggers a production stop faster than 20,000 units with invalid Device Attestation Certificates. The DAC chain is unforgiving: one digit wrong in a VID field and every device fails commissioning. Here is what the chain looks like, what must happen at the factory, and what kills production runs.

This is a deep-dive from Provisioning Matter Devices at Scale. For the broader manufacturing picture (CM handoff, pre-production validation, certification timing), start there.

The chain, in order

flowchart TD
    CSA["CSA PAA
(trust root)"] -->|signs| PAI["PAI
(per VID)"]
    PAI -->|signs| DAC["DAC
(per device, unique)"]
    CERT["Certification"] -->|generates| CD["CD
(CMS-signed)"]

    DAC -- "VID/PID" --> CHECK{"Commissioner
cross-checks"}
    CD -- "dacOriginVendorId
dacOriginProductId" --> CHECK
    FW["Firmware
Basic Info VID/PID"] -- "VID/PID" --> CHECK

    CHECK -->|"all match"| PASS["✓ Attestation passes"]
    CHECK -->|"any mismatch"| FAIL["✗ Attestation fails
device rejected"]

1. Product Attestation Intermediate (PAI) certificate — signed by the CSA’s Product Attestation Authority (PAA). You get one PAI per VID. If you have multiple VIDs, you have multiple PAIs.
2. Certification Declaration (CD) — a CMS-signed document that attests your device passed Matter certification. Generated during the certification process. The CD signing key is tied to your VID.
3. DAC — a per-device certificate signed by your PAI. This is what the commissioner checks during the attestation step. Each device gets a unique DAC.

What must happen at the factory

• DAC generation and injection into secure storage. You cannot defer DAC provisioning to post-manufacturing — the DAC must be on the device before it leaves the factory floor.
• CD injection into the device’s factory data partition. Without the CD, the commissioner cannot verify the certification status of the device.
• PAI certificate inclusion in the firmware image or injection alongside the DAC. Both approaches work, but in-firmware inclusion is less error-prone because it eliminates a per-unit injection step.

What can be deferred

DAC signing can happen off-device. You can generate DAC key pairs on a secure server, sign them with your PAI private key, and inject the pre-signed DACs at the factory. This decouples the security-sensitive signing operation from the factory floor. The tradeoff: you need a secure injection process that maps each serial number to its unique DAC.

Common misconfigurations that kill entire production runs

Wrong VID in the CD. The CD’s VID field must match the VID in your DAC and the VID in your firmware’s basic information cluster. A single-digit mismatch and every device fails commissioning. We’ve seen a production run of 15,000 units scrapped because the CD was generated with VID 0xFFF1 but the firmware declared 0xFFF2.

PAI signed with wrong key, or PAI not chaining to the CSA PAA. If your PAI certificate does not chain to the CSA PAA that the commissioner trusts, the entire attestation step fails. Validate the chain with chip-cert tooling before the production run starts. Not after.

DAC private key stored outside secure element. Matter requires the DAC private key to be stored in hardware-backed storage. If your provisioning script writes the key to flash instead of the secure element or trusted storage partition, the device fails attestation in a production-certified commissioner but may pass in your development controller. The difference is silent until the certification lab catches it.

DAC subject and CD not referencing same VID/PID. The commissioner cross-checks the DAC subject distinguished name, the CD’s dacOriginVendorId and dacOriginProductId, and the firmware-reported VID/PID. Any mismatch across these three sources fails attestation. Automate this cross-check in your production validation script.