DAC Provisioning Pipeline: The PKI Chain That Kills Production

The certificate chain is where production runs die. One wrong VID digit and every device in the batch fails commissioning in every ecosystem - we’ve watched it happen. The chain runs PAA -> PAI -> DAC , with a Certification Declaration (CD) on top, and a commissioner checks it every time a device joins a fabric.

PAA (Product Attestation Authority) - self-signed trust root. The CSA hands PAA status to approved organizations - itself and audited third-party PKI providers - and the approved list lives in the DCL (CSA PAA providers ). VID-scoped PAAs sign for one vendor; non-VID-scoped PAAs serve many.

PAI (Product Attestation Intermediate) - per-VID, signed by the PAA. It’s the intermediate that signs individual DACs.

DAC (Device Attestation Certificate) - per-device, signed by the PAI. Proves device identity during commissioning.

CD (Certification Declaration) - per-product, signed by the CSA Certification Center’s CD signing key. Attests that Matter certification passed, binds VID/PID, and since Matter 1.1 lists the authorized PAAs.

What the commissioner checks

During attestation , the commissioner cross-references three sources:

1. DAC subject DN - holds the device’s VID and PID
2. CD - dacOriginVendorId and dacOriginProductId fields
3. Firmware basic information cluster - the VID/PID the device reports

All three must match. Any mismatch fails attestation.

What must happen at the factory

• DAC generation and injection into secure storage. The DAC has to be on the device before it leaves the factory floor. You can’t defer DAC provisioning to after manufacturing.
• CD injection into the factory data partition. No CD, no way for the commissioner to verify certification status.
• PAI certificate inclusion in the firmware image or injected with the DAC. In-firmware inclusion is less error-prone - it removes a per-unit injection step.

What can be deferred

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

PKI infrastructure requirements

DACs are useless without the infrastructure to issue, store, and verify them. You need:

• A Certificate Signing Request (CSR) pipeline for manufacturing
• Secure key storage - CSA PKI policy wants DAC private keys in a secure subsystem (secure element or trusted storage), not plaintext flash. Honest caveat: this is policy, not a runtime-checked spec requirement. Attestation verifies certificates and signatures, not where a key physically lives. Treat secure storage as a certification requirement and a security best practice - not as the thing that makes attestation pass or fail.
• Integration with a CSA-approved Product Attestation Authority (PAA)
• Pre-certification DAC validation before you submit to the ATL

Common misconfigurations that kill production runs

Wrong VID in the CD. The CD’s VID field must match the VID in your DAC and in the firmware basic information cluster. Get it wrong and the whole batch fails attestation at every commissioner. This one is pure rework: recall, re-provision, re-ship.

PAI not chaining to a trusted PAA. If your PAI doesn’t chain to a PAA the commissioner trusts, the whole attestation step fails. Validate the chain with chip-cert tooling before production starts.

DAC private key stored outside the secure element. CSA PKI policy calls for hardware-backed key storage. A flash-stored key won’t fail attestation at commissioning - attestation checks certificates and signatures, not key location - but it violates certification security requirements and exposes the key to extraction. This is the one the lab catches, not the commissioner.

DAC subject and CD referencing different VID/PID. The commissioner cross-checks the DAC subject DN, the CD’s dacOriginVendorId/dacOriginProductId, and the firmware-reported VID/PID. Automate the cross-check in your production validation script.

Reusing DACs across devices. Every unit needs a unique DAC. A duplicated DAC still signs correctly, so it passes attestation’s signature checks - but it violates the Matter spec and certification requirements, and turns a duplicated identity into an impersonation risk.

FAQ

What is a Device Attestation Certificate (DAC)?

A DAC is a per-device X.509 certificate signed by the vendor’s Product Attestation Intermediate (PAI) certificate. It proves the device is genuine during commissioning. Each device in a production run must have a unique DAC, and the chain must root in a CSA-approved PAA that is listed in the DCL.

How do I validate my DAC chain before production?

Use the chip-cert tool from the Matter SDK to verify that your PAI chains to a CSA-trusted PAA and that each DAC chains to your PAI. Run this validation against the actual certificates that will be provisioned - not test certificates from your development environment.

Can DAC signing happen off-device?

Yes. You can generate DAC key pairs on a secure server, sign them with your PAI private key, and inject pre-signed DACs at the factory. This decouples signing from the factory floor but requires a secure injection process that maps each serial number to its unique DAC without exposing private keys.

What happens if my VID/PID mismatch is caught after production?

Every affected device must be recalled and re-provisioned. There is no remote fix for a VID/PID mismatch in the DAC or CD - the device fails attestation at every commissioner. This is why automated cross-checking during end-of-line testing is mandatory, not optional.

Part of the Shipping Matter series. See also: Factory Flashing at Scale , End-of-Line Testing .