1451  Access Control for IoT

1451.1 Access Control for IoT

This chapter covers access control models and identity management strategies for IoT systems, including RBAC, ABAC, OAuth 2.0, and certificate-based device authentication.

1451.2 Learning Objectives

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

  • Compare access control models (MAC, DAC, RBAC, ABAC)
  • Implement OAuth 2.0 for IoT applications
  • Design identity management for device fleets
  • Choose appropriate authentication mechanisms for IoT constraints

1451.3 Access Control Models

1451.3.1 Comparison of Access Control Models

Model Description IoT Use Case Complexity
MAC (Mandatory) System enforces policies Military, classified High
DAC (Discretionary) Owner controls access Personal devices Low
RBAC (Role-Based) Permissions by role Enterprise IoT Medium
ABAC (Attribute-Based) Policy-based on attributes Multi-tenant, dynamic High
LPAC (Least Privilege) Minimum necessary access All IoT Philosophy

1451.3.2 Role-Based Access Control (RBAC) for IoT

%% fig-alt: "RBAC hierarchy for IoT showing roles (Administrator, Operator, Monitor, Device) mapped to permissions (Configure, Control, Read, Report). Users are assigned to roles, roles have permissions, and IoT devices are granted role-based access to resources."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart TB
    subgraph users["USERS"]
        U1["Admin User"]
        U2["Operator"]
        U3["Read-Only User"]
    end

    subgraph roles["ROLES"]
        R1["Administrator"]
        R2["Operator"]
        R3["Monitor"]
        R4["Device"]
    end

    subgraph perms["PERMISSIONS"]
        P1["Configure"]
        P2["Control"]
        P3["Read"]
        P4["Report"]
    end

    subgraph resources["RESOURCES"]
        S1["Devices"]
        S2["Data"]
        S3["Logs"]
    end

    U1 --> R1
    U2 --> R2
    U3 --> R3

    R1 --> P1 & P2 & P3
    R2 --> P2 & P3
    R3 --> P3
    R4 --> P4

    P1 --> S1
    P2 --> S1
    P3 --> S1 & S2 & S3
    P4 --> S2

    style users fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style roles fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style perms fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style resources fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff

TipTradeoff: RBAC vs ABAC
Factor RBAC ABAC
Complexity Simpler to implement and audit More flexible but complex policies
Scalability Role explosion with many user types Scales better with attributes
Dynamism Static role assignments Real-time attribute evaluation
Context Limited (role only) Rich (location, time, device state)
Implementation Most IAM systems support Requires policy engine

Choose RBAC when: You have well-defined user categories with stable permissions Choose ABAC when: You need dynamic, context-aware access decisions

1451.3.3 Attribute-Based Access Control (ABAC) Example

{
  "policy": "allow_device_control",
  "effect": "allow",
  "action": "actuator:control",
  "conditions": {
    "subject.role": "operator",
    "subject.department": {"equals": "resource.owner_department"},
    "resource.type": "actuator",
    "resource.criticality": {"lessThan": "high"},
    "environment.time": {"between": ["06:00", "22:00"]},
    "environment.location": {"in": ["factory_floor", "control_room"]}
  }
}

This policy allows operators to control actuators only if: - Operatorโ€™s department matches device owner - Device is not high-criticality - Time is during working hours - Operator is in authorized location

1451.4 OAuth 2.0 for IoT

OAuth 2.0 enables secure third-party access without sharing credentials:

%% fig-alt: "OAuth 2.0 device flow for IoT showing device requesting authorization, user authenticating on separate device (phone/browser), authorization server issuing tokens, and IoT device using access token to call API. This flow works for devices without browsers or input capability."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
sequenceDiagram
    participant Device as IoT Device
    participant AuthServer as Authorization Server
    participant User as User (Phone/Browser)
    participant API as Resource API

    Note over Device,API: OAuth 2.0 Device Authorization Grant

    Device->>AuthServer: POST /device/code
    AuthServer-->>Device: device_code, user_code, verification_uri

    Device->>User: Display: "Go to verify.example.com and enter code ABC123"

    User->>AuthServer: Navigate to verification_uri
    User->>AuthServer: Enter user_code, authenticate
    AuthServer-->>User: Authorization granted

    loop Poll for Token
        Device->>AuthServer: POST /token (device_code)
        AuthServer-->>Device: access_token (or "pending")
    end

    Device->>API: GET /data (Authorization: Bearer {token})
    API-->>Device: Protected resource data

