SPDM certificates must be X.509 version 3, encoded in ASN.1 DER. PEM is not transmitted inside SPDM messages. Certificate path validation follows RFC 5280 in full.

The certificate chain runs root to leaf, i.e., each Root CA issues the Subordinate CA (Sub CA) certificate, and the Sub CA issues the leaf, which contains the public key used for SPDM authentication. A device can hold up to eight certificate-chain slots, numbered 0 through 7. Slot 0 is the primary identity slot and must always contain a valid DeviceCert or AliasCert chain. Slots 1 through 7 may carry GenericCert entries for additional purposes.

One detail specific to SPDM is that the chain is delivered with the hash of the root certificate prefixed to the DER-encoded certificate chain. The Requester uses this hash to verify the root independently against its trust store before validating the rest of the chain.

Mandatory X.509 fields

For DeviceCert and AliasCert certificates, SPDM identifies following certificate fields as mandatory

Basic Constraints- must correctly distinguish CA certificates from end-entity leaf certificates at every level of the chain
X.509 Version- must be v3
Serial Number- must be present and unique within each CA
Signature Algorithm- identifies the algorithm used to sign the certificate
Issuer- identifies the CA that signed it
Subject- identifies the certificate holder
Validity- notBefore and notAfter; see the validity section below
Subject Public Key Information- the public key and its algorithm
Key Usage- must include digitalSignature for authentication leaf certificates

For GenericCert entries in Slots 1 through 7, SPDM imposes fewer requirements. Basic Constraints, Version, Serial Number, and Subject Public Key Information remain mandatory, while other fields are optional from the SPDM perspective. RFC 5280 and your own organizational policies may still impose stricter requirements on GenericCert.

Basic Constraints

Basic Constraints must correctly label every certificate in the chain. Getting this wrong is one of the most common causes of SPDM chain validation failure.

Normal SPDM leaf certificate: CA = FALSE. This is the end-entity certificate used directly for authentication.
Root CA: CA = TRUE.
Intermediate CA: CA = TRUE.
Device Certificate CA in the AliasCert model: CA = TRUE. This is the on-device CA. It must also carry an appropriate pathLengthConstraint to limit how many additional CA certificates can be chained below it.

Key Usage

For an SPDM authentication leaf certificate, key usage must be set as digitalSignature. The device signs the SPDM challenge and the session transcript using its private key, so digitalSignature is what authorizes that operation.

CA certificates in the chain must carry keyCertSign and, where appropriate, cRLSign, consistent with their role per RFC 5280. An intermediate CA missing keyCertSign will fail path validation.

Carrying device identity in the Subject Alternative Name

SPDM recommends using the otherName field in the Subject Alternative Name extension to carry structured device information. The DMTF-defined format represents the device as:

OID: 1.3.6.1.4.1.412.274.1 (DMTF device information)
Value: Manufacturer : Product : SerialNumber
Example: ACME Corp : GPU-X100 : SN123456789

This binding is meaningful because it ties the cryptographic key not just to a generic subject name but to a specific hardware manufacturer, product line, and serial number. When an AI orchestrator or a BMC retrieves the certificate chain, it can verify that the device it is talking to is the specific physical device it has on record, not just some device from the right manufacturer.

Certificate validity

Slot 0 is the primary device identity slot and its validity policy is different from the other slots.

For a long-lived, immutable Slot 0 identity, a manufacturing-installed certificate that is expected to persist for the device’s entire operational lifetime, the specification discusses using 99991231235959Z as the notAfter value. This signals no defined expiration date. Most hardware devices have no reliable real-time clock, and the identity may need to outlast 10, 15, or 20 years of deployment. notBefore is typically set to the certificate creation or manufacturing date.

Slots 1 through 7 can carry certificates with conventional expiry dates. This gives PKI teams a manageable operational lifecycle for mutable and operational credentials: the permanent hardware identity in Slot 0 remains stable, while shorter-lived certificates in other slots can be renewed, replaced, and revoked with standard tools and timelines.

SPDM DMTF OIDs

SPDM defines six OIDs in the DMTF namespace. Your CA must be configured to issue certificates with these OIDs where appropriate. None of them are in the default OID sets of most commercial CA platforms; they all require explicit configuration.

Extended Key Usage OIDs

SPDM defines two EKU OIDs for authentication. These are optional in the base SPDM profile but strongly recommended for any deployment where you want to enforce that certificates are explicitly authorized for SPDM use.

