Maintaining IoT Device Identification under Concept Drift via Budget-Aware Traffic Labeling

Shayan Azizi; Norihiro Okui; Masataka Nakahara; Ayumu Kubota; Gustavo Batista; Hassan Habibi Gharakaheili

Source-linked AI summary

Maintaining IoT Device Identification under Concept Drift via Budget-Aware Traffic Labeling

Shayan Azizi, Norihiro Okui, Masataka Nakahara, Ayumu Kubota, Gustavo Batista, Hassan Habibi Gharakaheili

arXiv:2608.15465v1Aug 16, 2026cs.NIcs.CRcs.LG

TL;DR

IoT classifiers degrade as device behavior evolves, while operators must decide which deployment traffic to label under limited budgets. The paper combines a conformity-based drift detector with uniform sampling and adaptive labeling rates, maintaining performance more effectively than detector-guided selection while providing feature-level explanations.

Problem
Under limited labeling budgets, it remains unclear how to identify evolving deployment behaviors for effective long-term IoT classifier maintenance.
Method
The paper models class-conditional feature conformity to detect behavioral evolution, then uses uniform traffic sampling with labeling rates scaled to observed non-conformity.
Results
Uniform sampling with behavior-adjusted labeling maintains classifier performance more effectively than detector-guided sample selection and performs comparably to confidence-guided adaptation.
Takeaways & Limitations
Separating labeling-rate adaptation from traffic-instance selection supports effective classifier maintenance while retaining feature-level explanations of behavioral evolution.
Takeaways & Limitations
The detector infers behavioral evolution from marginal features and may overlook changes occurring only in feature dependencies; evaluation uses one ISP deployment dataset from a controlled testbed.

Abstract

from arXiv · show

Identification of IoT device types from passive traffic is increasingly used for security management in enterprise and ISP networks. However, the performance of machine learning-based classifiers gradually degrades under concept drift as device behavior evolves. Therefore, maintaining classification performance requires periodic retraining with newly labeled deployment traffic. The operational challenge is determining how much and which deployment traffic instances to label for maintaining classification performance. We show that these two decisions should be treated separately. While retraining solely on instances selected by a drift detector is prone to systematically overlooking parts of the emerging behavioral space, uniformly sampled deployment traffic captures more representative behavioral changes. Instead, drift detection is more effective at determining the amount of deployment traffic that should be labeled. We make three contributions. (1) We conduct a two-year longitudinal study of IoT traffic and characterize how behavioral evolution manifests across device classes and how retraining with newly labeled traffic restores classification performance. (2) We develop a conformity-based drift detector that captures class-conditional behavioral models directly from raw traffic features and provides feature-level explanations of behavioral evolution. (3) We demonstrate that adjusting the traffic labeling rate according to the observed behavioral evolution, combined with uniform traffic sampling, maintains classifier performance more effectively than detector-guided sample selection and is beneficial to managing the traffic labeling effort. We further show that this strategy performs comparably to confidence-guided adaptation while providing feature-level explanations. Our evaluation uses 3.8 million IPFIX flow records collected from 21 IoT types over more than 2 years.

I. INTRODUCTION · II. RELATED WORK

The paper frames long-term IoT device identification as a budget-aware maintenance problem under concept drift, separating how much deployment traffic to label from which instances to select. It motivates uniform sampling and conformity-based, feature-level drift detection as complementary responses to evolving behavior and limited labeling resources.

