Matter DACs can be prepared before production or issued on demand as devices move through the programming line. The difference goes beyond timing—it changes how manufacturers manage private keys, credential inventory, production authorization, and multi-factory deployment.
When a Matter product moves from development and certification into mass production, engineering teams eventually face a practical question:
Where do the DAC (Device Attestation Certificate) and private key for each device come from, and how do you provision them securely?
In production, there are generally two approaches.
The first is to prepare device credentials in advance. Key pairs are generated in a controlled environment before production, DACs are issued under the appropriate PAI (Product Attestation Intermediate), and the credentials are stored until they are provisioned to devices on the factory line.
The second is to issue DACs during production. When a device reaches the programming station, it generates its own key pair and CSR (Certificate Signing Request) inside a secure hardware environment. The CSR is sent through the programming station to a factory-side HSM or PKI service, which issues the DAC in real time. The certificate is then written back to the device.
At first glance, the difference is simply “prepare first, provision later” versus “generate and issue during production.”
In practice, the two approaches create very different security and production management models.
Generating and signing credentials in advance is straightforward.
Before production begins, the manufacturer generates the required key pairs in a secure environment. The PAI is then used to issue the DACs. Each DAC, private key, and its allocation information is managed as a set of device credentials and securely delivered to the factory for provisioning.
Think of it as printing identity cards before the devices arrive and assigning one to each device later.
The challenge is that those identities now have to be managed before they belong to an actual device.
Suppose a Matter switch is expected to ship 100,000 units, so 100,000 sets of credentials are prepared. The customer later reduces the order to 80,000 units. What happens to the remaining 20,000 identities?
Or consider another common production problem. Credentials have already been provisioned, but a hardware defect is discovered during testing and the entire batch of boards has to be scrapped. What happens to the identities already provisioned to those boards? Can they be recovered? Should they be reused? How do you prove that the original private keys are no longer accessible?
%20(1).avif)
Pre-generation places relatively little demand on real-time certificate issuance at the factory and may require fewer changes to an existing production line.
But once device identities are created in advance, they need their own lifecycle before they ever reach a device: storage, allocation, delivery, provisioning, reconciliation, and retirement.
From a production perspective, those credentials effectively become a form of digital inventory. They have quantities, status, ownership, allocation rules, and potentially unused stock.
There is also a security consideration: if the private key is generated outside the device, it has to reach the device somehow.
From generation to final provisioning, the private key may pass through backend systems, delivery channels, factory infrastructure, or provisioning tools. Every step requires strong access control, encryption, auditing, and operational safeguards.
The security problem is therefore not limited to generating a key securely. It also includes protecting that key throughout its journey into the device.
%20(1).avif)
Issuing DACs during production takes a different approach.
Instead of preparing pools of device identities and allocating them later, credentials are created when an actual device is being produced.
A typical flow looks like this:
Device generates key pair → Device generates CSR → Programming station forwards CSR → DAC is issued → DAC is written back → Production record is created
When the device reaches the programming station, its MCU, HSM, TrustZone-based secure environment, or dedicated Secure Element generates the key pair. The private key remains inside the device's protected hardware boundary.
The device then generates a CSR containing the information required for certificate issuance. The programming station forwards the CSR to an authorized factory-side HSM or remote PKI service. The DAC is issued and returned to the programming station, which provisions it to the device.
This changes several parts of the production process.
First, the private key does not need to be transported into the device. It is generated inside the device and remains there, reducing the number of systems that need to handle sensitive private-key material.
Second, there is no pool of pre-generated device identities to reconcile. If the production order is 80,000 units, 80,000 devices request DACs. If the order changes, there is no unused credential inventory left behind.
Third, this model becomes particularly useful when production spans multiple products, customers, factories, and programming stations.
Instead of distributing separate pools of credentials to different factories, the backend controls who is authorized to issue what, for which product, at which factory, and in what quantity.
The management problem shifts from allocating credential inventory to controlling production authorization.
Neither approach should simply be treated as the “old way” or the “new way.” They place security and operational complexity in different parts of the production system.
%20(1).avif)
The pre-generated model moves much of the operational burden upstream. It requires strong credential inventory management and a secure mechanism for protecting private keys from generation through factory provisioning.
The on-demand model moves more responsibility into the production environment. The device needs suitable hardware security capabilities, and the programming station must be able to communicate securely with the certificate issuance service. Production authorization and network availability also become important parts of the design.
If the device has an appropriate hardware security boundary and the factory environment can support the required communication, on-demand issuance can simplify credential management considerably.
For highly isolated factories or devices with limited hardware security capabilities, pre-generated credentials can still be a practical option when backed by rigorous key protection and credential management processes.
The right choice depends on the device architecture, factory environment, production scale, and security model.
In Snowball Technology's OnBoard™ IoT Security (OBIS) deployments, the on-demand model is used to support real-time Matter DAC issuance during production.
OBIS Cloud manages device configuration and production authorization. At the factory, local services and HSM-backed security capabilities handle authorized DAC issuance, while the programming station integrates the process into device programming.
The device generates its private key internally, so the private key never leaves the chip. The CSR is submitted for authorized DAC issuance during production, and the resulting certificate is written back to the device together with the corresponding production record.
There is no need to prepare and distribute pools of DAC credentials according to forecast production volumes. DAC issuance follows actual production.
For the factory operator, this remains part of the normal programming process rather than a separate certificate-handling workflow.
For companies planning Matter mass production, the first question therefore does not have to be:
“How many DACs should we prepare in advance?”
A better place to start is with the device and production environment:
Can the device securely generate and protect its own private key, and can the factory support authorized certificate issuance during production?
Once those two questions are clear, the choice between managing credential inventory and managing production authorization becomes much easier.
