Authentication & Access Control Module Guide
Your guide: Shield Shelly
“A login tells you who arrived once. A trustworthy system keeps asking what this identity may do, from which device, for how long, and how access will end.”
Compare a technician and a headless field unit before choosing how each proves identity.
A technician opens the plant screen.
A field unit joins the same service.
They are different actors with different needs.
Match each actor to the right proof.
Prove Before You Permit
Authentication is often drawn as a neat gate: present a credential, receive a green tick, enter the system. An IoT estate is messier. People, gateways, services, sensors, and commissioning tools all claim identities. Some cannot type a password, some work while disconnected, and some remain deployed long enough for owners, firmware, and risk to change. Even a perfectly verified identity should not inherit every action, every resource, and an unlimited access window.
This module turns that gate into an operating design. You will separate identity, authentication, authorization, accounting, and revocation; compare credentials by the threat and device that must carry them; and decide how roles, attributes, capabilities, sessions, tokens, policy engines, and enforcement points cooperate. The zero-trust chapters then remove the comfortable assumption that being inside a network makes any of those claims safe.
Carry one scenario through the route: a water-treatment operator needs a maintenance system for human technicians, field gateways, and an analytics service. A technician may inspect all pumps at their assigned site, change a threshold only during an approved work window, and receive emergency shutdown authority for ten minutes. A gateway may publish its own telemetry but never command a neighbour. Your task is to make every allow and deny decision explainable after the event.
Learning Objectives
By the end of the route, you should be able to name the principal, credential, requested resource, permitted action, context, decision point, enforcement point, and audit evidence in an IoT access path. You should be able to distinguish authentication from authorization; select passwords, salted hashes, certificates and mutual TLS, signed tokens, or multi-factor methods for the identity actually being proved; and explain why a valid credential does not by itself grant a useful permission.
You should also be able to combine stable roles with contextual attributes or narrow capabilities, set access-token, refresh-token, idle-session, absolute-session, and elevation windows by consequence rather than convenience, and show how revocation ends authority early. For a zero-trust rollout, you should be ready to map protected resources, device identity evidence, allowed east-west paths, policy signals, enforcement ownership, legacy-device mediation, monitoring, and a staged transition that can be tested without trusting a slogan.
Before You Start
You do not need a cryptography course, but you should already recognise a client, server, API request, certificate, network segment, and log record. If the protocol path is unfamiliar, use Application Protocol Roles to identify where requests travel, and DTLS Threats and Authentication to separate transport protection from application permission. Encryption can protect a credential in transit without deciding whether its holder may stop a pump.
Start with a small vocabulary contract: an identity names a principal; a credential supplies evidence; authentication verifies that evidence; authorization evaluates a requested action; accounting preserves what happened; and revocation withdraws authority before its natural expiry. Keep those nouns separate whenever a chapter introduces JWT, OAuth, RBAC, ABAC, a capability, or zero trust. The module teaches design and evidence, not how to invent cryptographic algorithms or operate a public certificate authority from scratch.
A Worked Route Through the Module
First, write the identity and decision contract
Begin with Identity and Access Control Roadmap, then make the treatment-plant scenario concrete in Authentication and Authorization. Name three principals separately: technician Mara, gateway pump-gw-17, and the trend-analysis service. For each request write “who claims to act, what evidence proves it, which action is requested on which resource, who decides, who enforces, and what is logged.” That sentence exposes the common failure in which authentication succeeds and the application silently treats every authenticated principal as an administrator.
Continue to Authentication Methods for IoT and choose credentials by carrier and threat. Mara can use an organization identity with multi-factor authentication; the field gateway needs a unique device certificate and mutual TLS rather than a fleet-wide embedded password; the analytics workload needs its own service identity rather than Mara's token copied into a job. Record provisioning, secure storage, rotation, expiry, and compromise recovery beside each choice. A stronger login method with no lifecycle is merely a harder credential to replace badly.
Next, turn a proved identity into narrow, timed authority
Use Access Control for IoT to give Mara a maintenance role, then add site assignment, work-order state, device health, and current time as attributes. The role supplies a stable baseline; the attributes answer whether this request is appropriate now. Follow the OAuth device-flow animation to see why a browserless device can receive scoped authorization without asking a learner to type their main password into the controller. Keep the authorization server, resource server, user approval, access token, and protected pump API as distinct responsibilities.
Open Capability-Based Access Control for the emergency shutdown right. Model it as an unforgeable, narrow authority for one site and one action, delegable only by attenuation and valid for ten minutes. Then move to Operating Access Control and place time around the whole route: a short-lived access token on each API call, a protected and rotating refresh token, an idle timeout for a walked-away console, an absolute session limit even while active, and a separate elevation expiry. Signing prevents token alteration; it does not make a stolen bearer token instantly revocable, so choose a denylist, introspection, or server-side session state where prompt withdrawal matters.
Then, remove network location from the trust argument
Read Never Trust, Always Verify with pump-gw-17 already connected to the plant network. Its location is context, not proof. In Policy Engines and Enforcement Points, decide which signals reach the policy engine and where the decision is enforced close enough to stop an unsafe command. Use Proving Device Identity to join a unique credential with attestation, inventory, owner, firmware state, and lifecycle evidence; the provisioning visualizer belongs here because it reveals every hand-off that can accidentally create shared or orphaned identity.
Continue through Microsegmentation and East-West Control. Permit the gateway's telemetry path to its broker and the maintenance API path to the pump controller, while denying gateway-to-gateway commands that the scenario never requires. Finish the architecture route with Rolling Out Zero Trust in Stages: inventory first, pilot one protected resource, run policy in observation mode, compare expected and actual decisions, enforce with rollback criteria, and mediate legacy devices that cannot carry modern credentials. The policy builder and simulator should confirm the route you wrote, not invent it for you.
Finally, prove the design on a workbench
The three lab chapters turn the paper decision into evidence. In Lab: Access Control Setup, build the inspectable credential, GPIO, indicator, lockout, and audit-state boundary. In Lab: Access Control Implementation, implement valid, disabled, and unknown credentials plus rate limits and explicit deny behavior. Then use Lab: Access Control Advanced Topics to test session expiry, token refresh and revocation, privilege elevation, ABAC time windows, attestation, and the OAuth device flow.
Close with Debate: Security vs. Usability Trade-offs. Do not argue for maximum friction or frictionless access. Defend which extra proof is proportionate to a pump-reading request, a threshold change, and an emergency shutdown; state what happens when connectivity or a second factor is unavailable; and preserve a safe, auditable recovery route. Usability is part of the threat model because controls that operators routinely bypass are not strong controls.
Labs and Interactives
Place each interactive at the decision it can expose. Use the OAuth device-flow animation while assigning human approval to an input-constrained device, the provisioning visualizer while tracing device identity custody, and the zero-trust comparison while removing implicit network trust. Only then use the policy builder and simulator: enter Mara's role, site, work order, time window, device state, resource, and requested action; change one signal at a time; and explain the decision path before accepting the displayed result.
Keep one access-decision record across the three labs with principal, credential, session identifier, token issue and expiry times, idle and absolute deadlines, requested resource and action, policy inputs, allow or deny result, enforcement point, elevation end, revocation event, and audit outcome. Run the happy path once, then test a disabled credential, a replayed refresh token, an expired work window, a modified device, an attempted east-west command, and a revoked emergency capability. The record is complete only when every denial is visible to both the operator and the reviewer.
Quick Route Check
Mara authenticated with MFA at 08:00. At 14:20 she presents an unexpired token to stop a pump, but the approved work window ended at 14:00 and her ten-minute emergency elevation has expired. Should the API accept the command?
Reveal the route
No. Authentication proves Mara's identity and the token may prove an active session, but authorization must still evaluate this action, resource, time, attributes, and elevation state. The policy decision should deny the shutdown at its enforcement point, log the expired window and elevation as reasons, and direct Mara through a fresh approval path. If revocation or device-health evidence also changed, those independent controls should remain visible rather than being hidden behind “token valid.”