The Identity Crisis at the Edge of Agentic AI

The global agentic AI market reached $7.6 billion in 2025 and is projected to exceed $196.6 billion by 2034. Yet most deployments have no hardware-rooted agent identity.

Traditional software credentials such as API keys, OAuth tokens, mTLS certificates, and service identities help authenticate the software or workload. They prove that a process has presented the right credentials. However, they do not prove that the underlying hardware is trusted, that the firmware has not been modified, or that the agent is running on the expected platform.

This is the core security challenge for agentic AI.

A certificate can tell you that a workload has the right private key. It cannot, by itself, tell you whether the machine hosting that workload has been compromised. In simple terms, software identity is like a badge. Hardware-rooted identity is closer to a biometric because it is anchored in the device itself.

Hardware-based identity provides a stronger foundation of trust by tying the agent’s identity to a hardware root of trust. Instead of only asking, “Is this the right software?”, organizations can ask, “Is this the right software, running on the right hardware, with the right firmware, in a verified state?” This distinction becomes extremely important as agentic AI moves into enterprise and regulated environments.

The foundation for this trust model already exists through standards such as DICE from TCG, SPDM from DMTF, and CMS with X.509 certificates. Together, these standards can help establish a hardware-to-agent identity chain that proves where an agent is running, what state the platform is in, and whether that platform can be trusted.

Quick Answer: What Is Hardware-Rooted Identity for Agentic AI?

Hardware-rooted identity for agentic AI anchors an AI agent’s identity in silicon rather than software credentials. Using DICE (key derivation from hardware-embedded secret plus firmware measurement), SPDM (runtime attestation protocol), and X.509 certificate profiles, an orchestrator can verify that an agent is running on genuine, unmodified hardware before dispatching any workload. Software credentials alone cannot provide this assurance.

Key Takeaways

• The global agentic AI market reached $7.6 billion in 2025 and is projected to exceed $196.6 billion by 2034, yet most deployments have no hardware-rooted agent identity. Software credentials (API keys, OAuth tokens, mTLS certificates) prove that a process has the right credentials but cannot prove the underlying hardware is trusted, the firmware is unmodified, or the agent is running on the expected platform.
• The DigiCert Trust Pulse Survey (July 2, 2025) found that 45 percent of organizations experienced certificate-related downtime in the prior year. Hardware identity certificate failures are directly analogous: an AI accelerator whose DICE certificate chain fails SPDM attestation verification is operationally dead, unable to receive any workload from the orchestrator, with no software-level remediation possible. The hardware fleet is the certificate fleet.
• Three interlocking standards already exist and are implemented in enterprise hardware today. DICE (TCG) creates the hardware-rooted key derivation. SPDM (DMTF) is the runtime protocol by which hardware proves its identity and measurement state to an orchestrator. CMS with X.509 certificate profiles is the PKI envelope that ties hardware identity to signed agent actions and the broader enterprise PKI. The gap is not missing standards; it is missing operational PKI architecture that connects them for agentic AI deployment.
• Hardware PKI is structurally different from server PKI in five critical ways: keys are physically bound to silicon and cannot be exported; certificate validity is tied to device lifetime (notAfter 99991231235959Z) rather than compliance windows; manufacturer and owner PKI hierarchies must never share a root; revocation triggers physical device quarantine rather than certificate replacement; and the issuing CA may be embedded in device firmware and must be certified at manufacturing time. A standard CA platform without DICE-specific configuration will produce certificates that fail SPDM attestation.
• NIST FIPS 203, 204, and 205 (finalized August 13, 2024) require replacing RSA and elliptic-curve algorithms on the NIST IR 8547 deprecation timeline. CA key algorithms used in DICE manufacturer CA and owner CA hierarchies must be included in the post-quantum migration roadmap. For post-quantum CA key algorithm migration planning, track requirements through the PQC Center of Excellence.

Who Should Care About Hardware Identity for Agentic AI

Hardware identity for agentic AI spans hardware manufacturing, PKI operations, security architecture, compliance governance, and executive strategy. Each team owns a distinct part of the implementation, and gaps in any area produce a device fleet that fails SPDM attestation, carries non-compliant certificates, or has an undetectable firmware modification attack surface.

