Nordic offers two production SDKs for its wireless SoCs — and they are architecturally very different. nRF5 SDK is the mature bare-metal path; nRF Connect SDK is the Zephyr-based strategic platform. The right answer for your product depends on lifecycle stage, target hardware, and team priorities — not on which SDK gets better marketing. This guide gives you the honest engineering view, informed by shipped products on both stacks.

DigitalMonk IoT Engineering Team

Nordic Firmware & Embedded Systems · Jalandhar, IN · Alpine, CA · Coventry, UK

The Two SDKs at a Glance

nRF5 SDK

Nordic's original production SDK, in active use since the nRF51 era. It is built for bare-metal development on nRF51 and nRF52 SoCs, using Nordic's SoftDevice architecture — a precompiled BLE (or ANT) stack that runs at a higher ARM exception priority than your application, managing radio timing without direct application involvement. Hardware configuration lives in per-project C headers (sdk_config.h, custom_board.h). The build system is GCC Makefiles or Segger Embedded Studio project files.

nRF5 SDK is mature and widely deployed. There is a large body of reference code, forum history, and application notes across the embedded industry. Nordic continues to issue bug fixes, but new features are no longer being added and new chip support goes exclusively to nRF Connect SDK. It is in maintenance mode — stable, not evolving.

nRF Connect SDK

Nordic's strategic platform for all new development. Built on Zephyr RTOS — the Linux Foundation's embedded OS — with Nordic's extensions, protocol stacks, and drivers layered on top. Hardware is described in .dts / .overlay devicetree files. Build configuration uses Kconfig (prj.conf). Repository management uses the west tool. The BLE stack is Zephyr's Bluetooth subsystem, which calls into Nordic's own softdevice controller underneath. It supports nRF51, nRF52, nRF53, nRF54, and the nRF7002 Wi-Fi companion IC. Nordic's own documentation is direct: nRF Connect SDK is the recommended SDK for new designs. For the broader RTOS selection question — when Zephyr is the right choice versus FreeRTOS or bare-metal C — our embedded RTOS decision guide covers that across all embedded platforms.

Attribute	nRF5 SDK	nRF Connect SDK
Architecture	Bare-metal + SoftDevice	Zephyr RTOS
Build system	GCC Makefiles / Segger SES	west + CMake + Kconfig
Hardware config	C header defines	Devicetree (.dts / .overlay)
Feature config	`sdk_config.h`	Kconfig (`prj.conf`)
nRF51 / nRF52	Yes	Yes
nRF53 / nRF54	No meaningful support	Yes (required for nRF53)
Wi-Fi (nRF7002)	No	Yes
BLE + Thread + Matter	Limited	Yes
Nordic's strategic focus	Maintenance only	Active development
Learning curve (from bare-metal)	Lower	Higher (Zephyr + west + DTS)

Fig. 1 — SDK stack architecture comparison. The key differences: nRF Connect SDK's multi-protocol support (L3), board-agnostic HAL via devicetree (L2), and broader hardware support including nRF53 / nRF54 multi-core parts (L1).

Devicetree: Hardware Description That Scales

In nRF5 SDK, hardware configuration lives in C code. Your UART peripheral assignment, GPIO pin numbers, interrupt priorities, and SPI bus configuration are defined in sdk_config.h or directly in application structs. This works for a single board with a fixed schematic. The problem surfaces when you need a hardware variant — a new PCB revision with different pin assignments, or a second product in the same family targeting a slightly different SoC. You end up editing C code, hunting across files for hardcoded peripheral definitions.

Zephyr's devicetree separates hardware description from application logic entirely. A .dts file describes your board: "UART0 is on pin P0.06 (TX) and P0.08 (RX), at 115200 baud; SPI1 has chip select on P0.17; the RGB LED is on GPIO P0.22." Your application code uses symbolic references — DT_ALIAS(uart0), DEVICE_DT_GET(DT_NODELABEL(spi1)) — and the build system resolves these to the correct peripheral instances and pin assignments at compile time. No pin number appears in application code.

The practical payoff is board portability. When you fork the firmware for a hardware revision with different pin assignments, you write a .overlay file — typically a dozen lines — rather than hunting through application code. When you move from nRF52832 to nRF52840 for additional GPIOs, the SoC-level DTS changes and your overlay adapts; the application layer is largely untouched. When you share a driver across three products with different board layouts, the driver is written once to the Zephyr API and each board gets its own devicetree.

Honest caveat: Devicetree has a real learning curve. The DTS syntax, the compatible string and binding system, and the way overlays compose with board and SoC base files are not intuitive coming from a header-based background. Most engineers need focused hands-on time before it clicks. The overhead pays off as soon as you have more than one board variant to maintain — and compounds further across a product family.

Kconfig: Configuration as Code

