10 Proving Device Identity

10.1 Make the Device Prove Itself

Imagine a door controller joining a building network after a repair. Its label and network address do not prove that it is the approved controller. Device identity is evidence that a particular device is the one it claims to be.

Start by asking what the device can prove now. Check a protected secret, a signed record, or another trusted property. Then check its current software and allowed role before granting access. Test a copied name, an expired credential, and a device with unsafe software. Each failed check should lead to a limited and visible response.

Use a short identity review. Give the device one stable record. Protect the secret used for proof. Set a clear end date for that proof. Make renewal visible. Check the device state before access. Grant only the action its role needs. Record every denied attempt. Remove access when ownership changes. Plan for a lost or stolen device. Test how quickly one identity can be blocked. Make sure another device cannot copy its name and role.

A successful sign-in proves only one moment. Keep checking evidence during the session. Ask for fresh proof before a high-impact action. Stop or narrow access when the evidence becomes weak.

This small example does not make every device trustworthy forever. Identity, health, and permission can change after a connection begins. The Practitioner section shows how policy uses fresh device evidence. Under the Hood explains proof chains, renewal, and attack limits.

Start with a device at the edge of the network saying, "I am sensor 17." Zero trust does not accept the label, the address, or the subnet as proof. It asks the device to demonstrate control of the credential that belongs to sensor 17, then uses that proven subject in a narrower access decision.

Zero trust gives every access decision a subject, and for the Internet of Things that subject is the device. The core requirement is simple to state and easy to get wrong: a device must prove a unique identity before it reaches a protected resource, and the proof must rest on a secret the device controls, such as a private key, not on an address, hostname, subnet, serial number, or inventory label. A name can locate a device. Only control of a credential can prove the device is who it claims to be right now.

Two consequences follow. First, identity must be unique per device wherever the device can support it, because a single shared fleet credential means one compromise impersonates the entire class. Second, identity is not access. Proving who is asking is only the first step; the policy decision still has to check the resource, the action, the device's state, the purpose, and the context before allowing anything.

This overview also sets up the practitioner work: keep credentials unique, connect attestation to the credential lifecycle, use gateway mediation when roots of trust are weak, and check under the hood that the proof still belongs to the device.

Before choosing a credential mechanism, examine Figure to separate the claim of identity from the policy decision that follows it. The diagram matters here because it shows why possession of a name or network address cannot substitute for an authenticated subject and current device evidence.

In Figure, begin with IoT Device beside User Request: either entity is external to the trust decision, so arrival alone proves nothing. Their request reaches the central Policy Engine, where Identity Verification answers who controls the enrolled credential while Device Health, Context Analysis, and Risk Assessment qualify the present request. Only after those checks does Access Control lead to the Protected Resource; Continuous Monitoring shows that the decision is revisited rather than becoming permanent trust. This ordering explains why a serial number, MAC address, or DNS name can locate inventory but cannot authenticate it. The practitioner layer that follows therefore treats unique credentials, attestation evidence, rotation, and revocation as parts of one device-identity lifecycle.

The One-Minute View

Beginner Examples

Work from the simplest case toward the broader design consequence. First, A sensor on the expected Wi-Fi is not yet trusted; it must still prove control of its credential before it can upload. Next, A serial number identifies an inventory record, but anyone can read or copy one, so it is not authentication. Finally, "The device authenticated" answers who; it does not answer whether that device should perform the action it just requested.

Overview Knowledge Check

If you can explain why identity is proof of a secret and why identity is not the same as access, you have the core idea. Continue to Practitioner to run the lifecycle and choose credential patterns.

10.2 Run the Credential Lifecycle

Device identity is a lifecycle: define the device class, owner, resources, and required identity strength; enroll the device record before it joins the fleet; issue a credential bound to that identity, recording where the private key or secret lives; and operate it by authenticating, renewing, suspending, recovering, and retiring with evidence. A fleet can authenticate perfectly on day one and still fail later if renewal, suspension, and retirement are undefined.

Choose a Credential Pattern Deliberately

Different devices need different credential patterns; pick the weakest acceptable one only with a written reason and compensating enforcement. Inspect Figure to compare where each pattern keeps its proof material and which component remains accountable.

Read Figure from the asymmetric certificate path through symmetric, gateway-mediated, and short-lived assertion patterns. A certificate keeps a unique private key at the device; a symmetric pattern relies on a separately managed device secret; gateway mediation moves stronger proof to an accountable intermediary; and a short-lived assertion narrows exposure in time. The comparison leads directly to the ledger: record where proof lives, who operates it, and how it is revoked.

Authenticate Both Sides, Record the Failure Behavior