Role	Why It Matters	Action Item
Hardware Vendors and Firmware Teams	Own the manufacturing-time IDevID implementation: UDS provisioning, CDI derivation at each firmware layer, ECA key generation, and ECA certification by the manufacturer CA before the device ships; if the manufacturing workflow does not integrate with the manufacturer CA, devices ship without a valid DICE certificate chain, and no post-deployment procedure can restore a properly manufacturer-issued IDevID; discovering the ECA needs certification after manufacturing has started means redesigning a production workflow	Design the UDS provisioning and CDI derivation process against the TCG DICE Layering Architecture specification; integrate the manufacturing workflow with the manufacturer CA API to certify ECA keys and issue IDevID certificates for each device at production time; confirm each device ships with a complete, verifiable certificate chain from device leaf to manufacturer root CA; engage Encryption Consulting’s PKIaaS for manufacturer CA design, HSM selection and configuration, SPDM certificate chain format validation, and manufacturing API implementation
PKI and Certificate Teams	Own CA hierarchy design and DICE-specific configuration: manufacturer CA hierarchy for hardware certificate profiles (IDevID, ECA, Attestation), owner CA hierarchy for LDevID and agent operational certificates, SPDM GET_CERTIFICATE chain format validation, 99991231235959Z validity handling, tcg-dice-kp OID registration, and CRL/OCSP infrastructure for ECA certificates; standard CA platforms without DICE-specific configuration produce certificates missing the required OIDs, with incorrect Key Usage for ECAs, BasicConstraints present on non-ECA leaf certificates, or validity periods rejected by SPDM verifiers	Configure manufacturer CA certificate templates for IDevID, ECA, and Attestation profiles with correct field-level requirements per TCG DICE Certificate Profiles v1.1 and IEEE 802.1AR-2018; register tcg-dice-kp OIDs in the CA platform OID database; configure 99991231235959Z validity handling; confirm CRLDistributionPoints is present on all ECA certificates; implement fleet-level agent operational certificate lifecycle management using CertSecure Manager; classify CA key algorithms against NIST post-quantum deprecation milestones through PQC Readiness services
Security Architects and Enterprise AI Deployers	Own the governance model for hardware identity in agentic AI deployments: defining the boundary between manufacturer-issued IDevID and owner-issued LDevID credentials, designing the owner PKI bridge that connects manufacturer CA and owner CA in the same DICE trust chain without merging the hierarchies, specifying the SPDM attestation verification policy that the orchestrator enforces before dispatching workloads, and ensuring the architecture satisfies IEEE 802.1AR-2018 requirements for the deployment environment; in regulated industries deploying AI hardware, the governance model must also satisfy applicable regulatory requirements for hardware identity assurance	Define the explicit governance controls for each identity phase: manufacturer CA authority over IDevID, owner CA authority over LDevID and agent operational certificates, SPDM attestation as the gate before operational certificate issuance; design the owner PKI bridge architecture; specify the SPDM attestation policy including which tcg-dice-kp OIDs are required for each attestation event; plan the post-quantum migration path for hardware CA key algorithms (ECDSA to ML-DSA per NIST FIPS 204); use CBOM Secure to discover and classify all cryptographic assets in the hardware identity hierarchy
Compliance Teams	Must produce audit evidence that AI hardware deployed in regulated environments carries verifiable, manufacturer-anchored identity; regulated industries deploying AI accelerators in healthcare (HIPAA), financial services (PCI DSS, SOX), defense (CMMC), or critical infrastructure (NERC CIP) may require evidence that each device’s identity is hardware-rooted, firmware-measured, and traceable to a manufacturer trust anchor; the DigiCert Trust Pulse Survey (July 2, 2025) found 45 percent of enterprises experienced certificate-related downtime, and hardware identity certificate failures are a direct source of that downtime in AI infrastructure deployments	Confirm the DICE certificate implementation produces a complete, auditable certificate chain for each deployed device on demand; include hardware identity certificate governance in the quarterly compliance evidence package: certificate chain completeness, SPDM attestation pass rate per device, firmware version correlation, and CA key algorithm compliance; map CA key algorithm migration to NIST IR 8547 deprecation milestones; verify that CRL and OCSP infrastructure for ECA certificates meets the availability requirements of the attestation verification infrastructure
CISOs Deploying AI Infrastructure	AI hardware without hardware-rooted identity is a supply chain and runtime security gap at the board level: supply chain attacks modifying accelerator firmware before deployment are a documented threat vector, and without DICE-rooted identity there is no cryptographic proof that deployed hardware is genuine and running expected firmware; as AI workloads handle increasingly sensitive data and autonomous actions, the identity assurance of the hardware executing those workloads becomes a board-level security and compliance requirement; the $7.6 billion agentic AI market (2025) expanding to $196.6 billion by 2034 means this is not a niche concern but a mainstream enterprise security challenge arriving at scale	Require hardware-rooted identity as a procurement requirement for AI accelerators and edge hardware before any production deployment; fund the manufacturer CA hierarchy design and PKIaaS engagement before hardware manufacturing begins (ECA certification cannot be retrofitted after manufacturing); mandate that all deployed hardware passes SPDM attestation verification using a complete DICE certificate chain before being trusted with a production workload; evaluate PKI as a Service for the manufacturer and owner CA infrastructure; require post-quantum migration planning for hardware CA key algorithms alongside the broader PKI post-quantum program

