SPDM Protocol Clarification Questions (v1.0, v1.1, v1.2)

[PrakashK94]

I have a few conceptual questions related to the SPDM protocol. These questions are not related to SPDM implementation or code, but to understanding the security goals and use cases across SPDM versions 1.0, 1.1, and 1.2.

SPDM 1.0 Questions
SPDM 1.0 provides device discovery, authentication, and attestation capabilities.

1. Security Scope

• My understanding is that SPDM 1.0 does not protect runtime data traffic, but instead focuses on device identity and trust establishment. Is this correct?

2. Identity

• Does “identity” in SPDM 1.0 mean identifying the device vendor and device model using the certificate chain retrieved via GET_CERTIFICATE?

3. Authentication

• Is authentication achieved by validating:
  - the responder’s certificate chain, and
  - the signatures returned in CHALLENGE_AUTH and measurement responses?

4. Attestation & Platform Policy

• Is attestation intended to allow the requester to:
  - compare received measurements against known-good (reference) measurements, and
  - make a platform-specific policy decision (e.g., allow normal operation, restrict functionality, log an error, or trigger firmware recovery)?
• Are enforcement actions (lockdown, recovery, logging, etc.) outside the scope of SPDM and left to the platform firmware or management software?

5. Use Case

• Is the primary use case of SPDM 1.0 establishing trust in a device before it is used, rather than protecting ongoing communication?

SPDM 1.1 Questions
SPDM 1.1 introduces secure session establishment.

1. Secure Sessions

• Once a secure session is established, is the communication:
  - confidential (encrypted),
  - integrity-protected, and
  - protected against replay and tampering?

2. Threat Model

• Assuming correct cryptographic implementation and key protection, is it correct that:
• a third party cannot tamper with messages or firmware update payloads exchanged inside a secure session?

3. Use Case

• Is SPDM 1.1 primarily intended for:
  - secure firmware updates,
  - secure management commands, and
  - protected measurement retrieval after trust has been established?

SPDM 1.2 Questions
SPDM 1.2 introduces certificate provisioning and update.

1. Certificate Provisioning
   - SPDM 1.2 allows writing certificate chains into responder slots. What are the intended scenarios for this capability?
2. Manufacturing vs Field Update
   - While devices typically have certificates provisioned during secure manufacturing (e.g., SLOT0), is SPDM 1.2 designed to support:
   - certificate rotation,
   - ownership transfer,
   - lifecycle management, or
   - post-manufacturing certificate updates in the field?
3. Use Case
   • What are the real-world deployment scenarios where SPDM 1.2 certificate write capability is expected to be used?

[steven-bellock]

See the SPDM whitepaper (https://www.dmtf.org/sites/default/files/standards/documents/DSP2058_1.3.0.pdf) for answers to questions like these.

My understanding is that SPDM 1.0 does not protect runtime data traffic, but instead focuses on device identity and trust establishment. Is this correct?

Broadly yes.

Does “identity” in SPDM 1.0 mean identifying the device vendor and device model using the certificate chain retrieved via GET_CERTIFICATE?

That, and the identity of the instance of the device itself, assuming the manufacturer generates unique keys for each device.

Is authentication achieved by validating:

• the responder’s certificate chain, and
• the signatures returned in CHALLENGE_AUTH and measurement responses?

Broadly yes. For certificate chains, the relying party should establish a trust relationship with the device manufacturer. Once established then the relying party acquires the manufacturer's root certificates and uses them to validate the device's certificate chain.

Is attestation intended to allow the requester to:

• compare received measurements against known-good (reference) measurements, and
• make a platform-specific policy decision (e.g., allow normal operation, restrict functionality, log an error, or trigger firmware recovery)?

Broadly yes.

Are enforcement actions (lockdown, recovery, logging, etc.) outside the scope of SPDM and left to the platform firmware or management software?

Broadly yes. HeartBeat is one exception, where the SPDM specification is normative on what Responders do when a HeartBeat times out.

Is the primary use case of SPDM 1.0 establishing trust in a device before it is used, rather than protecting ongoing communication?

Broadly yes.

Once a secure session is established, is the communication:

• confidential (encrypted),
• integrity-protected, and
• protected against replay and tampering?

That depends on the endpoints' capabilities, mainly MAC_CAP and ENCRYPT_CAP. If both endpoints support both of those capabilities then all three of those bullet points are true.

Assuming correct cryptographic implementation and key protection, is it correct that:
a third party cannot tamper with messages or firmware update payloads exchanged inside a secure session?

That is incorrect. Messages may be tampered with, even within a secure session. However, that tampering would be detected by, at least, the receiving endpoint.

Is SPDM 1.1 primarily intended for:

• secure firmware updates,
• secure management commands, and
• protected measurement retrieval after trust has been established?

SPDM 1.1 is primarily 1.0 plus secure sessions.

SPDM 1.2 allows writing certificate chains into responder slots. What are the intended scenarios for this capability?

This allows entities other than the device manufacturer to endorse the device. See also https://opencomputeproject.github.io/Security/device-identity-provisioning/HEAD/#introduction

• While devices typically have certificates provisioned during secure manufacturing (e.g., SLOT0), is SPDM 1.2 designed to support:
• certificate rotation,
• ownership transfer,
• lifecycle management, or
• post-manufacturing certificate updates in the field?

Broadly yes. SPDM supports those directly or provides the building blocks for things like ownership transfer.

[PrakashK94]

Is SPDM being used in broader scale? Like in server platforms/client platforms etc?

[steven-bellock]

Yes, server platforms are currently the predominant landscape in which SPDM is used.

[PrakashK94]

1. Adoption Beyond Servers
“You mentioned server platforms are the predominant area using SPDM today. Are there any ongoing efforts or roadmaps to bring SPDM into client platforms, IoT, or edge devices?”

2. SPDM Version / Maturity
“Which SPDM version (1.0 / 1.1 / 1.2 / 1.3) is typically implemented in these server platforms today? Are customers moving toward SPDM 1.3 adoption?”

3. Integration with Existing Security Frameworks
“How is SPDM being integrated with existing platform security mechanisms like DICE/RIoT, TCG TPM, or Intel PFR?”

4. Use Cases
“In server deployments, what are the most common SPDM use cases you see—attestation, measurement, key exchange, device authentication, or firmware updates?”

5. Interoperability Challenges
“Are there known interoperability challenges between vendors implementing SPDM, and how is the industry addressing them?”

6. Hardware vs. Firmware Implementation
“Is SPDM typically implemented in hardware (BMC, NIC, accelerator) or firmware/software? What’s the trend?”

7. Deployment Readiness / Tooling
"What tooling or validation frameworks exist today to help vendors test SPDM compliance and interoperability?”

8. Certification or Compliance
"Is there any industry certification or compliance program emerging around SPDM implementations?”

9. Performance Considerations
"Are there measurable performance impacts when enabling SPDM in large‑scale server deployments?”

10. Cloud Vendor Adoption
Are hyperscalers (AWS, Azure, GCP, Meta) actively adopting SPDM in their hardware supply chain?”

11. Long‑Term Adoption Trends
“Do you foresee SPDM becoming a mandatory requirement in future server or accelerator platforms?”

12. Software Ecosystem Support
“How mature is the software ecosystem support for SPDM—such as BMC firmware, NIC vendors, and accelerator cards?”

13. Missing Features
“Are there any gaps in the current SPDM spec that the industry is trying to address in future revisions?”