9  Access Control for IoT

9.1 Learning Objectives

By the end of this chapter, you should be able to:

• Distinguish between authentication and authorization
• Implement Role-Based Access Control (RBAC) for IoT platforms
• Design Attribute-Based Access Control (ABAC) policies for context-aware security
• Apply the principle of least privilege to IoT deployments
• Create comprehensive audit trails for compliance and forensics

For Beginners: Understanding Access Control

What is Access Control? Access control determines what authenticated users and devices are allowed to do. While authentication proves “who you are,” authorization (access control) determines “what you can do.”

Real-world analogy:

• Authentication: Showing your employee badge to security (proving identity)
• Authorization: Your badge only opens doors to YOUR department (controlling access)

Key terms: | Term | Definition | |——|————| | Authorization | Determining what actions an authenticated entity can perform | | RBAC | Role-Based Access Control - permissions assigned by role (Admin, Operator, Viewer) | | ABAC | Attribute-Based Access Control - permissions based on attributes (time, location, clearance) | | Least Privilege | Granting only minimum permissions necessary for a task | | ACL | Access Control List - explicit list of who can access what |

Sensor Squad: The Permission Ladder!

“Access control is about answering ONE question: should this request be allowed?” Max the Microcontroller stated. “There are different models for making this decision, and each one works differently.”

Sammy the Sensor described the models. “RBAC – Role-Based Access Control – is the most common. It is like job titles at a company. The ‘Operator’ role can read sensors and control actuators. The ‘Viewer’ role can only read. The ‘Admin’ role can do everything. Simple and effective for most IoT systems!”

“ABAC – Attribute-Based Access Control – is more flexible,” Lila the LED added. “Instead of just checking your role, it also checks attributes like time of day, your location, and the current device state. A maintenance worker might have full access during business hours from inside the factory, but read-only access from home at night. The policy considers CONTEXT, not just identity.”

“The most important principle is Least Privilege,” Bella the Battery emphasized. “Every user and device should have the MINIMUM permissions needed to do their job – nothing more. A temperature sensor does not need access to the door lock system. A guest viewer does not need the ability to change settings. By keeping permissions tight, even if one account gets compromised, the damage is limited to what that account was allowed to do.”

9.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Authentication Methods: How to verify identity before checking permissions
• Defense in Depth: Where authorization fits in security layers

How It Works: Access Control Decision Flow

Access control operates in two distinct phases that work together to protect IoT systems:

Phase 1: Authentication (Who are you?)

1. Credential Presentation: User or device presents credentials (password, certificate, token)
2. Identity Verification: System validates credentials against stored database
3. Outcome: Returns authenticated identity OR rejects with 401 Unauthorized

Phase 2: Authorization (What can you do?)

1. Permission Lookup: System retrieves permissions for authenticated identity
2. Policy Evaluation: Checks if requested action matches granted permissions
3. Context Check (ABAC only): Evaluates time, location, device state attributes
4. Outcome: Grants access OR rejects with 403 Forbidden

Real-World Example: Smart home door lock

• Authentication: User scans fingerprint, system verifies fingerprint matches stored template, user identified as “Alice”
• Authorization: System checks Alice’s permissions, Alice has “unlock front door” permission, door unlocks
• If Bob (Guest) tries same action, authentication succeeds but authorization fails (no unlock permission), and the door stays locked

Key Insight: Authentication happens ONCE per session. Authorization happens for EVERY action. A compromised authenticated session can still be limited by authorization policies (principle of least privilege).

9.3 Authentication vs Authorization

Understanding the distinction between authentication and authorization is critical:

Aspect	Authentication	Authorization
Question answered	“Who are you?”	“What can you do?”
When it happens	First (before authorization)	Second (after authentication)
HTTP error code	401 Unauthorized	403 Forbidden
Example	Login with username/password	Check if user can delete devices
Failure meaning	Identity not verified	Identity verified but lacks permission

Figure 9.1: Access control decision flow showing authentication then authorization

9.4 Role-Based Access Control (RBAC)

