4 IoT Access Control: Models and Policy

4.5.1 The Rulebook in One Minute

• DAC and MAC: DAC lets owners grant access; flexible but hard to govern. MAC enforces a central policy; rigid but strong for classified systems.
• RBAC: Group permissions into roles and assign roles to identities. The practical sweet spot when job categories are stable.
• ABAC: Decide from attributes and context (time, location, device state). Best when decisions are dynamic or multi-tenant.

4.5.2 Everyday IoT Examples

Work from the simplest case toward the broader design consequence. First, a new device should join with no permissions and be granted only what it needs, rather than full access pending review. Next, “Operators can use the dashboard” is a role grant; “operators can use it only during their shift, from the control room” adds attribute rules on top. Finally, giving every device the same broad permissions is convenient but means one compromised device can reach everything.

4.5.3 Overview Knowledge Check

If you can name the models and the least-privilege principle behind them, you have the overview. Continue to Practitioner to choose a model and provision device identity without turning a good login into a broad standing grant.

4.6.1 RBAC Versus ABAC

4.6.2 OAuth 2.0 for IoT: Delegated Authorization

OAuth 2.0 is an authorization framework, not an authentication method. It lets a device receive a scoped, short-lived access token instead of holding a user’s password, so even an intercepted token is limited and expires. If you also need to know who the user is, that is the job of OpenID Connect (OIDC), the identity layer built on OAuth. Choose the grant type by the device’s situation:

• Device Authorization Grant (the device code flow, RFC 8628): for input-constrained devices with no browser — the user approves on a phone while the device polls.
• Client Credentials: for machine-to-machine access where the device authenticates as itself, with no user present.
• Authorization Code with PKCE: for mobile companion apps where a user and a browser are involved; PKCE prevents interception of the authorization code.
• Refresh Token: to obtain new short-lived access tokens without repeating the full flow.

Avoid the Implicit and Resource Owner Password Credentials grants; both are discouraged and removed in OAuth 2.1. For a device with no user at all, a pre-provisioned device certificate is often a better fit than any OAuth flow.

4.6.3 Worked Example: Layering RBAC and ABAC in a Smart Building

Consider a commercial building with networked door locks, HVAC across many floors, lighting zones, and multiple tenants. A workable design layers the models. First, define coarse roles: building admin, tenant admin, maintenance, security, tenant employee, and visitor, each with a baseline permission set (a tenant admin manages only their own tenant). Then add ABAC contextual gates: an employee’s door access also requires a tenant match, business hours, and a normal threat level; after-hours maintenance requires an active work order covering that specific resource; a visitor requires a present escort and a non-expired badge. Apply least-privilege patterns — just-in-time grants, time-bounded privileges, approval workflows, and default deny — and record, in the audit log, which policy decided each access. The lesson is that roles give a clean baseline while attributes enforce the situational rules roles cannot express.

4.6.4 Provisioning Device Identity

Authorization is only as trustworthy as the identity behind it, so device identity must be provisioned deliberately. A practical checklist: give every device a unique identity (never a shared fleet credential); generate and keep the private key inside a secure element so it never leaves the hardware; separate the one-time bootstrap credential from the long-lived operational credential; scope each device’s policy to its own resources and tenant rather than using wildcards; and plan renewal and revocation before the first device ships. At the platform level, distinguish human identity and access management (IAM) from the management of machine and device identities, which have their own enrolment and lifecycle.

Figure 4.2 is worth following before writing a fleet policy because it shows that identity is maintained across the device’s whole service life, not installed once and forgotten.

Inspect Figure 4.2 now to connect the credential choices in Shelly’s ledger to the points where a fleet must issue, use, and withdraw them.

Read Figure 4.2 from manufacture through decommission. A unique key is first provisioned, deployment binds that key to an approved device record, operation repeatedly authenticates the device before applying its scoped policy, and decommission revokes the credential and removes residual secrets. Missing any stage weakens authorisation: an unbound key has no accountable owner, an unrenewable certificate becomes an outage, and an unrevoked retired device retains a path back into the service.

4.6.5 Cloud Authorization in Practice

