A Context-Aware, Policy-Driven Access Control Framework for Securing Distributed IoT Environments: Design, Implementation, and Comparative Evaluation

1. Introduction

The Internet now exists as a seamless fabric of classic networks and networked objects, enabling new ways of working, interacting, and living. Within this perspective, the conventional concept of the Internet as an infrastructure reaching out to individual end-user terminals is fading, giving way to a notion of interconnected “smart” objects forming pervasive computing environments; this innovation is enabled by embedding electronics into everyday physical objects and letting them seamlessly integrate within the resulting cyber-physical infrastructure. The term “Internet of Things” (IoT) is broadly used to refer to (i) the resulting global network interconnecting smart objects through extended Internet technologies, (ii) the set of supporting technologies necessary to realize this vision, and (iii) the ensemble of applications and services that these technologies support [1].

Although IoT can deliver services more effectively and efficiently to end users, it raises significant security and privacy challenges. Many IoT devices have limited capacity to encrypt or decrypt data, making it hard to verify the authenticity and integrity of exchanged data; the heterogeneous nature of IoT environments, spanning devices and sensors across multiple actuators and administrative domains, compounds this [2]. Among the resulting challenges — authentication, trust, rogue-node detection, privacy, intrusion detection, data protection, and key management — access control is central: it ensures only authorized entities can access a given resource or the data it collects [3]. cultivating the trust between devices, users, and services that underpins secure environments. IoT further complicates access control through large numbers of resource-constrained devices and highly distributed data; delegation, transferring users’ access rights to other entities for a given resource, addresses this by increasing flexibility and reducing administrative load at scale [4].

1.1. Problem Statement

The lack of trust in IoT environments is a significant concern that leads users to doubt the safety and privacy of IoT services, underscoring the necessity of establishing trust among heterogeneous IoT devices as a prerequisite for secure environments. According to a survey on the future of digital trust, 78% of customers find it difficult to trust organizations with their personal data [5], a barrier that directly constrains the wider adoption of IoT applications in consumer and business settings. IoT systems continue to face difficulty providing a secure environment for device interactions [6,7], in part because existing access-control approaches do not cover all IoT security requirements simultaneously, and in part because obtaining a safe and easy access-control scheme for open, dynamic environments, one that reduces rather than increases administrative effort, remains an open problem [8,9]. Critically, no existing framework couples a quantifiable, standards-based vulnerability threshold (CVSS) with a full commercial AAA and defense-in-depth architecture to drive real-time, threat-triggered revocation and delegation within a single, deployable architecture.

This research is guided by three questions: (RQ1) What access-control framework design can effectively address current security threats while automating policy enforcement and identity management in distributed, heterogeneous IoT environments? (RQ2) How can access-rights delegation, revocation, and verification be automated in response to real-time threat indicators without manual administrative intervention? (RQ3) To what extent does the proposed framework satisfy established IoT security requirements relative to existing access-control frameworks?

1.2. Objectives and Contributions

This work’s general objective is to address trust and privacy challenges in open, dynamic IoT environments through a secure, adaptive, and scalably deployable access-control framework for protected data and resource exchange. The specific objectives are: (i) design a generic framework that addresses security threats while streamlining rule definition for complex scenarios; (ii) develop a formal approach for modeling access-control entities in large, dynamic, open environments, reducing manual administrative burden; and (iii) implement automated delegation, revocation, and verification of access rights in distributed IoT settings.

The significance of this work lies in three evidence-grounded contributions. First, it directly addresses the documented trust deficit in IoT access management [10,11] through automated, policy-driven threat response. Second, it reduces the administrative burden imposed by manual policy management, which is impractical at IoT scale [12], through rule-based automation. Third, it closes the gap left by current frameworks, the absence of integrated identity management combined with real-time, evidence-based revocation[13], by operationalizing a quantifiable threat indicator (a CVSS score exceeding 7.0) that automatically triggers revocation and delegation decisions. This work extends and substantially revises an earlier paper by the same authors [14], adding the comparative benchmark, extended related-work synthesis, and limitations analysis presented in Section 2 and Section 5.5, and Section 6.2.

1.3. Paper Organization

The remainder of this paper is organized as follows. Section 2 reviews traditional and IoT-specific access-control models, the security threats and requirements that motivate this work, and recent access-control frameworks proposed for IoT. Section 3 details the research methodology, the design goals, and the architecture of the proposed access-control framework. Section 4 describes its implementation on a defense-in-depth network testbed. Section 5 presents the evaluation results, including a comparative benchmark against nine existing frameworks. Section 6 discusses the findings and their limitations, and Section 7 concludes the paper and outlines directions for future work.

2. Related Work

2.1. IoT Security Requirements

Building secure IoT systems requires a clear understanding of the security requirements specific to the IoT context. The IoT’s resource constraints and rapidly evolving threat landscape make several of these requirements especially difficult to satisfy simultaneously: lightweight cryptographic and protocol design is necessary because typical IoT devices cannot support the computational overhead of conventional security mechanisms [15,16], while the continual introduction of new device types and communication patterns constantly opens attack surfaces that existing solutions do not yet fully address [17]. Drawing on a systematic treatment of these requirements, ten requirements recur across the literature and are used throughout this paper as the basis for evaluation: (i) light-weight solutions, which account for the resource-constrained nature of IoT devices; (ii) decentralized management, since centralized solutions are generally impractical at IoT scale; (iii) end-to-end security across the multiple administrative domains and technologies that IoT communications traverse; (iv) identity management, i.e., reliable techniques for administering the identities of devices and users and the relationships between them; (v) privacy of users and data; (vi) mobility/dynamic support, so that devices, users, and things can move across jurisdictions without interrupting security; (vii) scalability and incremental deployment, allowing entities to join and leave the system as it evolves; (viii) robustness, self-healing, reliability, and real-time data-freshness, i.e., the ability to discover faults and correct them automatically and to respond to threats in real time; (ix) composition, heterogeneity, and interoperability across diverse devices and technologies; and (x) federation across administrative domains, so that the security policies of all cooperating domains can be enforced and administered coherently. These ten requirements are used in Section 5 as the common yardstick against which the proposed framework and nine existing frameworks are compared.

