EASA: An Edge-Centric Adaptive Security API for AIoT Devices

1. Introduction

Sensing devices that carry their own inference—cameras, pre-processing sensors, hubs fusing telemetry from dozens of nodes—are now deployed in numbers that make per-device security management impractical. These AIoT fleets stress security designs inherited from enterprise networks: heterogeneous capability makes one cryptographic policy too heavy for a battery-powered sensor or too weak for a mains-powered camera; long lifetimes and rare patching mean a device trustworthy at enrolment may not be a year later; and the edge tier is itself a target [1,2], while cloud latency and intermittent availability exclude the cloud from the time-critical decision path considered here [3].

Recent threat-intelligence reports describe AI-assisted reconnaissance and agentic workflows for vulnerability scanning and credential harvesting [4,5]. For API-mediated AIoT deployments, these observations reinforce the need to reassess the privileges of authenticated devices and to propagate credential revocations across sites, motivating continuous enforcement that responds locally under device-resource and connectivity constraints. The experiments in this paper evaluate that control loop through scripted trace replay; autonomous AI-agent attacks and application-level API vulnerabilities are outside the evaluated scope.

The literature has moved security to the edge and made it adaptive: gateways externalising authentication and intrusion prevention [6], zero-trust admission control that scores every message and can accept, challenge or revoke [7], learned trust with resource-stress evidence gating federated task placement [8] and machine-learning detection of zero-trust violations at the 5G edge [9]. Read together, they leave three gaps. First, the enforcement a trust or risk value triggers is per message or per task, binary (admit, block) or outside the evaluated system; a persistent, graded per-device security state, stepped up and relaxed with hysteresis, is not evaluated, although it follows the continuous-evaluation principle of zero-trust architecture [10,11]. Second, the device’s own state (energy, compute headroom, link quality, firmware integrity), already reported for its own management, enters these designs, if at all, as evidence of suspicion or a scheduling constraint rather than as a budget for the response—what is needed to decide how to respond to a suspicious device without draining a legitimate one. Third, the cloud is absent or only an analytics back-end, so the functions at which a single gateway is weakest—detecting an attack family another site has seen and rejecting a credential revoked elsewhere—are not measured, nor is the cost of reaching a real cloud service.

This paper presents the Edge-centric Adaptive Security API (EASA): an edge gateway exposes a small set of security primitives to devices and cloud services and continuously re-negotiates each device’s security level from a composite trust score fusing a per-flow anomaly detector’s output with the device’s reported posture and decision history. A policy decision point maps the score, with hysteresis, to four enforcement levels from normal operation to quarantine, and a cloud service holds the state shared across gateways—an aggregated detector, versioned policy, a revocation registry—without being in the decision path. Every component can be disabled, so the baseline comparison is an internal ablation, not a re-implementation contest.

We evaluate EASA as a system prototype on the flow-based release of the CIC IoT-DIAD 2024 dataset [12,13], replaying per-address traces of 65 real consumer devices of the CIC testbed under synthetic attack campaigns against three emulated gateways and a cloud service on Google Cloud Run in the Seoul region, so every cross-gateway interaction incurs a real round trip. As the release is not labelled per flow, we release a transparent row-level labelling rule and state its limits; as configurations that compute trust differently sit at different operating points for one threshold, we calibrate each to the same target false-positive rate on a benign segment preceding the evaluated one before comparing recall, containment and overhead. The contributions are:

• An edge-centric security architecture whose API contract, composite trust score, state-transition rules and four-level policy are specified so that baselines inspired by four design classes—static authentication, gateway virtual security functions, rule-based zero-trust admission and network-only learned trust—are configurations of the same implementation, with evaluated, emulated and specified-only parts stated (Section 3).
• A reproducible evaluation protocol on IoT-DIAD 2024: row-level labelling with disclosed attacker sets, device-level trace replay, forced cross-site and credential-replay campaigns, operating-point calibration at a fixed target false-positive rate, and metrics with stated units and denominators (Section 4).
• Evidence over 30 paired seeds, at a common target false-positive rate on clean devices, that the cloud’s federated model raises recall on attack families a gateway never saw, but another site had, from 0.24 to 0.60, and its revocation registry catches 81% of credential-replay epochs over all runs (85% when a revocation exists), a family a local detector catches only by coincidence; that the full configuration restricts more attack episodes than the per-alarm configuration with a stronger detector while isolating about 45% fewer clean devices (4.2% vs. 7.7%; a whole-configuration trade-off); that the energy-aware action selector, isolated with everything else held equal, performs 37% fewer re-authentication handshakes in a low-battery scenario with no detected change in detection or restriction metrics; and the negative results that the composite trust score, with the cloud held constant, does not demonstrate an improvement on any detection metric and lengthens benign-side restriction—a lock-in that a trajectory audit traces to the decaying history term and that a history reset reduces but does not remove—that the graded loop is not faster than per-alarm blocking, and that a stronger per-flow detector detects in-distribution attacks better (Section 5).
• A measured account of the real cloud path: 596 calls per run at a 103 ms mean per-run median round trip in the main EASA runs, zero failures across the 270 cloud-dependent runs, per-seed metrics identical to those of an in-process mock, and a 15-minute outage after warm-up that reduces replay rejection with no change detected in the evaluated local metrics (Section 5.5 and Section 5.8).

The paper is organised as follows. Section 2 (Related Work) analyses lightweight authentication, edge-externalised security, zero-trust and learned trust at the edge, federated learning and their evaluation datasets, and positions EASA against the closest designs. Section 3 (Proposed Architecture: Edge-Centric Adaptive Security API (EASA)) describes the architecture. Section 4 (Experimental Setup) describes the data, emulation, calibration and baselines. Section 5 (Experimental Results) presents the results. Section 6 (Discussion) analyses their limits and practical implications. Section 7 (Conclusions) concludes. The simulator, labelling rule, cloud service and all configuration files are released with the paper.

2. Related Work

We group prior work by the question it answers—device authentication, security externalised to the edge, trust assessment, the cloud’s contribution—and close with the datasets that make such systems comparable. Table 1 aligns the closest designs on the four axes our evaluation measures.

2.1. Lightweight Authentication for Cloud-Connected IoT

Lightweight authentication and key agreement for constrained devices—three-party authentication for cloud-connected services [14], provably secure mutual authentication for cloud-based IoT [15], elliptic-curve protocols with tracking-resistant dynamic credentials [16]—decides whether a device may join. Such protocols are verified against protocol-level adversaries and costed by computation and communication, which the handshake dominates on constrained nodes; the DTLS measurements of Raza et al. [17] are why EASA treats a re-handshake as a costed action, not a free check. By design they are blind to what a device does after joining: a compromised device with valid credentials passes every check. EASA does not replace them—its $L_2$ step-up invokes whichever handshake the device class supports—but adds the continuous assessment that decides when the handshake is worth its cost. Static authentication is baseline B0.

2.2. Security Externalised to the Edge

Many devices cannot run security functions at all, so a second line moves them to a gateway. The IoT Proxy [6] externalises a static chain of virtual network security functions (VPN termination, a machine-learning intrusion prevention system) that protects resource-limited devices transparently: an IPS alarm blocks the flow, and a device’s posture does not change with evidence. Two earlier gateways, the nearest precedents of our enforcement tier, keep a per-device restriction state. IoT SENTINEL [18] fingerprints the device type from enrolment traffic, looks it up in a vulnerability database and assigns one of three gateway-enforced isolation classes (strict, restricted, trusted), with policy cached at the gateway and refreshed periodically from a remote server; its Raspberry Pi gateway evaluation measures traffic latency to local and remote servers, including an Amazon EC2 endpoint. IoT-KEEPER [19] detects malicious activity with a fuzzy-clustering classifier over flow features and moves the offending device, by link-layer address, into one of three overlay networks (no access, restricted, full) via software-defined flow rules; analysis runs on the gateway, policies and trained rules are described as shareable across gateways, and the evaluation is a Raspberry Pi testbed with real devices. Neither specifies or evaluates the trust-threshold, hysteresis-based bidirectional controller studied here (IoT-KEEPER describes policy-cache expiry and overlay-network updates; otherwise a class is set at identification or at detection), budgets the response by the device’s reported resources, or evaluates the cross-site functions—a shared detector and a shared revocation list—against a deployed service with measured round trips. EASA adds that closed loop (a graded level stepped up and relaxed over time with hysteresis from a continuously updated trust value, an action selector conditioned on reported energy, separately measured cloud functions) but, unlike both, is not evaluated on gateway hardware. Realguard [20] couples a gateway intrusion detector to an action manager that logs, notifies or blocks, so gateway detection-to-response coupling is established; open is the shape of the response state. A patent [21] describes, without a published evaluation, a gateway that periodically summarises device interactions, receives a cloud signature and flags deviations. The IoT Proxy’s per-alarm blocking inspires baseline B1; what the gateway should do between “allow” and “block” is the subject of our four-level policy.

2.3. Zero Trust and Learned Trust at the Edge

Zero-trust architecture [10] prescribes continuous evaluation of every access and a policy engine acting on it; surveys [11,22] find that engine its least specified component, and its IoT transfer has been argued as principles for non-human identities [23] and surveyed across cloud, edge and fog [1,2,24]. IoT trust management is older: Yan et al. [25] classify trust by the properties it aggregates, Chen et al. [26] combine direct observation with recommendation and decay it over time (the pattern of our decision-history term), and ledger-backed trust is surveyed in [27]; these models rarely specify the enforcement a trust value triggers, our question here. Dimitrakos et al. [28] formulated trust-aware continuous authorization for consumer IoT, and Jeong and Yang [29] select allow, additional authentication or block from a weighted trust score over user behaviour, network environment, device status and threat history, reassessed during a session; EASA builds on this established score-to-policy pattern. YB-IoT-CG [7] screens each authenticated message with a deterministic, policy-based risk score over freshness (nonce, timestamp), gateway-observed context and firmware-state evidence, answers Accept, Challenge or Revoke per message, anchors confirmed revocations on a permissioned ledger with an on-chain registry, and is evaluated by packet-level simulation on synthetic traffic. EdgeGuard-AI [8] keeps a per-node trust value with exponential forgetting from flow statistics (bursts, flag behaviour, anomaly concentration) and resource-stress indicators (CPU, memory, queue pressure); trust gates which nodes receive sensitive tasks under a risk budget, with federated averaging at the server, so trust selects where work is placed, resource stress is evidence of suspicion, and what remaining energy should change about the response is not modelled. Ashfaq et al. [9] predict zero-trust violations at the 5G edge with machine learning on CICDDoS2019 in an SDN emulation; the loop closes at detection. Aydin’s federated multi-agent defence (FMAD) for edge–cloud IoT [30] validates only the threat-intelligence agent empirically; the mitigation agent remains at design level.

EASA evaluates what this set lacks: a persistent, graded per-device security level with explicit escalation and release rules (YB-IoT-CG decides per message, EdgeGuard-AI gates placement), stepped up and relaxed over time with hysteresis; the device’s reported resource posture as a budget for the response (EdgeGuard-AI reads resource stress as evidence, but neither design lets a low battery change which enforcement action is taken); and cross-gateway model and revocation services. The first two cost one posture beacon per epoch and one bit per past decision, and Section 3.3 and Section 3.4 make the case that both change the right enforcement action.

2.4. Federated Learning and the Role of the Cloud

Federated learning shares detector knowledge across sites without sharing traffic [31,32]. For IoT intrusion detection, Rahman et al. [33] compare centralised, on-device and federated training, finding federated detectors close to centralised ones on non-IID NSL-KDD partitions; Mothukuri et al. [34] federate a recurrent detector over device traffic; DÏoT [35] established federated, device-type-specific anomaly detection across local security gateways; Nguyen et al. [36] show that compromised IoT devices can poison the training traffic of otherwise uncompromised federated gateways; and partitioned IIoT data has been federated [37]. In all of these the cloud is an aggregator and the quantity of interest is model accuracy. Unmeasured are what a federated model does for the security policy of a gateway that has never seen a given attack family, and the second cross-site function—propagating one gateway’s revocation to the others—for which blockchain ledgers have been proposed [7]. We treat both as first-class cloud functions, evaluate them against a real deployment, and quantify what is lost when the cloud is unreachable.

2.5. Datasets and Evaluation Practice

Comparable evaluation depends on shared data used without the closed-world assumptions Sommer and Paxson [38] warned against; Ring et al. [39] catalogue the available network datasets and their recurring labelling and representativeness problems. Consumer IoT traffic is sparse and periodic with few endpoints per device [40], which makes device-level replay meaningful and lets a gateway identify device types [18]; the Mirai family dominating IoT botnet datasets is described in [41]. CICIoT2023 [42] provides 33 attacks in seven classes from a testbed of 105 real devices; its flow-based 2024 re-release, IoT-DIAD [12,13], adds endpoints and timestamps to every flow, enabling device-level replay. TON_IoT [43] and Edge-IIoTset [37] add telemetry and multi-tier captures. Two cautions shaped our protocol: Purkaystha et al. [44] report that a naive Bot-IoT split in their study contained up to 97% duplicate rows and that zero-day performance must be measured on families held out of training, both of which we adopt; and threat-model studies of sensing systems [45] argue for explicit trust zones across sensor, edge and cloud, which our system model follows.

2.6. Positioning