Hardware PKI Implementation Checklist: Issue, Business Impact, Recommended Action, and Owner

Use this checklist to identify which hardware PKI implementation gaps apply to your environment, understand the business impact of each gap, and assign remediation ownership before a failed SPDM attestation or audit finding exposes the gap under pressure.

Issue	Business Impact	Recommended Action	Owner
Server CA certificate profiles used for device certificates (CA/Browser Forum TLS profiles)	IDevID and attestation certificates missing tcg-dice-kp OIDs in Extended Key Usage are rejected by every SPDM verifier and 802.1AR-aware infrastructure; the entire hardware fleet fails attestation and cannot receive production workloads	Configure separate DICE-specific certificate templates for IDevID, LDevID, ECA, and Attestation profiles with the correct field-level requirements per TCG DICE Certificate Profiles v1.1 (April 24, 2025); register tcg-dice-kp OIDs in the CA platform OID database; never use CABF TLS profiles for hardware identity certificates	PKI Team
CA not configured for 99991231235959Z notAfter validity	Enterprise CA maximum validity period enforcement rejects IDevID certificate requests or issues certificates with arbitrarily long but non-spec-compliant dates that fail SPDM attestation validation; hardware fleet cannot be enrolled in the hardware identity program	Create explicit CA configuration exceptions for hardware certificate profiles that permit 99991231235959Z notAfter; validate the CA platform’s handling of GeneralizedTime value 99991231235959Z before manufacturing integration; test SPDM verifier acceptance of certificates with this notAfter value	PKI Team
Manufacturer and owner CA hierarchies share a root CA	Merging the hierarchies gives the hardware vendor authority over the deploying organization’s operational identity, breaking the two-phase identity model defined in IEEE 802.1AR-2018; a single root CA failure or compromise affects both the manufacturer-issued IDevID chain and the owner-issued LDevID and operational certificate chain simultaneously	Design and operate completely separate CA hierarchies for the manufacturer PKI (issuing IDevID and ECA certificates) and the owner PKI (issuing LDevID and agent operational certificates); the two hierarchies must never share a root CA; the owner PKI trusts the manufacturer IDevID chain through SPDM attestation, not through a shared root	Security Architect + PKI Team
ECA certification not planned for manufacturing time	Devices ship without a properly certified ECA; the DICE layering architecture cannot function above the uncertified layer; discovering this requirement after manufacturing has started requires redesigning a production workflow, which is operationally expensive and time-consuming	Include ECA key certification as a required step in the manufacturing workflow design before production begins; the manufacturer intermediate CA must be available and integrated with the production line to certify ECA public keys before each device ships; validate the ECA certificate carries keyCertSign (Key Usage), cA:TRUE and pathLengthConstraint (Basic Constraints), id-tcg-kp-eca (EKU), and CRLDistributionPoints (required)	Hardware Vendor + PKI Team
SPDM certificate chain format incorrect for GET_CERTIFICATE	CHALLENGE_AUTH verification fails for every device in the fleet; the orchestrator cannot verify hardware identity and cannot dispatch any workload to the hardware; the failure appears as an SPDM protocol error rather than a certificate error, making root cause analysis slower	Validate the SPDM certificate chain format against the DMTF SPDM specification: 2-byte total length, 2-byte root hash length, root cert hash, concatenated DER certificates; test GET_CERTIFICATE and CHALLENGE_AUTH against a reference SPDM verifier before production deployment; engage Encryption Consulting’s SPDM implementation team to validate certificate chain format compatibility	Hardware Vendor + PKI Team
No CRL or OCSP infrastructure for hardware CAs	ECA certificates without CRLDistributionPoints violate the TCG DICE specification; every SPDM attestation validates the certificate chain including revocation status; devices whose certificates cannot be revocation-checked are operationally untrusted; a compromised device cannot be quarantined through standard revocation procedures	Deploy CRL and OCSP infrastructure for all hardware CA levels; configure CRLDistributionPoints in all ECA certificates as required by the specification; size the infrastructure for high validation frequency (every SPDM attestation) and low revocation frequency (hardware key compromise is rare and physically constrained); set CRL publication frequency for hardware CAs at weekly to monthly, with OCSP SLAs tight enough that an attestation failure does not leave a device in an indeterminate state	PKI Team

