Machines with passports: device identity

A Wi-Fi access point joins a company network. A smart plug joins your home. A payment terminal connects to its bank, and a car calls its manufacturer for an update. In each case, the other side needs to know: is this a genuine device, which model is it, which unit exactly, and who made it?

For years the answer was a password, often the same one for every unit of a model. Those passwords get printed in manuals, posted online and guessed by scanners. One leak opens every device.

A device certificate works much better. During manufacturing, each unit gets its own key pair. The private key is created inside a small security chip, a secure element or a TPM, and it is built never to leave that chip. The manufacturer’s CA then signs a certificate that binds the public key to the model and the serial number. The device carries that certificate for its whole life, like a passport issued at birth.

When the device connects, it shows its certificate and signs a fresh challenge with its private key. The other side checks the signature and checks that the certificate chains to the manufacturer’s CA. Copying the certificate is useless, because it is public anyway. Copying the private key is very hard, because the chip refuses to export it.

Often a second identity follows. When the device arrives at its new owner, the owner’s systems check the factory certificate and then issue their own certificate for daily use. The factory identity says “genuine sensor, serial 42731, made by Example Devices”. The owner’s identity says “our sensor in building 3”. Standards call these the IDevID (initial device identity) and the LDevID (locally significant device identity).

What a device certificate does not prove is just as important. It proves the hardware is genuine. It does not prove the firmware is up to date or that nobody has broken into the device since it left the factory. It also does not say who owns the device now.

The same idea, “trust one signing key instead of many individual keys”, fixes an old problem with SSH. Instead of copying every person’s public key to every server, an organisation can run a small SSH certificate authority.

What makes a device certificate different from a server certificate?

The format is the same X.509 you know from chapter 8. The differences are in where the key lives, what the names mean and how long the certificate lasts.

• The key lives in hardware. A TPM (Trusted Platform Module) is a security chip in most PCs and many servers. It ships with an endorsement key and, usually, an endorsement key certificate that the TPM or platform manufacturer issues during manufacturing, as described in the TCG EK Credential Profile. Embedded devices use secure elements or secure enclaves in the main chip. In each case the private key is generated inside and cannot be exported.
• The name is the hardware. The subject usually names the manufacturer, the model and a serial number. There is no domain name, so hostname rules do not apply.
• The lifetime can be “forever”. A device may sit in a warehouse for years and may never be able to renew. RFC 5280, section 4.1.2.5 uses exactly this example and says a certificate with no well-defined expiration date should use the notAfter value 99991231235959Z. The same section adds a condition: when the issuer can no longer keep status information, it must make sure no valid path to those certificates exists any more.
• The trust anchor is private. Verifiers trust the manufacturer’s root, or a list of approved manufacturer roots, not the public web roots.

What are IDevID and LDevID?

IEEE 802.1AR (IEEE 802.1AR-2018) standardises secure device identity. It defines a globally unique, manufacturer-provided Initial Device Identifier (IDevID), stored so that it is protected from modification, and Locally Significant Device Identifiers (LDevIDs) that a network administrator can create.

The usual pattern has three steps:

1. At the factory, the device generates its key pair and receives its IDevID certificate from the manufacturer’s CA.
2. At onboarding, the owner’s network checks the IDevID: genuine hardware from an approved manufacturer, and a serial number that the owner actually bought. Then the owner’s CA issues an LDevID, often to a new key pair.
3. In daily use, the device authenticates with the LDevID, for example to the network with 802.1X (EAP-TLS) or to services with mutual TLS. The LDevID can be renewed and revoked like any certificate the owner controls, and it does not reveal the factory serial number to every service.

Swipe sideways to see the whole diagram.

RFC 8995 (BRSKI) automates onboarding on IP networks. A new device, called the pledge, presents its IDevID to the owner’s registrar. A manufacturer service signs a “voucher” that tells the device which registrar to trust. The device then enrols for a local certificate, for example with EST (RFC 7030). RFC 8995 also deals honestly with two device realities: many devices do not know the current time when they first boot (section 2.6.1), and long-lived IDevIDs should use the “no expiry” date above (section 2.6.2).

How does a smart-home device prove it is genuine?