In Table 1, “graded” means more than two persistent enforcement levels per device and “deployed cloud” a service reached over the Internet with measured round trips; detection-only designs such as [9] are omitted because they do not enforce at all. Graded per-device isolation at a gateway is not new—IoT SENTINEL and IoT-KEEPER both assign a device to one of three classes—and score-to-policy control with session reassessment is established [29]. What this study contributes is an API-based integration and a controlled trace-replay evaluation of persistent device-level restriction, resource-conditioned response selection, and shared model and revocation services, quantifying their detection and restriction-cost trade-offs with a measured cloud path; no design in this set evaluates that combination, and because each is evaluated in its own environment, their numbers cannot be compared with one another. We do not claim to reproduce these designs: the baselines of Table 5 are configurations of EASA inspired by selected design classes of the table—selected traits (detector family, binary or graded enforcement, cloud functions used), implemented once in our simulator and run on the same traces at the same target operating point—and are internal ablations standing in for a design class, not re-implementations of a particular paper or reproductions of its reported performance.

Table 1. Closest designs on the four axes measured in this paper, summarised from the cited papers.

Work	Trust input	Enforcement	Cloud role	Evaluation
Lightweight AKA [14,15,16]	credentials only	admit at join	key/registration server	protocol cost, formal proof
IoT Proxy [6]	IPS alarm	allow / block	none	testbed throughput
IoT SENTINEL [18]	device-type fingerprint + vulnerability database	three isolation classes, assigned at identification	policy server (cached, refreshed)	Raspberry Pi gateway; traffic latency to local and remote servers incl. an EC2 endpoint
IoT-KEEPER [19]	fuzzy-clustering anomaly score on flow features	three overlay networks per device, assigned at detection	none in the evaluation (policy sharing described)	Raspberry Pi testbed, real devices, accuracy and overhead
YB-IoT-CG [7]	deterministic risk score: freshness, context, firmware evidence	per-message Accept / Challenge / Revoke	ledger-anchored revocation registry	packet-level simulation, synthetic traffic
Trust-score ZTA [29]	weighted score: user behaviour, network, device status, threat history	allow / additional authentication / block, reassessed in session	policy server	real-world performance evaluation
EdgeGuard-AI [8]	learned trust from flow statistics + resource stress	binary admissibility gate for task placement	federated aggregation server	replay of Edge-IIoTset flows
FMAD [30]	threat-intelligence agent	designed, not evaluated	federated agents	detector only, CIC-IoT-2023
EASA (this paper)	network + reported posture + decision history	four persistent graded levels; posture budgets the $L_2$ action	federated model + revocation registry, outside the decision path	replay of IoT-DIAD 2024 device traces, deployed cloud (Cloud Run, Seoul), ablation at a fixed target FPR

Table 1. Closest designs on the four axes measured in this paper, summarised from the cited papers.

Work	Trust input	Enforcement	Cloud role	Evaluation
Lightweight AKA [14,15,16]	credentials only	admit at join	key/registration server	protocol cost, formal proof
IoT Proxy [6]	IPS alarm	allow / block	none	testbed throughput
IoT SENTINEL [18]	device-type fingerprint + vulnerability database	three isolation classes, assigned at identification	policy server (cached, refreshed)	Raspberry Pi gateway; traffic latency to local and remote servers incl. an EC2 endpoint
IoT-KEEPER [19]	fuzzy-clustering anomaly score on flow features	three overlay networks per device, assigned at detection	none in the evaluation (policy sharing described)	Raspberry Pi testbed, real devices, accuracy and overhead
YB-IoT-CG [7]	deterministic risk score: freshness, context, firmware evidence	per-message Accept / Challenge / Revoke	ledger-anchored revocation registry	packet-level simulation, synthetic traffic
Trust-score ZTA [29]	weighted score: user behaviour, network, device status, threat history	allow / additional authentication / block, reassessed in session	policy server	real-world performance evaluation
EdgeGuard-AI [8]	learned trust from flow statistics + resource stress	binary admissibility gate for task placement	federated aggregation server	replay of Edge-IIoTset flows
FMAD [30]	threat-intelligence agent	designed, not evaluated	federated agents	detector only, CIC-IoT-2023
EASA (this paper)	network + reported posture + decision history	four persistent graded levels; posture budgets the $L_2$ action	federated model + revocation registry, outside the decision path	replay of IoT-DIAD 2024 device traces, deployed cloud (Cloud Run, Seoul), ablation at a fixed target FPR

3. Proposed Architecture: Edge-Centric Adaptive Security API (EASA)

In the Edge-centric Adaptive Security API (EASA) an edge gateway exposes a small, stable set of security API primitives to AIoT devices and cloud services and continuously re-negotiates each device’s security posture from a composite trust score. Its design goals follow from the gaps of Section 2:

G1

Closed loop. Trust assessment and policy enforcement are coupled in a single sense–score–decide–enforce–observe cycle rather than treated as independent modules [8,9].

G2

API abstraction. Devices, gateways and cloud services interact only through a declared API contract, so the adaptation logic is independent of any particular authentication protocol or gateway implementation [6,7].

G3

Resource-aware adaptation. Device resource posture (energy, compute headroom, link quality) is an explicit input to the trust model, not merely a deployment constraint [23].

G4

Cloud as a first-class participant. The cloud layer owns the global trust model, cross-gateway threat correlation, policy distribution and revocation—functions that no single edge node can perform alone [24].

G5

Comparability. Every component of the composite score and of the cloud path can be disabled, so that baselines inspired by the published designs of Section 2 are configurations of the same implementation (Section 3.8).

3.1. System Model and Threat Model

 Entities. Devices $\mathcal{D}=\{d_1,\dots ,d_N\}$ attach to a gateway g; a cloud security service c serves gateways $\mathcal{G}=\{g_1,\dots ,g_M\}$. A lightweight EASA client on each device emits a periodic posture beacon; the gateway hosts the Trust Scoring Engine (TSE), Policy Decision Point (PDP) and Policy Enforcement Point (PEP); the cloud hosts the Global Trust Model (GTM), policy repository, revocation registry and audit store (Figure 1).

 Trust zones. Adapting the STRIDE-based zoning of [45] to three tiers, three trust zones (device, edge, cloud) are separated by two boundaries (local wireless link, Internet uplink); cross-boundary traffic is mutually authenticated (mTLS or DTLS-PSK by device class; the prototype of Section 4 uses an API key over HTTPS at the gateway–cloud boundary).

 Adversary. The adversary may (i) compromise a legitimate device and use it to launch volumetric or reconnaissance attacks (botnet enrolment), (ii) spoof or replay device credentials, (iii) tamper with sensing payloads, and (iv) attempt lateral movement toward the gateway. The adversary cannot break standard cryptographic primitives and does not control the cloud service. We explicitly include a compromised device that keeps valid credentials, to which static authentication [14,15] is blind, and that may lie in its posture beacon (signing proves the sender, not the contents). EASA therefore treats the beacon’s resource fields as self-reported and bounds their influence (Section 3.3), and takes the integrity flag from an attestation mechanism outside the API (measured boot or remote attestation verified by gateway or cloud, not the device); in the evaluation that flag is an oracle, so the firmware-tampering results measure the policy’s response, not the attestation.

3.2. Architecture Overview

All adaptation decisions are taken at the edge within a bounded latency budget; the cloud improves them asynchronously. A gateway cut off from the cloud degrades gracefully, scoring and enforcing with its last synchronised model and policy and queueing audit events for later upload.

Figure 1. EASA architecture: the gateway closes the sense–score–decide–enforce loop locally and the cloud holds only cross-gateway state.

Figure 1. EASA architecture: the gateway closes the sense–score–decide–enforce loop locally and the cloud holds only cross-gateway state.

3.3. Composite Trust Score

For device d at epoch t the TSE fuses three normalised sub-scores in $[0,1]$ into a composite trust score $T_d\left(t\right)$.

 Network behaviour score $S_d^{\mathrm{net}}\left(t\right)$. A lightweight per-flow classifier $f_{\theta }$ (a two-layer multilayer perceptron, chosen because its parameters can be averaged across gateways; any per-flow classifier can be substituted) maps each flow $\mathbf{x}$ to an attack probability $f_{\theta }\left(\mathbf{x}\right)\in [0,1]$. With ${\mathcal{X}}_d\left(t\right)$ the flows of d in the window of length W ending at t, the window score is a top-k mean,

$${\overline{p}}_d\left(t\right)={\displaystyle \frac{1}{k}}{\displaystyle \sum _{j=1}^k}{f}_{\theta }\left({\mathbf{x}}_{\left(j\right)}\right),S_d^{\mathrm{net}}\left(t\right)=1-{\overline{p}}_d\left(t\right),$$

(1)

where ${\mathbf{x}}_{\left(1\right)},\dots ,{\mathbf{x}}_{\left(k\right)}$ are the k highest-probability flows and missing terms are zero when the window holds fewer than k flows (an empty window gives ${\overline{p}}_d=0$). This soft evidence pooling caps one confident alert at $1/k$: a single benign false alarm cannot dominate a sparse window, several alerts within W accumulate, and it is not a count rule (two alerts at probability 1 give ${\overline{p}}_d=2/3$ with $k=3$, which may or may not cross the calibrated threshold, Section 4.5). $\theta$ is initialised from the GTM, which federated-averages the gateways’ locally trained parameters (Section 3.6).

 Device posture score $S_d^{\mathrm{pos}}\left(t\right)$. From the beacon we take energy headroom $e_d$, compute headroom $u_d$ and link quality $q_d$, each clipped to $[0,1]$, and an integrity flag ${\iota }_d\in \{0,1\}$ from the attestation mechanism (firmware measurement matches the registry):

$$S_d^{\mathrm{pos}}\left(t\right)={\iota }_d·\left({\alpha }_e{e}_d+{\alpha }_u{u}_d+{\alpha }_q{q}_d\right),{\alpha }_e,{\alpha }_u,{\alpha }_q\ge 0,{\alpha }_e+{\alpha }_u+{\alpha }_q=1.$$

(2)

A failed integrity check drives $S^{\mathrm{pos}}$ to zero irrespective of resources. Because $e_d,u_d,q_d$ are self-reported, the posture term contributes at most $w_{\mathrm{pos}}$ to the instantaneous fused score ${\tilde{T}}_d$. This bounds its direct additive contribution, but it does not guarantee resistance to evasion through a falsified posture: near a threshold, the difference between a truthful low posture and a forged healthy one (up to $w_{\mathrm{pos}}$) can decide whether $L_2$ is entered, and a device that under-reports its energy can obtain the deferral of the $L_2$ re-handshake, although rate limiting and scope reduction still apply. Such resistance was not evaluated (Section 6.3). The PDP also consumes posture when selecting the enforcement action, so a low-energy benign device is not pushed into a costly re-authentication loop (G3).

 Decision history $S_d^{\mathrm{hist}}\left(t\right)$. An exponentially weighted record of the policy’s own past decisions,

$$S_d^{\mathrm{hist}}\left(t\right)=\lambda S_d^{\mathrm{hist}}(t-1)+(1-\lambda )\mathbb{1}\left[{\ell }_d(t-1)\le L_1\right],$$

(3)

where ${\ell }_d(t-1)$ is the previous level (Table 2) and $\lambda \in (0,1)$ controls memory. The decay follows the reputation models of [25,26], but the evidence is the policy’s own decision, so this is policy memory, not independent evidence: a recently restricted device recovers gradually, not at the first clean window, and one oscillating around a threshold settles at the stricter level. The price, a slower return to $L_0$ after a false alarm, is measured (post-attack dwell, restricted share of benign epochs; Section 5.1) and bounded analytically in Section 3.4.

Fusion and smoothing.

$${\tilde{T}}_d\left(t\right)=w_{\mathrm{net}}{S}_d^{\mathrm{net}}\left(t\right)+w_{\mathrm{pos}}{S}_d^{\mathrm{pos}}\left(t\right)+w_{\mathrm{hist}}{S}_d^{\mathrm{hist}}\left(t\right),T_d\left(t\right)=\beta T_d(t-1)+(1-\beta ){\tilde{T}}_d\left(t\right).$$

(4)

Here $w_{\mathrm{net}},w_{\mathrm{pos}},w_{\mathrm{hist}}\ge 0$ sum to one, $\beta \in [0,1)$, and $T_d\left(0\right)=S_d^{\mathrm{hist}}\left(0\right)=1$ (a new device is trusted until evidence accrues). Weights and $\beta$ are policy parameters, possibly per device class. The defaults ($0.60/0.25/0.15$, $\beta =0.7$) encode two design decisions, not a fit to the test data: network evidence is the only term that can detect an attack, so it must carry a device across the restriction threshold alone ($w_{\mathrm{net}}>\frac{1}{2}$); posture and history are regularisers whose combined weight should separate a clean record from none, while the bound $w_{\mathrm{pos}}+w_{\mathrm{hist}}<\frac{1}{2}$ limits the direct weighted contribution of a forged posture to $w_{\mathrm{pos}}$ (Section 3.1); it does not by itself guarantee that a forged posture cannot keep a device above a calibrated threshold, and resistance to such evasion is not verified in this paper. Whether the regularisers add detection value at a fixed operating point is an empirical question, answered negatively for this formulation in Section 5.1; Appendix C varies $w_{\mathrm{net}}$ over $[0.4,0.8]$. Setting $w_{\mathrm{pos}}=w_{\mathrm{hist}}=0$ recovers a purely network-driven trust model in the spirit of [8], and replacing $f_{\theta }$ with a deterministic screen in the spirit of [7] a rule-based score; these reductions underlie Section 3.8.

