Matter Device Attestation Certificates: PAA, PAI, and DAC Hierarchy Explained for Enterprise PKI Teams

By Dan Cvrcek, Founder, Axelspire · Updated March 2026

Part of the IoT Certificate Management pillar. This page explains how Matter's Product Attestation Authority / Product Attestation Intermediate / Device Attestation Certificate hierarchy actually works and what it means for manufacturers and operators running their own fabrics.

You Know X.509. You Don't Know This.

If you run enterprise PKI, you understand certificate chains: root CA signs intermediate, intermediate signs end-entity certificate. You manage this for TLS, mutual auth, and code signing.

Matter uses the same cryptographic primitives—X.509v3, RFC 5280, ECDSA on NIST P-256. Your PKI team will recognise the structures.

But the trust architecture is fundamentally different: you don't control the root, onboarding relies on a shared compliance ledger, certificates are per-device at manufacturing scale, and operational communication uses a separate certificate hierarchy entirely.

The Matter PKI Hierarchy

Enterprise PKI typically follows a two- or three-tier model with roots you operate. Matter introduces a hierarchy where the Connectivity Standards Alliance (CSA) maintains the set of trusted roots and your devices must chain into that ecosystem.

PAA vs PAI vs DAC: Matter Certificate Hierarchy at a Glance

Product Attestation Authority (PAA)

A Product Attestation Authority (PAA) is the root certificate authority in the Matter device attestation hierarchy — the Matter-approved root CA that all device attestation certificates ultimately chain back to. Commonly referred to as a PAA certificate or PAA cert, its certificate is approved by the Connectivity Standards Alliance and published in the Distributed Compliance Ledger (DCL).

There are two main models:

• Vendor-ID Scoped PAA: operated by or for a specific manufacturer; embeds a CSA Vendor ID.
• Non-Vendor-ID Scoped PAA: operated by third-party providers such as DigiCert or Kudelski IoT; may serve multiple manufacturers.

If you're an enterprise PKI team, think of the PAA as a publicly trusted root—but instead of browser root stores, trust is defined by the CSA's DCL. For teams evaluating a product attestation authority for their Matter product line, the first decision is whether to operate a vendor-scoped PAA or delegate to a third-party provider — a choice with multi-year implications covered in Planning Your Matter PKI Architecture below.

Product Attestation Intermediate (PAI)

A Product Attestation Intermediate (PAI) is the intermediate certificate authority in the Matter PKI hierarchy, issued by a PAA and responsible for signing Device Attestation Certificates. Often referred to as a PAI certificate or PAI cert, the PAI embeds Vendor ID and optionally Product ID, binding the intermediate to a specific manufacturer or product line.

The product attestation intermediate is where manufacturers gain operational flexibility: you can scope PAIs per product family to allow more granular revocation and lifecycle control without affecting your entire device portfolio. From Matter v1.3 onward, PAIs must publish CRLs with endpoints referenced in the DCL.

Device Attestation Certificate (DAC)

A Device Attestation Certificate (DAC) is a unique per-device X.509 certificate that proves a Matter device is genuine and certified. Commonly shortened to DAC cert, every Matter device gets a unique DAC, signed by a PAI and chaining to a PAA. It contains Vendor ID and Product ID and is used during commissioning to prove the device is authentic.

Key points:

• One DAC per physical device; ship 500,000 thermostats, you need 500,000 DACs and key pairs.
• The DAC key must be securely stored on the device—your key storage architecture determines how strong that guarantee is.
• The DAC is not used for everyday operational traffic; that's handled by separate network operational certificates (NOCs).

How Commissioning Actually Works

During commissioning, the commissioner (phone app or hub) establishes a secure channel, obtains the device's DAC, PAI, and Certification Declaration, and validates them against the DCL.

1. Discover device (BLE or IP-based discovery).
2. Establish a PASE session using setup codes.
3. Request DAC, PAI, and Certification Declaration.
4. Validate chain DAC → PAI → PAA and cross-check Vendor ID / Product ID with the DCL.
5. Issue a fabric-specific NOC that the device will use for ongoing communication.

This two-layer model—attestation via DACs, operational identity via NOCs—is unfamiliar to many enterprise PKI teams and has implications for how you monitor and manage devices after onboarding.

The Distributed Compliance Ledger

The DCL is a shared registry that:

• Lists approved PAA certificates — the effective trust store of Matter-approved root CAs.
• Records which Vendor ID / Product ID combinations are certified.
• Publishes CRL distribution points for PAIs.

Commissioners query the DCL to decide whether to trust a given chain and product. If your PAA is removed or your PAI's CRL endpoint becomes unreachable, new devices can fail commissioning even if the cryptography is sound.

What Enterprise PKI Teams Get Wrong

In large organisations, three mistakes are common when PKI teams meet Matter—and each one has caused real production failures.

Mistake 1: Treating PAA Selection as Simple CA Procurement

