The Matter protocol was designed around a simple promise: any certified device should work with any certified controller, regardless of brand. That promise rests on a shared library of standardized clusters — well-defined collections of attributes, commands, and events that describe how a light, lock, thermostat, or sensor behaves. But real-world products rarely fit neatly into generic templates. Manufacturers need room to innovate, differentiate, and expose features that no standard cluster anticipates. This is exactly the problem that Matter custom clusters — also called manufacturer-specific or proprietary clusters — were built to solve.

Custom clusters are the sanctioned escape hatch inside the Matter specification. They let vendors extend the protocol with proprietary capabilities while still shipping a fully certified, interoperable product. Done well, they give buyers the best of both worlds: baseline compatibility across ecosystems, plus access to the unique features that justified the purchase in the first place. Done poorly, they fragment the experience and quietly reintroduce the walled gardens Matter was meant to eliminate.

This guide explains how manufacturer extensibility actually works under the hood, where compatibility breaks down, what the security model looks like, and which categories of devices benefit most from custom clusters. If you are evaluating a Matter device and the spec sheet mentions "proprietary features" or "advanced capabilities available in the manufacturer app," this article will tell you exactly what that means for your smart home.

Protocol Overview: Where Custom Clusters Fit in Matter

Matter organizes device functionality into a hierarchy. A device type (for example, a Dimmable Light or a Door Lock) is composed of one or more clusters. Each cluster exposes a contract: a set of attributes you can read or write, commands you can invoke, and events the device can emit. The On/Off cluster, Level Control cluster, Color Control cluster, and Thermostat cluster are all standard clusters defined by the Connectivity Standards Alliance (CSA) and shared across every Matter implementation.

Custom clusters occupy a reserved region of the cluster ID space. The Matter specification allocates cluster IDs from 0xFC00 through 0xFFFE specifically for manufacturer-specific use. Any cluster ID in that range signals to a controller: "this functionality is proprietary — interpret it only if you know the vendor's schema." The vendor ID embedded in every Matter device (the 16-bit VendorID assigned by the CSA) is what ties a custom cluster back to its owner, preventing two different companies from accidentally reusing the same proprietary ID.

This design choice is deliberate. By reserving a dedicated ID range and binding it to a registered vendor, Matter allows extensibility without risking collisions in the global namespace. A controller that does not recognize a custom cluster is required to ignore it gracefully rather than fail — which is the single most important rule that keeps interoperability intact.

How Matter Custom Clusters Work Under the Hood

Structurally, a custom cluster is identical to a standard cluster. It is defined using the same Matter data model, described in the same Matter XML or ZAP schema format, and compiled into the device's endpoint table through the same code-generation pipeline. It has attributes with data types, commands with argument lists, events with priority levels, and access control entries that determine which fabric roles can read, write, or invoke them.

The differentiation happens at three layers:

  • Identification. The cluster ID lives in the 0xFC00–0xFFFE range and is paired with the manufacturer's CSA-assigned VendorID. A controller must check both before deciding it understands the cluster.
  • Discovery. Custom clusters appear in the standard cluster list returned by the Descriptor cluster on each endpoint. A generic controller sees them, notes their IDs, and typically hides them from the user because it has no UI to represent them.
  • Interpretation. Only the manufacturer's own app — or a third-party controller that has been given the proprietary schema — knows what each attribute means, which command arguments are valid, and what events signify.

A practical example helps. A Matter smart bulb might expose the standard On/Off, Level Control, and Color Control clusters so that Apple Home, Google Home, Amazon Alexa, and Samsung SmartThings can all turn it on, dim it, and change its color. The same bulb might also expose a custom cluster at 0xFC01 that controls a "circadian rhythm" mode, a "scene sync" feature tied to the vendor's hub, or a firmware-defined animation engine. The generic controllers ignore 0xFC01 and the bulb still works perfectly as a color light. Open the vendor's app, and suddenly those extra features become available.