nRF5 SDK uses sdk_config.h — a large C header with hundreds of #define CONFIG_SOMETHING 1 flags. Enable a feature by setting its flag; disable by clearing it. This works, but it scales poorly. The header grows large. Merge conflicts in a shared sdk_config.h are common on teams with more than one engineer. There is no build-system-level enforcement that your configuration is consistent — a missing or mismatched define often surfaces as a runtime failure rather than a build error.

nRF Connect SDK inherits Zephyr's Kconfig system — the same configuration infrastructure used by the Linux kernel. Each software component declares its configuration options in a Kconfig file with explicit dependency declarations: depends on BT_GATT ensures you cannot enable GATT without Bluetooth, and the build system enforces this. Your project configuration lives in prj.conf, a clean version-controlled file that contains only the options you have set. Board-level configuration lives separately in board.conf.

west build -t menuconfig opens an interactive menu browser — navigate the full configuration tree, view dependencies, and toggle subsystems without reading source files. This is genuinely useful for onboarding engineers who need to understand which Kconfig flags control which features. The dependency tracking is the key improvement over sdk_config.h: Kconfig catches configuration errors at build time rather than at runtime.

Hardware Abstraction Layer

nRF Connect SDK uses Zephyr's Hardware Abstraction Layer with Nordic's nrfx drivers underneath. Your application calls Zephyr's generic peripheral APIs — gpio_pin_set(), spi_transceive(), i2c_write() — and Zephyr resolves these to the correct nrfx calls for the target SoC, as described by the devicetree. In nRF5 SDK you call nrfx directly: nrfx_spi_init(), nrfx_uart_tx() — with hardware-specific parameters embedded in the call.

The Zephyr HAL benefit is real for product families. If you maintain three hardware variants of the same product, peripheral configuration differences live in devicetree overlays. Driver code is shared without modification. For a single one-off product that will never change hardware, the HAL abstraction adds learning overhead without a direct return — the abstraction is overhead until it is not. The benefit compounds when you are managing a product line or planning hardware revisions.

Multi-Core Support: nRF53 and nRF54

Before the SDK choice comes the chip choice. If you are still evaluating which Nordic SoC to build on, our nRF52 vs nRF53 vs nRF54L hardware comparison covers power budget, protocol support, and cost — with an interactive flowchart.

The nRF5340 — Nordic's first nRF53 series device — has two ARM Cortex-M33 cores: an application core running at 128 MHz for user application logic, and a network core running at 64 MHz dedicated to radio protocol execution. This architecture isolates radio timing from application scheduling, eliminating a class of BLE latency and timing conflicts that can affect single-core designs running both stacks on the same core. The nRF54 family (nRF54L15, nRF54H20) extends multi-core further.

nRF5 SDK was designed for single-core nRF51 and nRF52 parts. It does not support the nRF5340's dual-core architecture in any meaningful way. If you are targeting nRF53 or nRF54 hardware, the SDK choice is effectively made: nRF Connect SDK is the only supported path.

Zephyr handles multi-core natively. On the nRF5340, you build separate firmware images for the application core (nrf5340_dk_nrf5340_cpuapp) and the network core (nrf5340_dk_nrf5340_cpunet). Inter-processor communication uses the IPC service — built on Zephyr's OpenAMP/RPMsg framework — allowing the two cores to exchange messages, share memory regions, and synchronise state without you implementing IPC primitives from scratch. The nRF Connect SDK includes pre-built network core images for BLE, Bluetooth LE Audio, Thread, and other radio stacks, so most projects only need to build and customise the application core image.

Note: The nRF53 and nRF54 sections above describe Nordic's architecture and nRF Connect SDK's capabilities — not DigitalMonk deployments on these parts. Our shipped Nordic projects are on nRF52 hardware; see the project section below for accurate details.

For teams evaluating the nRF5340 for a new design: the app-core / network-core split affects your entire firmware architecture. Budget time to understand IPC messaging and the separate build image model before committing to nRF5340 in production. The investment is worth it for the architectural separation — but it is a real learning cost that should be scoped into your project timeline.

Real-World Experience: DigitalMonk Projects on Both Stacks

We have shipped production firmware on both nRF5 SDK and nRF Connect SDK. Three projects are relevant here — two SDKs, three shipped products.

Smart Golf Ball

A BLE-based golf tracking system built around a custom circular PCB engineered for a golf ball form factor, using an nRF52840 built on nRF5 SDK. At the time this product was developed, nRF5 SDK was the proven production path for nRF52840 BLE peripheral devices — mature SoftDevice BLE stack, well-documented advertising and connection management API, large reference codebase. It shipped as a complete, working product. The power engineering behind it — 3.8 µA sleep current, interrupt-driven wake, and BLE duty cycling — is documented in our nRF52840 power optimization guide.