The Matter smart-home standard builds this into every certified product. Each device holds a Device Attestation Certificate (DAC), unique per device, with its private key in secure storage. The DAC is issued by a Product Attestation Intermediate (PAI), which chains to a Product Attestation Authority (PAA). The PAAs that home controllers trust are published in the Distributed Compliance Ledger, a shared database that the Connectivity Standards Alliance runs with its member companies.

When you add a device, your phone or hub acts as the commissioner and runs device attestation. It sends a fresh nonce. The device signs its attestation data and that nonce with the DAC’s private key and returns its certificates and a Certification Declaration, which the Alliance signs to confirm the product passed certification. The commissioner validates the chain to a trusted PAA, checks the signature and the nonce, and checks that the vendor and product IDs match. Only then does your home’s own CA issue the device an operational certificate (a Node Operational Certificate) for daily use. That is the IDevID and LDevID pattern again, in your living room. Google’s Matter primer walks through each check.

Swipe sideways to see the whole diagram.

How do SSH certificates fit in?

SSH normally uses bare public keys. The first time you connect, your client asks you to accept the server’s key fingerprint, which is “trust on first use”. Servers keep long authorized_keys files listing every user’s key. Both scale badly.

OpenSSH certificates solve this with a small PKI of their own. They are a different and much simpler format than X.509, as the ssh-keygen manual puts it. An SSH CA key signs a user’s or a host’s public key together with a key ID, a serial number, a list of principals (user names or host names) and a validity period. Servers then trust the CA key instead of individual user keys (TrustedUserCAKeys in sshd_config), and clients trust host certificates through a @cert-authority line in known_hosts. Short-lived user certificates, valid for hours, replace keys that live on servers forever.

What does a device certificate look like?

Here is a demo IDevID-style certificate from a test manufacturing CA. The subject names the product and its serial number, and the end date is the RFC 5280 “no well-defined expiration” value:

openssl x509 -in device.crt -noout -subject -issuer -dates

subject=O=Example Devices, CN=Sensor S-200, serialNumber=S200-00042731
issuer=O=Example Devices, CN=Example Devices Manufacturing CA
notBefore=Oct 20 00:00:00 2026 GMT
notAfter=Dec 31 23:59:59 9999 GMT

The demo used openssl ca with -enddate 99991231235959Z to set that exact end date. Real factories do the same thing in their manufacturing CA, with the CA key in an HSM and the device key generated on the chip.

Does my PC have a TPM?

On Windows, tpmtool reports the TPM without administrator rights (output shortened):

tpmtool getdeviceinformation

-TPM Present: True
-TPM Version: 2.0
-Ready For Attestation: True
-Is Capable For Attestation: True

Attestation means the TPM vouches for the machine with keys rooted in its endorsement key. Device management services can use it to check that a PC is genuine before they enrol it.

How do I set up SSH certificates?

Create a CA key once, keep it safe (ideally in a hardware token), and sign each user’s existing public key with an identity, principals and a short validity:

ssh-keygen -t ed25519 -f user_ca -C "ssh-user-ca"
ssh-keygen -s user_ca -I alex@example.com -n alex,deploy -V +8h -z 1001 id_ed25519.pub
ssh-keygen -L -f id_ed25519-cert.pub

        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:XRRXpVX3qKQZD2zuoBItjU45D23KImUQFn3NXWrWac8
        Signing CA: ED25519 SHA256:fgV8drS5C8GoVOYKkeCg3CEg8V6LizgUF+XYTpQDldo (using ssh-ed25519)
        Key ID: "alex@example.com"
        Serial: 1001
        Valid: from 2026-10-20T00:14:00 to 2026-10-20T08:15:51
        Principals: 
                alex
                deploy
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

On each server, trust the CA’s public key instead of individual user keys:

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub

For hosts, sign the server’s host key with -h and a host name as the principal, and give clients one line in known_hosts, as in the sshd manual:

@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...

The trust-on-first-use prompt disappears for every host whose key the CA signed.

What usually goes wrong with device identity?

