Request for nRF54L15 JTAG Lock/Unlock Procedure

[H538063]

Hi Team,

We require the detailed procedure for locking and unlocking JTAG access on the nRF54L15 device. Specifically, we are looking for:

• Steps to enable JTAG protection (lock/debug disable)
• Procedure to recover or unlock JTAG access
• Any prerequisites or considerations (power cycle, erase behavior, firmware impact, etc.)
• Impact of locking on firmware updates and debugging
• Recommended best practices for secure production configuration

This information is needed to correctly implement and validate JTAG security handling in our product.

Thanks

Haritha

[Øyvind]

Hello Haritha, 

Below is the answer from our AI chatbot, and what the documentation explicitly covers for nRF54L15. Where something is not fully specified, I’ll point it out.

---

1. How to lock/disable JTAG (enable protection)

On nRF54L15, JTAG/SWD debug access is controlled by:

• UICR.APPROTECT – non-secure debug access (Cortex‑M33 AHB‑AP)
• UICR.SECUREAPPROTECT – secure debug access
• TAMPC.PROTECT.DOMAIN[0].DBGEN/NIDEN/SPIDEN/SPNIDEN – software control of debug enable signals
• Optional UICR.AUXAPPROTECT for AUX‑AP (VPR) [Debug access port].

Hardware-side locking (production-style)

To lock the device from the host PC (recommended for production):

1. Enable non-secure AP-Protect (APPROTECT):

   nrfutil device protection-set All
   

   This writes Enabled to UICR.APPROTECT and hard-resets the device, enabling hardware AP-Protect. [nRF54L AP-Protect]

2. Enable Secure AP-Protect (SECUREAPPROTECT) if you also want to block secure debug:

   nrfutil device protection-set SecureRegions
   

   This writes Enabled to UICR.SECUREAPPROTECT and hard-resets the device. [nRF54L AP-Protect]

3. (Optional but common in final products) Enable ERASEPROTECT to block ERASEALL:

   • Write 0x50FA50FA to UICR.ERASEPROTECT[0].PROTECT0 (0x00FFD060) and PROTECT1 (0x00FFD07C). [Enabling device protection]
   • This blocks RRAMC ERASEALL and CTRL‑AP.ERASEALL. [Enabling device protection; Debug ERASEALL]

4. Reset the device (pin reset or power cycle) so the new UICR values take effect. [Enabling device protection]

After this, the access ports are locked; JTAG/SWD debug is effectively disabled unless you perform the appropriate erase/unlock sequence.

Note: nRF54L15 supports UICR.ERASEPROTECT, which can prevent ERASEALL when AP‑Protect is enabled. [nRF54L AP-Protect]

Software-side locking (firmware behavior)

In nRF Connect SDK, you control whether firmware opens or keeps AP-Protect locked:

• CONFIG_NRF_APPROTECT_LOCK=y
  MDK locks AP-Protect in SystemInit() at every boot and prevents CPU from disabling it. [nRF54L AP-Protect Kconfig]
• CONFIG_NRF_SECURE_APPROTECT_LOCK=y
  Same for Secure AP-Protect. [nRF54L Secure AP-Protect Kconfig]

For a fully locked production image, you typically enable these in the first image (e.g., secure bootloader) so firmware never opens the debug port. [nRF54L AP-Protect Kconfig]

---

2. How to unlock / recover JTAG access

If ERASEPROTECT is not enabled

You can fully unlock by issuing ERASEALL via nRF Util:

nrfutil device recover

• This issues ERASEALL, waits for completion, and on nRF54L15 also programs firmware that corresponds to CONFIG_NRF_APPROTECT_DISABLE=y and CONFIG_NRF_SECURE_APPROTECT_DISABLE=y. [nRF54L AP-Protect]
• After this, AP-Protect and Secure AP-Protect are disabled and the device is debug‑open.

You can also “force AP-Protect to be disabled after hard reset” by the same nrfutil device recover command; the device is automatically unlocked after erase. [nRF54L AP-Protect]

If ERASEPROTECT is enabled

Here the documentation is explicit: any value other than “Unprotected” in UICR.ERASEPROTECT disables ERASEALL (both RRAMC and CTRL‑AP). [Debug ERASEALL; CTRL‑AP erase protection]

• With ERASEPROTECT enabled, ERASEALL cannot be performed, so you cannot simply “recover” the device by erase. [How to unlock nRF54L10]
• Disabling ERASEPROTECT requires a coordinated key write from both debugger and CPU to ERASEPROTECT.DISABLE registers, followed by an automatic erase. [CTRL‑AP erase protection]
• If you have locked ERASEPROTECT and do not have firmware support for this handshake, the device is effectively not recoverable by normal means; this is intentional as a final‑production security measure. [How to unlock nRF54L10]