2.2. Traditional and IoT-Specific Access Control Models

Traditional access control rests on three classical models. Discretionary Access Control (DAC) leaves the decision to the discretion of the resource owner, who determines which subjects may access a resource, the model underlying access control lists in commercial operating systems. Mandatory Access Control (MAC) instead has the operating system enforce a security-label system in which users and data are assigned clearance levels (e.g., confidential, secret, top secret), with access rules set by a security officer and enforced by the operating system itself. Role-Based Access Control (RBAC) assigns users to roles engineered on the principle of least privilege, and the role, rather than the individual user, dictates access to resources, which scales considerably better than DAC in centralized enterprise settings [18].

These traditional models are difficult to apply directly to IoT because of the scale, heterogeneity, and dynamism of IoT deployments. Attribute-Based Access Control (ABAC) has therefore become the dominant paradigm for IoT and cloud settings: access decisions are computed from attributes of the initiator, the target, and the environment rather than from a fixed role assignment, which better matches the fine-grained, context-dependent access decisions that IoT scenarios require. ABAC has been applied specifically to secure home IoT environments, and broader surveys of IoT access control confirm that ABAC, together with hybrid RBAC/ABAC schemes, dominates recent proposals because of this flexibility [4,9].

2.3. Existing IoT Access-Control Frameworks

Several frameworks model access control around the resources or applications that an IoT deployment exposes, rather than around its network architecture. One framework modelled the communication procedures themselves as first-class resources subject to access-control policy, applying this model across representative IoT communication scenarios, while a related application-scoped model extended this idea to publish/subscribe IoT architectures built on the FIWARE platform, evaluating access-control overhead directly on that platform [19].

A substantial body of further work has proposed access-control frameworks for cloud and IoT environments more broadly. Early cloud-oriented proposals externalized access-control decisions from the application layer itself: one framework moved access-control policy specification and decision-making to a dedicated external authorization server that issues tokens to users after evaluating their resource-specific policies [20], while a related approach let users create and manage access-control policies for their own cloud resources according to their own security requirements.

A second line of work addresses the mismatch between conventional cloud computing and the latency and bandwidth constraints of IoT by moving access decisions to the network edge. One study characterized how edge computing reduces latency and bandwidth congestion for latency-sensitive IoT applications such as smart cities, smart grids, and autonomous vehicles [21]. Building on this direction, an access-control framework for information-centric networks allowed legitimate users to retrieve cached content directly at the wireless edge without per-request authentication by an online provider, reducing both delivery latency and the impact of server outages [22]. A reconfigurable, edge-computing-based security framework combined the standard Extensible Authentication Protocol (EAP) with RBAC and ABAC to treat each security service as an object, allowing flexible adoption of different security measures without redesigning the underlying IoT protocol stack, and introduced a near-user “security agent” to offload cryptographic computation from resource-limited devices [23]. A further edge-based framework for information-centric networks performed authentication at the network edge to block unauthorized requests early, used group signatures for anonymous authentication and hash chains to reduce overhead under repeated requests, and added a revocation mechanism for robustness [24].

A third line of work integrates blockchain technology to achieve decentralized, tamper-resistant access governance. Dai et al. proposed a blockchain-based access-control system for hazardous-material supply chains to improve security, traceability, and resistance to single points of failure [25]. Algarni et al. proposed a lightweight and decentralized IoT access-control framework based on blockchain and a multi-agent architecture, supporting secure communication among IoT devices, fog nodes, and cloud services [26]. One framework used the blockchain address of a node as its identity and stored access-control permissions, encrypted, on-chain to prevent illegal access by external attackers or by insiders with elevated privileges [27]. Another integrated a permissioned blockchain with ABAC and identity-based signatures to build a lightweight, cross-domain IoT access-control system, partitioning the IoT deployment into per-domain local ledgers and using channel technology together with a policy-decision-point selection algorithm to support real-time, off-chain distributed decisions while filtering illegitimate requests to mitigate DDoS attacks [28]. A hybrid access-control framework combined RBAC and ABAC, using attribute-based policies over an RBAC infrastructure to support dynamic authentication and authorization while reducing privilege-management complexity and improving fine-grained access-control flexibility [29], while a supply-chain-oriented ABAC framework used separate local and global blockchain ledgers to restrict access among competing supply-chain stakeholders while preserving network scalability [30]. A dedicated study of denial-of-service defenses evaluated individual and ensemble machine-learning classifiers for detecting and mitigating DoS attacks on IoT networks, including real-time testing on resource-constrained hardware, and demonstrated the practical value of ensemble methods for intrusion detection at the edge [31].

More recent proposals combine zero-trust principles, fog computing, and messaging infrastructure with ABAC. A zero-trust access-control model based on attributes and dynamic trust evaluation continuously evaluates trust and adjusts access decisions according to contextual and behavioural factors [32]. Complementing this approach, Awan et al. proposed ZAIB, a blockchain-inspired zero-trust and ABAC framework specifically for IoT that evaluates device trust for each access request, applies variable policies according to environmental parameters and device behaviour, supports anonymous device and user registration through blockchain, and protects IoT attributes, trust histories, and generated data using IPFS [33]. A Fog-Based Adaptive Context-Aware Access Control framework secures IoT systems by adjusting access policies to real-time context, moving decision-making closer to edge devices to improve responsiveness and adapt to changing device behavior [34]. Most recently, a blockchain-based IoT access-control system combined with a message-queuing mechanism was proposed to improve security, transparency, and operational performance: access rules are enforced through smart contracts on a blockchain network, while a message queue ensures reliable, ordered delivery of access requests under load; the authors note, however, that ABAC policies embedded in smart contracts are inflexible to change, that blockchain consensus can slow time-sensitive decisions, and that the message queue itself can introduce latency under heavy request volumes [35].