I. INTRODUCTION: IoT device identification enables device-specific security policies against threats including large-scale attacks, service disruption, tracking, and private-data exfiltration.These risks are especially consequential for ISPs serving residential and enterprise subscribers.
I. INTRODUCTION: Firmware updates, software changes, and changing operating environments evolve traffic patterns, causing deployed classifiers to degrade through concept drift.Maintaining accuracy therefore becomes an operational problem rather than a one-time deployment task.
I. INTRODUCTION: Limited labeling capacity creates separate decisions about how much deployment traffic to label and which instances to select.The paper challenges drift-detector-guided selection because it can overlook emerging behavioral patterns.
I. INTRODUCTION: Uniformly sampled deployment traffic captures broader behavioral evolution than detector-selected instances for retraining.The paper argues that drift detection should instead help determine the labeling amount as behavioral evolution varies over time.
I. INTRODUCTION: The proposed framework separates labeling-rate control from instance selection and uses a conformity-based detector that models class-conditional traffic distributions.The detector identifies feature-level non-conformity and provides interpretable explanations of behavioral changes.
I. INTRODUCTION: The study analyzes more than two years of IoT traffic from 21 real device types and examines behavioral evolution, classifier drift, and maintenance using freshly labeled deployment traffic.These contributions establish longitudinal evidence for how drift manifests across device classes.
II. RELATED WORK: Prior IoT research models distinctive device behavior using packet-level features, flow-level statistics, or combinations of both for identification and anomaly detection.Related drift studies often document classifier degradation but provide limited insight into its behavioral causes or long-term maintenance.
II. RELATED WORK: Existing drift detectors mainly use classifier confidence or learned embeddings, offering limited visibility into underlying behavioral changes and how to allocate scarce labeling resources.Alternative model-selection, transfer-learning, and domain-adaptation methods do not address previously unseen patterns or instance-level drift detection, while adaptation research largely assumes labeled data are already available.

III. IOT TRAFFIC DATA … B. Behavioral Evolution under Long-Term Deployment

The study uses a two-year, multi-device IPFIX dataset to examine long-term IoT traffic evolution and its effects on classification. Behavioral changes are continuous, heterogeneous, and non-monotonic, while retraining with newly labeled deployment traffic can restore performance.

III. IOT TRAFFIC DATA: The dataset covers more than 2 years of traffic from 21 IoT device types spanning speakers, cameras, streaming devices, plugs, hubs, and home automation equipment.Traffic focuses on TCP/443 and represents flows as IPFIX records with 22 statistical features.
III. IOT TRAFFIC DATA: The resulting data include approximately 260K training flows, 113K validation flows, and 3.38M deployment-phase flows collected across two years.Training and validation use traffic from 1 Oct 2021 to 31 Dec 2021, while evaluation uses traffic from 1 Jan 2022 to 31 Dec 2023.
IV. BEHAVIORAL EVOLUTION OF IOT TRAFFIC UNDER LONG-TERM DEPLOYMENT: The study first evaluates an unchanged baseline classifier throughout a two-year deployment period, then analyzes behavioral evolution and restoration through freshly labeled traffic.This establishes the feasibility of maintaining classification under limited labeling resources.
A. IoT Traffic Classification Setup: The baseline is a Random Forest trained on 70% of October–December 2021 flows, with 30% reserved for validation and hyperparameters selected by 10-fold cross-validation.The model has 100 trees, maximum depth 30, minimum 5 samples per split, and validation macro-averaged F1-score 0.974.
B. Behavioral Evolution under Long-Term Deployment: A progressive decline in macro F1-score begins around mid-2022 when the baseline is evaluated on consecutive 7-day deployment windows without updates.The evaluation spans continuously collected traffic from January 2022 through the end of 2023.
B. Behavioral Evolution under Long-Term Deployment: Performance partially recovers during the second half of 2023, indicating that device behaviors can evolve dynamically rather than continuously diverging from the training distribution.Behavioral evolution also differs across device classes, producing persistent, decaying, and restoring recall patterns.
B. Behavioral Evolution under Long-Term Deployment: During low-performance periods, deployment instances deviate from training behavior and partially overlap other classes, whereas high-performing traffic conforms to learned patterns without being statistically identical.The relevant criterion is conformity to learned behavioral patterns, not exact statistical identity with training traffic.
B. Behavioral Evolution under Long-Term Deployment: New and consistent deployment patterns can differ from training observations yet remain within learned decision boundaries, so behavioral evolution does not necessarily degrade classification.This shows that maintenance requires more than simply correcting misclassifications.