Read Figure from the asymmetric certificate path through symmetric, gateway-mediated, and short-lived assertion patterns. A certificate keeps a unique private key at the device, a symmetric pattern relies on securely managed per-device secrets, gateway mediation moves stronger proof to an accountable intermediary, and a short-lived assertion narrows exposure in time. Zero trust still verifies both ends and applies resource policy after proof. Record which identity each pattern represents, where its secret lives, and what happens when it is missing, expired, duplicated, or revoked.

Worked Reasoning: Environmental Monitoring Gateway

Constrained sensing endpoints sit behind local gateways, with a telemetry service, a command service, and an operations dashboard upstream. Name each subject (endpoint, gateway, telemetry service, command service, operator, provisioning automation), then write the failure behavior, which is where most designs are vague:

• Unknown endpoint identity: deny the upstream claim and record the local observation.
• Duplicated endpoint claim: suspend both until ownership is resolved.
• Gateway credential expired: deny upstream access except pre-approved local safety behavior.
• Attestation signal missing: allow only low-impact telemetry until review.
• Endpoint requests a command path: deny, because these endpoints are telemetry-only subjects.

Before accepting any design, run the checklist: identity is unique (no shared fleet identity), verifiable (proof uses secret control), scoped (identity does not equal access), and operable (renewal, suspension, recovery, and retirement have owners, triggers, and evidence).

Practitioner Knowledge Check

If you can run the lifecycle, choose a credential pattern with a reason, and write the failure behavior, you can stop here. Continue to Under the Hood for roots of trust, attestation, and lifecycle failure modes.

10.3 Where Device Identity Breaks

The deeper layer separates the pieces people blur together and explains where device identity actually breaks: how the secret is protected, what device state adds, and how the credential lifecycle fails.

Four Things People Call "Identity"

Precise designs keep four ideas distinct. The identifier is the name or inventory record (a device ID or serial number). The credential is the proof material (a certificate, key, token, or signed assertion). The authenticator is the mechanism that proves the credential is genuinely controlled by the device. The authorization context is the policy input that decides what the identity may do now. Confusing the identifier with the credential is the classic error: it leads teams to treat a readable serial number or an inventory entry as if it were proof of control.

Roots of Trust and Honest Claims

Identity strength is bounded by how well the secret is protected. Architectures should state the protection level per device class rather than assume one size: a key isolated in dedicated hardware such as a secure element or trusted platform module is strongest and can support attestation; a key protected by isolated platform execution is next; a software-held key is acceptable only when the residual extraction risk is accepted and enforcement limits the blast radius; and a gateway-held credential suits endpoints that cannot store strong keys at all. The discipline that matters is honesty: avoid marketing words like "unclonable" or "tamper-proof" unless the evidence supports them, and instead write precise statements such as "private key is hardware-isolated," "software-held secret accepted with a shorter lifetime and narrow access," or "gateway signs on behalf of the device group."

Attestation Adds State, Not Authorization

Identity answers "which device?" Attestation and device state answer "is this device in a condition that should receive access?" Useful signals include a boot or firmware measurement, configuration baseline state, credential and issuer status, the enrollment record, gateway observation for constrained devices, recent denied or unusual requests, and current update state. Inspect Figure to see why attestation adds state rather than authorization. A genuine device can still request a forbidden action, so policy must combine identity, state, resource, purpose, and context.

In Figure, follow the fresh challenge to the device's signed measurement and then to verification against an approved reference. The verifier can accept the evidence, quarantine the device, or deny the request, but that state result still enters a separate resource-policy decision. This distinction keeps a genuine, healthy device from receiving authority for an action it was never meant to perform.

The Credential Lifecycle Is Where Fleets Fail

In Figure, follow the device measurement and signed evidence into verification, then notice that the result becomes one input to a later policy decision. A valid measurement can raise confidence in device state, while a mismatch can trigger denial or remediation; neither outcome grants unrelated permissions. This keeps the running narrative precise as it moves to lifecycle failure: renewal, rotation, suspension, and retirement must preserve both trustworthy proof and narrow authorisation, and shared fleet credentials defeat that containment.

Mechanisms and Failure Modes

Common Pitfalls

Review these failure modes in order. First, Treating inventory as authentication. Inventory says what should exist; authentication proves what is asking now. Next, Sharing one credential across a fleet. Distinct per-device proof keeps a compromise narrow and investigable. Then, Forgetting renewal and retirement. A credential that cannot be renewed, suspended, or retired becomes a permanent exception. Then, Letting identity override authorization. A valid identity still has to pass an action, resource, state, and context check. Finally, Overclaiming hardware protection. State the real protection level instead of "unclonable" or "tamper-proof.".

Under-the-Hood Knowledge Check

At this depth, zero trust device identity is a verifiable, unique, and operable claim: a credential whose secret is protected at a stated level, proven by mutual authentication, enriched but not replaced by attestation, scoped by policy, and carried through a real renewal, suspension, and retirement lifecycle. A trustworthy review asks how the key is protected, whether identity is unique, what device state the decision uses, and how a credential is revoked when it must be.