Nordic nRF54 vs. nRF5 vs. nRF52: Which BLE Generation Is Right for Your Next Product?

Published on May 19, 2026

Embedded engineers selecting a Bluetooth module today face a choice that didn't exist two years ago: Nordic's silicon lineup now spans three distinct hardware generations, each representing a meaningful jump in architecture, not just a spec revision. The nRF52840 defined a decade of BLE product design. The nRF5340 introduced dual-core processing and a dedicated network processor for wireless stacks. The nRF54L15 — the first device in the nRF54 series — rewrites the power model entirely, with an always-on subsystem architecture that makes the nRF52840's sleep current figures look outdated. And the nRF54H20 takes this a step further into applications that require higher compute, more complex logic, or more processing.

Ezurio offers certified, production-ready modules built on all three generations: the BL65x series on nRF52840, the BL53xx series on nRF5340, and the BL54xxx series on the new nRF54L15 and nRF54H20. The question isn't which Nordic chip to buy — it's which generation of Ezurio module maps to your product's actual requirements. Getting this wrong has consequences: choosing an older platform for a next-generation product means revisiting the design when power budgets tighten or BLE feature requirements evolve. Choosing a newer platform before your supply chain and toolchain are ready adds schedule risk.

This piece breaks down the three generations across the dimensions that matter most for hardware selection: processing architecture, power consumption, BLE capability, memory, and the practical migration considerations that Nordic's developer zone documents extensively — but that no module vendor has yet synthesized for engineers designing at the module level.

Why Generation Choice Matters More Now

The nRF52840 launched in 2017 and quickly became the rational default for serious BLE products — strong BLE 5.1 support, proven SoftDevice stack, high integration, and broad ecosystem tooling. Ezurio's BL652 and BL654 are built on this foundation and remain fully supported and appropriate for a large class of products.

The landscape has since shifted in three specific ways.

First, the nRF5340 introduced a dual-core architecture — an application core for user code and a dedicated network core for the BLE/Zigbee/Thread stack — decoupling radio timing from application-layer interrupt variability. This directly addressed products where application processor interrupt latency was affecting BLE connection reliability.

Second, the nRF54L15 brought a fundamentally new power architecture: a Global Domain DPLL that handles real-time clocking without waking the main CPU, and a sub-microamp always-on domain that runs RTC, GPIO sensing, and limited logic without touching the main processing subsystem.

Third, the nRF54H20 extended the nRF54 platform into high-compute territory. Where the nRF54L15 optimises for ultra-low power, the nRF54H20 targets applications requiring substantially more processing headroom — edge inference, multi-protocol coordination, or complex application logic — while retaining the nRF54 security architecture. Ezurio's BL54H20 module addresses the tier of products where the nRF54L15's compute envelope becomes a constraint.

The regulatory dimension sharpens this decision further. The EU Cyber Resilience Act (EU CRA), now in its enforcement transition period, imposes requirements on firmware update capability, secure boot, and cryptographic attestation. Earlier-generation silicon can satisfy these in software — but the nRF54L15 and nRF54H20 handle them at the hardware root of trust level via Arm TrustZone-M and PSA Certified Level 2 architecture. Choosing a platform now means choosing how much of your security compliance burden lands on your firmware team versus the silicon.

The Specification Layer: BLE Feature Availability by Generation

The Bluetooth specification — governed by the Bluetooth Special Interest Group — defines what a given BLE version mandates versus what it permits. Understanding this layer is prerequisite to understanding why newer silicon matters for specific features.

Bluetooth 5.0 introduced 2× data throughput (2M PHY), 4× range (Coded PHY at S=8), and advertising extensions. Bluetooth 5.1 added Direction Finding — the AoA/AoD infrastructure for sub-meter BLE location. Bluetooth 5.2 added LE Audio foundations (isochronous channels, LC3 codec, LE Power Control). Bluetooth 5.4 (2023) added Periodic Advertising with Responses (PAwR). And Bluetooth 6.0, defined in the Bluetooth SIG Core Specification 6.0, introduced Channel Sounding — also known as High Accuracy Distance Measurement (HADM) — enabling sub-decimeter ranging between BLE devices. The feature matrix below maps each capability to Ezurio's module families.