A blockchain-enabled access-management system for edge computing integrated decentralized blockchain governance with edge-based real-time processing, RBAC, smart-contract authorization, and protocol translation to support scalable and distributed IoT access management [36].

More recently, Sathya et al. combined edge AI processing with blockchain-based access control in IoMT, using role-specific authorization, unique identity tokens, decentralized storage, and real-time edge inference to enhance healthcare data privacy, integrity, and responsiveness [37].

Each framework was scored per requirement based solely on its own stated design goals and reported evaluation: 0 where the requirement is unaddressed, 1 where it is addressed partially or only for a subset of scenarios, and 2 where it is a core design goal with a corresponding mechanism described and evaluated.

The nine frameworks scored in Table 3 were selected as the most recent representative of each of the three design lines discussed above, prioritizing frameworks whose reported evaluation (where present) maps onto the ten requirements used in this comparison; frameworks evaluated primarily on domain-specific metrics outside this scope or with no reported evaluation at all were excluded from formal scoring but remain discussed in the narrative review above. As Table 3 shows, no single existing framework satisfies all ten requirements simultaneously: six of nine comparators score only “Well Satisfied” or below on Robustness/Self-healing/Reliability/Real-time, and Identity Management against other requirements. This gap, the absence of a framework that jointly satisfies identity management, real-time responsiveness, and decentralized management within one deployable architecture, is precisely the gap the framework proposed in Section 3 is designed to close.

3. Materials and Methods

3.1. Research Methodology

This research employed the System Development Life Cycle (SDLC) methodology, selected because the research emphasized requirements gathering, implementation, configuration, operational verification, and iterative system engineering. SDLC’s phase-gated structure provides traceability from security requirements through design to verified implementation, which is essential for a security framework where each phase must be validated before the next proceeds. The methodology was implemented through five steps: (1) requirements gathering, identifying and analyzing access-control-related security threats in IoT, evaluating the most relevant access-control models for open and dynamic environments, and determining security requirements from the perspective of IoT consumers; (2) framework design, defining the access-control framework, developing both low-level algorithmic designs and high-level architectural plans, designing interaction procedures between IoT service providers and consumers, and creating a delegation-enforcement mechanism for distributed open environments; (3) implementation, realizing the designed framework using simulator software and hardware equipment selected for their relevance to real-world IoT environments; (4) verification, rigorous testing and debugging against criteria of efficiency, reliability, and security; and (5) maintenance, establishing a systematic method for reporting issues and requesting modifications so that the framework remains functional as requirements evolve.

This research is scoped to enterprise-grade and campus-scale IoT environments operating over IP-based networks. The following are explicitly outside the scope of this work: resource-constrained IoT protocols such as LoRa, Zigbee, and MQTT at the device level (though edge computing is retained as a bridging layer); wireless physical-layer security; blockchain-based decentralization mechanisms; and formal mathematical security proofs. The framework was evaluated in a simulated environment using EVE-NG and VMware ESXi and has not been tested on physical IoT sensor hardware. Prior to implementation, four measurable success criteria were established: (i) encrypted tunnels achieving 100% session encryption; (ii) correct, automated access revocation whenever a CVSS score exceeds 7.0; (iii) processing of all Active Directory authentication requests without manual intervention; and (iv) a demonstrably strong score across the ten IoT security requirements listed in Section 2.1, assessed comparatively in Section 5.5. These criteria are the benchmark against which the results in Section 5 are assessed.

Generative artificial intelligence (Claude, Anthropic) was used during the preparation of this manuscript to assist with restructuring and drafting text from the authors’ own prior thesis and conference-paper material, and in generating the comparative-table layout; it was not used to generate, analyze, or interpret any experimental data. All AI-assisted text was reviewed, verified against the source material, and edited by the authors, who take full responsibility for the content of this publication. See also the Acknowledgments section.

3.2. Distributed IoT Resource Analysis

IoT deployments span diverse use cases, from consumer-level asset tracking to large-scale industrial applications such as monitoring containers on cargo ships, and are typically highly distributed across central office headquarters, branch offices, internal users and devices, and remote users or guests. Four distinct IoT architectures recur across such deployments and were used to organize the framework’s policy space: centralized-based, service-based, client-based, and end-to-end-based access. This four-way categorization is proposed by the present authors, derived from analysis of a representative distributed organizational network topology (central office, branch offices, and remote client/service users), rather than adopted from an existing taxonomy in the literature. Each architecture requires a bespoke access-control policy and corresponding access-control information (ACI), so the framework’s design steps (Section 3.4) were tailored separately to each of the four architectures.

3.3. Access-Control Framework Design Goals

The proposed access-control framework (ACF) was designed to meet the following operational requirements: (1) handling of access-control-related security threats to proactively protect sensitive resources; (2) alleviation of administrative effort by automating access-control processes rather than relying on manual management; (3) simplified, accelerated rule definition for complex scenarios; and (4) a delegation-enforcement mechanism that automatically performs delegation, revocation, and verification of access rights in distributed open environments. In addition, the framework was designed to support scalability across distributed environments through modular and incremental deployment, fine-grained at the instance level rather than the class level, generic enough to be adapted to other domains with minimal modification, and available through a combination of reliability and redundancy, with traffic distributed across multiple firewall hosts to sustain performance under load.

3.4. Methodical Analysis of Access-Control Processes

The security requirements driving the framework’s design steps were derived through structured threat identification. The primary threat categories addressed by the five design steps below, unauthorized access, user-privilege escalation, and man-in-the-middle attacks, map as follows: policy representation (Step 1) primarily addresses privilege escalation; ACI representation, allocation, and binding (Steps 2–4) address unauthorized access; and ACI protection (Step 5) addresses interception and tampering threats. A fourth threat category, endpoint compromise, is addressed separately through the defense-in-depth layers described in Section 3.5. The overarching objective is to mitigate unauthorized exchange of data and resources within IoT systems, pursued through three sub-goals: access control that functions within a single security domain or across multiple domains; context-based access control that responds dynamically to factors such as time, location, or access route; and reactive authorization control capable of responding to changes in authorization in real time during an ongoing access session.