RBAC assigns permissions based on predefined roles. Users inherit permissions from their assigned roles, implementing the principle of least privilege.

9.4.1 RBAC Permission Matrix

Example: Smart Home Platform

Role	Read Sensors	Control Actuators	Manage Devices	Write Data	Admin Panel
Admin	Yes	Yes	Yes	Yes	Yes
User	Yes	Yes	No	No	No
Device	No	No	No	Yes	No
Guest	Yes	No	No	No	No

9.4.2 RBAC Authorization Flow

Figure 9.2: RBAC authorization flow showing role-based permission checking

9.4.3 Real-World Example: Smart Lock Access Control

• Homeowner (Admin): Can unlock door, add users, view logs, delete access codes
• Family Member (User): Can unlock door, view logs (but cannot add/remove users)
• Guest (Temporary): Can unlock door during specified dates only
• Cleaning Service (Scheduled): Can unlock door on Tuesdays 9am-11am only (requires ABAC time-window policy layered on the RBAC role)

Minimum Viable Understanding: Least Privilege

Core Concept: The principle of least privilege grants users, devices, and processes only the minimum permissions necessary to perform their intended functions, nothing more. Why It Matters: When credentials are compromised (inevitable in large IoT deployments), damage is limited to what that account could access; an HVAC sensor with read-only temperature permissions cannot be used to unlock doors or exfiltrate customer data. Key Takeaway: Design permission structures starting from zero access and add only what is required; audit permissions quarterly and remove any that are unused.

9.5 Attribute-Based Access Control (ABAC)

ABAC makes access decisions based on multiple attributes of the subject, resource, action, and environment. This enables fine-grained, context-aware access control.

9.5.1 ABAC Decision Factors

Factor	Attributes	Example
Subject	User ID, role, department, clearance level	user_id=“123”, role=“engineer”, dept=“manufacturing”
Resource	Device ID, owner, sensitivity, location	device_id=“sensor-42”, owner=“123”, sensitivity=“high”
Action	Read, write, control, delete, configure	action=“read” or “control_actuator”
Environment	Time of day, location, IP address, threat level	time=“14:00”, location=“office”, threat_level=“low”

9.5.2 ABAC Policy Evaluation

Figure 9.3: ABAC policy evaluation with multiple attribute conditions

9.5.3 Example ABAC Policies for Smart Building

Policy	Conditions	Result
Policy 1: Own Devices	IF user.id == device.owner AND action == “read”	ALLOW
Policy 2: Admin Hours	IF user.role == “admin” AND 9am <= time <= 5pm	ALLOW
Policy 3: Emergency Override	IF user.role == “security” AND threat_level == “high”	ALLOW ALL
Policy 4: Geo-Fencing	IF device.location == “restricted_area” AND user.clearance < “high”	DENY
Default Policy	IF no rules match	DENY

9.5.4 RBAC vs ABAC Comparison

Feature	RBAC	ABAC
Granularity	Role-based (coarse)	Attribute-based (fine-grained)
Flexibility	Low (static roles)	High (dynamic conditions)
Complexity	Simple	Complex
Use Case	Small teams, stable permissions	Large organizations, context-aware access
Example	“All admins can delete devices”	“Admin can delete devices owned by their department during business hours from office IP”

Tradeoff: RBAC vs ABAC

Option A (RBAC):

• 5-10 predefined roles (Admin, Operator, Viewer, Device, Guest)
• Implementation cost: ~40 hours
• Policy changes require code deployment
• Audit complexity: Low

Option B (ABAC):

• Dynamic attribute evaluation
• Implementation cost: ~200 hours
• Policy changes via configuration
• Audit complexity: High

Decision Factors: Choose RBAC when team size is under 50 users, permissions are stable, and development resources are limited. Choose ABAC when you need context-aware decisions (time, location, threat level), when managing 100+ users across departments, or when regulatory requirements demand fine-grained audit trails.

Hybrid approach: Start with RBAC for 80% of use cases, layer ABAC policies for edge cases requiring contextual decisions.