Manufacturers typically distribute the schema for their custom clusters in one of three ways: bundled inside their own mobile app, published to developer portals for third-party integrators, or kept entirely private. This decision — more than any technical detail — determines how open or closed the proprietary feature set really is.

The Role of the Device Type Library

Device types in Matter are composable. A single endpoint can carry both a standard device type (say, 0x0102 for a Dimmable Light) and additional custom device types, each backed by its own cluster set. The CSA has steadily expanded the official device type library — covering everything from robot vacuums to solar inverters — which reduces the pressure on vendors to invent custom clusters for common functionality. When a feature is standardized, using a custom cluster for it becomes an anti-pattern, because it sacrifices interoperability for no real gain.

Compatibility and Interoperability Considerations

The most common question homeowners ask about custom clusters is whether they "break" Matter. The honest answer is that they do not break the baseline experience, but they do create a two-tier experience. The standard cluster surface area works everywhere. The custom cluster surface area works only where the schema is understood.

This creates a predictable compatibility matrix:

The matrix makes one thing clear: if a feature matters to your daily use — say, a specific lighting rhythm, a proprietary sensor algorithm, or a custom lock gesture — you should assume it will require the manufacturer's app. Generic controllers will not expose it, even though they can still control everything else about the device.

Multi-Admin and Fabric Behavior

Matter's multi-admin model lets a device be commissioned to several fabrics simultaneously — for example, an Apple Home fabric, a Google Home fabric, and the vendor's own fabric. Custom clusters are accessible on every fabric where the controller understands them. In practice, this means the vendor's app can expose proprietary features while Apple Home exposes only standard features, both talking to the same physical device over the same Thread or Wi-Fi link. There is no conflict, because access control entries on each attribute determine which fabric role can invoke what.

The Risk of Feature Gating

The darker side of manufacturer extensibility is feature gating. Some vendors ship devices where core functionality — functionality that arguably should be standardized — is hidden behind a custom cluster and available only through the vendor's app or cloud service. This is technically compliant with Matter but philosophically at odds with it. Buyers should watch for products where the marketing materials emphasize proprietary features heavily; those features are almost certainly custom-cluster-bound and will not follow the device into a new ecosystem if you switch platforms later.

Performance Implications of Custom Clusters

Custom clusters do not carry an inherent performance penalty. They travel over the same encrypted Matter protocol messages, use the same TLV (Tag-Length-Value) encoding, and ride the same transport — whether that is Thread, Wi-Fi, or Ethernet. A read of a custom attribute costs exactly as much as a read of a standard attribute with the same data type.

Where performance can diverge is in how vendors implement the features behind those clusters. Three patterns are worth watching:

  • Local vs. cloud-routed logic. A custom cluster that triggers on-device processing (for example, a local AI model for occupancy detection) responds in milliseconds. A custom cluster whose command is forwarded to the vendor's cloud and then back to the device adds round-trip latency and a dependency on internet connectivity.
  • Attribute subscription load. Some proprietary features emit high-frequency events — think of an air quality sensor reporting particulate levels every second. Standard Matter subscriptions handle this fine on Wi-Fi and Ethernet, but on Thread networks with limited bandwidth, aggressive subscription intervals can crowd out other traffic. Well-designed vendors throttle event rates or use the Matter event priority system to keep critical events ahead of telemetry noise.
  • Firmware size and memory. Custom clusters add code to the device's firmware image. On constrained Thread end-devices with tight flash budgets, a bloated proprietary feature set can mean less room for the core Matter stack, potentially affecting certification stability or update headroom.

For the homeowner, the practical takeaway is that custom-cluster features should feel as responsive as standard features when the vendor has done the work locally. If a proprietary feature feels sluggish or requires an internet connection to function, that is an implementation choice, not a protocol limitation.

Security Model for Custom Clusters