3.4. Security Levels and Policy Decision

The PDP maps $T_d\left(t\right)$ to four discrete security levels with hysteresis (Table 2): promotion to a stricter $L_k$ is immediate when $T_d<{\tau }_{Lk}$; relaxation requires $T_d>{\tau }_{Lk}+\delta$ for h consecutive epochs. The thresholds fix the operating point and are set from the benign distribution of $T_d$ to meet a target false-positive rate (Section 4.5).

Table 2. Security levels enforced by the PEP (each level applies its actions in addition to those of the levels below it).

Level	Trust band	Enforcement actions (PEP)
$L_0$ Normal	$T_d\ge {\tau }_{L1}$	Default token TTL; baseline telemetry rate; full API scope.
$L_1$ Observe	${\tau }_{L2}\le T_d<{\tau }_{L1}$	Token TTL halved; telemetry rate $\times 2$; audit event to cloud; no user-visible change.
$L_2$ Restrict	${\tau }_{L3}\le T_d<{\tau }_{L2}$	Step-up re-authentication (mTLS re-handshake or challenge); per-device rate limit; API scope reduced to read-only / essential endpoints; cloud notified for cross-gateway correlation.
$L_3$ Quarantine	$T_d<{\tau }_{L3}$ or ${\iota }_d=0$	Traffic dropped at PEP; credential pushed to cloud revocation registry; neighbouring gateways alerted; manual or policy-timed release.

Table 2. Security levels enforced by the PEP (each level applies its actions in addition to those of the levels below it).

Level	Trust band	Enforcement actions (PEP)
$L_0$ Normal	$T_d\ge {\tau }_{L1}$	Default token TTL; baseline telemetry rate; full API scope.
$L_1$ Observe	${\tau }_{L2}\le T_d<{\tau }_{L1}$	Token TTL halved; telemetry rate $\times 2$; audit event to cloud; no user-visible change.
$L_2$ Restrict	${\tau }_{L3}\le T_d<{\tau }_{L2}$	Step-up re-authentication (mTLS re-handshake or challenge); per-device rate limit; API scope reduced to read-only / essential endpoints; cloud notified for cross-gateway correlation.
$L_3$ Quarantine	$T_d<{\tau }_{L3}$ or ${\iota }_d=0$	Traffic dropped at PEP; credential pushed to cloud revocation registry; neighbouring gateways alerted; manual or policy-timed release.

Posture modulates which $L_2$ action is chosen: below an energy floor the PDP prefers rate limiting and scope reduction to cryptographic step-up and marks the re-handshake pending; it executes at the first later epoch at which the device is still at $L_2$ or stricter with $e_d$ above the floor, and is cancelled if the device first relaxes to $L_1$ or $L_0$ (rate limit and scope reduction having been lifted). This is how resource awareness changes behaviour (G3) rather than merely being measured.

 State transitions and recovery. Table 3 makes the transition rules explicit, one row per case, including the cases Algorithm 1 handles when the level does not change; in the table ℓ is the previous level, T the current trust, ${\tau }_{Lk}^{\mathrm{x}}={\tau }_{Lk}+\delta$ the exit threshold of $L_k$, and “Action” the one-shot action issued in that epoch in addition to the level’s standing enforcement (Table 2), “none” being the default when nothing changes. Three properties matter for the evaluation. (i) Promotion is immediate and driven by $T_d$, ${\iota }_d$ or the revocation cache; relaxation is one level at a time and requires $T_d$ to exceed the exit threshold ${\tau }_{Lk}+\delta$ for h consecutive epochs. (ii) Every entry into $L_3$ publishes a revocation, and a revoked or tampered credential holds the device at $L_3$ while the revocation is in force; the policy-timed release of Table 2 applies only to a credential that has been reinstated. Re-enrolment after a quarantine (new credential, registry update) is an operator action outside the API and is not modelled, so in the evaluation $L_3$ is absorbing within a run. (iii) Because $S^{\mathrm{hist}}$ decays while a device is restricted, a device at $L_2$ can only recover if its other evidence suffices without history: asymptotically, $L_2\to L_1$ requires $w_{\mathrm{net}}{S}^{\mathrm{net}}+w_{\mathrm{pos}}{S}^{\mathrm{pos}}>{\tau }_{L1}-w_{\mathrm{hist}}{S}^{\mathrm{hist}}$, with $S^{\mathrm{hist}}\to 0$ in the worst case. With the calibrated thresholds of Section 5.9 (${\tau }_{L1}\approx 0.74$) and the default weights, a benign device recovers whenever its window score satisfies ${\overline{p}}_d<1-(0.74-0.25S^{\mathrm{pos}})/0.60$, i.e. ${\overline{p}}_d<0.16$ for a mains-powered device ($S^{\mathrm{pos}}\approx 0.95$) and ${\overline{p}}_d<0.10$ for a sensor node at 60% charge ($S^{\mathrm{pos}}\approx 0.80$). The condition is not guaranteed: a benign device whose traffic the detector finds persistently suspicious, or whose reported resources are low (with $S^{\mathrm{pos}}=0.55$ and a clean network score the asymptotic fused score is $0.738<0.743$), can remain at $L_2$ until an operator intervenes, and the policy provides no finite recovery guarantee. We report the observed restricted share of benign epochs and the post-attack dwell (Section 5.1) and audit the saved trajectories for benign devices still restricted at the end of a run (Section 5.7), which finds exactly this lock-in. A history reset after h consecutive epochs with a clean network score at $L_2$ removes the dependence; it was not part of the pre-specified protocol and is evaluated as a supplementary revision.

3.5. Adaptive Security API

The API is deliberately small (Table 4); devices use only the first group and the cloud sees only the last. Cloud calls carry a model version for drift detection; repeating a revocation or model push with the same version has no further effect (idempotent), whereas a repeated audit event is stored twice and de-duplicated by event identifier at analysis time. In Table 4, D, E and C denote the device, the edge gateway and the cloud; the frequencies are design defaults, which the evaluation compresses for the cloud intervals (Section 4.6); and the last column states, for each primitive, whether it is exercised over HTTPS against the deployed service in the evaluation of Section 5 (net), emulated in-process in the simulator (emu), or specified but not implemented (spec).

Three device-facing endpoints fit a constrained-device footprint; a posture beacon is a few dozen bytes and can piggyback on an MQTT keep-alive.

3.6. Role of the Cloud Layer

Three functions are impossible at a single gateway. The global trust model and revocation registry are implemented in the deployed service and evaluated; policy distribution is specified and, in the evaluation, replaced by the per-run calibration of Section 4.5; the audit store is an event sink only—cross-gateway correlation on its contents is a design goal (G4) that we do not evaluate.

• Global Trust Model. Each gateway trains $f_{\theta }$ on local traffic from a common initialisation and uploads its parameters; once all have pushed, the cloud computes a sample-weighted federated average [31] and redistributes $\theta$ with a new version, so an attack family first seen at $g_i$ raises $f_{\theta }$ sensitivity at $g_j$ before it is attacked (evaluated as cross-site generalisation, Section 5).
• Policy distribution. Weights, thresholds and hysteresis parameters are versioned in the cloud; operators tune a device class once and all gateways converge within one sync period.
• Revocation and correlation. An $L_3$ event publishes the credential to the registry; other gateways pull it within the revocation interval and pre-emptively place any device presenting it at $L_3$. The audit store receives every level transition and is intended for post-incident reconstruction and cross-site threat correlation.

Under cloud unavailability (Section 3.2) a gateway keeps deciding with its last synced model and revocation list and only cross-gateway state ages (quantified in Section 5.5).

3.7. Decision Procedure

Algorithm 1 summarises one decision epoch at the gateway.

Algorithm 1:EASA decision epoch at gateway g for device d

Require:  flows ${\mathcal{X}}_d\left(t\right)$ of the window, posture $(e_d,u_d,q_d,{\iota }_d)$, previous $T_d(t-1)$, ${\ell }_d(t-1)$, $S_d^{\mathrm{hist}}(t-1)$, ${\mathrm{pending}}_d$, policy $(\theta ,\mathbf{w},\beta ,\tau ,\delta ,h,e_{\mathrm{floor}})$ Ensure:  level ${\ell }_d\left(t\right)$, enforcement action $a_d\left(t\right)$ 1: $S^{\mathrm{net}}\leftarrow 1-{\overline{p}}_d\left(t\right)$, ${\overline{p}}_d\left(t\right)$ = top-k mean of $f_{\theta }$ over ${\mathcal{X}}_d\left(t\right)$▹ Eq. (1) 2: $S^{\mathrm{pos}}\leftarrow {\iota }_d({\alpha }_e{e}_d+{\alpha }_u{u}_d+{\alpha }_q{q}_d)$▹ Eq. (2) 3: $S^{\mathrm{hist}}\leftarrow \lambda S_d^{\mathrm{hist}}(t-1)+(1-\lambda )\mathbb{1}[{\ell }_d(t-1)\le L_1]$▹ Eq. (3) 4: $T_d\left(t\right)\leftarrow \beta T_d(t-1)+(1-\beta )(w_{\mathrm{net}}{S}^{\mathrm{net}}+w_{\mathrm{pos}}{S}^{\mathrm{pos}}+w_{\mathrm{hist}}{S}^{\mathrm{hist}})$ 5: $a_d\left(t\right)\leftarrow none$▹ default: standing enforcement of the current level only 6: if${\iota }_d=0$or credential of d in revocation cache then 7:     ${\ell }_d\left(t\right)\leftarrow L_3$▹ persists while the condition holds 8: else 9:     ${\ell }_d\left(t\right)\leftarrow MapWithHysteresis(T_d\left(t\right),{\ell }_d(t-1),\tau ,\delta ,h)$▹ Table 3 10: end if 11: if${\ell }_d\left(t\right)\ne {\ell }_d(t-1)$then 12:     Audit$(d,{\ell }_d(t-1)\to {\ell }_d\left(t\right))$; Enforce(standing actions of ${\ell }_d\left(t\right)$, Table 2) 13:     if ${\ell }_d\left(t\right)=L_2$and${\ell }_d(t-1)<L_2$ then 14:         if $e_d<e_{\mathrm{floor}}$ then 15:            ${\mathrm{pending}}_d\leftarrow \mathbf{true}$▹ energy-aware deferral 16:         else 17:            $a_d\left(t\right)\leftarrow StepUp$ 18:         end if 19:     end if 20:     if ${\ell }_d\left(t\right)<L_2$ then 21:         ${\mathrm{pending}}_d\leftarrow \mathbf{false}$ 22:     end if 23:     if ${\ell }_d\left(t\right)=L_3$ then 24:         $a_d\left(t\right)\leftarrow Drop$; PublishRevocation$\left(d\right)$ 25:     end if 26: else if${\ell }_d\left(t\right)\ge L_2$and${\mathrm{pending}}_d$and$e_d\ge e_{\mathrm{floor}}$then 27:     $a_d\left(t\right)\leftarrow StepUp$; ${\mathrm{pending}}_d\leftarrow \mathbf{false}$▹ deferred re-handshake executed 28: end if 29: return${\ell }_d\left(t\right),a_d\left(t\right)$

The per-epoch cost is one (batched) classifier inference per flow plus a top-k selection and $O\left(1\right)$ arithmetic per device, so latency grows with flows per window rather than device count alone; under a flood the flow rate sets the bound. Cloud calls (model pull, revocation poll, audit) are off the decision path, which uses the last synchronised model and revocation list. We report the cost measured in the emulation and do not extrapolate it to flood rates we did not run (Section 5.8).

3.8. Comparability Design

To satisfy G5, EASA is evaluated against configurations of itself that stand in for the design classes of Section 2, within the same simulator and on the same traces (Table 5; “Inspired by” names the design class each configuration stands in for, and the integrity gate ${\iota }_d=0\Rightarrow L_3$ is common to every configuration except B0). They are inspired by, not reproductions of, the cited designs, and each adopts selected traits rather than the cited system’s control semantics: B1 takes a strong per-flow classifier and per-alarm blocking (the IoT Proxy’s IPS chain), B2 a deterministic screen with binary admission and a shared revocation path (YB-IoT-CG’s screening and registry), and B3 a learned, network-only, exponentially forgotten trust with federated aggregation (EdgeGuard-AI’s trust evidence and server)—but B3 applies that trust to four persistent device-level restriction levels, which is not EdgeGuard-AI’s placement-admission control, and none of the three carries the cited system’s other machinery (virtual security function chaining, a ledger, a scheduler) or reproduces its reported performance. Read as ablations, the pairs EASA vs. EASA−C (cloud removed, everything else equal) and EASA vs. EASA−PH (posture and history removed, everything else equal) isolate the cloud layer and the composite score respectively, and EASA−PH vs. B3 (which differ only in the registry and the energy-aware action) isolates the registry in the main experiment, where the energy branch is never exercised. The design avoids the apples-to-oranges comparisons that arise when numbers are copied across papers.