Real-world lesson – Target breach (2013): Attackers compromised Target’s HVAC vendor (Fazio Mechanical) via a phishing email. The vendor had been given network credentials for remote HVAC monitoring, but those credentials provided lateral access to Target’s payment processing network – a classic RBAC failure where a “vendor” role had broader permissions than its function required. ABAC policies checking IF vendor.access_scope == "HVAC" AND target_network == "payment_processing" THEN DENY would have blocked the pivot. The breach cost Target approximately $162 million in expenses and affected roughly 40 million customer payment cards. This single incident demonstrated why IoT device networks (HVAC, lighting, elevators) must be segmented from business-critical networks, and why vendor access should be scoped by function, not by a generic “partner” role.

9.6 Worked Example: Smart Building Access Control Design

Scenario: A commercial office building is deploying a smart building system with IoT-controlled door locks on 200 doors, HVAC systems across 15 floors, and lighting controls in 500 zones. Multiple tenant companies, maintenance staff, and daily visitors need access.

9.6.1 Step 1: Identify Roles and Resources

User roles:

Role	Count	Primary Responsibilities
Building Admin	3	Full system configuration, emergency override
Tenant Admin	12	Manage access for their company’s employees
Maintenance Staff	8	Access mechanical rooms, HVAC controls
Security Guard	6	Monitor access logs, issue visitor badges
Tenant Employee	~2,000	Access to own company’s floor/zones
Visitor	~50/day	Escorted access to specific meeting rooms

9.6.2 Step 2: Design RBAC Permission Matrix

Permission	Admin	Tenant Admin	Maintenance	Security	Employee	Visitor
Unlock all doors	Yes	No	No	No	No	No
Unlock tenant doors	Yes	Own tenant	No	No	Own tenant	Escorted
Unlock utility rooms	Yes	No	Yes	No	No	No
Modify HVAC settings	Yes	Own zones	Yes	No	No	No
Control lighting	Yes	Own zones	Yes	No	Own zones	No
View access logs	Yes	Own tenant	No	Yes	No	No
Create user accounts	Yes	Own tenant	No	No	No	No
Emergency override	Yes	No	No	Yes	No	No

9.6.3 Step 3: Add ABAC Contextual Policies

# Employee door access policy
IF user.role == "Employee"
AND resource.type == "TenantDoor"
AND resource.tenant == user.tenant
AND (time.hour >= 6 AND time.hour <= 22)
AND building.risk_level != "Lockdown"
THEN ALLOW
ELSE DENY

# Maintenance after-hours access policy
IF user.role == "Maintenance"
AND resource.type IN ["UtilityRoom", "HVAC", "TenantDoor"]
AND user.has_active_work_order == True
AND work_order.covers_resource(resource.id)
THEN ALLOW
ELSE DENY

# Visitor escorted access policy
IF user.role == "Visitor"
AND user.escort.is_present == True
AND user.escort.role IN ["Employee", "TenantAdmin"]
AND resource.id IN user.approved_resources
AND time.current < user.badge_expiry
THEN ALLOW
ELSE DENY

9.6.4 Step 4: Implement Least Privilege

Pattern	Implementation	Example
Just-in-time access	Maintenance gets access only during work order	Work order 08:00-12:00 grants HVAC access
Time-bound privileges	Visitor badges expire after meeting	2-hour badge for conference room
Approval workflows	After-hours access requires manager approval	Employee requests weekend access
Default deny	New users start with zero permissions	Badge activates after onboarding

9.6.5 Step 5: Comprehensive Audit Logging

{
  "event_id": "uuid-v4",
  "timestamp": "2026-01-10T14:32:15.234Z",
  "event_type": "ACCESS_ATTEMPT",
  "outcome": "GRANTED",
  "user": {
    "id": "emp-12345",
    "role": "Employee",
    "tenant": "Acme Corp"
  },
  "resource": {
    "id": "door-floor5-main",
    "type": "TenantDoor",
    "location": "Floor 5, Main Entrance"
  },
  "context": {
    "time": "14:32:15",
    "day_type": "weekday",
    "risk_level": "normal"
  },
  "policy_evaluation": {
    "policies_checked": ["RBAC-Employee", "ABAC-TimeWindow"],
    "deciding_policy": "RBAC-Employee"
  }
}