What Does “Hardware Identity” Actually Mean?

Hardware identity is the principle that a device’s identity should be anchored in something that cannot be extracted from the hardware without physical destruction: a cryptographic key embedded during manufacturing, accessible only to the firmware running directly on that silicon, and probably linked to the specific device produced.

The most established implementation of this principle is the Trusted Platform Module (TPM), present in enterprise servers and laptops for decades. But TPMs were designed for a world of relatively static machines and relatively simple trust assertions. The challenge of agentic AI agents running on purpose-built AI accelerators, edge inference hardware, cloud-based silicon, and GPU clusters requires a more flexible, composable approach to hardware-rooted identity.

That approach is built on three interlocking standards. Each will receive its own deep-dive blog in this series, but here is what each one does:

DICE: Device Identifier Composition Engine (TCG)

Developed by the Trusted Computing Group, DICE provides the foundation: a mechanism for deriving a unique, hardware-bound cryptographic identity from a secret embedded at the time of manufacture. Every layer of firmware added on top of that foundation is measured and incorporated into the identity derivation, so the identity that emerges at the application layer reflects not just the hardware itself. Still, the specific firmware state running on it. An agent running hardware with modified firmware will have a different identity than the same hardware running unmodified firmware, and that difference is cryptographically provable.

SPDM: Security Protocol and Data Model (DMTF)

SPDM is the communication protocol that allows one component to prove its hardware identity to another. Where DICE creates the identity, SPDM is the mechanism by which that identity is presented and verified during a live interaction. An AI orchestrator using SPDM can challenge a hardware component, a GPU, a network card, or a secure enclave, and receive a cryptographically signed attestation of that component’s identity and measurement state before trusting it with any workload.

CMS and X.509: The PKI envelope

Cryptographic Message Syntax (CMS, RFC 5652) and X.509 certificate profiles are the layer at which hardware identity connects to the broader PKI ecosystem. DICE produces a certificate chain rooted in hardware. SPDM attests to the hardware’s integrity at runtime. CMS provides the envelope for signing individual agent actions, transactions, or messages, tying them back to the hardware-rooted identity of the agent who produced them. Together, these three standards form a complete chain of trust from silicon to signed action.

Hardware-Rooted Identity for AI Agents

DICE, SPDM, IEEE 802.1AR-2018 (Secure Device Identity), and CMS are well-specified and actively implemented in enterprise hardware today. AI accelerators from major hardware-based vendors already implement DICE. Enterprise servers already support SPDM. The certificates that tie these attestations into a usable PKI already conform to well-established X.509 and IEEE 802.1AR profiles.

The challenge is that no one has yet built the operational infrastructure that connects these hardware-level standards to the AI agent deployment lifecycle. Certificate issuance platforms were built for servers, users, and devices. They were not designed to:

• Enroll an AI accelerator’s hardware identity using DICE-derived certificate chains
• Verify firmware integrity via SPDM before issuing an operational agent certificate
• Manage certificate lifecycle for agent identities that may spin up and tear down multiple times per day
• Tie signed agent actions via CMS back to the hardware-rooted chain that proves the agent’s provenance

