Closing the Loop: An Access-Control Architecture for Automated, Anomaly-Driven Network Revocation in IoT Deployments

Source: arXiv:2607.11649 · Published 2026-07-13 · By Muhammet Emir Korkmaz, Kemal Bicakci, Yusuf Uzunay

TL;DR

This paper addresses a key gap in IoT security: while network-based anomaly detection for IoT devices has achieved strong accuracy, most systems stop at alerting without automated enforcement. The authors present a closed-loop access-control architecture that links anomaly detection to automatic network enforcement using only standard, widely deployed protocols (IEEE 802.1X with EAP-TLS and RADIUS). A RADIUS server acts as a continuous policy decision point capable of evicting a device instantly via Change-of-Authorization Disconnect-Request and permanently excluding it by certificate revocation. A central policy engine consumes outputs from a one-class, anomaly-based detector that fuses clustering, volumetric, and protocol-signature scores from passively captured traffic. The detector reaches very high accuracy (AUC 0.9964) on 24 attack scenarios with a simplified pipeline requiring 43× less training data than prior work. Alerts cause automated disconnects within 335.8 ms and revocations within another 111.5 ms on average, demonstrating the feasibility of real-time automated enforcement without relying on SDN or MUD profiles.

Methodologically, the paper designs around existing enterprise infrastructure and protocols to enable deployment in typical networks without programmable data planes. It uses a controlled benign traffic generator to simulate typical IoT device behavior and passive packet capture to extract aggregate flow statistics over fixed windows. A dimensionality reduction and clustering approach models benign distributions, while additional scoring captures volumetric spikes and protocol signatures. This fused anomaly score drives the enforcement decision. The architecture unifies policy and audit logging in a central engine, enabling automatic session termination and certificate revocation driven by anomaly signals. The end-to-end testbed evaluation validates the responsive closed-loop system and discusses possibilities for multi-device scaling.

Key findings

• The proposed anomaly detector achieves an AUC of 0.9964 detecting 24 attack scenarios (8 types × 3 intensities) on a single IoT device testbed.
• It requires approximately 43× less benign training data than the reference MUD/SDN multi-model pipeline they adapt from [2].
• Automated network eviction via RADIUS Change-of-Authorization Disconnect-Request occurs within an average of 335.8 ms after an alert fires.
• Certificate revocation to permanently exclude the device completes in an additional average 111.5 ms after disconnect.
• The architecture operates entirely on standard, widely deployed protocols (IEEE 802.1X/EAP-TLS and RADIUS CoA) without need for SDN/OpenFlow or manufacturer-published MUD profiles.
• The fused anomaly score combines three components: a cluster-based model on PCA-reduced traffic statistics, a volumetric spike score, and a protocol-signature score.
• A small set of contextual policy rules govern access decisions, with anomaly-driven dynamic enforcement implemented by a narrowly-secured SSH channel to RADIUS and a token-authenticated HTTP endpoint to the certificate authority.
• The detector’s false positive rate on held-out benign data is 2.92% after thresholding at the 99th percentile cluster boundary.

Threat model

The adversary is a compromised or malicious IoT device that has authenticated onto the network with a valid certificate and tries to perform network attacks or misbehave behaviorally. The adversary cannot bypass the 802.1X authentication or forge devices' X.509 certificates, and does not have network administrator privileges or access to reconfigure RADIUS or certificate authority mechanisms. The detection and enforcement operate to identify and revoke such misbehaving devices via traffic anomaly signals, assuming standard enterprise network infrastructure without programmable data planes.

Methodology — deep read

1. Threat model & assumptions: The adversary is a compromised or malicious IoT device already authenticated to the network with a valid certificate. The architecture assumes the attacker can generate malicious network traffic after authentication to disrupt or attack the network. However, the adversary cannot bypass 802.1X authentication or easily forge device certificates. The system cannot rely on programmable data planes or manufacturer MUD profiles as these are often unavailable.

2. Data provenance & preparation: The detector is trained exclusively on benign traffic generated by a controlled benign-traffic generator run directly on the test IoT device. This generator probabilistically executes seven protocols (HTTP/HTTPS, DNS, NTP, mDNS, SSDP, ICMP echo), reflecting common IoT behavior. Passive packet capture with BPF filtering records traffic to/from the monitored device IP while excluding management flows. Collected packets are deduplicated and divided into fixed 60-second windows. Labeling is done via timestamped attack start and end intervals logged during structured testing.

3. Feature extraction and modeling: From each 1-minute window, 29 base traffic statistics are computed (packet, byte, and flow counters split by direction and protocol/port). A sliding window of 4 consecutive 1-minute windows produces per-feature aggregates: sum, mean, standard deviation, and delta, resulting in a 116-feature vector. Features are standardized then reduced by PCA, retaining 12 components covering ~90% variance. Clustering of benign windows via X-means (up to 7 clusters) identifies modes of normal behavior, with cluster boundaries defined at the 99th percentile Manhattan distance. Two additional scores compute volumetric traffic spikes and protocol-signature anomalies directly on standardized features.

4. Model training & calibration: Benign windows exclude periods around attacks and transitions to ensure purity. The data is chronologically split 70/15/15 into train/calibration/evaluation sets. Clusters are fit on training data; threshold boundaries calibrated on calibration set. Final evaluation is on held-out data with no overlap.

5. Live scoring and alerting: For each new 60-second window, features are extracted and standardized consistently, then scored by the three detectors fused by taking the largest anomaly ratio across them. A state machine raises an alert when three consecutive windows exceed threshold, triggering a signal to the policy engine.