All configurations share the metrics of Section 4.7: detection at the $L_2$ boundary per device-epoch (recall, F1, false-positive rate); share of attack episodes reaching a restricting level and the delay to it; benign-side cost (false quarantine, restricted share of benign epochs, post-attack dwell); re-authentications per device-hour; and, for the cloud ablation, cross-site recall when the attack family was absent from the local training split and the credential-replay catch rate. Datasets and simulation environment are described in Section 4.

4. Experimental Setup

This section describes the data, emulation, detector, operating-point calibration, cloud deployment and metrics used to evaluate EASA against the baselines of Table 5. One configuration file drives every run, so each number below traces to a reproducible run; simulator and configuration are released with the paper.

4.1. Research Questions

• RQ1 (composite trust). At the same target false-positive operating point and with the cloud functions held constant, what does fusing reported posture and decision history with the network score (Eq. 4) change in the trade-off between the share of attack episodes reaching a restricting level (and cross-site recall) and the benign-side cost (restricted benign epochs, post-attack dwell, false quarantines), compared with a network-only score?
• RQ2 (closed loop). Does the four-level loop reach a restricting level sooner after attack onset than per-alarm blocking, and restrict fewer benign devices while doing so? (The first half is answered negatively in Section 5.1.)
• RQ3 (cloud layer). Does the cloud layer do work at which a single gateway is weakest: (a) detecting attack families never seen locally but seen at another site, (b) catching credentials revoked elsewhere, and (c) what is lost, and what is not, when the cloud is unreachable?
• RQ4 (resource awareness). Does energy-aware action selection reduce the security cost borne by battery-powered devices?
• RQ5 (measured cloud latency). What round-trip latency and call volume does a real, regionally deployed cloud service impose on the cross-gateway functions, and what does that imply for sizing an asynchronous gateway loop? (The simulator is synchronous, Section 4.6; RQ5 measures the endpoint, not an asynchronous decision loop.)

4.2. Dataset and Row-Level Labelling

We use CIC IoT-DIAD 2024 [12,13], the flow-based release of the CIC IoT testbed (105 consumer devices; directory AD_Flow-based-features, downloaded September 2026), whose packet captures also underlie CIC-IoT-2023 [42]. Flows are extracted by the dataset authors with CICFlowMeter [46]; each CSV has 84 columns: a flow identifier, source and destination address and port, timestamp, protocol, 76 statistical features and a Label. The 132 files (14.7 GB) form seven attack families—DDoS, DoS, Mirai, Reconnaissance, Spoofing, Web and Brute-Force—plus a benign chain of four consecutive files ($\approx 28$ h). Unlike the 2023 release, every flow carries addresses and timestamp, which makes device-level trace replay (Section 4.3) possible. The model input is the 77 numeric columns (protocol and the 76 statistics); identifier, addresses, ports, timestamp and label are never fed to a detector. Non-finite values (zero-duration division) are set to zero and headerless single-row files (the DoS TCP-flood captures) are dropped.

Label holds the placeholder NeedManualLabel in every row of every downloaded file; the release is labelled per capture, an attack capture being a full-LAN capture containing the attacking Raspberry Pis, the victims and all other devices. We therefore assign row labels with a transparent dominant-source rule, a weak label treated as such below. For each attack type, in-subnet source addresses (192.168.137.0/24, router excluded) are ranked by share of the type’s flows; addresses holding at least 5% (at most eight per ranking) form the attacker set $\mathcal{A}$, and a flow is attack iff its source or destination is in $\mathcal{A}$. For ICMP and Mirai floods, whose flows collapse under CICFlowMeter’s 5-tuple aggregation, the attacker set is the union of the flow-share and packet-share rankings, hence Mirai’s eleven designated attackers (Appendix A). Types whose attacker set covers less than 40% of the capture and whose largest attacker holds less than 25% (ARP Spoofing, Uploading, XSS, Brute-Force) cannot be labelled this way and are excluded; the remaining 11 types and their attacker sets are listed in Appendix A. Under this rule 75.7% of the sampled working rows from the retained attack captures (1,287,458 of 1,700,965) are attack flows; the rest are benign background traffic, kept as additional benign samples. Two consequences are carried through the paper. First, the label is per attacker address, so every flow of an attacking Pi during a capture—including its benign housekeeping traffic—is labelled attack; this can distort reported recall, in either direction, on families whose attack flows resemble sessions, and is why per-family results are reported. Second, the rule uses only the address share of flows and never a flow’s own features, so the detector is not trained on its own output; but the label is volume-based, so a count- or rate-based detector could learn a shortcut to it, and its accuracy—whether the designated addresses are the attackers and whether their traffic with other devices is attack traffic—has not been verified against packet captures, which we do not hold, or any independent ground truth. The detection results of Section 5 are therefore results on synthetic campaigns built from weakly labelled attacker traces, not a measurement of real-attack detection accuracy. Appendix E reports how much attacker sets and row labels move when the thresholds are varied, on the raw captures and on the working data.

Because the testbed LAN uses DHCP, an address identifies a device only within one capture chain. The 68 in-subnet addresses of the benign chain form the device universe; 65 have enough benign traffic for a replayable per-address trace, and “device” below means such a trace. Table 6 summarises the working set after family-balanced sampling (500k rows per family, as four contiguous time windows per file, preserving inter-flow timing within a window), a per-file time-based split (first 60% of each file’s timeline for training, next 10% validation, last 30% test and replay), exact-duplicate removal within the training split (111,229 rows, 8.8%) and feature scaling fitted on the training split only (signed $\log (1+|x\left|\right)$ then standardisation; CICFlowMeter features are heavy-tailed). Splitting by time within each capture, not by capture or device, measures generalisation to later traffic of the same testbed, not to a new site. Rows are never shared between splits (each row has one index), but near-duplicates across the time boundary are not removed, and the three gateways’ training sets overlap (each is the training split minus one held-out family)—a federation of sites seeing the same campaigns, not an independent-site setting.

4.3. Trace-Replay Emulation

The simulator emulates $M=3$ edge gateways, each owning 21–22 of the 65 device traces (round-robin), one in-process trust engine and PDP per gateway, and one cloud security service. Benign traffic is not sampled from a feature pool: each device replays its own address’s flows from the evaluation segment of the test split (the two thirds not used for calibration, Section 4.5) in availability order with the measured gaps between consecutive availability times (gaps above 60 s clipped; random phase per seed; the trace wraps if exhausted, which Appendix F quantifies: 7 of the 65 evaluation traces are shorter than one run). While compromised, a device additionally replays the flows of one designated attacker of the campaign family in the same way, so attack intensity, burstiness and within-burst feature distributions are those of the capture, not of a traffic model. Level-2 rate limiting and Level-3 isolation act on the emitted flows: the $L_2$ limit of 2 flows/s drops records (uniformly at random) above that rate—a limit on sessions per second, not packets—and $L_3$ drops every record.

Two qualifications apply. First, the schedule is synthetic: which device is compromised, when and for how long is drawn per seed (Table 7); overlaying an attacker’s trace on a benign trace does not reproduce the session-level correlations of the original capture, and clipped gaps and four-window subsampling do not preserve long idle periods; the replay preserves measured within-burst timing and feature distributions, not the full timeline. Second, a flow record carries completed statistics (duration, packet counts, inter-arrival times) that an online extractor has only at the flow’s end or timeout, so each record becomes visible at its CICFlowMeter start timestamp plus its duration, and no feature is used before a packet-level extractor could have computed it. The duration is capped at the 120 s flow timeout, which would make a longer record visible early, but no record in the working data exceeds the timeout (CICFlowMeter terminates flows at it), so the cap is never binding (Appendix F). A flow is attributed to the window in which it becomes visible; we do not claim sub-window timing precision.

CICFlowMeter flows are sessions, and consumer IoT traffic is sparse and periodic [40]: a benign device emits only $\approx 0.02$ flows per second, and floods arrive in bursts (DDoS: 2.7 flows/s on average, but 88% of one-second intervals are empty). We therefore use a decision epoch of 10 s and a flow window of 120 s, CICFlowMeter’s default flow timeout, so a window is at least as long as any single flow record; it is not guaranteed to contain a complete record, since benign devices emit only a few per window. Each run lasts one simulated hour.

Ten attack campaigns per run have uniformly random onset and duration and each compromise 15% of one gateway’s devices (Table 7). Three are forced to use a family the target gateway never trained on (cross-site campaigns, Section 4.4); one is a credential-replay campaign in which devices at one gateway present a credential already used by a flood campaign at another gateway while their traffic stays benign—the only way to measure the revocation path, since no local detector can see it; the rest are drawn from the traffic families, firmware tampering (${\iota }_d=0$) and further credential replays with the probabilities in Table 7.

Device posture follows a parametric model with four classes (camera, hub, battery-powered sensor node, mains-powered appliance; shares, battery capacity, idle drain and per-flow cost in Table 7), spanning a coin-cell environmental sensor to a streaming camera; an mTLS re-handshake costs 8 mWh, the order of a full-power radio transmission on a constrained node. Link quality is drawn per device from $\mathcal{N}(0.85,0.08)$ and CPU headroom recovers with a 5 s time constant.

4.4. Detector and Federated Warm-Up

$f_{\theta }$ is a two-layer multilayer perceptron (77–128–64–1, ReLU, dropout 0.1, Adam with learning rate ${10}^{-3}$, batch 4,096) on the flow features; we chose an MLP over gradient-boosted trees because its parameters can be averaged, which the cloud’s global trust model requires. An XGBoost classifier (400 trees, depth 8) is the per-flow alarm source of baseline B1, and B2 uses a deterministic rule screen in the spirit of [7]: a flow is scored by the largest standardised deviation among six rate and flag features (flow and forward packets per second, SYN and RST counts, mean inter-arrival time, forward packet count), mapped linearly to $[0,1]$ above $3\sigma$ of the benign training distribution. Every gateway trains on the training split minus one held-out family (Table 7), the non-IID situation that motivates cloud aggregation: a gateway that has never seen DDoS detects it mostly through the aggregated model (its local detector still flags a minority of such flows, Section 5.3).

Configurations with a cloud model path (B3, EASA−PH, EASA) start from a common initialisation and run 15 rounds of federated averaging [31], one local epoch per round; the cloud aggregates (sample-weighted) once all three gateways have pushed. EASA−C’s MLP trains locally for 15 epochs, an identical budget; B1’s classifier is fitted once per gateway on the same local split, B2’s rules from the benign training statistics, and B0 has no detector. Every detector is frozen during the simulated hour (no online fine-tuning) so the calibrated thresholds remain valid. On the validation split the global model detects 0.84 (DDoS), 1.00 (DoS), 0.78 (Recon), 0.70 (Spoofing), 0.51 (Web) and 0.12 (Mirai) of attack flows at $p\ge 0.5$ with a benign false-alarm rate of 0.04 (seed 0; other seeds within $\pm 0.03$), whereas the locally trained model of the gateway holding a family out detects 0.19 (DDoS), 0.11 (Recon) and 0.42 (Spoofing) of it.

4.5. Window Score and Operating-Point Calibration

 Window score. Eq. 1 is evaluated on a window, not a single flow. Averaging per-flow probabilities dilutes a sparse attack: with 2–3 benign flows per window, a burst of a few malicious flows barely moves the mean. We therefore pool the $k=3$ highest per-flow probabilities of the window (zero-padded), so a single benign false alarm is worth at most $1/k$ of a full alert while a few confident alerts accumulate; the sensitivity analysis varies k.

 Calibration. The configurations of Table 5 map the same network evidence to different trust values (B3: $T_d=S_d^{\mathrm{net}}$; EASA: $T_d=0.6S_d^{\mathrm{net}}+0.4(·)$), so a fixed threshold would place them at different operating points and confound the comparison. We instead fix the operating point: before each run, the trained system executes a benign-only pass (1,800 s, no campaigns) on a calibration segment of the traces, and the thresholds are set from the resulting distribution of benign trust values. For each device, the test records are sorted by availability time and the first third of the ordered records is reserved for calibration and the remainder for evaluation, so the two segments share no record and the calibration segment becomes available entirely before the evaluation segment (a record that starts before the boundary and becomes available after it belongs to the evaluation segment); the calibration segment is thus an earlier, disjoint observation period on the deployment’s own devices, not an independent capture. Appendix F reports an implementation audit of these invariants (duration cap, availability ordering, segment boundary, wrap) on the working data. ${\tau }_{L1}$ is the 10th percentile; ${\tau }_{L2}$ is found by bisection (at most six passes, tolerance $\pm 25\%$ of the target) such that the realised fraction of benign device-epochs at level $\ge L_2$, hysteresis included, equals 2%; ${\tau }_{L3}=\max \{0,\min (q_{0.005},{\tau }_{L2}-({\tau }_{L1}-{\tau }_{L2}))\}$, i.e. one further spread below ${\tau }_{L2}$ unless the 0.5th percentile is lower; and the hysteresis width is $\delta ={\tau }_{L1}-{\tau }_{L2}$. All configurations are thus compared at the same target false-positive rate on the calibration segment; the realised rate on the evaluated segment is higher (4.7–5.4% for every calibrated configuration, Section 5.1) because the later traffic is not stationary with respect to the calibration segment and transient false alarms incur hysteresis dwell. We report it, its paired differences and the sensitivity of every conclusion to the target (Appendix C) rather than treat the operating points as identical. Calibrated thresholds are logged per run and reported in Table 17 (Section 5.9); Appendix B details the procedure.

4.6. Cloud Deployment

