TL;DR: Matter device launches are being framed as a certification and certificate-lifecycle problem, with claims of up to 65% faster certification, 50% less DevSecOps overhead, and zero exposed keys when issuance, rotation, and revocation are handled in a managed workflow, according to DigiCert. The governance lesson is that device trust breaks fastest where teams still treat PKI as an engineering side task rather than an identity programme.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Matter certification for IoT OEMs centers on certificate lifecycle management as the foundation of device trust, launch speed, and compliance continuity.
Why it matters: It matters because IoT identity programmes fail when per-device certificates, rotation, and revocation are handled as ad hoc engineering work instead of governed lifecycle control.
Context
Matter certification for IoT devices is not only a product-testing exercise. It also depends on whether OEMs can issue, manage, rotate, and revoke per-device certificates without turning PKI into a manual bottleneck.
For identity teams, the practical issue is workload and device trust governance. When certificate lifecycle management sits outside the core launch process, certification delays, exposed keys, and compliance drift become more likely as devices move from prototype to retail.
Key questions
Q: What breaks when Matter certificates are handled as one-off engineering artefacts?
A: Certification becomes brittle because each device identity can drift away from the records that prove it is trusted, compliant, and revocable. That creates delays in launch, harder audit evidence, and a larger recovery burden when a device or key has to be withdrawn.
Q: Why do per-device certificates matter for IoT OEM compliance?
A: Per-device certificates give each unit a distinct trust anchor, which is essential when devices move through manufacturing, testing, shipment, and field operation. Without that separation, revocation and accountability become fuzzy, and a single compromise can affect a much larger set of devices.
Q: Why do IoT programmes need certificate lifecycle management?
A: Because device identity is only useful if it can be discovered, rotated, renewed, and revoked on time. Without lifecycle management, certificates outlive the devices and services they protect, leaving stale trust in place and creating a long tail of exposure that scales with fleet growth.
Q: How should teams govern certificate rotation for Matter devices?
A: Teams should tie rotation to clear lifecycle events such as manufacturing release, firmware updates, compromise response, and retirement. Rotation should be policy-driven and evidenced in inventory records so that device trust does not depend on tribal knowledge or individual engineers.
Technical breakdown
Per-device certificate issuance in Matter OEM environments
Matter device trust relies on each device having a unique certificate chain rather than a shared credential model. In practice, OEMs need an Intermediate CA, device-side SDK integration, and provisioning workflows that bind identity to hardware before shipment. That makes certificate issuance part of identity architecture, not a late-stage ops activity. If issuance is inconsistent across prototypes, test fixtures, and production runs, certification evidence becomes fragile and device trust becomes harder to prove.
Practical implication: Map device identity issuance to a governed provisioning process before certification testing begins.
Certificate rotation and revocation as lifecycle controls
Certificates are not static artefacts. They must be rotated to reduce compromise exposure and revoked when devices, keys, or manufacturing contexts change. In an IoT estate, that lifecycle spans factory provisioning, field operation, firmware updates, and retirement. If rotation and revocation are manual or fragmented, exposed keys remain valid longer than intended and compromised devices can stay trusted after the original risk has emerged.
Practical implication: Treat rotation and revocation as mandatory lifecycle checkpoints for every device identity.
Why managed PKI reduces certification friction
Managed PKI shifts the burden of device identity governance away from one-off engineering decisions and into repeatable control. That matters for Matter because certification, compliance evidence, and post-launch maintenance all depend on the same identity records and cryptographic state. When those controls live in separate systems, OEMs spend more time reconciling certificate health, test status, and field compliance than shipping devices.
Practical implication: Align certificate management, certification evidence, and runtime monitoring under one operating model.
Threat narrative
Attacker objective: Obtain or abuse device identity material so that Matter trust, certification integrity, or compliance posture can be undermined.
- entry via device provisioning paths that create or import Matter certificates into OEM workflows
- credential exposure when private keys are handled outside protected lifecycle controls or exposed through DIY processes
- escalation through reuse of poorly governed certificates across devices, environments, or firmware stages
- impact in the form of delayed certification, weakened device trust, and compliance gaps after launch
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Matter certification is becoming a certificate-lifecycle governance problem, not just a device-compliance task. OEMs can pass technical tests and still fail operational trust if issuance, rotation, and revocation are not controlled as one lifecycle. That is why device identity now sits inside broader NHI governance rather than isolated embedded engineering. The practitioner takeaway is to treat certification readiness and certificate governance as the same programme.
Zero exposed keys is an operating condition, not a marketing outcome. Once private keys leave protected lifecycle controls, the device estate inherits long-lived trust debt that is expensive to unwind. The article’s emphasis on managed generation, rotation, and revocation points to the real control boundary: who can create, store, and retire device credentials. Practitioners should read that as a warning that trust breaks at the credential lifecycle edge.
Built-in analytics matter because certificate health is an identity signal, not a maintenance metric. Telemetry on revocation, anomalies, and certificate state gives teams the evidence they need to know whether device trust is still intact after shipment. Without that visibility, certification becomes a point-in-time event instead of an ongoing governance posture. The implication is that device identity must be observable if it is to remain governable.
Named concept: certificate trust debt: The longer OEMs postpone lifecycle governance, the more trust risk accumulates in issued certificates, stored keys, and field devices. That debt shows up as slower certification, harder revocation, and more expensive compliance recovery. Practitioners should recognise that every unmanaged credential adds to the future cost of proving device trust.
Matter device identity belongs in the same governance conversation as IAM and lifecycle management. The article shows that per-device certificates, provisioning, and revocation are not special cases but identity controls with a different subject type. That means the governance model should extend beyond human access to include workloads, devices, and embedded identities. Practitioners should manage Matter devices as governed identities, not as hardware exceptions.
What this signals
Certificate trust debt: The longer device certificates and private keys stay outside a governed lifecycle, the harder it becomes to prove trust after deployment. For OEMs, the real test is whether issuance, rotation, and revocation remain observable once devices leave the lab.
Matter turns embedded trust into an identity programme concern because the control point is no longer just the device firmware. It is the certificate lifecycle that follows the device through manufacturing, certification, and field operations, which is why launch teams and identity teams need a shared operating model.
For practitioners
- Standardise per-device certificate provisioning Define a repeatable provisioning flow that generates unique certificates for each device and binds them to approved manufacturing and test paths. Avoid shared credentials across prototypes or production batches.
- Make rotation and revocation mandatory lifecycle steps Require every Matter device identity to have explicit rotation and revocation triggers tied to firmware updates, compromise response, and end-of-life handling.
- Separate certification evidence from engineering workarounds Keep certificate status, test readiness, and compliance evidence in governed records rather than in ad hoc spreadsheets or build notes.
- Monitor certificate health after shipment Use certificate telemetry to watch revocation status, anomalies, and expired credentials so that post-launch trust problems surface before they become fleet-wide issues.
Key takeaways
- Matter certification exposes a governance gap when device identity is treated as a one-time engineering task rather than a managed lifecycle.
- The article ties faster certification and lower overhead to controlled issuance, rotation, and revocation of per-device certificates.
- OEMs that cannot observe certificate health after shipment will struggle to keep Matter devices compliant and trusted over time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Device identities must be revoked cleanly when OEMs retire, replace, or reissue certificates. |
| NHI-07 — Long-Lived Secrets | The article stresses rotation and revocation to prevent long-lived device keys from persisting in the field. | |
| Recommendation — Define offboarding triggers for Matter device certificates and revoke identities when devices leave service. Shorten certificate lifetimes and enforce rotation so device trust does not depend on stale credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance, rotation, and revocation map directly to authenticator lifecycle management. |
| Recommendation — Apply IA-5 to govern device certificates across issuance, rotation, and revocation. | ||
| CIS Controls v8 | CIS-5 — Account Management | IoT device certificates require the same lifecycle discipline as other managed credentials. |
| Recommendation — Track device certificate inventories and remove credentials that no longer belong to active devices. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud-managed device identity and certificate telemetry fall under IAM governance in the CCM. |
| Recommendation — Use IAM controls to manage device identity records, certificate state, and revocation evidence. | ||
Key terms
- Matter Certification: Matter certification is the process of proving that a device meets the connectivity and interoperability requirements expected by the ecosystem. For IoT OEMs, it also depends on whether the device identity and certificate lifecycle are governed well enough to sustain trust after launch.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Intermediate Certificate Authority: An intermediate certificate authority is a delegated signing layer that issues certificates on behalf of a higher-level root CA. In device trust programmes, it helps scale issuance while preserving separation of duties, but it also becomes a critical governance point because its policies shape device identity integrity.
- Device Trust: Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org