AdministratorCommissioning Cluster
Cluster ID: 0x003C |
Endpoint: Fixed on Endpoint 0 (Root Endpoint)
AdministratorCommissioning controls the opening and closing of the device's Commissioning Window. When a device has already joined a Fabric (been commissioned), and you want new administrators to also commission this device, you need to open a commissioning window through this Cluster. It does not handle the commissioning flow itself (that is GeneralCommissioning's job), but rather controls the "whether the device accepts new commissioning requests" switch.
If the device is like a building, AdministratorCommissioning is the access control system at the entrance. The building owner (existing administrator) can choose to temporarily open access, allowing new residents (new administrators) to complete move-in procedures (commissioning). OpenCommissioningWindow is changing to a new lock code before opening the door (more secure), OpenBasicCommissioningWindow is opening the door with the existing code (more convenient), RevokeCommissioning is closing the door at any time.
Feature Map
| Bit | Code | Name | Description |
|---|---|---|---|
0 |
BC | Basic Commissioning | Supports basic commissioning method — the OpenBasicCommissioningWindow command. If the device does not support this Feature, only the enhanced commissioning method can open a window |
Commands
The AdministratorCommissioning Cluster has 3 commands for opening an enhanced commissioning window, opening a basic commissioning window, and closing a commissioning window. None of these commands have dedicated response structures; they return results through the standard Status response. Click a command ID in the table below to jump to its detailed description.
| ID | Name | Feature | Description |
|---|---|---|---|
0x00 |
OpenCommissioningWindow | -- | Open enhanced commissioning window with a new PAKE verifier |
0x01 |
OpenBasicCommissioningWindow | BC | Open basic commissioning window using existing passcode |
0x02 |
RevokeCommissioning | -- | Close the currently open commissioning window |
OpenCommissioningWindow — Enhanced Commissioning Window (0x00)
Opens an Enhanced Commissioning Window. The caller must provide a brand-new PAKE verifier, and the new Commissioner will use this verifier instead of the device's factory passcode to establish a PASE secure channel. This is the most secure window-opening method — each window uses a one-time password, so even if intercepted, it cannot be used for the next commissioning.
| Parameter | Type | Description |
|---|---|---|
| CommissioningTimeout | uint16 | Number of seconds the window stays open. Automatically closes after timeout. Range is typically 60 ~ 900 seconds |
| PAKEPasscodeVerifier | octstr | New PAKE password verifier. Generated by the Commissioner based on a new passcode |
| Discriminator | uint16 | 12-bit device discriminator, used by the new Commissioner to identify the target device during discovery |
| Iterations | uint32 | PBKDF2 iteration count, range 1000 ~ 100000 |
| Salt | octstr | PBKDF2 salt, length 16 ~ 32 bytes |
Enhanced commissioning generates a new PAKE verifier each time a window is opened, completely invalidating the old password. This means even if someone sniffs the PASE handshake data during this commissioning session, it cannot be used to crack the next one. In contrast, OpenBasicCommissioningWindow uses the device's factory passcode (usually printed on the device label), which is less secure but more convenient. Enhanced commissioning is recommended for production environments.
Usage Scenarios & Notes
Typical scenario: A user has commissioned a device on App A and now wants App B to also control this device. App A calls OpenCommissioningWindow to open a window, providing a temporary commissioning password (displayed to the user as a QR Code or numeric code). The user scans the QR Code or enters the numeric code in App B to complete secondary commissioning. The window closes automatically after timeout.
Note: If the device already has an active commissioning window (WindowStatus is not 0), calling again returns a Busy (2) error. You need to first call RevokeCommissioning to close the existing window, or wait for it to timeout.
OpenBasicCommissioningWindow — Basic Commissioning Window (0x01)
Opens a Basic Commissioning Window. Unlike the enhanced method, basic commissioning uses the device's factory passcode (the pairing code printed on the device label) to establish a PASE secure channel. Simpler to operate, but less secure.
This command requires the device to support the BC (Basic Commissioning) Feature. You can confirm device support by reading the Feature Map. Devices that do not support this Feature can only open windows through OpenCommissioningWindow (enhanced method).
| Parameter | Type | Description |
|---|---|---|
| CommissioningTimeout | uint16 | Number of seconds the window stays open. Automatically closes after timeout |
Usage Scenarios & Notes
Suitable for quickly adding a second controller in a home environment. For example, a user has commissioned a light bulb with Google Home and now wants Apple Home to also control it. After opening a basic commissioning window in the Google Home App, simply use the pairing code on the back of the bulb to commission in Apple Home.
Since it uses a fixed factory passcode, it is not recommended for high-security scenarios. The factory password may be used multiple times, and if obtained by a third party, there is a risk of unauthorized commissioning.
RevokeCommissioning — Close Commissioning Window(0x02)
Closes the currently open commissioning window. This command has no parameters.
After a successful call, the device immediately stops accepting new commissioning requests, WindowStatus returns to WindowNotOpen (0),
and AdminFabricIndex and AdminVendorId reset to null.
Can only be called when a commissioning window is already open. If there is no active commissioning window (WindowStatus = 0), a WindowNotOpen (4) error is returned.
Usage Scenarios & Notes
Main use: An administrator opened a commissioning window but changed their mind, or discovered a security concern requiring immediate window closure. For example, in a commercial environment, an IT admin opens a window for a new colleague to commission, but the colleague is temporarily unavailable; the admin can proactively close the window to prevent unauthorized access.
Automated systems can also call this command as a security response when detecting abnormal commissioning attempts.
Attributes
The AdministratorCommissioning Cluster has 3 attributes describing the current commissioning window state and operator information.
| ID | Name | Type | Description |
|---|---|---|---|
0x0000 |
WindowStatus | CommissioningWindowStatusEnum | Current commissioning window status |
0x0001 |
AdminFabricIndex | fabric-idx (nullable) | Fabric index of the administrator who opened the window |
0x0002 |
AdminVendorId | vendor-id (nullable) | Vendor ID of the administrator who opened the window |
Window Status (0x0000)
| ID | Name | Type | Description |
|---|---|---|---|
0x0000 |
WindowStatus Window Status |
CommissioningWindowStatusEnum |
Indicates the device's current commissioning window status.
WindowNotOpen (0) means no window is open, the device does not accept new commissioning requests;
EnhancedWindowOpen (1) means the enhanced commissioning window is open;
BasicWindowOpen (2) means the basic commissioning window is open.
Only one window can be open at a time
|
In security-sensitive deployment environments, you can subscribe to WindowStatus attribute changes to monitor the device's commissioning window state in real time.
Once an unexpected window opening is detected (e.g., BasicWindowOpen),
you can immediately call RevokeCommissioning to close the window and send an alert.
Administrator Info (0x0001, 0x0002)
Records who opened the current commissioning window. Both attributes are null when the window is closed or not opened.
| ID | Name | Type | Description |
|---|---|---|---|
0x0001 |
AdminFabricIndex Admin Fabric Index |
fabric-idx (nullable) |
Fabric index of the administrator who opened the commissioning window.
Can be used to trace which Fabric's administrator performed the window-opening operation.
null when no window is open
|
0x0002 |
AdminVendorId Admin Vendor ID |
vendor-id (nullable) |
Vendor ID of the administrator who opened the commissioning window.
Identifies which manufacturer's App or controller performed the window-opening operation.
null when no window is open
|
AdminFabricIndex and AdminVendorId used together provide a complete audit trail of "who" under "what identity" opened the commissioning window. This is highly valuable for security audits — for example, in an enterprise environment, when a device is unexpectedly commissioned, these two attributes can confirm which administrator and which platform performed the window-opening operation.
Enum Definitions
CommissioningWindowStatusEnum
Indicates the device's current commissioning window status, used for the WindowStatus attribute.
Cluster Status Codes (StatusCode)
AdministratorCommissioning commands return results through the standard Status response. In addition to standard status codes, the following Cluster-specific status codes are defined:
OpenCommissioningWindow returns Busy → A commissioning window is already open, call RevokeCommissioning to close it first then retry; OpenCommissioningWindow returns PAKEParameterError → Check the PAKE verifier generation parameters, confirm Iterations and Salt are within valid ranges; RevokeCommissioning returns WindowNotOpen → Window has already timed out and auto-closed, or was never opened; no action needed.
Example Data
Attribute Data Example (Window Not Open)
Device in normal state with no active commissioning window:
{
// --- Commissioning Window Status ---
"0x0000": 0, // WindowStatus = WindowNotOpen (no commissioning window open)
// --- Administrator Info ---
"0x0001": null, // AdminFabricIndex = null (no administrator opened window)
"0x0002": null // AdminVendorId = null (no administrator opened window)
}
Attribute Data Example (Window Open)
An administrator has opened a commissioning window using the enhanced method:
{
// --- Commissioning Window Status ---
"0x0000": 1, // WindowStatus = EnhancedWindowOpen (enhanced commissioning window open)
// --- Administrator Info ---
"0x0001": 1, // AdminFabricIndex = 1 (administrator from Fabric index 1 opened the window)
"0x0002": 4996 // AdminVendorId = 0x1384(Vendor ID of the administrator who opened the window)
}
OpenCommissioningWindow Interaction Example
Opening a commissioning window using the enhanced method:
// Commissioner → Device: Open enhanced commissioning window
{
"invokeRequests": [{
"commandPath": {
"endpointId": 0,
"clusterId": "0x003C",
"commandId": "0x00" // OpenCommissioningWindow
},
"commandFields": {
"commissioningTimeout": 180, // Auto-close after 180 seconds
"PAKEPasscodeVerifier": "base64...", // New PAKE verifier
"discriminator": 3840, // 12-bit device discriminator
"iterations": 1000, // PBKDF2 iteration count
"salt": "base64..." // PBKDF2 salt
}
}]
}
// Device → Commissioner: Successfully opened (Status = SUCCESS)
// This command has no dedicated response structure; results are returned via standard Status
OpenBasicCommissioningWindow Interaction Example
Opening a commissioning window using the basic method (requires BC Feature):
// Commissioner → Device: Open basic commissioning window
{
"invokeRequests": [{
"commandPath": {
"endpointId": 0,
"clusterId": "0x003C",
"commandId": "0x01" // OpenBasicCommissioningWindow
},
"commandFields": {
"commissioningTimeout": 180 // Auto-close after 180 seconds
}
}]
}
// Device → Commissioner: Successfully opened (Status = SUCCESS)
RevokeCommissioning Interaction Example
Close the currently open commissioning window:
// Commissioner → Device: Close commissioning window
{
"invokeRequests": [{
"commandPath": {
"endpointId": 0,
"clusterId": "0x003C",
"commandId": "0x02" // RevokeCommissioning
},
"commandFields": {} // No parameters
}]
}
// Device → Commissioner: Successfully closed (Status = SUCCESS)
In practice, Commissioner SDKs typically wrap the OpenCommissioningWindow call and automatically handle PAKE verifier generation. App developers usually only need to call the SDK's "multi-admin commissioning" interface, and the SDK handles PAKE parameter calculation and command sending at a lower level. However, understanding the underlying principles helps troubleshoot multi-admin commissioning failures.
Common Scenarios
Scenario 1: Adding a Second Administrator (Multi-Platform Co-Management)
Background: A user has commissioned a smart light with Google Home and now wants Apple Home to also control it.
- User finds the light's device detail page in the Google Home App
- Click "Share Device" or "Add to Other Platform"
- Google Home calls
OpenCommissioningWindow (0x00)under the hood, generating a new PAKE verifier and temporary Discriminator - The App displays a commissioning QR Code (containing the temporary password and Discriminator)
- User opens Apple Home and scans the QR Code
- Apple Home uses the temporary password to establish a PASE channel and complete commissioning
- After commissioning completes, the window automatically closes, WindowStatus returns to
WindowNotOpen (0)
At this point, the device belongs to two Fabrics (Google and Apple) simultaneously and can be independently controlled by both platforms.
The device's AdminFabricIndex and AdminVendorId return to null after the window closes.
Scenario 2: Alternative to Factory Reset
Background: The device's App has been uninstalled or Fabric info is lost, but you don't want to factory reset (which would lose all configuration).
- If the device supports BC Feature and has a physical button or other local trigger:
- Trigger local window opening by long-pressing the device button (some devices support this)
- Device enters basic commissioning window state (BasicWindowOpen)
- If the device still belongs to a valid Fabric and has another administrator:
- Use that administrator to call
OpenBasicCommissioningWindow (0x01) - Use the factory passcode on the back of the device to re-commission
- Use that administrator to call
- After the new Commissioner completes commissioning, the device joins the new Fabric
- Old, no-longer-needed Fabrics can be removed via the OperationalCredentials Cluster
Note: If administrators of all the device's Fabrics are inaccessible and the device does not support local window opening, then factory reset may be the only option. This is why configuring at least two administrators (Fabrics) as backup is recommended.
Scenario 3: Security Audit (Detecting Abnormal Commissioning Windows)
Background: An enterprise IoT administrator needs to ensure that Matter devices in the office have not been unexpectedly opened for commissioning.
- Periodically poll all devices'
WindowStatus (0x0000)attribute - If a device's WindowStatus is not
WindowNotOpen (0):- Read
AdminFabricIndex (0x0001)to confirm which Fabric's administrator opened the window - Read
AdminVendorId (0x0002)to confirm which platform was used
- Read
- If this window opening is not in the expected operation log:
- Immediately call
RevokeCommissioning (0x02)to close the window - Record audit log: device ID, window opening time, AdminFabricIndex, AdminVendorId
- Send an alert to the security team
- Immediately call
- Better approach: Subscribe to WindowStatus attribute changes for real-time detection instead of polling
In high-security environments, it is recommended to completely disable the BC Feature (no basic commissioning support), allowing only the enhanced commissioning method to open windows — this way each window opening requires a new PAKE verifier, reducing the risk of malicious exploitation.