BLE Feature	BL65x (nRF52840)	BL53xx (nRF5340)	BL54xxx (nRF54L15)	BL54Hxx (nRF54H20)
BLE 5.0 (2M PHY, Coded PHY)	✓	✓	✓	✓
BLE 5.1 Direction Finding (AoA/AoD)	✓	✓	✓	✓
BLE 5.2 LE Audio (LC3 codec)	Partial (stack only)	✓	✓	✓
BLE 5.4 PAwR / EATT	✗	✓	✓	✓
BLE 6.0 Channel Sounding (HADM)	✗	✗	✓	✓
LE Secure Connections (LESC)	✓	✓	✓	✓
Hardware AES acceleration	AES only	AES + ECC	AES + ECC + CRACEN	AES + ECC + CRACEN
PSA Certified Level 2	✗	✗	✓	✓
USB 2.0 Full-Speed	✓	✗	✗	✗
Multi-core architecture	✗	✓ (app + network)	✓ (app + PPR)	✓ (multi-domain)
High-performance application core	✗	Moderate (128 MHz M33)	Moderate (128 MHz M33)	✓ (high-clock M33 + coprocessors)
802.15.4 (Thread / Zigbee)	✓	✓	✓	✓
NFC	✓	✓	✓	✗

PAwR deserves specific attention. It enables a central device to send timestamped requests to up to 255 peripheral devices in a single advertising interval, with each peripheral responding in its assigned time slot. For retail shelf-edge label networks, industrial sensor polling, or keyless entry systems, PAwR eliminates the need for a full BLE mesh stack. The nRF52840 cannot support PAwR — this is a hard architectural limit, not a firmware gap.

BLE 6.0 Channel Sounding uses phase-based and round-trip time (RTT) ranging techniques to achieve distance measurements accurate to under 10 cm under controlled conditions. This enables proximity-based access control, precise asset tracking, and spatial interaction without UWB hardware. It is exclusive to the nRF54L15 and above.

The Hardware Architecture Layer: What Each Generation Provides

nRF52840 — The Proven Foundation

The nRF52840 is a single-core Arm Cortex-M4F at 64 MHz with 1 MB flash and 256 KB RAM. Its USB 2.0 full-speed integration alongside BLE is unique in the Nordic lineup, enabling HID, CDC-ACM, and audio class enumeration. The SoftDevice S140 BLE stack is among the most battle-tested in embedded production, with millions of deployed units across medical, industrial, and consumer applications.

Power is the platform's main constraint: System ON idle runs 1.5–3 µA — adequate for many designs, but reflective of a 2016 architecture.

Ezurio's BL654 module is the production-proven nRF52840 choice, with UART/SPI/I²C interfaces, on-board antenna, and FCC/IC/CE certification. The BL652 serves space-constrained designs requiring an external antenna.

nRF5340 — Dual-Core and LE Audio

The nRF5340 splits workload across two Cortex-M33 cores: a 128 MHz application core (1 MB flash, 512 KB RAM) and a dedicated 64 MHz network core (256 KB flash, 64 KB RAM) that runs the BLE stack in full isolation. This eliminates latency from application-layer interrupt competition — critical for connection intervals below 10 ms.

The nRF5340 also delivers full LE Audio support, including LC3 codec and Auracast broadcast. Any product with audio transmission requirements — hearing aids, wireless accessories, smart speakers — should treat this as the minimum platform. Ezurio's BL5340 module brings these capabilities in a certified FCC/IC/CE form factor with on-board and U.FL antenna options.

nRF54L15 — The New Power Architecture

