Term · Safety & Security
Secure debug
Controlling access to JTAG, trace and other debug interfaces so they are unlocked only after cryptographic authentication, or permanently disabled by fuses once a device leaves development.
Open debug ports otherwise hand an attacker full control.
- Also known as
- Debug lock, Authenticated debug
- Type
- Term
- Domain
- Safety & Security, Security architecture
Notes
Challenge-response unlock is now preferred over permanent fusing so failed field units can still be analysed.
Overview
Secure debug is the set of hardware and firmware controls that decide who may use a chip's debug and trace interfaces, when, and with which privileges. Debug ports such as JTAG and SWD can halt processors and read or write any memory, so leaving them open in a shipped product hands an attacker control of the device. Secure debug keeps that power available to authorised engineers during development and failure analysis while closing it to everyone else.
How it works
The simplest control is a lock. A fuse, one-time programmable bit or protected configuration register disables the debug access port when the device leaves the factory, sometimes with a recovery path that first erases all flash so secrets cannot be read out. Nordic's nRF devices, for example, offer access port protection that blocks debugger access to processor registers and memory, can be reset only by a full erase, and on newer parts is re-applied by firmware at every boot.
Authenticated debug goes further and lets a trusted party reopen debug on a locked part. In Arm's Authenticated Debug Access Control (ADAC) specification, a Secure Debug Authenticator running in a trusted context such as the boot ROM or bootloader issues a challenge through a debugger mailbox that stays reachable even when debug is locked. The debug host answers with a signed token and a chain of certificates; the target checks the signatures, intersects the requested permissions with limits set in each certificate and in the chip, and only then enables the matching debug signals. Certificates can be restricted to one device, one device family or one lifecycle state, and debug is usually opened only after a reset so secrets in memory are not exposed.
Fine-grained designs separate secure and non-secure debug, so an application developer can debug their own code without reaching keys held by the security subsystem.
Examples
- An nRF5340 shipped with access port protection enabled, which a developer can clear only with an erase-all command that wipes flash, RAM and configuration.
- Trusted Firmware-M running an ADAC Secure Debug Authenticator in its bootloader to grant debug only to holders of valid certificates.
- Nordic's Secure AP-Protect on nRF5340 and nRF91 Series devices, which blocks debugging of the secure processing environment while leaving non-secure code debuggable.
- A failure analysis lab reopening debug on one returned part with a certificate bound to that device's identifier.
Related terms
Part of the Safety & Security glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 5 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary