42  Matter Device Commissioning

Keywords

Matter commissioning evidence, Matter PASE CASE review, Matter device attestation, Matter operational credentials, Matter multi-admin commissioning

42.1 Start With the Trust Boundary

Start with the trust boundary in Matter Device Commissioning: who is allowed to join, who can carry keys or credentials, and which record proves that the decision was made correctly. A short-range protocol is only as useful as the join, identity, and recovery evidence around it.

The start-simple move is to follow one device from discovery through approval to ordinary traffic. Once that path is visible, the deeper material can test replay protection, credential custody, fabric scope, and operational exceptions.

42.2 Matter Device Commissioning Evidence

Matter commissioning is the process that turns an untrusted, uncommissioned device into a fabric member that can be reached through operational Matter sessions. A reviewer should not treat “the device appeared in an app” as enough evidence. The commissioning record needs to show the setup scope, discovery path, PASE session, device attestation, network commissioning, operational credentials, ACLs, CASE readiness, and failure handling that support the final approval.

This chapter reviews commissioning as evidence. It explains what to prove, what not to overclaim, and how to write a bounded release decision for a Matter device onboarding path.

42.3 In 60 Seconds

• Matter commissioning starts with a setup payload and uncommissioned discovery, then uses PASE to protect the initial commissioning session.
• PASE uses the setup passcode for onboarding. It is not the same evidence as later CASE operational sessions.
• Device attestation evidence checks product identity and certification signals before the device is trusted into a fabric.
• Network commissioning evidence depends on the transport: Thread, Wi-Fi, and Ethernet do not require the same proof.
• Operational credentials make the device a fabric member with a node identity, fabric scope, and controller trust boundary.
• CASE readiness proves the device can be reached after commissioning through an operational secure session.
• Multi-admin review treats each additional administrator as a separate fabric-scoped onboarding claim.
• A strong approval states what was commissioned, by which commissioner, onto which fabric and network path, with which failures and retest triggers.

42.4 Learning Objectives

By the end of this chapter, you will be able to:

• Separate setup payload, discovery, PASE, device attestation, network commissioning, operational credentials, and CASE evidence.
• Explain why PASE success does not prove operational fabric readiness by itself.
• Review device attestation without turning it into a broad product-quality or network-health claim.
• Scope Thread, Wi-Fi, Ethernet, and multi-admin commissioning evidence correctly.
• Identify commissioning failures that should block release or trigger retest.
• Write bounded commissioning approval records for Matter devices and controllers.

42.5 Quick Check: Matter Commissioning

42.6 Prerequisites

This chapter assumes you have reviewed:

• Matter Overview, for Matter’s purpose and smart-home context.
• Matter Fragmentation Evidence, for the interoperability problem commissioning helps address.
• Matter Architecture Evidence, for nodes, fabrics, controllers, bridges, and endpoint boundaries.
• Matter Fabric Security Evidence, for fabric trust, operational credentials, PASE, CASE, and ACL boundaries.
• Matter Interaction Evidence, for secure session and interaction evidence after commissioning.
• Matter Device Types and Clusters Evidence, for endpoint and behavior approval after onboarding.

42.7 Commissioning Review Claim

Use a claim that can be tested against records:

Matter commissioning review claim: A Matter device is approved for commissioning only when the setup payload, discovery path, PASE session, attestation result, network onboarding, operational credential installation, ACL scope, CASE reachability, failure handling, and retest triggers all support the same device, commissioner, fabric, and transport claim.

The claim is deliberately narrow. Commissioning evidence proves onboarding into a fabric under reviewed conditions. It does not automatically prove every cluster, automation, controller UI, remote access feature, bridge behavior, or future firmware state.

42.8 Commissioning Evidence Flow

The first figure shows the review path from an uncommissioned device to an operational fabric member.

Figure 42.1: Matter commissioning evidence flow.

The flow separates temporary onboarding evidence from operational evidence. PASE protects the commissioning session. CASE proves the later operational session after credentials and fabric membership are in place.

42.9 Commissioning Sequence Trace

The commissioning sequence starts with setup evidence and ends with operational Matter evidence. Treat each step as a separate checkpoint, because skipping one can make a device appear onboarded before it is a fabric member that can operate through CASE.

Figure 42.2: Matter commissioning sequence from setup code through PASE, credentials, network join, and ACL evidence.

Discover. A fresh device advertises through the expected uncommissioned path, commonly BLE for first-use onboarding, and the commissioner matches it using setup-payload evidence such as the discriminator.

Establish PASE. The commissioner and device use the setup passcode in a password-authenticated key exchange to protect the temporary commissioning channel without sending the passcode itself.

Verify attestation. The commissioner checks device identity and certification evidence before trusting the device with operational credentials.

Install credentials. The commissioner installs operational fabric credentials such as the Node Operational Certificate, giving the device an identity in the reviewed fabric.