C. Classifier Maintenance Using Fresh Traffic · V. CONFORMITY-BASED DRIFT DETECTION IN IOT TRAFFIC FEATURES · A. Drift As Seen in Raw Traffic Features

Exhaustive retraining with fresh deployment traffic can nearly eliminate classifier degradation, but practical maintenance requires identifying behavioral evolution under limited labeling resources. A conformity-based detector addresses this by modeling class-conditional patterns directly in raw traffic features, enabling interpretable detection of localized and heterogeneous drift.

C. Classifier Maintenance Using Fresh Traffic: Exhaustive labeling of each 7-day deployment window and cumulative retraining establishes an upper bound for maintaining classifier performance.All newly observed traffic is labeled, appended to the training dataset, and used to retrain the classifier before evaluation on the subsequent window.
C. Classifier Maintenance Using Fresh Traffic: Retraining on all newly labeled deployment traffic almost completely eliminates degradation and makes recall profiles persistent across device classes.The result shows that the classifier incorporates evolving behavioral patterns observed during deployment.
C. Classifier Maintenance Using Fresh Traffic: Exhaustive maintenance is operationally infeasible because network operators can label only a small fraction of deployment traffic.The resulting challenge is identifying evolving behaviors without relying on exhaustive labeling.
V. CONFORMITY-BASED DRIFT DETECTION IN IOT TRAFFIC FEATURES: The conformity-based detector operates directly on raw traffic features and models class-conditional behavioral patterns through feature-level non-conformity.Unlike approaches based on classifier confidence or learned embeddings, the detector captures behavioral evolution in the original feature space.
V. CONFORMITY-BASED DRIFT DETECTION IN IOT TRAFFIC FEATURES: The detector is decoupled from the classifier, using its predicted class only to select a behavioral model while performing detection entirely in the original feature space.This design provides the behavioral signal needed for practical classifier maintenance and enables feature-level explanations.
A. Drift As Seen in Raw Traffic Features: Deployment traffic can conform to learned behavior despite occupying only a subset of training feature values, so distributional differences alone do not establish drift.The Philips Hue Bridge example shows nearly perfect recall during the first deployment week while observations remain within previously learned behavioral patterns.
A. Drift As Seen in Raw Traffic Features: Drifted instances exhibit localized and heterogeneous non-conformity, with different subsets of traffic features deviating across instances and some changes not immediately affecting performance.Feature-level conformity is therefore an interpretable approximation rather than a complete description of behavioral evolution.

B. Drift Instance Detection · C. Modeling Feature Distributions

The detector identifies behavioral evolution by testing deployment features against predicted-class conformity regions. Feature distributions are modeled independently with KDE variants that preserve non-negative support and handle zero-valued or singular observations.

B. Drift Instance Detection: The instance-level detector compares each deployment feature with behavioral patterns learned for its predicted device class.An instance is behaviorally non-conforming when at least one feature falls outside its class-conditional conformity region.
B. Drift Instance Detection: For each device class and feature, the method estimates a probability density function and conformity threshold from recent labeled traffic.The classifier first predicts the device class, after which feature-level conformity determines whether the instance exhibits behavioral evolution.
C. Modeling Feature Distributions: Feature distributions are modeled independently with probability density functions estimated directly from training traffic.This design targets the heterogeneous and multi-modal variability of IoT traffic while representing each feature’s behavioral range.
C. Modeling Feature Distributions: Kernel Density Estimation requires selecting a valid kernel and handling zero-valued or degenerate observations.The bandwidth h controls smoothness in the KDE formulation.
C. Modeling Feature Distributions: Gaussian KDE can assign non-zero density to x < 0, violating the feasible range of non-negative traffic features.The paper illustrates this limitation with Apple Homepod averageInterarrivalTime flows and selects bandwidth h using Scott’s rule-of-thumb.
C. Modeling Feature Distributions: Log-normal KDE preserves non-negative support while modeling the observed behavioral range of traffic features.The resulting density is zero for X ≤0, and the paper uses Scott’s rule-of-thumb divided by 10 to reduce over-smoothing.
C. Modeling Feature Distributions: Zero-valued features are represented by a point mass at X = 0 combined with a continuous non-zero component when variability is sufficient.The continuous component uses LNKDE for non-zero observations.
C. Modeling Feature Distributions: Singular non-zero observations use a degenerate distribution, yielding 5 modeling scenarios based on zero values and singularities.Most distributions use either LNKDE alone or LNKDE combined with degeneracy at X = 0.