The five design steps are as follows. Step 1, establishing access-control policy representations, defines security policies aligned with organizational IoT security requirements, including two default policies: a primary default policy that is automatically activated immediately after any access attempt to mitigate well-known threats (IP address spoofing, denial-of-service and Smurf attacks, malicious ICMP messages, trace-route reconnaissance, and unnecessary open ports), and a secondary default policy that redirects any initiator not explicitly granted or denied access to a guest web page. Step 2, establishing ACI representations, determines the attribute types of ACI elements based on the established policy. Step 3, allocating ACI to elements, assigns specific attribute values to initiators, targets, and access requests. Step 4, binding ACI to elements, securely links ACI to its respective elements to preserve integrity and consistency. Step 5, protection of ACI, safeguards ACI from unauthorized access, alteration, or loss during storage and transmission. Figure 1 shows the resulting decision logic: an initiator’s access request is first evaluated against the primary default policy; requests that pass are then evaluated against a set of identity-based access-control policies; and requests that are neither explicitly granted nor denied are finally routed according to which of the four IoT architectures (service-based, centralized-based, client-based, or end-to-end-based) the initiator belongs to, with unmatched requests falling through to the secondary default policy and a guest web server.

Building on the mapping above, and as an informal security argument pending future formal verification: Steps 2–4 bind every access decision to verified ACI rather than to an unauthenticated request, so an initiator without valid, bound attributes cannot reach the identity-based policy stage shown in Figure 1. Step 1’s default policy evaluates every request against known-threat signatures before any identity-based grant is considered, so an attacker cannot bypass privilege checks by manipulating request ordering. Step 5 requires ACI to be protected in storage and transit, consistent with the AES-256/SSL encryption verified in Section 5.1. Formal verification of these properties using ProVerif or Tamarin is identified as future work in Section 7.

Figure 1. Decision logic of the proposed access control framework, from initial request through default policies, identity-based policies, and architecture-specific access-control policies.

Figure 1. Decision logic of the proposed access control framework, from initial request through default policies, identity-based policies, and architecture-specific access-control policies.

3.5. Defense-in-Depth Integration

To harden the framework against the threat categories identified above, a defense-in-depth approach was integrated around the network core, combining four complementary layers, illustrated in Figure 2 from outermost to innermost. Endpoint security provides identity and device security-policy compliance for every connected client. Communications security provides information assurance across all data in transit. Perimeter security secures the boundaries between network zones. Core network security protects against malicious software and traffic anomalies, enforces network policies, and ensures survivability; it is realized through a Domain Controller that combines Domain Name System (DNS), Authentication, Certificate Authority (CA), and Virtual Private Network (VPN) services, consolidating these responsibilities to ensure that all connected devices and users comply with defined security regulations.

4. Implementation

The designed access-control framework (Figure 1) was implemented using the network topology shown in Figure 3, presented as one representative example of the broader testbed used for evaluation. The topology consists of a private network segmented into three VLANs (VLAN 10 and VLAN 30 for two internal departments, and VLAN 50 for the server room); a demilitarized zone (DMZ) hosting outside-facing servers (a web server and a database server) together with the additional Domain Controller, the Identity Services Engine (ISE), a Layer-2 switch, and a virtual PC used for testing, with the DMZ perimeter enforced by a router and the Main-Office Adaptive Security Appliance (ASA) firewall; and a public network representing two independent remote sites, a service-based user and a smart home, each connecting to the main office over its own separate VPN tunnel rather than to one another, illustrating the remote-access path a user would take to reach either the organization’s services or their own smart-home resources.

The Active Directory Domain Controller is structured into four distinct Organizational Units (OUs), each tailored to the security requirements of one of the four IoT architectures introduced in Section 3.2: a Service-Base OU applying uniform policies to service-oriented devices and applications; an End-to-End-Base OU securing end-to-end communication channels and maintaining data integrity across the network; a Centralized-Base OU enforcing centralized policy over shared databases, control systems, and servers; and a Client-Base OU applying tailored access controls to individual client devices. This OU structure operationalizes the four-architecture design of Section 3.2 directly within the domain controller and allows additional OUs to be created as new IoT architectures or use cases emerge, without disrupting existing policy assignments.

Implementing this topology required integrating several critical components. A Domain Controller centralizes the management of security policies and user authentication across the network, serving as the authoritative entity for domain services so that every access request is verified against a secure, centralized directory; it also hosts DNS, DHCP, and CA services. An Additional Domain Controller, placed in the DMZ alongside the ISE, provides high availability. A Layer-3 switch is configured as the Internal Network Access Device (Internal NAD), acting as the Access Enforcement Function (AEF) that enforces the access decisions made by the Access Decision Function (ADF). A router configured with access control lists provides zone-based firewalling between VLANs at the back-end DMZ perimeter, while the Main-Office ASA forms the front-end DMZ perimeter, configured simultaneously as a VPN server, as the enforcement point for the primary default access-control policy, and as the External NAD to the ISE. The ISE itself serves as the ADF, evaluating access requests against security policies and rendering real-time grant/deny decisions through its Threat-Centric Network Access Control (TC-NAC) service, which lets administrators craft authorization policies directly from threat and vulnerability attributes supplied by integrated adapters and adjust endpoint access levels in real time as detected severity changes, the mechanism underlying the CVSS-triggered revocation behavior reported in Section 5.1. Authentication for service-based and remote users is enforced through Multi-Factor Authentication (MFA), combining a knowledge factor (password), a possession factor (a registered device or token), and, for devices capable of it, a biometric factor, with digital certificates used for endpoint devices capable of performing encryption directly. The access-control testbed comprised approximately ten simulated client machines acting as access initiators across the four architectural scenarios. In parallel, the integrated Cisco AMP environment contained 42 managed endpoint records, providing endpoint-health, threat, vulnerability, and compromise telemetry to the ISE policy engine. The AMP-managed endpoints were used to validate threat-informed policy integration rather than as a controlled concurrent-load population; Figure 3, presented as one representative example of the topology, shows eight of these explicitly, with the remainder distributed across the same VLAN structure during evaluation. A separate ASA firewall at the smart home establishes a secure IPsec site-to-site VPN tunnel with the Main-Office ASA, and Cisco AnyConnect client software establishes a secure remote-access VPN tunnel for the service-based user. Finally, a third-party posture-validation vendor, Cisco Advanced Malware Protection (AMP), supplies the ISE with data on each initiator’s health condition, verifying that connecting devices adhere to security regulations before access is finalized.