Provision the network. The device receives the reviewed Thread operational dataset or Wi-Fi credentials, with secrets redacted from learner-facing evidence.

Verify operation. The device joins the IP network, completes commissioning, and proves operational discovery, CASE reachability, ACL scope, and the first approved interaction.

42.10 Evidence Families

Commissioning review combines several evidence families.

Setup payload Record the QR code or manual-code source, discriminator, passcode handling, vendor and product identity, and expected commissioning flow. Redact secrets from published records.

Uncommissioned discovery Record whether the device was found through the expected discovery path, such as BLE or local service discovery, and whether stale advertisements were excluded.

PASE session Record that the setup passcode established the temporary encrypted commissioning session and that wrong or stale setup paths fail safely.

Device attestation Record attestation chain, certification declaration, nonce-bound response, verification result, and policy for failed or unknown attestation.

Network commissioning Record Thread, Wi-Fi, or Ethernet reachability evidence without exposing operational datasets, passwords, or other secrets.

Fabric credentials Record trusted root, node identity, fabric index, operational certificate installation, ACL scope, commissioning-complete status, and CASE readiness.

42.11 Interactive Commissioning Flow

42.12 What Commissioning Proves

Successful commissioning can prove that a commissioner could securely onboard a specific device into a specific fabric under reviewed conditions. It can also prove that the selected network path and operational credentials allowed the device to move from temporary onboarding to normal Matter operation.

The approval can include:

• The setup payload was accepted only through the intended commissioning flow.
• The commissioner established a PASE session with the expected device.
• Device attestation was verified or handled according to an explicit release policy.
• Network commissioning completed for the reviewed transport.
• Operational credentials were installed for the reviewed fabric.
• The commissioned device was reachable through CASE after commissioning completed.
• ACLs and controller scope matched the approved use.
• Failure paths were captured with retest triggers.

42.13 What Commissioning Does Not Prove Alone

Commissioning is necessary, but it is not the whole product review.

• It does not prove every device type, cluster, attribute, command, event, scene, or automation.
• It does not prove every controller will show the same UI or expose the same optional feature.
• It does not prove remote access, cloud services, account linking, notifications, or firmware update behavior.
• It does not prove all future multi-admin fabrics will have the same permissions or user experience.
• It does not prove bridge child endpoints unless the bridge mapping and child endpoint behavior were reviewed.
• It does not prove network resilience beyond the Thread, Wi-Fi, Ethernet, border-router, or local-routing conditions tested.

42.14 Setup Payload and Discovery Evidence

The setup payload is the first boundary in the commissioning record. It tells the commissioner how to find the device and establish the first secure onboarding session. A review should record the source of the setup payload and whether the device being discovered matches the expected identity and commissioning state.

Good setup evidence answers:

• Was the setup payload from the correct device, batch, packaging, label, or test fixture?
• Was the discriminator used to identify the intended commissionee rather than a nearby stale device?
• Was the passcode handled as a secret and excluded from public screenshots or logs?
• Was the device in an open commissioning window at the time of discovery?
• Was the discovered transport path expected for this product state?

Discovery evidence should avoid a common mistake: treating a visible device advertisement as proof that onboarding succeeded. Discovery only starts the review.

42.15 PASE Session Evidence

PASE protects the initial commissioning session using the setup passcode. It is temporary onboarding evidence, not operational fabric evidence.

For PASE, record:

Correct session The commissioner established PASE with the intended device and commissioning window, not a stale or nearby device.

Safe rejection Wrong passcodes, expired windows, repeated attempts, or mismatched discriminators fail without installing credentials.

Transition point The review records when the device moved from temporary PASE commissioning to operational credential installation.

PASE success should be followed by attestation, network commissioning when needed, operational credential installation, and CASE verification. If that transition is not recorded, the approval is incomplete.

42.16 PASE Passcode Proof

PASE uses SPAKE2+, a password-authenticated key exchange, so the commissioner and device can prove knowledge of the setup passcode without transmitting the passcode over the air. Capturing the exchange should not reveal the passcode. A useful review record therefore distinguishes “PASE established with the intended device” from weaker evidence such as “a passcode appeared in a UI.”

PASE also has strict scope. It protects temporary onboarding before operational credentials exist. It does not prove the device has joined the intended network, received a Node Operational Certificate, entered the intended fabric, or become reachable through CASE. Those later transitions need separate evidence.

42.17 Device Attestation Evidence

Device attestation helps the commissioner decide whether the device has acceptable product identity and certification evidence before operational trust is granted. The review should record the attestation result and the policy used to handle exceptions.

Attestation evidence normally includes:

• Device attestation certificate chain evidence.
• Certification declaration evidence.
• A nonce-bound attestation response, so the record is tied to the reviewed session.
• Verification result against the accepted attestation trust policy.
• Release decision for failed, missing, unknown, or development attestation material.

