Matter protocol changes smart device identity and trust models

At a glance

What this is: Matter is an interoperability standard for smart and IoT devices that uses certificate-based trust to simplify cross-vendor connectivity and device integrity.

Why it matters: It matters because enterprise and home IoT adoption expands the number of device identities, trust relationships, and update paths that IAM and security teams must govern.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read DigiCert's analysis of Matter and smart device identity trust

Context

Matter is a device interoperability standard for the smart home and connected workplace. Its security value comes from giving devices a common way to prove identity and establish trust across vendor boundaries, instead of relying on ad hoc integrations and repeated credential sharing.

For identity and access teams, the interesting question is not whether smart devices are convenient. It is whether their identities, certificates, update trust, and third-party connectivity can be governed with the same discipline used for other non-human identities, especially as consumer IoT increasingly enters enterprise environments.

Key questions

Q: How should security teams govern smart device identities in mixed-vendor environments?

A: Security teams should treat smart devices as governed non-human identities. That means assigning ownership, using certificate-based trust, controlling lifecycle events such as renewal and revocation, and requiring visibility into every device that can authenticate into shared systems. Interoperability should simplify operations, not remove accountability.

Q: Why do connected devices create identity risk for enterprise programmes?

A: Connected devices create identity risk because they multiply the number of trusted endpoints, credentials, and update paths that must be managed. If a device can authenticate, receive updates, or connect to business systems, it has an identity footprint that needs lifecycle control and monitoring, not just network segmentation.

Q: What breaks when device certificates are not managed as part of lifecycle governance?

A: When device certificates are not lifecycle-managed, revocation, ownership change, and re-enrolment become unreliable. A device may stay connected after it should have been removed from trust, which turns a valid identity into a stale one. That is how connectivity remains intact while governance fails.

Q: Which controls matter most when smart devices connect to enterprise systems?

A: The most important controls are certificate validation, signed update verification, ownership assignment, and revocation processes. Those controls ensure that connectivity is backed by trust, that updates come from approved sources, and that devices can be removed from the environment when their business need ends.

Technical breakdown

Device attestation certificates and cryptographic identity

Matter devices use a unique Device Attestation Certificate to prove that a device is genuine and has been issued by a manufacturer. That certificate sits inside a PKI trust chain, which lets devices verify origin and establish encrypted communication without exposing reusable passwords. In practice, this shifts trust from shared credentials to verified device identity. It also creates a governance boundary: if the certificate lifecycle is weak, the trust model weakens with it. Practical implication: security teams need certificate issuance, validation, and revocation processes that are as disciplined as any other non-human identity control.

Practical implication: security teams need certificate issuance, validation, and revocation processes that are as disciplined as any other non-human identity control.

Interoperability without repeated secret sharing

The central promise of Matter is that devices from different vendors can interoperate without the brittle, manual integrations that have historically required repeated logins, custom APIs, or platform-to-platform credential handoffs. That matters because every extra integration step becomes another place where secrets are copied, reused, or left in place after the original need has passed. In identity terms, interoperability should reduce credential sprawl, not hide it. Practical implication: teams should treat smart-device onboarding as an identity lifecycle problem, not just a networking or facilities task.

Practical implication: teams should treat smart-device onboarding as an identity lifecycle problem, not just a networking or facilities task.

Signed updates and device integrity

Matter also expects software updates to come from digitally verified sources, with certificate-based signing used to preserve device and firmware integrity. That is important because connected devices are not static assets. Their trust posture changes each time firmware is patched, updated, or re-enrolled. If the verification chain is broken, a device can remain connected while no longer being trustworthy. This is the same structural problem seen in other machine identity environments: connectivity is not proof of legitimacy. Practical implication: patching programmes must include trust validation, not just version tracking.

Practical implication: patching programmes must include trust validation, not just version tracking.

Threat narrative

Attacker objective: The objective is to abuse trusted device connectivity so a malicious or compromised device can operate inside legitimate smart-device workflows and extend access beyond its intended role.

1. Entry occurs when a smart device or its companion platform is onboarded into the environment through a trust relationship that is assumed rather than verified.
2. Escalation occurs when the device is allowed to communicate across systems using reused credentials, weak integration paths, or stale trust relationships after updates.
3. Impact occurs when a compromised or mismanaged device can no longer be distinguished from a legitimate one and is used to disrupt operations, expose data, or extend trust into other connected systems.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device interoperability becomes an identity problem before it becomes an integration problem. Matter reduces friction, but the governance burden shifts to certificates, onboarding, and lifecycle control across devices that may come from multiple vendors. That is a familiar pattern in machine identity security: once credentials and trust are distributed across many endpoints, visibility becomes the limiting control. The implication is that smart-device programmes need identity governance, not just compatibility testing.

Certificate-based trust is stronger than shared login credentials, but only if the lifecycle is controlled. The article correctly points to PKI and signed updates, which are foundational to device trust. Yet certificate strength does not solve revocation, re-enrolment, or ownership change by itself. This is the same failure mode seen in service-account governance: a valid identity can still be the wrong identity if lifecycle control is absent. Practitioners should treat device certificates as governed identities, not static technical artefacts.

Smart devices are a preview of how enterprise NHI sprawl will behave when business demand outruns security design. The article’s BYOD analogy is apt. Users and business units will keep pushing connected devices into operational environments because the productivity case is obvious. That creates the same governance pressure seen in broader NHI populations, where scale outpaces confidence and accountability. The result is not just more devices, but more unmanaged trust edges.

Digital trust for connected devices depends on reducing hidden credential paths. Matter’s design goal is to eliminate brittle, vendor-specific workarounds, but the underlying security value comes from replacing informal secret exchange with verifiable device identity. This is the right direction for NHI governance generally: reduce standing trust, reduce repeated credential handling, and make revocation possible. The practitioner conclusion is simple. If a connected device cannot be independently trusted, it should not be independently connected.

Consent and compatibility will drive adoption faster than security teams can redesign control planes. That is why smart-device governance must be built for scale from the outset. If controls are added only after device sprawl is already embedded in facilities, home, or production environments, identity review becomes reactive and incomplete. The field lesson is that interoperability standards change the shape of the risk, but not the need for explicit governance.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly machine identity governance breaks down once trust scales beyond a few known systems.
• The next step is to align device certificates, revocation, and ownership with Ultimate Guide to NHIs , Why NHI Security Matters Now so connected-device programmes do not outgrow control design.

What this signals

Certificate-backed device trust will accelerate IoT adoption, but it will also expose the same governance gaps seen in broader NHI programmes. The practical signal for security teams is that onboarding standards must be paired with identity lifecycle ownership, otherwise interoperability simply scales unmanaged trust. For teams building governance around machine identity, the useful reference point is the NIST Cybersecurity Framework 2.0, especially around identify, protect, and recover functions.

Identity teams should expect smart-device sprawl to enter the same control conversation as service accounts and workload identities. Once devices can authenticate, update, and exchange data across vendors, they become part of the identity estate whether or not the organisation labels them that way. The programme-level question is whether inventory, revocation, and attestation are already integrated into operational change management.

Device trust debt: connected environments accumulate trust edges faster than they retire them, which means every new device class increases the future cost of cleanup. That is why operational readiness now depends on knowing who owns each device identity, how certificates are renewed, and how trust is withdrawn when hardware changes hands.

For practitioners

• Define device identity ownership before onboarding Assign a business owner, technical owner, and certificate steward for each device class before it is connected to any shared environment. Without clear ownership, revocation and renewal decisions become guesswork after deployment.
• Treat certificate lifecycle as a control, not an afterthought Track issuance, renewal, revocation, and replacement for device certificates in the same way you track other non-human identities. Validate that devices fail closed when certificates are expired, replaced, or withdrawn.
• Reduce credential sharing across vendor ecosystems Eliminate repeated logins and cross-platform secret handoffs wherever possible. Where interoperability depends on integrations, prefer cryptographic trust and short-lived, governed credentials over shared secrets.
• Include firmware trust in patch governance Verify that firmware and software updates are signed, source-validated, and traceable to an approved trust chain. Patch status alone is not enough if the update path itself is untrusted.

Key takeaways

• Matter reduces integration friction, but it does not remove the need to govern connected devices as identities.
• Certificate-based trust improves device authenticity only when issuance, renewal, and revocation are controlled across the full lifecycle.
• For security teams, the main decision is whether smart-device onboarding will be treated as an identity programme or left as a series of ad hoc integrations.

Key terms

• Device Attestation Certificate: A device attestation certificate is a cryptographic credential used to prove that a connected device is genuine and was issued by a trusted manufacturer. In identity terms, it turns device authenticity into something that can be verified, audited, and revoked instead of assumed.
• Machine Identity: Machine identity is the set of credentials and trust signals used by a non-human system to authenticate and communicate. For smart devices, it usually includes certificates, keys, firmware trust, and ownership metadata that must be governed across the device lifecycle.
• Certificate Lifecycle: Certificate lifecycle is the process of issuing, renewing, validating, replacing, and revoking certificates over time. In connected-device environments, lifecycle control matters because a valid certificate can still belong to the wrong device if ownership, firmware, or use case has changed.
• Interoperability Trust Model: An interoperability trust model is the framework that lets devices from different vendors communicate safely without ad hoc credential sharing. It depends on common identity verification, signed updates, and defined trust boundaries so compatibility does not create unmanaged access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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: The Matter with Smart Devices. Read the original.