Authentication & Access · Study deck

Proving Device Identity

Imagine a door controller joining a building network after a repair.

Shield Shelly is your guide for this deck.

zero-trustdevice-identitydevice-attestation

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: 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.
Explain: 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.
Explain: 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.

Major section

Make the Device Prove Itself

Its label and network address do not prove that it is the approved controller.

Each failed check should lead to a limited and visible response.
Grant only the action its role needs.
This small example does not make every device trustworthy forever.
Identity, health, and permission can change after a connection begins.

Zero-trust architecture: a request from a user or IoT device passes through a policy engine that weighs identity verification, device health, context, and risk before granting least-privilege access to a protected resource, under continuous monitoring.

Major section

Make the Device Prove Itself (continued)

The Practitioner section shows how policy uses fresh device evidence.

Under the Hood explains proof chains, renewal, and attack limits.
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.
A name can locate a device.
Second, identity is not access.

Major section

Make the Device Prove Itself (continued)

Zero trust gives every access decision a subject, and for the Internet of Things that subject may be a device.

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.
Identity is the reliable subject zero trust needs, but it is a lifecycle to run, not a sticker applied once at the factory.
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.

Major section

Make the Device Prove Itself (continued)

The One-Minute ViewProve a secret, not a name Access depends on control of a private key or secret, not on an address, hostname, or asset label.

Unique, not sharedEach device gets its own identity where it can; a shared fleet credential turns one compromise into fleet-wide impersonation.
Identity is not accessA verified identity still has to be authorized for the specific resource, action, state, and context.
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.

Major section

Run the Credential Lifecycle

A fleet can authenticate perfectly on day one and still fail later if renewal, suspension, and retirement are undefined.

Devices that can hold and use a private key.
Key custody and the certificate lifecycle must be managed.
Constrained devices that cannot do asymmetric work.
A shared secret both sides hold; practical and lightweight.

Credential pattern selection for IoT device identity showing certificates, shared secrets, gateway mediation, and short-lived assertions.

Major section

Run the Credential Lifecycle (continued)

If you can run the lifecycle, choose a credential pattern with a reason, and write the failure behavior, you can stop here.

Provisioning and revocation are harder; never share one secret fleet-wide.
Endpoints that cannot authenticate directly.
Gateway authenticates upstream and carries a locally verified endpoint claim.
Scoped access after the underlying proof is checked.

Major section

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).

Device attestation decision: a fresh nonce elicits signed measured evidence; the verifier checks certificate chain, freshness, reference values, and policy before issuing a scoped allow, quarantine, or deny decision. Attestation is point-in-time evidence, not permanent trust.

Major section

Where Device Identity Breaks (continued)

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.
One extracted device credential does not directly impersonate other devices.

Major section

Where Device Identity Breaks (continued)

A genuine device is allowed an action it should not do.

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.
The secret cannot be easily extracted.
Both device and service are verified.

Major section

Where Device Identity Breaks (continued)

The verifier can accept the evidence, quarantine the device, or deny the request, but that state result still enters a separate resource-policy decision.

Roots of Trust and Honest ClaimsIdentity strength is bounded by how well the secret is protected.
Renewal, suspension, and retirement records with owners.
Expired or stolen credentials cannot be revoked in time.

Major section

Where Device Identity Breaks (continued)

A genuine device can still request a forbidden action, so policy must combine identity, state, resource, purpose, and context.

This distinction keeps a genuine, healthy device from receiving authority for an action it was never meant to perform.
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.

Deck summary

Key takeaways

Its label and network address do not prove that it is the approved controller.

The Practitioner section shows how policy uses fresh device evidence.
Zero trust gives every access decision a subject, and for the Internet of Things that subject may be a device.
The One-Minute ViewProve a secret, not a name Access depends on control of a private key or secret, not on an address, hostname, or asset label.
A fleet can authenticate perfectly on day one and still fail later if renewal, suspension, and retirement are undefined.

Retrieval practice

Recall check 1 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q1Which statement best matches zero trust device identity?

AA device is trusted once it appears on the expected local network

BA serial number is enough, because it is unique in inventory

COne identity can be shared by every device of the same type

DProve control of an approved credential before access.

Show answer

Answer: D Zero trust identity requires a verifiable proof of credential control, not just a name or a network location.

Retrieval practice

Recall check 2 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q2A device has a valid credential but no fresh health evidence. How should access policy use the missing attestation signal?

AGrant every command because the credential is valid.

BReplace the device identifier with its MAC address.

CIgnore missing attestation indefinitely, because previously healthy evidence remains valid.

DLimit it to low-impact telemetry until its state is reviewed.

Show answer

Answer: D Identity alone does not prove current device health or authorize sensitive actions.

Retrieval practice

Recall check 3 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q3A constrained endpoint cannot perform direct certificate authentication. What should the architecture do?

ATrust every endpoint behind the gateway because the gateway is trusted

BLet the endpoint use its network address as authentication proof

CSkip logging because the endpoint is too constrained to log

DUse a gateway that preserves endpoint identity.

Show answer

Answer: D Gateway mediation lets constrained endpoints participate in zero trust while preserving per-endpoint accountability and enforcement.

Retrieval practice

Recall check 4 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q4To simplify provisioning, a vendor ships an entire device class with one identical embedded private key. What is the zero trust failure, and the fix?

AOne extracted key impersonates the fleet; provision distinct device keys.

BIt is acceptable, because the key is embedded in firmware where users cannot see it

CIt is fine as long as the shared key is rotated on a schedule

DEncrypting the shared key at rest fully resolves the problem

Show answer

Answer: A Shared fleet credentials make one compromise fleet-wide and impossible to scope or revoke individually.

Print reference

Answers

Answer key.

D · Zero trust identity requires a verifiable proof of credential control, not just a name or a network location.
D · Identity alone does not prove current device health or authorize sensitive actions.
D · Gateway mediation lets constrained endpoints participate in zero trust while preserving per-endpoint accountability and enforcement.
A · Shared fleet credentials make one compromise fleet-wide and impossible to scope or revoke individually.