Do not inflate attestation into a claim it cannot support. Attestation does not prove radio quality, power behavior, controller UI quality, bridge mapping, cluster conformance, or long-term operational reliability. It supports the device identity and certification portion of the commissioning decision.

42.18 Attestation Trust Chain

The step that separates Matter onboarding from simple password pairing is device attestation. Before installing operational credentials, the commissioner verifies the Device Attestation Certificate, usually abbreviated DAC, and checks that it chains through a Product Attestation Intermediate, or PAI, to an accepted root. A valid chain supports the claim that the device is a genuine certified Matter product from the expected manufacturer, not only a device that displayed a plausible setup code.

This matters because the setup code is not a high-value long-term secret. It may be printed on a label or packaging, so it can be photographed or copied. Attestation adds a device-held authenticity proof that a fake device should not be able to forge. Only after attestation passes or an explicit exception policy accepts the case should the commissioner install the NOC and provide network credentials.

42.19 PASE and CASE Boundary Check

42.20 Network Commissioning Evidence

Network commissioning evidence depends on the transport and device state. The reviewer should state what path was actually used.

For Thread devices, the record should show that the device received the intended Thread network information, joined the expected local mesh, and became reachable through the expected border-router path. Sensitive operational datasets should be redacted.

For Wi-Fi devices, the record should show that credentials were provided securely, the device joined the expected local network, and local reachability matched the commissioning claim. Passwords and account-specific identifiers should not appear in published evidence.

For Ethernet devices, the record may not include wireless credential transfer, but it still needs local IP reachability, operational discovery, fabric membership, and CASE evidence.

Do not approve a general “network works” claim unless the transport, local path, border-router or access-network dependency, and failure state were all reviewed.

42.21 Operational Credentials and Fabric Evidence

Operational credentials are the point where the device becomes a Matter fabric member. The review should tie credentials to the device, commissioner, fabric, and operational identity being approved.

Record:

• Which commissioner installed credentials.
• Which trusted root and fabric scope were used.
• Which operational node identity and fabric index were assigned.
• Whether commissioning completed cleanly.
• Which ACL entries or privileges were applied for the approved controller role.
• Whether operational discovery and CASE succeeded after commissioning.
• Which fabric removal, factory reset, or credential replacement events require retest.

Credentials are fabric-scoped. Evidence from one fabric should not be reused as proof for another administrator, controller, or fabric unless that second scope was reviewed.

42.22 CASE and First Operational Checks

After commissioning completes, the reviewer should prove that the device can operate outside the temporary commissioning channel. This is where CASE and first operational interactions matter.

The first operational check should include:

Operational discovery. Confirm that the commissioned node can be found through the expected local operational path.

CASE establishment. Confirm that the controller can establish an operational secure session using fabric credentials.

Basic interaction. Read descriptor or basic information evidence to verify node and endpoint identity.

Claim-specific behavior. Test only the endpoint, cluster, command, attribute, or subscription behavior needed for the commissioning claim.

The first operational check does not need to become a full conformance campaign. It should be just enough to prove that commissioning completed into operational Matter behavior.

42.23 Multi-Admin Commissioning Evidence

Multi-admin commissioning lets a commissioned device be shared with another administrator through an additional fabric. A review should treat that as a second commissioning claim, not as an automatic consequence of the first one.

Multi-admin evidence should answer:

• Who opened the commissioning window and under what authority?
• Which second commissioner used the window?
• Which fabric was added, and how was it kept separate from the first fabric?
• Which ACLs and privileges apply on each fabric?
• Which endpoint and interaction evidence was checked from each administrator?
• What happens when one fabric is removed, rotated, or no longer authorized?

The safest wording is specific: “The reviewed device joined the second fabric and completed the approved operational checks for the named controller.” Avoid saying that the device now works the same way for every ecosystem.

42.24 Commissioning Failure Handling

Commissioning failures are evidence, not noise. A release review should preserve enough failure detail to decide whether the issue blocks approval, requires retest, or stays outside the approved scope.

Important failure categories include:

Setup failure Wrong code, expired window, stale discriminator, duplicate nearby device, or unsupported commissioning flow.

PASE failure Session establishment fails, retry behavior is unsafe, or the device accepts a path that should be rejected.

Attestation failure Certificate chain, certification declaration, nonce-bound response, or release policy does not support trust.

Network failure Thread join, Wi-Fi join, local IP reachability, border-router dependency, or operational discovery fails.

Credential failure Operational credential installation, trusted root handling, commissioning complete, or fabric table behavior fails.

Operational failure CASE, ACL, endpoint identity, first read, first command, or subscription evidence fails after commissioning.

A failed commissioning path should not be hidden by a later factory reset and retry unless the record explains the cause, fix, and retest trigger.

