Identity, Authentication and Access Control

Introduction

An Internet of Things (IoT) system is secure only when it can answer three questions reliably: Which entity is requesting access? Is the entity genuinely who it claims to be? What is that entity allowed to do? These questions correspond to identity, authentication and authorization. Access control is the mechanism that turns authorization decisions into enforceable actions.

IoT security makes these concerns more difficult than in conventional information systems. Devices may be deployed in exposed locations, operate with limited memory and processing power, communicate intermittently, remain in service for many years, and be managed by several organizations. A sensor, gateway, mobile application, cloud service and human operator may all need distinct identities and carefully limited privileges.

This chapter presents practical foundations for implementing device identity, secure onboarding, mutual authentication, authorization, role- and attribute-based access control, credential protection and lifecycle management.

Learning Objectives

After studying this chapter, you should be able to:

1. Explain identity, authentication, authorization and access control and distinguish among them.
2. Select appropriate device identity and credential mechanisms.
3. Describe secure onboarding and mutual authentication workflows.
4. Apply role-based access control (RBAC) and attribute-based access control (ABAC).
5. Protect credentials during storage, transmission, use and recovery.
6. Design a credential lifecycle from provisioning to revocation and retirement.
7. Analyze an IoT access-control problem and recommend a defensible solution.

1. Identity, Authentication and Authorization

1.1 Identity

An identity is a persistent representation of an entity within a security domain. An entity may be a physical device, a software service, a user, an organization or a workload. Identity does not necessarily reveal a real-world name. A device can have a pseudonymous identity while still being uniquely distinguishable and accountable.

An IoT identity commonly includes:

• a unique identifier, such as a device identifier or certificate subject;
• ownership or organizational information;
• device type, model and capabilities;
• manufacturing or enrollment information;
• lifecycle state, such as active, suspended or retired;
• references to public keys, certificates or other credentials.

A serial number printed on a device is an identifier, but it is not by itself a secure identity. If an attacker can copy or alter it, the identifier provides recognition without trustworthy proof.

1.2 Authentication

Authentication is the process of verifying a claimed identity. Common authentication factors are:

• Knowledge: a password, PIN or secret key.
• Possession: a hardware token, private key or authenticator.
• Inherence: a biometric characteristic.
• Location or context: network position, time or device posture. These are generally supplementary rather than sufficient on their own.

IoT devices most commonly use cryptographic possession: the device proves control of a private key without revealing that key. Authentication should also provide freshness, meaning that an old valid message cannot simply be replayed.

1.3 Authorization

Authorization determines what an authenticated entity may do. For example, a temperature sensor may publish readings but may not change firmware; a maintenance technician may update firmware only on assigned devices; and a cloud analytics service may read data without opening a physical actuator.

Authentication answers “Who are you?” Authorization answers “What may you do?” Confusing these functions creates serious vulnerabilities. A valid identity should not automatically receive unrestricted access.

1.4 Access control

Access control is the complete enforcement process: identifying a subject, authenticating it, evaluating a policy, allowing or denying an operation, and recording the decision. A useful conceptual model is:

Subject → Authentication → Policy decision → Enforcement point → Resource
                                      ↓
                                  Audit record

A subject is the entity requesting access. A resource is a device, command, data item, API or administrative function. An operation is an action such as read, write, execute, configure or update.

2. Device Identity Architecture

2.1 Identity domains and trust boundaries

An IoT deployment may contain several identity domains:

• a manufacturer domain that creates initial device credentials;
• an owner or operator domain that enrolls and manages devices;
• a local network domain that controls gateways and endpoints;
• a cloud domain that exposes APIs and data services;
• a maintenance domain used by authorized personnel.

Trust should not be assumed merely because two components communicate over the same network. Each domain should define who issues credentials, which entities are trusted, how trust is established, and how trust is withdrawn.

2.2 Device identity patterns

Per-device identity assigns each device a unique cryptographic identity. This supports precise authorization, auditing and revocation. It is usually preferable to a shared fleet password.

Group identity allows multiple devices to use a common credential. It reduces provisioning complexity but makes compromise difficult to localize. If one device is compromised, the attacker may impersonate the entire group.

Hierarchical identity combines an organizational or product identity with a unique device identity. Certificates and policy claims can express both dimensions.

Attested identity includes evidence about the device’s hardware, firmware or boot state. A verifier may require not only a valid key but also an acceptable security posture.

2.3 Identifiers and credentials

An identifier names an entity; a credential provides evidence for authentication. Examples include:

• an asymmetric key pair and certificate;
• a symmetric key stored in secure hardware;
• a short-lived access token;
• a password, preferably only for human users and protected with a password-hashing function.

Public-key systems are attractive for large IoT deployments because a device can prove possession of a private key while the verifier needs only the corresponding public key or certificate chain. Symmetric keys can be efficient, but key distribution and compromise containment require careful design.

3. Secure Onboarding

Secure onboarding is the controlled process by which a device becomes a trusted member of an IoT system. It should not be confused with merely connecting a device to Wi-Fi or assigning an IP address.

3.1 Onboarding stages

A robust process normally includes:

1. Manufacturing preparation: create or inject a unique key pair, preferably in a protected environment or secure element.
2. Initial identification: record the device identity and relevant metadata in an inventory or registry.
3. Ownership transfer: bind the device to the customer or operational organization.
4. Proof of possession: require the device to demonstrate control of its private key or bootstrap secret.
5. Mutual verification: authenticate the device and the onboarding service.
6. Policy assignment: issue operational credentials and assign least-privilege permissions.
7. Activation: permit normal communication only after successful enrollment.
8. Audit: record who enrolled the device, when, under which policy and with what result.

3.2 Bootstrap and operational credentials

A bootstrap credential should have limited purpose and lifetime. It may authenticate a device only to an enrollment service. After onboarding, the device receives an operational credential used for routine communication. Separating these credentials limits damage if one credential is exposed.

A device should not be activated solely because it presents a known serial number or connects from an expected network. Secure onboarding must resist cloning, rogue enrollment, interception and unauthorized ownership transfer.

3.3 Out-of-band methods

For constrained or locally deployed devices, onboarding may use a QR code, near-field communication, a wired commissioning interface or a manufacturer-provided claim certificate. Such methods can improve usability, but the claim information must be protected from copying and should not become a permanent universal secret.

3.4 Onboarding threats

Important threats include:

• Cloning: copying an identifier or credential to another device.
• Rogue enrollment: an attacker registering an unauthorized device.
• Man-in-the-middle attack: intercepting or altering enrollment messages.
• Ownership hijacking: transferring a legitimate device to an attacker’s account.
• Downgrade: forcing use of an obsolete authentication method.
• Supply-chain compromise: inserting or replacing credentials before deployment.

Controls include secure manufacturing, certificate validation, proof of private-key possession, authenticated key exchange, protected transfer of ownership, secure boot and audit logging.

4. Authentication Protocols and Mutual Trust

4.1 One-way and mutual authentication

In one-way authentication, a device authenticates the server, but the server does not cryptographically verify the device. This may protect a device from a fake server but does not prevent unauthorized clients from connecting.

In mutual authentication, both parties verify each other. A typical certificate-based exchange is:

1. The device connects to the service.
2. The service presents its certificate; the device validates the chain, name and validity status.
3. The device presents its certificate or other credential.
4. Each side proves possession of its private key.
5. Both derive session keys through an authenticated key-exchange protocol.
6. Subsequent messages use integrity and confidentiality protection.

The exact protocol should use established standards and libraries rather than custom cryptography. Transport Layer Security (TLS), Datagram TLS (DTLS), or a protocol with equivalent authenticated encryption may be appropriate depending on transport and constraints.

4.2 Freshness and replay resistance

A captured command such as “open valve” must not remain valid forever. Replay resistance can be provided by nonces, sequence numbers, timestamps with reliable time, short-lived tokens, or stateful challenge-response. A nonce is a value intended for one protocol execution; it must be unpredictable or uniquely managed according to the protocol design.

4.3 Certificate validation

A certificate should not be accepted merely because it is syntactically valid. Validation commonly includes:

• trusted issuer and valid chain;
• validity period;
• subject or service-name match;
• key-usage and extended-key-usage constraints;
• revocation or status information where feasible;
• acceptable cryptographic algorithms and key sizes;
• device lifecycle status in the organization’s registry.

4.4 Passwords and human authentication

Passwords are vulnerable to guessing, reuse, phishing and disclosure. Where passwords are unavoidable, systems should enforce rate limits, use salted password-hashing functions designed for password storage, support multi-factor authentication for privileged roles, and avoid storing plaintext or reversible password data. Device-to-device authentication should generally use cryptographic keys rather than a shared human-style password.

5. Authorization Models

5.1 Least privilege and separation of duties

