How Do You Implement a Matter Device on the nRF Connect SDK?

Detailed Explanation

Nordic's nRF Connect SDK (NCS) is the standard path for implementing Matter on Nordic silicon, and its Zephyr-based, dual-core-aware architecture is worth understanding before starting a Matter project on the nRF5340 or nRF52840. For Matter concepts, see What Is Matter?; for the transport decision this implementation targets, see Matter over Thread vs Matter over Wi-Fi — NCS-based Matter designs are overwhelmingly Thread-transport, since Nordic's wireless portfolio centres on Thread/BLE rather than Wi-Fi. For the ESP32/Wi-Fi-transport equivalent of this guide, see how do you implement a Matter device on the ESP32?.

NCS's Relationship to Zephyr and CHIP

Like esp-matter, NCS's Matter support is built on the same upstream Project CHIP (Connected Home over IP) codebase, integrated with Zephyr RTOS (which NCS is itself built on) and Nordic's OpenThread port. This means a Matter project on NCS is, at its foundation, a Zephyr project with Matter-specific modules and samples layered on top — the same west build tooling, prj.conf Kconfig system, and device driver model used for any other NCS/Zephyr application apply. If you haven't set up an NCS development environment before, see how do you set up the nRF Connect SDK and Zephyr RTOS for nRF52 development? for the base workspace and toolchain setup this builds on.

The nRF5340 Dual-Core Architecture

Nordic's recommended platform for new Matter-over-Thread designs is the nRF5340, which splits processing across two independent Arm Cortex-M33 cores: the network core runs OpenThread's radio-layer processing, handling the time-sensitive IEEE 802.15.4 operations in relative isolation from application workload variability; the application core runs Zephyr, the Matter data model, and all device-specific application logic. This separation is architecturally similar to the network/application core split used in Nordic's Thread and Bluetooth Mesh products generally — it reduces the risk of application-layer processing timing variability affecting the radio stack's real-time requirements. The single-core nRF52840 also supports Matter over Thread and remains viable for simpler devices where the dual-core separation's benefits matter less, but Nordic positions the nRF5340 as the primary target for new Matter designs.

Starting from an NCS Matter Sample

NCS ships Matter sample applications for common device types (Matter Light Bulb, Matter Lock, Matter Sensor samples, among others), and — as with esp-matter — the recommended starting point is the closest matching sample rather than assembling a device's Matter data model from the CHIP libraries directly. Each sample includes working commissioning, a functional (if minimal) device type implementation, and the correct Kconfig baseline for Matter-over-Thread on the target board, giving a validated starting point to extend with product-specific behaviour rather than a blank slate.

Implementing Device-Specific Behaviour

Device-specific logic in an NCS Matter project is implemented the same way as any Zephyr application: using Zephyr's device driver model to interface with actual hardware (GPIO, sensors, PWM outputs), and Matter attribute/command callback handlers (defined through the CHIP data model APIs, the same underlying mechanism esp-matter uses) to connect that hardware state to the Matter data model the network sees. Attribute persistence decisions (what state needs to survive a reboot, stored via Zephyr's settings subsystem) follow the same considerations as any Zephyr application with persistent configuration needs.

Commissioning and Development Tools

Commissioning an NCS-based Matter device uses the same protocol-level flow as any Matter device — PASE over BLE, network credential transfer, then CASE on the operational Thread network — and the same chip-tool command-line controller from the upstream CHIP project works identically regardless of which SDK the target device runs on, since chip-tool implements the Matter specification's controller role rather than anything platform-specific. As with ESP32-based development, validate final commissioning against the actual target ecosystem app before considering a device production-ready, since chip-tool exercises the protocol but not the real consumer app experience.

Certification Considerations

Matter certification testing is identical in scope regardless of which SDK a device is built on — the CSA's certification program tests conformance to the Matter specification's data model and protocol behaviour, not which vendor SDK produced the firmware. What differs by platform is the practical bring-up experience: NCS's Thread-native focus means Thread-specific certification concerns (network layer conformance, Border Router interoperability testing) are more central to an NCS project's certification path than they would be for a Wi-Fi-transport esp-matter device, which instead needs to demonstrate correct behaviour against Wi-Fi network conditions.

Design Considerations

• Default to the nRF5340 for new Matter-over-Thread product designs unless a specific cost or complexity constraint favours the simpler single-core nRF52840. Zeus Design implements Matter firmware on Nordic's nRF Connect SDK as part of full-stack embedded product development, including Thread network integration and certification-readiness testing.
• Start from the closest matching NCS Matter sample rather than building the data model from CHIP APIs directly, mirroring the same practical advice that applies to esp-matter development.
• Budget Thread network layer certification and Border Router interoperability testing explicitly for NCS-based Matter products, since this is a more central part of the certification path than it is for Wi-Fi-transport designs.
• Track NCS release versions against the specific Matter/CHIP revision they integrate, the same version-pinning discipline that applies to esp-matter — mismatched assumptions about which CHIP features a given NCS release actually supports can cause confusing gaps between documentation and actual behaviour.

Common Mistakes

• Choosing the nRF52840 for a new design without considering whether the nRF5340's dual-core separation would meaningfully simplify Thread/application timing interactions for a more complex application workload.
• Building a device's data model from CHIP APIs directly instead of starting from a matching NCS Matter sample, increasing development time and commissioning-bug risk unnecessarily.
• Assuming NCS's Matter support requires writing Thread networking code manually. The OpenThread integration handles this; application development should focus on device-specific behaviour, not Thread protocol internals.
• Treating chip-tool commissioning success as production readiness without also validating against the actual target ecosystem app, mirroring the same risk on any Matter SDK.
• Underestimating Thread network layer certification scope for an NCS-based product relative to a Wi-Fi-transport equivalent, and being surprised by the additional certification testing this requires.

For MCU and radio platform selection guidance across Matter, Thread, and other wireless protocols, see how to choose a microcontroller for your project.