.png){kind=logo}
Matter - Guide for the OEM / Vendor
The Matter standard relies on PKI X.509 certificates to secure the messages exchanged by devices and servers. Two different PKIs—Device Attestation and Operational—are in use, and this guide focuses on the Device Attestation PKI operated by the OEM/Vendor of a Matter hardware.
The Matter standard requires that every Matter device, appliance, or application bear a permanent identity document in the form of an X.509 certificate, called the DAC - Device Attestation Certificate. This certificate must be issued by a Matter-compliant Public Key Infrastructure (PKI), operated under the control of the device OEM, and adhere to the strict X.509 requirements on certificate content and size defined in the Matter specifications.
Although secure boot and firmware signing are also recommended, this guide will focus on the OEM/Vendor PKI and how to generate DAC certificates to comply with the standard.
The Role of Certificates in Matter Device Trust
To understand device trust in Matter, it is important to see how certificates are issued and validated across manufacturing, onboarding, and operation.
Manufacturing: Matter security relies on X.509 certificates. During manufacturing, each device is assigned an initial, long-lived (permanent) DAC certificate that is delivered and embedded by the OEM.
Onboarding: Upon joining a network (Fabric), each device is vetted for genuineness and conformity and gets an operational, dynamic certificate (NOC) delivered by the LAN (Local Area Network) gateway. This certificate is used by the stack mTLS to secure communication channels end-to-end. Matter devices can recognize one another: A shared Distributed Compliance Ledger (DCL) lists Matter-approved PAA, PAI certificates, device Certification Declarations (CD), firmware versions for each device, etc by all OEMs/Vendors.
Operation: The Fabric operational PKI is the one delivering the shorter-lived Node Operational Certificate (NOC) which is used to secure the mTLS transactions between the Matter devices and servers.
Certificates in Matter Device Trust
Matter Device Attestation PKI
When an OEM designs and manufactures Matter products, a PKI software is used to create a specific Product Attestation Authority (PAA) root. The PAA can either be unique to the OEM or shared with other OEMs, and is used to derive Product Attestation Intermediate (PAI) certificate authorities, which must be product-specific, and are used to issue the Device Attestation Certificates (DACs):
Product Attestation Authority (PAA): a root Certificate Authority and the Matter root identity of a Vendor. The PAA X.509 certificate is self-signed, inherently trusted, associated with a VendorID, and must be registered into the DCL. The PAA certificate signs PAIs.
Product Attestation Intermediate (PAI): a subordinate Certificate Authority and Matter’s unique, immutable identity of a device manufactured by a Vendor. A DAC is issued by a PAI certificate authority and injected into the device at manufacturing, and is, as such, associated with a ProductID. The DAC can be seen as the initial device certificate proving the genuineness of a Matter device from a given approved Vendor.
Distributed Compliance Ledger (DCL): a shared online ledger where every Matter VID, PID, PAA, and PAI must be declared and should be revoked if necessary. The DCL also lists the URLs to DAC CRLs (Certificate Revocation List) for every OEM. From a strict PKI point of view, the DCL acts as a centralized Validation Authority for all Matter OEMs and devices: Distributed Compliance Ledger (DCL).
Typical Matter OEM PKI covering 2 products, one of them with a redundant production
Considerations when Planning a Matter Device Attestation PKI
When reviewing Matter and its certificate-related requirements, several important questions and challenges typically arise, including compliance considerations and determining how to address requirements specific to my environment and product.
For many OEMs, the following areas require careful planning before moving forward:
Compliance and Specification Alignment
How do I ensure compliance with the Matter Certificate Policy: PKI Certificate Policy 2025?
How do I interpret and apply the Matter Core Specification to my specific products?
PKI Architecture and Security
How should I securely host a PAA (Product Attestation Authority) — the digital representation of my brand in the Matter ecosystem?
How should I host PAIs (Product Attestation Intermediates) to enable both security and high-volume DAC issuance in manufacturing?
How can I manage the revocation of PAIs and DACs?
Manufacturing and Provisioning Challenges
How can I assign DACs for identical products manufactured in different locations or factories?
What’s the process for issuing DACs at scale, in real time, during production?
Can I use my device’s secure element for Matter Device Attestation?
If my device doesn’t have a secure element, can I still provision a DAC?
If my device cannot generate private keys or CSRs (e.g., due to a low-cost MCU with poor RNG), what are my options?
Operational Constraints
If I outsource manufacturing, lack stable Internet connectivity in the factory, or lack in-house PKI expertise, are there turnkey solutions available?
How Keyfactor can help
Keyfactor EJBCA is Matter-compliant PKI software that allows OEMs to establish their own Matter PKI - PAA and PAIs - to generate DACs at scale in the factory. The variety of deployments of the PKI components fulfills every possible scenario an OEM may have. Additionally, Keyfactor is partnering with Trusted Objects, whose tops Plug&Go appliance provides an added layer of integration to address even the most complex in-factory manufacturing challenges.
The following outlines common approaches and configurations to meet Matter requirements, based on practical PKI implementations and deployment patterns.
Compliance and Specification Alignment
Complying with the Matter Certificate Policy
The Matter Certificate Policy defines strict requirements for hosting, administration, access control, and security at all PKI levels: PKI Certificate Policy 2025.
EJBCA can be configured for both VID-scoped (OEM-specific PAA root) and non-VID-scoped (shared PAA root) use cases, meeting Common Criteria standards and supporting various hosting models and RBAC (Role-Based Access Control) options to align with the policy: Interoperability and Certifications.
EJBCA is compliant with the latest HSMs available on the market, including the FIPS 140-3 Level 2 and 3 models as specified by the Matter certificate policy.
Complying with the Matter Core Specification
Matter uses the X.509v3 certificate format with specific Object Identifiers (OIDs) for Vendor Identifier (VID) and Product Identifier (PID), and enforces a 600-byte DER size limit for all certificates in the PAA-PAI-DAC chain PKI.
EJBCA implements these formats and OIDs natively and has been in production for Matter certificate issuance with many OEMs and trust providers since 2023. The Alliance Specifications Download Request Form.
PKI Architecture and Security
Hosting a PAA Securely
The PAA represents the OEM brand in the Matter ecosystem and must be handled as a high-value corporate asset.
A best practice is to keep it offline, backed by a FIPS 140-3 Level 3 HSM, and used only for signing new PAIs or updating PAI CRLs. EJBCA supports this approach across the hardware appliances and air-gapped deployments.
Hosting PAIs for Efficient and Secure Manufacturing
A PAI represents a product type and make in the Matter ecosystem, issues DACs in production and must be both secure and highly available.
Deploying PAIs with FIPS 140-3 Level 2 HSM protection and redundant infrastructure ensures availability without compromising security. EJBCA supports multiple deployment models, including hardware appliance, IaaS, and SaaS. Each option has distinct characteristics but can be configured to remain fully compliant with the Matter Certificate Policy.
One advantage of the hardware appliance deployment model is the inclusion of a built-in FIPS-certified HSM, providing secure key storage without the need for separate hardware. Keyfactor EJBCA Hardware Appliance.
Managing the revocation of PAIs and DACs
Cryptography constantly needs to adapt to adversaries. Increasing a key length or migrating to the latest algorithm will keep attackers at bay, and the Matter standard will be no exception. This has immediate consequences on the PKI: CAs and device certificates may need to be revoked and replaced by stronger ones over time.
In Matter, it is the role of the Commissioner to check the validity of the DAC, PAI and PAA chain upon enrolling a device into a Fabric. Part of the check is downloading the latest CRL - Certificate Revocation List - from a server. The URL to the CRL is traditionally provided inside the certificate, but not in Matter because:
The certificate is limited in size (600 bytes)
The DCL can centralize and manage this information
Therefore, URLs to CRLs for PAIs and DACs must be kept in the Device Attestation PKI Revocation Distribution Points Schema of the DCL.
A PAI can be revoked in a CRL signed either by its parent PAA or by a PAA-delegated certificate.
Likewise, a DAC can be revoked in a CRL signed either by its parent PAI or by a PAI-delegated certificate. This proves very useful whenever a PAI is located on-prem inside a factory on a production line and cannot be easily called to sign a CRL.
EJBCA can issue and manage PAA, PAIs, and DACs certificates, generate and host CRLs or make them available to a custom repository to which the DCL can point.
Manufacturing and Provisioning
Manufacturing in Multiple Locations
When production occurs at multiple sites, PAIs can either be accessed centrally over secure connections or deployed locally while sharing the same PID for a product.
EJBCA supports both models, enabling flexibility based on network availability and operational needs.
A factory with remote connection to a distant PAI#1 and another with a local PAI#1b, both assembling the same product
Generating DACs at Scale in Production
An RA (Registration Authority) may be placed between the production environment and the PAI to buffer and validate requests, ensuring secure and efficient real-time issuance.
EJBCA allows clear separation of RAs, CAs, and validation components to optimize manufacturing workflows.
Typical manufacturing with local PAI RA protecting access to the remote PAI CA
Device Hardware Capabilities
Using Secure Elements
Many secure elements support On-Board Key Generation (OBKG), though most require the MCU or production system to handle CSR creation. EJBCA can issue DACs for any secure element, including those using vendor-specific certificate compression.
Examples of supported secure elements by various silicon vendor partners
Without a Secure Element
Devices built around MCUs with a secure enclave or a TEE (Trusted Execution Environment) can handle key and certificate operations directly. For MCUs without these features, dedicated security stacks (e.g., Trusted Objects, Synopsys PUF) can provide secure storage and crypto processing. EJBCA integrates with both approaches.
Typical architecture of a secure MCU
Devices Without Key/CSR Generation Capability
If the device cannot generate keys or CSRs, the EJBCA PAI can generate and pass them to the production machine in a PKCS #12 file. In such case, strong protections around the PKI must be put in place to ensure that only legitimate certificate requests are passed over to the PAI. Otherwise, the PAI could find itself generating valid DACs for rogue or counterfeited devices.
Operational Constraints
Turnkey Solutions for Outsourced or Offline Manufacturing
When connectivity, expertise, or control is limited, turnkey appliances such as Keyfactor' partner Trusted Objects’ tops Plug&Go can automate VID/PID handling, DAC issuance, and device personalization with other OEM-specific keys, serial number, etc. It will also collect and inject the device bootloader and FW stack.
These solutions verify device authenticity and act as an enhanced RA in the production process.
Using an enhanced RA (e.g. tops plug&go) as the all-in-one secure gateway to remote resources used in the assembly of a Matter product, including the PAI CA
Hands-On Example: SaaS PAI with On-Prem PAA for OEM/Vendor Deployment
In this section, we take a practical approach by walking through an OEM/Vendor scenario. This example demonstrates both the physical and logical PKI architecture for a deployment that balances security, manufacturing efficiency, and scalability.
The Example
An OEM produces three Matter products (this example covers Product #1, it could, for example, be a washing machine). To ensure scalability, strong security, and streamlined production, the OEM adopts a hybrid PKI deployment that combines an on-premises hardware appliance with a cloud-based SaaS deployment of EJBCA PKI.
Product capabilities
Product #1 supports Matter onboarding, secure communications, and firmware updates. The device can generate its own cryptographic keys and CSRs inside a secure element on the main board.
Manufacturing setup
Manufacturing is handled directly by the OEM and is not outsourced. A production computer in the factory acts as the Registration Authority (RA). It communicates with the PKI via REST APIs, manages CSRs, and injects issued DACs into devices during production.
PKI architecture decision
The PAA (Root CA) is generated and managed in a secure on-premises EJBCA hardware appliance. It is self-signed with the OEM VID assigned by the Matter Alliance and registered in the DCL. For maximum isolation, the appliance can be turned off and stored in a secure safe.
The PAI runs in a SaaS EJBCA instance in the cloud for scalability and ease of management. The product PAI is signed by the PAA and also registered in the DCL. The PAI only accepts authenticated connections from the production computer.
In the factory, the production computer is configured to talk to the PAI via REST APIs and the PAI is configured to only accept connections from this computer playing the role of the RA in the PKI.
The production computer passes the PID and VID corresponding respectively to the product and OEM identifiers to the device being manufactured, instructs the device to generate its private/public key pair and a DAC CSR, receives it, sends it to the PAI, collects the DAC and injects it into the device.
The Matter DCL is pivotal in the vetting and validation process of a Matter device in the field, and as such, must be configured adequately with the OEM PAA, product PAI certificates and URLs to the DAC CRLs (Certificate Revocation Lists) if any.
A high-level physical and logical architecture diagram for our example:
Example: SaaS PAI with On-Prem PAA for OEM/Vendor Deployment
Conclusions
Matter device attestation relies on a robust PKI implementation to guarantee the integrity and security of IoT ecosystems. By utilizing a hierarchical certificate structure, with the PAA as the root of trust, PAI for product lines, and unique DACs for each device, Matter ensures that only authorized devices connect to the network.
EJBCA PKI facilitates this process by providing the tools to manage and automate the entire certificate lifecycle, from issuance and revocation to renewal. This is crucial for Matter's attestation models, whether it's:
Compliant with Matter security requirements
Compliant with worldwide data protection regulations
Flexible deployment options: hardware, software, cloud, SaaS
Easily extensible
By leveraging EJBCA, manufacturers can establish a robust and scalable PKI infrastructure for Matter-compliant device attestation. This ensures the authenticity and integrity of devices to a secure smart home ecosystem.
Moreover, with our Bring Your Own Root of Trust program - BYORoT - we are continuously making sure that EJBCA works with any MCU, MPU or secure element available on the market.
Related Content
Hands-On Guides
Further Reading
Contact us
Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.