The implementation was conducted using a virtual-machine architecture on a high-performance server: an emulated virtual environment (EVE-NG) running on VMware ESXi 6.0, deployed on an HP ProLiant DL380 G7 server with a 12-core Intel Xeon CPU and 51 GB of RAM. This virtualized environment enabled deployment of enterprise operating systems, including Windows Server 2012 for Active Directory, and provided a cost-effective, flexible platform for testing multiple configurations and simulating a range of operational scenarios.

Figure 3. Implemented network topology used to instantiate the proposed access control framework.

Figure 3. Implemented network topology used to instantiate the proposed access control framework.

5. Results

5.1. Connectivity, Encryption, and Threat-Driven Revocation

Site-to-site connectivity between the smart home and the main office network was verified by successful bidirectional ping between the two networks’ internal test hosts, with round-trip times of 4.4–10.2 ms from the main office to the smart home and 4.5–48.1 ms in the reverse direction (one of five packets timed out in the reverse direction, consistent with VPN tunnel negotiation on first contact); reported as illustrative connectivity verification rather than a rigorous performance characterization, given the limited sample size, and the Cisco Adaptive Security Device Manager (ASDM) confirmed an active IPsec site-to-site session between the Smart-Home ASA and the Main-Office ASA. Encryption statistics for both directions of this session showed 100% encrypted traffic using the AES-256 algorithm, satisfying success criterion (i) defined in Section 3.1. Remote connectivity for the service-based user was likewise verified: after establishing an AnyConnect VPN session to the Main-Office ASA, the service-based user successfully reached the internal test host across four packets (0% loss, average 18 ms; likewise illustrative rather than a formal benchmark), and ASDM confirmed that this remote-access session was encrypted using an SSL tunnel. Together, these results confirm that both the site-to-site and remote-access paths of the defense-in-depth architecture deliver end-to-end encrypted communication with network-layer latency consistent with typical VPN-tunneled connections, as designed.

The framework’s automated revocation mechanism was configured around a quantifiable threat indicator: a threshold of 7.0 was selected because it corresponds to the conventional boundary between “Medium” and “High” severity in the CVSS v3.1 specification, aligning automated revocation with a widely recognized industry severity tier rather than an arbitrary cutoff [38], a CVSS score greater than 7.0 automatically triggers revocation and delegation of the corresponding client’s access permissions (applied at the next policy refresh cycle for an already-active session), without manual administrative intervention, satisfying success criterion (ii). Revocation withdraws the client’s current access rights on threshold breach; delegation is the subsequent reassignment of that session to a restricted or guest-tier policy rather than full termination, both triggered by the same CVSS event. Cisco AMP continuously assessed client susceptibility to security breaches and synchronized its findings with the ISE in real time, giving administrators a unified view of client health, including antivirus status, AMP-connector status, and detected threats or vulnerabilities, and a root-cause breakdown of detected threats, which together inform the ISE’s access decisions.

The threat-driven decision mechanism was implemented directly within the ISE authorization policy. A dedicated CVSS_GreaterThan_7 rule was evaluated before the architecture-specific authorization rules. When the threshold condition was satisfied, the endpoint’s existing authorization was revoked through a Change of Authorization (CoA) process and the endpoint was reassigned to the GuestAccess profile; otherwise, evaluation proceeded to the corresponding service-based, client-based, end-to-end, or centralized authorization rule. This provides implementation-level evidence that the CVSS threshold was operationalized as an access-control condition rather than used only as a conceptual risk indicator.

5.2. Endpoint Security Telemetry

The integrated Cisco AMP environment provided operational endpoint-security telemetry that was synchronized with the ISE and used as contextual input for policy evaluation. The monitored environment contained 42 endpoint records and reported multiple categories of endpoint-health and threat information, including antivirus status, compromises, detected threats, malicious items, and network-related security events. Table 1 summarizes the principal indicators visible during the evaluation. These values represent operational security telemetry rather than independent experimental trials or concurrent access requests.

5.3. Policy Enforcement Behavior and Edge Cases

Live ISE logs, generated under the “Remote Initiators” policy set, demonstrate the framework’s decision logic in operation and surfaced three notable outcomes during testing. First, an initiator not belonging to any joined domain was correctly denied access, confirming that the enforcement mechanism rejects unrecognized identities as intended. Second, an internal user lacking remote-access permission was not blocked outright but was instead assigned a GuestAccess authorization profile through the default policy rule, a graceful-degradation outcome rather than a hard failure. Third, a user belonging to the Service_Based_Users group was correctly authorized through the ServiceBasedInitiator policy and assigned a ServiceBasedUsersAccess profile; achieving this behavior required manually reordering the ISE policy sequence so that the ServiceBasedInitiator rule was evaluated ahead of the default rule, a configuration dependency that should be documented for deployment guidance. This log-level evidence confirms that all Active Directory authentication requests were processed automatically by the ISE without manual intervention during evaluation, satisfying success criterion (iii).

Table 2 shows the functional validation of representative authorization outcomes.

These observations provide functional evidence that the implemented policy engine produced distinct authorization outcomes according to identity, group membership, and endpoint risk state.