1451.4.1 OAuth 2.0 Grant Types for IoT

Grant Type Use Case Security Level
Device Code Devices without browser High
Client Credentials Server-to-server, device identity High
Authorization Code + PKCE Mobile companion apps High
Refresh Token Long-lived device sessions Medium

Never use Implicit Grant or Resource Owner Password Grant for IoT - these are deprecated and insecure.

1451.5 Identity Management for Device Fleets

1451.5.1 IAM vs IRM

Aspect IAM (Identity Access Management) IRM (Identity Resource Management)
Focus Human users Machine identities (devices, services)
Scale Thousands of users Millions of devices
Lifecycle Onboarding โ†’ Offboarding Provisioning โ†’ Decommissioning
Authentication Passwords, MFA Certificates, keys
Credential Rotation User-initiated Automated

1451.5.2 Certificate-Based Device Identity

%% fig-alt: "Device certificate lifecycle showing manufacturing (key generation, CSR, certificate issuance), deployment (certificate installation, trust anchor configuration), operation (mTLS authentication, certificate validation), renewal (automated re-enrollment), and revocation (CRL/OCSP update, key destruction)."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart LR
    subgraph mfg["MANUFACTURING"]
        M1["Generate Key Pair"]
        M2["Create CSR"]
        M3["Issue Certificate"]
    end

    subgraph deploy["DEPLOYMENT"]
        D1["Install Certificate"]
        D2["Configure Trust Anchor"]
    end

    subgraph operate["OPERATION"]
        O1["mTLS Authentication"]
        O2["Certificate Validation"]
    end

    subgraph renew["RENEWAL"]
        R1["Monitor Expiry"]
        R2["Re-enroll"]
    end

    subgraph revoke["REVOCATION"]
        V1["Publish to CRL"]
        V2["OCSP Update"]
    end

    mfg --> deploy --> operate --> renew
    operate --> revoke

    style mfg fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style deploy fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style operate fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff
    style renew fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style revoke fill:#c0392b,stroke:#2C3E50,stroke-width:2px,color:#fff

1451.6 Worked Example: Certificate Management for IoT Fleet

Scenario: A utility company manages 50,000 smart meters. Each meter needs a unique X.509 certificate for mTLS authentication to the backend. Certificates expire after 2 years and must be renewed automatically without service disruption.

Solution Architecture:

  1. Manufacturing: Each meter generates key pair in secure element, CSR submitted to enrollment server
  2. Enrollment: EST (RFC 7030) protocol issues certificate from organizational CA
  3. Operation: Meters authenticate with mTLS to data collection servers
  4. Renewal: Automated re-enrollment 30 days before expiry using existing certificate
  5. Revocation: Compromised meters added to CRL, OCSP updated in real-time

Key Design Decisions:

  1. Private keys never leave device: Generated in secure element, CSR signed on-device
  2. Short-lived bootstrap credentials: Initial enrollment uses one-time token that expires
  3. ECDSA-P256 over RSA: Smaller certificates, faster verification for constrained devices
  4. 30-day renewal window: Allows time for retry on network failures
  5. EST over SCEP: Modern protocol with better security properties

Metrics After 12 Months:

Metric Before After Improvement
Expired cert incidents 47/year 3/year 94% reduction
Manual cert operations 200/month 12/month 94% reduction
Average renewal time 45 minutes 3 seconds 99.9% faster
Security audit findings 8 critical 0 critical 100% remediation

1451.7 Summary

This chapter covered access control for IoT:

  • RBAC: Role-based permissions for well-defined user categories
  • ABAC: Attribute-based policies for dynamic, context-aware access
  • OAuth 2.0: Device code flow for browserless authentication
  • Certificate Identity: X.509 certificates provide strong device identity
  • Fleet Management: Automated provisioning, renewal, and revocation at scale

1451.8 Whatโ€™s Next

The next chapter explores Network Segmentation including VLANs, firewall rules, and micro-segmentation strategies for isolating IoT devices from critical infrastructure.

Continue to Network Segmentation โ†’