D. Constructing Feature Conformity Regions

The method constructs class-feature conformity regions by selecting density thresholds that bound the probability mass of non-conforming behavior. A user-defined sensitivity parameter controls this bound, while binning provides a practical threshold computation procedure.

Conformity-region definition: For every class-feature pair, the method defines a low-density non-conforming region to distinguish behavior consistent with training data from sufficiently uncommon behavioral evolution.The region is derived from the estimated feature density.
Threshold selection: Because feature ranges differ across device classes, θf,c is derived automatically from each distribution instead of using universal or manually specified thresholds.This avoids impractical per-feature, per-class threshold configuration as models are continuously updated.
Threshold selection: The threshold constrains the non-conformity probability mass to at most ϵ, which controls detector sensitivity and is the methodology’s only user-set hyperparameter.The same integral represents the probability of falsely flagging an instance drawn from the modeled density.
Threshold selection: The method selects the largest θf,c satisfying the probability constraint, avoiding the trivial θf,c = 0 solution that classifies every observation as conforming.The trivial solution would therefore fail to detect drift.
Threshold computation: A piecewise-constant density approximation bins feature values, sorts bin densities, accumulates probability mass until ϵ is exceeded, and chooses the largest admissible density.For degenerate distributions, θf,c = 0; degenerate components are conforming at their support while continuous components use the thresholding procedure.

E. Behavioral Non-conformity and Classifier Misclassification · F. Choice of ϵ · G. Feature-Level Explanations of Behavioral Evolution

The detector captures substantial misclassified traffic while behavioral evolution increasingly appears among correctly classified instances, reducing specificity over deployment. Setting ϵ balances detection sensitivity and false positives, while raw-feature analysis provides interpretable, instance-specific explanations of evolving behavior.

E. Behavioral Non-conformity and Classifier Misclassification: The detector captures a substantial fraction of misclassified traffic, although TPR varies across device classes and over time.Performance is summarized using mean TPR and specificity across weekly evaluation windows, with temporal standard deviations.
E. Behavioral Non-conformity and Classifier Misclassification: 0.71 average specificity over the first six deployment months shows that most correctly classified instances initially remain behaviorally conforming.Thirteen device classes exceed 0.8 specificity during this period.
E. Behavioral Non-conformity and Classifier Misclassification: As device behaviors evolve, more correctly classified instances exhibit previously unseen patterns that the detector identifies as behavioral non-conformity.These emerging patterns do not immediately cause misclassifications.
F. Choice of ϵ: The method evaluates ϵ values of 10−3, 10−2, and 10−1 across three orders of magnitude, with ϵ as its only hyper-parameter.The evaluation reports TPR, specificity, and balanced accuracy.
F. Choice of ϵ: Increasing ϵ raises the detection rate but increases false positives, especially for ϵ = 0.1; ϵ = 0.01 slightly outperforms in balanced accuracy.Different choices achieve similar balanced accuracy overall, and Appendix B examines sensitivity around ϵ = 0.01.
G. Feature-Level Explanations of Behavioral Evolution: Operating directly on raw traffic features provides feature-level explanations for every detected instance.Binary indicator vectors identify the features that deviate from the learned behavioral representation of the predicted device class.
G. Feature-Level Explanations of Behavioral Evolution: For the Wansview Q5, misclassification as Apple HomePod involves firstNonEmptyPacketSize and maxPacketSize, whereas Amazon Echo Dot involves reverseOctetTotalCount, dataByteCount, and reverseDataByteCount.The distinct feature subsets show that the same device can undergo different forms of behavioral evolution over time.
G. Feature-Level Explanations of Behavioral Evolution: Behavioral evolution is dynamic and instance-specific, with different deployment stages characterized by different subsets of non-conforming traffic features.The detector therefore supplies interpretable explanations directly in the original feature space.

VI. ADAPTING IOT TRAFFIC CLASSIFIERS TO CONCEPT DRIFT · A. Detector-Guided Adaptation

Detector-guided adaptation improves classification by labeling detector-identified deployment instances, but its retraining data can miss representative coverage of emerging traffic patterns. Across deployment windows, it achieves macro F1-score 0.917 while labeling 2.66% of instances, yet remains below upper-bound maintenance.

VI. ADAPTING IOT TRAFFIC CLASSIFIERS TO CONCEPT DRIFT: Limited deployment labeling requires determining how to exploit behavioral signals for long-term classifier maintenance.The study frames adaptation as selecting both which deployment instances to label and how much traffic to label.
A. Detector-Guided Adaptation: Detector-guided adaptation labels non-conforming instances in each test window, appends them to cumulative training data, and updates both detector and classifier.The classifier is a Random Forest with fixed training-phase hyperparameters, while detector thresholds use ϵ = 0.01.
A. Detector-Guided Adaptation: Detector-guided adaptation substantially outperforms no adaptation but remains consistently below upper-bound maintenance.Uniformly sampled deployment traffic at the same detector-guided labeling rate performs close to the upper bound.
A. Detector-Guided Adaptation: 0.917 average macro F1-score is achieved across deployment windows by labeling 2.66% of deployment instances overall.Per-window labeling cost is reported separately in Fig. 11b.
A. Detector-Guided Adaptation: The detector identifies substantial behavioral evolution, but detector-selected retraining data do not necessarily representatively cover newly emerging traffic patterns.This limitation explains why retraining on behaviorally non-conforming instances may fail to fully recover classifier performance.
A. Detector-Guided Adaptation: 0.446 F1-score from 0.938 in the preceding window marks a sharp drop for one class beginning 30 July 2022, followed by 0.389 F1-score in the subsequent window.The persistent degradation indicates a novel pattern emerging at the end of July that the detector did not adequately capture.

B. Uniform Traffic Sampling for Model Adaptation · C. Adaptation Under Operational Labeling Budgets

Uniform sampling captures emerging IoT behavior more broadly than detector-selected traffic, while drift-aware allocation of a fixed labeling budget preserves adaptation performance with fewer labels. The operational strategy scales labeling to observed behavioral evolution and updates the classifier and behavioral model using newly labeled examples.

B. Uniform Traffic Sampling for Model Adaptation: Detector-selected traffic concentrates on only some emerging behavioral patterns, leaving other newly formed regions unexplored and limiting adaptation.This systematic omission prevents retraining from adequately capturing behavioral diversity.
B. Uniform Traffic Sampling for Model Adaptation: Uniformly sampled deployment traffic provides substantially broader coverage of evolving behavior than detector-selected samples when using the detector’s labeling rate.The strategy separates sample selection from the drift detector’s role in determining labeling amount.
B. Uniform Traffic Sampling for Model Adaptation: Labeling at the detector’s flagged abundance in each deployment window ties the random-sampling rate to drift severity and supports repeated evaluation across 10 random seeds.Reported metrics use the average ± standard deviation across the 10 seeds.
B. Uniform Traffic Sampling for Model Adaptation: Detector-selected labeling declines rapidly over time as fewer instances appear behaviorally non-conforming, leaving emerging patterns unlabeled and excluded from adaptation.The unlabeled patterns are consequently incorporated into neither the classifier nor the behavioral model.
C. Adaptation Under Operational Labeling Budgets: The operational-budget evaluation uses a representative cap of 0.1% of deployment traffic per evaluation window.This fixed budget reflects the strict labeling limits typical of operational deployments.
C. Adaptation Under Operational Labeling Budgets: Full-budget uniform sampling maintains an average macro F1-score of 0.8970 ± 0.0042 across deployment, but fully consumes the available labeling budget.This serves as the reference operating point for evaluating lower-cost allocation strategies.
C. Adaptation Under Operational Labeling Budgets: Behavior-aware allocation scales each window’s labeling rate linearly to the running maximum fraction of behaviorally non-conforming instances.The classifier and behavioral model are updated before the next deployment window.

D. Comparison to Confidence-based Model Adaptation

Confidence-guided adaptation performs below full-budget uniform sampling and the behavior-aware strategy at a 0.1% labeling rate. Overall, confidence- and behavior-guided adaptation achieve comparable performance, but behavior-guided adaptation incurs slightly lower labeling cost and provides feature-level interpretability.

Direct confidence-based selection: 0.8845 average macro F1-score results from labeling the 0.1% lowest-confidence instances, below full-budget uniform sampling at 0.8970 and behavior-aware adaptation at 0.8934.The comparison uses deployment-phase average macro F1-score.
Direct confidence-based selection: 0.8905 average F1-score is achieved by stratified low-confidence sampling at a 0.123% labeling cost.The stratified procedure ensures every predicted class contributes at least one labeled instance when necessary.
Uniform sampling with adaptive labeling rate: Confidence-guided and behavior-guided sampling achieve comparable adaptation performance, while confidence guidance incurs a slightly higher labeling cost.The comparison is summarized across all adaptation strategies in Table IV.
Uniform sampling with adaptive labeling rate: Unlike classifier confidence, the behavioral signal identifies traffic features responsible for behavioral evolution while guiding the labeling rate.This provides feature-level interpretability in addition to adaptation guidance.

E. Goodness Properties of the Detector and its Maintenance Scheme

The detector maintenance scheme is evaluated for stability, consistency, and efficiency: preserving learned behavior, remaining robust to selective updates, and approximating full-data updates. Across deployment windows, the three metrics show strong performance, supporting incremental detector maintenance for long-term deployment.

Evaluation properties: Detector maintenance targets stability, consistency, and efficiency: preserving learned patterns, tolerating selective updates, and approximating updates using all labeled data.The evaluation applies three detector update strategies before processing adjacent deployment windows.
Stability: Stability requires that updating with newly observed data introduce no spurious detections relative to the frozen detector in subsequent windows.This property tests whether previously learned behavioral patterns are preserved.
Consistency: Consistency requires stability to hold when updates use only selected drifted instances instead of all labeled data.This isolates whether selective updates preserve the detector’s prior behavior.
Efficiency: Efficiency requires selected-instance updates to produce detection behavior similar to all-data updates while using significantly fewer labeled samples.The property indicates that selected instances adequately capture the underlying marginal distributions.
Results: η1 = 0.984±0.012, η2 = 0.971±0.017, and η3 = 0.953 ± 0.028 across deployment windows indicate preserved behavior, selective-update consistency, and close full-data approximation.Together, these results support the proposed detector maintenance strategy for long-term deployment.

VII. LIMITATIONS · VIII. CONCLUSION

The study identifies a limitation in modeling behavioral evolution through marginal traffic features, while concluding that long-term IoT classifier maintenance is feasible despite concept drift. It emphasizes that device behavior evolves differently across classes and motivates periodic maintenance with newly labeled deployment traffic.

VII. LIMITATIONS: The method may overlook behavioral changes occurring only in feature dependencies because it models marginal traffic features rather than their joint distribution.This choice improves computational and data efficiency by avoiding explicit joint-distribution modeling.
VII. LIMITATIONS: Marginal-feature modeling is computationally and data efficient, but it cannot capture evolutions that leave individual feature distributions unchanged.The limitation concerns dependencies among features rather than changes in their marginals.
VII. LIMITATIONS: The limitation is shared by input-based methods that avoid explicitly modeling high-dimensional joint feature distributions.The passage situates this constraint among methods discussed in §V.
VIII. CONCLUSION: Accurate IoT device identification from network traffic supports security monitoring and policy enforcement.The conclusion frames identification as operationally important for both functions.
VIII. CONCLUSION: Device behavior evolves over time, causing deployed classifiers to experience concept drift and require periodic maintenance with newly labeled deployment traffic.The conclusion presents maintenance as a response to temporal behavioral evolution.
VIII. CONCLUSION: Behavioral evolution manifests differently across IoT device classes, yet effective long-term classifier maintenance is feasible.These findings are stated as the study’s initial conclusion before introducing its conformity-based detector.

APPENDIX … 1) Indicator Weights:

The appendix characterizes KDE distribution-modeling cases, examines detector sensitivity to ϵ, and finds that indicator weights alone cannot reliably distinguish true from false detections.

A. Distribution Modeling Cases: The KDE appendix categorizes five possible feature-distribution modeling cases by their prevalence across class-feature pairs in training data.During detection, degenerate components are treated as perfectly conforming at their support point.
A. Distribution Modeling Cases: 181 cases use only an LNKDE component when no training observation exists at X = 0 and the dataset is not singular.At test-time, the PDF is manually evaluated as 0 when X = 0 because the logarithm is undefined there.
A. Distribution Modeling Cases: 4 cases use only one degenerate component at x0 > 0 when the training data is singular at x0.During detection, the PDF is evaluated as infinity at X = x0 and 0 elsewhere.
B. Sensitivity Analysis for ϵ: ϵ = 0.01 is used throughout the experiments, and detector performance shows relatively low sensitivity to nearby ϵ values.Once ϵ is selected at the appropriate order of magnitude, such as 10^-2, further fine-tuning has little impact on detector performance.
1) Indicator Weights:: The indicator weights of true and false detections show no consistent separation and substantial temporal variation across device classes.The analysis compares the number of non-conforming features contributing to each detection’s explanation.
1) Indicator Weights:: The number of non-conforming features alone is insufficient to distinguish true detections from false ones.The entropy trace demonstrates higher ambiguity in the indicators for false positives than true positives.

2) Diversity of Feature-Level Explanations: … F. Measures of Detector Goodness for Adaptation

Feature-level explanations remain structured over deployment, with true behavioral evolution showing lower diversity than false detections. Detector-guided and confidence-guided adaptation achieve comparable temporal performance, while detector goodness is assessed through stability, consistency, and efficiency.

2) Diversity of Feature-Level Explanations:: True detections consistently have lower explanation entropy than false detections, indicating more structured and repeatable behavioral evolution.Entropy is computed from indicator bit strings within fortnightly windows for each device class.
2) Diversity of Feature-Level Explanations:: Indicator-weight and entropy analyses show that feature-level explanations remain structured across deployment.These analyses support the detector’s ability to provide meaningful and interpretable explanations of behavioral evolution.
E. Performance of the Confidence-based Methods Over Time: Behavior-aware and confidence-guided sampling achieve comparable classification performance throughout deployment and generally outperform two confidence-based instance-selection approaches.The comparison is presented in Fig. 15 alongside the two confidence-based baselines discussed in §VI-D.
D. Formal Description of Detector-guided Adaptation: Algorithm 3 provides the formal description of detector-guided adaptation.The scheme is discussed in §VI-A.
F. Measures of Detector Goodness for Adaptation: Three detector-update strategies assess the behavioral signal for adaptation, with values close to one indicating preservation of all-traffic update behavior.The evaluation covers stability, consistency, and efficiency over the deployment period.
F. Measures of Detector Goodness for Adaptation: Detector goodness is evaluated using stability (η1), consistency (η2), and efficiency (η3) over continuously generated detection results.The classifier model M is fitted on training data and kept fixed throughout the evaluation.