One of the strongest guarantees of Matter is that custom clusters inherit the same security model as standard clusters. There is no separate, weaker channel for proprietary features. Every custom attribute and command is subject to the same access control list (ACL) system, the same encrypted CASE sessions, and the same certificate-based authentication that protects the rest of the device.

Concretely, this means:

  • Encryption is mandatory. Custom cluster traffic is encrypted end-to-end between the controller and the device using the same operational certificates as standard traffic. A vendor cannot legally ship a Matter-certified device that exposes proprietary features over a plaintext side channel.
  • Access control applies per attribute. A manufacturer can mark certain custom attributes as readable by any admin, writable only by the vendor's own fabric, or invoke-only with a specific privilege level (View, Operate, Manage, or Administer). This granularity lets vendors protect sensitive proprietary controls — say, a calibration routine for a sensor — from being triggered accidentally by a generic controller.
  • OTA updates are signed. Firmware that modifies custom cluster behavior must still pass through Matter's signed OTA update process. A vendor cannot silently push proprietary code to a device without the cryptographic signature that the device's root of trust validates.

Where Security Gaps Still Appear

The protocol-level security is strong, but two real-world gaps persist. First, some vendors pair their custom clusters with companion cloud services that have their own, separate security posture. The Matter link between phone and device may be airtight, but the cloud account that unlocks advanced features may rely on weaker authentication. Second, the schema for a custom cluster — what each attribute actually does — is a form of security through obscurity when kept private. Researchers and integrators cannot audit what they cannot see, which means vulnerabilities in proprietary features sometimes go unnoticed longer than they would in standardized code paths.

For security-conscious deployments, the recommendation is to treat custom-cluster features as you would any vendor-specific cloud integration: enable them when they add clear value, but do not assume they have been audited to the same degree as the core Matter stack.

Best Devices Leveraging Manufacturer Extensibility

Not every device category benefits equally from custom clusters. The categories where extensibility adds genuine value — without undermining the interoperability promise — tend to share a few traits: they have rich, differentiated hardware; their standard device types are still maturing in the CSA library; or their value proposition is inherently algorithmic rather than mechanical.

Smart Lighting with Advanced Effects

Standard Matter clusters handle on/off, dimming, color temperature, and full hue/saturation color. They do not yet fully capture dynamic scene engines, music-reactive modes, or multi-segment addressable strips. Lighting vendors use custom clusters to expose these effects while keeping basic control universal. A Matter smart light with custom clusters can be dimmed from any platform but still offer its signature animated scenes through the vendor app.

Robot Vacuums and Floor Care

The Matter robot vacuum device type is relatively recent in the specification, and it covers core commands like start, stop, pause, and return to dock. Room-specific cleaning, no-go zones, mop-lift behaviors, and AI-based obstacle avoidance are almost universally exposed through custom clusters. This is a case where extensibility is genuinely necessary — the standard simply cannot encode the full complexity of a modern robot vacuum without ballooning into an unmanageable specification.

Air Quality and Environmental Sensors

Sensors are a natural fit for custom clusters because the interesting value often lies in proprietary calibration, sensor fusion, or trend analysis. A Matter air quality sensor might expose standard PM2.5 and VOC readings through official clusters while offering a custom cluster for a vendor-trained "overall air quality index" that combines multiple inputs. Homeowners get the raw data universally and the curated insight where it is supported.

Smart Locks with Biometric or Keypad Features

The standard Matter lock cluster handles lock, unlock, and basic user management. Fingerprint enrollment, PIN schedule management, duress codes, and doorbell-style video integration typically live in custom clusters. Because smart locks are safety-relevant, the access control granularity of Matter's ACL system is particularly valuable here: a vendor can ensure that only its own authenticated app can enroll new biometric users, while any Matter controller can still lock and unlock the door.

Energy Devices: Solar, Batteries, and EV Chargers

The CSA has added device types for solar inverters, batteries, and EV supply equipment, but the operational detail that enthusiasts want — tariff-aware charging curves, grid-service participation, battery state-of-health telemetry — usually ships via custom clusters. These are categories where Matter provides the universal on/off and monitoring baseline, and the vendor's app provides the energy-management intelligence.