Least privilege grants only the permissions needed for an entity’s legitimate task and only for the necessary duration. Separation of duties ensures that a single identity cannot perform conflicting actions without independent approval. For example, the person who requests a firmware release may not be the only person able to approve and deploy it.

Authorization should consider the operation, resource, context and consequences. Reading a sensor value and changing a safety threshold are not equivalent, even if both use the same API.

5.2 Role-Based Access Control

RBAC assigns permissions to roles and assigns subjects to roles. Typical roles include sensor, operator, maintenance technician, security administrator and analytics service.

A simple RBAC relationship is:

User or service → Role → Permission → Resource and operation

For example, the “maintenance technician” role may have read diagnostics and install approved firmware permissions, while the “operator” role may have read status and acknowledge alarm permissions.

RBAC is understandable and manageable where organizational responsibilities are stable. However, too many specialized roles can produce role explosion. Temporary privileges should be time-limited and approved rather than permanently added to a role.

5.3 Attribute-Based Access Control

ABAC evaluates attributes of the subject, resource, action and environment. A policy might state:

Permit a technician to update a device if the technician is assigned to the device, the firmware is approved, the device is in maintenance mode, and the request originates from an authorized network.

Attributes may include department, device ownership, location, time, risk state, firmware version, data sensitivity and emergency status. ABAC expresses context-sensitive rules more precisely than simple role membership, but it requires trustworthy attribute sources and careful policy testing.

5.4 Relationship- and capability-oriented approaches

Relationship-based policies authorize according to a relationship such as “technician assigned to device.” Capability-based security uses an unforgeable token that grants a defined right, often to a specific resource. These approaches can be useful for delegated access and distributed systems, but capabilities must be protected against theft, excessive scope and uncontrolled forwarding.

5.5 Policy decision and enforcement points

A Policy Enforcement Point (PEP) intercepts requests and enforces the result. A Policy Decision Point (PDP) evaluates policy. A Policy Information Point (PIP) supplies attributes, while a Policy Administration Point (PAP) manages rules.

This separation improves consistency, but an IoT system must consider availability. If a remote PDP is unreachable, an actuator must not automatically enter an unsafe state. Local cached policies, bounded offline permissions and fail-safe behavior may be necessary.

6. Credential Protection

6.1 Protecting private keys

A private key should be generated and stored in a secure element, trusted platform module, hardware security module or protected operating-system keystore where feasible. The key should be marked non-exportable, and cryptographic operations should occur inside the protected component.

If hardware protection is unavailable, apply layered controls: memory protection, filesystem permissions, encrypted storage, secure boot, process isolation, minimized privileges and rapid replacement procedures. Encryption of a key file is not sufficient if the decryption key is stored beside it in accessible plaintext.

6.2 Protecting secrets in transit and logs

Credentials must be transferred only through authenticated and encrypted channels. Secrets should never appear in ordinary logs, crash reports, source code, container images or configuration repositories. Diagnostic records should use redaction, access control and retention limits.

6.3 Token protection

Access tokens should be scoped, audience-restricted and short-lived. A token should identify its issuer and intended service and should not grant more permission than required. Refresh credentials require stronger protection than short-lived access tokens. Token replay can be reduced through sender-constrained mechanisms, nonce use or binding to a secure channel.

6.4 Recovery and backup

Recovery procedures are part of credential security. Backups must be encrypted and access-controlled, and restoration must not create duplicate device identities. If a private key cannot be recovered safely, replacement and re-enrollment may be preferable. Emergency access should be logged, time-limited and reviewed.

7. Credential Lifecycle Management

Credential management continues throughout the device lifecycle:

Key rotation should be planned before expiry. Devices with intermittent connectivity need a grace strategy that does not leave old credentials valid indefinitely. Revocation mechanisms may include certificate status services, deny lists, registry checks or short-lived credentials that naturally expire. Each has availability, bandwidth and freshness trade-offs.

A credential inventory should record the identity, owner, credential type, issue date, expiry date, current state, last use and revocation status. Inventory data itself is sensitive because it reveals the organization’s attack surface.

8. Applied Case: Smart Water-Distribution Network

The following is an illustrative case.

Background

A municipal water utility operates pressure sensors, flow meters and remotely controlled valves. Devices communicate through field gateways to a cloud management platform. Contractors perform maintenance, while utility operators supervise daily operations.

Problem

The original deployment used a shared password for all field devices. The cloud API accepted long-lived tokens, and technicians could access devices outside their assigned districts. One leaked password therefore permitted broad access, and the utility could not identify which device had issued a suspicious command.

