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.

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.