You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With multiple additional ways for commissioning Matter devices (in HA) like Matter's NFC based approach introduced in Matter 1.6 or the built-in BLE proxy support in HA core
this enables new or more refined ways for further shaping the Matter commissioning flow as it is today.
At the same time, the move to the matter.js based Matter Server has changed what happens at the end of that flow. Server 0.7.0 (18 May 2026) shipped as a breaking change that enables strict validation of Attestation and Certificates at commissioning, and this reached all users with Matter Server 9.0 alongside Home Assistant 2026.7:
Concretely, three things changed. Devices presenting only a test or development certificate are no longer accepted by default, where the old Python server accepted them. Certificate revocation data is now checked during commissioning and revoked certificates are treated as invalid. And the trust store itself now comes from the CSA Distributed Compliance Ledger, seeded at release time and refreshed in the background whenever the server has internet access.
These measures are sound and we do not want to walk them back. A device proves what it claims to be through a certificate chain that ends at a PAA the CSA vouches for. Test and development credentials are shared, public artifacts that anyone can flash, so accepting them by default means accepting any device that claims any vendor and product identity, which is precisely the case where a malicious device could join a user's fabric unnoticed. The old server could not easily draw that boundary; the new one can.
What did not come along with the new boundary is a way for the user to make the call. Today the flow simply fails at attestation, and the only remedy is a server wide option ("Test DCL", --enable-test-net-dcl / ENABLE_TEST_NET_DCL) that has to be found in the add-on configuration, applies to every future commissioning rather than to the one device in question, and needs a server restart. So the user is asked to lower the bar globally and permanently, in a settings screen, at a moment when they are standing next to a device with a QR code in their hand.
Every major ecosystem solves this the other way around: it asks. That is the gap this opportunity should close, alongside the BLE proxy and NFC work, because all of these touch the same flow.
To summarize, this opportunity tackles 2 concrete aspects of the Matter commissioning flow:
Handling of uncertified Matter devices in a more user friendly way
Optimizing the "Add matter device" dialog to also consider BLE proxies
There is a first proposal on how that could be established by @Apollon77
Home Assistant Native Discovery Implementation: Responding to a suggestion from the community during June's Monthly Matter community sync we could further investigate utilizing Home Assistant's native discovery features for Matter noting that using mDNS to detect commissionable devices on the network is a viable idea, though we must first determine how to handle the short-lived nature of Matter commissioning announcements.
The server itself has already had to soften the landing: release 0.8.0 lists an improvement to the error message shown when a device with a test or development certificate is commissioned without the Test DCL option enabled. A dead end that needs a better error message is usually a dead end that needs an exit.
Hard failure does not only affect DIY hardware. Release 1.1.0 pulled in a matter.js fix for an attestation certificate validation error affecting Nuki SmartLocks, a certified commercial product. Any check with no user visible override turns a library level or trust store level problem into "this device cannot be added", with no path forward for the user and a support request for us.
The confirmation dialog pattern is established and users already recognise it. Apple Home shows an "Uncertified Accessory" prompt with an "Add Anyway" option, and Google Home, Alexa and SmartThings all warn and continue in comparable ways. Our own Matter documentation instructs users to tap "Add Anyway" in Apple's dialog when adding a test board or beta device through iOS, so we are already relying on another ecosystem's confirmation dialog to get our users through this exact situation.
Worth noting the mirror image: Home Assistant's own Matter Hub bridge is uncertified, and users commissioning it into Google Home or Apple Home get precisely this prompt and proceed. Those ecosystems let their users add our uncertified bridge; we currently do not let ours add anything uncertified without a global flag.
Still to do: a systematic sweep of the forum, Discord and GitHub issues since 2026.7 to quantify how often this is being hit and with which device categories.
Scope & Boundaries
In scope
Rethink ways with the improved BLE proxying capabilities to commission Matter device without the requirement for the Companion App
Surface the attestation outcome inside the commissioning flow, per device, instead of failing with a generic error
Introduce an explicit user confirmation step for the recoverable uncertified cases, naming the vendor, the product and what specifically could not be verified
The plumbing this needs: a server to client confirmation round trip over the WebSocket API and the corresponding Home Assistant frontend dialog
Clear and actionable messaging for the cases we still refuse, including a stale or unavailable DCL trust store on installations without internet access
Mark devices that were commissioned without verified attestation so the decision stays visible afterwards
Revisit what role the server wide Test DCL option should still play once a per device confirmation exists
Not in scope
Weakening or making optional the certificate revocation check. A revoked certificate is an active signal, not an unknown, and should stay a hard failure with no override offered
A blanket "skip attestation" switch, or turning the Matter integration into a development tool
Changing how the trust store is sourced or distributed
Re-litigating the decision to enforce attestation strictly
Previous thoughts (just to have them for discussion)
From a first look it seems that most of the mechanism already exists - to be challenged.
matter.js exposes an onAttestationFailure option on the commissioning flow (DeviceAttestationValidator). It receives the list of attestation findings and can return proceed or reject, and because it may return a promise it can wait for something, including a user.
The Matter Server already wires this hook up (ControllerCommandHandler), but its callback is synchronous and returns a fixed message telling the user to go and enable the Test DCL setting. That message is the thing to replace.
So the foreseen shape is: on a recoverable finding, the server asks the connected client rather than rejecting. The client (Home Assistant) shows a confirmation dialog, the user's answer travels back, and the callback resolves to proceed or reject accordingly. This needs a WebSocket schema addition and version bump plus frontend work, but no fundamental change in the controller.
It also helps to stop treating "uncertified" as one case. The validator distinguishes them, and they deserve different answers:
The device presents official CSA test or development credentials (TrustedAsTestCertificate). This is exactly the case the Test DCL flag exists for, it is already collected as a recoverable finding rather than thrown, and it can be turned into a prompt today with no upstream changes.
The device presents a PAA that is not in the trust store at all (PaaNotTrusted), which covers self generated factory data as well as a legitimate device whose PAA entered the DCL after our seed data was built on an installation with no internet. This currently throws immediately and is not reachable from the callback, so covering it needs an upstream matter.js change to make the finding recoverable.
The certificate is revoked (CertificateRevoked). Hard failure, no prompt, no override.
Getting case 1 done first would already cover the flag's entire purpose with a better interaction, and would let us judge whether case 2 is worth pursuing upstream.
Risks & open questions
Risks
Introducing option that potentially overcomplicates existing flow
Clear communication of handling a BLE proxy for the commissioning flow rather than using the mobile phone + Companion app in proximity of the device to be commissioned
Problem statement
With multiple additional ways for commissioning Matter devices (in HA) like Matter's NFC based approach introduced in Matter 1.6 or the built-in BLE proxy support in HA core
this enables new or more refined ways for further shaping the Matter commissioning flow as it is today.
At the same time, the move to the matter.js based Matter Server has changed what happens at the end of that flow. Server 0.7.0 (18 May 2026) shipped as a breaking change that enables strict validation of Attestation and Certificates at commissioning, and this reached all users with Matter Server 9.0 alongside Home Assistant 2026.7:
Concretely, three things changed. Devices presenting only a test or development certificate are no longer accepted by default, where the old Python server accepted them. Certificate revocation data is now checked during commissioning and revoked certificates are treated as invalid. And the trust store itself now comes from the CSA Distributed Compliance Ledger, seeded at release time and refreshed in the background whenever the server has internet access.
These measures are sound and we do not want to walk them back. A device proves what it claims to be through a certificate chain that ends at a PAA the CSA vouches for. Test and development credentials are shared, public artifacts that anyone can flash, so accepting them by default means accepting any device that claims any vendor and product identity, which is precisely the case where a malicious device could join a user's fabric unnoticed. The old server could not easily draw that boundary; the new one can.
What did not come along with the new boundary is a way for the user to make the call. Today the flow simply fails at attestation, and the only remedy is a server wide option ("Test DCL", --enable-test-net-dcl / ENABLE_TEST_NET_DCL) that has to be found in the add-on configuration, applies to every future commissioning rather than to the one device in question, and needs a server restart. So the user is asked to lower the bar globally and permanently, in a settings screen, at a moment when they are standing next to a device with a QR code in their hand.
Every major ecosystem solves this the other way around: it asks. That is the gap this opportunity should close, alongside the BLE proxy and NFC work, because all of these touch the same flow.
To summarize, this opportunity tackles 2 concrete aspects of the Matter commissioning flow:
There is a first proposal on how that could be established by @Apollon77
Community signals
Pass network_only: false when commissioning Matter devices home-assistant/frontend#52456
Home Assistant Native Discovery Implementation: Responding to a suggestion from the community during June's Monthly Matter community sync we could further investigate utilizing Home Assistant's native discovery features for Matter noting that using mDNS to detect commissionable devices on the network is a viable idea, though we must first determine how to handle the short-lived nature of Matter commissioning announcements.
The server itself has already had to soften the landing: release 0.8.0 lists an improvement to the error message shown when a device with a test or development certificate is commissioned without the Test DCL option enabled. A dead end that needs a better error message is usually a dead end that needs an exit.
Hard failure does not only affect DIY hardware. Release 1.1.0 pulled in a matter.js fix for an attestation certificate validation error affecting Nuki SmartLocks, a certified commercial product. Any check with no user visible override turns a library level or trust store level problem into "this device cannot be added", with no path forward for the user and a support request for us.
The confirmation dialog pattern is established and users already recognise it. Apple Home shows an "Uncertified Accessory" prompt with an "Add Anyway" option, and Google Home, Alexa and SmartThings all warn and continue in comparable ways. Our own Matter documentation instructs users to tap "Add Anyway" in Apple's dialog when adding a test board or beta device through iOS, so we are already relying on another ecosystem's confirmation dialog to get our users through this exact situation.
Worth noting the mirror image: Home Assistant's own Matter Hub bridge is uncertified, and users commissioning it into Google Home or Apple Home get precisely this prompt and proceed. Those ecosystems let their users add our uncertified bridge; we currently do not let ours add anything uncertified without a global flag.
Still to do: a systematic sweep of the forum, Discord and GitHub issues since 2026.7 to quantify how often this is being hit and with which device categories.
Scope & Boundaries
In scope
Revisit what role the server wide Test DCL option should still play once a per device confirmation exists
Not in scope
Foreseen solution
Proposal as mentioned here
Previous thoughts (just to have them for discussion)
From a first look it seems that most of the mechanism already exists - to be challenged.
So the foreseen shape is: on a recoverable finding, the server asks the connected client rather than rejecting. The client (Home Assistant) shows a confirmation dialog, the user's answer travels back, and the callback resolves to proceed or reject accordingly. This needs a WebSocket schema addition and version bump plus frontend work, but no fundamental change in the controller.
It also helps to stop treating "uncertified" as one case. The validator distinguishes them, and they deserve different answers:
Getting case 1 done first would already cover the flag's entire purpose with a better interaction, and would let us judge whether case 2 is worth pursuing upstream.
Risks & open questions
Risks
Appetite
No response
Execution issues
No response
Decision log