So, for a recoverable product, you must design and validate a firmware‑assisted ERASEPROTECT disable path before enabling ERASEPROTECT in production. The knowledge sources do not provide a full reference implementation of that handshake.

---

3. Prerequisites and considerations

Resets / power cycles

• UICR‑based protection (APPROTECT, SECUREAPPROTECT, ERASEPROTECT) takes effect only after a device reset (pin reset, power‑on, brownout, or watchdog reset). [Debug access port]
• After CTRL-AP.ERASEALL completes, the access port remains open until one of those resets occurs, at which point protection is re‑applied according to UICR and TAMPC. [Debug access port]

ERASEALL behavior

• nrfutil device recover issues ERASEALL and then flashes firmware that opens AP-Protect (sets the “disable” Kconfig behavior). [nRF54L AP-Protect]
• If UICR.ERASEPROTECT is set (Protected), ERASEALL is disabled and nrfutil device recover will fail. [Debug ERASEALL; CTRL‑AP erase protection]

Interaction with firmware

• On every reset, internal boot logic loads AP-Protect configuration from UICR, then firmware may further open/lock AP-Protect via TAMPC depending on Kconfig (CONFIG_NRF_APPROTECT_DISABLE, CONFIG_NRF_APPROTECT_LOCK, etc.). [AP-Protect flow; nRF54L AP-Protect Kconfig]
• To keep AP-Protect or Secure AP-Protect disabled after hard reset, firmware must open the debugger signals in TAMPC; in nRF Connect SDK this is handled by CONFIG_NRF_APPROTECT_DISABLE and CONFIG_NRF_SECURE_APPROTECT_DISABLE (both y by default). [nRF54L AP-Protect]

---

4. Impact on firmware updates and debugging

From the docs:

• With AP-Protect and Secure AP-Protect disabled (default Kconfig), you can start debugging and programming without extra steps. [nRF54L AP-Protect Kconfig]
• With AP-Protect enabled and locked (CONFIG_NRF_APPROTECT_LOCK / CONFIG_NRF_SECURE_APPROTECT_LOCK and UICR set to protected), external debug access is blocked; firmware updates via JTAG/SWD are not possible unless you first perform ERASEALL (and ERASEPROTECT is not enabled). [nRF54L AP-Protect Kconfig; Debug access port]
• If you also enable ERASEPROTECT, then neither debug nor ERASEALL is possible without the firmware+debugger key handshake; if that is not implemented, the device cannot be recovered. [Enabling device protection; How to unlock nRF54L10]

The knowledge sources do not describe the impact on other update channels (e.g., OTA) in detail, but any update path that relies on JTAG/SWD will be blocked when AP-Protect is locked.

---

5. Recommended best practices for secure production

Based on the provided docs:

1. Use UICR + firmware together

   • Configure UICR.APPROTECT / UICR.SECUREAPPROTECT for hardware protection.
   • Use CONFIG_NRF_APPROTECT_LOCK / CONFIG_NRF_SECURE_APPROTECT_LOCK in the first image to ensure firmware does not reopen debug. [nRF54L AP-Protect Kconfig; Debug access port]

2. Lock UICR in final production

   • “For devices in a production environment, it is highly recommended to lock the UICR.APPROTECT and UICR.SECUREAPPROTECT registers to prevent unauthorized access. If configured this way, access port protection cannot be disabled without erasing NVM.” [nRF54L AP-Protect]

3. Be very careful with ERASEPROTECT

   • Only enable UICR.ERASEPROTECT once you have a tested recovery/upgrade strategy that uses the ERASEPROTECT.DISABLE handshake from both debugger and firmware.
   • Nordic explicitly warns: if both APPROTECT and ERASEPROTECT are active, the device cannot be recovered without a proper software solution. [Enabling device protection]

4. Use nRF Util flows for production programming

   • Nordic provides specific guides for:
     • Enabling device protection on nRF54L
     • Disabling AP-Protect on nRF54L
     • Checking AP-Protect status
       [nRF54L AP-Protect; Enabling device protection]

5. Plan a debug/unlock policy

   • During development: keep CONFIG_NRF_APPROTECT_DISABLE=y (default) and UICR unprotected.
   • For field returns / RMA: rely on nrfutil device recover (no ERASEPROTECT) to erase and reopen debug.
   • For high‑security SKUs: enable ERASEPROTECT only if you accept that devices may become unrecoverable without the key‑based disable flow.

Kind regards,
Øyvind

[H538063]

Hi Øyvind,

To enable JTAG lock, we followed two steps:

1. Enable Non-Secure AP-Protect (APPROTECT):

   nrfutil device protection-set All

   This command writes Enabled to UICR.APPROTECT and performs a hard reset, thereby activating hardware AP-Protect.

2. Enable Secure AP-Protect (SECUREAPPROTECT): (optional, for blocking secure debug access)

   nrfutil device protection-set SecureRegions
   

   This writes Enabled to UICR.SECUREAPPROTECT and performs a hard reset.

Issue:
Even after enabling both protections, I am still able to perform erase and write operations using nRF Connect for Desktop v5.2.0.

Concern:
Is there any possibility for an attacker to access the device via JTAG and read the firmware despite these protections?

Thanks

Haritha

[Øyvind]

H538063 said:

Even after enabling both protections, I am still able to perform erase and write operations using nRF Connect for Desktop v5.2.0.

Can you please elaborate more on what this means? What is your setup? 

[H538063]

Hi Øyvind,

• SoC: nRF54L15 (CPUAPP)
• SDK: nRF Connect SDK v3.1.0
• Tools: nRF Connect for Desktop v5.2.0, nrfutil

We have enabled both APPROTECT and SECUREAPPROTECT on our nRF54L15 custom board using:

nrfutil device protection-set All
nrfutil device protection-set SecureRegions

Issue: Despite JTAG lock being enabled, we are still able to perform ERASEALL and firmware write operations using nRF Connect for Desktop Programmer v5.2.0.

Once JTAG is locked (APPROTECT enabled), no operations should be possible via the debug interface — including erase and write — unless the device is explicitly unlocked using the proper unlock command/key.

In our product (medical/industrial BLE device), an attacker with physical access could:

1. Perform ERASEALL (destroying original firmware)
2. Flash custom firmware onto the device
3. Use that firmware to access external peripherals (SPI flash, sensors, GPIO expander) connected to the nRF54L15

This is a physical attack vector that we need to mitigate at the hardware level.

1. Does nRF54L15 support ERASEPROTECT (preventing mass erase without an unlock key)?
2. If so, what is the correct command/procedure to enable it?
3. Is there a way to configure a device-specific unlock key so that only authorized personnel can unlock the JTAG?
4. What is the recommended configuration for production devices that need full JTAG lockdown?

Thanks

Haritha

[Øyvind]

Hello,

From the nRF54L15 datasheet Control Access Port:

Access port protection (APPROTECT) blocks the debugger from accessing the AHB-AP and prevents read and write access to all CPU registers and memory-mapped addresses. To enable access port protection for both secure and non-secure modes, use the registers UICR.SECUREAPPROTECT and UICR.APPROTECT.

Erase protection (ERASEPROTECT) protects the entire non-volatile memory, SICR, and UICR from being erased. Erase protection is enabled through UICR and disabled through cooperation between the firmware and debugger. For more information about disabling erase protection, see Erase protection.

H538063 said:

In our product (medical/industrial BLE device), an attacker with physical access could:

1. Perform ERASEALL (destroying original firmware)
2. Flash custom firmware onto the device
3. Use that firmware to access external peripherals (SPI flash, sensors, GPIO expander) connected to the nRF54L15

This is expected behavior by design, not a bug. Here's why:

When only APPROTECT is enabled (without ERASEPROTECT), the ERASEALL command via CTRL-AP is still permitted. APPROTECT blocks debugger read/write access to CPU registers and memory-mapped addresses, but the CTRL-AP ERASEALL operation remains available as the recovery mechanism. [Only APPROTECT enabled]

Specifically:

• APPROTECT → blocks debugger access to CPU registers and memory, but CTRL-AP ERASEALL still works.
• ERASEPROTECT → additionally blocks the ERASEALL functionality itself.

So if you want to prevent ERASEALL and firmware write operations via the debug interface, you need to enable both APPROTECT and ERASEPROTECT. [Managing AP-Protect]

Important warning: If both APPROTECT and ERASEPROTECT are enabled, the device cannot be recovered without firmware that supports the ERASEPROTECT unlock key mechanism. When both are enabled, unlocking requires both the debugger and the on-chip firmware to write the same non-zero 32-bit KEY value to ERASEPROTECT.DISABLE. [APPROTECT and ERASEPROTECT enabled]

To achieve your goal (blocking all debug interface operations including erase and write), you must:

1. Enable ERASEPROTECT in addition to APPROTECT by writing a non-0xFFFFFFFF value to UICR.ERASEPROTECT.
2. Ensure your firmware implements the ERASEPROTECT key-based unlock mechanism if you ever need to recover the device. [Enabling device protection]

Kind regards,
Øyvind