Responder Authentication: 1.3.6.1.4.1.412.274.3, placed in the leaf certificate of a hardware device acting as an SPDM Responder. A GPU, NPU, DPU, or NIC presenting this EKU is declaring that its certificate is authorised for SPDM Responder authentication specifically.
Requester Authentication: 1.3.6.1.4.1.412.274.4, placed in the certificate presented by an SPDM Requester during mutual authentication. A device that participates in mutual authentication may need both EKUs. A device acting only as a Responder needs only the Responder EKU.

Hardware identity and mutable certificate OIDs

These two OIDs encode a security-relevant distinction that SPDM Requesters and trust management systems can act on programmatically.

Hardware Identity: 1.3.6.1.4.1.412.274.2, marks the certificate that represents the permanent device identity. In the AliasCert model, this OID belongs on the Device Certificate CA, not on the mutable alias certificates below it. A Requester enforcing a hardware-bound policy can check for this OID to confirm it is communicating with a manufacturing-installed permanent identity.
Mutable Certificate: 1.3.6.1.4.1.412.274.5, marks certificates that represent mutable state: firmware version, configuration, or an operational key generated after manufacturing. Alias certificates carry this OID. The Device Certificate CA and IDevID-style permanent certificates should not.
SPDM extension container: 1.3.6.1.4.1.412.274.6, a container extension for additional structured SPDM-specific data when the certificate needs to carry content beyond what the other OIDs represent.

The Three Certificate Models

The following are the three certificate models:

DeviceCert model

The DeviceCert model is the straightforward option. The device certificate is the leaf. The private key corresponding to that certificate lives inside the device and is used directly for SPDM authentication. The chain runs from Root CA down through any intermediate CAs to the device leaf with CA=FALSE.

Use DeviceCert when the device has a permanent key that performs authentication directly, and you do not need to separate the hardware identity from operational state. It is simpler to deploy and simpler to manage.

AliasCert model and the Device Certificate CA

The AliasCert model introduces an on-device CA. The enterprise PKI issues a Device Certificate CA to the device a certificate with CA=TRUE, the Hardware Identity OID (1.3.6.1.4.1.412.274.2), and an appropriate pathLengthConstraint. This Device Certificate CA represents the permanent hardware identity installed at manufacturing time.

The device then uses the Device Certificate CA key to sign alias certificates locally. Alias certificates represent mutable state: the current firmware version, the device’s boot configuration, or a freshly generated operational key. They carry the Mutable Certificate OID (1.3.6.1.4.1.412.274.5) and have shorter validity periods. The actual SPDM authentication uses the alias leaf, not the Device Certificate CA directly.

The trust chain still flows back to the Root CA: the Root CA trusts the Device Certificate CA, which signs the alias certificate; therefore, the alias is linked to the trusted hardware identity. The enterprise PKI manages everything above the Device Certificate CA. The device manages the alias layer below it.

Why the AliasCert model matters: It separates two identities with very different lifecycles. The permanent hardware identity needs to be extremely stable it represents the physical device and should not change unless the hardware changes. The operational identity needs to be flexible, it should reflect current firmware state, and it should be able to rotate when firmware updates or security-state changes. DeviceCert conflates these two identities into one. AliasCert separates them cleanly.

Note: The Device Certificate CA must not be treated as a general-purpose enterprise issuing CA. It is scoped to that specific device. Use pathLengthConstraint and, where appropriate, name constraints to limit its authority to keys on that device only.

GenericCert model

GenericCert is for Slots 1 through 7 when the device supports multiple asymmetric key pairs and needs certificates for separate purposes. Slot 0 must always use DeviceCert or AliasCert. GenericCert has fewer identity-specific requirements from SPDM but must still satisfy RFC 5280 and your organizational policies.

Aligning your enterprise PKI with SPDM

SPDM provides the runtime mechanism for proving, “This device possesses the private key associated with a certificate trusted by my platform”. PKI provides the foundation for deciding factors such as who issued that identity, what hardware it represents, what it is authorized to do, how long it is trusted, and how that trust is removed.

Build a dedicated SPDM CA hierarchy

Keep SPDM device certificate issuance separate from your general-purpose TLS and user CA hierarchy. A dedicated SPDM Device Issuing CA under an offline SPDM Root CA gives you tighter control over device profiles, manufacturing enrollment, and trust-anchor distribution. For supply-chain environments, separate issuing tiers or separate certificate slots can map to manufacturers, platform integrators, and enterprise customers individually.