nRF52840nRF5 SDKBLECustom PCB

nRF Haptic / Motion-Feedback System

A motion-triggered haptic feedback device built directly on nRF Connect SDK and Zephyr. The Zephyr threading model — separating the sensor sampling thread from the haptic output thread — was the right fit for this application's real-time requirements. PWM driver configuration via devicetree kept the hardware binding clean and the application layer portable. Shipped on nRF Connect SDK from the start. BLE command interfaces of this kind — write-without-response commands with notify-based acknowledgement — are covered in our custom GATT services guide for Nordic platforms.

nRF Connect SDKZephyrHapticsMotion Sensing

nRF Wearable Sports Performance Tracker

A wearable Nordic device for sports performance tracking, built on nRF Connect SDK. The Kconfig system made managing sensor driver dependencies, BLE service stack configuration, and power management flags meaningfully cleaner than sdk_config.h would have been at this complexity level. Shipped on nRF Connect SDK from the start.

nRF Connect SDKZephyrBLEWearable

The honest framing: This is not a migration story. We did not move any product from nRF5 SDK to nRF Connect SDK. Our earlier nRF work was built on nRF5 SDK because that was the right choice at the time. Our newer work is built on nRF Connect SDK because that is where Nordic's tooling and the embedded industry have moved. Both stacks produced real shipped products. Working in both gives us a concrete basis for advising on the SDK question — not just a preference for whatever is newest.

Migration Considerations

If you are weighing a migration from nRF5 SDK to nRF Connect SDK for an existing product, the following is general engineering guidance for teams thinking through the decision — informed by our experience with both stacks, not a personal migration story.

When migration is worth it

✓
Your next hardware revision targets nRF53 or nRF54
In this case you have no choice — nRF Connect SDK is the only supported path. The migration is really a greenfield build on new hardware rather than a port.
✓
You need multi-protocol support nRF5 SDK cannot provide
BLE + Thread + Matter, or Wi-Fi via the nRF7002 companion IC. For protocol combinations that cross Nordic's product lines, nRF Connect SDK is the only supported option. See also our Wi-Fi vs BLE vs LoRa protocol comparison for guidance on the wireless selection decision before committing to a stack.
✓
Long-term Nordic support is a product requirement
Security patches, protocol updates, and new regulatory certifications will come to nRF Connect SDK first. For products with a multi-year service life in regulated markets, this matters.

When to leave it alone

✕
Stable product in volume production
If the product meets its requirements and the nRF5 SDK version is sufficient, migration is significant cost and risk with limited upside. Rewriting working production firmware rarely pays off unless there is an architectural reason.
✕
Tight timeline with existing nRF5 SDK expertise
Absorbing the Zephyr learning curve under deadline pressure is a reliable way to miss both the deadline and the quality bar. Use the SDK your team already knows if the timeline cannot absorb ramp-up.
✕
Simple single-protocol nRF51/52 design with no variant plans
If the product is straightforward, protocol requirements are met by nRF5 SDK, and there are no hardware variants to maintain, the nRF Connect SDK overhead exceeds any benefit.

What migration actually involves

Migration is not a porting exercise — it is rebuilding on a different architecture. Hardware configuration moves from C headers to devicetree. The build system changes from GCC Makefiles or Segger Embedded Studio to west + CMake + Kconfig. Application architecture changes from a bare-metal event loop to Zephyr threads, work queues, and the Zephyr kernel API. BLE application code changes from the SoftDevice API to Zephyr's Bluetooth API — different call signatures and connection management model, even though Nordic's softdevice controller is still underneath.

Practical advice: Do not attempt a cold migration of a production codebase as your team's first Zephyr project. Build something on nRF Connect SDK first — a standalone peripheral prototype, a sensor node, anything low-stakes that forces your team through the Zephyr ramp-up. Build competence, then estimate the migration. Teams that skip this step consistently underestimate the effort.

The Honest Verdict

For new production designs — especially anything targeting nRF53 (nRF5340) or nRF54 hardware — nRF Connect SDK with Zephyr is the right choice. It is Nordic's recommended SDK, it is where all new chip support and active development live, and the architectural investments (devicetree, Kconfig, multi-core IPC) compound in value over a product's lifecycle. If you are starting a new Nordic design today, nRF Connect SDK is the correct default.

For existing nRF5 SDK products in stable volume production, the calculation is different. If the product meets its requirements, the nRF5 SDK version covers your needs, and there is no architectural reason to migrate — no nRF53/54 target, no multi-protocol requirement beyond what nRF5 SDK can support — then leaving it on nRF5 SDK is not a mistake. It is the pragmatic call. Migration has real engineering cost and real risk; it needs a real reason.