• The same key in every unit. Some products ship one key or one certificate per model. One extracted key then impersonates the whole product line. Each unit needs its own key, generated on the chip.
• Keys in ordinary flash memory. If the private key can be read from storage, anyone with the device and a few tools can clone it. Use a secure element or TPM.
• No clock. A device that has just booted may think it is 1970, so every certificate looks “not yet valid”. Design onboarding so it can work without trusted time, as RFC 8995 does, and fetch trusted time afterwards.
• No plan for the manufacturer CA. A factory root may have to last for decades. Keep it offline in an HSM, plan how to replace it, and decide which algorithm it will use when post-quantum signatures arrive.
• Forgetting the end of life. When a device is sold, returned or scrapped, revoke its LDevID and remove it from your inventory. The IDevID stays with the hardware.

Paste a device certificate into the decoder to see its subject attributes, its issuer and its end date:

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

Common mistakes

• “Devices can share one password or one key per model.” One leak then breaks every unit. Each device needs its own key pair and certificate.
• “A device certificate proves the device is secure.” It proves the hardware is genuine and holds the key. It says nothing about the firmware running on it today.
• “A certificate that never expires is a mistake.” For a factory IDevID, RFC 5280 provides the 99991231235959Z value on purpose. The certificates a device uses every day should still be renewable.
• “SSH has nothing to do with PKI.” OpenSSH certificates are a small PKI: a CA key, signed keys, principals, validity and revocation.
• “The private key can live in a file on the device.” Then it can be copied. Hardware that never exports the key is what makes a device identity worth trusting.

Check yourself

Check yourself

A device sends its factory certificate to your server. What must the device also do to prove it is that device?

1. Send the certificate twice
2. Sign a fresh challenge with the private key held in its secure chip
3. Show a serial number that matches the certificate

Show answer

Answer B Sign a fresh challenge with the private key held in its secure chip

What happened

It must sign a fresh challenge (nonce) with its private key.

Why

The certificate is public and can be copied. Only the chip holding the private key can make a valid signature over a fresh challenge.

The rule

Identity is proven by possession of the private key, never by showing a certificate.

Check yourself

What is the difference between an IDevID and an LDevID?

1. The IDevID is installed by the manufacturer; the LDevID is issued by the owner for local use
2. The IDevID is for IPv4 and the LDevID for IPv6
3. The LDevID is a backup copy of the IDevID's private key

Show answer

Answer A The IDevID is installed by the manufacturer; the LDevID is issued by the owner for local use

What happened

IEEE 802.1AR defines the IDevID as the manufacturer-provided identity and LDevIDs as identities a network administrator creates.

Why

The factory identity proves the hardware is genuine; the local identity is what the owner manages, renews and revokes.

The rule

Check the factory identity once at onboarding, then use an identity you control.

Check yourself

Why do many factory device certificates use 31 December 9999 as their end date?

1. It is a bug in old software
2. RFC 5280 defines it as the value for certificates with no well-defined expiration date
3. It makes the certificate trusted by browsers

Show answer

Answer B RFC 5280 defines it as the value for certificates with no well-defined expiration date

What happened

RFC 5280 section 4.1.2.5 says such certificates should use 99991231235959Z.

Why

A device may be stored for years and may never be able to renew its factory identity.

The rule

Long-lived factory identities are fine if the daily-use identity can be renewed and the CA is guarded for the long term.

Go deeper

• IEEE 802.1AR Secure Device Identity: the IDevID and LDevID model, and the revision in progress.
• RFC 5280, section 4.1.2.5: validity periods, including certificates for the lifetime of a device.
• RFC 8995: BRSKI, zero-touch onboarding with manufacturer-installed certificates and vouchers.
• RFC 7030: Enrollment over Secure Transport (EST), a standard way for devices to request certificates.
• TCG EK Credential Profile: how TPM endorsement key certificates are built and issued.
• Google Home Developers: Matter device attestation and fabrics: the DAC chain, the Distributed Compliance Ledger and operational certificates. The normative text is the Matter specification, a free download from the Connectivity Standards Alliance after registration.
• ssh-keygen(1), CERTIFICATES and sshd_config(5): OpenSSH user and host certificates.

In the gameLevel 25: Machines with passportsClockmaker's Factory, Keystone. In development

The crash course covers this chapter in lesson 10, Beyond the browser, and what comes next.