Analysis

The system lacked per-device identity, strong attribution, least privilege and effective credential lifecycle management. A shared secret created a large blast radius. Long-lived tokens increased replay risk. Contractor access was not restricted by assignment or time.

Approach and solution

The utility adopts the following design:

1. Each device receives a unique asymmetric key pair generated in a secure element.
2. A device certificate identifies the device and its operational owner.
3. Mutual authentication is required between device and gateway, and between gateway and cloud service.
4. A bootstrap credential is used only during enrollment and is replaced by an operational certificate.
5. RBAC defines operator, technician, security administrator and analytics roles.
6. ABAC further requires that a technician be assigned to the district, use an approved workstation, operate during an approved maintenance window and install signed firmware.
7. Valve-control commands require a stronger privilege than sensor reading and may require dual approval.
8. Tokens are short-lived, scoped to a service and excluded from logs.
9. A central registry records issuance, rotation, suspension and revocation.
10. Devices cache a bounded emergency policy so that loss of cloud connectivity does not permit unrestricted control.

Outcome

The utility can attribute requests to individual devices and personnel, restrict contractors to assigned assets, revoke a compromised identity without changing every device credential, and distinguish ordinary telemetry from high-risk actuator commands. Availability and emergency operation still require testing, especially during certificate expiry or network isolation.

Learning points

The case demonstrates that identity is not simply an identifier. Security depends on a chain linking unique credentials, authenticated communication, policy-based authorization, protected keys, lifecycle processes and audit evidence.

9. Governance, Ethics and Professional Practice

Identity systems affect privacy and accountability. Excessive collection of location, operator behavior or biometric information may create unnecessary surveillance. Organizations should collect only attributes needed for a defined security purpose, restrict access to identity data, define retention periods and provide transparent governance.

Access decisions should be explainable enough for operators and auditors to understand why a request was allowed or denied. Emergency override mechanisms require special scrutiny: they should be narrowly defined, strongly authenticated, logged and reviewed after use.

Regulatory obligations vary by sector and jurisdiction, but professional practice commonly requires protection of personal data, secure defaults, incident reporting, supplier accountability and evidence of risk management. Compliance does not replace sound engineering; a system can satisfy a checklist and still fail if keys are shared or policies are not enforced.

10. Contemporary Developments and Limitations

Important developments include hardware-backed identity, remote attestation, automated certificate management, zero-trust architectures and policy engines that evaluate device posture. Machine learning can help identify unusual authentication or command patterns, but it should supplement—not replace—cryptographic identity and explicit authorization. A model may produce false positives, miss novel attacks or become a target itself.

No authentication system eliminates all risk. A valid credential may be stolen, a trusted device may be compromised, an attribute source may be wrong, and a policy may contain a design error. Defense therefore requires segmentation, secure updates, monitoring, incident response and safe physical design in addition to identity controls.

Best-Practice Checklist

• Give every important device a unique identity.
• Prefer proof of private-key possession over shared fleet passwords.
• Use secure onboarding with ownership binding and audit records.
• Authenticate both endpoints where feasible.
• Enforce least privilege and separate high-risk operations.
• Combine RBAC with attributes when context matters.
• Protect keys with hardware-backed storage when practical.
• Use short-lived, scoped tokens and plan rotation before expiry.
• Maintain accurate credential and device inventories.
• Support suspension, revocation, replacement and secure retirement.
• Test offline, recovery, emergency and certificate-expiry behavior.
• Keep secrets out of logs, code, images and ordinary configuration files.
• Review policies for privacy, safety, accountability and unintended access.

Chapter Summary

Identity represents an IoT entity; authentication verifies its claimed identity; authorization determines its permitted actions; and access control enforces and records those decisions. Secure IoT deployments normally use unique device identities, cryptographic credentials and secure onboarding rather than shared passwords. Mutual authentication, freshness protections and certificate validation help prevent impersonation and replay.

RBAC organizes permissions around responsibilities, while ABAC evaluates subject, resource, action and environmental attributes. Policy decision and enforcement points provide a structured way to implement these models, but offline operation and safety requirements must be addressed. Private keys require strong protection, and credentials must be managed from generation through provisioning, rotation, revocation and retirement. Governance must also consider privacy, explainability, emergency access and accountability.

Key Terms

Identity: A representation of an entity within a security domain.

Identifier: A value used to distinguish or name an entity.

Credential: Evidence used to authenticate an identity.

Authentication: Verification of a claimed identity.