The cloud security service of Section 3.6 is a FastAPI application (eight endpoints: health, model push and pull, revocation publish and pull, audit, statistics, reset) deployed on Google Cloud Run in the Seoul region (asia-northeast3; 1 vCPU, 512 MiB; minimum and maximum instance count 1). Aggregation state, registry and audit log live in that instance’s process memory. A minimum-instance setting keeps an instance warm but does not prevent the platform from restarting it, so this is an experimental deployment, not a durable one: a production registry needs external persistent storage, which we did not implement. Requests are authenticated with a per-service API key over HTTPS (the design’s mutual TLS between gateway and cloud was not deployed); every call’s wall-clock round-trip time is recorded. Configurations using only part of the cloud (B2: revocation registry; B3: model path) call the same service with the other endpoints disabled; EASA−C makes no calls.

 Clocks. Three clocks are kept apart. Simulated time is the discrete clock of the replay (10 s epochs, 3,600 s per run) in which all policy intervals are expressed; it advances only when every gateway has completed its epoch, and a cloud call made during an epoch is synchronous—the simulator waits for the response before the clock advances—so the information available to a decision does not depend on how long the call took. Wall-clock time is what the round-trip measurements use; the simulated hour of an EASA run takes about a minute of wall time (Section 5.8), so the round-trip figures measure the deployed path rather than shape the decisions. Intended deployment time is the design default of Table 4 (model synchronisation hourly, revocation poll every 5 min); the evaluation shortens these to 300 s and 30 s of simulated time so that twelve model cycles and 120 polls fall inside the one-hour run, keeping the intervals an order of magnitude apart (10:1 instead of 12:1) and both long compared with the decision epoch. A revocation’s propagation delay is therefore “one poll interval” in either clock.

Before the experiments, 200 probe requests per endpoint measured a baseline round-trip of 130 ms median and 159 ms 95th percentile from the client uplink, a residential connection in Korea whose route to the Google front end leaves the country (a plain HTTPS connect to a public search engine measured the same 130 ms), so this is pessimistic for a Seoul-to-Seoul deployment; the in-experiment round trips of Section 5.8 were lower (102–103 ms median for B2, EASA−PH and EASA; 122 ms for B3, whose few calls are the larger model transfers). A full EASA run issues 596 calls on average: 90 during the federated warm-up (15 rounds × 3 gateways × push and pull), and during the simulated hour 36 model pulls, 36 statistics uploads, 360 revocation polls, one audit event per level transition and one revocation publish per $L_3$ entry. B3 (model path only) pulls the model but, with a frozen detector, uploads nothing; B2 polls the registry only. An in-process mock with the same aggregation arithmetic serves the sensitivity sweep; every cloud-dependent configuration of the main, outage and low-battery experiments was run against both, and the per-seed results are identical (Section 5.8).

4.7. Baselines, Metrics and Statistics

The seven configurations of Table 5 share the simulator, the traces, each seed’s campaign schedule and the calibration procedure. The four with a cloud path (B2, B3, EASA−PH, EASA) ran against the deployed service; B0, B1 and EASA−C issue no cloud calls. All metrics are computed per run and aggregated over 30 seeds.

Metrics are defined on four units. A flow is one CICFlowMeter record; a device-epoch is one device at one 10 s decision epoch (65 devices × 360 epochs per run), labelled attacking while the device is under a campaign; an episode is a maximal run of consecutive attacking epochs of one device (one per device per campaign unless campaigns overlap, in which case they merge); a device is one replayed trace. Unless stated otherwise, denominators are device-epochs.

• Detection at the $L_2$ boundary. Per device-epoch, positive when the device is attacking and predicted positive when its level is $\ge L_2$. Precision, recall and F1 follow. False-positive rate (FPR) uses as negatives only the epochs of devices never compromised in the run (“clean devices”), so that the post-attack dwell of an actually compromised device is not counted as a false alarm. Because that choice hides part of the benign-side cost, we also report the restricted share of all benign epochs (every non-attacking device-epoch at level $\ge L_2$, including pre- and post-attack epochs of devices compromised at some point) and the post-attack dwell in seconds per compromised device.
• In-distribution vs. cross-site recall. Recall restricted to epochs of campaigns whose family the local detector was trained on, and to epochs of the forced campaigns whose family it never saw (RQ1 vs. RQ3). Per-family recall is also reported.
• False-quarantine rate. Share of clean devices that reach $L_3$ at any time (per device).
• Containment (restriction activation) and time to it. Per episode, the containment rate is the share of episodes during which the device reached level $\ge L_2$ at least once, and the time-to-containment (TTC) is the delay from onset to that first decision, defined for contained episodes only. “Containment” is kept for brevity, but it measures that a restricting action was activated during the episode, not the share of attack traffic suppressed, which the flow-level replay cannot measure in bytes; an episode starting while the device is already restricted counts as contained with TTC 0, and TTC statistics are conditional on containment and describe the detected subset only. Because $L_3$ is absorbing, we also decompose the rate into episodes that began on an already restricted device and episodes in which the restriction was newly activated, and report TTC for the latter separately.
• Credential replay. Share of replay device-epochs at $L_3$, over all runs (unconditional) and over the runs in which at least one replay campaign’s donor credential had been revoked anywhere by the end of the run (conditional); both denominators are reported because the conditional subset depends on the detector.
• Overhead. Re-authentications per device-hour (executed step-ups divided by device-hours), deferred step-ups per run split by outcome (executed, cancelled, still pending at the end of the run), and mean residual energy over all devices (mains-powered devices at 1.0) at the end of the run.
• Latency. Round-trip time of real cloud calls (per-run median, 95th percentile and maximum, averaged over runs, plus the pooled maximum).

Each seed fixes the campaign schedule, replay phases and posture draws for every configuration, so all comparisons are paired. Differences between EASA and each other configuration are tested with the two-sided paired Wilcoxon signed-rank test over the 30 seeds, Holm-corrected over the six comparisons of each metric; we report means with standard deviations, the mean paired difference with a 95% bootstrap confidence interval (2,000 resamples of seeds) and the number of seeds in which EASA is better (Appendix D). The 30 seeds vary the schedule, phases, posture draws, detector initialisation and batch order (one detector is trained per configuration and seed) but share one set of traces and one data split; the intervals therefore quantify Monte-Carlo uncertainty on this testbed, not generalisation to other networks.

 Use of generative AI. In line with the publisher’s policy, we note that a generative AI assistant (Claude, Anthropic) was used during this study and contributed, under the authors’ specification and supervision, to writing the experiment code (simulator, cloud service, run, audit and analysis scripts), to generating the figures and tables from the result files, to the statistical analysis of the outputs, and to drafting the manuscript text, which the authors revised (details in the Acknowledgments). The research questions, the architecture, the evaluation protocol, the execution of the experiments and the interpretation of the results are the authors’ own; the authors verified the code, the figures and tables and every reported number, and the code is released so that all results can be regenerated independently.

 Sensitivity analysis. In Appendix C we vary $w_{\mathrm{net}}\in \{0.4,\dots ,0.8\}$ (with $w_{\mathrm{pos}}:w_{\mathrm{hist}}$ held at $5:3$ of the remainder), $\beta \in \{0.5,0.7,0.9\}$, $h\in \{3,5,10\}$, $k\in \{1,3,5\}$ and the target FPR $\in \{1,2,5\}\%$, ten seeds each with the in-process cloud mock, to show where the ranking of configurations holds and where it does not.

5. Experimental Results

We report the seven configurations of Table 5 over 30 seeds under the replay protocol of Section 4: flow records become visible at their end, thresholds are calibrated on a segment of each device’s test records preceding the evaluated one, and cloud-path configurations ran against the deployed service. Each seed fixes campaign schedule, replay phases and posture draws, so all comparisons are paired. “Significant” means $p<0.05$ in a paired Wilcoxon signed-rank test against EASA, Holm-corrected over the six comparisons per metric (Section 4.7); Appendix D tabulates the paired differences, CIs and seed-wise counts, quoted here where effect size matters.

5.1. Overall Comparison (RQ1, RQ2)

Table 8 and Figure 2 give the headline metrics: the configurations with a cloud path and a revocation registry (EASA, EASA−PH) restrict the most attack episodes and catch most credential replays, and between the two the composite trust score did not demonstrate an improvement on any detection metric while adding a measurable benign-side cost. Three observations frame the section.

First, every calibrated configuration shares the 2% target and all realised rates are looser: FPR on never-compromised devices is 4.7–5.4% against the 2% target for every trust-score configuration (EASA 5.4%, B3 and EASA−PH 5.0%, B1 5.3%); none of the five paired differences to EASA is significant (all Holm-adjusted $p=1.0$, mean differences $\le 0.7$ points; B0 never escalates, FPR 0 by construction). This is not equality: no equivalence margin was pre-specified and the paired CIs (Appendix D) admit differences up to about 1.6 points, so configurations are compared at a common target, not a verified common operating point. The excess is a property of the protocol, not of a configuration: thresholds set on the first third of each device’s test-split records are applied to the later two thirds, whose benign traffic is not stationary relative to the calibration segment, and transient false alarms incur hysteresis dwell. Appendix C moves the target from 1% to 5% to check that the ordering is unaffected; Table 9 gives the benign-side cost in full.

Second, the composite score did not demonstrate a detection improvement over the network-only score with the same cloud path. EASA and EASA−PH differ only in the posture and history terms of Eq. 4, and no difference between them was detected on any detection metric: F1 0.601 vs. 0.615 (paired difference $-0.014$, 95% CI $[-0.053,0.022]$, $p=0.78$), containment 0.849 in both ($\Delta =0.000$, $[-0.054,0.048]$, $p=0.67$), cross-site recall 0.599 vs. 0.630 ($-0.031$, $[-0.110,0.056]$, $p=0.98$), in-distribution recall 0.756 vs. 0.772 ($p=1.0$), unconditional replay catch 0.806 vs. 0.757 ($+0.049$, $[-0.070,0.172]$, $p=0.36$). The two terms change the benign side (Table 9): EASA restricts 17.5% of all benign device-epochs against 14.1% ($+3.4$ points, $[2.3,4.5]$, $p<0.001$, worse in 25 of 30 seeds), holds a compromised device restricted 1236 s after its campaign against 962 s ($+274$ s, $[193,359]$, $p<0.001$) and fully isolates 4.2% of clean devices against 2.6% ($+1.6$ points, $[0.6,2.7]$, $p=0.018$); re-authentication load does not differ (0.228 vs. 0.246 per device-hour, $p=0.13$). RQ1 is thus answered negatively: at a common target with the cloud functions held constant, fusing reported posture and decision history with the network score did not demonstrate an increase in restricted attack episodes or cross-site recall (the cross-site CI spans $-0.11$ to $+0.06$: neither improvement nor equality is established) and raised the benign-side cost. Section 5.9 offers a plausible mechanism, Section 6 the consequences.

Third, the differences lie in the cloud path and the registry. Removing the cloud (EASA−C) costs $0.162$ in F1 ($[0.122,0.206]$), $0.293$ in containment ($[0.220,0.368]$) and $0.362$ in cross-site recall ($[0.276,0.449]$; all $p<0.001$, EASA better in 26–29 of 30 seeds) and cuts replay catch from 0.806 to 0.122. Against B3 (model path, no registry), EASA restricts $+0.085$ more episodes ($[0.037,0.134]$, $p=0.010$, 22/30) and catches $+0.668$ more replay epochs ($p<0.001$); F1 ($+0.037$, $[-0.001,0.073]$, $p=0.09$), in-distribution and cross-site recall ($p\ge 0.98$) do not differ. EASA−PH separates the two effects: it calibrates to the same ${\tau }_{L1}$ and ${\tau }_{L2}$ as B3 in every seed (Table 17) and its local detection coincides with B3’s (in-distribution recall 0.772 in both, cross-site 0.630 vs. 0.627, FPR 0.050 in both), so its gain over B3 is attributable to the registry: $+0.086$ containment, $+0.051$ F1, $+0.618$ replay catch (separate comparison, Holm-corrected over these three metrics, all $p<0.001$, EASA−PH better in 26 of 30 seeds, tied in the other four), entirely through replay campaigns (Section 5.4). The energy-aware branch is never exercised in the main experiment (Section 5.6).

B1 is a strong detector but a coarse controller: its gradient-boosted alarm source has the best in-distribution recall (0.821 vs. 0.756 for EASA, $-0.065$, $[-0.119,-0.007]$, $p=0.088$ after correction) but jumps from $L_0$ straight to $L_3$, so 7.7% of never-compromised devices are fully isolated during the hour against 4.2% for EASA (about 45% lower, $p<0.001$), its F1 (0.497) is $0.103$ below EASA’s ($[0.056,0.155]$, $p<0.001$, 27/30) through that imprecision, and without a model or revocation path its cross-site recall (0.346, $-0.253$, $p<0.001$) and replay catch (0.182, $p<0.001$) are far below EASA’s. B2 and B0 have lower F1, in-distribution recall, cross-site recall and containment than every learned configuration: B0 never escalates (its zero containment and zero benign-side cost are reference points, not results), and B2’s z-score rules on CICFlowMeter features reach only 0.144 in-distribution recall at the calibrated operating point while isolating as many clean devices as B1 (7.7%).