Define certificate profiles for every SPDM certificate type

One profile is not enough. Define a separate profile for each certificate type that will appear in an SPDM chain:

SPDM Device Authentication Leaf: CA=FALSE, digitalSignature, Responder EKU (1.3.6.1.4.1.412.274.3), 99991231235959Z validity for Slot 0
SPDM Device Certificate CA: CA=TRUE, keyCertSign, Hardware Identity OID (1.3.6.1.4.1.412.274.2), pathLengthConstraint to limit alias chain depth
SPDM Alias Leaf: CA=FALSE, digitalSignature, Responder EKU, Mutable Certificate OID (1.3.6.1.4.1.412.274.5), shorter validity period
SPDM Requester Authentication: Requester EKU (1.3.6.1.4.1.412.274.4) for mutual authentication scenarios

Protect device private keys correctly

Generate device keys inside a hardware Root of Trust, TPM, secure element, or protected device firmware, such as Hardware Security Module (HSM). Mark the private key non-exportable. Provision a unique key pair for each physical device, shared keys across a production batch undermine the authentication model entirely. Protect Root and Issuing CA keys with enterprise HSMs.

Integrate certificate issuance with manufacturing

Initial certificate provisioning happens before SPDM is running, so it requires an out-of-band enrollment mechanism: EST, SCEP, a custom REST API, or a controlled batch-manufacturing interface. SPDM v1.3.0 adds GET_CSR and SET_CERTIFICATE for in-band provisioning after deployment, but the initial Slot 0 certificate must be provisioned during manufacturing before the device ships.

A typical manufacturing sequence: device generates its key pair internally, manufacturing system reads the public key and device identifiers, a CSR is created, PKI validates the manufacturer and serial number, a certificate is issued, the chain is written to the SPDM slot, and the device is tested with a live SPDM challenge to confirm the slot is correctly provisioned.

Distribute trust anchors to Requesters

The Requester needs the Root CA certificate or its hash before it can trust any Responder. Trust distribution policy must answer: which manufacturer roots are trusted in this environment, how are compromised vendor roots removed, and how is trust handled when a device is transferred to a different organization. Without controlled trust-anchor management, a technically valid certificate may still be unauthorized for the environment it is presented in.

Define lifecycle and revocation policy

For AliasCert deployments, a practical approach: keep the Device Certificate CA long-lived and tightly protected, issue shorter-lived alias certificates with conventional renewal cycles, regenerate alias certificates after firmware updates, and have a clear process for denying compromised hardware serial numbers through out-of-band trust-store updates or deny lists.

How Encryption Consulting can help

Encryption Consulting supports SPDM PKI as an end-to-end PKI implementation and PKIaaS service.

PKIaaS for SPDM. EC’s PKI as a Service offering provides the Manufacturer CA hierarchy configured for SPDM compliance: all DMTF OIDs registered and templated, dedicated SPDM certificate profiles for DeviceCert and AliasCert chains, pathLengthConstraint and name constraint design for Device Certificate CA, and SPDM chain format handling for GET_CERTIFICATE delivery.

PKI Designing and Implementation: EC designs the dedicated SPDM CA hierarchy separate from your general TLS and user CAs, selects the right certificate model for each device type, builds all certificate templates with the correct field-level requirements, and documents the CP/CPS sections covering device identity issuance.

EC designs the integration between the manufacturing system, device provisioning gateway, PKIaaS issuing CA, and the SPDM certificate slot. Initial provisioning via EST, SCEP, REST API, or batch manufacturing interface whichever fits the production environment. Our Fortune 100 SPDM case study is a production reference for this work.

PKI Assessment: If you already have a device identity architecture, EC can assess it against DSP0274 X.509 requirements: correct Basic Constraints at every chain level, required OIDs present, SAN otherName structure, validity policy, key protection, and trust-anchor distribution — and identify the gaps before they become production issues.

Conclusion

The X.509 requirements SPDM places on certificates are specific and additive to standard PKI profiles. The DMTF OIDs must be registered and configured in your CA. The certificate models must be chosen deliberately. The validity periods must reflect device lifetime rather than software renewal cycles. And the trust-anchor distribution must cover the full supply chain from manufacturer through integrator to end operator.

SPDM Requirements for X.509 Certificate