Mutual authentication: Authentication in which both communicating parties verify each other.

Authorization: Determination of what an authenticated entity may do.

Access control: Processes and mechanisms that enforce authorization decisions.

Secure onboarding: Controlled enrollment of a device into a trusted system.

Bootstrap credential: Limited credential used to obtain operational credentials.

Private key: Secret cryptographic value used to prove possession or create signatures.

Certificate: Signed binding between an identity and a public key.

Nonce: A protocol value used to provide uniqueness or freshness.

Replay attack: Reuse of a previously valid message or transaction.

Least privilege: Granting only the permissions necessary for a task.

RBAC: Access control based on roles and their permissions.

ABAC: Access control based on attributes of subjects, resources, actions and context.

Policy Enforcement Point: Component that applies an allow or deny decision.

Credential rotation: Replacement of a credential with a new one.

Revocation: Invalidation of a credential before or at the end of its normal validity.

Secure element: Hardware component designed to protect keys and perform cryptographic operations.

Review Questions

Short Answer Questions

1. Distinguish an identifier from a credential.
2. Why is mutual authentication valuable in an IoT system?
3. What is the purpose of a bootstrap credential?
4. State the principle of least privilege.
5. Give two methods for protecting a device private key.

Long Answer Questions

1. Explain the stages of a secure IoT onboarding process and identify threats addressed at each stage.
2. Compare RBAC and ABAC, including one situation in which each is most appropriate.
3. Describe the lifecycle of an IoT credential from generation to retirement.
4. Explain how replay attacks can occur and discuss controls that provide freshness.
5. Discuss the governance and privacy issues associated with identity and attribute collection.

Analytical / Application Questions

1. A factory uses one password for 2,000 sensors. Analyze the security and operational weaknesses and propose a migration plan to per-device identity.
2. A contractor must update firmware only on assigned machines between 18:00 and 22:00. Express the required authorization conditions using RBAC and ABAC concepts.
3. A remote valve must remain safe during a 24-hour cloud outage. Design an authentication, authorization and emergency-policy approach that balances security, availability and safety.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication assigns a role, while authorization creates an identity.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication encrypts data, while authorization compresses data.

D. Authentication records logs, while authorization generates certificates.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

What is the principal security advantage of a unique cryptographic identity for each IoT device?

A. It eliminates the need for software updates.

B. It allows all devices to share one password safely.

C. It supports precise attribution and selective revocation.

D. It guarantees that the device cannot be physically attacked.

Correct Answer: C. It supports precise attribution and selective revocation.

Question 3

Which credential is intended primarily for initial enrollment and should have limited purpose?

A. Bootstrap credential

B. Permanent administrator credential

C. Shared fleet password

D. Audit record

Correct Answer: A. Bootstrap credential

Question 4

In mutual authentication, what is verified?

A. Only the cloud server

B. Only the device’s network address

C. Both communicating parties

D. Only the device model number

Correct Answer: C. Both communicating parties

Question 5

Which access-control model evaluates attributes such as technician assignment, time and device location?

A. RBAC

B. ABAC

C. Discretionary password control

D. Physical isolation

Correct Answer: B. ABAC

Question 6

Which practice provides the strongest protection for a device private key?

A. Storing it in a public source-code repository

B. Printing it on the device label

C. Keeping it in a secure element as non-exportable

D. Including it in ordinary diagnostic logs

Correct Answer: C. Keeping it in a secure element as non-exportable

Question 7

What is the main purpose of a nonce in an authentication protocol?

A. To provide message uniqueness or freshness

B. To increase sensor measurement accuracy

C. To replace authorization policies

D. To identify the device manufacturer only

Correct Answer: A. To provide message uniqueness or freshness

Question 8

A technician may read diagnostics but may not install firmware. Which principle is being applied?

A. Least privilege

B. Credential duplication

C. Anonymous access

D. Unrestricted delegation

Correct Answer: A. Least privilege

Question 9

Which action is part of credential retirement?

A. Making the credential permanent

B. Revoking credentials and removing operational permissions

C. Copying the credential to every device

D. Disabling audit records

Correct Answer: B. Revoking credentials and removing operational permissions

Question 10

Why are short-lived, scoped access tokens preferable to unrestricted long-lived tokens?

A. They increase the impact of token theft.

B. They reduce exposure duration and limit permitted operations.

C. They remove the need for authentication.

D. They allow tokens to be safely written to logs.

Correct Answer: B. They reduce exposure duration and limit permitted operations.