How to Evaluate Custom Clusters as a Buyer

When you are reading a product page or a review, a few concrete signals tell you how much a device relies on manufacturer extensibility:

  • Feature lists that mention "in the app." Any capability described as "available through the [brand] app" is almost certainly a custom cluster or a cloud-routed feature.
  • Published developer documentation. Vendors who publish their custom cluster schemas (Nanoleaf, for example, has historically done this) are signaling that they want their proprietary features to work beyond their own app.
  • Community integrations. Active support in platforms like Home Assistant often indicates that the custom cluster schema has been reverse-engineered or officially shared, which dramatically improves long-term value.
  • Dependence on the vendor cloud. If advanced features stop working when the internet is down, the custom cluster is a thin client to a cloud service rather than a local capability.

A healthy Matter device uses custom clusters to add functionality on top of a complete standard-cluster baseline. An unhealthy one uses custom clusters to withhold functionality that should have been standard.

The Future of Extensibility in Matter

The CSA has been steadily absorbing popular custom-cluster features into the official specification with each major Matter release. What was proprietary in one generation often becomes standardized in the next — energy reporting, robot vacuum controls, and water leak detection have all followed this trajectory. This is the intended lifecycle: vendors innovate with custom clusters, the market signals which features matter, and the CSA codifies the winners.

For homeowners, the implication is that buying a device with interesting custom-cluster features is a bet on two things: that the vendor will continue to support its app, and that the most valuable of those features will eventually migrate into the standard so they survive platform changes. Devices from vendors with a track record of publishing schemas and contributing to the CSA tend to age better than devices from vendors who treat Matter as a bare-minimum certification badge.

Frequently Asked Questions

Can Apple Home, Google Home, or Alexa use Matter custom clusters?

Not directly, unless the platform vendor has chosen to implement that specific manufacturer's schema. In practice, Apple Home, Google Home, and Amazon Alexa expose only the standard Matter clusters and ignore custom cluster IDs. The manufacturer's own app is usually the only controller that can exercise proprietary features. Some enthusiast platforms such as Home Assistant do integrate selected custom cluster schemas when they are published or reverse-engineered.

Do custom clusters make a Matter device less secure?

At the protocol level, no. Custom clusters use the same encrypted CASE sessions, operational certificates, and access control lists as standard clusters. The security risk, when it exists, is in the companion cloud services that some vendors tie to their proprietary features, or in the lack of public auditability when schemas are kept private. The Matter link itself remains as secure for custom traffic as it is for standard traffic.

Will a Matter device with custom clusters still work if the manufacturer goes out of business?

The standard-cluster functionality will continue to work indefinitely, because it is interpreted locally by any Matter controller. Custom-cluster features that are processed on-device will also continue to work in the vendor's app as long as the app keeps running on your phone. Custom-cluster features that depend on the vendor's cloud will stop working the day those servers are shut down. This is the strongest argument for preferring devices whose core value lives in standard clusters.

How can I tell which features of a device use custom clusters?

Look at the product's feature list and identify anything described as requiring the manufacturer's app, a cloud account, or a specific hub. Those features are almost certainly behind custom clusters or cloud APIs. Technical users can also inspect the device's endpoint descriptor through a Matter controller that exposes raw cluster lists — custom clusters will appear with IDs in the 0xFC00–0xFFFE range, tagged with the vendor's CSA-assigned vendor ID.

Are custom clusters unique to Matter, or do other protocols have them?

The concept is inherited directly from Zigbee, which has long used manufacturer-specific clusters in the same ID range. Z-Wave uses a similar idea through proprietary command classes. What Matter does differently is formalize the access control and multi-admin behavior around custom clusters, so that a proprietary feature on one fabric does not interfere with standard operation on another. The underlying idea — "extend the standard without breaking it" — is a well-established pattern across smart home protocols.