Cloud IoT platforms enforce these ideas with policy. On AWS IoT Core, scope each device to its own message topics using a policy variable bound to the device’s identity (such as its Thing name), and add an explicit deny for cross-device access; a sensor should publish only its own telemetry and never another device’s commands. On Azure IoT Hub, assign the narrowest built-in role that does the job — for example a data-reader role rather than a data-contributor role — even when a broader role would also work. The common discipline is the same: grant the minimum, scope per device, and prefer explicit denies for anything cross-tenant.

4.6.6 Practitioner Knowledge Check

If you can choose a model, pick an OAuth grant, and provision per-device identity, you can stop here. Continue to Under the Hood for how policies evaluate and how the certificate lifecycle fails.

4.7.1 How ABAC Evaluates a Request

An ABAC engine decides in steps. It first collects attributes from four sources: the subject (role, department, clearance, whether MFA was used), the resource (owner, sensitivity, criticality, location), the action (read, write, control, configure), and the environment (time, day, network zone, threat level). It then selects policies that match the requested action and evaluates each policy’s conditions, all of which must be true. The decisive rules are precedence and default: an explicit deny overrides any allow, and if no policy grants access the request is denied by default. Every decision is logged. This is why ABAC scales: expressing a new rule means adding an attribute or condition, not minting a new role.

4.7.2 How Cloud Policies Evaluate

Cloud IoT policy engines work the same way at heart. Each statement is checked for an action match and a resource match; an explicit Deny always wins over any Allow, and if nothing allows the action it is implicitly denied. The powerful part is the runtime substitution of the device’s own identity into the policy — for instance, binding a topic to the connecting device’s Thing name — so the same policy text gives each device access only to its own resources, and one device cannot publish as another.

4.7.3 The Certificate Lifecycle, Stage by Stage

Certificate-based device identity has a lifecycle, and each stage has a failure to avoid:

• Manufacturing: generate the key pair inside a secure element. Failure to avoid: shipping the same key in every device.
• Enrolment: the device sends a certificate signing request and proves it is genuine with a one-time bootstrap secret. Failure to avoid: issuing a certificate to anyone who merely reaches the enrolment endpoint.
• Activation: the device receives an operational certificate and a scoped policy. Failure to avoid: attaching broad wildcard permissions.
• Operation: the device authenticates with mutual TLS and each action is authorized. Failure to avoid: assuming that being authenticated also means being authorized.
• Renewal: renew well before expiry, and only for healthy, non-revoked devices. Failure to avoid: letting a quarantined device silently regain access, or letting certificates lapse and brick the fleet.
• Revocation: publish the revocation and remove the device from its policy groups. Failure to avoid: leaving a decommissioned device’s credentials active.

Enrolment and renewal are commonly automated with EST (RFC 7030), preferred over the older SCEP. On constrained devices, ECDSA on a curve such as P-256 is often chosen over RSA because it yields much smaller keys and signatures and faster signing, which saves flash, bandwidth, and energy — note that RSA verification can actually be faster, so the win is size and signing, not verification speed.

4.7.4 Blast Radius and Token Identifiers

The damage a compromised device can do scales with the breadth of its permissions: a device scoped to its own telemetry is a small blast radius, while a device holding wildcard rights is a large one. The same logic applies to identifiers — use long random token or session identifiers (at least 128 bits) so they cannot be guessed or collide across a large fleet.

4.7.5 Mechanisms and Failure Modes

4.7.6 Common Pitfalls

Review these failure modes in order. First, Keys in firmware instead of a secure element. Extractable keys turn one device into a fleet-wide impersonation path. Next, No revocation checking. Without CRL or OCSP, a revoked or stolen certificate keeps working. Then, Renewing only at expiry. Renew well before expiry, or devices that miss the window go offline. Then, Uniform permissions across device types. A weather sensor and a valve actuator should not share a policy; scope to each role. Then, Wildcard development policies in production. A convenient “allow all” left in place is a standing breach. Finally, Treating OAuth as authentication. OAuth authorizes; use OIDC if you need to authenticate the user.

4.7.7 Under-the-Hood Knowledge Check

At this depth, access control is policy evaluated consistently — deny overrides allow, default deny, identity bound at runtime — resting on device identity that is provisioned in hardware, scoped to the minimum, renewed before expiry, and revoked on retirement. A trustworthy review traces a request through the policy and traces a device through its certificate lifecycle, rather than trusting a single broad grant.