The nRF54L15 adds a 16 MHz Peripheral Processor (PPR) alongside its 128 MHz Cortex-M33 application core, enabling lightweight I/O and sensor tasks without waking the main CPU. System ON active current is ~0.5 µA/MHz — roughly half the nRF5340 — and the PPR subsystem runs at under 30 µA total. For coin-cell and energy-harvesting designs, this is a meaningful expansion of the design space.

Security is also significantly upgraded: the CRACEN hardware cryptographic engine (AES-128/256, SHA-256/512, ECDSA/ECDH, hardware key storage) underpins PSA Certified Level 2 and directly supports EU CRA Article 13 compliance — shifting the audit burden from firmware to pre-certified silicon.

Ezurio's BL54L15 module brings BLE 6.0, CRACEN, and sub-microamp always-on operation to a certified, production-ready form factor.

nRF54H20 — High-Performance Compute with nRF54 Power

The nRF54H20 is the compute-focused member of the nRF54 family. Where the nRF54L15 targets ultra-low-power IoT and sensor applications, the nRF54H20 is designed for products requiring substantially more processing headroom — complex edge inference, multi-protocol coordination, or demanding application logic — while retaining the nRF54 power architecture advantages.

It features a multi-core design with high-performance and low-power processing domains, hardware security consistent with the nRF54 series, and BLE 6.0 support. Ezurio's BL54H20 module brings these capabilities to a certified form factor suited for applications where the nRF54L15's compute envelope is a limiting factor.

Note: The BL54H20 is targeted at designs requiring significant compute beyond typical BLE/mesh IoT workloads. For the majority of connected sensor and control applications, the BL54L15 remains the recommended starting point.

Practical Deployment Guidance: How to Choose

Six questions determine which generation is correct for your product. Work through them in order:

Do you need BLE 5.4 features (PAwR, EATT, ECRED) or BLE 6.0 Channel Sounding? If yes, the BL54xxx (nRF54L15) or BL54Hxx (nRF54H20) series are the only options. These are hard platform requirements — neither feature can be backported to nRF52840 or nRF5340.
Do you need LE Audio (Auracast, LC3 codec, broadcast audio)? If yes, the BL53xx series is the minimum — the nRF5340's 512 KB RAM and dual-core architecture provide the headroom LC3 encoding/decoding requires. The nRF54L15 and nRF54H20 also support LE Audio, so if you have additional power, security, or compute requirements, you do not have to choose.
Is your application coin-cell or energy-harvested? If your power budget is below 50 µA average current with significant idle time, the nRF54L15's PPR subsystem enables designs not feasible on prior generations at equivalent functionality. The BL54xxx series should be the default evaluation target for any new battery-constrained design. The nRF54H20 shares the nRF54 power architecture but is not optimised for ultra-low-power operation — if power is the primary constraint, prefer the BL54xxx.
Does your application require significant compute headroom? If your product involves edge inference, multi-protocol coordination, or complex application logic that pushes the nRF54L15's processing envelope, the BL54Hxx series on the nRF54H20 is the correct platform. This is the differentiating question between the two nRF54 variants — if the nRF54L15's CPU and memory are sufficient, the BL54xxx is the lower-risk choice.
Do you have a hard USB device requirement? USB 2.0 full-speed is only available on the nRF52840. If your product must enumerate as a USB HID, CDC-ACM, or audio class device, the BL65x series is the only option. Verify whether your USB requirement is functional or cosmetic — USB-C charging does not require nRF52840.
What is your time-to-market constraint and toolchain maturity? The BL65x on nRF52840 has the deepest ecosystem: the most validated Zephyr RTOS drivers, the most third-party library support, and the most reference designs. If you are shipping in the next 12 months with no nRF5340 or nRF54L15 experience on your team, the BL65x series carries lower schedule risk. The BL54Hxx on nRF54H20 carries the highest toolchain risk of the four platforms — Nordic's production ramp and SDK maturity for the nRF54H20 should be verified against your development timeline before committing.

