DevID (IEEE 802.1AR)

What DevID is

DevID — short for Device Identifier — is IEEE standard 802.1AR. It specifies how a network device can carry a cryptographically verifiable identity that survives across owners, networks, and operational contexts. The standard defines two flavours of identity:

Both are X.509 certificates. The IDevID is written to secure storage at the factory (often a TPM or secure element) and never changes. The LDevID is issued after the device joins an owner's network and can be rotated freely.

The design is deliberately reminiscent of a passport plus a work badge: your passport (IDevID) proves you are the person the government said you are and never changes; your work badge (LDevID) proves you are authorised to enter this building today and can be reissued or revoked when your role changes.

Why it exists

Device onboarding used to be the wild west. Every vendor invented its own bootstrap protocol — pre-shared keys mailed in envelopes, MAC address whitelists, "trust on first use" that quietly accepted whatever showed up. Every one of these approaches had failure modes at scale: PSKs leaked, MACs got spoofed, TOFU accepted rogue devices claiming to be legitimate.

802.1AR sets a standard: manufacturers assert device identity at the factory, deployers verify that assertion cryptographically before granting an operational identity. It underpins other standards:

• BRSKI (RFC 8995) — Bootstrapping Remote Secure Key Infrastructure — uses IDevIDs as the bootstrap credential for zero-touch onboarding.
• IETF ANIMA — Autonomic Networking Integrated Model — assumes IDevIDs as the seed of trust.
• IEEE 802.1X-2020 — updated to reference DevID as the recommended device credential for network access control.
• NIST SP 1800-36 — recommends 802.1AR for trusted IoT onboarding.

If you are building an IoT program and expect regulator scrutiny in the next few years, DevID is what auditors will look for.

What is inside an IDevID

An IDevID is an X.509 certificate with a few specific properties:

• Subject and SAN identify the specific device (usually via serial number, MAC address, or an OID-namespaced identifier).
• The HardwareModuleName Subject Alternative Name (per RFC 4108) carries a structured identifier — hardware type OID plus a manufacturer-assigned serial — that other systems can match against inventory records.
• The private key lives in the device's secure element or TPM and is not exportable.
• The certificate chains to a manufacturer root CA the deployer can verify against a trust bundle.

TigerTrust's DevID verifier lives in services/pki-core/internal/devid/devid.go. ValidateIDevID chains a presented IDevID against the same trust bundle used for TPM Endorsement Keys, extracts the HardwareModuleName, and returns a structured device record. IssueLDevID then signs a short-lived LDevID whose subject inherits from the IDevID. The endpoint is POST /api/v1/devid/ldevid.

The two-tier lifecycle

A typical DevID flow:

1. Manufacturing. Factory provisions the device with a TPM-bound key, generates a CSR, signs it with the manufacturer's DevID issuing CA, and writes the resulting IDevID and its private key handle to secure storage.
2. Shipping. Device arrives at customer with IDevID intact. Nothing else on the device is trusted yet.
3. Onboarding. Device presents its IDevID to the deployer's network. The deployer chain-verifies to the manufacturer root, extracts the hardware serial, and looks it up in a purchase or provisioning record. If it matches, the deployer accepts the device and issues an LDevID keyed to their own CA.
4. Operation. The LDevID is what the device uses for day-to-day authentication — 802.1X on the network, mTLS to backend services, whatever the deployer's environment requires.
5. Rotation. LDevIDs rotate on the deployer's schedule (short is better) without touching the immutable IDevID.
6. Transfer or decommission. When the device changes hands, the new owner issues their own LDevIDs against the same IDevID. When the device is retired, the IDevID becomes worthless — no one issues it a fresh LDevID.

What problem it solves

DevID solves provenance: "is this device really the physical thing we bought, or something claiming to be it?" It also solves operational isolation: "does this device have permission to be on our network today?" The two-tier design decouples the two questions — you can rotate operational trust (LDevID) without touching provenance (IDevID), and you can transfer ownership without regenerating factory identity.

Without DevID, both questions collapse into a single credential that has to be either eternal (and therefore high-risk if leaked) or fragile (and therefore reissued constantly, which is expensive at scale). With DevID, each concern has its own credential with appropriate lifetime and rotation policy.

When to use it

Reach for DevID when:

• You buy hardware in bulk from a vendor that supports IDevID provisioning (Cisco, Juniper, Fortinet, Aruba, Rockwell, Schneider, and a growing list of IoT-focused manufacturers).
• You need to prove hardware provenance for compliance — IEC 62443, NIST SP 800-213, CISA CPGs.
• You are automating device onboarding at scale and cannot afford manual credential distribution.
• You want to support device resale or transfer without breaking the ownership audit trail.

Skip it (or postpone it) when your hardware does not ship with a factory-provisioned identity, or when your fleet is small enough that manual enrolment is tractable.

Common misconceptions

"IDevID is the certificate the device uses to authenticate." Usually not directly. The IDevID authenticates the onboarding request. Day-to-day authentication uses the shorter-lived LDevID. Using the IDevID for everything conflates provenance with operational identity and forces you to accept a lifetime-long credential in every session — undesirable.

"IDevIDs work like TLS server certificates." They do not. IDevIDs are consumed by trusted internal onboarding services, not by public clients. Nothing chains an IDevID to the WebPKI, and it should never appear in a public-facing TLS handshake.

"You can extract an IDevID's private key." Not from a compliant device — the standard requires the key to live in secure storage without export capability. If you can extract it, the implementation is non-compliant.

"LDevIDs need to look like IDevIDs." They do not. Deployers can pick their own subject formats, CA hierarchies, and validity periods. The only constraint is that the LDevID subject should be traceable back to the IDevID that authorised its issuance, usually via a shared serial number or a stored mapping in inventory.

"BRSKI is just IDevID with more steps." BRSKI (RFC 8995) is a zero-touch onboarding protocol that uses IDevIDs plus a manufacturer voucher service to make onboarding fully automatic. IDevID alone is the credential; BRSKI is one workflow that consumes it.

How TigerTrust supports DevID

TigerTrust's DevID module accepts IDevIDs from any manufacturer whose root is in the configured trust bundle (the same bundle used for TPM EKs, kept separately from public WebPKI trust to avoid confusion). ValidateIDevID performs chain verification and HardwareModuleName extraction; IssueLDevID signs an LDevID whose lifetime, subject, and policy are controlled by the operator's normal certificate templates. When the underlying hardware also has a TPM, IDevID validation can be combined with TPM attestation for defence-in-depth: prove both that this is the hardware we bought and that its current firmware/software state is trustworthy before issuing the LDevID.

Related reading

• IEEE 802.1AR-2018 — the standard itself.
• IETF RFC 4108 — the HardwareModuleName SAN.
• IETF RFC 8995 — BRSKI, which builds zero-touch onboarding on top of IDevID.
• NIST SP 1800-36 — Trusted IoT Onboarding, which recommends 802.1AR.