2  Identity and Access Control Roadmap

Proving identity, granting permissions, and protecting IoT systems

Authentication and Access Control

Learn how IoT systems prove identity, issue trust, and limit what each user or device can do.

Learning Objectives

After completing this module, you will be able to:

• Explain the difference between authentication, authorization, and accounting.
• Choose practical authentication methods for IoT users, devices, gateways, and cloud APIs.
• Design access-control policies using RBAC, ABAC, least privilege, and default deny.
• Compare passwords, certificates, JWTs, MFA, API keys, and hardware-backed identities.
• Build and test simple access-control workflows before deploying them to real devices.

2.1 Why This Module Matters

An IoT system is not secure just because it uses encryption. The system must also know who is connecting, what that identity is allowed to do, and how to revoke access when something goes wrong.

This module focuses on the identity layer of IoT security. A smart lock, PLC, sensor gateway, medical monitor, or cloud dashboard all need the same basic chain:

1. Identify the user, device, service, or gateway.
2. Authenticate that the identity is genuine.
3. Authorize only the actions that identity needs.
4. Log and audit important access decisions.
5. Rotate or revoke credentials when risk changes.

For beginners, the key idea is simple: authentication answers “Who are you?” and access control answers “What are you allowed to do?” Both are required. If either one is weak, attackers can move from a single stolen password or device key into the rest of the IoT system.

2.2 Suggested Study Paths

Path	Best For	Start With	Then Study	Time
Beginner path	New students who need the mental model first	Authentication Fundamentals	Authentication Methods for IoT, then Access Control for IoT	3-4 hours
Builder path	Students implementing a prototype	Authentication and Access Control Overview	Access Control Fundamentals, then the basic lab chapters	5-7 hours
Security path	Students reviewing a real deployment	Secure Data Authentication	Secure Data and Software, then advanced access-control challenges	6-8 hours
Advanced path	Students designing production systems	Advanced Capabilities	Advanced Implementation, advanced access control, and advanced labs	8-12 hours

2.3 Visual Topic Map

Figure 2.1: Authentication and access control roadmap linking users, credentials, permissions, and IoT security protocols.

2.4 Chapter Guide

Area	Chapters	What You Should Be Able To Do
Core foundations	Authentication Fundamentals, Authentication Methods for IoT	Explain identity, credentials, password hashing, mTLS, JWT, MFA, and when each method fits.
Authentication plus authorization	Authentication and Access Control Overview, Access Control Index	Connect identity verification to permission decisions and audit trails.
Access-control models	Access Control Fundamentals, Access Control Concepts, Access Control for IoT, IoT Security Access Control	Compare RBAC, ABAC, least privilege, default deny, resource-level permissions, and policy evaluation.
Advanced identity patterns	Advanced Access Control, Access Control Challenges, Advanced Capabilities, Advanced Implementation	Handle token lifetimes, OAuth-style flows, capability tokens, key distribution, revocation, and scale.
Secure-data connections	Secure Data Authentication, Secure Data and Software	Protect credentials, firmware, data paths, and software update trust.
Hands-on labs	Basic Lab Setup, Basic Lab Implementation, Advanced Lab Concepts, Advanced Lab Implementation	Build and reason through RFID-style identity checks, policy decisions, and secure access workflows.

2.5 No-Hardware Learning Route

You can learn the main ideas without buying hardware:

• Use the diagrams to trace each request from identity proof to permission decision.
• Complete the knowledge checks and ordering exercises before reading the lab solution.
• Treat each code block as pseudocode first: identify the credential, the policy, and the final allow/deny decision.
• In lab chapters, focus on the workflow and security reasoning even if you cannot flash an ESP32.

When you later use hardware, the same process applies. The only difference is that credentials come from real devices, cards, keys, or certificates instead of examples on the page.

2.6 Common Beginner Mistakes

Mistake	Why It Causes Trouble	Better Habit
Using one shared password for every device	One compromised device exposes the whole fleet	Give every device a unique credential or certificate.
Treating login as the whole security system	Authenticated users may still need strict limits	Check authorization for every sensitive action.
Giving admin access “temporarily”	Temporary privileges often become permanent risk	Start with no access and add only what is needed.
Storing credentials in code or plaintext files	Firmware, backups, and logs can leak secrets	Use secure storage, hashing, signing, and rotation.
Ignoring audit logs	Breaches become invisible until damage is done	Log important access decisions and review anomalies.