One common misconfiguration across all generations: engineers often configure advertiser intervals optimised for active-scan scenarios, then deploy products that operate as beacons or sensors with infrequent connections. Advertising interval directly dominates average current in non-connected BLE devices. The nRF54L15's GDPLL architecture allows very long advertising intervals (up to 10 seconds in PAwR configurations) while maintaining microsecond-accurate event timing — a capability the nRF52840 cannot match because waking the CPU for clock management at that interval would exceed the power benefit. The nRF54H20 shares this GDPLL capability, though power optimisation at the advertising layer is less likely to be the design constraint on that platform.

Migrating Between Generations: What Actually Changes

The migration from nRF52840 to nRF5340 is primarily a software architecture change. The hardware pinouts and RF characteristics are similar enough that a BL654-to-BL5340 board redesign is manageable. The code change is more significant: the nRF5340 requires splitting the application into a network core image and an application core image, with IPC communication between them. Developers accustomed to a single-image SoftDevice build must restructure their project layout, understand Zephyr's multi-image build system, and validate IPC channel behavior under load.

Migration from either previous generation to the nRF54L15 adds one additional consideration: Nordic's SoftDevice stack is not available for the nRF54L15. The platform uses Zephyr RTOS with Nordic's BLE Host stack exclusively. If your firmware is built on SoftDevice S140 with a custom ATT/GATT implementation, that is not a direct port — it requires a Zephyr migration. For teams already on Zephyr (increasingly the default for new nRF designs since 2022), this is not a significant barrier. For teams on SoftDevice-based legacy codebases, budget for a non-trivial porting effort.

The CRACEN security engine on the nRF54L15 exposes its cryptographic operations through the PSA Crypto API — the same interface used on the nRF5340's CryptoCell 312. If your existing code uses Mbed TLS or nRF Security, the PSA abstraction layer is largely source-compatible. Key provisioning workflows change more meaningfully: the CRACEN KMU stores keys in dedicated, access-controlled memory rather than in flash, and key lifecycle operations require explicit PSA key management API calls. This is more secure and more auditable, but it requires updating provisioning tooling and manufacturing test procedures.

Migration to the nRF54H20 shares the same Zephyr and PSA Crypto requirements as the nRF54L15 — SoftDevice is equally absent, and CRACEN-based key management applies in the same way. The additional complexity is architectural: the nRF54H20's multi-domain design (separate application, radio, and security processing domains) requires a more involved project structure than even the nRF5340's dual-core split. Teams migrating from nRF54L15 to nRF54H20 will find the BLE stack and security layers largely familiar, but should expect meaningful rework in how application workloads are partitioned across domains. Teams migrating from nRF52840 or nRF5340 directly to nRF54H20 are compounding three distinct architectural changes simultaneously — Zephyr adoption, PSA key management, and multi-domain partitioning — and should plan accordingly.

One further nRF54H20-specific consideration: SDK and toolchain maturity. Nordic's nRF Connect SDK support for the nRF54H20 is newer than for the nRF54L15, and the volume of production-validated reference designs and community Zephyr drivers is correspondingly thinner. Teams targeting the nRF54H20 should validate SDK version compatibility and peripheral driver coverage against their specific hardware requirements early in the design phase, before committing board layout.

Common manufacturing failure point: On nRF52840-based BL65x modules, hardware root-of-trust key programming (UICR/KDR) must be completed before the device leaves the manufacturing line — these registers are one-time programmable and cannot be updated in the field. Missed key provisioning during production is one of the most common security deployment errors on this platform. The nRF54L15's CRACEN KMU lifecycle management makes this failure mode significantly harder to produce — and the nRF54H20 carries the same improvement, with the added benefit that its security domain isolation means a compromised application domain cannot directly access key material even at runtime.

Regulatory and Compliance Dimensions

The EU Cyber Resilience Act (Regulation (EU) 2024/2847), which applies to products with digital elements placed on the EU market, imposes specific requirements on connected device security: vulnerability handling, security updates, and technical documentation of cybersecurity measures. Article 13 requires that products 'be designed, developed, and produced in such a way as to ensure an appropriate level of cybersecurity based on the risks.'