9.7 Common Pitfalls

Pitfall: Overprivileged Default Accounts

The mistake: Deploying IoT devices with default accounts that have administrator privileges, assuming “we’ll lock it down later.”

Symptoms:

• Service accounts with full admin rights when they only need read access
• IoT devices with “admin/admin” credentials never changed
• API keys with wildcard permissions (*:*)

The fix: Implement least privilege from day one. Create RBAC policies that grant only minimum permissions. Use ABAC for context-aware restrictions. Audit and remove unused permissions quarterly.

Pitfall: Implementing Authentication Without Authorization

The mistake: Verifying user/device identity (authentication) but then granting full access without checking permissions (authorization).

Why it happens: Developers focus on “who is this?” and forget “what are they allowed to do?”

The fix: Always implement both. After authentication succeeds, check RBAC/ABAC policies before granting access. The Ring camera breach occurred because authenticated users had unrestricted access to camera feeds without granular permission checks.

Concept Relationships

Concept	Related To	Relationship Type
RBAC (Role-Based)	Organizational Structure	Mirrors - User roles align with job functions (Admin, Operator, Viewer)
ABAC (Attribute-Based)	Context-Aware Decisions	Extends - Evaluates dynamic attributes beyond static roles (time, location, risk level)
Least Privilege	Defense-in-Depth	Implements - Minimizes blast radius by granting only necessary permissions
OAuth 2.0	Token-Based Access	Standardizes - Industry protocol for delegated authorization without sharing credentials
Audit Logging	Forensics, Compliance	Supports - Records all access decisions for investigation and regulatory requirements
Default Deny	Fail-Safe Design	Enforces - Explicit allow rules required; no rule match = access denied

See Also

Foundation Concepts:

• Authentication Methods - Identity verification before authorization
• Cryptography for IoT - Token signing and encryption

Related Security Topics:

• Threat Modelling - STRIDE threat analysis
• Zero Trust Security - Never trust, always verify architecture
• Network Segmentation - Isolate devices by role/trust level

Practical Labs:

• Access Control Implementation Lab - RBAC hands-on with ESP32
• Advanced Access Control Lab - Capability-based and session management

Try It Yourself: ABAC Policy Evaluation

Design attribute-based access control policies for a hospital IoT system with three roles (Doctor, Nurse, Visitor) and three resources (Patient Records, Infusion Pumps, Visitor Logs).

Exercise Steps:

1. Define attributes for each role (clearance_level, department, shift)
2. Define attributes for each resource (sensitivity, criticality, location)
3. Write ABAC policy rules combining role + attributes + time constraints
4. Test scenarios: Doctor accessing patient records during shift, Nurse adjusting pump after-hours, Visitor accessing records

Example Policy Template:

IF user.role == "Doctor"
AND user.department == resource.department
AND resource.sensitivity <= user.clearance_level
AND time.hour >= 6 AND time.hour <= 22
THEN ALLOW
ELSE DENY

What to Observe:

• RBAC alone cannot enforce “same department” constraint
• Time-based restrictions require ABAC context evaluation
• Multiple conditions create fine-grained control
• Default deny ensures safety when no rules match

Key Concepts

• Default Deny: An access control stance that rejects all requests unless they are explicitly permitted by a policy rule; the opposite of default allow, which permits everything not explicitly denied
• Policy Rule: A conditional statement that grants or denies a permission based on subject, resource, action, and optionally environmental conditions
• RBAC Policy: A set of role definitions and role assignments that together determine effective permissions for each user or device
• Resource-Level Permissions: Access control that operates at the level of individual resources (specific device, specific sensor, specific actuator) rather than at the service or API level
• Condition-Based Access: Adding contextual constraints to permission rules — e.g., “role:operator can actuate valve:001 only between 08:00–18:00 Monday–Friday”
• Access Control Matrix: A two-dimensional table with subjects (users/devices) as rows and objects (resources) as columns, with permissions at each intersection; conceptually useful but impractical at scale
• Policy Evaluation Engine: The software component that evaluates incoming requests against the policy rules and returns an allow/deny decision; must be fast enough not to add perceptible latency

