%% fig-alt: "Access control decision flow showing multi-stage authorization process. Flow begins with Access Request, goes through Authentication (Who are you?) which returns 401 if invalid, then Authorization (What can you do?) which returns 403 if insufficient permissions, then Access Granted if permitted, and finally Audit Log recording who, what, when, where."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
flowchart TD
A[Access Request<br/>User/Device attempts action] --> B{Authentication<br/>Who are you?}
B -->|Invalid credentials| C[401 Unauthorized<br/>Access Denied]
B -->|Valid credentials| D{Authorization<br/>What can you do?}
D -->|Insufficient permissions| E[403 Forbidden<br/>Access Denied]
D -->|Permitted action| F[Access Granted<br/>Perform action]
F --> G[Audit Log<br/>Record: who, what, when, where]
style A fill:#2C3E50,stroke:#16A085,color:#fff
style B fill:#E67E22,stroke:#d35400,color:#fff
style C fill:#e74c3c,stroke:#c0392b,color:#fff
style D fill:#E67E22,stroke:#d35400,color:#fff
style E fill:#e74c3c,stroke:#c0392b,color:#fff
style F fill:#16A085,stroke:#0e6655,color:#fff
style G fill:#2C3E50,stroke:#16A085,color:#fff
1379 Access Control for IoT
1379.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
TipFor 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 |
1379.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
1379.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 |
1379.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.
1379.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 |
1379.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
TipMinimum 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.
1379.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.
1379.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” |
1379.5.2 ABAC Policy Evaluation
%% fig-alt: "ABAC policy evaluation flow showing multiple attribute conditions. Access Request is evaluated against Rule 1 (owner AND read), Rule 2 (admin AND business hours), Rule 3 (same department AND office location). If any rule matches, ALLOW. If no rules match, Default DENY."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TD
A[Access Request] --> B{Evaluate Policy Rules}
B --> C{Rule 1:<br/>user.id == device.owner<br/>AND action == read?}
C -->|Yes| D[ALLOW]
C -->|No| E{Rule 2:<br/>user.role == admin<br/>AND 9am <= time <= 5pm?}
E -->|Yes| D
E -->|No| F{Rule 3:<br/>user.dept == device.dept<br/>AND location == office?}
F -->|Yes| D
F -->|No| G[Default: DENY]
style A fill:#2C3E50,stroke:#16A085,color:#fff
style B fill:#E67E22,stroke:#d35400,color:#fff
style C fill:#E67E22,stroke:#d35400,color:#fff
style E fill:#E67E22,stroke:#d35400,color:#fff
style F fill:#E67E22,stroke:#d35400,color:#fff
style D fill:#16A085,stroke:#0e6655,color:#fff
style G fill:#e74c3c,stroke:#c0392b,color:#fff
1379.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 |
1379.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” |
WarningTradeoff: 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.
1379.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.
1379.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 |
1379.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 |
1379.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 DENY1379.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 |
1379.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"
}
}1379.7 Common Pitfalls
WarningPitfall: 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.
WarningPitfall: 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.
1379.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.
1379.9 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.
Continue to Secure Communications →