2.7 Decision Checklist

Use this checklist when designing an IoT identity system:

1. What identities exist: users, devices, gateways, services, installers, guests?
2. What proof does each identity use: password, certificate, token, API key, badge, or biometric?
3. What can each identity do: read, write, control, configure, update, or administer?
4. What context changes the decision: time, location, network, risk level, maintenance window?
5. What happens when a credential is stolen or a device is retired?
6. How are access attempts logged, reviewed, and investigated?

Matching Quiz: Match Auth Module Sections to Focus Areas

Ordering Quiz: Order the Auth Module Study Sequence

Label the Diagram

2.8 What’s Next

Start with Authentication Fundamentals if you are new to the topic. If you already understand authentication and want practical implementation details, go directly to Authentication Methods for IoT and then Access Control for IoT.

Knowledge Check

Code Challenge

Navigation: Networking Fundamentals | Cryptography for IoT

2.9 Overview: Two Questions People Constantly Confuse

Access control rests on two different questions that beginners routinely merge into one. Authentication asks “who are you?” - it proves identity. Authorization asks “what are you allowed to do?” - it grants permissions. A system can authenticate you flawlessly and still must separately decide what you may touch.

Keeping them distinct is the foundation of the whole module. Logging in as yourself (authentication) does not entitle you to read someone else’s records (authorization). Mixing the two is the root of a large class of real security bugs, where a correctly logged-in user reaches data that was never theirs.

Intuition: authentication is showing your ID at the door; authorization is the guest list deciding which rooms your badge opens. Getting through the door is not the same as being allowed everywhere inside.

2.9.1 Overview Knowledge Check

2.10 Practitioner: Factors, MFA, and Access-Control Models

Authentication draws on three factors, and strong systems combine factor types:

Factor	Meaning	Examples
Something you know	A secret in your head	Password, PIN
Something you have	A physical possession	Phone, security key, smart card
Something you are	A biometric trait	Fingerprint, face

Worked example: what counts as multi-factor

Multi-factor authentication (MFA) = two or more DIFFERENT
factor types.

  password + SMS code         -> know + have  = real MFA
  password + security question -> know + know  = NOT real MFA
  fingerprint + hardware key   -> are + have   = real MFA

Mixing types matters: a phisher who steals your password
(know) still lacks your phone (have), so one theft is not
enough to get in.

Authorization then uses a model. The workhorse is role-based access control (RBAC): assign users to roles, and roles to permissions, so access is managed by role rather than per user. Attribute-based access control (ABAC) extends this with context (time, location, device state).

2.10.1 Practitioner Knowledge Check

2.11 Under the Hood: Different Failures, and the Identity Lifecycle

Because authentication and authorization are separate, they fail in separate ways - and both must be tested.

Two kinds of bug

An authentication flaw lets the wrong person in. An authorization flaw lets the right person do the wrong thing - privilege escalation, or accessing another user’s object by changing an ID (insecure direct object reference). Test both paths.

Least privilege

Grant the minimum permissions a role needs. Least privilege shrinks the blast radius: a compromised low-privilege account or token can do little, whereas over-broad grants turn any breach into a full compromise.

Revocation is the weak spot

Identities have a lifecycle: provision, rotate credentials, and - critically - revoke on role change or offboarding. Stale, un-revoked access is a leading cause of breaches; deprovisioning is as important as onboarding.

Log for accountability

Record who did what and when, so actions can be attributed (non-repudiation). Logs turn “someone changed this” into “this identity changed this at this time,” which is essential for both response and deterrence.

So the identity layer is five verbs, not one: identify, authenticate, authorize, log, and revoke. Authentication and authorization sit at its heart as distinct decisions, MFA hardens the first by mixing factor types, RBAC organises the second by role, and least privilege plus timely revocation keep the damage of any single failure small.

2.11.1 Under-the-Hood Knowledge Check

2.12 Summary

Authentication and access control provide the identity and permission layer for IoT security. The module covers device identity, user identity, authorization models, advanced credential patterns, and labs that test whether policies work under realistic conditions.

2.13 Key Takeaway

Secure IoT systems need identity for every actor and least-privilege access for every action. Design enrollment, authorization, audit, and revocation as first-class parts of the system.