In 60 Seconds

Access control in IoT cybersecurity implements the principle of least privilege through RBAC policies that define exactly which users, devices, and services can perform which actions on which resources — with a default-deny stance that rejects any request not explicitly permitted.

Extension: Add emergency override policy allowing any Doctor to access any resource when hospital_status == “Code Blue”

Putting Numbers to It: Access Control Policy Evaluation

An access control decision is a boolean function \(f: (S, A, R, E) \rightarrow \{Allow, Deny\}\) where \(S\) = subject attributes, \(A\) = action, \(R\) = resource attributes, \(E\) = environment context.

\[P_{ABAC}(s,a,r,e) = \bigwedge_{i=1}^{n} C_i(s,a,r,e)\]

where \(C_i\) are policy conditions that must ALL evaluate to true for access to be granted.

Working through an example:

Given: Operator Bob requests “control actuator valve-42” at 14:00

Subject attributes: \(S = \{role: operator, dept: production, clearance: 2\}\)

Resource attributes: \(R = \{type: actuator, owner\_dept: production, criticality: medium\}\)

Environment: \(E = \{hour: 14, day: weekday, threat\_level: normal\}\)

Action: \(A = \{control\}\)

Step 1: Evaluate role condition \[C_1: S.role \in \{operator, admin\} \Rightarrow true\]

Step 2: Evaluate department match \[C_2: S.dept = R.owner\_dept \Rightarrow production = production \Rightarrow true\]

Step 3: Evaluate time window \[C_3: 6 \leq E.hour \leq 22 \Rightarrow 6 \leq 14 \leq 22 \Rightarrow true\]

Step 4: Final decision \[P_{ABAC} = C_1 \land C_2 \land C_3 = true \land true \land true = \textbf{Allow}\]

Result: Access granted. If time were 03:00, \(C_3\) would be false and entire policy would evaluate to Deny.

In practice: ABAC policies prevent privilege escalation by enforcing context (Bob can only control actuators in his department during work hours). In the 2013 Target breach, HVAC vendor credentials lacked department restrictions, allowing lateral movement from HVAC network to payment systems. Proper ABAC would have blocked cross-department access.

viewof userRole = Inputs.select(
  ["operator", "admin", "viewer", "guest", "maintenance"],
  {label: "User Role", value: "operator"}
)

viewof userDept = Inputs.select(
  ["production", "engineering", "marketing", "facilities"],
  {label: "User Department", value: "production"}
)

viewof resourceDept = Inputs.select(
  ["production", "engineering", "marketing", "facilities"],
  {label: "Resource Owner Department", value: "production"}
)

viewof accessHour = Inputs.range([0, 23], {
  label: "Access Time (hour, 24h format)",
  step: 1,
  value: 14
})

viewof threatLevel = Inputs.select(
  ["normal", "elevated", "high"],
  {label: "Threat Level", value: "normal"}
)

c1_role = ["operator", "admin"].includes(userRole)
c2_dept = userDept === resourceDept
c3_time = accessHour >= 6 && accessHour <= 22
c4_threat = threatLevel !== "high"

decision = c1_role && c2_dept && c3_time && c4_threat ? "ALLOW" : "DENY"
decisionColor = decision === "ALLOW" ? "#16A085" : "#E74C3C"

