Because identity proves who made the device, while firmware integrity proves what is running on it. Either control on its own is incomplete. A device can be authentic at onboarding and still become unsafe if its software can be altered, so trust has to extend across both identity and code provenance.
Why Matter Needs Both Device Identity and Firmware Integrity
Matter trust is strongest when you can verify both the hardware endpoint and the software state it is running. device identity answers whether the product is the expected device, while firmware integrity answers whether that device is still running trusted code. In practice, these are separate questions, and each closes a different gap in onboarding and ongoing trust.
Device identity is the anchor for enrollment, access decisions, and ownership. It lets a controller distinguish a legitimate light, lock, sensor, or hub from a lookalike or replayed endpoint. Firmware integrity complements that by checking whether the device’s software image has been signed, measured, or otherwise protected against tampering after manufacture or during updates. Without both, trust can be established too early and then silently lost later.
That separation matters because a device can be genuine and still dangerous. If an attacker alters firmware, injects malicious logic, or replaces a valid image with a compromised one, the device may continue presenting a valid identity while behaving in an unsafe or unexpected way. The reverse is also true: integrity checks are useful, but they do not tell you whether the endpoint is the right device, owned by the right party, or enrolled into the right fabric.
How the Two Controls Work Together
Device identity usually supports the root-of-trust side of the relationship, through unique identifiers, certificates, attestation, or secure onboarding. Firmware integrity supports the runtime side, by asserting that the code image matches a trusted baseline and has not been altered since signing or last validation. The first protects who joins; the second protects what is allowed to run once it has joined.
In a Matter environment, that pairing is especially important because the ecosystem is built around onboarding, interoperability, and device lifecycle changes. A device may be provisioned correctly at the beginning, yet later receive a bad update, suffer local tampering, or inherit a compromised supply-chain image. Strong identity alone would not catch that post-onboarding drift, and integrity alone would not establish device ownership or trust boundaries.
This is why firmware provenance and device trust are better treated as complementary controls rather than alternatives. Device identity gives you continuity across sessions and networks, while firmware integrity gives you confidence that the endpoint’s behavior still matches the trust decision made at enrollment. For a useful reference point on device trust, onboarding, and firmware signing, see Device and IoT Identity Guide.
Why Gaps in Either Layer Create Exposure
When device identity is weak, an attacker can impersonate a device, register an unauthorized endpoint, or substitute a cloned product that looks legitimate to the controller. When firmware integrity is weak, an attacker can keep the same device identity but change the software beneath it, which is often more dangerous because the trust signal still appears valid. A good example of this pattern is hard-coded or bypassable firmware authentication on devices, which can let unauthorized parties get control even when the hardware is real. See HPE Aruba Instant On hard-coded credentials for an illustration of firmware-level trust failure.
Firmware integrity also matters for update hygiene. If update mechanisms do not enforce signing, verification, or anti-rollback protections, a device can be downgraded or altered after deployment and still remain network-visible. That is why Matter implementations need to treat integrity as part of the trust boundary, not as a one-time manufacturing check. Open standards for build and software provenance reinforce the same lesson at the artifact level, as described by SLSA and the broader supply-chain work at OpenSSF.
Risk and Threat Considerations
Where Matter devices control doors, safety functions, environmental systems, or home automation, the combination of impersonation risk and firmware tampering risk becomes operationally significant. An attacker does not need to break both controls at once, they can target whichever one is weaker and use that to obtain unauthorized access or persistent control.
Failure mechanism: A legitimate-looking device can remain enrolled while its firmware is modified, or a fraudulent device can be onboarded with a convincing identity but untrusted code. In both cases, the trust model is broken because the identity signal and the software state no longer agree.
Impact: Controllers may continue granting access, automations may execute unsafe actions, and operators may miss compromise because the device still appears authenticated. The result is persistent misuse of a trusted endpoint rather than an obvious perimeter breach.
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 SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Firmware integrity depends on trusted build and provenance controls. |
| Recommendation — Require verifiable build provenance for device firmware before release. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Device identity depends on protected credentials and lifecycle control. |
| SI-7 — Software, Firmware, and Information Integrity | The question centers on verifying firmware has not been altered. | |
| IA-3 — Device Identification and Authentication | Matter device identity requires unique, verifiable device authentication. | |
| Recommendation — Manage device authenticators so enrollment secrets cannot be reused or stolen. Validate firmware integrity before installation and during update verification. Use unique device identity and authentication before granting network trust. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Device identity must resist bypassable or weak authentication paths. |
| Recommendation — Eliminate weak device authentication paths that allow impersonation. | ||
Practitioner Guidance
What to verify: Treat onboarding evidence and runtime integrity evidence as separate checks. Confirm that the device has a durable identity rooted in a trusted enrollment path, and separately confirm that its firmware can be measured, signed, or validated before update acceptance.
What good looks like: A Matter device should not be considered trustworthy just because it paired successfully. Good practice is to be able to answer both questions at any time: is this the expected device, and is it still running expected code?
Practitioner takeaway: The safest Matter deployments do not collapse device trust into a single control; they preserve identity for ownership and authorization, and integrity for runtime confidence, because either one can fail while the other still looks healthy.
Related resources from NHI Mgmt Group
- Why do device posture and segmentation matter in high-variance environments?
- How should manufacturers govern device identity in Matter environments?
- Why does unique device identity matter for IoT security in connected environments?
- How can security teams tell whether device identity is actually working?