MCTP, PLDM and SPDM Explained: How OpenBMC Management Protocols Work Together

MCTP, PLDM and SPDM are complementary specifications used to manage and secure hardware components through a baseboard management controller (BMC). In an OpenBMC system, MCTP provides a message transport between endpoints; PLDM defines structured commands and data for tasks such as inventory, monitoring and firmware update; and SPDM establishes trust through authentication, measurement exchange and, where supported, protected sessions. They are often deployed together, but they are not interchangeable protocols and none automatically supplies every layer. Understanding the boundaries helps engineers design component discovery, update flows and security checks that work across buses and devices. This article explains the roles, message path, practical uses and integration choices involved in an OpenBMC platform.

The Three Protocol Roles at a Glance

A useful mental model is: MCTP moves management messages, PLDM tells a component what management operation is being requested, and SPDM helps determine whether the component is trusted and what security evidence it can provide. This is a conceptual separation; a real implementation also depends on transport bindings, endpoint capabilities, OpenBMC services and platform policy.

• MCTP (Management Component Transport Protocol): a transport for low-level management messages between platform components. It provides endpoint addressing and message delivery over supported physical bindings such as SMBus/I²C, PCIe VDM or serial links, depending on implementation.
• PLDM (Platform Level Data Model): a family of message formats, commands and data models for platform management. PLDM types cover areas including base discovery, platform monitoring and control, FRU data, firmware update, BIOS control and other defined functions.
• SPDM (Security Protocol and Data Model): a security protocol for discovering security capabilities, negotiating algorithms, authenticating an endpoint, retrieving certificates or measurements, and establishing a secure session when supported.

How MCTP Carries Management Traffic

MCTP separates its message format from the physical link. An endpoint has an MCTP endpoint ID (EID) on an MCTP network. MCTP handles message framing and, when needed, the fragmentation and reassembly of a message across packets. A binding adapts that MCTP traffic to a medium: for example, SMBus/I²C has different framing and arbitration constraints from PCIe vendor-defined messages. Discovery and routing are therefore real integration work, not properties that a PLDM command can solve by itself.

On Linux, the kernel can expose MCTP through AF_MCTP datagram sockets, with binding-specific drivers underneath. OpenBMC deployments may also use daemon and library components to configure networks, discover endpoints, allocate EIDs, and deliver messages to applications. The exact division depends on the platform software version and its chosen components. Engineers should establish who owns EID assignment, bus discovery, routing and endpoint lifecycle before writing upper-layer clients.

What PLDM Adds on Top

PLDM messages identify a PLDM type and command, with request and response payloads defined by the relevant specification. PLDM Base commands support capability discovery and endpoint identity functions. A BMC can then use the supported PLDM types to perform a particular management task. For example, PLDM Platform Monitoring and Control (Type 2) can exchange sensor readings, state information, events and platform descriptors; PLDM Firmware Update (Type 5) defines an update protocol between an update agent and a device component.

PLDM is not itself a physical transport. In a common OpenBMC path, a PLDM application or daemon sends a PLDM message through MCTP to a device. A PLDM library such as libpldm handles encoding and decoding specified message fields, while application logic still decides when to issue commands, how to interpret results, and how to coordinate a system-level workflow. PLDM may also be carried over other transports where the relevant binding exists.

What SPDM Contributes to Device Trust

SPDM addresses a different question: can this endpoint demonstrate an identity and security state that the platform is willing to trust? Depending on negotiated version and capabilities, an SPDM exchange can include version and capability negotiation, algorithm negotiation, certificate or public-key authentication, challenge-response, measurement retrieval and secure-session establishment. A verifier can compare authenticated measurements against reference values or policy. SPDM does not define the product’s trust policy or guarantee that a reported measurement is acceptable; the BMC or a higher-level attestation service must make that decision.

SPDM also needs a transport binding. SPDM over MCTP is common for BMC-to-component communication, but SPDM can be bound to other transports such as PCIe DOE or TCP. Thus, “SPDM over MCTP over SMBus” describes distinct layers: SPDM security messages are carried as MCTP payloads, and MCTP packets are framed for the SMBus/I²C link.

How the Protocols Work Together in OpenBMC

1. Bring up the physical path. The platform enables the required controller and binding, such as an I²C/SMBus interface or PCIe VDM path, and configures the MCTP network.
2. Discover and address the component. MCTP discovery or platform configuration makes the endpoint reachable and assigns or resolves an EID. OpenBMC must associate the endpoint with the correct bus, physical address and expected device role.
3. Check capabilities. A requester uses PLDM Base discovery to learn what PLDM types and commands the endpoint supports. An SPDM requester separately checks supported SPDM versions, capabilities and algorithms.
4. Establish trust where required. The SPDM requester validates the device certificate or key against an appropriate trust anchor, requests a challenge or measurements, and applies local policy. If the component supports secure sessions, the requester can establish one for protected SPDM traffic.
5. Perform management operations. PLDM can provide inventory, telemetry, event handling or a firmware-update state machine. OpenBMC services map the device-level operation into platform policy, logs, D-Bus state and, where appropriate, a higher-level Redfish interface.

