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

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 is the 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 View Prove 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 shared Each device gets its own identity where it can; a shared fleet credential turns one compromise into fleet-wide impersonation.
Identity is not access A 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 the 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 compromise affects one device.
The secret cannot be easily extracted.

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.
Both device and service are verified.
Renewal, suspension, and retirement records with owners.

Major section

Where Device Identity Breaks (continued)

Roots of Trust and Honest Claims Identity strength is bounded by how well the secret is protected.

A genuine device can still request a forbidden action, so policy must combine identity, state, resource, purpose, and context.
The verifier can accept the evidence, quarantine the device, or deny the request, but that state result still enters a separate resource-policy decision.
Expired or stolen credentials cannot be revoked in time.

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 is the device.
The One-Minute View Prove 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 3

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

Q1Which statement best matches zero trust device identity?

AProve control of an approved credential before access.

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

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

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

Show answer

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

Retrieval practice

Recall check 2 of 3

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

Q2A 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 3 of 3

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

Q3To 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 whole fleet.

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.

A · Zero trust identity requires a verifiable proof of credential control, not just a name or a network location.
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.