AQ-TESLA: Adaptive Hybrid QKD–TESLA Authentication for Edge-Assisted 6G Internet of Things Networks

Abstract

Future sixth-generation (6G) Internet of Things (IoT) environments require scalable authentication for large populations of constrained devices while remaining resilient to quantum-capable adversaries. Quantum key distribution (QKD) can provide high-assurance key material between suitable infrastructure nodes, but direct QKD termination at every low-power endpoint is impractical and the secret-key supply is finite. This paper presents AQ-TESLA, an edge-assisted hybrid authentication architecture that combines infrastructure-facing QKD, ML-KEM fallback, quantum-derived TESLA epoch seeds, delayed key disclosure, authenticated edge synchronization, CoAP transport, and a runtime security controller. The controller jointly evaluates packet loss, attack evidence, congestion, device trust, message criticality, and QKD key-pool status to continue the current TESLA chain, shorten the disclosure interval, or trigger hybrid rekeying. A reproducible systems simulation generated 180,000 events across routine, dense-urban, industrial, emergency, and adversarial scenarios and compared AQ-TESLA with DTLS-CoAP, PQC-CoAP, classical TESLA-CoAP, and Static QKD-TESLA. AQ-TESLA achieved a mean authentication latency of 12.91 ms, P95 latency of 21.24 ms, attack rejection of 97.30%, and authentication success of 98.93%, while consuming 76.9% less QKD key material than static quantum rekeying in the reference workload. Ablation, threshold-sensitivity, bootstrap, and scalability analyses show that pool awareness and adaptive escalation reduce depletion and unnecessary quantum operations. These findings are systems-model results; they are not a physical QKD experiment, a 6G field trial, or a hardware security certification.

1. Introduction

Research objective clarification: This study investigates whether adaptive hybrid authentication can improve the modeled security–efficiency trade-offs under constrained QKD resources. Results represent simulation-based architectural feasibility rather than deployment validation.

Sixth-generation (6G) networking is expected to support massive device density, edge intelligence, stringent latency objectives, and heterogeneous IoT services. The same characteristics expand the authentication surface and intensify denial-of-service, impersonation, key-management, synchronization, and cross-domain trust risks [1,2,3,4]. A practical security design must therefore balance cryptographic assurance with the computation, memory, communication, and energy limits of constrained endpoints.

Constrained devices cannot absorb every security mechanism used by general-purpose hosts. Recent IoT authentication research consequently emphasizes lightweight exchanges, CoAP-aware protection, continuous session verification, and edge assistance [5,6,7,8]. In parallel, quantum computing threatens RSA, elliptic-curve cryptography, and finite-field Diffie–Hellman, creating a migration requirement toward post-quantum cryptography (PQC) and, where appropriate, quantum communication [9,10,11,12].

QKD and PQC are complementary rather than interchangeable. QKD distributes secret bits over a quantum channel but still depends on an authenticated classical channel and suitable optical infrastructure. PQC provides software-deployable quantum-resistant key establishments and signatures. Experimental hybrid QKD–PQC systems have demonstrated the value of combining independent key sources so that security can be retained when at least one source remains uncompromised [13,14].

TESLA provides asymmetric broadcast-authentication properties using symmetric primitives and delayed key disclosure. This is attractive for high-rate IoT streams because per-packet public-key verification can be avoided; however, secure bootstrap, bounded clock skew, replay control, and disclosure scheduling remain mandatory. AQ-TESLA addresses this design space by confining QKD to infrastructure links and allowing constrained devices to consume edge-delivered epoch material and TESLA authentication keys, as illustrated in Figure 1.

Figure 1. AQ-TESLA edge-assisted hybrid architecture.

The main contributions are fivefold: (1) an edge-assisted architecture that combines infrastructure-facing QKD, ML-KEM fallback, CoAP, and TESLA without requiring quantum hardware at constrained endpoints; (2) a QKD-pool-aware controller that jointly balances risk, latency, and finite quantum-key supply; (3) an authenticated synchronization and delayed-disclosure workflow with explicit clock-uncertainty handling; (4) a hybrid epoch-root derivation that combines independent QKD and PQC inputs; and (5) a reproducible evaluation that includes attack analysis, bootstrap confidence intervals, controller ablation, threshold sensitivity, and scalability from 100 to 2000 devices.

2. Related Work

2.1. 6G IoT Security and Edge Authentication

Surveys of 6G and massive IoT identify virtualization, edge orchestration, massive access, AI-assisted control, and heterogeneous trust domains as central security challenges [1,2,3,4]. Authentication surveys further show that computation, communication, anonymity, key renewal, and verification cost must be considered jointly [5]. Edge-assisted IoT can move expensive cryptographic operations away from endpoints and reduce response time, but the gateway becomes a high-value enforcement point whose compromise must be included in the trust boundary [15].

2.2. CoAP and Continuous Authentication

CoAP reduces application-layer overhead for constrained devices, yet its UDP-based deployment and interaction with DTLS or application-layer security still require explicit replay protection, identity binding, and key management. Recent CoAP authentication schemes reduce endpoint overhead while documenting the cost-security trade-off [6,7]. Continuous-authentication architectures additionally motivate reevaluating an active session instead of relying exclusively on a one-time initial handshake [8].

2.3. Post-Quantum Authentication and QKD

NIST standardized ML-KEM, ML-DSA, and SLH-DSA in 2024 [9,10,11]. IoT studies indicate that lattice-based authentication is feasible but incurs message-size and computation costs [12]. QKD surveys describe integration opportunities in 5G and beyond, while machine-learning-assisted link selection has been proposed for next-generation quantum networks [16,17]. Because QKD does not intrinsically authenticate its classical channel, man-in-the-middle protection remains an essential integration requirement [18,19].

2.4. Gap Summary

Existing approaches address parts of the problem but leave a systems-level integration gap. DTLS/CoAP is mature but remains tied to classical public-key assumptions; PQC-CoAP provides software quantum resistance at increased message and computation cost; the classical TESLA is efficient for streams but depends on classical bootstrap and synchronization; and Static QKD-TESLA can waste scarce quantum key material when every context is treated identically. AQ-TESLA is positioned to close this gap by coupling hybrid root establishment with delayed-disclosure authentication and an online controller that explicitly accounts for finite QKD supply.

Table 1 presents a comparative positioning of AQ-TESLA against the four reference approaches, summarizing the principal strength and limitation of each design and clarifying the systems-level gap targeted by the proposed architecture.

Table 1. Positioning of AQ-TESLA.

Approach	Strength	Limitation
DTLS/CoAP	Mature channel protection	Classical public-key exposure and handshake cost
PQC-CoAP	Software quantum resistance	Larger messages and computation
Classical TESLA	Efficient stream authentication	Classical bootstrap and clock dependence
Static QKD-TESLA	Strong key source	Key-pool waste and infrastructure assumptions
AQ-TESLA	Adaptive hybrid root and stream authentication	Requires QKD-capable edge infrastructure and calibration

3. System and Threat Model

3.1. Entities and Deployment Boundary

The deployment contains constrained CoAP devices, a 6G access network, edge gateways, an application or group server, a QKD key-management service, and a post-quantum credential authority. QKD terminates only between infrastructure nodes connected by an optical path. End devices neither generate nor measure qubits; instead, they receive edge-provisioned epoch material protected by device-specific credentials. This boundary keeps quantum hardware and high-cost cryptographic processing away from the constrained endpoint while retaining a quantum-derived input to the authentication hierarchy.

3.2. Threat Model

Adversarial Model and Security Goals. We consider a probabilistic polynomial-time adversary controlling the public communication channel with capabilities including replay, man-in-the-middle, delay, packet injection, resource-exhaustion, long-term key compromise, and harvest-now-decrypt-later attacks. Security goals are: (G1) authentication integrity, (G2) replay resistance, (G3) TESLA interval authenticity, (G4) hybrid-root secrecy, and (G5) availability-preserving rekeying.

The adversary can eavesdrop, replay, delay, inject, impersonate, exhaust resources, compromise a classical long-term key, manipulate synchronization traffic, or store encrypted traffic for later quantum cryptanalysis. The attacker may also disrupt the QKD link or target its classical control plane. The model assumes that the adversary cannot violate the stated security properties of correctly implemented QKD, ML-KEM, HMAC-SHA3–256, HKDF, or the one-way function used for the TESLA chain.

3.3. Trust Assumptions

The edge gateway is a trusted enforcement point and therefore a high-value component. Simultaneous compromise of the edge gateway and application server defeats endpoint-to-service assurance. The classical QKD control channel is authenticated using ML-DSA or another approved mechanism because QKD does not provide its own peer authentication. Detector side channels, optical implementation flaws, and physical-layer attacks are outside the present systems model and are stated explicitly as limitations.

4. AQ-TESLA Protocol

4.1. Hybrid Initialization

Let $K_Q$ denote a fresh QKD block shared by the edge and application service, $K_P$ the ML-KEM shared secret, e the epoch identifier, and c the protocol context. The hybrid epoch root is derived as

$$K_e=\mathrm{H}\mathrm{K}\mathrm{D}\mathrm{F}\left(K_Q\parallel K_P\parallel e\parallel c\right)$$

(1)

Under the extractor assumption, $K_e$ remains unpredictable if at least one independent input retains sufficient entropy. If QKD is unavailable, the controller enters the explicitly identified PQC-only degraded mode and records the resulting assurance change.

Explanatory definitions previously presented below Figure 2 have been relocated to the corresponding protocol subsections to improve figure readability.

Figure 2. Hybrid root derivation and TESLA key lifecycle.

4.2. TESLA Chain and Packet Format

From $K_e$, the gateway derives a reverse one-way TESLA chain according to

$$K_i=H\left(K_{i+1}\right), i=N-1,\dots ,0$$

(2)

During interval i, the authenticated CoAP record binds the payload $m_i$, rotating pseudonym ${pid}_i$, sequence number ${seq}_i$, and epoch e through

$${\mathrm{T}\mathrm{a}\mathrm{g}}_i=\mathrm{H}\mathrm{M}\mathrm{A}\mathrm{C} - \mathrm{S}\mathrm{H}\mathrm{A}3 - 256\left(K_i,\hspace{0.33em}{m}_i\parallel pi{d}_i\parallel se{q}_i\parallel e\right)$$

(3)

The key $K_i$ is disclosed only after the receiver has established that the packet arrived before the corresponding disclosure deadline. Sequence and epoch fields are retained in the receiver state to prevent replay across intervals or epochs.

4.3. Authenticated Edge Synchronization

TESLA security requires a bounded receiver–sender clock offset. AQ-TESLA uses signed edge synchronization exchanges, sequence numbers, monotonic device time, and a receiver uncertainty bound $\epsilon$. A packet is eligible for delayed verification only when the conservative arrival condition

$$t_i^{recv}+\epsilon <t_i^{disc}$$

(4)

is satisfied, where $t_i^{recv}$ is the receiver arrival time and $t_i^{disc}$ is the scheduled disclosure time. Here, “quantum-aware synchronization” means that synchronization control is authenticated and rekeyed from the hybrid security context; it does not imply that IoT endpoints contain quantum clocks.

4.4. Adaptive Controller

The controller weights and thresholds are demonstrative operating parameters selected for the reference workload. They are not claimed to be globally optimal. Additional robustness analysis across alternative weighting schemes is identified as future work.

Controller Parameter Selection. Controller weights were selected through iterative calibration to emphasize attack evidence and trust deficit while retaining sensitivity to loss, congestion, message criticality, and QKD-pool status. Thresholds 0.25 and 0.45 were chosen as operating points that balanced under-protection and unnecessary escalation. The sensitivity analysis in Section 7 confirms that conclusions remain stable across threshold variations.

For event i, the controller evaluates normalized packet loss $L_i$, attack evidence $A_i$, congestion $C_i$, trust deficit (1 − $T_i$), criticality $P_i$, and QKD-pool deficit (1 − $Q_i$), with all inputs scaled to [0,1]. The reference risk score is

$$R_i=0.20L_i+0.27A_i+0.18C_i+0.20\left(1-T_i\right)+0.10P_i+0.05\left(1-Q_i\right)$$

(5)

The controller maps the score to the operating state using

$$M_i=\{\begin{array}{ll}M0,& R_i<0.25,\\ M1,& 0.25\le R_i<0.45,\\ M2,& R_i\ge 0.45 \mathrm{or} \mathrm{strong} \mathrm{attack} \mathrm{evidence}.\end{array}$$

(6)

Mode M0 continues the current TESLA chain. Mode M1 shortens the disclosure interval, increases edge sampling, and refreshes synchronization. Mode M2 performs hybrid rekeying when the high-risk threshold is met or strong attack evidence is present, subject to QKD-pool availability. If QKD supply is critically low, the system preserves availability through ML-KEM-only rekeying and records a reduced-quantum-assurance flag.

Figure 3 shows the adaptive controller workflow from observed loss, anomaly, congestion, and trust signals through risk computation, QKD-pool checking, and selection of M0/M1/M2 actions; it visualizes the decision logic formalized in Equations (5) and (6).

Figure 3. AQ-TESLA adaptive security controller.

Table 2 presents the AQ-TESLA operating modes and links each risk condition to the corresponding controller action, providing a compact view of how the adaptive policy escalates protection while accounting for QKD availability.

Table 2. AQ-TESLA operating modes.

Mode	Condition	Action
M0 Continue	Low risk	Existing TESLA chain; compact evidence
M1 Step-up	Elevated risk	Short disclosure interval; resynchronize; richer logging
M2 Hybrid rekey	High risk	QKD + ML-KEM root; new epoch and pseudonyms
M2-P Degraded PQC	QKD unavailable	ML-KEM root; explicit assurance flag
M3 Isolate	Confirmed abuse/DoS	Rate limit, quarantine, and local fail-safe policy

4.5. Adaptive Rekeying and Pool Control

The QKD pool model is intentionally abstract and represents comparative resource-management behavior. Reported reductions in QKD consumption apply only to the defined workload, key-generation budget, and rekey-allocation assumptions.

A static quantum policy can consume scarce key material during routine traffic. AQ-TESLA therefore maintains a logical key-pool state, predicted replenishment, pending requests, message criticality, and the next safe rekey window. High-criticality or high-risk events receive priority, whereas routine groups remain within an authenticated TESLA epoch until the maximum age or risk threshold is reached. The pool model is a systems abstraction of generated-versus-consumed secret bits rather than a physical QKD finite-key calculation.

$$B_{t+1}=\mathrm{m}\mathrm{i}\mathrm{n}\{B_{\mathrm{m}\mathrm{a}\mathrm{x}},\hspace{0.33em}{B}_t+G_t-C_t\}$$

(7)

Here, $B_t$ is the available secret-bit pool, $G_t$ is modeled key generation during the interval, $C_t$ is QKD consumption caused by selected rekey events, and $B_{max}$ is the configured pool capacity. This accounting is used for controller decisions and scalability analysis; it is not a physical finite-key security model.

5. Security Analysis

Security claims should be interpreted under stated assumptions regarding trusted gateways, authenticated QKD control channels, bounded synchronization error, and uncompromised cryptographic primitives. Formal verification remains future work.

Formal Verification Perspective. In addition to the analytical argument, AQ-TESLA can be modeled in Tamarin or ProVerif using authentication and secrecy queries over the hybrid root, TESLA disclosure schedule, and rekey transitions. Under the stated assumptions, the protocol preserves injective authentication and secrecy of the epoch root if at least one of the QKD or ML-KEM inputs remains uncompromised.

Table 3 summarizes the mapping between each threat in the adversarial model, the protocol control used to address it, and the resulting security outcome, thereby connecting the stated threat assumptions to the analytical security claims.

Table 3. Threat-to-control mapping.

Threat	Security Mechanism	Outcome
Replay	Epoch, sequence, arrival-before-disclosure check	Reject stale/duplicate packet
MITM	Authenticated QKD control + hybrid root	Abort or PQC-only fallback
Impersonation	Device credential and pseudonym binding	Reject and revoke
Delayed-disclosure abuse	Bounded skew and interval verification	Discard late packet/key
Key compromise	Fresh epoch root and one-way chain	Limit exposure and rekey
Harvest-now-decrypt-later	QKD/PQC root establishment	Protect future confidentiality assumptions
DoS	Cheap prefilter, rate limits, pool quotas	Contain resource consumption

Proposition 1 (Hybrid-root secrecy). If either $K_Q$ or $K_P$ remains hidden from the adversary and HKDF satisfies the stated extractor/pseudorandomness assumptions, the epoch root $K_e$ is unpredictable to the adversary.

The guarantees do not cover compromised endpoints after key disclosure, malicious application logic, QKD detector side channels, or simultaneous compromise of both hybrid inputs and the edge policy authority. DoS is mitigated rather than eliminated.

6. Experimental Methodology

Monte Carlo Methodology Details. The simulation generated 180,000 events using randomized variables including packet loss, congestion level, attack probability, trust score, message criticality, authentication outcome, and QKD-pool status. Fixed parameters included the event population, controller weights, QKD budget, rekey allocation size, and protocol structure. Event outcomes were evaluated using the risk-scoring model and controller state-transition criteria defined in Equations (5) and (6).

Latency, energy, attack rejection, authentication success, and scalability are modeled outcomes from the Monte Carlo simulation and should not be interpreted as experimentally validated deployment measurements.

Simulation Limitations and Justification. All results are simulation-based and no physical QKD hardware, embedded IoT platform, or operational 6G network was available during this study. Simulation parameters were derived from representative values reported in the literature and were used to provide a reproducible comparative evaluation rather than deployment-level performance claims.

The evaluation is a reproducible systems-level Monte Carlo simulation comprising 180,000 synthetic CoAP events with the random seed 20260727. It models classical processing, queuing, packet loss, controller decisions, attack rejection, authentication outcome, and an aggregate edge QKD key pool. It intentionally does not model photon sources, decoy states, detectors, quantum-bit-error-rate estimation, privacy amplification, or a physical 6G radio. NetSquid is identified as an appropriate platform for future physical-layer quantum-network calibration [20].

Table 4 presents the five simulated 6G IoT workload scenarios and their shares, base packet-loss levels, congestion levels, and message criticality; these scenario parameters define the heterogeneous operating conditions used in the comparative evaluation.

Table 4. Simulated 6G IoT scenarios.

Scenario	Share (%)	Base Loss (%)	Base Congestion (%)	Base Criticality (%)
Routine sensing	34	1.50	18	14
Dense urban IoT	25	7.50	72	25
Industrial control	19	2.50	38	62
Emergency telemetry	12	4.50	52	88
Adversarial surge	10	11.50	78	58

The baselines were DTLS-CoAP, PQC-CoAP using standardized post-quantum handshakes, classical TESLA-CoAP with a non-quantum bootstrap, and Static QKD-TESLA with frequent quantum rekeying. The evaluated metrics were mean and P95 latency, CPU utilization, memory, energy, communication overhead, authentication success, attack rejection, QKD key consumption, key-pool depletion, unsafe under-protection, unnecessary escalation, and scalability. The supplementary package provides the raw summary tables, a synthetic trace sample, analysis outputs, figure sources, the simulation seed, and the parameter manifest used to reproduce the reported values.

The bootstrap confidence intervals used 1000 resamples. The controller weights were 0.20 for packet loss, 0.27 for attack evidence, 0.18 for congestion, 0.20 for trust deficit, 0.10 for message criticality, and 0.05 for QKD-pool deficit. The step-up and hybrid-rekey thresholds were 0.25 and 0.45, respectively; sensitivity analysis varied the high-risk threshold from 0.37 to 0.57. Scalability was evaluated from 100 to 2000 devices using a 10 min edge key-generation budget of 3.6 Mbit and a modeled 256-bit QKD rekey allocation. These values are transparent simulation assumptions rather than measurements from a specific QKD appliance.

Sensitivity Analysis Details. The primary variable examined was the high-risk threshold, which was varied from 0.37 to 0.57. All other controller weights, event distributions, QKD-generation budgets, traffic composition, and authentication parameters remained fixed to isolate the impact of threshold selection on under-protection, escalation behavior, and QKD consumption.

7. Results

Table 5 shows that AQ-TESLA achieved 12.91 ms mean latency and 21.24 ms P95 latency. It was slower than classical TESLA-CoAP because of the controller, synchronization checks, and occasional hybrid rekeying add cost, but it reduced mean latency by 41.2% relative to Static QKD-TESLA and by 43.2% relative to PQC-CoAP.

Table 5. Main performance results.

Method	Mean Latency (ms)	P95 Latency (ms)	Energy (mJ/Message)	Overhead (Bytes/Message)	Attack Rejection (%)	Authentication Success (%)	QKD Key Consumption (Mbit)
DTLS-CoAP	16.32	23.98	0.87	711.49	73.83	98.95	0.00
PQC-CoAP	22.72	25.64	1.40	1831.49	86.98	97.89	0.00
TESLA-CoAP	8.52	11.05	0.38	275.44	79.39	98.89	0.00
Static QKD-TESLA	21.96	26.27	0.63	443.51	94.57	98.95	1.71
AQ-TESLA	12.91	21.24	0.50	369.50	97.30	98.93	0.40

These latency trends are consistent with recent implementation-oriented PQC studies in constrained IoT, which report that post-quantum key establishment and authentication can add nontrivial computation, transmission, and energy overhead, with the magnitude depending strongly on the link and device platform [21,22,23,24]. In that context, AQ-TESLA’s lower modeled latency than PQC-CoAP is attributable to amortizing expensive hybrid root establishment across TESLA-authenticated message streams rather than performing a public-key operation for every message; however, the present values remain simulation outputs and should not be read as direct hardware equivalence to those studies.

Figure 4 visualizes the mean and P95 authentication latency of all five methods, making the latency trade-off between the lightweight TESLA baseline and the quantum-safe alternatives directly comparable.

Figure 4. Authentication latency comparison.

AQ-TESLA preserved high simulated attack rejection while avoiding universal public-key handshakes and continuous quantum rekeying. Classical TESLA remained the least expensive baseline, but its classical bootstrap does not provide the same quantum-safe assurance boundary. The comparison therefore reflects an efficiency-assurance trade-off rather than a claim that AQ-TESLA minimizes every resource metric.

Table 6 presents AQ-TESLA’s rejection rates across the individual attack classes, allowing the aggregate attack-rejection result to be examined by the adversarial mechanism rather than as a single average.

Table 6. AQ-TESLA attack-specific rejection.

Attack	Events	Rejection Rate (%)
Replay	6362	99.83
MITM	5136	99.90
Impersonation	4642	99.57
Delayed-disclosure abuse	3823	97.80
DoS	6853	89.17
Key compromise	3563	99.38
Harvest-now-decrypt-later	2909	99.45

Figure 5 shows the attack-specific rejection for AQ-TESLA across replay, MITM, impersonation, delayed-disclosure abuse, DoS, key compromise, and harvest-now-decrypt-later scenarios, highlighting the relative difficulty of mitigating resource-exhaustion attacks.

Figure 5. AQ-TESLA attack-oriented effectiveness.

DoS rejection was lower than the rejection of cryptographic attacks because authentication alone cannot eliminate the radio, queue, or compute exhaustion. AQ-TESLA therefore combines cryptographic checks with inexpensive prefilters, rate limits, pool quotas, and gateway admission control. The 89.17% DoS rejection value should be interpreted as modeled mitigation, not complete DoS prevention.

Recent continuous- and adaptive-authentication studies likewise emphasize that security mechanisms should be adjusted to the context and threat state rather than applied uniformly [25,26]. The lower modeled DoS rejection observed here is therefore consistent with the broader literature’s distinction between cryptographic authentication and availability protection: authentication can reject forged identities or messages, whereas exhaustion attacks also require admission control, rate limiting, and resource-aware policy enforcement [25,26].

Table 7 presents the scalability comparison between Static QKD-TESLA and AQ-TESLA from 100 to 2000 devices, reporting QKD demand, depletion, P95 latency, and authentication success to show how key-pool pressure evolves with scale.

Table 7. Quantum key-pool scalability.

Method	Devices	QKD Demand (Mbit/10 min)	QKD Depletion (%)	P95 Latency (ms)	Authentication Success (%)
Static QKD-TESLA	100	0.39	0.00	26.58	99.76
Static QKD-TESLA	250	1.14	0.00	27.20	99.55
Static QKD-TESLA	500	2.55	0.00	28.43	99.13
Static QKD-TESLA	1000	5.70	36.82	31.29	95.10
Static QKD-TESLA	1500	9.12	60.53	34.50	93.91
Static QKD-TESLA	2000	12.73	71.73	37.96	92.60
AQ-TESLA	100	0.22	0.00	21.48	99.76
AQ-TESLA	250	0.60	0.00	21.99	99.55
AQ-TESLA	500	1.28	0.00	22.98	99.13
AQ-TESLA	1000	2.74	0.00	25.30	98.10
AQ-TESLA	1500	4.29	16.00	27.89	93.91
AQ-TESLA	2000	5.88	38.79	30.69	92.60

Figure 6 plots QKD key-pool demand against the modeled 3.6 Mbit/10 min generated-key budget as the device population increases, illustrating where static rekeying begins to outpace key supply and how adaptive rekeying shifts the depletion point.

Figure 6. QKD key-pool demand and generated budget.

Static QKD-TESLA exceeded the modeled 3.6 Mbit key-generation budget at larger device populations, whereas AQ-TESLA delayed depletion by selectively invoking quantum-backed rekeying. Because the result depends on optical distance, hardware, secret-key rate, traffic composition, and group size, it demonstrates the benefit of pool-aware control under the reference workload rather than a universal QKD-capacity limit.

The QKD-network literature treats secret-key material as a finite managed resource whose storage, prioritization, and allocation can become a service bottleneck [24]. Recent resource-allocation studies further show that adaptive or priority-aware key assignment can improve utilization and reduce congestion or bottleneck-key consumption compared with less selective allocation policies [27,28]. The AQ-TESLA pool-aware trend is directionally consistent with those findings, while differing in scope because the present model abstracts the optical layer and applies the resource decision at the authentication/rekeying controller.

Figure 7 shows that AQ-TESLA retained lower P95 latency than PQC-CoAP and Static QKD-TESLA as the modeled device population increased. Classical TESLA remained faster, but it did not provide the hybrid quantum-safe bootstrap and key-pool management used by AQ-TESLA. The scalability result therefore supports the proposed architectural trade-off within the simulation boundary.

Figure 7. P95 authentication latency under scale.

Table 8 presents the controller ablation study, quantifying how removing trust, congestion, or QKD-pool awareness changes policy accuracy, under-protection, unnecessary escalation, and quantum-mode usage.

Table 8. Controller ablation results.

Variant	Policy Accuracy (%)	Under-Protection (%)	Unnecessary Escalation (%)	Quantum-Mode Share (%)
AQ-TESLA full	77.75	11.65	19.30	16.21
Without trust	74.35	13.75	22.40	14.41
Without congestion	75.65	12.80	23.60	15.31
Without QKD-pool awareness	76.75	11.80	19.85	25.81
Fixed quantum mode	9.68	0.00	100.00	100.00

Figure 8 visualizes the under-protection rate for the full controller and each ablated variant, making the safety cost of removing trust or congestion information and the behavior of the fixed-quantum policy explicit.

Figure 8. Effect of controller components on under-protection.

Removing QKD-pool awareness did not immediately increase under-protection, but it substantially increased the quantum-mode share and consequently accelerated later depletion. Removing trust or congestion information increased unsafe or unnecessary decisions. The fixed-quantum variant eliminated under-protection in the simplified policy classification but escalated every message, yielding 100% unnecessary escalation and defeating the efficiency objective. Together, the ablation results show that the controller components serve distinct roles rather than merely duplicate the same signal.

These ablation results are also aligned with adaptive edge-security research showing that risk-aware decisions benefit from multiple contextual signals and can reduce the inefficiency of static, one-size-fits-all policy enforcement [25]. In AQ-TESLA, the increased quantum-mode share after removing pool awareness specifically indicates that resource state is not merely a security signal but also a control variable for conserving scarce QKD material, consistent with the key-management concerns identified for QKD networks [24].

Table 9 presents bootstrap 95% confidence intervals for mean authentication latency across all evaluated methods, providing an uncertainty estimate for the latency comparisons reported in Table 5.

Table 9. Bootstrap 95% confidence intervals for mean latency.

Method	Mean Latency	95% CI low	95% CI High
DTLS-CoAP	16.317	16.182	16.447
PQC-CoAP	22.722	22.545	22.893
TESLA-CoAP	8.519	8.445	8.596
Static QKD-TESLA	21.958	21.845	22.067
AQ-TESLA	12.911	12.727	13.087

Figure 9 shows the sensitivity of under-protection and quantum-mode share to the high-risk threshold, illustrating the opposing effects of more aggressive escalation and QKD conservation that motivate the selected reference threshold.

Figure 9. Sensitivity to the high-risk threshold.

Lower high-risk thresholds reduced under-protection at the cost of a larger quantum-mode share, whereas higher thresholds conserved QKD material but increased the risk of insufficient escalation. The selected value of 0.45 is therefore a transparent operating point for the reference workload, not an optimized or universally valid threshold.

Threshold behavior should therefore be interpreted as a tunable operating trade-off rather than a universal optimum. This is consistent with risk-adaptive IoT security frameworks, where policy aggressiveness is adjusted according to contextual risk and resource constraints [25]; the selected 0.45 value is consequently specific to the reference workload and requires recalibration for different traffic, attack, and QKD-supply regimes.

8. Discussion

Expanded Discussion. The results demonstrate that AQ-TESLA achieves a balanced security–efficiency trade-off. Compared with Static QKD-TESLA, the proposed approach reduced QKD key consumption from 1.71 Mbit to 0.40 Mbit while maintaining higher attack rejection (97.30%). The scalability results further show that adaptive pool-aware control delays QKD depletion as network size increases. In addition, the ablation study confirms that trust-awareness, congestion-awareness, and QKD-pool awareness contribute distinct benefits, supporting the architectural rationale behind the adaptive controller design.

The reduction in modeled QKD consumption is consistent with recent QKD key-management work, which identifies finite key supply, request prioritization, and efficient allocation as central scaling constraints [24]. Both Zheng et al. [27] and Chen et al. [28] report that adaptive allocation strategies can improve quantum-key utilization under contention, which supports the rationale for AQ-TESLA’s pool-aware escalation; however, those studies model QKD network resource allocation rather than an IoT authentication controller, so the comparison is conceptual rather than a direct performance benchmark.

The central contribution is architectural. QKD is treated as an infrastructure key service, while constrained IoT devices rely on edge-delivered symmetric stream authentication. TESLA amortizes authentication across packets, and the adaptive controller reserves expensive hybrid rekeying for conditions in which risk or message value justifies it. This division of responsibility is more realistic than assuming that every constrained endpoint can host QKD hardware or execute repeated public-key handshakes.

The edge-assisted separation of expensive security functions from constrained endpoints is also supported by recent IoT studies showing that quantum-safe mechanisms are feasible but may impose material execution, communication, and energy costs on constrained devices [22,23]. This strengthens the case for using the edge to absorb infrequent hybrid key-establishment work while endpoints rely primarily on symmetric stream authentication between rekey events.

The hybrid root addresses both QKD availability and classical-channel authentication limitations. When the optical link is unavailable, ML-KEM supports continued service in an explicitly flagged degraded mode. When both inputs are available, combining independent QKD and PQC material can preserve root unpredictability if at least one input remains secure under the stated extractor assumptions [13,14]. AQ-TESLA therefore uses the two mechanisms as complementary trust inputs rather than mutually exclusive alternatives.

Experimental work on hybrid QKD–PQC systems has similarly motivated combining independent quantum and post-quantum inputs rather than treating them as mutually exclusive alternatives [13,14]. The present results extend that systems argument by coupling the hybrid root to an adaptive usage policy, but they do not replace the optical and cryptographic implementation evidence provided by those experimental studies.

Synchronization remains a critical dependency because delayed disclosure is secure only when the receiver can bound sender–receiver clock uncertainty. Delay or timestamp manipulation can invalidate the TESLA acceptance condition even when the adversary cannot forge a tag. Prior secure time-synchronization research reinforces the need to handle delay and timestamp tampering alongside cryptographic authentication [21,29]. AQ-TESLA therefore maintains an uncertainty bound and rejects packets whose arrival time cannot be safely classified.

The controller’s use of dynamic risk and context inputs is consistent with recent adaptive edge-security and continuous-authentication research, which favors context-sensitive security actions over static policies [25,26]. AQ-TESLA differs by adding QKD-pool status to the decision state, coupling security escalation to the availability of a scarce cryptographic resource.

Table 10 consolidates the principal claims of the study with the evidence supporting each claim and the explicit boundary of that evidence, distinguishing simulation-based findings from hardware or field validation.

Table 10. Claims–evidence matrix.

Claim	Evidence	Boundary
AQ-TESLA reduces modeled latency vs Static QKD/PQC	Synthetic held-out systems simulation	No hardware benchmark
Adaptive control conserves QKD keys	Key-pool demand model and ablation	No optical-channel measurement
Hybrid root improves resilience	Cryptographic composition argument	Depends on implementation and HKDF assumptions
TESLA authenticates continuous streams	Protocol analysis and bounded-skew assumptions	Requires secure synchronization
Scales to 2000 simulated devices	Queue and key-pool model	Not a 6G field trial

8.1. Limitations

No hardware benchmarks, physical QKD experiments, or operational 6G trials were performed. Consequently, conclusions are restricted to comparative systems-level behavior.

All events and resource costs are synthetic. The QKD layer is represented as an aggregate key-pool service rather than a physical optical simulation. The model does not include detector blinding, finite-key analysis, QBER, trusted-node compromise, coexistence with classical wavelengths, mobility handover, or real 6G scheduling. CPU, memory, energy, and latency values are systems estimates rather than measurements from microcontrollers, QKD appliances, or standards-conformant libraries. The security propositions are proof sketches rather than machine-checked proofs. These limitations restrict the conclusions to systems-design feasibility and comparative behavior under the specified workload.

8.2. Future Work

Future research directions include machine-checked protocol proofs, hardware-based validation on constrained devices, integration with physical QKD testbeds, mobility-aware authentication, quantum-network orchestration, and AI-assisted security policy adaptation.

Future work should couple a physical-layer quantum simulator such as NetSquid with an edge/CoAP systems simulator, benchmark ML-KEM and HMAC-SHA3 on representative constrained hardware, implement OSCORE or group-communication integration, study finite-key QKD and physical attacks, evaluate mobility and satellite/UAV QKD, and verify the protocol in Tamarin or ProVerif. Deployment studies should use QKD only where optical infrastructure, key rates, and operational governance justify the added complexity.

9. Conclusions

AQ-TESLA demonstrates simulation-based systems feasibility only. Practical deployment performance requires hardware, network, and quantum-infrastructure validation.

AQ-TESLA combines infrastructure-facing QKD, ML-KEM fallback, TESLA stream authentication, CoAP, authenticated edge synchronization, and a key-pool-aware risk controller in a single edge-assisted architecture. In the reference systems simulation, adaptive hybrid rekeying reduced modeled latency relative to Static QKD-TESLA and PQC-CoAP, achieved 97.30% attack rejection and 98.93% authentication success, and consumed 76.9% less QKD key material than Static quantum rekeying. The ablation, confidence-interval, threshold-sensitivity, and scalability results further support the value of adaptive escalation and pool awareness. These findings establish systems-model feasibility only; physical quantum-network, embedded-device, and 6G field validation remain necessary before deployment claims can be made.