These steps can be ordered differently according to platform design. For example, a product may require authentication before accepting firmware-management commands, or it may collect telemetry before full attestation. The important point is to define and enforce the policy explicitly. MCTP reachability alone is not proof of identity, PLDM support alone is not authorization, and a successful SPDM exchange does not itself perform a firmware update.

Applications and Industry Relevance

In servers and data-center platforms, the BMC can use MCTP to reach accelerators, NICs, retimers, storage controllers or power components. PLDM can provide monitoring and inventory or coordinate supported firmware updates. SPDM can authenticate components and obtain measurements for platform security workflows. This becomes especially useful when a system contains components supplied by several vendors, each with different capabilities and lifecycle requirements.

In industrial systems, the same separation can support out-of-band diagnostics and controlled maintenance of modular controllers, communication cards or power subsystems. Automotive and medical products may use related device-management concepts, but the exact standards, safety processes, transport choices and certification requirements differ. Teams should confirm which specifications and profiles their target devices actually implement instead of assuming that “MCTP/PLDM/SPDM support” means a uniform feature set.

PLDM vs SPDM: Management Versus Security

PLDM and SPDM can both use MCTP, but their jobs differ. PLDM expresses management operations and platform data. SPDM provides security exchanges that help authenticate the peer, retrieve security evidence and optionally establish a protected session. One does not replace the other: PLDM firmware update describes update interactions, while SPDM can help establish whether the device is genuine or whether the management channel meets the system’s security policy.

Integration Best Practices and Common Pitfalls

• Build a capability matrix. Record each endpoint’s MCTP binding, EID behavior, supported PLDM types/commands, SPDM version, algorithms, certificate format and measurement support.
• Treat discovery as stateful. Handle endpoint resets, bus changes, EID reassignment, timeouts and stale device records; do not assume an address remains valid forever.
• Keep protocol parsing separate from policy. Use maintained protocol libraries where appropriate, validate lengths and completion codes, and keep authorization and trust decisions in explicit policy code.
• Plan certificate provisioning and rotation. Define trust anchors, manufacturing identity injection, certificate expiry handling, revocation strategy and recovery behavior before deployment.
• Test interoperability and negative cases. Include unsupported commands, malformed or truncated messages, delayed responses, component resets, invalid certificates, measurement mismatches and update interruptions.
• Coordinate security and updates. Specify whether SPDM checks are required before PLDM update, how update integrity and activation are verified, and what happens when attestation or rollback checks fail.
• Expose actionable state. Translate protocol errors into logs and service state with enough context to diagnose bus, endpoint, command and policy failures.
• A frequent mistake is to treat a successful MCTP ping or PLDM response as evidence that the component is trusted. It is only evidence that a message exchange succeeded at that layer. Another is assuming every SPDM-capable device supports the same certificates, algorithms or measurement blocks. Interoperability must be checked against the target component’s supported specification versions and implementation profile.

Implementation Checklist

• Select and document the physical MCTP binding for every component.
• Define EID assignment, discovery, routing and reset behavior.
• Map PLDM types and commands to each device and its firmware lifecycle.
• Set SPDM authentication, algorithm, measurement and session requirements.
• Implement trust-store provisioning and failure handling.
• Validate the full path from bus framing through OpenBMC service behavior.
• Run conformance, fuzz, fault-injection and system recovery tests on target hardware.

Frequently Asked Questions

Is MCTP the same as PLDM?

No. MCTP transports management messages and provides endpoint-level delivery. PLDM defines message types and commands for management tasks. PLDM can use MCTP as its transport.

Does SPDM require MCTP?

No. SPDM is designed to work over different transports. MCTP is one common choice for BMC-to-component communication; other bindings can include PCIe DOE or TCP, depending on the system and supported specifications.

Does SPDM encrypt all PLDM traffic?

No. SPDM can establish a secure session for SPDM-protected communications when supported, but that does not automatically wrap arbitrary PLDM exchanges. The platform must define how management traffic is protected, and implementations must support the required session or secure-transport mechanism.

Can PLDM update firmware without SPDM?

Technically, a PLDM firmware-update flow can be implemented without SPDM. Whether that is acceptable depends on the product’s security requirements. Systems may require authentication or attestation before allowing an update and should also verify image authenticity through their update and boot chain.

What OpenBMC components are involved?

The architecture commonly combines MCTP kernel or daemon support, PLDM services and libraries, SPDM requester or attestation components, and D-Bus integration. The exact components, maturity and feature coverage vary by OpenBMC distribution and platform configuration.

Conclusion

MCTP, PLDM and SPDM form complementary layers in an OpenBMC management design. MCTP provides the message path, PLDM provides structured platform-management operations, and SPDM supplies mechanisms for component authentication, measurement and secure sessions. A production implementation has to connect those protocol capabilities to real platform policy: discovery and addressing, device support, trust provisioning, update authorization, fault handling and service-level visibility. Conclusive Engineering’s OpenBMC work spans these protocol and integration layers, including MCTP, PLDM, SPDM and BMC application interfaces. For projects involving a custom BMC platform or device-management flow, see our OpenBMC Ecosystem Services.