It is acknowledged that controlled access-request testing was conducted using approximately ten simulated initiators within EVE-NG on VMware ESXi, although the integrated AMP environment contained 42 managed endpoint records supplying operational security telemetry. Quantitative performance metrics, authentication latency, policy-decision throughput, and resource consumption under load, were not measured in this study. This is a limitation: the framework’s behavior under high-concurrency conditions and with larger device populations remains untested, and controlled load testing is identified as a priority for future work (Section 6.2).

5.4. Conformity to Research Objectives

This section reconciles the results above against the three research objectives set out in Section 1.2, which the four success criteria of Section 3.1 were designed to operationalize into measurable outcomes. Objectives 1 and 3 were fully achieved: the implemented framework demonstrates a generic, deployable access-control architecture with automated delegation and revocation, and the dynamic interplay between Cisco AMP, the ISE, and the network devices successfully executed delegation, revocation, and verification without manual oversight. Objective 2, a generic framework that streamlines rule definition for complex scenarios, was substantially achieved under simulated conditions: the integration of a third-party posture-validation vendor with ISE Policy Sets proved effective for real-time risk evaluation and simplified rule creation, but full validation of this objective requires testing with real IoT hardware and larger device populations, as discussed in Section 6.2.

Taken together, these results also address the three research questions stated in Section 1.1. RQ1 is addressed by the implemented context-aware architecture integrating identity management, defense-in-depth protection, and automated policy enforcement. RQ2 is addressed by the demonstrated CVSS-triggered CoA mechanism, which automates revocation and reassignment of access rights without manual intervention. RQ3 is addressed through the comparative benchmark in Section 5.5, which evaluates the proposed ACF against nine existing frameworks across the ten established IoT security requirements.

5.5. Comparative Benchmark Against Existing Frameworks

The proposed ACF was scored against the same ten IoT security requirements used in Table 3, using the same three-point scale and identical scoring criteria, to allow direct comparison with the nine existing frameworks reviewed in Section 2.3. The proposed ACF satisfies light-weight solutions through its modular design, which minimizes overhead; partial decentralization through distributed policy enforcement at network branches, within an otherwise centralized AAA architecture; end-to-end security through dedicated encrypted channels (Section 5.1); strong identity management through its AAA-based architecture, which also reinforces privacy through fine-grained access control and local processing of sensitive data; mobility and dynamic support through adaptive, context-aware mechanisms that maintain seamless operation as nodes move or conditions change; architectural scalability and incremental deployment through modular components; Robustness, self-healing, reliability, and real-time data-freshness through smart policy-set rules combined with contextual information (notably the CVSS-triggered revocation mechanism of Section 5.1) that allow the system to detect anomalies and react autonomously; and composition, heterogeneity, interoperability, and cross-domain federation through standardized interfaces, semantic compatibility, and interoperable policies that let users join the nearest available branch domain.

Table 3 includes the proposed ACF as the tenth column alongside the nine comparator frameworks. The proposed framework scored “Good Satisfied” (2) in seven of the ten requirements, with three exceptions: Decentralized management, reflecting its centralized AAA architecture; and Scalability/Incremental deployment and Composition/Heterogeneity/Interoperability, reflecting the scale and vendor-dependency limitations discussed in Section 6.2; all three scored “Well Satisfied” (1). Notably, Identity Management is a near-universal strength across the comparator field (seven of nine frameworks score “Good Satisfied”), so the proposed ACF’s performance here is consistent with, rather than distinctive from, existing practice. Robustness/Self-healing/Reliability/Real-time shows a genuine split: only three of the nine comparators [28,33,34], score “Good Satisfied”, while the remaining five score “Well Satisfied” or below. The proposed ACF joins this stronger-performing group through its CVSS-triggered, quantifiable revocation mechanism (Section 5.1), which gives an administrator a specific, auditable trigger for access revocation rather than a qualitative or best-effort resilience claim. This is consistent with the central design claim of Section 3.3: that integrating an AAA-based identity architecture with a quantifiable, CVSS-triggered revocation mechanism supports robust, evidence-based access control, even where identity management alone is no longer a differentiating capability among current frameworks.