That operational gap between the existing standards and the infrastructure that implements them for agentic AI is precisely where risk accumulates. Our engagement with a Fortune 100 organization on SPDM-compliant PKI for device certificates, aligned with DICE X.509 and IEEE 802.1AR, represents the kind of real-world implementation that most vendors are still positioning as a future roadmap item. The standards exist, the hardware supports them, and the implementation work is underway for organizations that choose to require it.

Five Ways Hardware PKI Is Structurally Different

The following are the 5 PKI implications that are structurally different and need to be considered during hardware manufacturing.

1. The private key is physically bound to silicon

In server PKI, a private key can be exported, backed up, migrated, or rotated on a schedule. In hardware identity PKI, the private key is derived from the UDS (Unique Device Secret), a value physically embedded in silicon at manufacture, as specified in the TCG DICE architecture. It cannot be exported. It cannot be backed up. Key compromise means device decommissioning, not certificate replacement.

PKI implications:

• No key escrow model for hardware-bound keys
• Key rotation requires physical device replacement
• Your CA cannot verify the key through a standard CSR workflow alone; the DICE derivation chain provides the proof of binding

2. Certificate validity must be designed around device lifetime, not compliance windows

The CA/Browser Forum has mandated 47-day maximum TLS certificate lifetimes (Ballot SC-081, effective March 2026). An AI accelerator shipping today may still be in production in 2045. The TCG DICE Certificate Profiles specification handles this directly:

Devices without a secure clock can set the Not After portion of the certificate’s Validity Period to the X.509-defined GeneralizedTime value of 99991231235959Z. This value is used to indicate that the certificate has no defined expiration date.

This is not optional and not a workaround. It is the normative behavior for hardware certificates on devices without a real-time clock. Your CA infrastructure must be configured to issue certificates with this value. Most enterprise CA platforms enforce maximum validity period constraints by default; you will need explicit configuration exceptions for hardware certificate profiles.

3. Two distinct identity phases require two completely separate PKI hierarchies

Hardware identity operates in two phases with different trust anchors:

Phase 1 – Manufacturing-time identity (IDevID)	Phase 2 – Deployment-time identity (LDevID)
Standard: IEEE 802.1AR-2018 + TCG DICE X.509	Standard: IEEE 802.1AR-2018 + TCG DICE X.509
Issued by: Device manufacturer’s CA	Issued by: Device owner’s CA (completely separate from manufacturer CA)
Policy OID: id-tcg-kp-identityInit {id-tcg-kp 6}	Policy OID: id-tcg-kp-identityLoc {id-tcg-kp 7}
Purpose: Proves this is genuine hardware from this manufacturer	Purpose: Operational identity within the owner’s environment
This is the device’s birth certificate. It cannot be reissued after manufacture.	Issued after SPDM attestation of the IDevID chain succeeds.

These two hierarchies must never share a root. The manufacturer CA has no authority over the owner’s operational environment. Merging them gives the hardware vendor ongoing control over a deploying organization’s PKI decisions, which is both a trust model failure and, in regulated industries, a compliance problem.

4. Revocation means physical action, not certificate replacement

Revoking an IDevID does not allow you to reissue it with a new key. The key is hardware-bound. Revocation means the device is quarantined or decommissioned. Your CRL and OCSP infrastructure must be built around this reality:

• IDevID CRL entries should trigger device quarantine workflows, not just certificate invalidation
• OCSP SLAs for hardware CAs must be tight, i.e., a device that cannot validate its certificate chain is operationally dead
• CRL publication frequency for hardware CAs can be longer than server CAs (weekly to monthly) because key compromise events are rare and physically constrained

5. The issuing CA may be embedded in the device firmware

The TCG DICE specification defines an Embedded Certificate Authority (ECA), a CA that lives inside the device firmware and issues certificates to firmware layers above it.

The ECA is a real CA. It has a key pair derived from the DICE CDI (Compound Device Identifier). It signs certificates. It must be certified by the manufacturer CA during the manufacturing process. This means:

• The manufacturer’s issuing CA must be available and integrated into the production line
• The ECA certificate MUST carry: keyCertSign in Key Usage, cA:TRUE in Basic Constraints with pathLengthConstraint, Policy OID id-tcg-kp-eca {id-tcg-kp 12}, and CRLDistributionPoints MUST be present.
• If you discover the ECA needs to be certified after manufacturing has started, you are redesigning a production workflow plan, so this is in from day one

