IEEE 802.1AR-2018, approved by the IEEE Standards Association on 14 June 2018 and published 2 August 2018, defines the Secure Device Identifier (DevID): a cryptographically bound, manufacturer-installed Initial Device Identifier (IDevID) X.509 certificate that lets a network authenticate one specific physical device rather than trusting a shared password, pre-shared key, or self-signed certificate an attacker could copy onto other hardware. Protocols built on top of it — IETF's BRSKI (RFC 8995), IEEE 802.1X network access control, and NIST's IoT onboarding practice guide SP 1800-36 — all use that same IDevID as the hardware-rooted identity a device presents the moment it joins an OT or IoT network, which is why it keeps showing up as the identity layer underneath newer zero-trust and secure-onboarding work rather than as a standalone feature.
Key takeaways
- 802.1AR specifies two things, not one: the identifiers themselves, and how a device manages the relationship between them over its lifecycle.
- An IDevID answers "is this the device the manufacturer actually built," which is why it is the trust anchor BRSKI and similar protocols use to authenticate brand-new, unconfigured hardware.
- BRSKI (RFC 8995, published by the IETF in May 2021) is the clearest real-world demonstration of what 802.1AR's IDevID is actually for.
- No — it is the identity primitive those frameworks assume exists, not a competing or redundant layer.
What does IEEE 802.1AR actually specify?
802.1AR specifies two things, not one: the identifiers themselves, and how a device manages the relationship between them over its lifecycle. Per the IEEE 802.1 Security Task Group's own page, the standard covers "unique per-device identifiers (DevID) and the management and cryptographic binding of a device to its identifiers, the relationship between an initially installed identity and subsequent locally significant identities, and interfaces and methods for use of DevIDs with existing and new provisioning and authentication protocols." That last clause matters for OT and IoT device makers specifically: 802.1AR is deliberately written to plug into protocols that already exist — EAP, 802.1X, and later BRSKI — rather than requiring a proprietary authentication scheme, so a device identity built to this standard carries forward as the industry's onboarding and zero-trust protocols evolve around it.
What is the difference between an IDevID and an LDevID?
| Identifier | Who issues it | When | Key property |
|---|---|---|---|
| IDevID (Initial Device Identifier) | The device manufacturer | At manufacturing time | Globally unique, stored so it cannot be modified after issuance — the device's permanent birth credential |
| LDevID (Locally significant Device Identifier) | A network administrator or operator | Any time after deployment, often during onboarding | Cryptographically bound to the device so it cannot be forged or moved to different hardware without the private key used to create that binding |
An IDevID answers "is this the device the manufacturer actually built," which is why it is the trust anchor BRSKI and similar protocols use to authenticate brand-new, unconfigured hardware. An LDevID answers a narrower, operator-specific question — "is this the identity I, this network, issued to that device" — and can encode local information such as network segment or role that the manufacturer has no way to know in advance. A device is not limited to one or the other: the common pattern is to use the manufacturer's IDevID once, during onboarding, specifically to authenticate the device while it enrolls for an operator-issued LDevID it will then use for routine network access.
How does IEEE 802.1AR relate to BRSKI and OT/IoT device onboarding?
BRSKI (RFC 8995, published by the IETF in May 2021) is the clearest real-world demonstration of what 802.1AR's IDevID is actually for. The RFC's terminology section defines an IDevID in its own words as "an Initial Device Identifier X.509 certificate installed by the vendor on new equipment... a term from 802.1AR" — a direct normative reference, not an independent reinvention. In the protocol, a new device presenting itself to a network for the first time (BRSKI calls it a "pledge") uses that factory-installed IDevID to authenticate itself to a registrar, discover its Manufacturer Authorized Signing Authority through a certificate extension BRSKI itself defines, and receive a signed voucher confirming the network is authorized to take ownership of it — all without the device needing any network-specific secret in advance. NIST's own SP 1800-36 practice guide on trusted IoT device onboarding builds on exactly this mechanism, describing a pre-market "birth credential" that, for a BRSKI-capable device, takes the form of this same 802.1AR IDevID certificate.
Does 802.1AR replace IEC 62443 or TPM-based identity requirements?
No — it is the identity primitive those frameworks assume exists, not a competing or redundant layer. IEC 62443-4-2's identification-and-authentication requirements expect a component to be able to uniquely identify and authenticate itself to other components and to a PKI; 802.1AR's IDevID/LDevID structure is a standard, interoperable way to satisfy that expectation with per-device X.509 certificates instead of a shared key baked into every unit of a product line — see our IEC 62443-4-2 component requirements guide for the fuller requirement set 802.1AR identity feeds into. On the hardware side, 802.1AR does not mandate a TPM: NIST's SP 1800-34 guide on validating computing device integrity documents a TPM-backed, TCG- and 802.1AR-compliant IDevID as one implementation pattern, but the standard's own requirement is only that the IDevID be "stored in a way that protects it from modification" — a discrete TPM, a secure element, or any other tamper-resistant storage can meet that bar, which is what makes DevID usable on constrained OT and IoT hardware that has no room for a dedicated security chip. Where a hardware root of trust for the signing operation itself is the question, see our secure boot and hardware root of trust guide.
Is IEEE 802.1AR still being maintained?
Yes. The 2018 base text is still the active, current standard — it replaced 802.1AR-2009, not the reverse — and two further pieces of work sit on top of it rather than superseding it. The IEEE 802.1 Security Task Group's page lists an already-approved amendment, 802.1AReg-2026, adding optional support for a Module-Lattice-Based Digital Signature Algorithm (a post-quantum signature option), and a full revision project, P802.1AR-2018-Rev, edited by Mick Seaman and currently in progress. Neither changes what an IDevID or LDevID is for; they extend the cryptographic algorithms a conformant implementation can use for the same identity model, which matters for any OT or IoT device with a multi-decade expected service life planning its key material now.
A workable starting point
Confirm whether your device's identity is a per-unit X.509 certificate or a shared secretA key or password baked into every unit of a product line is not a DevID in any meaningful sense, no matter what the datasheet calls it — the entire point of an IDevID is that it is unique per physical device. Decide where the IDevID will actually be stored before committing to silicon802.1AR only requires tamper resistance against modification, so the choice between a TPM, a secure element, or a protected flash region should follow from your device's cost and threat model, not from copying a reference design built for a different product. Plan the IDevID-to-LDevID handoff explicitly, particularly if you expect operators to onboard your device with BRSKI or an equivalent zero-touch provisioning flow — the manufacturer credential's only job in that flow is proving provenance once, at enrollment. Track the 802.1AReg-2026 and P802.1AR-2018-Rev workif your device's service life is measured in years rather than months, since the signature algorithm your current implementation uses today may need to change well before the hardware is retired.
For the broader chain-of-trust mechanics an IDevID's signing operations ultimately depend on, see secure boot and hardware root of trust, explained; for where a missing or weak device identity shows up as an exploitable gap, see MITRE EMB3D; and for the component-level security requirements an 802.1AR-based identity is typically built to satisfy, see IEC 62443-4-2 component requirements.
SoftWSP's device & firmware security service reviews how a device's identity, provisioning and onboarding flow are actually implemented — not just whether a datasheet claims DevID support — against the device's real hardware constraints: see Device & Firmware Security.
This guide is based on the IEEE 802.1 Security Task Group's and IEEE Standards Association's own published pages for 802.1AR, IETF's RFC 8995 (BRSKI), and NIST's SP 1800-36 and SP 1800-34 practice guides and CSRC glossary, all read directly for this guide. IEEE standards text itself is not freely reproducible in full; confirm exact clause wording against the IEEE Get Program's free copy of 802.1AR-2018 before citing this guide as authoritative on a specific requirement.
Sources
- IEEE SA — IEEE Std 802.1AR-2018, Standard for Local and Metropolitan Area Networks: Secure Device Identity
- IEEE 802.1 Security Task Group — 802.1AR: Secure Device Identity
- IETF RFC 8995 — Bootstrapping Remote Secure Key Infrastructure (BRSKI), May 2021
- NIST Special Publication 1800-36 — Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management
- NIST Computer Security Resource Center Glossary — IDevID (sourced from NIST SP 1800-34B)
Frequently asked questions
What is IEEE 802.1AR?
IEEE 802.1AR is the IEEE standard for Secure Device Identity, titled "IEEE Standard for Local and Metropolitan Area Networks — Secure Device Identity." The current version, IEEE 802.1AR-2018, was approved by the IEEE Standards Association on 14 June 2018 and published 2 August 2018, superseding the original 802.1AR-2009. Per the IEEE 802.1 Security Task Group's own page, it specifies a cryptographically bound, per-device identifier (DevID) and the management of that identifier's relationship to subsequent locally administered identities, designed to work with existing and new provisioning and authentication protocols rather than inventing a new one of its own.
What is the difference between an IDevID and an LDevID?
An IDevID (Initial Device Identifier) is installed by the device's manufacturer at the factory, is globally unique, and is stored in a way that protects it from modification — it is the device's permanent, vendor-issued birth credential. An LDevID (Locally significant Device Identifier) is created afterward by a network administrator or operator and is cryptographically bound to the device so it cannot be forged or moved to different hardware without the private key that performed the binding, per the IEEE 802.1 Security Task Group's own description. In practice an IDevID proves "this is the device the manufacturer built"; an LDevID proves "this is the identity this specific network operator issued to that device," and a deployment can carry both at once — the LDevID enrollment itself is frequently authenticated using the IDevID as the trust anchor.
Does using IEEE 802.1AR DevID require a TPM?
No — 802.1AR specifies the identifier and its properties, not which hardware module has to store it. NIST's SP 1800-34 practice guide on validating computing device integrity documents one implementation where a Trusted Platform Module stores a TCG- and 802.1AR-compliant IDevID certificate for platform attestation, which is a common high-assurance pattern. But 802.1AR itself is hardware-agnostic: a secure element, a provisioned flash region with appropriate write protection, or any other tamper-resistant storage that meets the standard's "protected from modification" requirement for the IDevID can serve the same role, which is exactly why constrained IoT and OT devices without a discrete TPM can still implement DevID.
How does IEEE 802.1AR relate to BRSKI and IoT device onboarding?
IETF's RFC 8995 (Bootstrapping Remote Secure Key Infrastructure, BRSKI, published May 2021) uses the IDevID as its starting trust anchor. The RFC's own terminology section defines an IDevID as "an Initial Device Identifier X.509 certificate installed by the vendor on new equipment... a term from 802.1AR," and the protocol has a new device (a "pledge") present that certificate to a network registrar to authenticate itself, discover its Manufacturer Authorized Signing Authority (MASA) through a certificate extension BRSKI itself defines, and receive a voucher proving the network is authorized to enroll it — all before the device has any network-specific credentials of its own. NIST's SP 1800-36 practice guide on trusted IoT device onboarding builds directly on this: it describes a "birth credential" installed pre-market that, for a BRSKI-capable device, takes the form of exactly this 802.1AR IDevID certificate.
Is IEEE 802.1AR-2018 still current, or has it been replaced?
It is still the active, current version as of this guide's publication — IEEE 802.1AR-2009 was the version it replaced, not the other way around. Per the IEEE 802.1 Security Task Group's page, two pieces of further work are in progress on top of the 2018 base text: an approved amendment, IEEE 802.1AReg-2026, adding optional support for a Module-Lattice-Based Digital Signature Algorithm (a post-quantum signature scheme), and a full revision project, P802.1AR-2018-Rev, edited by Mick Seaman. Neither change alters IDevID/LDevID's core role; they add a newer signature algorithm option on top of the same identity model.
In this cluster
Questions about this page?