Your nRF54L15 Secure Boot Works—But Did You Lock the JTAG Port Attackers Will Actually Use?
You verified the signature chain. The bootloader rejects unsigned images, the keys are fused, the test vectors pass. You closed the ticket and moved on.
Here’s what an attacker does next: they don’t touch your signature chain at all. They solder two wires to the SWD pads, attach a $40 debug probe, and read your flash straight out. Keys, firmware, customer data, all of it. Your beautifully signed image is sitting right there in plaintext, and the debugger doesn’t care that it’s signed.
Secure boot answers one question: is the code that runs authentic? It says nothing about who can read or rewrite the chip while it sits on a bench. Those are two different doors, and most teams bolt the first one shut while leaving the second wide open.
On the nRF54L15, closing that second door means dealing with APPROTECT, ADAC, and lifecycle states, configured deliberately and at the right moment in your manufacturing flow. Miss the timing and you can’t fix it in the field.
Why Secure Boot Doesn’t Cover the Debug Port
Picture the two systems side by side.
SECURE BOOT DEBUG PORT
+-----------+ +-----------+
| verifies | | reads & |
| code runs | <--?-- | writes |
| authentic | | flash/RAM |
+-----------+ +-----------+
covered OPEN GAPSecure boot runs at startup. It checks a hash, validates a signature, and either lets the image run or halts. The whole process assumes the attacker is trying to get malicious code to execute.
A debugger doesn’t execute anything. It halts the core and reads memory directly over SWD: flash, RAM, registers, the lot. It can dump your firmware to a file and pull symmetric keys out of the binary, or write a patched image back without ever presenting a signature.
That means an open debug port reads out your keys regardless of how well you signed the image. The two threats don’t overlap. One is about code authenticity at runtime; the other is about raw read/write access to silicon that’s powered on a bench.
This is the gap that generic secure boot tutorials skip. They stop at “signature verified” and call the device secure. It isn’t. The debug interface is the realistic attack surface, and on the nRF54L series it’s a lifecycle problem, not a single fuse.
The nRF54L15 Lockdown Stack: Three Layers
Three mechanisms govern debug access, and they nest. Treating them as independent toggles is how people end up with a half-locked device.
+--------------------------------------+
| LIFECYCLE STATE (LCS) | <- overall posture
| +--------------------------------+ |
| | ADAC (authenticated debug) | | <- recovery path
| | +--------------------------+ | |
| | | APPROTECT (access block) | | | <- read/write gate
| | +--------------------------+ | |
| +--------------------------------+ |
+--------------------------------------+APPROTECT gates the debugger’s read/write path to flash and RAM. When it’s engaged, a connected probe can’t read out memory. On the nRF54L15 this is enforced at the hardware level and persists across resets once set, which is the behavior you want. APPROTECT is the actual gate; everything above it decides under what conditions the gate can be lifted. Confirm the register and UICR handling against your current product spec revision rather than copying nRF52-era flows, since the field names and the exact enable mechanism shifted between Nordic families.
ADAC, Authenticated Debug Access Control, makes recovery possible. Without it, debug access is all-or-nothing: either the port is open to anyone or it’s shut to everyone including you. ADAC adds a credentialed path. A debug host proves it holds the right key, and only then does it get access. This is the ARM-defined model for authenticated debug, and it’s the single most important layer for anyone who has to service returns. Lock this in early: the ADAC credentials have to be provisioned onto the device before you lock it down. If you lock first and never provision, your recovery path is as dead as the open one. (The deeper mechanics belong in your secure provisioning at scale flow.)
Lifecycle States (LCS) set the device’s overall posture. The chip moves through defined states, and the transition into a deployed/secured state is what actually clamps the configuration down. The transitions are one-way: once you advance into a locked deployment state, you don’t roll back. Nordic names these states explicitly in the product spec, so use those names as your source of truth and verify them against the revision you’re building on, because field naming has changed across the nRF54L documentation.
The three work together. LCS decides the posture, ADAC decides who gets in, APPROTECT enforces the block. Set APPROTECT without provisioning ADAC and advancing the LCS, and you’ve built a device that’s either still debuggable or permanently bricked. Which one you get depends on the step you skipped.
The Production Lockdown Gap
The lockdown step is where good intentions die.
PROVISION --> [TEST: debug open] --> SHIP
|
+-- LCS lock MUST happen HERE
(missed = open device in field)During development and end-of-line test, the debug port has to stay open. You’re flashing images, running diagnostics, reading logs. That’s correct. The problem is the handoff. The LCS transition that locks the device has to happen as the last step before the unit leaves the line, after test passes and after ADAC credentials are provisioned.
“We’ll lock it later” is the phrase that sinks products. There is no later. Once the device is in a customer’s hands, you can’t advance the lifecycle state remotely if APPROTECT was never engaged, and you certainly can’t fix a unit that shipped with an open SWD port. Every one of those units is a readable copy of your firmware and keys sitting in the field.
I’ve seen this miss happen because the lockdown step lived in a separate script that someone forgot to wire into the production line, and because a contract manufacturer ran the test fixture but not the provisioning fixture. The firmware was fine. The signing was fine. The devices shipped debuggable anyway.
Secure provisioning is the step where all three layers get set together, in order, as a verified gate that a unit can’t pass without. If it’s a manual afterthought, it’ll eventually get skipped, and you won’t find out until someone dumps your product and posts the keys.
“But What About RMA and Recovery?”
This is the real reason teams hesitate to lock anything. Lock the device hard and a returned unit is a brick. You can’t attach a debugger, can’t pull logs, can’t reflash. The customer’s failure analysis becomes guesswork.
That fear is legitimate, and it pushes a lot of teams toward leaving the port open “just in case.” Look at what each posture actually costs:
| Posture | Field secure | RMA debug | Risk |
|----------------|--------------|-----------|-------------|
| Open SWD | No | Yes | Full readout|
| Hard lock | Yes | No | Brick on RMA|
| ADAC creds | Yes | Auth only | Balanced |Open SWD gives you easy returns and zero security. A hard lock gives you security and dead RMA units. ADAC is the middle ground that most products should land on.
With ADAC provisioned, the field device is locked to everyone who doesn’t hold the credential. When a unit comes back, your own debug host presents the key, ADAC authenticates it, and you get access to the same hardware an attacker can’t touch.
The practical posture for most BLE products: provision ADAC credentials at manufacturing, advance the LCS into the locked deployment state, and keep the debug credential under the same controls you’d use for signing keys. Returns stay serviceable through the authenticated path, the field stays closed, and you never ship a generic open port.
Where This Fits in IEC 62443
If you’re chasing product certification, debug interface hardening isn’t optional polish. IEC 62443-4-2 covers device-level security requirements, and protecting physical and logical access interfaces sits squarely in the expected control families. An auditor who finds an open SWD port on a deployed device writes it up as a finding.
A debuggable production device fails the basic expectation that an attacker with physical access can’t read out secrets. Locking the port the way described above is table stakes for a certifiable product, not a gold-plated extra. The consulting-heavy framing makes this sound like a compliance maze. At the device level, it’s the lockdown work you should be doing anyway.
Lock It Before It Leaves
Secure boot tells you the code is authentic. It tells you nothing about who can read the chip on a bench, and that’s the door attackers actually use.
Go check your manufacturing flow today. Pull a shipped unit off the shelf and try to attach a debugger. If it answers, your secure boot was never the whole story.
Get APPROTECT, ADAC, and the LCS transition wired into production as a verified gate, with credentials provisioned before lockdown so your recovery path survives. Once the port is shut, your visibility into fielded units shifts to whatever telemetry those devices send home, which is its own design problem worth solving early for any fielded BLE asset deployment.
Hubble Network gives you visibility into locked-down fielded devices over BLE, without leaving a debug port open to get telemetry back. See how it works →