The honest framing: nRF Connect SDK is the future of Nordic development. nRF5 SDK can still ship real products today. Know which situation your project is actually in.

Why DigitalMonk for Nordic Firmware

We have shipped production firmware on both nRF5 SDK and nRF Connect SDK. That is not a documentation claim — it is experience with the actual friction points of each stack under production conditions. The Golf Ball project taught us where nRF5 SDK's BLE stack is solid and where it constrains you. The haptic and wearable projects taught us where Zephyr's threading model and Kconfig genuinely win over the bare-metal approach. Both experiences inform how we advise clients on the SDK decision.

If you are evaluating the SDK choice for a new Nordic design — or weighing whether a migration makes sense for an existing product — our nRF Connect SDK developers can work through the specifics: hardware requirements, protocol stack, timeline, and team background. We give you an honest recommendation, not a default to whatever is newest.

For teams already committed to nRF Connect SDK, we can accelerate the Zephyr ramp-up. For teams continuing on nRF5 SDK, we support that work too. We are nRF firmware developers who work across the full Nordic stack.

DigitalMonk — Nordic Firmware Developers

Production nRF5 SDK and nRF Connect SDK experience. BLE, multi-protocol, wearables, and custom PCB design. UK, US, and India.

→

Frequently Asked Questions

It depends on your situation. For new production designs — especially on nRF53 (nRF5340) or nRF54 hardware — nRF Connect SDK is Nordic's recommended path and the right default. It is where new chip support, long-term maintenance, and multi-protocol capabilities live. For existing nRF5 SDK products in stable production that meet their requirements, 'better' is not the right framing: they are two SDKs suited to different situations. nRF5 SDK still ships real products in production today.
Probably not — unless you have a specific reason. If the product is in stable production and meets its requirements, migration carries significant cost and risk with limited upside. The right reasons to migrate: the next revision targets nRF53 or nRF54 hardware, you need long-term Nordic security patch coverage beyond nRF5 SDK's maintenance window, or you require multi-protocol capabilities (BLE + Thread + Matter) that nRF5 SDK cannot support. 'nRF Connect SDK is newer' is not a reason on its own.
Devicetree is a hardware description language that separates your board's physical configuration from your application code. In a .dts or .overlay file, you describe which pins are connected to which peripherals, what UART baud rates are, which SPI bus your sensor uses. Application code uses symbolic references (DT_ALIAS, DEVICE_DT_GET) and the build system resolves these to actual peripheral instances at compile time. The practical payoff: porting to a new board variant or a hardware revision becomes a devicetree overlay change, not a hunt through application code for hardcoded pin assignments.
Yes, Nordic still ships nRF5 SDK updates and bug fixes — but it is in maintenance mode. New features are not being added, and all new chip support goes to nRF Connect SDK exclusively. Your existing nRF5 SDK codebase will not stop working, but Nordic's active development effort is on nRF Connect SDK. For security-sensitive products, this matters: security patches and protocol updates will arrive in nRF Connect SDK first, with nRF5 SDK coverage dependent on severity.
Not meaningfully. nRF5 SDK was designed for single-core nRF51 and nRF52 SoCs. The nRF5340 has a dual-core architecture (application core + network core) that nRF5 SDK does not support. nRF54 parts extend this further. For nRF53 and nRF54, nRF Connect SDK is not a preference — it is the only viable SDK with proper multi-core support, inter-processor communication (IPC service / OpenAMP), and the tooling to manage separate firmware images for each core.
It depends heavily on codebase complexity and team familiarity with Zephyr. A simple single-protocol BLE peripheral with modest application logic might take a few focused engineering weeks. A complex multi-service BLE product with proprietary protocol layers, custom drivers, and OTA update firmware will take months. The effort is not proportional to lines of code — the conceptual shifts (devicetree, west build system, Zephyr threading model) take time regardless of code volume. Our recommendation: run a standalone pilot project on nRF Connect SDK first to absorb the learning curve before estimating the main migration.
Both have extensive documentation, but with different strengths. nRF5 SDK documentation is mature and well-refined for the nRF52 BLE stack — years of accumulated application notes and examples. nRF Connect SDK documentation is growing rapidly, with Nordic investing heavily in it, but since the SDK is built on Zephyr, you sometimes need to read both Nordic-specific docs and upstream Zephyr documentation for platform-agnostic components. Nordic's Infocenter and DevAcademy (developer.nordicsemi.com) are the primary references; the DevAcademy structured courses significantly reduce the nRF Connect SDK ramp-up time.

Building a New Nordic Product, or Considering a Migration?

DigitalMonk has shipped production firmware on both nRF5 SDK and nRF Connect SDK. We can give you an honest assessment of which SDK fits your product — and support the build either way.

Talk to our Nordic team →

Get a Free Project Estimate