OpenThread NCP Maintenance and Thread Certification

[Werner-Prbk]

Hello OpenThread team,

We are currently evaluating the OpenThread NCP architecture for a commercial product and would appreciate some clarification regarding its long-term viability and maintenance status.

Our planned system architecture consists of:

• An nRF54-based network coprocessor running OpenThread
• A Linux host communicating with the NCP via Spinel

One of the main reasons we are considering the NCP approach is related to Thread certification.

Our understanding is that, with the NCP architecture, the complete Thread stack remains confined to the Nordic device. The Linux host only interacts with the Thread stack through the NCP interface and does not execute any Thread protocol code itself.

The idea would therefore be to use Nordic's pre-certified OpenThread implementation on the nRF54 and follow the Certification by Inheritance approach.

Is this assumption and certification strategy generally considered valid and realistic?

From our perspective, the RCP architecture is not a suitable alternative, because in that case the OpenThread stack runs on Linux and we would no longer have a pre-certified Thread stack available for inheritance purposes.
The full certification process via ATL, together with the associated requirements and costs (including full Thread Group membership), would exceed the budget of this product.

Additionally, we would like to understand the future direction of OpenThread:

Is the NCP architecture still actively maintained and will be supported in future releases, or is the project primarily focusing on RCP-based solutions?

Any guidance, especially from maintainers or companies that have gone through a similar certification path, would be greatly appreciated.

Thank you!

[Werner-Prbk]

Any comments on this from the maintainers?

[jwhui]

Hello @Werner-Prbk,

1. Thread Certification by Inheritance & Nordic

• Component Certification: Nordic certifies its SoCs as Thread Certified Components (FTD and MTD roles) in the nRF Connect SDK using reference builds (SoC/CLI) with pre-compiled libraries (CONFIG_OPENTHREAD_NORDIC_LIBRARY=y).
• NCP Certification Status: Nordic does not typically certify a distinct "NCP" component. While the NCP sample uses the same core stack, you should check with Nordic and the Thread Group to confirm whether an NCP build qualifies for inheritance without delta testing.
• Membership Requirement: An active Thread Group membership (Implementer level or higher) is still required to inherit certification, obtain a CID, and license Thread trademarks.

2. Maintenance Status & Thread 1.4 Limitations

• NCP Maintenance: OpenThread actively maintains and tests NCP builds (ot-ncp-ftd, ot-ncp-mtd) and Spinel framing in CI.
• Thread 1.4 Feature Gap: While otbr-agent supports many NCP features (tracked in openthread/ot-br-posix#2398), NCP mode does not yet support all Thread 1.4 Border Router features (such as TREL, NAT64, and DNS-SD Discovery Proxy).

3. Host-Side Architecture

• wpantund Replacement: wpantund is deprecated and unmaintained. Its modern replacement, otbr-agent (OTBR), supports communicating with both an RCP and an NCP over Spinel.
• Host Integration: If using an NCP on Linux, you can use otbr-agent in NCP mode (with Border Routing features disabled if the device is not a Border Router) to handle host-to-NCP communication, wpan netif management, and ot-ctl CLI commands.

Hope that helps.

[Werner-Prbk]

@jwhui
Shouldn't NCP host integration already be covered by otbr-agent?

There are several discussions here that address exactly this topic, for example: https://github.com/orgs/openthread/discussions/11425#discussioncomment-12870450

Based on those posts, otbr-agent seems to be the recommended approach for integrating an NCP with the host side.
A quick test also showed that the NCP can communicate with otbr-agent in principle. However, no tests with a real Thread network have been performed yet, so full end-to-end validation is still pending.

[jwhui]

@Werner-Prbk Good catch. I have updated my previous response above to reflect this.

To confirm:

• otbr-agent NCP Mode: otbr-agent (ot-br-posix) is indeed the recommended host-side daemon for NCP integration on Linux (tracked in openthread/ot-br-posix#2398). It already supports wpan netif management, ot-ctl CLI commands, and core Border Router features (with Service Discovery, NAT64, and TREL still in progress for Thread 1.4). If your device is not a Border Router, you can disable the Border Routing features in otbr-agent and use it strictly for host netif and control integration.
• Certification by Inheritance: If you are building an FTD/MTD (with Border Router features disabled in otbr-agent), the Thread protocol stack remains confined to the NCP, so you only need to verify with Nordic and the Thread Group that the NCP build qualifies under Nordic's certified component. However, if you are building a Border Router, otbr-agent still executes host-side Border Router functions on Linux even in NCP mode, so an SoC's FTD component certification alone cannot be used to inherit Border Router certification.