Table 9 widens the view beyond clean-device FPR: over all benign device-epochs, including pre- and post-attack epochs of devices compromised at some point, EASA restricts 17.5%, B1 14.5% ($+3.0$ points, $p=0.003$), B3 14.0% and EASA−PH 14.1% (both $p<0.001$). The difference to EASA−PH is post-attack dwell (1236 vs. 962 s), from two mechanisms to be read differently. A device that reached $L_3$ during its campaign is revoked and quarantined for the rest of the run in every configuration ($L_3$ is absorbing, Section 3.4); its $L_3$ dwell was not compared between the two configurations trace by trace. The other is the history term: a device held at $L_2$ returns to $L_0$ only once its decision history has recovered, and Section 5.7 audits devices that never do; that the history term contributes to the extra dwell is consistent with the audit and the history-reset result, not a decomposition of the 274 s. Whether 1236 s of restriction per compromised device is acceptable is an operator’s decision; the data say that the composite score, in this form, pays a benign-side cost without a demonstrated detection benefit.

Figure  plots, for three devices of seed 0, $T_d$ with its network, posture and history components, the enforced level (shaded, scaled to $[0,1]$) and each campaign window (light red): the compromised device (top) is quarantined at $L_3$ by design from its first campaign; the benign device (bottom), escalated to $L_2$ by a transient burst of suspicious flows, had its history term decay while restricted, so $T_d$ never regains the exit threshold although its network score does and the hysteresis rule of Section 3.4 cannot release it.

Time-to-containment does not separate the cloud-path configurations (Table 8: medians 33–38 s for B3, EASA−PH and EASA). Holm-corrected Wilcoxon tests on per-seed medians (released significance.txt) find no difference between EASA and B1, B2, B3 or EASA−PH (all $p\ge 0.41$) and one, in EASA’s favour, against EASA−C, which restricts 20 s later (58 vs. 38 s, $p=0.007$) because its locally trained detector is less confident on unseen families. The first half of RQ2 is thus answered negatively: the four-level loop does not reach a restricting level sooner than per-alarm blocking (42 s for B1). With a 10 s epoch and a 120 s flow window, the first $L_2$ decision is dominated by how long the first attack burst takes to enter the window, a property of the traces, not the policy; the $p95$ values, 162–239 s, reflect campaigns with sparse attacker traces at onset. Table 10 splits containment by whether the device was already restricted at episode start: for EASA 12.9% of episodes start on a device still restricted from an earlier campaign (10.7% EASA−PH, 10.8% B3), the newly activated share is 0.720, 0.742 and 0.655, and TTC medians on newly activated episodes only (52, 42 and 47 s) lead to the same conclusion. TTC is conditional on containment, so a configuration containing fewer episodes is summarised on an easier subset. What the policy changes is whether an episode is contained at all, how many clean devices are isolated to achieve it (the second half of RQ2, answered in EASA’s favour against B1 above) and how long a contained device stays restricted (Table 9).

5.2. Detection Per Attack Family

Table 11 and Figure 3 break recall down by family. DoS floods are detected almost completely by every learned configuration (0.87–0.93); DDoS (0.77–0.80) and Recon (0.67–0.73) are detected well with a cloud model path and markedly less by EASA−C (0.37 and 0.29), where one gateway lacks each in training, and B1 (0.43 and 0.49), whose local classifier never sees them at the held-out gateway. Web is in-distribution everywhere and limited by its small sample (0.70–0.82 for B1 and the cloud-path configurations; 0.62 for EASA−C). Spoofing (0.31–0.43, learned configurations) is weak everywhere, including B1’s stronger detector, and the loss is at the window stage: the detector is adequate (0.70 of DNS-spoofing flows at $p\ge 0.5$ on the validation split) but DNS-spoofing traces are sparse (0.37 flows/s), so a 120 s window often holds fewer than three confident flows and the pooled evidence cannot pull $T_d$ below ${\tau }_{L2}$; $k=1$ in the sensitivity analysis trades this against false alarms on other families. Mirai (0.69–0.72 with a cloud path or B1’s classifier; 0.49 for EASA−C) is detected although the aggregated model flags only 0.12 of Mirai flows at $p\ge 0.5$ on the validation split (Section 4.4): the replayed traces are dense enough that top-k pooling over a 120 s window accumulates the few confident flows the detector does raise, which the per-flow figure does not reflect. The dominant-source rule labels the attacking Pi’s entire traffic as attack, so the Mirai and Web figures carry label noise in both directions (Section 6.3; Appendix E quantifies the rule’s sensitivity). Firmware tampering is caught by every configuration with an integrity check (1.00), which, as noted in Section 3.1, measures the policy’s response to an attestation flag, not attestation itself; credential replay is caught only by the working-registry configurations (EASA 0.82 and EASA−PH 0.76 of replay epochs at $\ge L_2$ in Table 11; 0.81 and 0.76 at $L_3$, the quarantine the registry mandates, Section 5.4).

5.3. Cross-Site Generalisation (RQ3a)

Figure 4 contrasts, per configuration, recall on campaigns whose family the local detector was trained on with recall on forced cross-site campaigns whose family it never saw. Without a cloud model path the gap is large: EASA−C falls from 0.675 to 0.237, B1 from 0.821 to 0.346. With federated averaging the held-out family is detected at 0.599–0.630 (EASA, B3, EASA−PH), closing most of the gap to in-distribution performance (0.756–0.772). The detector-level effect is the same: on the validation split the aggregated model detects 0.84 of DDoS flows at the gateway that never trained on DDoS, against 0.19 for that gateway’s local model (0.78 vs. 0.11 for Recon; 0.70 vs. 0.42 for Spoofing; Section 4.4). Two qualifications bound this result. It is transfer within a federation whose other members have seen the family, not zero-day detection: a family unknown to every gateway is not evaluated, and a locally trained detector is not blind to unfamiliar families (EASA−C still reaches 0.237). And the three configurations sharing the aggregated model do not differ ($p\ge 0.98$), so the cross-site result is a property of the shared model and the window rule, not of the composite score.

5.4. Credential Replay and Revocation (RQ3b)

A credential-replay campaign generates no traffic anomaly; it is caught only by having learned, from another gateway, that the credential was revoked. Table 12 gives every denominator: the runs in which at least one replay campaign’s donor credential had been revoked (at $L_3$) anywhere by the end of the run, the share of replay campaigns (1.4 per run on average) whose donor was revoked, and the catch rate (share of replay device-epochs at $L_3$) over all runs and over runs with a revocation only; the conditional subsets differ between configurations because revocation depends on the detector. Over all 30 runs, the two working-registry configurations raised replaying devices to $L_3$ in 80.6% (EASA, 95% CI $[70\%,90\%]$) and 75.7% (EASA−PH) of replay device-epochs, against 12–18% for every configuration without one (paired differences to EASA $+0.62$ to $+0.68$, all $p<0.001$); the residual catches are coincidental local escalations, e.g. a replaying device also under a traffic campaign, and B2’s registry counts among them because its weak detector almost never revokes, so the revocation path cannot matter. EASA vs. EASA−PH ($+0.049$, $p=0.36$) is not significant. The unconditional rate is bounded by whether a revocation exists at all: under EASA the donor campaign reached $L_3$ somewhere in 28 of the 30 runs (89% of replay campaigns), where the catch rate is 85.2% ($\pm 23$ points); under EASA−PH a revocation exists in 26 runs, with 82.5% caught, so the conditional catch rate was high under both scores (on subsets differing by two runs). The other configurations’ conditional figures use their own subsets (26 runs for B3, 5 for B2) and are shown for completeness, not compared. The gap between unconditional and conditional rate is a property of the detector, not of the registry, and closes as detector recall on the donor family rises.

Propagation delay is set by the 30 s revocation poll: a credential revoked at gateway $g_i$ is rejected at $g_j$ at the next poll, within one poll interval of simulated time (Section 4.6).

5.5. Cloud Outage (RQ3c)

The outage experiment repeats the 30 EASA runs against the deployed service with every cloud call skipped between $t=1800$ s and $t=2700$ s of simulated time; gateways keep deciding with their last synced model and revocation list (Figure 5). No change was detected in the evaluated local metrics: in-distribution recall (0.756 in both conditions), cross-site recall (0.599 vs. 0.598, $p=0.32$), FPR (0.054 in both) and false-quarantine rate (0.042 in both). This is expected by construction, the aggregated model being obtained during warm-up and frozen for the hour, so it establishes only that a gateway keeps scoring and enforcing with a cached model, not that model staleness is harmless over longer horizons or that an outage before warm-up would be benign. What degrades is the revocation path: unconditional replay catch drops from 0.806 to 0.622 (conditional 0.852 to 0.654; $p=0.005$), containment from 0.849 to 0.825 ($p=0.005$) and F1 from 0.601 to 0.588 ($p=0.005$; all unadjusted, one pre-specified comparison per metric): replays starting during the 15-minute window are missed until the first poll after recovery. Cloud calls per run fall from 596 to 454; no call failed outside the skipped window. The narrow conclusion is the one we draw: within this protocol, an outage removes the cross-gateway revocation signal for its duration, with no change detected in the evaluated local metrics.

5.6. Enforcement Overhead and Energy (RQ4)

The four-level configurations re-authenticate 0.20–0.25 times per device-hour in the main experiment (Table 8); the binary configurations never do, having no $L_2$, and pay instead with the false-quarantine rates above. Residual energy after the hour is 0.79–0.82 of capacity for every configuration, and the energy-aware deferral of $L_2$ step-ups (Algorithm 1) was never exercised: from $e_d\sim U(0.6,1.0)$, no device reached the 20% floor within one simulated hour.

The low-battery experiment therefore repeats B3, EASA and, to isolate the selector, “EASA, no energy-aware action” (EASA with the deferral branch disabled, otherwise identical; released as EASA_no_energy; “EASA without the selector” below), with battery devices starting at $e_d\sim U(0.10,0.35)$ so that most are below the floor when first escalated (Table 13). B3’s decisions are independent of battery state by construction, so its figures coincide with the main experiment. Between EASA and EASA without the selector no difference was detected in any detection or restriction metric (containment 0.833 in both, false quarantine 0.040 in both, replay catch 0.816 in both, F1 0.602 vs. 0.605, $p=0.65$, FPR 0.051 vs. 0.050, post-attack dwell 1158 vs. 1162 s, $p=0.32$; the small differences arise because a deferred handshake shifts a few later transitions, and equivalence was not established), while handshakes differ: 0.136 against 0.217 per device-hour, a 37% reduction (mean per-seed ratio 0.63; two-sided paired Wilcoxon $p<{10}^{-5}$, EASA lower in all 30 seeds; p values in this section are unadjusted, one pre-specified comparison per metric). The deferrals account for it exactly: 5.27 deferred step-ups per run over 65 device-hours are 0.081 re-authentications per device-hour, the observed difference. The remaining gap to B3 (0.217 vs. 0.247, a 12% reduction, $p=0.011$, EASA without the selector lower in 17 of 30 seeds) is what the different score and the registry contribute, and is small. The supported claim is therefore component-level: in the simulated low-battery scenario, enabling the energy-aware action selector alone reduced re-authentication handshakes by 37%; no change in the evaluated detection or restriction metrics was detected. It is not a measurement of energy saved or credential freshness preserved: residual energy does not differ (0.365 with and without the selector; the mean includes mains-powered devices at 1.0), because an mTLS handshake (8 mWh) is small against the modelled idle drain (50 mWh per hour for a sensor node, 1.2 Wh for a camera) within one hour, and the handshake cost is a parameter, not a hardware measurement.

A deferred step-up has three outcomes (Table 3): executed, if the device’s energy recovers above the floor while it is still at $L_2$ or stricter; cancelled, if it relaxes to $L_1$ first; or pending at the end of the run. No battery recharges in this scenario, so none was executed; of the 5.27 deferrals per run, 0.47 were cancelled and 4.80 were pending at the end of the hour. The price is thus that, on average, 4.8 devices per run end the hour at a restricting level whose standing enforcement (rate limit, re-validation) is in force but whose entry handshake was never performed: the level is enforced, the credential not refreshed. The policy has no transition from a completed handshake back to a lower level, so a restricted device is released only by the hysteresis rule, with or without the handshake, which is why the deferral leaves the restriction metrics essentially unchanged.

5.7. Recovery from $L_2$: Trajectory Audit and a Design Revision

Section 3.4 showed that a device held at $L_2$ recovers only if its network and posture evidence suffice without the history term, with no finite recovery guarantee. We audited the saved seed-0 trajectories of the configurations run against the deployed service (Table 14; audit script released): for the 40 never-compromised devices, the maximal runs at $\ge L_2$ (episodes), those that returned to $L_1$ or below (recovered) and the devices still at $L_2$ or $L_3$ at the end (stuck); for the 25 compromised devices, the restricted time per device after its last campaign at $L_2$ and at $L_3$. Under EASA, three of the 40 never-compromised devices entered $L_2$ or stricter; none recovered, two ended at $L_2$ and one at $L_3$ (an integrity-independent trust-driven quarantine), with median restricted dwell 3350 s of the 3600 s. Under the network-only score (B3, EASA−PH) four benign devices entered a restricting level, two recovered after a median 990 s, and one each remained at $L_2$ and $L_3$. The two EASA devices stuck at $L_2$ had a clean network score ($S^{\mathrm{net}}\approx 0.76$) and a history term decayed to zero, giving $T_d\approx 0.70$ against ${\tau }_{L1}=0.74$: exactly the lock-in predicted analytically. Compromised devices show the same pattern at $L_2$ (216 s of post-attack $L_2$ time per device under EASA against 57 s under B3; the $L_3$ time, 915 vs. 849 s, is the absorbing quarantine common to both).