Enterprise teams often evaluate PAA providers the same way they evaluate TLS certificate vendors: compare pricing, check SLAs, sign a contract. But a product attestation authority is not a commodity purchase—it is a multi-year infrastructure commitment that outlives any single product line.

Every DAC you issue chains to that PAA for the lifetime of the device. If you switch providers, you cannot re-sign existing devices in the field. If your PAA provider is removed from the DCL—whether through audit failure, business closure, or policy non-compliance—new devices using that chain cannot be commissioned. Devices already deployed continue operating on their NOCs, but your manufacturing pipeline stops until a new PAA is established and new PAIs are issued.

The practical consequence: teams that selected a product attestation authority solely on unit cost have found themselves locked into providers with no migration path, paying escalating renewal fees because the switching cost is effectively infinite for shipped inventory.

Mistake 2: Assuming Data Centre Key Ceremonies Scale to Factories

In enterprise PKI, key ceremonies happen infrequently—once for a root, occasionally for intermediates. They involve quorum-based access, air-gapped HSMs, and documented procedures that take hours.

Manufacturing DAC provisioning happens at line speed. A factory producing 10,000 units per day needs 10,000 unique key pairs generated and 10,000 DACs signed in that window. The operational model is fundamentally different: HSMs must be rack-mounted on the factory floor (or accessible via low-latency network), signing throughput must be measured in operations per second, and the entire process must be automated end-to-end with no manual intervention.

The failure mode we see most often: teams design a "secure" provisioning process modelled on their data centre key ceremonies, then discover during production ramp that it adds 8–15 seconds per device. At 10,000 units/day, that is 22–42 hours of additional line time—enough to miss shipping deadlines and trigger contractual penalties with retail partners.

Mistake 3: Focusing Only on DACs and Ignoring Operational Certificates

The DAC gets all the attention because it is the novel element—enterprise teams haven't dealt with per-device manufacturing certificates before. But the DAC cert is only used once, during commissioning. After that, the device operates on a fabric-specific NOC for all encrypted communication.

NOCs have their own lifecycle: they expire, they can be revoked, and they need to be renewed. If you are running your own Matter fabric (as many commercial building operators and fleet managers do), you are the NOC issuer and you own that lifecycle. This means you need monitoring infrastructure that tracks NOC expiry across your entire device fleet, automated renewal workflows that handle devices with intermittent connectivity, and revocation capability for compromised or decommissioned devices.

Teams that focus exclusively on the attestation layer during planning discover this gap only after deployment—when the first batch of NOCs approaches expiry and there is no renewal mechanism in place. At that point, the options are manual re-commissioning of every affected device or building the automation infrastructure under time pressure. Both are expensive. Neither needed to happen.

Planning Your Matter PKI Architecture

The first decision is whether to operate your own PAA or work with a provider.

Operate your own PAA if: you ship very high volumes, have robust PKI operations with HSMs and ceremonies, and are prepared for ongoing CSA audits. Cloud offerings like AWS Private CA can help, but as discussed in Who Owns Your Device Identities?, they also introduce platform lock-in.

Use a third-party PAA if: you want faster time to market, lower operational burden, and predictable managed service pricing from vendors such as DigiCert or Kudelski IoT.

Either way, you must design how PAIs are scoped, how DACs are provisioned at manufacturing, how keys are protected, and how CRLs will be maintained for the full device lifetime.

For lifecycle considerations beyond attestation—provisioning, renewal, and revocation—see The IoT Certificate Lifecycle Nightmare. For the key storage decision underpinning DAC security, see Hardware vs Software Key Storage. For how cloud platform choices affect device identity ownership, including the implications of hosting your Matter-approved root CA on AWS Private CA versus operating independent infrastructure, see our device identity and lock-in analysis. For the complete technical guide to Matter DAC provisioning at the factory floor — including on-device keygen, pre-provisioned SE, and key injection models — see Factory Provisioning. For the CTO-level view covering regulatory timelines and TCO, see Device Identity Strategy.

Related Axelspire Content

• IoT Certificate Management — Pillar overview
• What Is the Matter Standard and Why It Mandates PKI — Commercial and regulatory context
• Hardware-Backed Device Identity — SE/TPM selection for DAC storage, certificate hierarchies
• Factory Provisioning — Three provisioning models for DAC injection
• Device Identity CTO Strategy — CRA/Cyber Trust Mark compliance, TCO modelling
• PKI Trust Models Explained — Foundation for understanding the hierarchy
• ACME Protocol Enterprise Guide — Relevant for lifecycle automation
• HashiCorp Vault PKI — Dynamic issuance patterns

External References

• CSA Matter Attestation Handbook
• Google Developers — Matter Attestation
• DigiCert — Issuing CSA Matter Certificates
• AWS — Matter Device Attestation with Private CA
• Matter SDK on GitHub
• RFC 5280 — X.509 Certificates