6. Automated response pipeline: The central access policy engine listens for alert signals and automatically invokes two enforcement actions concurrently without manual confirmation: (a) a RADIUS Change-of-Authorization Disconnect-Request is sent over an SSH channel locked to a restricted wrapper script to immediately evict the device’s active session, and (b) a token-authenticated HTTP request to the certificate authority revokes the device’s certificate, updating CRLs to prevent reauthentication.

7. Evaluation protocol: Detection accuracy is measured by ROC/AUC and attack detection counts across 8 attack types at 3 intensity levels. Enforcement latency is measured end-to-end on a physical testbed between alert onset and enforcement completion. False positive rates are reported on held-out benign windows. No direct adversarial evasion tests or multi-device cross-validation are performed.

8. Reproducibility: The paper does not mention public release of code or data. Benign traffic is generated by a custom controlled generator and feature extraction is described in detail, enabling reproducibility in principle but with high engineering effort. The detector adapts existing work [2] but modifies data capture and score fusion.

Technical innovations

• A closed-loop IoT access-control architecture that uses only widely deployed protocols (802.1X/EAP-TLS and RADIUS CoA) to automate device eviction and certificate revocation triggered by anomaly detection.
• A unified anomaly detector combining cluster-based, volumetric, and protocol-signature scores on passively captured traffic, replacing prior MUD/SDN multi-model pipelines and reducing benign training data needs by ~43×.
• A contextual policy engine with condition-action rules that automates enforcement actions over narrowly restricted channels to RADIUS and the certificate authority, supporting dynamic session termination and permanent exclusion.
• Demonstration of rapid automated enforcement: network session eviction in ~336 ms and certificate revocation completion in ~112 ms after anomaly alert.

Datasets

• Benign traffic generated by a custom in-situ benign traffic generator simulating typical IoT network behavior across seven protocol categories; dataset size approximately 345 windows for training, unknown total size.
• Attack dataset includes 24 scenarios (8 attack types × 3 traffic intensity levels) carried out on a single physical IoT device testbed.

Baselines vs proposed

• Reference design [2]: Multi-model MUD/SDN-based anomaly detector using per-flow telemetry with AUC close to 0.9964, but requiring 43× more benign training data than proposed detector.
• Proposed fused detector: AUC = 0.9964 versus reference design; false positive rate = 2.92% on held-out windows (no comparable FPR reported for baseline in this detail).
• Automated enforcement latency: disconnect in 335.8 ms and cert revocation in 111.5 ms (baseline: no automated enforcement).

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.11649.

Fig 1: System architecture. The IoT device presents a certificate issued by the certificate authority and authenticates via 802.1X/EAP-TLS through the access

Fig 2: Overall data flow of the anomaly-detection pipeline, from controlled

Fig 3: Structure of the 116-dimensional feature vector: four rolling-window

Fig 4: Distribution of benign windows across six X-means clusters (56–78

Fig 5: Score computation and fusion pipeline: the cluster-based (PCA) score,

Fig 6: Alarm state machine. Three consecutive anomalous windows raise

Fig 7: Automated response flows, both triggered by the same alert-onset transition (Section IV-F), with no separate confirmation step between them. (a)

Fig 8: Testbed topology. Attacks are launched from the Kali VM toward the device under test; benign traffic is generated on the device itself (Section IV-A).

Limitations

• The evaluation is performed on a single IoT device testbed; multi-device or large-scale deployment performance is not evaluated.
• No adversarial robustness or evasion attacks against the anomaly detector or policy enforcement are tested.
• The detector excludes transition windows around attacks from training and evaluation, potentially biasing results to cleaner benign/anomalous separation.
• Coarse enforcement granularity: only whole-session eviction rather than fine-grained per-flow blocking due to reliance on RADIUS rather than SDN.
• No public release of code or datasets is noted, limiting immediate reproducibility.
• Enforcement timing and anomaly detection thresholds may vary with network conditions and device types not extensively tested.

Open questions / follow-ons

• How well would the proposed detector and closed-loop enforcement scale and generalize across large heterogeneous IoT device populations and network topologies?
• What are the implications of coordinated, stealthy adversaries that attempt to evade one-class traffic anomaly detection or spoof benign traffic patterns?
• Can the fine-grained per-flow or capability-level enforcement granularity be integrated with this approach without requiring SDN?
• How does the system perform over longer-term deployments with evolving benign device behaviors and certificate lifecycle management?

Why it matters for bot defense

This work is highly relevant to bot-defense and CAPTCHA practitioners focused on IoT and enterprise network security, as it demonstrates a practical, deployable closed-loop system that links anomaly detection directly to timely automated network enforcement without relying on complex SDN infrastructure or vendor-specific profiles. The architecture and policy engine design provide a model for integrating network-traffic-based anomaly signals into identity- and certificate-driven access control, offering a pathway to more robust automated incident response in IoT-heavy environments. Bot-defense engineers could draw inspiration from the narrowly scoped enforcement channels and the fusion of detection signals that combine volumetric and protocol signatures. While this system focuses on network-level bot evictions rather than application-layer challenges, the underlying principle of linking detection to automated policy actions in real time is broadly applicable. Challenges remain in scaling, evasion resistance, and heterogeneous devices, which would be important to consider for CAPTCHA integration scenarios involving IoT-originated attacks.

Cite

@article{arxiv2607_11649,
  title={ Closing the Loop: An Access-Control Architecture for Automated, Anomaly-Driven Network Revocation in IoT Deployments },
  author={ Muhammet Emir Korkmaz and Kemal Bicakci and Yusuf Uzunay },
  journal={arXiv preprint arXiv:2607.11649},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.11649}
}

Read the full paper

• arXiv:2607.11649 (abstract)
• arXiv:2607.11649 (PDF)