The PKI Hierarchy for Hardware Identity

Here is the complete CA hierarchy, with the requirements at each level. This applies to hardware vendors building the manufacturer’s PKI.

CA Level	Algorithm / HSM	Validity	Key Usage	Issues
Manufacturer Root CA	ECDSA P-384 / FIPS 140-3 L3+ HSM, offline air-gapped	99991231235959Z (no clock) or defined	CA only	Manufacturer Intermediate CAs only
Manufacturer Intermediate CA	ECDSA P-384 / FIPS 140-3 L3 HSM, online restricted	99991231235959Z (no clock) or defined	CA + CRLSign	IDevID certs or ECA certs
ECA (on-device, DICE)	ECDSA P-256/384 / DICE CDI-derived	Matches IDevID lifetime	keyCertSign only (MUST NOT cRLSign)	Attestation certs for firmware layers
IDevID Leaf Certificate	ECDSA P-256/P-384 / silicon-bound	99991231235959Z (no clock) or defined	MUST NOT keyCertSign	End-entity for device identity

TCG Policy OIDs: Every Certificate Must Carry the Right One

The TCG DICE specification defines a set of policy OIDs in the id-tcg-kp namespace. Each OID encodes what a certificate is authorized for and how its key was bound. Getting the OID wrong means the certificate fails validation at every SPDM verifier and 802.1AR-aware system.

OID Name	OID Value	Certificate Type	Key Must Be Bound
id-tcg-kp-identityInit	{id-tcg-kp 6}	IDevID	At manufacturing time. Certified by the manufacturer CA.
id-tcg-kp-identityLoc	{id-tcg-kp 7}	LDevID	Post-manufacturing. Certified by local/owner CA.
id-tcg-kp-attestInit	{id-tcg-kp 8}	Attestation (initial)	At manufacturing time. Signs evidence about device firmware/config.
id-tcg-kp-attestLoc	{id-tcg-kp 9}	Attestation (local)	Post-manufacturing. Certified by a local issuer.
id-tcg-kp-assertInit	{id-tcg-kp 10}	Assertion (initial)	At manufacturing time. Signs reference measurements.
id-tcg-kp-assertLoc	{id-tcg-kp 11}	Assertion (local)	Post-manufacturing. Certified by a local issuer.
id-tcg-kp-eca	{id-tcg-kp 12}	ECA	Manufacturing or post-manufacturing. Authorizes certificate issuance by embedded CA.

Practical rules for your CA configuration:

• IDevID MUST contain id-tcg-kp-identityInit. It MAY also contain id-tcg-kp-eca (if the device is an ECA) and id-tcg-kp-attestInit (if it also performs attestation signing).
• LDevID MUST contain id-tcg-kp-identityLoc. It MAY also contain id-tcg-kp-eca and id-tcg-kp-attestLoc.
• ECA certificates MUST contain id-tcg-kp-eca. CRLDistributionPoints extension MUST be present.
• Attestation certificates MUST contain either id-tcg-kp-attestInit or id-tcg-kp-attestLoc.

The Six Most Common PKI Mistakes Hardware Vendors Make

The following are six common mistakes that hardware vendors may make when designing or implementing hardware-based identity and security controls. These points are not necessarily applicable to every hardware vendor and may vary depending on the product architecture, deployment model, threat landscape, regulatory requirements, and specific use case. They should be treated as general considerations rather than universal assumptions.

Using server certificate profiles for device certificates. CA/Browser Forum profiles are designed for TLS. They impose subject name requirements, SAN requirements, and validity periods that do not apply to hardware identity. An IDevID issued with a CABF profile will not carry id-tcg-kp-identityInit, will have a short validity period, and will be rejected by SPDM verifiers checking for TCG OIDs.

Not configuring the CA for 99991231235959Z lifetime. Enterprise CAs have maximum validity period enforcement. If your hardware team requests an IDevID and the CA rejects it because the lifetime exceeds policy limits, you either get a misconfigured certificate or a workaround certificate with an arbitrarily long date, but not the spec-mandated value.