The one-line revision that removes the dependence, resetting $S^{\mathrm{hist}}$ to 1 once a restricted device has produced $h=5$ consecutive epochs with $S^{\mathrm{net}}\ge {\tau }_{L1}$, was run on the same 30 seeds against the same service and is a supplementary result outside the pre-specified comparison (Table 15). It fires 98 times per run, lowers the restricted share of benign epochs from 17.5% to 16.6% ($-0.9$ points, 95% CI $[-1.4,-0.4]$, unadjusted $p<0.001$) and post-attack dwell from 1236 to 1162 s ($-73$ s, $[-121,-36]$, $p<0.001$), with no detected change in any detection metric (F1, containment, cross-site recall, replay catch: all $p\ge 0.24$); in the seed-0 audit one of the three stuck devices recovers after 2290 s. It removes part, not all, of the lock-in: the remaining dwell is the hysteresis and the EWMA on a device whose network score sits near ${\tau }_{L1}$, and the restricted share stays 2.5 points above the network-only score. We report it as evidence that the audit identified the right mechanism, not as a tuned configuration.

5.8. Measured Cloud Latency and Its Implications for Deployment (RQ5)

All cloud-dependent runs (the four cloud-path configurations of the main experiment, the outage, low-battery and supplementary history-reset runs; 270 runs, 122,274 calls) were executed against the Cloud Run service in Seoul (Table 16). A full EASA run issues 596 calls (90 during federated warm-up, the rest during the simulated hour; Section 4.6); B3, which pulls the model and uploads nothing, 127; B2, which only polls the registry, 369. Over the main-experiment runs the per-run median round-trip time averaged 102–103 ms for B2, EASA−PH and EASA (122 ms for B3, whose few calls are dominated by the larger model transfers) and the 95th percentile 106–124 ms (159 ms for B3); the calls include warm-up, and the “Retried” and “Dropped” columns count calls that needed a retry or were given up after three retries. Excluding stalls, the pooled worst single call was 585 ms. In 15 of the 270 runs a call stalled for 4.9–10.4 s, was served within the 15 s timeout and triggered no retry; these 15 stalls, which the “RTT max” column of Table 16 averages over, are the only cloud anomalies observed in the whole study. No call failed and none needed a retry in any of the 270 runs; the 15 s timeout and retry logic were introduced after a single call in a preliminary run exceeded an initial 5 s timeout. The decisions do not depend on the transport: every cloud-dependent configuration was also run against the in-process mock of the service with identical per-seed results for every metric (the aggregation arithmetic is the same code), so the deployed service adds the latency measurement and nothing else.

Two readings are available and only one is claimed. In the simulator, cloud calls are synchronous and happen at synchronisation points, not inside a device’s decision, and the simulated clock does not advance while a call is in flight (Section 4.6), so the round trips measure the deployed path, not a quantity the decisions depended on. They support a sizing argument: a 100 ms round trip is 1% of the 10 s decision epoch and 0.3% of the 30 s poll interval, so a deployment issuing these calls asynchronously, as the design intends, would see RTT only as propagation delay of cross-gateway state; a 10 s stall would delay the refresh of the revocation list or model by up to that time, and a deployment needing a bound on that delay would have to enforce it explicitly, which this prototype does not. The per-epoch decision cost is small: a complete EASA−C run (360 epochs, 65 devices, no cloud calls) takes about 0.8 s of wall time on the experiment machine (an RTX 5080 GPU for the MLP), about 2 ms per epoch for all devices of all gateways, and the 59 s of an EASA run are almost entirely its 596 synchronous calls. These costs are for the replayed flow rates; a flood at packet-level rates would raise the per-window classifier cost and was not measured. The client uplink routes outside Korea (Section 4.6); a direct domestic path would be shorter still.

5.9. Calibrated Operating Points

Table 17 lists the calibrated thresholds. They differ by construction: the network-only score of B3 and EASA−PH is noisier on benign traffic and needs ${\tau }_{L2}=0.46$ to hold 2% on the calibration segment, whereas EASA’s composite score, smoothed by posture and history, holds the same rate at ${\tau }_{L2}=0.63$ with a narrower spread across seeds ($\pm 0.029$ against $\pm 0.051$, one standard deviation). The smoothing offers a plausible account of why the composite score showed no detection gain: calibration raises the threshold by about the amount the posture and history terms add on benign traffic, so at the common target the network term remains what moves a device across the threshold, while the slowly decaying history term governs its release. We offer this as an interpretation consistent with the thresholds, the trajectory audit and the history-reset result, not as a demonstrated mechanism. Whether the small spread of ${\tau }_{L2}$ would allow a fixed threshold per device class after a short observation period is a hypothesis for a deployment study, taken up in the discussion. ${\tau }_{L3}$ reached its floor of zero in two B2 runs and in no other run.

Table 17. Calibrated entry thresholds (mean ± std over seeds).

Configuration	${\mathit{\tau }}_{\mathit{L}1}$	${\mathit{\tau }}_{\mathit{L}2}$	${\mathit{\tau }}_{\mathit{L}3}$
B0 static	0.800 ± 0.000	0.600 ± 0.000	0.350 ± 0.000
B1 VNSF	0.789 ± 0.028	0.519 ± 0.038	0.224 ± 0.055
B2 rules	0.505 ± 0.114	0.362 ± 0.009	0.172 ± 0.082
B3 net-only	0.626 ± 0.035	0.461 ± 0.051	0.251 ± 0.083
EASA−C	0.733 ± 0.015	0.553 ± 0.059	0.286 ± 0.061
EASA−PH	0.626 ± 0.035	0.461 ± 0.051	0.251 ± 0.083
EASA	0.743 ± 0.021	0.625 ± 0.029	0.414 ± 0.069

Table 17. Calibrated entry thresholds (mean ± std over seeds).

Configuration	${\mathit{\tau }}_{\mathit{L}1}$	${\mathit{\tau }}_{\mathit{L}2}$	${\mathit{\tau }}_{\mathit{L}3}$
B0 static	0.800 ± 0.000	0.600 ± 0.000	0.350 ± 0.000
B1 VNSF	0.789 ± 0.028	0.519 ± 0.038	0.224 ± 0.055
B2 rules	0.505 ± 0.114	0.362 ± 0.009	0.172 ± 0.082
B3 net-only	0.626 ± 0.035	0.461 ± 0.051	0.251 ± 0.083
EASA−C	0.733 ± 0.015	0.553 ± 0.059	0.286 ± 0.061
EASA−PH	0.626 ± 0.035	0.461 ± 0.051	0.251 ± 0.083
EASA	0.743 ± 0.021	0.625 ± 0.029	0.414 ± 0.069

5.10. Sensitivity

Appendix C varies one parameter at a time around the defaults with ten seeds per point (17 points, B3 and EASA, in-process cloud mock, decision-equivalent to the deployed service by Section 5.8; Table A2, Figure A1). Comparing EASA with B3, it bundles the registry with the composite score and cannot test the composite score in isolation; its narrower purpose is to check whether the EASA–B3 ordering in containment and benign-side cost holds away from the defaults, and whether any setting shows a consistent cross-site advantage the main experiment would have missed. The sweep compares EASA with B3, so each difference bundles the registry with the composite score, and its p values are unadjusted on ten seeds; we read it for direction and stability only. Three things are stable across all 17 points. EASA activates a restriction in more episodes than B3 at every point ($+0.03$ to $+0.12$), which is the registry effect of the main experiment. EASA restricts more benign epochs and holds compromised devices longer at every point (dwell $+125$ to $+417$ s, $p\le 0.05$ at every point); the post-attack dwell difference declines monotonically as weight moves to the network term ($+417$ s at $w_{\mathrm{net}}=0.4$, $+141$ s at 0.8), as the calibrated ${\tau }_{L2}$ falls with it (0.71 to 0.54), whereas the restricted-share difference does not (it rises from 3.6 to 4.2 points between $w_{\mathrm{net}}=0.4$ and 0.5 before falling to 1.0 point at 0.8). And the cross-site comparison has no consistent direction: EASA is below B3 at the defaults and at $\beta \in \{0.5,0.9\}$, $h\in \{3,10\}$, $w_{\mathrm{net}}=0.4$ and a 1% target, within $\pm 0.01$ at $w_{\mathrm{net}}=0.5$, and above it at $w_{\mathrm{net}}\in \{0.7,0.8\}$, $k\in \{1,5\}$ and a 5% target, with one point reaching nominal significance ($w_{\mathrm{net}}=0.7$: $+0.098$, $p=0.037$, 8 of 10 seeds). The sweep therefore neither confirms nor overturns the composite-score result of Section 5.1, which rests on the EASA−PH ablation at the pre-specified defaults; what it shows is that no setting exhibits a consistent EASA advantage in cross-site recall over B3, and that a fusion with more weight on the network term costs less on the benign side. We record the latter as a hypothesis for a pre-registered follow-up rather than tune on the test traces. The hysteresis length h has no measurable effect in 3–10 epochs, a slow EWMA ($\beta =0.9$) costs both configurations about 0.06 in F1 by delaying escalation, $k=1$ lowers the realised FPR of both (0.03–0.04) at the price of containment, and the target FPR behaves as expected: the realised rate tracks it (0.02 at 1%, 0.08–0.10 at 5%) and loosening it to 5% raises recall and containment for both while increasing the re-authentication load by about 20% (EASA) and 40% (B3).

6. Discussion

6.1. What the Results Do and Do Not Show

Table 5 attributes the measured differences to components, unevenly.

 The cloud layer carries the benefit, and nearly all of it for two attack classes. Removing the cloud (EASA−C) costs 0.16 in F1, 0.29 in containment and 0.36 in cross-site recall, and cuts the unconditional replay catch rate from 0.81 to 0.12. A single gateway is weakest against a family another site has seen (local 0.24; 0.60 with shared parameters) and a credential revoked elsewhere (0.12, by coincidence; 0.81 with shared state). The two functions are separable: EASA−PH vs. B3 isolates the registry ($+0.086$ in containment, $+0.62$ in replay catch), and the model path accounts for the cross-site gap between configurations with it (0.60–0.63) and without (0.24–0.35). These cases motivate a cloud layer; with a cached model it can be lost for a quarter of an hour with the revocation path degraded and no change detected in the evaluated local metrics. The cloud should therefore hold slowly varying, cross-site state (model, revocations, and by design policy) and never sit in the per-epoch decision path.

 The composite score, in this form, is a negative result. With the cloud functions held constant and a common calibration target, fusing reported posture and decision history with the network score did not demonstrate an improvement on any detection metric (F1, containment, in-distribution and cross-site recall, replay catch: all Holm-adjusted $p\ge 0.36$, mean differences within $\pm 0.05$; intervals include gains and losses: F1 $[-0.053,0.022]$, containment $[-0.054,0.048]$, cross-site recall $[-0.110,0.056]$) and raised the benign-side cost: 3.4 points more restricted benign epochs, 274 s longer post-attack dwell (both $p<0.001$) and 1.6 points more false quarantines ($p=0.018$) (Table 8 and Table 9). RQ1 is answered negatively. Table 17 suggests why: the smoother composite score puts the same target at ${\tau }_{L2}=0.63$ instead of $0.46$, about the margin the posture and history terms add; the network term still crosses the threshold while the history term, decaying under restriction, governs release, which would explain the later release. The trajectory audit (Section 5.7) agrees: benign devices held at $L_2$ with a clean network score and zero history term, as Section 3.4 predicts. This is an interpretation, not a demonstrated mechanism: the two scores’ decisions were not compared trace by trace. A history reset removes part, not all, of this cost with no detected change in detection, and we did not search for posture and history terms that would add detection value; the data support the graded loop with a calibrated operating point, the registry and model path, and the energy-aware selector—not the fusion of Eq. 4.

 The energy-aware selector does what it is specified to do. In the low-battery scenario the selector alone (disabled with everything else equal) reduced re-authentication handshakes by 37%, equal to the deferred step-ups, with no detected change in the evaluated detection or restriction metrics (equivalence was not established). Deferred devices end the hour restricted without a refreshed credential; the energy saved is not measurable within an hour and was not measured on hardware.

 A better per-flow detector is not a substitute for the architecture. B1’s gradient-boosted per-flow classifier beats our MLP in-distribution (0.82 vs. 0.76 recall) but, blocking on every alarm, isolates 7.7% of clean devices against EASA’s 4.2%, reaches a lower F1 and has no path for cross-site knowledge or revocation. EASA’s gains come from policy structure and the cloud, not detection; whether they add to a stronger detector was not tested, and graded-versus-binary is not isolated because the detectors differ. The detector-agnostic trust engine could run a gradient-boosted model locally and federate a parametric one; this hybrid was not evaluated.

 Time-to-containment is a property of the traces at this resolution. With a 10 s epoch and 120 s window, TTC medians of 33–38 s do not separate the learned configurations with a cloud path, and the graded loop is not faster than per-alarm blocking (RQ2, negative); only the configuration without a cloud differs, restricting 20 s later. The window is set by the data (session-level flows, bursty floods), not the policy; a faster loop needs packet-level or sub-flow gateway features. With flow records visible only at their end, the medians are no longer optimistic by the flow duration. The policy controls whether an episode is contained, how many clean devices are isolated, and how long a device stays restricted.

 What the ablation does not isolate. Some pairs differ in more than one component. EASA vs. EASA−C is a clean cloud ablation, EASA vs. EASA−PH a clean score ablation and, in the low-battery scenario, EASA vs. EASA without the selector a clean selector ablation; EASA−PH vs. B3 isolates the registry because the energy branch is idle in the main experiment. The $2\times 2$ of model sharing against registry was not run (it is released as a configuration); graded against binary enforcement is compared only across detectors (B1 vs. EASA), and B1’s classifier was not combined with EASA’s policy. The headline numbers should be read with these gaps in mind.