42.25 Worked Review Records

42.25.1 Record 1: Thread Sensor Onboarding

Scenario: A battery sensor is commissioned onto a Thread network through a mobile commissioner.

Evidence found: The setup payload matched the expected device, PASE succeeded during the open window, attestation passed the release policy, Thread network information was delivered with secrets redacted from the review record, operational credentials were installed, CASE succeeded, and the descriptor endpoint read matched the approved sensor endpoint.

Decision: Approve commissioning for the reviewed sensor, commissioner, fabric, Thread path, and first operational read. Keep battery-life, full sensor accuracy, remote access, and other controllers outside the commissioning approval.

42.25.2 Record 2: Attestation Hold

Scenario: A development plug can complete PASE and network commissioning, but device attestation does not match the release policy.

Evidence found: PASE, Wi-Fi join, and operational credential installation were repeatable in a lab build, but the attestation record was marked development-only and not acceptable for production release.

Decision: Hold production commissioning approval. Accept the lab path only for internal testing with a clear retest trigger when production attestation material is provisioned.

42.25.3 Record 3: Multi-Admin Handoff

Scenario: A commissioned lighting device is shared with a second administrator for household control.

Evidence found: The first administrator opened a commissioning window, the second commissioner added a separate fabric, operational discovery and CASE succeeded on both fabrics, and each administrator performed the approved on/off interaction within its ACL scope.

Decision: Approve multi-admin commissioning for the reviewed device, two fabrics, two controllers, and on/off interaction. Retest after ACL changes, fabric removal, controller replacement, or firmware changes affecting commissioning.

42.26 Common Mistakes

• Treating QR-code scanning or device discovery as proof of completed commissioning.
• Treating PASE success as proof of CASE readiness.
• Ignoring device attestation failures because later network steps appear to work.
• Publishing setup passcodes, network credentials, operational datasets, or other commissioning secrets in review evidence.
• Reusing one fabric’s operational evidence as proof for another fabric or administrator.
• Treating a Thread border router, Wi-Fi access point, or Ethernet link as proof of Matter fabric membership.
• Approving every endpoint or cluster after only a basic commissioning check.
• Hiding failed attempts instead of recording cause, fix, and retest trigger.

42.27 Match the Commissioning Evidence

42.28 Order the Commissioning Review

42.29 Commissioning Review Record

The second figure shows the minimum review record needed before accepting a commissioning claim.

Figure 42.3: Matter commissioning review record.

Use this record when a team asks whether a device is ready for release, certification preparation, pilot deployment, or multi-admin sharing. The record keeps onboarding evidence, operational evidence, and open limitations visible.

42.30 Release Checklist

Use this checklist before accepting a Matter commissioning claim.

Device scope The reviewed device, firmware, setup payload, commissioning window, and commissioner are identified.

Session scope PASE succeeded for the intended device, and unsafe setup paths failed without installing credentials.

Trust scope Device attestation evidence and exception policy support the release decision.

Network scope Thread, Wi-Fi, or Ethernet evidence matches the claimed transport and redacts sensitive material.

Fabric scope Operational credentials, fabric identity, ACLs, commissioning-complete state, and CASE reachability are recorded.

Retest scope Firmware, attestation material, network credentials, fabric changes, ACL changes, controller changes, and factory reset behavior have retest triggers.

42.31 Release Decision Check

42.32 Summary

Matter commissioning is a trust transition. The device begins as an uncommissioned node discovered through a setup path, establishes PASE for onboarding, passes or fails attestation policy, joins the intended network path, receives operational credentials, and then proves CASE-based operational reachability on a fabric.

The review discipline is separation. Keep setup payload, PASE, attestation, network commissioning, operational credentials, ACLs, CASE, multi-admin, and failure handling distinct. Then approve only the device, commissioner, fabric, transport, and first operational behaviors that the evidence supports.

42.33 Key Takeaway

Matter Device Commissioning Evidence should prove commissioning through identity, fabric membership, credential exchange, network setup, recovery paths, and deployment evidence.

42.34 Concept Relationships

• Matter Fabric Security Evidence explains the fabric, PASE, CASE, operational credential, and ACL boundaries behind commissioning.
• Matter Interaction Evidence shows how post-commissioning reads, writes, subscribes, invokes, and timed interactions are reviewed.
• Matter Device Types and Clusters Evidence explains how endpoint behavior is approved after a device has joined a fabric.
• Matter Fragmentation Evidence explains why secure commissioning and multi-admin matter for ecosystem interoperability.

42.35 What’s Next

Next, Matter SDK and Development Environment Evidence reviews how implementation environment evidence should be scoped before building or modifying a Matter device. Later, Matter Implementation Evidence connects commissioning readiness to firmware, endpoint behavior, and release discipline.