Merging the manufacturer and owner CA hierarchies. Creating a single PKI that issues both IDevID and LDevID from the same root gives the hardware vendor authority over the deploying organization’s operational identity. This breaks the two-phase identity model defined in IEEE 802.1AR-2018, creating a single point of failure for both phases.

Not planning for ECA certification at manufacturing time. If your device implements DICE, the ECA must be certified before the device ships. This means the manufacturer’s intermediate CA must be available and integrated into the manufacturing workflow. Teams that discover this requirement after manufacturing has begun face costly process redesigns or ship devices without a properly certified ECA.

Ignoring the SPDM certificate chain format. SPDM GET_CERTIFICATE returns a chain in a specific format: 2-byte total length, 2-byte root hash length, root cert hash, concatenated DER certs. If your PKI issues standard DER chains and your SPDM implementation wraps them incorrectly, CHALLENGE_AUTH verification will fail.

No CRL/OCSP infrastructure for hardware CAs. The ECA certificate profile requires CRLDistributionPoints to be present. Hardware CA CRL infrastructure must be sized for very low revocation frequency but very high validation frequency. Every SPDM attestation validates the certificate chain, which includes CRL/OCSP checks.

How Encryption Consulting Can Help

Encryption Consulting specializes in PKI architecture for hardware-based identity. Our work with hardware vendors and deploying organizations covers the scope of this blog: designing manufacturer CA hierarchies, configuring hardware certificate profiles, implementing ECA provisioning in manufacturing workflows, and building the owner PKI that bridges IDevID to the agent’s operational identity.

• Manufacturer PKI design: We design CA hierarchies aligned to TCG DICE, IEEE 802.1AR, and DMTF SPDM. This includes offline root CA ceremony planning, HSM selection and configuration, and the certificate profile specifications your CA needs for IDevID, ECA, and attestation certificates.
• Manufacturing workflow integration: ECA key certification requires the manufacturer CA to be available and integrated during the production process. We design and implement the PKI-to-manufacturing integration HSM connectivity, certificate generation, and verification that makes this operationally practical.
• SPDM and DICE implementation: We bridge hardware PKI to runtime attestation, ensuring the certificate chain your PKI issues passes SPDM GET_CERTIFICATE and CHALLENGE_AUTH validation. Our Fortune 100 SPDM case study is a production reference for this work.
• CertSecure Manager for agent CLM: For the owner’s PKI managing agent operational certificate lifecycles at scale, CertSecure Manager provides discovery, automated EST renewal, revocation automation, and audit trail infrastructure.

Conclusion

Hardware identity for AI agents is not a future concern. AI accelerators already implement DICE. Enterprise hardware already supports SPDM. The certificates that tie these attestations into a usable PKI already conform to well-established X.509 and CMS standards. What is missing is the operational architecture that connects them and the organizational will to require hardware-rooted trust as a baseline for agentic AI deployment.

The remaining four blogs in this series build that architecture piece by piece. By the end, you will have a complete blueprint for an AI agent identity stack that begins in silicon and ends with a signed, auditable record of every consequential action your agents take.

Frequently Asked Questions

What is the main takeaway from The Identity Crisis at the Edge of Agentic AI?

Most agentic AI deployments rely on software credentials that prove a process has the right credentials but cannot prove the underlying hardware is trusted, the firmware is unmodified, or the agent is running on the expected platform. Hardware-rooted identity using DICE, SPDM, and X.509 certificate profiles resolves this gap by anchoring agent identity in silicon, making firmware modification cryptographically detectable, and enabling orchestrators to verify hardware state before dispatching workloads. The hardware supports these standards today; the gap is the operational PKI architecture that connects them.

Why does hardware PKI for agentic AI matter for enterprise PKI teams?

Hardware PKI is structurally different from server PKI in five ways: keys are physically bound to silicon and cannot be exported; certificate validity is tied to device lifetime (99991231235959Z) rather than compliance windows; manufacturer and owner PKI hierarchies must never share a root; revocation triggers physical device quarantine rather than certificate replacement; and the ECA must be certified at manufacturing time. A standard CA platform without DICE-specific configuration will produce certificates that fail SPDM attestation, leaving the entire hardware fleet unable to receive production workloads.

What risks increase if hardware identity for AI agents is handled without a structured program?