For BLE products, this translates practically into secure boot (attestable chain of trust from bootloader to application), firmware update integrity verification, and cryptographic authentication of configuration changes. The four generations offer different levels of native compliance support:

nRF52840 (BL65x): Secure boot via MCUboot with UICR/KDR hardware key storage. Effective, but key programming at manufacturing time is the common failure point — and the audit trail is software-dependent.
nRF5340 (BL53xx): CryptoCell 312 provides hardware-accelerated key storage and attestation, reducing firmware complexity versus nRF52840. Full PSA compliance requires integration of Nordic's Trusted Firmware-M (TF-M), which adds build complexity but is well-documented.
nRF54L15 (BL54xxx): CRACEN engine with PSA Certified Level 2 status. TF-M integration is the default build target, not an add-on. Secure boot and key management are first-class SDK features, not bolt-ons — significantly reducing the CRA Article 13 documentation burden.
nRF54H20 (BL54Hxx): Shares the CRACEN security engine and PSA Certified Level 2 architecture of the nRF54L15, with one meaningful addition: hardware-enforced domain isolation. The nRF54H20's security processing domain is physically separated from the application domain, meaning a compromised application cannot access key material or tamper with secure boot attestation at runtime. For products in higher-risk categories under EU CRA Annex III — or targeting US federal procurement under NISTIR 8425 Profile B — this provides a stronger security argument than software domain separation alone.

NIST SP 800-213 ("IoT Device Cybersecurity Guidance for the Federal Government") and its companion NISTIR 8425 establish baseline security requirements for IoT devices that map closely to EU CRA Article 13. Products targeting US federal procurement must satisfy NISTIR 8425 Profile B, which explicitly requires hardware-enforced secure boot — a requirement both the nRF54L15's and nRF54H20's CRACEN architecture satisfies natively. For products in the highest-risk classifications, the nRF54H20's domain isolation provides additional separation of duties that may be relevant to formal security evaluations.

FCC authorization for the BL54Hxx, BL54xxx, BL53xx, and BL65x modules is handled at the module level under Ezurio's modular grant. End-products can leverage the existing module FCC ID under modular grant conditions without a full radio frequency device authorization in most configurations. Full certification documentation — FCC, IC, CE/RED, and country-specific marks — is available via Ezurio's support page.

Conclusion

The nRF52840, nRF5340, nRF54L15, and nRF54H20 are not competing options on a single value curve — they represent distinct architectural generations with non-overlapping capabilities at their edges. The BL65x series on nRF52840 remains the right answer for USB-dependent designs and for teams with SoftDevice codebases that don't justify migration. The BL53xx series on nRF5340 is the minimum platform for LE Audio applications and delivers dual-core determinism for latency-sensitive BLE products. The BL54xxx series on nRF54L15 is the correct default for new battery-constrained designs, any product requiring BLE 6.0 Channel Sounding, and products where PSA Certified Level 2 hardware security is a procurement or regulatory requirement. The BL54Hxx series on nRF54H20 addresses the tier above: products where the nRF54L15's compute envelope is a constraint, where hardware domain isolation strengthens a security argument, or where complex multi-protocol workloads require dedicated processing headroom alongside the nRF54 power and security architecture.

Ezurio's module families across all four generations share common form factors, pre-earned FCC and CE certifications, and a consistent hardware abstraction approach that reduces redesign burden when moving between generations. The selection decision is primarily a software architecture and feature requirements exercise — not a hardware reinvention. For the majority of new connected designs, the BL54xxx on nRF54L15 is the right starting point; the BL54Hxx on nRF54H20 is the answer when that platform's boundaries become visible during scoping.

Ready to Get Started?

To discuss which BLE module generation aligns with your product requirements, contact Ezurio's engineering team at ezurio.com/contact, or review the BL54xxx, BL53xx, and BL65x product families at ezurio.com/wireless-modules/bluetooth-modules.

Ezurio Engineering Team Bluetooth Module Families