6.2. Operating-Point Calibration as a Deployment Procedure

Calibrating on a benign pass makes configurations comparable and is how EASA would be deployed. The calibrated ${\tau }_{L2}$ varies by $\pm 0.029$ (one standard deviation) across seeds on a 30-minute benign pass; whether a shorter window or a fixed per-class threshold would hold was not tested and is a hypothesis for a deployment study. The cloud policy repository would version such thresholds; Appendix C shows how recall and re-authentication load move with the target FPR. Three aspects are not covered. First, a device already compromised during the benign window would raise its own threshold. Second, calibration is global per gateway while benign traffic differs per device; a per-device baseline is a direct extension. Third, the calibration segment precedes the evaluated segment but shares its devices, and the realised false-positive rate on the evaluated segment is 2.4–2.7× the target (4.7–5.4% against 2%) for every calibrated configuration, because the later traffic is not stationary and transient false alarms incur hysteresis dwell; no differences between the realised rates (4.7% to 5.4%) were detected after correction, but equivalence was not established, so the comparison is at a common target rather than a verified common operating point. A deployment needing the target itself would calibrate on a longer window and on the realised rate.

6.3. Threats to Validity

 Labelling and label validity. IoT-DIAD carries no per-flow label. Our dominant-source rule is transparent and reproducible but weak: it marks the attacking Raspberry Pi’s entire capture traffic as attack, so families whose attack flows resemble benign sessions—Mirai, DNS spoofing, parts of the web attacks—carry label noise that can distort any configuration’s recall in either direction (Table 11); four low-volume types could not be labelled and were excluded; and the volume-based label could give a count- or rate-based detector a shortcut. What was measured is the rule’s sensitivity to its own thresholds (Appendix E), not its accuracy: lowering the minimum flow share from 5% to 3% or changing the attacker cap to 6 or 12 relabels at most 1.9% of the retained rows on the raw captures (flow-weighted; up to 20% within one DDoS type), whereas raising it to 10% relabels 12% in aggregate and up to 62% of one type: stable in one direction, not the other. On the family-balanced working data the same settings move 3% of the retained rows (up to 16% of one type) under the looser settings and 18% under the stricter share, which removes the attack label from 25% of the replayed attacker-trace records (45% for DDoS, 50% for Mirai, 51% for Spoofing); the benign traces that drive calibration and false-positive measurements come from the benign chain and are unaffected. We did not retrain or re-evaluate under an alternative rule, so the main comparisons are conditional on the default rule. None of this says whether the designated addresses are the attackers or whether their traffic with other devices is attack traffic; that needs the packet captures or another independent ground truth, which we do not hold. The detection results are therefore results on synthetic campaigns built from weakly labelled attacker traces; the per-family breakdown lets readers discount the weakest families, and the attacker sets are released for audit.

 Data split. The split is by time within each capture, so train and test share sessions and devices; near-duplicate rows across the boundary were not removed (exact duplicates only within training). Each gateway trains on the pool’s training split minus one family, so the pairwise Jaccard overlaps of the three de-duplicated training sets (0.96, 0.99 and 1.13 million rows) lie between 0.69 and 0.84: the cross-site result is transfer between heavily overlapping clients of one testbed, not independent sites, and measures generalisation to later traffic of the same testbed. A capture- or device-level group split with a time embargo, and clients from disjoint observations, are stricter protocols; we have not run them and make no claim about what they would show.

 Device identity and posture. The testbed LAN uses DHCP, so an address identifies a device only within one capture chain; we take the benign chain as the device universe and attach attack traces per address per campaign; cross-session tracking of a physical device was not possible. The posture model is parametric, the beacon is self-reported and trusted in the simulation, and the integrity flag is an oracle: forged posture, stale or missing beacons and false low-battery reports were not injected, and the attestation mechanism behind ${\iota }_d$ is outside what we built.

 Emulation and replay. Gateways, devices and the trust engine are emulated in one process; only the cloud is real, so gateway decision latency, radio-level effects of rate limiting and the mTLS re-handshake cost on constrained hardware are modelled, not measured. The campaign schedule is synthetic; device traces wrap when exhausted (7 of 65 evaluation traces are shorter than one run, and the attacker traces of two DoS attackers and of all three Web attackers are shorter than the longest campaign, so those campaigns replay the same burst more than once; Appendix F); and “containment” measures that a restricting level was reached, not how many attack bytes were suppressed, which a flow-level replay cannot express. Because $L_3$ is absorbing, an episode on a device quarantined earlier counts as contained without a new detection, so the activation rate reflects the controller’s prior state; Table 10 reports the newly activated share separately (10–13% of episodes begin on an already restricted device for configurations with a cloud model path, 6–10% for the others). The one-hour horizon exercises the energy-aware branch only in the low-battery scenario.

 Policy state. A revoked credential is never reinstated within a run, so $L_3$ is absorbing and the post-attack dwell includes the quarantine of devices that were in fact compromised; re-enrolment is an operator action we did not model. The history term can hold a benign device at $L_2$ if its traffic is persistently suspicious or its reported resources are low (Section 3.4); the policy gives no finite recovery guarantee, and the one-seed audit of Section 5.7 found benign devices locked at $L_2$ for the rest of the run by exactly this mechanism. The history reset was a supplementary revision on all 30 seeds, not part of the pre-specified comparison, and an audit over all seeds was not run. Step-ups still pending at the end of a low-battery run (4.8 per run) leave devices restricted without a refreshed credential; whether that is acceptable depends on what re-validation at $L_2$ protects against, which the simulation does not model.

 Cloud. A single region, one instance with in-memory state and one client uplink were used; the platform may restart a minimum instance at any time, and a durable registry (external storage, versioned, with a consistency rule under partition) is required for production and was not built. Authentication was an API key over HTTPS rather than the mutual TLS of the design. Of the functions in Section 3.6, policy distribution is specified but not implemented, the audit store was exercised only as an event sink, and cross-gateway threat correlation on those events (e.g. linking one attacker signature across sites) was not implemented or evaluated. The outage experiment covers complete unreachability after warm-up only, not an outage before the global model exists, partial partitions, packet loss, stale policy, or catch-up after recovery.

 Aggregation and poisoning. Federated averaging with a common initialisation and synchronous rounds assumes honest gateways, yet a compromised gateway is a realistic adversary here. Nguyen et al. [36] show that compromised IoT devices can poison a federated detector through its training traffic without compromising the gateways; a compromised gateway is a separate, stronger threat: it could submit malicious updates that lower the global model’s sensitivity to a family (a targeted availability attack on cross-site recall) or publish false revocations that quarantine devices at other sites. The first is the classic Byzantine setting [32], for which robust aggregators such as Krum [47] and coordinate-wise median or trimmed mean [48] replace the plain average at some cost in accuracy. Krum requires $2f+2<n$, so its guarantee does not cover one Byzantine participant in our three-gateway federation; median and trimmed-mean methods rely on different statistical assumptions that we have not established for the present non-IID setting. A small federation would instead need per-gateway update validation (e.g. rejecting updates whose validation loss on a held-out benign set rises) or an aggregator whose guarantees hold at $n=3$. The second calls for signed, attributable revocations with a per-gateway quota and an operator path to reverse them. Neither was implemented or evaluated, and our results hold only for honest gateways.

 Statistics and generality. The 30 seeds vary the schedule, phases, posture draws and detector initialisation on one set of traces; the confidence intervals are Monte-Carlo intervals on this testbed, not over deployments, and all results are on one testbed’s traffic. Loaders for CIC-IoT-2023 and TON_IoT are retained in the released code, and reproducing the protocol on the 2025 DataSense release [49], whose captures include an explicit edge and cloud tier, is the natural next validation.

6.4. Practical Implications

Three recommendations follow, with the scope the evidence supports. Keep the decision loop at the gateway and the cloud out of its critical path: measured 100 ms round trips are two orders of magnitude below the 10 s epoch, and an outage after warm-up degraded the revocation path with no detected change in local detection. The observed trade-off favours a graded policy with a calibrated target and a shared revocation registry over per-alarm blocking: at the same target the full configuration restricted more attack episodes than the per-alarm configuration with a stronger detector while isolating about 45% fewer clean devices (4.2% vs. 7.7%), at the price of longer restriction of compromised devices; because the two differ in detector, cloud path and policy at once, this is a whole-configuration observation, not an isolated effect of grading. Drive the escalation from the network score alone, or from a fusion whose added terms are shown to add detection value, because the posture-and-history fusion evaluated here added cost without a demonstrated benefit. And give the action selector the device’s energy state: in the low-battery simulation this alone reduced re-authentication handshakes by 37% with no detected change in detection or restriction metrics, although the energy saved was not measurable within an hour and was not measured on hardware. These assume a posture beacon on top of the authentication and runtime support a device already has; its interoperability with real device firmware was not tested.

7. Conclusions

We presented EASA, an API-based system prototype combining persistent device-level restriction states, resource-conditioned response actions, and cross-site model and revocation services for sensing devices in the AIoT device–edge–cloud continuum, and characterised its detection and restriction-cost trade-offs under a controlled trace-replay protocol: per-address traces from real consumer devices, flow records visible only when an online extractor could emit them, every baseline a configuration of the same implementation calibrated to the same target false-positive rate on a segment disjoint from the evaluated one, and a cloud service that is actually deployed. Four results stand, each with its scope. The cloud layer is not an accessory: a federated detector raised recall on attack families a gateway had never seen, but another site had, from 0.24 to 0.60, and a shared revocation registry caught 81% of credential-replay epochs over all runs (85% when a revocation existed), a family a local detector catches only by coincidence; a 15-minute outage after warm-up, with a cached model, degraded the revocation path, with no change detected in the evaluated local metrics. The full configuration restricted more attack episodes than the per-alarm configuration with a stronger detector while isolating about 45% fewer clean devices (4.2% vs. 7.7%)—a whole-configuration trade-off, since the two differ in detector, cloud path and policy. The energy-aware action selector, isolated with everything else held equal, reduced re-authentication handshakes by 37% in a simulated low-battery scenario with no detected change in the evaluated detection or restriction metrics, by deferring handshakes of devices that then end the hour restricted but not re-validated. The composite trust score, as evaluated here, is a negative result: with the cloud functions held constant it did not demonstrate an improvement on any detection metric and raised restricted benign epochs by 3.4 points, post-attack dwell by 274 s and the false-quarantine rate by 1.6 points; plausibly the calibration absorbs the smoothing the extra terms provide while the decaying history term delays release—a lock-in that a trajectory audit found on individual benign devices and that a history reset reduces but does not remove. The graded loop was not faster than per-alarm blocking—time-to-containment is set by the traces at this resolution—and a stronger per-flow detector detected in-distribution attacks better than ours, so the contribution is the policy structure, the registry and the model path, not detection or the fusion.

For API-mediated AIoT systems, the practical significance is a measurable control loop linking device behaviour to continuing access decisions and cross-site credential revocation: under the evaluated protocol the shared registry improved replay rejection and the resource-aware selector reduced re-authentication handshakes, while the negative composite-score result shows that added context can impose costs on benign devices. Reduced application-level API exploitation, resistance to autonomous attackers and hardware energy savings remain to be established.

The limits are equally clear: the realised false-positive rate is 2.4–2.7× the calibration target for every calibrated configuration, because the evaluated traffic is not stationary with respect to the calibration segment; the label rule is stable under a looser minimum share and a tighter attacker cap but not under a stricter share, and its accuracy was not verified against packet captures or any independent ground truth, so the detection figures are for synthetic campaigns built from weakly labelled attacker traces; the split is by time within captures, not by capture or device, and the gateways’ training sets overlap heavily; “containment” measures that a restricting action was taken, not the attack traffic stopped; the posture beacon is self-reported, its evasion resistance unverified and the integrity flag an oracle; the recovery audit covers one seed; the cloud is a single in-memory instance in one region, authenticated by an API key, with honest gateways assumed; and the ablation leaves the model-sharing/registry interaction and a graded-versus-binary comparison with the same detector to be run. Next steps follow: posture and history evidence formulated to add detection value rather than smoothing, or removed from the escalation path in favour of the action selector alone; a label audit against packet captures; a capture-level split with a time embargo and disjoint clients; packet-level replay measuring suppressed attack bytes and delivered sensing data; forged-posture and poisoned-gateway adversaries with a robust aggregator; a durable registry; and reproduction on a multi-tier dataset such as DataSense [49]. The simulator, labelling rule, cloud service, audit scripts and all configurations are released so that each can be tried against the numbers reported here.