Four risk categories increase: software credential spoofing (without hardware-rooted identity, any process with the right credentials can impersonate an AI agent, including a compromised or counterfeit device); undetected firmware modification (DICE makes firmware modification cryptographically detectable; without it, supply chain attacks cannot be detected); SPDM attestation failure (certificates missing TCG policy OIDs fail every SPDM verifier); and post-quantum migration gaps (DICE CA key algorithms must migrate to ML-DSA per NIST FIPS 204, finalized August 13, 2024; uncatalogued hierarchies cannot be included in migration planning).

Which teams should own hardware identity for agentic AI?

Hardware vendors and firmware teams own manufacturing-time IDevID implementation. PKI and certificate teams own CA hierarchy design and DICE-specific configuration. Security architects own the governance model: IEEE 802.1AR-2018 integration, SPDM attestation policy, and owner PKI bridging from manufacturer IDevID to owner LDevID and agent operational certificates. Compliance teams own the audit evidence for hardware identity certificates across the deployed fleet.

How does hardware identity for agentic AI connect to certificate lifecycle management?

Hardware identity CLM is driven by firmware update cadence, not calendar expiry: a firmware update triggers a new CDI derivation, a new key pair, and a new certificate request. The owner’s PKI issues LDevID and agent operational certificates after SPDM attestation succeeds, and those operational certificates must be managed at fleet scale for AI accelerators that spin up and tear down multiple times per day. CertSecure Manager provides the fleet-level CLM layer: automated renewal via EST, revocation automation, fleet-level discovery, and audit trail for agent operational certificate populations.

How should organizations measure success in hardware identity for agentic AI?

Key metrics: SPDM attestation pass rate (100 percent for all production AI accelerators); certificate chain completeness (all deployed hardware has a complete, verifiable chain from device leaf to manufacturer root CA); fleet-level CLM coverage (all agent operational certificates in the inventory with firmware version correlation); and post-quantum readiness classification (CA key algorithms classified against NIST IR 8547 deprecation milestones with migration timeline defined).

What should be audited or monitored regularly?

Monitor continuously: OCSP responder and CRL distribution point availability for all ECA certificates (required by TCG DICE specification; every SPDM attestation validates the chain including revocation status); agent operational certificate expiry with renewal alerts; SPDM attestation pass/fail rates. Audit quarterly: fleet-level certificate inventory correlated with deployed firmware versions; SPDM attestation logs for devices failing due to certificate chain issues; CA key algorithm classification against NIST FIPS 203/204/205 (finalized August 13, 2024).

How does hardware identity for agentic AI affect cloud, hybrid, or multi-CA PKI environments?

The manufacturer CA layer sits below the enterprise PKI hierarchy. In cloud and hybrid deployments, the owner PKI bridge must connect manufacturer-rooted IDevID credentials to owner-operated LDevID and agent operational certificate infrastructure without merging the two hierarchies or giving the hardware vendor authority over the owner’s PKI decisions. Multi-cloud environments must ensure each cloud environment’s SPDM attestation verification infrastructure trusts the same manufacturer CA root. Agent operational certificates for AI workloads that spin up multiple times per day require CLM automation that standard tools were not designed to provide.

What common mistakes should teams avoid?

The six most frequent mistakes: using CA/Browser Forum TLS profiles for device certificates (missing TCG policy OIDs fail every SPDM verifier); not configuring the CA for 99991231235959Z notAfter validity; merging the manufacturer and owner CA hierarchies into a single root; not planning ECA certification at manufacturing time; not framing the SPDM GET_CERTIFICATE chain correctly (causing CHALLENGE_AUTH to fail); and not deploying CRL/OCSP infrastructure for hardware CAs (required by the ECA certificate profile).

What should be refreshed quarterly for hardware identity governance?

Quarterly: verify fleet-level certificate inventory is current and correlated with deployed firmware versions; confirm OCSP responder and CRL distribution point availability for all ECA certificates; review SPDM attestation pass/fail logs; classify CA key algorithms against NIST post-quantum deprecation milestones (ML-DSA per FIPS 204, finalized August 13, 2024); confirm the owner PKI bridge is correctly configured for any newly deployed hardware; review agent operational certificate renewal automation coverage. For post-quantum CA key algorithm migration planning, check the PQC Center of Excellence.