MIPI Security Specification for Debug
Developed by: Debug Working Group
Adds a security layer to the MIPI debug architecture, enabling remote debug of target systems by protecting MIPI “Debug Over” interfaces from cybersecurity threats and misuse
Quick Facts
-
Key Highlights
- Adds a security layer to the MIPI debug architecture, protecting debug data from cybersecurity threats, tampering and unauthorized access
- Enables secure, remote debugging of production devices deployed “in the field”
- Security is applied “end-to-end” from the debug test system to the target system
- Transport layer- and network topology-agnostic debug security can be applied over interfaces such as MIPI I3C, USB and PCIe, across interface bridges and other intermediary network components
- Leverages industry-standard DMTF SPDM protocol
-
MIPI Debug Over (MDO) Specifications
The debug specification portfolio includes the "MIPI Debug Over” (MDO) family of specifications, which define how debug and trace data is transmitted to and from a debug and test system over a functional network. MIPI debug and trace specifications are available for download and use by the public and the open source community. MIPI members enjoy benefits including access to relevant licenses and opportunities to participate in development activities, interoperability workshops and other events.
-
Physical Layer
Debug security is physical layer-agnostic and can be applied over interfaces such as MIPI I3C, USB and PCIe.
Get the Specification
-
Current Version
MIPI Security Specification for Debug v1.0 (November 2024)
Member version
Industries
Overview
The MIPI Security Specification for Debug, developed to accompany the existing portfolio of MIPI “Debug Over” specifications, defines a method to establish and manage secure debug communication sessions between a Debug and Test System (DTS) and the Target System (TS).
The aim of the specification is to enable a DTS to securely debug a production TS located in the field (i.e., outside of a test lab), closer to the actual end user state and in a potentially hostile environment, where problems are typically more difficult to debug and reproduce. To enable debugging in such environments, the following security objectives must be met: Authenticity – by establishing mutual trust between debug test system and target device, ensuring only authorized entities can establish debug sessions, and guaranteeing debug data comes from the expected target device; Confidentiality – through the provision of message encryption; and Integrity – by the provision of message authentication.
To achieve these objectives, the level of protection applied to debug interfaces must go far beyond traditional physical protection mechanisms such as burying debug traces on system boards. A trusted relationship must be established between the DTS and TS, and the data exchanged between DTS and TS needs to be protected against tampering and snooping. Specifically, the entire data path between the physical debug tool (i.e., DTS) and the package pins of the component being debugged (i.e., TS) through any cabling, connectors, board routing and bridging must be secured ‘end-to-end’. Each endpoint must recognize and permit the other to establish a debug session (i.e., the endpoints must mutually authenticate), and the full communication path between the DTS and TS must be integrity protected and encrypted.
Adding a Secure Layer to the MIPI Debug Architecture
MIPI Debug specifications use a layered approach to build a debug architecture. Debug functionality and/or applications are built on top of debug-specific network adaptors and protocols, which themselves are built over a network infrastructure. This layering allows for modularity and reuse of MIPI Debug specifications.
The MIPI Security Specification for Debug adds an additional layer to the existing architecture, providing the necessary message encryption and message authentication of MIPI debug interfaces.
The specification places the secure messaging layer between the network adaptors and the transport layers to be agnostic to the debug transport interface and any bridges or other components used to create the transport network. This placement allows for complete protection between the DTS and the TS; even if the communication channel between the DTS and the TS changes interfaces and goes through bridges, the communication is still protected ‘end-to-end’ through all the interfaces and bridges.
The diagram below shows a particular example implementation where the security layer is added and management of the secure messaging is done in-band over the MIPI SneakPeek Protocol (SPP).

The specification uses an existing industry-standard protocol, the DMTF Security Protocol and Data Model (SPDM), to define a common set of messaging to perform mutual authentication and set up of a secure communications channel between the DTS and TS. Message encryption and authentication for confidentiality and integrity protection is provided, to ensure all message transfers between the DTS and TS are protected from any malicious actors on the communication channel. These capabilities are agnostic to the debug transport interface being used (e.g., I3C, USB, PCIe) and can be implemented to create a platform-wide communication protection mechanism.
Secure Communications Manager (SCM)
The specification defines how a DTS establishes, manages and uses a secure debug communications channel. It uses a common “secure protocol” and flows to control and manage secure communication, with the protocol running ‘in-band’ over the desired debug interface. This means control and management of the secure debug interface does not have to be done via a parallel or side-channel interface, benefiting solution enabling and validation.
These new security capabilities within the system are managed through the definition of a secure communications manager (SCM), a key new component of the MIPI Debug security architecture. The SCM comprises:
- Security Agent: A hardware, software and/or firmware component that processes the SPDM messages and generates session keys associated with the created secure session, as well as other materials such as the initialization vector (IV) for the message encryption and/or message authentication function.
- Message Encryption and/or Message Authentication Function: A hardware, software and/or firmware componentperfroming the necessary cryptographic algorithms on the debug communication. It handles the secure message formatting and holds all the necessary keys and other material for message encryption and/or message authentication.
- Secure Communication Management Message Path: Either an in-band or an out-of-band path to the existing DTS to TS connection, this is the path between the secure messaging layer and the secure communication management infrastructure.
MIPI Security Specification for Debug v1.0 was developed by the MIPI Debug Working Group and was released in January 2026.



