A PoV on Matter Security and Zero Trust Architecture
When it comes to smart homes, getting devices connected is only the beginning. Matter has transformed this connected landscape by providing a common standard that enables products to connect to various ecosystems such as Apple Home, Google Home, Amazon Alexa, and others to work together seamlessly. This has made smart home experiences simpler, more reliable, and far easier for users to manage.
However, connectivity alone does not guarantee trust and security. While Matter establishes a strong foundation for secure device onboarding through mechanisms such as device attestation and certificate-based authentication, the security journey does not end once a device is commissioned. Smart devices continue to evolve through firmware updates, configuration changes, and feature enhancements, while also facing an ever-evolving threat landscape.
This creates a critical challenge for connected ecosystems: how can trust be maintained long after a device has joined the network? The real question is no longer whether a device was trustworthy on day one, but whether it continues to operate securely and as intended throughout its lifecycle.
Let’s explore how continuous verification, including periodic re-attestation, firmware integrity checks, and runtime behavioral monitoring, can bridge this gap and extend Matter’s trust model beyond the commissioning handshake. In this article, Rohan Nathi, Lead Engineer, System Software, shares his perspective on maintaining trust in Matter-enabled devices long after onboarding. Drawing on his experience in embedded systems, firmware development, and IP-based connectivity, Rohan explains why trust established at commissioning is only the first step and how a more resilient, lifecycle-aware Zero Trust approach can help strengthen security across modern smart home ecosystems.
He discusses the importance of continuously validating device identity, monitoring firmware integrity, and verifying device behavior throughout its operational lifecycle. As connected devices evolve through software updates and configuration changes, these capabilities become essential for detecting security risks and ensuring that devices continue to operate as intended.
Rohan also highlights how a continuous verification approach can help address lifecycle security challenges, reduce the risk of post-commissioning attacks, and strengthen consumer confidence in smart home networks.
To understand how this can be achieved in practice, let’s dive into the core challenge and explore the path from one-time trust to continuous assurance.
Q.1: Why move from a "one-time handshake" to continuous Zero-Trust verification?
A.1: Matter basically onboard devices through a pre-defined set of security rules. These rules are applied when users want to onboard the devices. Through device attestation and certificate-based authentication, Matter verifies that a device is genuine before allowing it to join the network and establishes an initial level of trust. This approach works well for device commissioning, but it is fundamentally a one-time verification process.
A one-time handshake only proves that a device was genuine when it was commissioned. In the current Matter model, once a device completes attestation, it is generally trusted for the rest of its lifetime unless it is explicitly removed or revoked. The problem is that a device’s security can change long after commissioning. Firmware can be tampered with, vulnerabilities exploited, malicious updates installed, or cryptographic keys compromised. Yet, the controller has no built-in mechanism to automatically detect these changes because attestation is not performed again during normal operation.
Another limitation is certificate revocation. While Matter supports revocation through the Device Compliance Ledger (DCL), checking whether a device’s attestation certificates have been revoked is optional rather than mandatory. In the absence of active checks performed by the Matter Controller, a device operating under certificates that have been revoked will be allowed to continue operation without interruption.
It also raises a bigger problem with static trust since a cryptographic proof generated during commissioning only captures the state of the device at commissioning time.
This means it cannot be guaranteed that the device is still secure weeks or months after commissioning since new vulnerabilities could be discovered, the firmware could change, or the threat landscape could evolve. That is why Matter Security cannot depend only on proof at onboarding.
The concept of Zero-Trust helps one to conquer this problem through trust as something that needs to be earned continuously and not across-out differently. Instead of presuming that the device is trusted and reliable simply because it was on the same network, the system controller must validate that device’s identity on an ongoing basis; this requires checking to make sure that the device has the software and behavioral patterns as expected. In other words, the model shifts from “prove identity once and trust forever” to “continuously verify before trusting.”
Q.2: How can the controller continuously validate identity, integrity, and behaviour post-commissioning?
A.2: Commissioning should not be the last time a Matter device is trusted. A production controller can continue validating a device throughout its lifetime by periodically re-checking its identity, integrity, and runtime behaviour.
For identity, the Attestation Request command in the Operational Credentials cluster is available post-commissioning, not just at first join. The controller can re-trigger it at regular intervals or before sensitive operations like firmware updates or access control changes, confirming the device still holds its original hardware-backed private key and a valid, unrevoked DAC chain.
To assure integrity, the controller will check the runtime data report against VendorID, ProductID, software version, reboot logs, and the diagnostic data with the expected baseline and the data in the DCL servers. If there are any unexpected changes, such as mismatched software versions, strange reboots, or any other change in the details of the device, it will be an indication of compromise.
For revocation, the controller should periodically check CSA’s certificate revocation lists and re-validate the running firmware version against the DCL server to ensure it remains certified and hasn’t been withdrawn.
Together, these checks use the device’s immutable hardware-backed identity as a stable trust anchor while continuously re-evaluating everything built on top of it. This ongoing model is central to stronger Matter Security in production deployments.
Q.3: How does Matter enable seamless and secure handovers between multiple ecosystem controllers?
A.3: Matter makes this possible through a feature called multi-fabric architecture. Simply put, it allows a single smart device to connect to multiple smart home platforms at the same time.
Think of a fabric as a secure, private network managed by a specific platform. This means the same smart device can be connected to Google Home, Apple Home, and Amazon Alexa simultaneously. Each platform communicates with the device independently using its own secure credentials, so users can control the same device from their preferred ecosystem without any conflicts.
Trust is maintained separately per ecosystem, so a compromised controller on one fabric cannot affect the others. When a new controller is added, Matter doesn’t simply trust it because another controller already manages the device. The existing controller opens a commissioning window, generating a temporary pairing code. The new controller uses this to establish its own independent credentials; no factory reset, no re-scanning the original QR code required.
This is where JCM (Joint Commissioning Method) strengthens the process. It validates the incoming controller’s vendor identity, cross-checks its administrator information, and requires explicit user consent before granting privileges. The device actively verifies each new controller rather than blindly accepting any commissioning request.
The result is seamless from the user’s perspective, just a simple confirmation while remaining cryptographically secure because every controller independently earns its own trust relationship with the device.
Q.4: How does Immutable Identity ensure persistent, tamper-proof attestation across restarts and re-joins?
A.4: Immutable Identity is referred to as permanent and unchangeable digital fingerprint security. Immutable Identity is established during manufacturing, where the device generates its DAC private key inside a secure hardware environment. Once created, it’s permanently bound to the device protected by technologies like PUF, TEE, or secure storage and cannot be extracted, replaced, or regenerated.
Because identity is tied to hardware rather than software or a commissioning session, it survives reboots, factory resets, fabric removal, and re-commissioning. Whenever the controller requests device attestation, the device presents the same DAC certificate chain and proves ownership of the corresponding private key using a fresh cryptographic challenge. This hardware-rooted continuity is one of the strongest pillars of Matter Security.
Q.5: What is the role of the Device Compliance Ledger (DCL) in real-time revocation and trust verification at the edge?
A.5: The DCL server extends Matter’s trust model beyond static certificates by providing an up-to-date view of the ecosystem’s trust status covering newly approved certificate authorities, certification changes, software compliance, and revocations that may have occurred since the controller’s firmware was built.
Its most important role is granular software compliance. Rather than revoking an entire device over a single vulnerable firmware release, the DCL can mark a specific version non-compliant while keeping newer, patched versions trusted. An edge controller can continuously compare a device’s reported software version against this, identifying devices running deprecated or vulnerable firmware.
Critically, revocation is independent of the device itself. A compromised device cannot escape revocation by going offline; the status change lives in the DCL, not on the device. If the controller periodically syncs, it detects changes and responds accordingly.
In practice, edge controllers maintain a local DCL mirror for resilience. As the cache ages, trust confidence reduces until the next sync, combining local performance with the ability to adapt to real-time ecosystem changes.
Ultimately, leveraging deep expertise in consumer electronics services, MosChip offers comprehensive engineering capabilities across the entire Matter landscape. From initial hardware design and custom firmware porting to Thread border router integration and multi-fabric development, we build turnkey ecosystems. We also provide full lifecycle services, custom mobile apps with edge AI, and end-to-end certification support to accelerate your time-to-market.
To know more about MosChip’s capabilities, drop us a line, and our team will get back to you.
