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: This is a DigiCert partner post about accelerating Matter device certification through managed PKI, certificate lifecycle automation, and embedded support for OEMs.
Why it matters: It matters because IoT device trust depends on the same lifecycle discipline as other non-human identities, and weak certificate governance creates long-lived exposure across provisioning, rotation, and revocation.
By the numbers:
- Beechwoods’ average: up to 65% faster cycles for IoT OEMs.
- 50% less DevSecOps overhead (PKI, key management, and OTA workflows in one platform)
👉 Read DigiCert's post on Matter certification and device trust for IoT OEMs
Context
Matter device programmes are not only a product engineering problem, they are an identity and certificate governance problem. Every device needs a trustworthy identity, controlled issuance, and a predictable offboarding path, otherwise the programme accumulates exposed keys, inconsistent revocation, and compliance drift.
For OEMs, the hard part is not generating a certificate once. The hard part is sustaining certificate lifecycle management across prototype, manufacturing, field updates, and retirement while preserving auditability and keeping device trust aligned with policy.
That is why Matter certification should be read through an NHI lens. A device certificate is a non-human identity artefact, and the operational question is whether the organisation can govern it at scale rather than simply create it.
Key questions
Q: How should teams govern certificate-based device identities in IoT programmes?
A: Treat device certificates as non-human identities with an owner, lifecycle, and revocation path. Governance should cover issuance, storage, rotation, validation, and retirement, not just initial provisioning. The programme should also produce audit evidence that certificate status remains current across manufacturing, deployment, and field support.
Q: Why do IoT certificates become a governance risk when they are not rotated?
A: Unrotated certificates extend trust far beyond the point where their original context remains valid. That creates a standing-credential problem for devices, especially when fleets are large, distributed, or difficult to patch. Rotation reduces exposure only when it is tied to automated lifecycle controls and verifiable revocation.
Q: What breaks when device certificate revocation is handled manually?
A: Manual revocation breaks at scale because devices move faster than ticket-based processes can keep up. The result is stale trust, inconsistent enforcement, and weak auditability when a device is retired, compromised, or repurposed. Teams lose confidence in the accuracy of the certificate inventory itself.
Q: What should security teams look for in a certificate trust programme for Matter devices?
A: Look for automatic issuance, rotation, revocation, telemetry, and clear ownership across the device lifecycle. A sound programme should show where identities live, how they are validated, and how expired or compromised certificates are removed without manual intervention. That is what turns PKI into governance rather than overhead.
Technical breakdown
Matter device identity and certificate provisioning
Matter devices rely on cryptographic identity to prove they are genuine and authorised to join an ecosystem. In practice, that identity is established through certificate provisioning, often backed by an intermediate CA and an embedded SDK that can support constrained hardware. The operational challenge is not the cryptography itself but the lifecycle around it: secure generation, storage, binding to hardware, and traceable issuance across manufacturing and deployment. If those steps are inconsistent, device trust becomes fragile long before the product reaches the field.
Practical implication: treat device certificate issuance as governed identity provisioning, not a one-time engineering task.
Certificate lifecycle management for IoT fleets
Lifecycle management covers issuance, rotation, renewal, and revocation, which are the core controls that prevent certificates from becoming permanent trust liabilities. IoT fleets make this harder because devices may be offline, resource-constrained, or spread across multiple firmware states, so revocation and replacement must be designed for scale. When teams rely on manual processes or ad hoc tooling, they lose the ability to prove that a given device identity is still valid, current, and bound to policy.
Practical implication: align device identity operations to automated lifecycle controls so certificate status stays current across the fleet.
PKI telemetry, revocation, and auditability
PKI telemetry turns device identity from a static record into an observable control surface. Certificate health data, revocation status, and anomaly alerts help teams distinguish between normal device churn and identity problems that require intervention. For regulated or certification-driven environments, this matters because audit evidence depends on demonstrating that trust decisions are not only made, but continuously maintained. Without telemetry, organisations can neither measure exposure nor defend compliance claims with confidence.
Practical implication: use certificate telemetry and revocation visibility as evidence that device trust is being actively governed.
NHI Mgmt Group analysis
Device certificates are non-human identities, not mere deployment artifacts. When OEMs treat certificates as a build step instead of an identity object, they miss the governance reality that each device carries a lifecycle of issuance, rotation, revocation, and audit. That is the same structural problem NHIs create in cloud and SaaS environments, only shifted into embedded systems. The practitioner conclusion is to govern device certificates with identity discipline, not firmware-only thinking.
Certificate lifecycle management is the control boundary that separates secure device trust from persistent exposure. The article’s emphasis on automated issuance, rotation, and revocation reflects a familiar NHI pattern: exposure grows when credentials outlive the context that created them. In device programmes, the failure mode is not usually theft alone, but unmanaged persistence across manufacturing, distribution, and field maintenance. The practitioner conclusion is to treat certificate lifecycle as the trust boundary that must be continuously maintained.
Embedded Matter programmes expose a broader identity governance gap: compliance cannot be proved after the fact if identity state is not observable during operation. Certification support, HSM-backed key protection, and telemetry only matter when they create evidence that trust is current, not stale. That aligns directly with NIST Cybersecurity Framework 2.0 expectations for ongoing protection and detection. The practitioner conclusion is to make certificate health observable before audit and incident pressure force the issue.
Top 10 NHI Issues: device identity sprawl is a lifecycle problem before it becomes a security problem. As IoT fleets scale, the number of device identities grows faster than most governance teams can manually review. That makes certificate inventories, expiry monitoring, and revocation assurance more important than one-off launch readiness. The practitioner conclusion is to manage embedded device identity as an enduring programme, not a product milestone.
From our research:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
- For practitioners building a lifecycle programme, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows how issuance, rotation, and offboarding fit into one control model.
What this signals
Device trust programmes will increasingly be judged by whether certificate state is observable, not whether issuance is automated. OEMs that can prove current revocation status, expiry health, and ownership will be better positioned to withstand audit pressure as device fleets grow. The governing question is no longer whether PKI exists, but whether it behaves like an identity programme under operational scrutiny.
More devices will be treated as NHIs in governance inventories, which changes how security teams think about accountability. A device identity that cannot be rotated, revoked, or traced reliably becomes a persistent exposure regardless of whether the device is still in production. Teams should expect inventory, lifecycle, and evidence collection to become part of product release criteria, not after-the-fact compliance work.
For practitioners
- Map Matter certificates into your NHI inventory Treat each device certificate as a governed identity record with an owner, purpose, issuance source, expiry date, and revocation path. Include manufacturing, staging, and field devices so you can see where trust is created and where it can fail.
- Automate certificate rotation and revocation workflows Replace manual renewal and revocation steps with policy-driven workflows that can operate across constrained devices and large fleets. Prioritise devices that cannot be reliably patched or reimaged after deployment.
- Require telemetry for certificate health and anomalies Track revocation status, expiry proximity, failed validation, and unusual device certificate behaviour in one operational view. Use the data to prove trust posture during certification, audits, and incident response.
- Bind PKI ownership to the product lifecycle Assign clear accountability for device identity across engineering, security, manufacturing, and support teams. Make it explicit who approves issuance changes, who handles compromised certificates, and who retires identities at end of life.
Key takeaways
- Matter device security fails when certificate identity is treated as a build artifact instead of a governed lifecycle object.
- DigiCert’s figures point to faster certification and lower operational overhead, but the deeper lesson is that automated issuance, rotation, and revocation reduce identity exposure across the fleet.
- Practitioners should bring embedded certificates into the same inventory, ownership, and audit model used for other non-human identities.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Certificate rotation and revocation are central NHI lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Device certificate issuance and validation map to access control governance. |
| NIST Zero Trust (SP 800-207) | PR.AA-01 | Device trust depends on continuous identity verification, not one-time enrolment. |
Track device identities as access assets and enforce least privilege across the fleet.
Key terms
- Device Certificate: A device certificate is a cryptographic credential that proves a device’s identity to other systems. In IoT and embedded environments, it functions like a non-human identity, binding trust to a specific device, policy scope, and lifecycle state from issuance through revocation.
- Certificate Lifecycle Management: Certificate lifecycle management is the set of processes that govern issuance, renewal, rotation, revocation, and retirement of certificates. For devices, it is the control layer that keeps identity current and auditable across manufacturing, deployment, maintenance, and end of life.
- 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.
- Revocation: Revocation is the act of invalidating a certificate before its natural expiry because trust can no longer be assumed. In device identity programmes, revocation is essential for compromised, retired, or repurposed devices, and it only works when clients and monitoring systems can reliably enforce it.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by DigiCert: DigiCert + Beechwoods Embedded Experts Device Trust. Read the original.
Published by the NHIMG editorial team on 2025-10-14.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org