html`<div style="background: #f8f9fa; border-radius: 8px; padding: 20px; margin-top: 10px; font-family: Arial, sans-serif;">
  <h4 style="color: #2C3E50; margin-top: 0;">ABAC Policy Evaluation Result</h4>
  <table style="width: 100%; border-collapse: collapse; margin-bottom: 15px;">
    <tr style="border-bottom: 1px solid #dee2e6;">
      <th style="text-align: left; padding: 8px; color: #2C3E50;">Condition</th>
      <th style="text-align: left; padding: 8px; color: #2C3E50;">Check</th>
      <th style="text-align: center; padding: 8px; color: #2C3E50;">Result</th>
    </tr>
    <tr style="border-bottom: 1px solid #dee2e6;">
      <td style="padding: 8px;">C1: Role</td>
      <td style="padding: 8px;"><code>${userRole}</code> in {operator, admin}</td>
      <td style="padding: 8px; text-align: center; color: ${c1_role ? '#16A085' : '#E74C3C'}; font-weight: bold;">${c1_role ? 'TRUE' : 'FALSE'}</td>
    </tr>
    <tr style="border-bottom: 1px solid #dee2e6;">
      <td style="padding: 8px;">C2: Department</td>
      <td style="padding: 8px;"><code>${userDept}</code> == <code>${resourceDept}</code></td>
      <td style="padding: 8px; text-align: center; color: ${c2_dept ? '#16A085' : '#E74C3C'}; font-weight: bold;">${c2_dept ? 'TRUE' : 'FALSE'}</td>
    </tr>
    <tr style="border-bottom: 1px solid #dee2e6;">
      <td style="padding: 8px;">C3: Time Window</td>
      <td style="padding: 8px;">6 <= <code>${accessHour}</code> <= 22</td>
      <td style="padding: 8px; text-align: center; color: ${c3_time ? '#16A085' : '#E74C3C'}; font-weight: bold;">${c3_time ? 'TRUE' : 'FALSE'}</td>
    </tr>
    <tr style="border-bottom: 1px solid #dee2e6;">
      <td style="padding: 8px;">C4: Threat Level</td>
      <td style="padding: 8px;"><code>${threatLevel}</code> != "high"</td>
      <td style="padding: 8px; text-align: center; color: ${c4_threat ? '#16A085' : '#E74C3C'}; font-weight: bold;">${c4_threat ? 'TRUE' : 'FALSE'}</td>
    </tr>
  </table>
  <div style="text-align: center; padding: 15px; background: ${decisionColor}22; border: 2px solid ${decisionColor}; border-radius: 6px;">
    <span style="font-size: 1.3em; font-weight: bold; color: ${decisionColor};">
      Decision: ${decision}
    </span>
    <br/>
    <span style="font-size: 0.9em; color: #7F8C8D;">
      P<sub>ABAC</sub> = C1 ${c1_role ? '(T)' : '(F)'} AND C2 ${c2_dept ? '(T)' : '(F)'} AND C3 ${c3_time ? '(T)' : '(F)'} AND C4 ${c4_threat ? '(T)' : '(F)'} = <strong>${decision}</strong>
    </span>
  </div>
</div>`

9.8 Chapter Summary

Access control determines what authenticated entities can do within IoT systems. RBAC provides simple, role-based permission management suitable for small teams with stable permission requirements. ABAC enables fine-grained, context-aware access decisions based on user attributes, resource characteristics, actions, and environmental factors.

The principle of least privilege should guide all access control design: start with zero permissions and add only what is necessary. Comprehensive audit logging supports security monitoring, incident investigation, and compliance requirements. Combining RBAC for basic structure with ABAC for contextual rules provides the best balance of simplicity and flexibility.

9.9 Knowledge Check

Quiz: Access Control for IoT

Matching Quiz: Match Access Control Types to Properties

Ordering Quiz: Order Access Control Policy Design Steps

Label the Diagram

9.10 What’s Next

With access control policies in place, the next chapter examines Secure Communications where you’ll learn to implement TLS/DTLS protocols, VPN configurations, and secure boot mechanisms to protect data in transit and ensure firmware integrity.

If you want to…	Read this
Learn to secure IoT communications	Secure Communications
Understand authentication methods	Authentication Methods for IoT
Explore IoT-specific access control	IoT Security Access Control
Implement zero trust architecture	Zero Trust Security
Study cryptographic foundations	Encryption Principles

💻 Code Challenge