Table 3. Comparison of the proposed ACF with nine existing access-control frameworks across ten IoT security requirements (0 = Not addressed/not demonstrated (Not Satisfied); 1 = Partially addressed (Well Satisfied); 2 = Strongly addressed with corresponding mechanism described and evaluated.

IoT Security Requirement	[23] Hsu	[24] Xue	[27] Yang	[28] Sun	[33] Awan	[34] Kalaria	[35] Karankar	[36] Zhu et al.	[37] Sathya et al.	Proposed ACF
Light-weight solutions	2	2	0	2	1	2	2	2	1	2
Decentralized management	1	1	2	2	2	1	1	2	2	1
End-to-end security	2	2	1	2	2	2	2	1	1	2
Identity management	2	2	2	2	2	1	2	2	1	2
Privacy	2	2	2	2	2	2	1	2	2	2
Mobility/Dynamic	2	1	1	2	2	2	1	2	1	2
Scalability/Incremental deployment	2	1	1	2	1	2	2	2	2	1
Robustness/Self-healing/Reliability/Real-time	1	1	1	2	2	2	1	1	1	2
Composition/Heterogeneity/Interoperability	2	1	0	1	1	2	1	2	1	1
Federation in administration domains	2	1	0	2	1	1	1	2	1	2

Table 3. Comparison of the proposed ACF with nine existing access-control frameworks across ten IoT security requirements (0 = Not addressed/not demonstrated (Not Satisfied); 1 = Partially addressed (Well Satisfied); 2 = Strongly addressed with corresponding mechanism described and evaluated.

IoT Security Requirement	[23] Hsu	[24] Xue	[27] Yang	[28] Sun	[33] Awan	[34] Kalaria	[35] Karankar	[36] Zhu et al.	[37] Sathya et al.	Proposed ACF
Light-weight solutions	2	2	0	2	1	2	2	2	1	2
Decentralized management	1	1	2	2	2	1	1	2	2	1
End-to-end security	2	2	1	2	2	2	2	1	1	2
Identity management	2	2	2	2	2	1	2	2	1	2
Privacy	2	2	2	2	2	2	1	2	2	2
Mobility/Dynamic	2	1	1	2	2	2	1	2	1	2
Scalability/Incremental deployment	2	1	1	2	1	2	2	2	2	1
Robustness/Self-healing/Reliability/Real-time	1	1	1	2	2	2	1	1	1	2
Composition/Heterogeneity/Interoperability	2	1	0	1	1	2	1	2	1	1
Federation in administration domains	2	1	0	2	1	1	1	2	1	2

For the two requirements underlying the comparative discussion above, scores were anchored as follows. Identity Management: [37] scores 1, as it implements role-based token authentication without a registration or identity-lifecycle mechanism; [34] similarly scores 1, as its framework explicitly defers identity/registration to prior work and only retrieves pre-existing subject attributes at runtime. All other comparators, [23,24,27,28,33,35], and [36], score 2, each implementing identity generation, registration, or verification as a first-class, evaluated mechanism (e.g., near-user Security Agent-based key management for [23]; group-signature-based anonymous authentication for [24]; blockchain address-based identity for [27]; identity-based signatures for [28]; blockchain wallet registration for[33]; token-based authentication for [35]; public-key and JWT-based identity for [36]).

Robustness/Self-healing/Reliability/Real-time: [28,33], and [34] score 2, through mechanisms that address genuine resilience to node failure or compromise, Byzantine fault tolerance in [28]’s consensus layer; continuous trust-level recalculation and automatic device quarantine on anomalous behavior in [33]; and adaptive, feedback-driven policy adjustment reducing central-cloud dependency in [34]. [23] scores 1, as its revocability mechanism addresses only Security Agent corruption rather than broader fault tolerance; [24] and [37] score 1, addressing availability under attack (DoS resistance, edge-based blocking) or data tamper-evidence rather than self-healing or fault recovery; [27,35], and [36] score 1, as each addresses only latency, message-delivery, or architectural resilience in general terms, [35] via RabbitMQ’s fault-tolerant message queuing, rather than a demonstrated mechanism for node failure or compromise.

Decentralized management: [27,28,33,36], and [37] score 2, each implementing an architecture with no single point of policy authority — blockchain-address identity for [27]; per-domain local ledgers with channel-based off-chain decisions for [28]; blockchain-based registration and IPFS-distributed storage for [33]; blockchain governance combined with edge-based processing for [36]; and decentralized storage with edge inference for [37]. [23,24,34], and [35] score 1: [23] and [34] each move only a bounded function (cryptographic offload; context adjustment) to a near-user or fog component while retaining a centralized core; [24]’s edge authentication reduces round trips to a central provider but does not remove it; and [35]’s smart-contract layer is explicitly noted by its own authors to depend on blockchain consensus, a centralizing bottleneck for time-sensitive decisions. The proposed ACF’s Domain Controller and ISE likewise serve as the authoritative identity and decision points, with only enforcement distributed to network branches; it is scored 1 on this basis, consistent with [23] and [34]. Scalability/Incremental deployment: [28,34,35,36], and [37] score 2, each describing an explicit mechanism for adding capacity without redesigning the system — per-domain ledger partitioning for [28]; edge-ward fog deployment for [34]; load-tolerant message queuing for [35]; explicit design for scalable, distributed access management for [36]; and an edge-native inference architecture for [37]. [23] also scores 2, as its object-based security-service model is adoptable without redesigning the underlying IoT protocol stack. [24,27], and [33] score 1: [24]’s hash-chain overhead reduction is a per-request efficiency gain rather than a described deployment mechanism, and [27] and [33] rely on blockchain components whose node-scaling behavior is not evaluated in the cited work. The proposed ACF scores 1 on the same basis: Section 5.5 describes scalability as achieved through modular, addable components, but this was not evaluated under increasing load (Section 6.2), matching the partial-evidence standard applied to [24,27], and [33].

6. Discussion

6.1. Interpretation of Results

The results in Section 5 support the central claim of this paper: that a context-aware, policy-driven access-control framework integrating AAA-based identity management, real-time CVSS-triggered revocation, and a defense-in-depth architecture can achieve strong real-time robustness while matching the identity-management performance common across most existing frameworks in Table 3. The proposed ACF’s reliance on a centralized AAA architecture combined with a quantifiable, automatically evaluated threat indicator (CVSS > 7.0) allows it to score well on both dimensions simultaneously, at the cost, discussed below, of the decentralization and vendor-independence that blockchain- and open-source-based approaches offer more naturally.

This robustness performance is not unique to the proposed ACF: framework [33], a zero-trust, ABAC-based design built on continuous behavioral assessment, also scores “Good Satisfied” on Robustness (Table 3). The two approaches reach this outcome by different means. Framework [33] computes a continuous, behavior-derived trust score for every access request, which is well suited to detecting gradually emerging anomalies but requires ongoing behavioral profiling infrastructure. The proposed ACF instead triggers revocation from a discrete, externally sourced vulnerability score (CVSS), which is simpler to audit and reason about, an administrator can point to the exact CVSS threshold that triggered a given revocation, but is only as timely as the vendor feed supplying it, and does not itself model gradual behavioral drift. Which approach is preferable is likely deployment-dependent, and a direct empirical comparison of the two under identical conditions is a natural direction for future work.

Table 4 positions the proposed ACF against the three closest design lines discussed in Section 2.3.

Beyond the representative access-control initiators used in the EVE-NG topology, the integration with an AMP environment containing 42 managed endpoint records demonstrates that the policy architecture can consume security telemetry from a broader operational endpoint population; nevertheless, this evidence should be interpreted as integration validation rather than a formal scalability benchmark.

6.2. Limitations

Several limitations qualify these findings. Scalability is constrained: as the number of devices and transactions grows, the additional computational cost of gathering initiator health state, encryption, and validation restricts throughput, and reducing these safeguards to improve performance would compromise security, a fundamental trade-off between efficiency and robust protection that this study did not attempt to resolve quantitatively. Resource-constrained devices remain only partially addressed: the proposal secures data transmission for devices capable of performing encryption directly, and edge computing is adopted as a bridging layer for devices with limited resources, but secure data transfer between resource-constrained devices and the edge-computing layer remains an open challenge requiring further work. The current implementation relies exclusively on Cisco commercial products (ISE, AMP, ASA, AnyConnect), creating a vendor lock-in constraint that limits accessibility and generalizability for organizations without Cisco infrastructure. Correct policy behavior also depended on a specific ISE policy-set ordering (Section 5.2), a configuration dependency that is not self-evident from the design alone and should be made explicit in any deployment guidance derived from this work. Similarly, CVSS-triggered revocation for an already-active session is applied at the next policy refresh cycle rather than instantaneously. Although the implemented policy explicitly distinguishes CVSS scores above the 7.0 threshold and successfully operationalizes threat-triggered CoA, controlled boundary testing using scores immediately below, at, and above the threshold was not performed. Such sensitivity testing should be included in future evaluations to characterize policy behavior around the decision boundary.

The framework’s security properties, including the correctness of policy evaluation and the absence of privilege-escalation paths, have not been formally verified using mathematical proof methods or model-checking tools such as ProVerif or Tamarin, though an informal security argument is provided in Section 3.4 The comparative scoring in Table 3 was performed by the author team from the published reports rather than through independent experimental testing, which introduces potential subjectivity into the benchmark. As a sensitivity check, one author independently re-scored all 100 framework–requirement cells using only the framework descriptions presented in Section 2.3, without consulting the original scoring matrix. Agreement was obtained for 82 of 100 cells. The 18 disagreements were concentrated in End-to-end Security, Privacy, Mobility/Dynamic Support, and Federation, where the Section 2.3 narrative did not always state a specific mechanism for the framework concerned. This indicates that some original scores relied on additional evidence obtained directly from the cited studies rather than solely on the condensed synthesis presented in Section 2.3. Because the sensitivity check was conducted internally rather than by an external independent rater, some risk of evaluator bias remains. Controlled authorization testing was conducted in a virtualized EVE-NG environment using approximately ten simulated initiators, while the associated Cisco AMP deployment contained 42 managed endpoint records that supplied operational threat and health telemetry. The latter broadens the operational evidence available to the framework but does not constitute a controlled scalability or concurrent-load test; the framework has not been tested with physical IoT sensors, actuators, or resource-constrained hardware, which may behave differently from virtualized endpoints. Finally, while basic network round-trip latency was captured for both VPN paths (Section 5.1), authentication latency, policy-decision throughput, and resource consumption under concurrent load were not measured, so the framework’s performance characteristics under realistic multi-tenant load remain unknown.

The framework’s automatic revocation of access rights based on CVSS scores also raises an ethical consideration that is worth surfacing explicitly rather than treating as a purely technical limitation: automated revocation without human review may interrupt legitimate user sessions in response to false-positive vulnerability detections, raising questions of due process and proportionality. Deployments in sensitive contexts such as healthcare IoT should incorporate a notification mechanism that alerts the affected user prior to or upon revocation, together with a defined review pathway for contested decisions.

The current CoA-based revocation mechanism (Section 5.1) operates purely at the network-enforcement level and includes no corresponding user-facing notification; the guest-redirect behavior used for unmatched initiators (Section 5.2) offers a plausible technical starting point for such a mechanism, but was not designed or evaluated for this purpose.

7. Conclusion

This paper presented the design, implementation, and evaluation of a context-aware, policy-driven access-control framework for distributed IoT environments. By integrating a domain controller, certificate authority, and Active Directory with an Identity Services Engine acting as the Access Decision Function and a third-party posture-validation vendor supplying real-time health telemetry, the framework addressed practical security challenges inherent to IoT while managing security risk, streamlining administrative processes, working toward simpler definition of complex rules, and enabling rapid delegation in a distributed environment. Benchmarked against nine existing IoT access-control frameworks across ten established IoT security requirements, the proposed framework scored “Good Satisfied” in seven of ten requirements, including Robustness/Self-healing/Reliability/Real-time, a requirement on which only three of the nine comparator frameworks scored equally well.

Table 5 summarizes the extent of this revision relative to the original paper [14].

From an architectural perspective, this work contributes an operational model for quantifiable, threat-driven dynamic access control, shifting the field from static, manually managed policies toward automated, evidence-based access governance. This principle extends beyond the specific Cisco-based implementation presented here and offers a replicable architectural model for heterogeneous IoT security research. Several avenues for future work follow directly from the limitations discussed in Section 6.2. Future studies should evaluate the framework’s scalability across larger and more heterogeneous IoT ecosystems, including testing with physical IoT sensors, actuators, and resource-constrained hardware to validate behavior beyond the virtualized testbed used here. Re-implementing the framework using open-source components, specifically FreeRADIUS as the authentication server, Keycloak for identity and access management, OpenVPN for communications security, and OpenSSL for the certificate authority, would remove the Cisco vendor dependency, reduce deployment cost, and extend the framework’s applicability to resource-limited and public-sector IoT deployments. Integrating artificial intelligence and machine learning for predictive behavioral analytics and anomaly detection could reduce dependence on external threat-intelligence providers such as AMP, particularly if locally embedded models operate in conjunction with third-party providers through an adaptive, hierarchical data-acquisition model that prioritizes local processing before resorting to remote data retrieval. Future work should also develop flexible security architectures for resource-constrained devices that adjust protection strategies to available device resources and varying network conditions, implement the human-review notification and appeal pathway for contested automated revocations proposed in Section 6.2, and examine the framework’s effectiveness across specific industry contexts such as healthcare and smart cities to identify industry-specific refinement needs. Finally, controlled load testing and CVSS threshold-sensitivity testing — using scores immediately below, at, and above the 7.0 boundary — to characterize authentication latency, policy-decision throughput, resource consumption, and revocation-boundary behavior, together with formal verification of the framework’s security properties, are necessary next steps before broader deployment can be recommended.