A Secure Cross-Domain Control Mechanism for Stateful Digital Twin Migration in Edge Computing

Abstract

Mobility-aware digital twin (DT) migration is increasingly used in edge computing to sustain low-latency service as physical entities and service demand move across domains. However, stateful DT migration across administrative domains requires more than placement adaptation; it also requires target-side legitimacy verification, protected-state transfer, continuity-preserving traffic transition, and invalidation of stale source-side instances. This paper presents a secure cross-domain authentication and service continuity mechanism for mobility-aware DT migration in edge computing. The proposed design formulates migration as a six-phase ordered control procedure comprising migration triggering, target-side authorization, protected-state transfer, continuity-aware traffic transition, post-migration activation, and revocation-aware completion. Security analysis examines authorization soundness, migration-state confidentiality and integrity, transition safety, and post-migration uniqueness. Performance evaluation shows that the full mechanism introduces only a bounded increase in migration-related cost while reducing service interruption at 500 MB from approximately 1.79 s without continuity-aware transition control to 285 ms in the full mechanism. The results indicate that the proposed mechanism preserves the operational benefit of mobility-aware DT migration while strengthening migration authorization, state transfer protection, and service continuity under cross-domain relocation.

1. Introduction

Digital twin (DT) services are increasingly deployed in edge computing to support low-latency monitoring, synchronization, and control for mobile IoT entities [1,2]. In such environments, the quality of DT service depends not only on computation and network resources but also on where the DT is hosted relative to the associated physical entity and active service users [3,4]. As mobility and demand evolve over time, a DT hosted in one edge domain may no longer remain an efficient service point. Mobility-aware DT migration is therefore an important mechanism for sustaining service quality in distributed edge systems [5,6].

For stateful DT services, however, migration is not merely a placement update. A migrated DT carries historical data, runtime context, and the permission-relevant state that must remain valid across domains. Once migration crosses administrative or service boundaries, the problem becomes a cross-domain control procedure involving target-side legitimacy verification, protected state relocation, continuity-preserving traffic transition, and invalidation of stale source-side instances [7,8]. If these requirements are not coordinated correctly, unauthorized DT instances may be admitted by the target domain, the migration state may be exposed or modified during transfer, traffic may be redirected before target-side restoration is complete, and stale source-side execution or authorization context may remain active after migration [9,10,11].

Existing research relevant to this problem spans several adjacent but technically distinct directions, including mobility-aware DT migration, service continuity under stateful edge-service transition, cross-domain authentication and secure inter-domain interaction, lightweight cryptography and hardware-aware edge security, and revocation-aware authentication in DT and twin systems. These directions are reviewed in Section 2, where the directly relevant studies are grouped by technical role rather than cited as an undifferentiated list. However, they do not directly formulate stateful cross-domain DT migration as a lifecycle-complete control problem in which later migration stages become valid only after specific earlier admission, transfer, readiness, activation, and invalidation conditions have been satisfied.

Accordingly, the problem addressed in this paper is not the optimization question of when or where to migrate a DT, nor the standalone design of a new cryptographic access protocol, nor general service continuity for segmented MEC applications. Instead, we study how a stateful DT migration should be controlled once migration is required so that cross-domain admission, migration-state handling, transition continuity, activation readiness, and source-side invalidation are coordinated without leaving security or service gaps. In this paper, we propose a six-phase secure cross-domain authentication and service continuity mechanism for mobility-aware DT migration in edge computing. The novelty does not lie in introducing authorization, protected transfer, buffering, activation checking, or revocation as isolated functions, each of which has appeared in adjacent forms in the prior literature. Rather, it lies in formulating cross-domain stateful DT migration as a dependency-constrained lifecycle control problem in which (i) target-side admission must precede any valid state export, (ii) protected state acceptance must precede restoration-ready transition, (iii) restoration readiness must precede live traffic release, (iv) formal target-side activation must remain scope- and uniqueness-valid, and (v) migration is not treated as complete until stale source-side execution and authorization state have been invalidated.

The main contributions of this paper are as follows:

• We formulate stateful digital twin migration across edge domains as a secure migration lifecycle control problem, in which target admission, protected state relocation, continuity-preserving transition, formal activation, and stale instance invalidation must be enforced in a coordinated order.
• We propose a six-phase secure migration mechanism covering migration triggering, target domain authorization, protected state packaging and transfer, readiness-gated traffic transition, target-side activation, and revocation-aware completion.
• We specify the inter-phase control dependencies that make migration completion conditional rather than procedural: admission-valid migration must precede any legitimate state export, restoration readiness must precede live traffic release, formal activation must remain scope- and uniqueness-valid, and migration is not considered complete until stale source-side execution and authorization state have been invalidated.
• We analyze the mechanism with respect to authorization soundness, migration-state confidentiality and integrity, transition safety, post-migration uniqueness, and resistance to common protocol-level attacks.
• We evaluate the mechanism using external authorization path comparison against recent cross-domain authentication schemes, repeated matched-run statistical analysis, mobility model sensitivity checking, implementation-backed control-path validation, and staged ablation of the main migration control functions.

The results show that the proposed mechanism preserves the operational benefit of mobility-aware DT migration while introducing bounded security and continuity overhead, substantially reducing transition disruption, and enforcing more reliable post-migration completion for cross-domain stateful DT operation.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 presents the system model, threat model, and design goals. Section 4 describes the proposed secure cross-domain authentication and service continuity mechanism. Section 5 provides the security analysis. Section 6 presents the performance evaluation. Section 7 concludes this paper.

2. Related Works

The problem addressed in this paper builds on two established research foundations: edge/fog computing as a distributed service paradigm and security analysis for systems operating across heterogeneous administrative and resource domains. Foundational edge computing studies have shown that moving computation and storage closer to users, devices, and data sources can reduce latency and bandwidth pressure while introducing coordination issues related to mobility, locality, service management, and privacy-sensitive edge data processing [12,13]. Fog computing surveys further characterize edge-side resource provisioning, multi-tier architectures, application placement, mobility support, federation, and interoperability as central design challenges for distributed edge systems [14]. Security analysis of mobile-edge, fog, and related edge paradigms further shows that distributed trust, heterogeneous ownership, mobility, virtualization, and resource constraints create threats that differ from conventional centralized cloud settings [15]. These observations motivate the present focus on stateful DT migration across edge domains, where service relocation must be coordinated with target-side admission, protected-state transfer, transition continuity, and stale state invalidation.

Existing research relevant to the problem addressed in this paper spans several adjacent but technically distinct directions. For clarity, we organize the literature into five categories: mobility-aware DT migration, service continuity under stateful edge-service transition, cross-domain authentication and secure inter-domain interaction, lightweight cryptography and hardware-aware edge security, and revocation-aware authentication in DT and twin systems.

2.1. Mobility-Aware Digital Twin Migration

Research on mobility-aware DT migration has primarily focused on how DT placement or migration should adapt to the movement of physical entities and to variations in edge resource availability. In the literature, the main objective is typically to sustain service responsiveness by determining when and where a DT should be relocated under latency, cost, freshness, or resource constraints. Zhang et al. studied mobility-aware DT migration in edge computing by jointly considering supplier and consumer mobility together with synchronization, migration, and service costs [16]. Chen et al. examined DT model migration in vehicular edge computing from an age-of-information perspective and emphasized dual-timescale coordination between model migration and data upload [17]. Yang et al. investigated adaptive DT migration in Internet-of-Electric-Vehicles environments by jointly accounting for sensing, communication, and computation resources during mobility-driven migration [18]. Xing et al. further considered fine-grained model-level migration in intelligent transportation systems, arguing that vehicle-level twins need not always be migrated as indivisible entities and proposing sub-model-level migration instead [19]. Ma et al. also studied adaptive DT migration in ISAC-assisted edge intelligence, where DTs are dynamically migrated across edge servers under mobility and resource variation to sustain service quality [20].

Taken together, these studies establish mobility-aware DT migration as an active direction centered on migration optimization, placement adaptation, information freshness, and migration granularity. However, they do not address the problem considered here, namely, how a stateful DT migration should be securely controlled once migration is required across administrative domains, such that admission validation, protected state relocation, transition continuity, activation readiness, and post-migration stale instance invalidation are enforced within one ordered procedure.

2.2. Service Continuity Under Stateful Edge-Service Transition

A second related direction concerns service continuity during stateful edge-service transitions. This body of work is concerned with preserving ongoing service delivery when an executing service or service component must be relocated, restored, or reconfigured across edge nodes. Typical concerns include migration downtime, continuity of service–user interaction, buffering during transition, routing or session reconfiguration, and restoration of execution state. Trung et al. studied service continuity for stateful segmented services in MEC and introduced coordinated session-modification procedures, pipeline-level metric aggregation, and SRv6-based buffering to preserve end-to-end continuity across sequential and parallel service pipelines [21]. Calagna et al. proposed an orchestration framework for stateful microservice migration at the edge, explicitly targeting migration disruption and preservation of the service–user connection while meeting network and application KPI targets [22]. Chu et al. examined live service migration in MEC over 5G through a software-defined migration framework integrating QUIC and SDN, with emphasis on continuity and recovery under dynamic mobile conditions [23]. Chen et al. investigated mobility-aware seamless service migration and resource allocation in multi-edge IoV systems to maintain uninterrupted and high-quality services under vehicle mobility [24]. Hua et al. further addressed seamless service migration in IoV edge computing through a dirty-page filtering and compression technique aimed at reducing transfer volume, migration latency, and service interruption duration [25].

These studies address important continuity issues during migration or transition of stateful edge services. Their technical emphasis, however, remains on service migration optimization, continuity-oriented orchestration, transport or session recovery, and migration efficiency improvement. They do not formulate the problem addressed in this paper, namely, secure control of stateful DT migration across domains, in which admission validation, protected state relocation, continuity-preserving traffic transition, activation readiness, and source-side stale instance invalidation must be coordinated within a single ordered workflow.

2.3. Cross-Domain Authentication and Secure Inter-Domain Interaction

Cross-domain authentication research investigates how entities belonging to different administrative or trust domains can establish legitimacy, preserve privacy, and securely exchange information without incurring excessive coordination or exposing the system to impersonation and replay risks. In edge- and IIoT-oriented environments, this problem is particularly important because inter-domain interaction often occurs among heterogeneous devices, servers, and management authorities under strict latency and resource constraints.

One stream of the literature studies cross-domain authentication together with protected inter-domain data exchange in industrial edge systems. Chen et al. considered IIoT under a cloud-fog automation architecture and proposed a consortium blockchain-based framework that jointly addresses cross-domain authentication and secure data sharing across domains with different cryptographic settings [26]. Chen et al. also studied blockchain-assisted cross-domain data transmission in IIoT with edge cloud computing, combining inter-domain trust establishment, authentication, and lightweight data-exchange support [27]. A second stream emphasizes lightweight or distributed cross-domain authentication to reduce dependence on centralized authorities and improve efficiency under resource constraints. Wu et al. proposed LRCDA for IIoT, where distributed edge nodes collaboratively generate reusable authentication signatures so that repeated cross-domain authentication overhead can be reduced over a validity period [28]. Liu et al. addressed vehicular networks under MEC and proposed a cross-domain authentication scheme that offloads computation to edge servers, separates authentication and computing functions, and supports anonymity and batch verification [29]. A third stream extends cross-domain authentication into emerging service-oriented edge-intelligence settings. Meng et al. proposed a cross-domain inference authentication protocol for edge inference-based pretrained foundation models, where the authentication burden of mobile devices is reduced through assistance from domain servers and distributed edge-side support [30].

Overall, the literature addresses credential generation, anonymous verification, inter-domain trust establishment, and secure data or inference exchange. Nevertheless, its focus remains on secure inter-domain legitimacy and interaction rather than on migration control. In particular, these studies do not specify how a stateful DT should be controlled once migration is triggered across administrative domains, such that admission validation, protected state relocation, transition continuity, activation readiness, and post-migration stale instance invalidation are enforced within one ordered migration procedure.

2.4. Lightweight Cryptography and Hardware-Aware Edge Security

A further related direction concerns lightweight cryptography and hardware-aware security implementation for constrained IoT and edge devices. This direction is relevant because cross-domain DT migration requires repeated authorization checks, protected-state transfer, integrity verification, and revocation-related control messages, all of which must remain practical under limited computation, memory, energy, and communication resources. Dobraunig et al. specified Ascon-128 and Ascon-128a as lightweight authenticated encryption algorithms and further described Ascon-Hash and Ascon-Xof, emphasizing that the same lightweight permutation can support authenticated encryption and hashing while remaining efficient on both constrained devices and high-end processors [31]. Their analysis also highlights the importance of software and hardware efficiency, low implementation footprint, and implementation robustness for lightweight authenticated encryption.

Recent hardware-oriented studies further show that the practical suitability of lightweight cryptographic primitives depends on implementation architecture, not only on the abstract algorithm. Khan et al. implemented Ascon using ASIC-oriented loop-folded, loop-unrolled, and fully unrolled architectures and reported explicit area–throughput trade-offs for Ascon-128 and Ascon-128a [32]. Their results show that fully unrolled designs can improve throughput at the cost of a substantially higher area, whereas lower-unrolling implementations reduce area consumption and are more suitable for constrained IoT nodes. More broadly, Zhong and Gu reviewed lightweight block ciphers for resource-constrained environments and evaluated software and hardware implementations using security, resource, and performance criteria [33]. Their survey reinforces that lightweight security design must balance cryptographic strength with latency, memory, hardware area, energy consumption, and implementation platform constraints.

These works provide the implementation context for lightweight cryptographic support in constrained edge devices. However, their focus is cipher design, hardware realization, and software/hardware implementation trade-offs, whereas the present paper focuses on the lifecycle control logic of stateful cross-domain DT migration. In the proposed mechanism, the evaluated artifact model uses the concrete primitives specified later in Section 4, Section 5 and Section 6. The lightweight cipher literature is therefore used to motivate practical deployment constraints for edge security, not to claim a new cipher design or to report Ascon-based measurements.

2.5. Revocation-Aware Authentication in DT and Twin Systems

A fifth related direction concerns revocation-aware authentication and trust control in DT and twin-based systems. In such environments, authentication alone is insufficient if compromised, malicious, or stale virtual participants can continue to access services or influence decision processes after trust has degraded. Recent studies therefore increasingly incorporate explicit revocation, traceability, or dynamic trust enforcement into DT-oriented security mechanisms.

A first group of studies focuses on revocable authentication of DT or twin entities in cross-domain environments. Li et al. proposed SRAA for cross-domain vehicular twin networks, where authorized twins perform secure access authentication and key agreement, while malicious twin nodes can be dynamically revoked to prevent further participation in inter-twin communication [34]. Xia et al. similarly studied efficient cross-domain authentication for dynamic DTs in wireless IIoT and combined pseudonym-based authentication, conditional traceability, and distributed trust management to support secure inter-domain DT interaction under heterogeneous domains [35]. A second group considers finer-grained revocation within DT-enabled data-collection settings. Wang et al. proposed a dual fine-grained authentication scheme for transportation DT systems that supports fine-grained access control, key puncturing, non-interactive attribute updating, and revocation of malicious physical entities without relying on an additional trusted authority [36]. Broader trust-governance and federated learning provenance studies are not included in

Table 1. Comparison of related studies with respect to component coverage and lifecycle-complete ordered enforcement for cross-domain stateful DT migration.

Study	Mobility-Aware Migration	Cross-Domain Authorization	Protected-State Transfer	Continuity-Aware Transition	Formal Activation Control	Revocation/ Invalidation	Lifecycle-Complete Ordered Enforcement
Zhang et al. [16]	Y	N	N	N	N	N	N
Chen et al. [17]	Y	N	N	N	N	N	N
Yang et al. [18]	Y	N	N	N	N	N	N
Xing et al. [19]	Y	N	P	N	N	N	N
Ma et al. [20]	Y	N	N	N	N	N	N
Trung et al. [21]	P	N	P	Y	P	N	N
Calagna et al. [22]	P	N	P	Y	P	N	N
Chu et al. [23]	P	N	P	Y	P	N	N
Chen et al. [24]	Y	N	P	Y	P	N	N
Hua et al. [25]	P	N	P	Y	N	N	N
Chen et al. [26]	N	Y	P	N	N	N	N
Chen et al. [27]	N	Y	P	N	N	N	N
Wu et al. [28]	N	Y	N	N	N	N	N
Liu et al. [29]	N	Y	N	N	N	N	N
Meng et al. [30]	N	Y	N	N	N	N	N
Li et al. [34]	N	Y	N	N	N	Y	N
Xia et al. [35]	N	Y	N	N	N	Y	N
Wang et al. [36]	N	Y	N	N	N	Y	N
Proposed lifecycle control mechanism	Y	Y	Y	Y	Y	Y	Y

Y: Explicitly supported; P: partially addressed; N: not addressed as a main mechanism component.

unless they directly address authentication, revocation, or lifecycle control of DT/twin entities. This restriction keeps the comparison focused on mechanism-level relevance rather than expanding the bibliography with loosely related recent work.

Table 1 compares related studies in terms of mobility-aware migration, cross-domain authorization, protected-state transfer, continuity-aware transition, formal activation, and revocation-aware completion. In this sense, the proposed mechanism should not be read as a checklist aggregation of known functions. Its central contribution is the explicit control logic that determines when those functions become valid and when migration can be treated as complete. A scheme may support migration without secure admission, secure transfer without continuity-safe release, or service resumption without post-migration exclusivity. The proposed mechanism differs by making these stages conditionally dependent and by treating stale source invalidation as part of migration completion rather than as optional cleanup.

These studies confirm that revocation-aware security is becoming an important concern in DT and twin systems. However, taken together with the other categories in Table 1, the literature still remains component-fragmented with respect to the problem studied here. Some works address mobility-aware migration but not cross-domain admission control; some address continuity during stateful service transition but not target-side legitimacy or post-migration invalidation; and others address cross-domain authentication or revocation-aware twin control without treating stateful migration itself as a completion-critical control procedure. The point of distinction in this paper is therefore not that each individual function is entirely unprecedented, but that cross-domain stateful DT migration is formulated as a lifecycle-complete ordered enforcement problem in which admission, protected relocation, readiness-gated service transfer, formal activation, and stale source invalidation are mutually dependent stages of one migration-complete procedure.

3. System Model, Threat Model, and Design Goals

We consider a multi-domain edge environment in which a stateful DT may migrate from its current hosting domain to another domain as the associated physical object moves, user demand shifts, or the current hosting domain becomes resource-inefficient. In this setting, migration is not merely a placement update. Because the DT carries historical data, runtime context, and service-relevant access state, cross-domain relocation must be treated as a controlled state-transition process involving migration decision, target-side authorization, protected-state transfer, continuity-aware traffic handling, and stale instance invalidation. This section specifies the corresponding system model, threat model, and design goals.

Figure 1 illustrates the considered multi-domain edge environment, the main migration control entities, and the exposed inter-domain threat surface. A stateful DT is hosted initially in a source domain and may migrate to a target domain as the associated physical object moves and active user demand shifts. Migration is coordinated by the migration orchestrator, the continuity controller, and the revocation manager, which govern migration decision, transition control, and source-side invalidation, respectively. The figure also highlights the exposed inter-domain control path over which replay or stale credential reuse, transfer path tampering, and premature forwarding attempts may arise.

Let $\mathcal{D}=\{D_1,D_2,\dots ,D_{\left|\mathcal{D}\right|}\}$ denote the set of edge domains. Each domain $D_j\in \mathcal{D}$ represents an administrative service domain with its own hosting resources, local access-control policy, and DT management authority. The term cross-domain therefore refers to migration across distinct administrative domains rather than migration among homogeneous nodes under a single global controller.

3.1. System Model

A.

Edge-Domain Environment

Each domain $D_j$ is characterized by the resource state ${\mathcal{R}}_j\left(t\right)=(R_j^{\mathrm{cpu}}\left(t\right),R_j^{\mathrm{mem}}\left(t\right),R_j^{\mathrm{stor}}\left(t\right),$$R_j^{\mathrm{net}}\left(t\right))$, where the four components denote available computing, memory, storage, and communication resources at time t. Inter-domain connectivity is represented by the graph $G=(\mathcal{D},\mathcal{L})$, where $\mathcal{L}$ is the set of communication links among domains, and $d(D_a,D_b)$ denotes the communication distance, latency, or transfer cost between domains $D_a$ and $D_b$.

To make the communication resource model less abstract, we distinguish nominal link capacity from effective migration goodput. For an inter-domain link $(D_a,D_b)\in \mathcal{L}$, let $B_{a,b}^{\mathrm{raw}}\left(t\right)$ denote the nominal available bandwidth, ${\upsilon }_{a,b}\left(t\right)\in (0,1]$ the residual bandwidth share after background traffic, ${\theta }_{a,b}^{\mathrm{oh}}\left(t\right)\in [0,1)$ the protocol–overhead ratio induced by the link layer, IP, transport, secure channel, and migration control headers, and ${\rho }_{a,b}^{\mathrm{retx}}\left(t\right)\ge 0$ the retransmission or congestion penalty. The effective migration goodput is modeled as

$$B_{a,b}^{\mathrm{eff}}\left(t\right)={\displaystyle \frac{B_{a,b}^{\mathrm{raw}}\left(t\right){\upsilon }_{a,b}\left(t\right)\left(1-{\theta }_{a,b}^{\mathrm{oh}}\left(t\right)\right)}{1+{\rho }_{a,b}^{\mathrm{retx}}\left(t\right)}}.$$

(1)

For a DT migration from $D_a$ to $D_b$, the transfer-stage transmission burden is therefore not determined by DT state size alone. Let ${\mathrm{\Omega }}_i^{\mathrm{ctrl}}$ denote the migration control byte overhead associated with credentials, authorization tokens, protected-transfer metadata, and revocation-related control artifacts. The effective transmission time for the protected migration state is modeled as

$$T_{i,a,b}^{\mathrm{tx}}\left(t\right)=L_{a,b}^{\mathrm{base}}\left(t\right)+{\displaystyle \frac{8\left({\mathrm{\Phi }}_i\left(t\right)+{\mathrm{\Omega }}_i^{\mathrm{ctrl}}\right)}{B_{a,b}^{\mathrm{eff}}\left(t\right)}}+q_{a,b}\left(t\right),$$

(2)

where $L_{a,b}^{\mathrm{base}}\left(t\right)$ is the baseline propagation and processing delay and $q_{a,b}\left(t\right)$ is the queueing delay caused by transient link contention. Thus, the model accounts for dynamic bandwidth variation, protocol stack overhead, retransmission or congestion effects, and queueing delay when estimating migration-state transfer feasibility and cost.

B.

Physical Entities, Users, and Digital Twins

Let $\mathcal{O}=\{o_1,o_2,\dots ,o_{\left|\mathcal{O}\right|}\}$ denote the set of physical entities and $\mathcal{U}=\{u_1,u_2,\dots ,u_{\left|\mathcal{U}\right|}\}$ the set of service users. Each entity $o_i$ is associated with a stateful DT and instance ${\mathrm{DT}}_i$, and ${\mathcal{U}}_i\left(t\right)\subseteq \mathcal{U}$ denotes the active users served by ${\mathrm{DT}}_i$ at time t. The physical entity’s location, user location, and current DT hosting domain are denoted by $L_i^o\left(t\right)$, $L_k^u\left(t\right)$, and $Lo{c}_i\left(t\right)\in \mathcal{D}$, respectively. The resource demand of ${\mathrm{DT}}_i$ is denoted by ${\chi }_i=({\chi }_i^{\mathrm{cpu}},{\chi }_i^{\mathrm{mem}},{\chi }_i^{\mathrm{stor}})$, reflecting that migration involves both instance relocation and continued service execution after state restoration.

C.

Control Functions

To support secure migration across administrative domains, the system includes four abstract control functions:

• A migration orchestrator, which determines whether migration is needed and selects a feasible target domain;
• Source and target domain authorization entities, which validate DT legitimacy, migration admissibility, and accepted service scope;
• A continuity controller, which manages request buffering and forwarding transition during the migration interval;
• A revocation manager, which invalidates stale, duplicated, unauthorized, or otherwise invalid DT instances and associated authorization artifacts after migration completion.

These functions are defined here at the system level to separate four logically distinct tasks: migration decision, cross-domain admission control, continuity-preserving traffic transition, and post-migration invalidation. Their detailed operations are specified in Section 4.

These control functions are specified as logical roles rather than as a fixed deployment architecture. In a centralized edge-federation deployment, they may be implemented by a federation-level migration controller that coordinates source and target domains. In a federated deployment, each domain may retain its own authorization and revocation service while exchanging signed migration and revocation records with peer domains. In a domain-local deployment, the source and target domains may execute the control steps through their local management planes using authenticated inter-domain messages. The security analysis assumes that regardless of deployment form, these control functions execute the specified protocol correctly, authenticate their control messages, and protect their long-term secret material; compromise of these trusted functions remains outside the stated threat model.

3.2. Threat Model

We consider an adversarial environment appropriate for stateful DT migration across public or semi-open inter-domain networks. The threat focus of this paper is the migration control process itself rather than general attacks on all layers of the underlying IoT or edge infrastructure.

A.

Adversary Capabilities

The adversary is assumed to be able to act on inter-domain communication paths and migration control exchanges. In particular, the adversary may:

• Observe, intercept, replay, delay, reorder, and modify messages transmitted over inter-domain channels;
• Attempt unauthorized migration by impersonating a legitimate DT or by reusing stale migration authorization material;
• Attempt to disclose, manipulate, or replay migration-state content during transfer;
• Exploit incomplete migration completion to preserve a stale or duplicate DT execution context;
• Induce premature traffic forwarding to a target-side DT that has received a state but is not yet restoration-ready.

Accordingly, the threat model covers external message manipulation, stale credential reuse, invalid migration attempts, and transition-phase abuse targeting the DT migration lifecycle.

B.

Trust Assumptions

The migration orchestrator, continuity controller, and revocation manager are assumed to be trusted protocol participants for the purpose of migration control enforcement. Source and target domain authorization entities are likewise assumed to execute the protocol correctly, to protect their long-term secret material, and to enforce their local policy logic as specified. However, the communication channels among these entities are not assumed secure by default and must therefore be protected by the proposed mechanism.

This paper therefore analyzes security under an honest-but-targeted control-plane trust model: the main concern is adversarial action on inter-domain migration control exchanges, stale credential reuse, transfer path tampering, replay, and transition-phase abuse. By contrast, insider compromise of trusted migration control entities, key exfiltration from those entities, and side-channel leakage from the underlying hardware or runtime platform are outside the present scope and are treated as limitations of the current model rather than as threats explicitly resolved here.

The model also assumes that long-term DT identity information should not be unnecessarily exposed across domains. Hence, cross-domain migration control should rely on the minimum identity disclosure needed for valid authorization and migration-state acceptance.

C.

Attacks Considered and Out of Scope

Under the above assumptions, the proposed mechanism is designed to resist impersonation, replay, tampering, unauthorized migration acceptance, stale credential reuse, insecure migration state disclosure, duplicate twin persistence, and premature forwarding to an unready migrated DT.

The following are outside the scope of this paper:

• Physical compromise of the associated IoT object or sensor platform;
• Infrastructure-scale denial-of-service attacks against the underlying edge system;
• Insider compromise of trusted migration control entities, including theft of long-term secret material or malicious policy override by those entities;
• Side-channel leakage from the underlying hardware, virtualization layer, or cryptographic implementation;
• Lower-layer radio, sensing, or device-level spoofing attacks unrelated to migration control.

These exclusions are made because the objective of this paper is to secure and coordinate the DT migration control path itself under the stated control-plane trust model rather than to solve all security problems of the surrounding IoT-edge environment or to provide implementation-level side-channel hardening.

3.3. Design Goals

Based on the above system and threat models, the proposed mechanism is designed to satisfy the following goals.

1. Cross-Domain DT Legitimacy and Authorization: A target domain should accept a migration request only if the incoming DT is currently legitimate, non-revoked, and admissible under the target domain authorization policy.

2. Secure and Scope-Bounded Migration-State Transfer: DT state should be exported and transferred only after successful target-side authorization, and the transferred state should preserve confidentiality, integrity, freshness, and target-scope validity during migration.

3. Continuity-Preserving Transition: During migration, incoming service requests should not be prematurely forwarded to the target-side DT before restoration readiness is achieved, and requests should be retained under controlled transition handling rather than being dropped or misrouted.

4. Valid Post-Migration Activation: The migrated DT should resume service only after target-side authorization remains valid, the imported state has been restored successfully, and the DT operates within the accepted target-side access scope.

5. Unique Active Instance and Revocation: After migration completion, the target-side DT should become the unique active service instance, while stale, duplicated, unauthorized, or compromised DT instances and their related authorization artifacts should be invalidated.

6. Resistance to Protocol-Level Attacks: The overall migration procedure should resist protocol-level attacks arising from the stated threat model, including impersonation, replay, tampering, stale credential reuse, and unauthorized cross-domain migration attempts.

In summary, the considered system is a multi-domain edge environment in which DT migration depends jointly on mobility, hosting feasibility, cross-domain authorization, state transfer protection, and continuity-preserving transition control. The threat model captures adversaries that exploit open inter-domain communication, stale authorization state, and migration-phase timing gaps. The above goals define the security and service continuity requirements that the proposed mechanism must satisfy.

4. Proposed Secure Cross-Domain Authentication and Service Continuity Mechanism

The proposed mechanism treats stateful DT relocation as an ordered migration control problem rather than as a simple placement update. In particular, migration is not regarded as complete when the state is merely transferred from one domain to another. Instead, completion requires that target-side admission, authorization-bounded state export, protected state import and restoration, continuity-safe service transfer, formal target-side activation, and source-side stale instance invalidation be satisfied in sequence. The following discussion specifies how these control dependencies are enforced once migration becomes necessary so that cross-domain relocation can proceed without unauthorized activation, insecure intermediate state use, or unsafe transition behavior.

4.1. Mechanism Overview

Figure 2 provides a high-level workflow view of the proposed six-phase migration control procedure. Phases I–III establish migration triggering, admission, and protected state relocation, whereas Phases IV–VI govern continuity-safe transition, formal target-side activation, and revocation-aware completion. This figure therefore summarizes the ordered control logic by which cross-domain DT migration is converted from a candidate relocation event into a valid and uniquely completed target-side service state.

Consider a DT ${\mathrm{DT}}_i$ migrating from source domain $D_s$ to target domain $D_t$. The migration procedure is coordinated by the four control functions introduced in Section 3: a migration orchestrator, source and target domain authorization entities, a continuity controller, and a revocation manager. Their joint role is not merely to move the DT state across domains, but to regulate when migration is allowed to begin, when the state may be exported and accepted, when service responsibility may shift to the target side, and when obsolete source-side execution and authorization state must be invalidated.

Table 2. Control logic of the proposed six-phase migration procedure.

Phase	Primary Role	Key Condition	Failure Consequence
Phase I	Trigger migration and select a feasible target domain	Migration benefit/resource trigger holds and at least one feasible target exists	Migration is not initiated
Phase II	Validate cross-domain admissibility	Source credential is valid, fresh, scope-compliant, and non-revoked under target policy	Migration request is rejected before state export
Phase III	Protect and transfer migration state	Export and import authorization both hold; protected package is valid, fresh, and scope-consistent	State transfer is rejected and restoration does not begin
Phase IV	Preserve continuity during transition	Target-side restoration is incomplete, so traffic remains buffered until readiness holds	Requests remain under controlled transition and are not released prematurely
Phase V	Declare formal target-side service resumption	Authorization remains valid, service state is active, scope remains valid, and no conflicting active instance exists	Target-side DT remains provisional and service resumption is not declared
Phase VI	Complete migration by invalidating stale source-side state	Successful target-side resumption and uniqueness have been established	Migration is not treated as fully complete

summarizes the control logic of the six-phase migration procedure.

At a high level, the proposed mechanism tracks four control questions during migration: whether the target domain has accepted the incoming DT under a valid authorization context, whether the migration state has been protected and restored successfully, whether traffic release is safe, and whether stale source-side execution and authorization artifacts have been invalidated. For readability, we avoid introducing an additional global state tuple at this stage and instead use phase-specific variables only where they are required by the mechanism logic and later security discussion. In this paper, successful migration therefore means not merely that DT state has been moved to another domain, but that the target-side DT becomes the only valid active service instance after authorization, protected state relocation, readiness-gated traffic release, formal activation, and source-side invalidation.

The key design principle is strict phase ordering. Target domain authorization must precede state transfer and activation, state restoration must precede traffic release, and stale instance invalidation must follow successful target-side service resumption. This ordering is what prevents unauthorized migration acceptance, insecure intermediate state use, and premature forwarding to an unready target-side DT.

For clarity, Algorithm 1 summarizes the front-end control flow of migration triggering, target-side authorization, and protected-state transfer.

Algorithm 1 Secure Cross-Domain DT Migration: Trigger, Authorization, and Protected Transfer

Require:  DT instance ${\mathrm{DT}}_i$, source domain $D_s$, candidate set $\mathcal{D}$, migration state ${\mathcal{X}}_i\left(t\right)$ Ensure:  Authorized and protected target-side state-import context, or rejection   1: Observe $L_i^o\left(t\right)$, ${\mathcal{U}}_i\left(t\right)$, ${\mathrm{\Phi }}_i\left(t\right)$, and domain resource states   2: if  ${\mathcal{E}}_i\left(t\right)=0$  then   3:     Reject migration request   4: end if   5: Compute feasible target set ${\mathcal{D}}_i^{\mathrm{feas}}\left(t\right)$   6: if  ${\mathcal{D}}_i^{\mathrm{feas}}\left(t\right)=⌀$  then   7:     Reject migration request   8: end if   9: Select $$D_t\leftarrow \arg \underset{D_j\in {\mathcal{D}}_i^{\mathrm{feas}}\left(t\right)}{\min }{C}_{i,j}^{\mathrm{mig}}\left(t\right)$$ 10: Form migration tuple ${\mathrm{\Xi }}_i\left(t\right)\leftarrow ({\mathrm{DT}}_i,D_s,D_t,{\mathrm{\Phi }}_i\left(t\right),{\mathcal{U}}_i\left(t\right))$ 11: Generate source-side migration credential ${\mathcal{M}}_i^{s\to t}$ 12: Send ${\mathcal{M}}_i^{s\to t}$ to target authorization entity ${\mathcal{A}}_t$ 13: if  ${\mathsf{Ver}}_i^t=0$  then 14:     Reject migration request 15: end if 16: Issue target-side token ${\mathcal{T}}_i^t$ and mark authorization complete 17: if ${\mathcal{T}}_i^t$ is not issued or not within its validity window then 18:     Reject migration request 19: end if 20: Derive migration-bounded protection context $${\mathcal{K}}_i^{\mathrm{mig}}\leftarrow \mathrm{KDF}\left({\mathcal{K}}_i^t,PI{D}_i^s,PI{D}_i^t,I{D}_s,I{D}_t,{\nu }_i,{\mu }_i\right)$$ 21: if target-side authorization remains valid then 22:     Package migration state as ${\mathcal{P}}_i\left(t\right)$ 23:     Generate protected package ${\mathcal{Q}}_i\left(t\right)$ and tag ${\chi }_i\left(t\right)$ 24:     Transmit $({\mathcal{Q}}_i\left(t\right),{\chi }_i\left(t\right),{\omega }_i)$ to $D_t$ 25: else 26:     Reject migration request 27: end if 28: if  ${\mathsf{PkgAcc}}_i\left(t\right)=0$  then 29:     Reject migration request 30: end if 31: Restore imported state components at target side 32: Track restoration status until ${\mathsf{Ready}}_i^t\left(t\right)$ is determined

The following subsections detail the six phases of the mechanism.

4.2. Phase I: Migration Trigger and Candidate Edge Selection

This phase determines when DT migration should be initiated and which target edge domain should be selected as the migration candidate. Its role is limited to migration triggering and candidate selection; it does not itself authorize migration acceptance. Cross-domain legitimacy and admission control are handled in Phase II.

Let ${\mathrm{DT}}_i$ denote the DT associated with physical entity $o_i$, and let $D_s$ denote its current source edge domain. Let $\mathcal{D}=\{D_1,D_2,\dots ,D_{\left|\mathcal{D}\right|}\}$ be the set of candidate edge domains that may host ${\mathrm{DT}}_i$ after relocation. At decision epoch t, the migration orchestrator observes the object location $L_i^o\left(t\right)$, active user set ${\mathcal{U}}_i\left(t\right)$, source domain $D_s$, DT migration-state volume ${\mathrm{\Phi }}_i\left(t\right)$, candidate-domain resource state, and current service demand context.

Migration is trigger-driven rather than periodic. A migration event is raised only when the current hosting domain no longer provides an acceptable operating point in terms of synchronization cost, service cost, or resource feasibility. The trigger condition is defined as

$${\mathcal{E}}_i\left(t\right)=1\iff \left(C_i^{\mathrm{stay}}\left(t\right)-\underset{D_j\in \mathcal{D}\setminus \left\{D_s\right\}}{\min }{C}_{i,j}^{\mathrm{mig}}\left(t\right)\right)>{\tau }_i\vee {\rho }_s\left(t\right)>{\rho }_{\max },$$

(3)

where $C_i^{\mathrm{stay}}\left(t\right)$ is the estimated cost of retaining ${\mathrm{DT}}_i$ in $D_s$, $C_{i,j}^{\mathrm{mig}}\left(t\right)$ is the estimated cost if ${\mathrm{DT}}_i$ migrates to candidate domain $D_j$, ${\tau }_i$ is the minimum migration benefit threshold, ${\rho }_s\left(t\right)$ is the normalized resource pressure of the source domain, and ${\rho }_{\max }$ is the allowable operating threshold. Thus, migration is initiated either when a sufficiently better candidate exists or when the source domain becomes resource-constrained.

For each candidate domain $D_j\in \mathcal{D}\setminus \left\{D_s\right\}$, the migration-selection cost is defined as

$$C_{i,j}^{\mathrm{mig}}\left(t\right)=\alpha C_{i,j}^{\mathrm{sync}}\left(t\right)+\beta C_{i,j}^{\mathrm{srv}}\left(t\right)+\gamma C_{i,j}^{\mathrm{state}}\left(t\right)+\delta C_j^{\mathrm{load}}\left(t\right),$$

(4)

where $C_{i,j}^{\mathrm{sync}}\left(t\right)$ is the synchronization cost between the physical entity and the DT if hosted in $D_j$, $C_{i,j}^{\mathrm{srv}}\left(t\right)$ is the aggregate service cost from $D_j$ to active users of ${\mathrm{DT}}_i$, $C_{i,j}^{\mathrm{state}}\left(t\right)$ is the migration-state transfer cost from $D_s$ to $D_j$, $C_j^{\mathrm{load}}\left(t\right)$ is the resource pressure penalty of $D_j$, and $\alpha ,\beta ,\gamma ,\delta \ge 0$ are weighting coefficients.

The four cost components are instantiated as

$$\begin{array}{cc}\hfill C_{i,j}^{\mathrm{sync}}\left(t\right)& =w_{1}d(L_i^o\left(t\right),D_j)+w_2{b}_i^o\left(t\right),\hfill \\ \hfill C_{i,j}^{\mathrm{srv}}\left(t\right)& =\sum _{u_k\in {\mathcal{U}}_i\left(t\right)}{\omega }_{k}d(D_j,L_k^u\left(t\right)),\hfill \\ \hfill C_{i,j}^{\mathrm{state}}\left(t\right)& =\eta {\widehat{T}}_{i,s,j}^{\mathrm{tx}}\left(t\right),\hfill \\ \hfill C_j^{\mathrm{load}}\left(t\right)& ={\displaystyle \frac{{\chi }_i^{\mathrm{cpu}}}{R_j^{\mathrm{cpu}}\left(t\right)+ϵ}}+{\displaystyle \frac{{\chi }_i^{\mathrm{mem}}}{R_j^{\mathrm{mem}}\left(t\right)+ϵ}}+{\displaystyle \frac{{\chi }_i^{\mathrm{stor}}}{R_j^{\mathrm{stor}}\left(t\right)+ϵ}}.\hfill \end{array}$$

(5)

Here, $b_i^o\left(t\right)$ is the physical entity update traffic volume, ${\omega }_k$ is the service demand weight of user $u_k$, $\eta$ is the unit state transfer coefficient, and $ϵ>0$ avoids division by zero. The term ${\widehat{T}}_{i,s,j}^{\mathrm{tx}}\left(t\right)$ denotes the normalized form of the effective protected-state transmission time $T_{i,s,j}^{\mathrm{tx}}\left(t\right)$ defined in Section 3. Therefore, the migration-state cost used for target selection reflects not only the DT state volume and inter-domain distance, but also effective bandwidth, protocol overhead, retransmission/congestion penalty, and queueing delay.

Candidate domains that violate hard hosting constraints are excluded, as follows:

$$\begin{array}{cc}\hfill D_j\in {\mathcal{D}}_i^{\mathrm{feas}}\left(t\right)\iff & R_j^{\mathrm{cpu}}\left(t\right)\ge {\chi }_i^{\mathrm{cpu}}\wedge R_j^{\mathrm{mem}}\left(t\right)\ge {\chi }_i^{\mathrm{mem}}\hfill \\ \hfill & \wedge R_j^{\mathrm{stor}}\left(t\right)\ge {\chi }_i^{\mathrm{stor}}\wedge B_{s,j}^{\mathrm{eff}}\left(t\right)\ge B_i^{\min }\hfill \\ \hfill & \wedge T_{i,s,j}^{\mathrm{tx}}\left(t\right)\le T_i^{\max ,\mathrm{mig}}.\hfill \end{array}$$

(6)

The last two constraints exclude target domains whose effective inter-domain goodput is too low or whose estimated protected-state transfer time exceeds the migration time budget. This prevents the migration orchestrator from selecting a target that appears feasible in compute, memory, and storage terms but is infeasible under practical network-stack and transmission conditions.

The target domain selection problem is therefore

$$D_i^{*}\left(t\right)=\arg \underset{D_j\in {\mathcal{D}}_i^{\mathrm{feas}}\left(t\right)}{\min }{C}_{i,j}^{\mathrm{mig}}\left(t\right),$$

(7)

subject to ${\mathcal{E}}_i\left(t\right)=1$. The weighting coefficients $\alpha ,\beta ,\gamma ,\delta$ and the trigger thresholds ${\tau }_i$ and ${\rho }_{\max }$ are deployment policy parameters rather than learned protocol variables. In the reported evaluation, all cost components are first normalized to a common dimensionless scale, and the fixed empirical setting

$$\alpha =0.30,\beta =0.30,\gamma =0.25,\delta =0.15$$

is used for all compared schemes and all repeated runs. This setting gives comparable emphasis to physical entity synchronization and user-side service proximity, assigns slightly lower but still substantial weight to protected-migration-state transfer, and uses the remaining weight for target-side load pressure. The trigger threshold is set to require a 15% migration benefit margin, i.e., migration is triggered when the best feasible migration cost improves on $C_i^{\mathrm{stay}}\left(t\right)$ by more than $0.15C_i^{\mathrm{stay}}\left(t\right)$, and the source load threshold is fixed as ${\rho }_{\max }=0.85$, consistent with the migration trigger rule used in the evaluation setup. These values are not dynamically tuned during a run; they are held constant so that differences among B1–B5 arise from the enabled migration control stages rather than from changes in the migration decision policy.

The ordered migration control logic developed in the later phases does not depend on one specific numerical setting of these parameters. Rather, these parameters govern when migration is initiated and which feasible target is selected before admission control begins. In this sense, Phase I provides a parameterized operational front end to the secure migration procedure rather than a claim of globally optimal migration selection under all environments. If no feasible candidate exists, the DT remains in the source domain and migration is terminated at this stage. Otherwise, the selected target domain is denoted by $D_t=D_i^{*}\left(t\right)$, and the migration decision tuple is denoted by ${\mathrm{\Xi }}_i\left(t\right)=\left({\mathrm{DT}}_i,D_s,D_t,{\mathrm{\Phi }}_i\left(t\right),{\mathcal{U}}_i\left(t\right)\right)$.

The output of this phase is therefore a candidate migration decision, not a completed migration authorization. In particular, the tuple ${\mathrm{\Xi }}_i\left(t\right)$ only identifies a migration candidate and a feasible target under mobility, service cost, and resource considerations; it does not by itself create any target-side right to accept the incoming DT or to receive migration state. This distinction is essential because a target selected as operationally desirable in Phase I may still be inadmissible from the standpoint of cross-domain legitimacy, accepted scope, or revocation status. Accordingly, Phase I determines where migration should next be evaluated, whereas Phase II determines whether migration is actually admissible under a valid cross-domain authorization context. Only after this admission control step succeeds may the mechanism proceed to protected-migration-state transfer.

4.3. Phase II: Cross-Domain DT Authorization and Handoff Authentication

After a candidate target domain has been selected in Phase I, the migration procedure still remains only at the level of an operational candidate transition. Migration cannot proceed directly to state relocation because target selection alone does not establish that the incoming DT is a legitimate migratable instance, that its current authorization state remains valid, or that its inherited service scope is admissible under the target domain policy. Phase II therefore serves as the admission control bridge between migration desirability and migration permissibility: it converts the candidate migration decision produced in Phase I into either an authorized migration context or a rejected request. In this way, the mechanism ensures that the output of migration selection is not mistaken for migration acceptance.

Before any state export is permitted, the source and target domains execute a cross-domain authorization procedure between the source domain authorization entity ${\mathcal{A}}_s$ and the target domain authorization entity ${\mathcal{A}}_t$ using the candidate migration decision produced in Phase I. The purpose of this procedure is threefold: to verify DT legitimacy, to check target policy admissibility, and to issue the target-side authorization material required for the subsequent migration-state transfer.

A.

Source-Side Authorization State and Migration Credential

For each DT ${\mathrm{DT}}_i$, the source domain maintains a current pseudonymous DT identity, identity-binding evidence, a valid service scope, a revocation status, and an authorization validity window. Based on this active authorization context and the selected target domain identifier $I{D}_t$, the source domain generates the migration credential

$${\mathcal{M}}_i^{s\to t}=\left(PI{D}_i^s,I{D}_s,I{D}_t,{Տ}_i^s,T_{\mathrm{issue}},T_{\exp },{\nu }_i,{\sigma }_i^s\right),$$

(8)

where $PI{D}_i^s$ is the current source-side pseudonymous DT identity, $I{D}_s$ and $I{D}_t$ are the source and target domain identifiers, ${Տ}_i^s$ is the currently valid service scope, $T_{\mathrm{issue}}$ and $T_{\exp }$ are the issue and expiration times, ${\nu }_i$ is a fresh nonce, and ${\sigma }_i^s$ is a source-side authentication tag or signature over the credential contents. This credential provides evidence that the migration request originates from an active and policy-valid source-side DT context. To avoid unnecessary cross-domain identity exposure, the credential carries a pseudonymous DT identifier and scoped authorization information rather than long-term real-world identity information.

B.

Target Domain Verification Conditions

Upon receiving ${\mathcal{M}}_i^{s\to t}$, the target domain authorization entity ${\mathcal{A}}_t$ validates the request under its identity acceptance, service scope, freshness, and revocation enforcement policies. The target domain accepts the incoming migration request only if

$${\mathsf{Ver}}_i^t=1\iff {\mathsf{AuthSig}}_i^t\wedge {\mathsf{Fresh}}_i^t\wedge {\mathsf{Bind}}_i^t\wedge {\mathsf{Scope}}_i^t\wedge {\mathsf{RevChk}}_i^t,$$

(9)

that is, only if the source-side authentication tag is valid, the credential remains fresh, the identity-binding evidence satisfies the target-side admission policy, the inherited service scope is admissible under the target policy, and the DT is confirmed to be non-revoked. Here, ${\mathcal{L}}_t^{\mathrm{rev}}$ denotes the target domain revocation structure. Hence, the target domain accepts migration only from a DT whose source-side authorization is authentic, fresh, identity-bound, scope-compliant, and non-revoked.

C.

Target-Side Migration Authorization

If ${\mathsf{Ver}}_i^t=1$, the target domain still does not immediately activate the incoming DT instance. Instead, it issues the target-side migration authorization token

$${\mathcal{T}}_i^t=\left(PI{D}_i^t,I{D}_t,{Տ}_i^t,{\mathcal{K}}_i^t,T_{\mathrm{grant}},T_{\exp }^t,{\mu }_i,{\sigma }_i^t\right),$$

(10)

where $PI{D}_i^t$ is the target-side pseudonymous DT identifier, ${Տ}_i^t$ is the accepted target-side service scope, ${\mathcal{K}}_i^t$ is the migration-session authorization material, $T_{\mathrm{grant}}$ and $T_{\exp }^t$ are the target-side validity timestamps, ${\mu }_i$ is a fresh target-generated nonce, and ${\sigma }_i^t$ is the target-side protection tag.

If target-side verification succeeds, the target domain issues ${\mathcal{T}}_i^t$ and the migration is marked authorization-complete. Otherwise, the migration request is rejected and no migration-state export is allowed.

For the subsequent transfer phase, the target domain uses the target-approved pseudonymous identity, accepted service scope, migration-session authorization material, and validity boundary contained in ${\mathcal{T}}_i^t$ as a migration-bounded authorization context for protected state import and restoration preparation, without introducing a separate long-term access state.

At the end of this phase, the migration request yields one of two outcomes. If target-side verification succeeds and the authorization token is issued, the mechanism proceeds to Phase III with an authorized migration context. Otherwise, the migration request is rejected and the process terminates at this stage. Phase II therefore determines whether the target domain is willing to admit the incoming DT under a valid, fresh, scoped, and non-revoked authorization context before any protected-state transfer is allowed.

4.4. Phase III: Secure Migration-State Transfer

After Phase II has completed target-side authorization, the migration procedure enters the secure state transfer phase. This phase relocates the operational state of the DT from the source domain to the target domain while preserving confidentiality, integrity, freshness, and policy-bounded usability. Because the migrating DT carries historical data, runtime context, and execution-relevant state, migration involves more than instance relocation; it must also transfer the information required for correct target-side restoration.

A.

Migration-State Model

Let the migration state of ${\mathrm{DT}}_i$ at decision epoch t be

$${\mathcal{X}}_i\left(t\right)=\left({\mathcal{X}}_i^{\mathrm{hist}}\left(t\right),{\mathcal{X}}_i^{\mathrm{run}}\left(t\right),{\mathcal{X}}_i^{\mathrm{ctx}}\left(t\right),{\mathcal{X}}_i^{\mathrm{perm}}\left(t\right)\right),$$

(11)

where ${\mathcal{X}}_i^{\mathrm{hist}}\left(t\right)$ is the historical DT data, ${\mathcal{X}}_i^{\mathrm{run}}\left(t\right)$ is the runtime state required to resume execution, ${\mathcal{X}}_i^{\mathrm{ctx}}\left(t\right)$ is the migration-relevant control context, and ${\mathcal{X}}_i^{\mathrm{perm}}\left(t\right)$ is the transferable permission state required for post-migration operation.

The total transferable state volume is

$${\mathrm{\Phi }}_i\left(t\right)=\left|{\mathcal{X}}_i^{\mathrm{hist}}\left(t\right)\right|+\left|{\mathcal{X}}_i^{\mathrm{run}}\left(t\right)\right|+\left|{\mathcal{X}}_i^{\mathrm{ctx}}\left(t\right)\right|,$$

(12)

which is the same migration-state burden used in Phase I.

B.

Transfer Preconditions and Migration-Bounded Protection Context

Secure state export is permitted only after successful target-side authorization and only while the target-issued migration authorization token remains valid. If either condition fails, no migration-state export is performed. This makes Phase II the mandatory gate for all subsequent state relocation.

Let ${\mathcal{K}}_i^t$ be the target-issued migration-session authorization material obtained in Phase II. The source and target domains derive the migration-bounded protection context

$${\mathcal{K}}_i^{\mathrm{mig}}=\mathrm{KDF}\left({\mathcal{K}}_i^t,PI{D}_i^s,PI{D}_i^t,I{D}_s,I{D}_t,{\nu }_i,{\mu }_i\right),$$

(13)

where $\mathrm{KDF}(·)$ is a key-derivation function and $({\nu }_i,{\mu }_i)$ are the source- and target-side freshness nonces introduced during handoff authentication.

This construction binds the transfer protection context to the source-side pseudonym, target-side pseudonym, source domain, target domain, and current migration event. Consequently, the protection context is migration-specific rather than a reusable general communication key, and its validity is bounded by the target-side authorization granted in Phase II.

For concreteness, the abstract primitives used in Section 4 are instantiated in the reported evaluation and artifact-size model by standard constructions. The migration-bounded protection context is derived using HKDF-SHA-256 with 256-bit output key material; protected-migration-state transfer is represented using AES-256-GCM-style AEAD metadata with a 96-bit nonce and a 128-bit authentication tag; and source- and target-side control-plane authentication artifacts are represented using Ed25519-style 64-byte signatures. Under the AEAD realization, the pseudonymous DT identifiers, source and target domain identifiers, validity window, and transfer sequence identifier are treated as associated data so that they are integrity-protected together with the encrypted migration state.

The reported evaluation does not apply compression before protected transfer; ${\mathrm{\Phi }}_i\left(t\right)$ denotes the uncompressed transferable DT state volume. Compression, dirty-page filtering, and incremental checkpoint reduction are compatible with the transfer model through a reduced effective ${\mathrm{\Phi }}_i\left(t\right)$, but they are not enabled in the reported measurements in order to isolate the overhead of the proposed migration control stages.

C.

Protected State Packaging and Transmission

The source domain packages the migration state as

$${\mathcal{P}}_i\left(t\right)=\left(PI{D}_i^s,PI{D}_i^t,{\mathcal{X}}_i\left(t\right),T_{\mathrm{pkg}},T_{\exp }^{\mathrm{mig}},{\omega }_i\right),$$

(14)

where $T_{\mathrm{pkg}}$ is the packaging timestamp, $T_{\exp }^{\mathrm{mig}}$ is the migration-state expiration time, and ${\omega }_i$ is the transfer sequence or version identifier.

The protected migration package is then generated as

$${\mathcal{Q}}_i\left(t\right)={\mathrm{Enc}}_{{\mathcal{K}}_i^{\mathrm{mig}}}\left({\mathcal{P}}_i\left(t\right)\right),$$

(15)

with the accompanying integrity/authenticity tag

$${\chi }_i\left(t\right)={\mathrm{MAC}}_{{\mathcal{K}}_i^{\mathrm{mig}}}\left({\mathcal{Q}}_i\left(t\right)\parallel PI{D}_i^s\parallel PI{D}_i^t\parallel {\omega }_i\right).$$

(16)

Thus, the transmitted migration-state object consists of the protected package ${\mathcal{Q}}_i\left(t\right)$, the associated integrity tag ${\chi }_i\left(t\right)$, and the transfer sequence identifier ${\omega }_i$.

The target domain accepts the incoming package only if

$${\mathsf{PkgAcc}}_i\left(t\right)=1\iff {\mathsf{MACVer}}_i\left(t\right)\wedge {\mathsf{TimeVer}}_i\left(t\right)\wedge {\mathsf{ScopeVer}}_i\left(t\right)\wedge {\mathsf{FreshVer}}_i\left(t\right),$$

(17)

that is, if the integrity tag is valid under the migration-bounded protection context, the package remains within its migration-validity window, the transferred permission state is consistent with the target-approved scope, and the transfer sequence identifier is fresh and not replayed. Hence, a migration-state package is accepted only if it is integrity-valid, time-valid, fresh, and scope-consistent.

D.

Target-Side State Import and Restoration Readiness

If ${\mathsf{PkgAcc}}_i\left(t\right)=1$, the target domain decrypts ${\mathcal{Q}}_i\left(t\right)$, reconstructs ${\mathcal{P}}_i\left(t\right)$, and extracts the migration state ${\mathcal{X}}_i\left(t\right)$. However, package acceptance does not by itself imply that the migrated DT is ready to resume service. The imported state must still be restored and validated at the target side.

The target domain then restores and validates the historical, runtime, control context, and permission-related components of the imported DT state. The target-side DT is marked as restoration-ready only if all required transferred components have been restored successfully and validated for use, as follows:

$${\mathsf{Ready}}_i^t\left(t\right)=1\iff r_i^{\mathrm{hist}}\left(t\right)=1\wedge r_i^{\mathrm{run}}\left(t\right)=1\wedge r_i^{\mathrm{ctx}}\left(t\right)=1\wedge r_i^{\mathrm{perm}}\left(t\right)=1.$$

(18)

This distinction between package acceptance and restoration readiness is essential. A DT that has merely received state is not yet eligible for traffic release; the later service transition must be conditioned on successful restoration rather than on receipt alone.

Phase III therefore ensures that DT state is exported only under valid migration authorization, protection during inter-domain transfer, a check for freshness and scope consistency, and preparation for target-side restoration before any service traffic is allowed to move.

4.5. Phase IV: Continuity-Aware Traffic Transition

Algorithm 2 summarizes the back end control flow of continuity-aware transition, formal target-side activation, and revocation-aware migration completion.

Algorithm 2 Secure Cross-Domain DT Migration: Continuity Control, Activation, and Completion

Require:  Accepted protected state package and target-side restoration status Ensure:  Migration completion status ${\mathsf{MigComp}}_i\left(t\right)\in \{0,1\}$   1: if  ${\mathsf{Ready}}_i^t\left(t\right)=0$  then   2:     Activate buffering: ${\beta }_i\left(t\right)\leftarrow 1$   3:     while ${\mathsf{Ready}}_i^t\left(t\right)=0$ do   4:         Retain incoming requests in ${\chi }_i^{\mathrm{buf}}\left(t\right)$   5:         Maintain forwarding mode ${\mathcal{F}}_i\left(t\right)\leftarrow \mathsf{trans}$   6:         if $t-t_i^{\mathrm{buf}}>T_i^{\max }$ or $\left|{\chi }_i^{\mathrm{buf}}\left(t\right)\right|>B_i^{\max }$ then   7:            Abort target-side traffic release   8:            Trigger recovery handling   9:            return 0 10:         end if 11:     end while 12: end if 13: if  ${\mathsf{Rel}}_i\left(t\right)=1$  then 14:     Flush retained requests to target-side DT 15:     Set ${\chi }_i^{\mathrm{buf}}\left(t\right)\leftarrow ⌀$ 16:     Set ${\beta }_i\left(t\right)\leftarrow 0$ 17:     Update forwarding mode ${\mathcal{F}}_i\left(t\right)\leftarrow \mathsf{tar}$ 18: end if 19: Revalidate target-side authorization and scope-valid operation 20: if  ${\mathsf{Act}}_i^t\left(t\right)=0$  then 21:     return 0 22: end if 23: Declare target-side service resumption: ${\mathsf{Resume}}_i\left(t\right)\leftarrow 1$ 24: if  ${\mathsf{Trig}}_i^{\mathrm{rev}}\left(t\right)=1$  then 25:     Invalidate source-side execution state 26:     Revoke source-side authorization artifacts 27:     Insert $PI{D}_i^s$ into revocation structure ${\mathcal{L}}^{\mathrm{rev}}$ 28: end if 29: if  ${\mathsf{MigComp}}_i\left(t\right)=1$  then 30:     return 1 31: else 32:     return 0 33: end if

After Phase III has completed secure state transfer, the system must ensure that ongoing requests are not disrupted while the migrated DT instance is being prepared for active service. This phase preserves service continuity during the interval between source-side migration control and formal target-side activation by buffering incoming requests and releasing them only after the target-side DT becomes restoration-ready.

A.

Transition State, Buffering, and Forwarding Control

Let the continuity control state of ${\mathrm{DT}}_i$ at time t be represented by the buffer activation indicator ${\beta }_i\left(t\right)\in \{0,1\}$ and the buffered request state ${\chi }_i^{\mathrm{buf}}\left(t\right)$. Target-side restoration readiness is captured by ${\mathsf{Ready}}_i^t\left(t\right)$, and the forwarding mode is represented by ${\mathcal{F}}_i\left(t\right)$.

We define the continuity control interval for ${\mathrm{DT}}_i$ as

$${\mathcal{I}}_i^{\mathrm{cont}}=\left[t_i^{\mathrm{buf}},t_i^{\mathrm{rel}}\right],$$

(19)

where $t_i^{\mathrm{buf}}$ is the time at which buffering is activated and $t_i^{\mathrm{rel}}$ is the first time at which traffic release toward the target-side DT becomes permissible because restoration readiness has been achieved. Thus, this phase explicitly treats the migration interval as a controlled service transition period rather than assuming immediate cutover.

Once secure state transfer has been accepted and target-side restoration is underway, the continuity controller activates request buffering for all new service requests associated with ${\mathrm{DT}}_i$. Let ${\mathcal{R}}_i\left(t\right)$ denote the incoming request stream for ${\mathrm{DT}}_i$. Buffering is activated according to

$${\beta }_i\left(t\right)=1\iff \left({\mathsf{PkgAcc}}_i\left(t\right)=1\right)\wedge \left({\mathsf{Ready}}_i^t\left(t\right)=0\right).$$

(20)

When ${\beta }_i\left(t\right)=1$, incoming requests are retained in the migration buffer under continuity control rather than forwarded to the target-side DT, and restoration readiness has not yet been achieved. Hence, requests arriving during restoration are retained under controlled buffering instead of being prematurely executed by an unready target-side instance.

To avoid indefinite transition buffering, the continuity controller enforces a maximum transition budget $T_i^{\max }$ and a buffer capacity limit $B_i^{\max }$. The timeout deadline is $t_i^{\mathrm{fail}}=t_i^{\mathrm{buf}}+T_i^{\max }$, and the buffer limit is set as $B_i^{\max }=\lceil {\lambda }_i^{\max }{T}_i^{\max }\rceil$, where ${\lambda }_i^{\max }$ is the configured peak request-arrival rate for ${\mathrm{DT}}_i$ during the transition interval. In the reported evaluation, $T_i^{\max }=2.5$ s and one protected-transfer retry is allowed before final migration abort.

If restoration readiness is not achieved before $t_i^{\mathrm{fail}}$, or if $\left|{\chi }_i^{\mathrm{buf}}\left(t\right)\right|>B_i^{\max }$, the continuity controller executes a deterministic recovery sequence. First, target-side traffic release is aborted and the forwarding mode is kept out of $\mathsf{tar}$. Second, the provisional target-side DT state and target-side activation context are cleared so that a partially restored DT cannot process live requests. Third, if the source-side DT remains authorization-valid and has not yet been revoked, buffered requests are redirected back to the source-side service path and the forwarding mode returns to $\mathsf{src}$. Fourth, if the source-side path is no longer valid, the controller performs at most one protected-transfer retry using a fresh transfer sequence identifier. If the retry also fails, the migration attempt is rejected, the provisional target-side state is cleared, and the buffered requests are failed or requeued according to the service policy rather than released to an unready target. Thus, continuity control prevents premature release, indefinite buffering, and silent buffer overflow.

During the continuity control interval, live service responsibility cannot remain bound to the ordinary source-side execution path, but it also cannot yet be assigned to the normal target-side service path. The forwarding mode ${\mathcal{F}}_i\left(t\right)$ therefore has three states: $\mathsf{src}$ before migration control begins, $\mathsf{trans}$ while requests are retained during target-side restoration, and $\mathsf{tar}$ after restoration readiness has been achieved and buffered requests have been safely released. The transition mode $\mathsf{trans}$ denotes a protected intermediate state in which requests are intercepted by the continuity controller, accumulated in the migration buffer, and prevented from direct execution at the target side until restoration has completed.

B.

Traffic Release and Buffer Flushing

Retained requests may be released only after the target-side DT reaches restoration-ready state and becomes eligible to assume live service responsibility. The release condition is

$${\mathsf{Rel}}_i\left(t\right)=1\iff \left({\mathsf{Ready}}_i^t\left(t\right)=1\right)\wedge \left({\beta }_i\left(t\right)=1\right).$$

(21)

If ${\mathsf{Rel}}_i\left(t\right)=1$, the continuity controller flushes the retained request set to the now-ready target-side DT, clears the migration buffer, deactivates buffering, and updates the forwarding mode to $\mathsf{tar}$. Therefore, the target-side DT becomes the live request-processing endpoint only after restoration has completed and buffered requests are safely released.

C.

Continuity Budget

The objective of this phase is not to assume zero migration delay but to ensure that disruption remains controlled at the logical service level. The continuity control interval duration is ${\Delta }_i^{\mathrm{cont}}=t_i^{\mathrm{rel}}-t_i^{\mathrm{buf}}$. During this interval, requests are not dropped, misrouted, or released before restoration readiness is achieved. Thus, the mechanism allows a bounded transition interval but does not allow uncontrolled request loss, misrouting, or premature execution.

D.

Ordering and Execution Correctness

Because the DT is stateful, continuity must preserve not only request retention but also execution consistency. For a buffered request sequence retained during migration, the flush policy is required to preserve causal or service-consistent ordering as follows:

$$r_{i,a}\prec r_{i,b}\Rightarrow \mathrm{exec}\left(r_{i,a}\right)⪯\mathrm{exec}\left(r_{i,b}\right),\forall a<b.$$

(22)

This requirement ensures that buffered requests released after restoration do not violate the execution semantics of the migrated DT state.

Phase IV therefore ensures that successful state transfer does not by itself imply successful service transfer. The migrated DT does not assume live service responsibility until restoration has completed and retained requests have been released safely under readiness-gated transition control.

4.6. Phase V: Formal Target-Side Activation and Service Resumption

After Phase IV has completed continuity-aware traffic transition, the migrated DT still cannot be treated as formally active solely because buffered requests have been released and forwarding has switched to the target domain. A final validation step is required to confirm that the target-side DT remains authorization-valid, operates within the accepted target-side access scope, and is recognized as the unique active execution instance. This phase therefore converts a restored and traffic-ready DT into a formally active target-side service endpoint.

Formal target-side activation depends on four conditions: target-side authorization must remain valid at activation time, the DT must have entered active target-side service state, post-migration access must remain within the accepted target-side scope, and the migrated DT must be recognized as the unique active execution instance. The overall activation condition is therefore

$${\mathsf{Act}}_i^t\left(t\right)=1\iff a_i^{\mathrm{auth}}\left(t\right)=1\wedge a_i^{\mathrm{svc}}\left(t\right)=1\wedge a_i^{\mathrm{data}}\left(t\right)=1\wedge a_i^{\mathrm{uniq}}\left(t\right)=1.$$

(23)

Only if ${\mathsf{Act}}_i^t\left(t\right)=1$ may the migrated DT be regarded as the formally active target-side DT.

The four activation subconditions in ${\mathsf{Act}}_i^t\left(t\right)$ are evaluated as follows. The authorization subcondition $a_i^{\mathrm{auth}}\left(t\right)$ requires the target-side authorization token to remain valid, unexpired, and non-revoked at activation time. The service subcondition $a_i^{\mathrm{svc}}\left(t\right)$ requires the migrated DT to be bootstrapped, synchronized, able to process incoming requests, and already placed under target-side forwarding mode. The scope validity subcondition $a_i^{\mathrm{data}}\left(t\right)$ requires the requested post-migration access scope to remain within the accepted target-side scope ${Տ}_i^t$ and its validity window. The uniqueness subcondition $a_i^{\mathrm{uniq}}\left(t\right)$ requires the target-side DT to be operational while no conflicting active source-side execution context is visible to the migration controller.

If any of these subconditions fails, the migrated DT remains provisional and formal service resumption is not declared. Final stale source invalidation is completed in Phase VI after valid target-side service resumption.

4.7. Phase VI: Source-Side Invalidation and Invalid Twin Removal

After the migrated DT is validated as the active target-side service instance in Phase V, migration is still not complete in the strong sense required by this paper. At this point, the mechanism has established target-side activation, but it has not yet converted that activation into exclusive target-side service ownership. The remaining task is therefore not auxiliary cleanup, but completion-critical invalidation of obsolete source-side execution context and revocation of stale, duplicated, or compromised authorization artifacts associated with the pre-migration state. Phase VI performs this final conversion from successful target-side activation to unique post-migration ownership, thereby closing the migration lifecycle and preventing a residual source-side state from remaining security-relevant after relocation.

A.

Revocation Scope and Trigger

Revocation applies not only to the stale source-side DT identity but also to all source-bound execution and authorization artifacts that could otherwise remain reusable, including source-side authorization tokens, access descriptors, migration or session keying material, and residual execution state.

Revocation is initiated only after the target-side DT has formally resumed service and has been recognized as the unique active instance. Let

$${\mathsf{Trig}}_i^{\mathrm{rev}}\left(t\right)=1\iff \left({\mathsf{Resume}}_i\left(t\right)=1\right)\wedge \left(a_i^{\mathrm{uniq}}\left(t\right)=1\right).$$

(24)

Thus, revocation is completion-dependent rather than migration-attempt-dependent. The source-side instance is not invalidated merely because migration was attempted; it is invalidated only after successful target-side activation has been established.

B.

Source-Side Invalidation and Revocation Propagation

Once revocation is triggered, the source-side DT must no longer be able to serve live requests or continue synchronization under the pre-migration state. Accordingly, the source-side execution context is deactivated and its residual execution state is cleared after the revocation trigger holds.

After source-side execution invalidation, the corresponding source-side authorization state and source-bound credential material are revoked. In particular, previously valid source-side authorization artifacts, access descriptors, and migration- or session-bound keying materials are invalidated so that they cannot remain usable after migration completion.

To prevent stale source-side artifacts from being accepted in future protocol executions, the revocation event is propagated to revocation-aware control entities together with the revoked source-side pseudonymous identity, the associated source and target domains, the revocation time, and the revocation reason. The revoked identity is then inserted into the revocation structure so that future protocol checks can reject subsequent reuse attempts.

The revocation update is disseminated as a versioned revocation record containing the revoked pseudonymous identity, source domain, target domain, revocation epoch, reason code, and issuer authentication tag. Each revocation-aware control entity accepts only records with a valid issuer tag and a revocation epoch newer than its locally stored version. After acceptance, the entity acknowledges the update to the revocation manager and rejects subsequent protocol messages carrying the revoked source-side identity. During the synchronization interval, conservative validation is used: if the target domain cannot confirm that a source-side identity is non-revoked under the latest known revocation epoch, the corresponding migration or access request is rejected rather than provisionally accepted.

C.

Invalid Twin Cases and Future Rejection

The same revocation logic applies both to ordinary stale instance cleanup and to explicitly invalid DT cases, including stale source-side persistence, duplicate active instances, compromised DT state, replayed authorization artifacts, and interaction without valid authorization. After revocation, any later request, migration attempt, or access validation involving the revoked source-side identity is rejected by the revocation-aware control path.

D.

Final Post-Revocation State and Output

After revocation is completed, the intended post-migration condition is that the source-side DT is no longer active, the target-side DT is the sole active instance, and stale source-side authorization no longer remains usable. Migration is therefore treated as fully complete only if

$${\mathsf{MigComp}}_i\left(t\right)=1\iff \left({\mathsf{Resume}}_i\left(t\right)=1\right)\wedge \left({\iota }_i^s\left(t^{+}\right)=0\right)\wedge \left({\mathsf{AuthVal}}_i^s\left(t^{+}\right)=0\right).$$

(25)

Thus, migration is not considered complete while stale source-side execution or authorization remains security-relevant. This phase closes the migration lifecycle by ensuring that stale or otherwise invalid twins cannot remain security-relevant after target-side activation.

5. Security Analysis

The security properties of the proposed secure cross-domain authentication and service continuity mechanism are examined here with reference to the system model, threat model, and design goals of Section 3 and the phase-based procedure of Section 4. The analysis is intended to establish mechanism-level security under the stated control-plane trust assumptions, not to provide a formal cryptographic reduction. In particular, the discussion evaluates whether the ordered migration control process enforces cross-domain DT legitimacy, protects migration-state transfer, preserves service continuity during stateful transition, ensures post-migration uniqueness of the active DT instance, and prevents stale or otherwise invalid twins from participating after migration completion, assuming standard secure cryptographic primitives and correct execution by the trusted control entities. For clarity, the discussion is organized by security objective.

5.1. Security Objectives

Under the threat model of Section 3, the proposed mechanism is examined with respect to five core security properties: (i) cross-domain DT legitimacy and authorization soundness, (ii) confidentiality and integrity of migration-state transfer, (iii) service continuity and transition safety, (iv) post-migration uniqueness and revocation security, and (v) resistance to common protocol-level attacks. The following subsections establish these properties by showing how they follow from the phase-ordering constraints and the admission, transfer, readiness, activation, and revocation conditions defined in Section 4 under the stated trust assumptions.

5.2. Security Scope and Representative Primitive Instantiation

The security analysis in this paper is mechanism-level rather than reduction-based cryptographic proof. The proposed contribution is not a new encryption, authentication, or key-agreement primitive. Instead, the analysis examines whether the ordered migration control procedure of Section 4 enforces authorization gating, protected-state transfer, readiness-gated transition, and revocation-aware completion under standard assumptions about the cryptographic building blocks used by the control path.

Table 3. Attack coverage under the stated migration control threat model.

Attack Type	Main Control-Stage Defense	Security Effect
Unauthorized migration attempt	Phase II credential verification, identity binding, scope admissibility, revocation check	Prevents target-side admission without valid migration authorization
Replay of migration credential or package	Freshness checks, authorization validity windows, migration package time validity, transfer sequence freshness	Prevents reuse of expired or previously accepted migration artifacts
Transfer path tampering	Integrity/authentication tag verification on the protected migration package	Rejects modified or substituted migration-state packages
Premature forwarding to unready target DT	Phase IV buffering and readiness-gated release	Prevents live traffic release before restoration completes
Stale or duplicate DT persistence	Phase V uniqueness validation and Phase VI revocation-aware invalidation	Prevents dual-active execution and stale context reuse after completion
Out-of-scope post-migration use	Target-side scope validation during admission and package acceptance	Prevents migration from extending permissions beyond target-approved scope

summarizes the representative attack types, main control-stage defenses, and corresponding security effects.

The representative primitive instantiation used for the artifact size and timing model is specified in Section 4 and the evaluation setup. The security discussion below assumes that these standard primitives provide their usual key-derivation, AEAD confidentiality and integrity, and signature-authentication properties. The primitive selection itself is not treated as a cryptographic contribution of this paper.

Under such an instantiation, this paper does not claim a new cryptographic security reduction. Rather, it assumes that the chosen underlying primitives satisfy their standard security properties and evaluates whether the migration control workflow composes them in a way that preserves authorization soundness, migration-state confidentiality and integrity, replay resistance, transition safety, and revocation-aware completion under the stated threat model.

Accordingly, the claims made in the remainder of this section should be interpreted as conditional mechanism security claims under the stated trust assumptions and standard primitive security. To strengthen these claims, the migration control path is additionally checked using ProVerif-based symbolic verification. This verification does not constitute a cryptographic reduction and does not cover compromised trusted entities, side-channel leakage, arbitrary implementation faults, or numerical performance behavior; rather, it verifies the secrecy and event-ordering properties of the abstract migration control protocol under the Dolev–Yao symbolic model.

5.3. Symbolic Verification of the Migration Control Path

To address the need for automated formal checking of the protocol logic, we constructed a ProVerif model of the migration control path. The model abstracts the Phase II source credential and target authorization exchange, the Phase III protected-migration-state transfer, the Phase V activation dependency, and the Phase VI revocation-aware completion dependency. The attacker is modeled under the standard Dolev–Yao symbolic setting, in which communication over the public channel can be observed, replayed, and modified, while cryptographic primitives are treated as ideal symbolic constructors satisfying their intended equations.

The symbolic model verifies secrecy and correspondence properties rather than numerical performance behavior. Accordingly, it does not model migration cost optimization, bandwidth variation, queue length, buffer timeout, or service latency measurements. These aspects are evaluated separately in Section 6. The purpose of the ProVerif model is to check whether the ordered migration control path enforces the expected authorization, protected-transfer, activation-ordering, and revocation-completion dependencies under symbolic cryptographic assumptions.

Table 4. ProVerif-based symbolic verification results for the migration control path.

Verified Property	Symbolic Query Interpretation	Result
Migration-state secrecy	The adversary cannot derive the protected DT migration state.	Verified
Authorization correspondence	Target-side acceptance implies that a corresponding source-side migration credential was previously issued.	Verified
Protected-transfer correspondence	Migration package acceptance implies prior target-side authorization and prior protected package transmission.	Verified
Activation-ordering safety	Target-side activation implies prior protected package acceptance and target-side restoration readiness.	Verified
Revocation-aware completion	Migration completion implies prior target-side activation and prior source-side revocation.	Verified

summarizes the corresponding ProVerif-based symbolic verification results.

The ProVerif output returned true for all listed secrecy and correspondence queries. Specifically, the secrecy query confirmed that the symbolic adversary cannot derive the protected DT migration state. The correspondence queries confirmed that target-side acceptance implies prior source-side credential issuance, migration package acceptance implies prior target authorization and package transmission, target activation implies prior package acceptance and restoration readiness, and migration completion implies prior target activation and source-side revocation. These results support the mechanism-level security claims by showing that the abstract migration control path enforces the intended authorization, protected-transfer, activation, and revocation dependencies under symbolic cryptographic assumptions.

5.4. Cross-Domain DT Legitimacy and Authorization Soundness

The first security requirement is that migration acceptance be conditioned on explicit cross-domain authorization and handoff authentication rather than on target selection alone.

In the mechanism, migration acceptance is based on the source-side migration credential introduced in Phase II, which is generated from the currently valid source-side authorization state. The target domain accepts the migration request only when the Phase II verification condition holds, requiring source authentication validity, freshness, identity-binding validity, scope admissibility, and revocation clearance. Consequently, a migration request lacking valid source-side authorization material, using expired timing information, violating target domain scope policy, or originating from a revoked DT identity fails before any migration-state export is permitted.

Under this control logic, authorization soundness follows in two respects. First, an adversary cannot introduce an arbitrary DT instance into the target domain without valid migration-bound authorization material. Second, stale or previously valid DT identities cannot be reused after revocation or authorization expiry. Because secure state export in Phase III is conditioned on successful completion of Phase II, an attacker cannot obtain protected target-side migration-state acceptance without first satisfying the target-side legitimacy check.

Hence, under the stated trust assumptions and standard primitive security assumptions, the mechanism enforces cross-domain DT legitimacy and authorization soundness at the migration control level: only a currently valid DT instance with acceptable scope and non-revoked status can pass migration authorization and proceed to the later phases.

5.5. Confidentiality and Integrity of Migration-State Transfer

The second security requirement is that DT migration state be transferred across domains without unauthorized disclosure, tampering, replay, or out-of-scope reuse. Because the migrating DT carries historical data, runtime execution state, and control context, the transfer stage must protect both the confidentiality and integrity of the migrated state.

State export is not permitted unless the migration request has already passed target-side authorization and handoff authentication. Consistent with Phase III, the source domain may export the migration state only if target-side authorization has completed successfully and the corresponding migration-bounded authorization context remains valid for import. This condition provides a first layer of protection: an adversary cannot obtain migration-state transmission merely by triggering a migration decision in Phase I. Instead, the target domain must first admit the DT under a valid migration authorization context. Thus, unauthorized state export is prevented at the protocol level.

After authorization is completed, the source and target domains derive the migration-bounded protection context defined in Phase III, which is then used to protect the packaged migration state. This construction has two important implications. First, the protection context is explicitly bound to the source identity, target identity, source domain, target domain, and fresh migration-specific nonces. Second, it is not a reusable general communication key but a migration-scoped transfer key. Therefore, even if an adversary observes multiple migrations involving the same DT over time, the protection context of one migration event is not directly reusable in another.

The source domain packages and protects the migration state using the migration-bounded protection context, and the target domain accepts the resulting migration package only when the Phase III package acceptance condition holds. This condition requires integrity tag verification, time validity, scope consistency, and transfer sequence freshness.

This validation structure yields the following security properties.

(1)

Confidentiality of migration-state content

Because the migration package is encrypted under the migration-bounded protection context ${\mathcal{K}}_i^{\mathrm{mig}}$, an external adversary observing the inter-domain migration channel cannot directly recover the underlying DT state. In particular, interception of migration traffic does not reveal plaintext access to ${\mathcal{X}}_i^{\mathrm{hist}}\left(t\right)$, ${\mathcal{X}}_i^{\mathrm{run}}\left(t\right)$, or ${\mathcal{X}}_i^{\mathrm{ctx}}\left(t\right)$.

(2)

Integrity and tamper resistance

The integrity tag ${\chi }_i\left(t\right)$ protects the encrypted migration package together with the source identity, target identity, and transfer sequence identifier. Therefore, if an adversary modifies the ciphertext, substitutes one migration package for another, or alters the source–target binding of the package, the condition ${\mathsf{MACVer}}_i\left(t\right)$ fails and the target domain rejects the modified state.

(3)

Replay resistance

Replay protection is achieved through two coordinated checks. First, the migration package remains valid only within its migration-validity window. Second, the package carries a sequence or version identifier whose freshness is checked before acceptance. Together, these checks prevent replay of an earlier valid migration-state package after the migration context has expired or after a newer state package has already been accepted.

(4)

Scope-bounded usability

The target domain does not accept all transferred permission-related state automatically. Instead, transferred permission state is accepted only if it remains consistent with the scope explicitly approved by the target domain. Thus, even a correctly protected-migration-state package cannot be used to activate permissions beyond the scope explicitly accepted by the target domain. The mechanism therefore prevents over-extension of source-side authorization into the target domain.

(5)

Safe restoration precondition

Even after the migration package has been accepted and decrypted, the target domain does not immediately treat the DT as operational. Instead, traffic release is permitted only after the Phase III restoration readiness condition holds. This prevents partial or incomplete state import from being used to force premature target-side service activation.

Under the stated trust assumptions and representative primitive instantiations, these properties support the confidentiality and integrity of migration-state transfer at the migration control level. In particular, migration-state export is authorization-gated, migration-state contents are protected during inter-domain transfer, tampered or replayed packages are rejected, transferred permission state cannot exceed the target-approved scope, and accepted migration state still requires successful restoration before service activation. Migration-state transfer is therefore enforced as a protected, migration-bounded, policy-scoped, and restoration-aware operation.

5.6. Service Continuity and Transition Safety

A central security requirement of the mechanism is that DT migration preserve service continuity during the transition from the source domain to the target domain. Because a stateful DT may be unsafe to continue executing at the source while still being unready at the target, the mechanism must prevent both premature forwarding and uncontrolled request loss during the transition.

This requirement is addressed through the Phase IV continuity control interval, during which the continuity controller activates request retention and transition forwarding for the migrating DT ${\mathrm{DT}}_i$. Request retention is enabled when secure migration-state transfer has been accepted but the target-side DT has not yet reached restoration-ready state. Under this condition, incoming requests are retained under migration control rather than released toward the target-side DT.

This rule provides the first continuity guarantee: requests are held under migration control rather than being prematurely executed. As long as ${\beta }_i\left(t\right)=1$ and ${\mathsf{Ready}}_i^t\left(t\right)=0$, the forwarding mode remains in protected transition rather than direct target-side service mode. Accordingly, the target-side DT cannot receive live service traffic before restoration is complete.

Under the Phase IV release condition, retained requests are released only after the migrated DT has completed restoration and is ready for service activation. At this point, the controller flushes the retained request set, clears the migration buffer, and updates forwarding to target-side service mode. Therefore, the target-side DT becomes the live request-processing endpoint only after the continuity conditions have been satisfied.

From this control logic, the following transition safety properties follow.

(1)

No premature forwarding to an unready target DT

If an adversary or erroneous controller attempts to force traffic toward the target-side DT before restoration completes, the attempt fails under the normal mechanism logic because the target-side service path is not released while ${\mathsf{Ready}}_i^t\left(t\right)=0$. During this interval, the controller keeps the forwarding mode in protected transition and maintains request buffering under migration control. Traffic is therefore intercepted and retained rather than executed by an unready target-side DT instance.

(2)

No request loss during controlled transition

During the continuity interval, the intended continuity property is that requests are not dropped, misrouted, or released before readiness. Because requests arriving during the transition interval are retained rather than discarded, and because the retained-request state is released after readiness is achieved, logical request continuity is preserved throughout migration.

(3)

Safe handoff from source-side execution to target-side execution

The continuity phase ensures that the source-side DT is not relied upon as the continuing live executor once migration transition begins, while the target-side DT is not permitted to become the live executor until restoration completes. Hence, the mechanism avoids the unsafe gap in which the system would otherwise have to choose between an obsolete executor and an unready one.

(4)

Ordering-preserving request release

For buffered requests retained during migration, the Phase IV ordering requirement preserves a causal or service-consistent execution order. This property matters because the DT is stateful: request handling may depend on previous runtime context, cached state, or sequential update semantics. By holding requests during restoration and releasing them only after the target-side state becomes usable, the mechanism reduces the risk of state-inconsistent interleavings.

(5)

Transition safety under restoration delay

If restoration delay increases, the continuity interval also increases. However, service safety is still preserved as long as the request-retention resource remains valid and the release condition is not violated. Thus, continuity degradation appears as bounded waiting rather than invalid execution. The mechanism does not assume zero migration delay; instead, it converts migration delay into a controlled service-transfer interval with retained requests and deferred release.

Under the stated migration control model, these observations support service continuity and transition safety for the proposed mechanism. Requests are not forwarded to the target-side DT before readiness is established; they are retained rather than dropped during migration transition, they are released only after restoration completes, and their ordering remains consistent with stateful execution. In this way, migration delay appears as controlled request retention and deferred release rather than uncontrolled service disruption.

5.7. Post-Migration Uniqueness and Revocation Security

Another essential security property is that after migration, the target-side DT becomes the only valid active execution instance, while stale source-side execution and authorization artifacts are invalidated. Without this property, the system remains vulnerable to dual-active execution and stale context reuse after migration.

Formal target-side activation and service resumption are not declared solely on the basis of successful state restoration or traffic transition. Instead, Phase V requires the activation condition to hold, including valid target-side authorization, active target-side service state, scope-valid operation, and unique active instance recognition. Thus, the target-side DT cannot be regarded as fully active unless no conflicting source-side execution remains visible at activation time.

This yields the first uniqueness guarantee: migration success requires the absence of conflicting active source-side execution at activation time. Under the normal protocol path, an adversary cannot preserve a conflicting source-side DT execution state while simultaneously obtaining a fully activated target-side DT.

After target-side activation is achieved, Phase VI initiates stale instance invalidation using the revocation trigger defined in Section 4. This ordering is important because revocation occurs only after the following:

• The target-side DT has formally resumed service;
• Uniqueness of active execution has been established.

Hence, the mechanism does not revoke the source-side DT prematurely and thereby risk disrupting service before migration has completed successfully.

Once the revocation trigger holds, the source-side execution state is invalidated, source-side authorization validity is revoked, and stale source-bound credential material is no longer permitted to remain usable.

These rules establish the following security properties.

(1)

Dual-active execution prevention

A successful migration leaves the system in a post-revocation condition in which the source-side DT is inactive, the target-side DT is active, source-side authorization is invalid, and target-side authorization remains valid. Hence, the normal protocol outcome excludes the possibility that both the source-side and target-side DT remain simultaneously active under valid authorization.

(2)

Stale permission reuse resistance

Even if an adversary attempts to reuse previously valid source-side migration or access artifacts after target-side activation, the source-side authorization state has already been invalidated. Because future access validation and migration control consult a revocation-aware authorization state, a stale source-side DT cannot continue to participate legitimately after invalidation.

(3)

Revocation-aware future rejection

The revocation event is propagated to the revocation enforcement structure together with the revoked source-side identity and associated metadata, and this identity is inserted into the revocation structure for future validation. Accordingly, any later protocol attempt involving the revoked source-side identity is rejected. This provides persistent revocation memory rather than relying only on immediate teardown.

(4)

Security against duplicate or replayed DT context

The revocation phase covers both ordinary stale instance cleanup and explicitly invalid DT cases, including duplicate, compromised, replayed, or unauthorized DT contexts. Therefore, the same revocation logic that removes the normal stale source-side DT after migration can also be applied to explicitly malicious or otherwise invalid DT instances. This generality matters because both ordinary stale state and explicitly invalid state must be excluded from future participation.

(5)

Completion security

The final migration-completion condition in Phase VI requires target-side resumption, source-side execution invalidation, and source-side authorization invalidation. Thus, migration is not declared complete while stale source-side execution or authorization remains security-relevant. Migration completion itself is therefore revocation-aware.

Under the stated trust and revocation assumptions, these observations support post-migration uniqueness and revocation security at the migration control level. After successful migration, the target-side DT becomes the unique active instance, the source-side execution context and authorization artifacts are invalidated, revoked identities remain available for future rejection, and duplicate, replayed, compromised, or unauthorized DT instances are reduced to revocation-enforced invalid participants. Revocation is therefore an essential completion condition for migration safety and for preventing invalid twin persistence after relocation.

5.8. Resistance to Common Attacks

The foregoing analysis implies resistance to the main protocol-level attacks identified in the threat model. Impersonation and unauthorized cross-domain access are constrained by the authorization gate in Phase II, which requires valid source-side migration credentials together with target-side verification under freshness, identity-binding, scope, and revocation checks. Replay and stale credential reuse are constrained by bounded authorization validity, migration-state freshness checks, and revocation-aware rejection of previously valid source-side identities. Tampering attacks are constrained by integrity-protected migration artifacts and target-side validation of protected state packages. Premature service activation is constrained by readiness-gated transition control in Phase IV, which prevents live request release before restoration completes. Finally, invalid twin persistence is constrained by the revocation and completion logic of Phase VI, which invalidates stale or otherwise invalid source-side execution and authorization state after successful target-side resumption. Accordingly, under the stated control-plane trust model and standard primitive security assumptions, the mechanism resists the main protocol-level attacks considered in this paper through the combined effects of authorization gating, protected-state transfer, continuity-aware transition control, and revocation-aware completion.

6. Performance Evaluation

The proposed secure cross-domain authentication and service continuity mechanism is evaluated in six aspects: migration cost and service efficiency, authentication and secure state transfer overhead, service continuity during DT transition, revocation and completion behavior, stage-wise contribution through ablation analysis, and control-path prototype validation under benign and adversarial migration conditions.

6.1. Evaluation Scope, Implementation Environment, and Baselines

The objective of this evaluation is to determine whether the proposed mechanism preserves the operational benefit of mobility-aware DT migration while incurring acceptable security and continuity overhead. To do so, the evaluation is organized in two complementary layers. First, a controlled simulation study compares staged mechanism variants at the system level under repeated mobility, workload, and DT state conditions. Second, a control-path artifact and timing study quantifies representative artifact sizes and migration control timing costs under the evaluation settings and MATLAB R2024b software and hardware environment reported in

Table 5. Main experimental setup parameters.

Parameter	Value
Number of edge domains	6
Decision horizon	50 time slots; one slot represents 1 s of migration control time
Number of DTs	30
Number of users	90
Mobility model	Random waypoint-style inter-domain mobility with seed-controlled movement traces
Inter-domain one-way delay	5–25 ms, sampled once per source–target domain pair and kept fixed within each matched scenario
Inter-domain bandwidth	100–1000 Mbps, sampled per source–target domain pair and kept fixed within each matched scenario
Effective bandwidth model	Nominal source–target bandwidth is converted to effective migration goodput using residual bandwidth share, protocol-overhead factor, retransmission/congestion penalty, and queueing delay terms defined in Section 3; matched traces are shared across schemes
DT state size	50–500 MB
DT state composition	70% historical DT state, 25% runtime checkpoint/context, and 5% permission/control metadata
Continuity timeout and recovery policy	Maximum transition budget $T_i^{\max }=2.5$ s; buffer limit $B_i^{\max }=\lceil {\lambda }_i^{\max }{T}_i^{\max }\rceil$; one protected-transfer retry with a fresh sequence identifier before final migration abort
Migration trigger	Migration is triggered when the estimated stay cost exceeds the best feasible migration cost by more than 15%, or when source-domain resource pressure exceeds 0.85
Request arrival rate	5–30 requests/s per active DT
Cost-weight parameters	Fixed across all schemes and runs: $\alpha =0.30$, $\beta =0.30$, $\gamma =0.25$, $\delta =0.15$ after component normalization; migration trigger uses a 15% migration benefit margin and source-load threshold ${\rho }_{\max }=0.85$
Request model	Independent Poisson request arrivals with common random numbers across compared schemes
Matched simulation runs per condition	50 matched scenario seeds per condition and per scheme
Simulation software	MATLAB R2024b with Statistics and Machine Learning Toolbox R2024b
Host hardware	Intel Core i9-13900HX CPU, 32 GB RAM, NVIDIA GeForce RTX 4070 GPU 8 GB, Windows 11 64-bit; GPU not used for reported control-path timing
Repeated-run design	Matched mobility, request-arrival, state size, bandwidth, and delay traces across all compared schemes; residual randomness controlled by fixed run seeds
Random-seed policy	Base seed 20260425; run seed = 20260425$+r$ for matched scenario run $r\in \{1,\dots ,50\}$
Statistical reporting	Mean, standard deviation, 95% confidence interval, and paired comparison across matched runs where applicable

and

Table 6. Evaluation environment and representative control-path artifacts.

Item	Value
Evaluation framework	MATLAB-based simulation and timing model for migration control logic, event-driven request arrivals, queue-based buffering, protected-transfer overhead, and six-phase migration-state progression
Software version	MATLAB R2024b with Statistics and Machine Learning Toolbox R2024b
Operating system	Windows 11 64-bit
Execution hardware	Intel Core i9-13900HX CPU, 32 GB RAM, NVIDIA GeForce RTX 4070 Laptop GPU 8 GB; GPU not used for reported control-path timing
Serialization format	Fixed-length binary serialization with deterministic field ordering; JSON and text encoding are not used for reported artifact sizes
KDF primitive	HKDF-SHA-256 parameterization with 256-bit output key material
Protected transfer primitive	AES-256-GCM-style protected-transfer metadata with 96-bit nonce and 128-bit authentication tag
Control-plane authentication primitive	Ed25519-style 64-byte signature artifact for source and target control artifacts
Migration credential size	168 bytes
Target authorization token size	200 bytes
Protected transfer metadata size	160 bytes, excluding the encrypted DT state payload
Revocation update artifact size	168 bytes
Control-path timing method	Each representative control-path operation is evaluated for 1000 repetitions after 100 warm-up repetitions; median and mean timing values are recorded, and scenario-level results use the measured mean operation cost

. Together, these layers are used to evaluate system-level behavior, stage-wise contribution, and representative control-path overhead under repeated conditions.

The evaluation separates authentication path comparison from migration lifecycle attribution. Recent cross-domain authentication schemes are used as external comparators for the shared authorization control function, where direct comparison is technically meaningful. The complete migration control behavior is then evaluated through B1–B5, which progressively enable target-side authorization, protected-state transfer, continuity-aware transition, and revocation-aware completion under identical topology, mobility, workload, DT state, and network conditions. This structure allows the authorization component to be compared with independent recent schemes while preserving controlled attribution of the end-to-end lifecycle functions introduced by the proposed mechanism.

In the controlled simulation layer, all compared schemes are evaluated in the same multi-domain edge environment with identical topology, mobility process, workload, and resource settings. Each physical entity is associated with one DT instance hosted at an edge domain, and a migration event corresponds to transferring DT state from a source domain to a target domain before service resumption. Unless otherwise stated, reported values are computed over 50 repeated simulation runs per condition. For cross-scheme comparison within a condition, runs are matched by shared scenario realization, while scheme-specific residual randomness is introduced separately. The reported uncertainty therefore reflects repeated matched-scenario evaluation rather than unrelated scheme-wise Monte Carlo batches.

In the control-path overhead layer, the source-side migration credential, target-side authorization token, protected-state transfer metadata, and revocation-related control artifacts are represented using fixed-size deterministic artifact layouts and evaluated under the software and hardware configuration reported in Table 6. Unless explicitly varied in a given experiment, the migration trigger thresholds and cost-weighting parameters are held fixed across all compared schemes so that reported differences reflect the added control stages rather than changes in migration decision policy. The implementation-backed validation reported later in this section records executable phase events, request traces, and attack outcomes to verify that the proposed control stages produce the intended protocol behavior under benign and adversarial migration conditions.

The evaluation remains a controlled simulation and control-path timing study rather than a deployment on a full real-world DT platform or physical edge testbed. Deployment-level validation across heterogeneous edge hardware and production DT middleware is left as future work.

The environment-specific timing measurements reported later in this section are obtained under the software and hardware configuration listed in Table 6, whereas the broader staged comparisons across mobility conditions and mechanism variants are obtained from the controlled simulation layer described above.

Table 7. Baseline configuration summary.

Scheme	Migration	Auth.	Secure Transfer	Continuity	Revocation
B1	√	×	×	×	×
B2	√	√	×	×	×
B3	√	√	√	×	×
B4	√	√	√	√	×
B5	√	√	√	√	√

√: enabled; ×: not enabled.

summarizes the staged baseline configurations used to isolate the contribution of each migration control function.

The main reported metrics are total migration-related cost, authentication latency, secure transfer latency, communication overhead, service interruption time, transition request-handling success ratio, and post-transition completion delay. For the cost comparison in Figure 3a, the plotted component and total cost values are expressed relative to the mean total migration-related cost of B5 under the same evaluation setting so that cross-scheme differences can be displayed on a common scale. For the mobility sensitivity analysis, mobility intensity is varied through the per-slot inter-domain transition probability, using representative levels of 0.05, 0.10, 0.15, 0.20, and 0.25 for Very Low, Low, Medium, High, and Very High mobility, respectively. Unless otherwise stated, the reported values are means over 50 matched simulation runs per condition. Statistical summaries are reported using mean, standard deviation, and 95% confidence interval, and paired comparison across matched runs is used where cross-scheme significance is discussed. The latency and continuity results reported in the subsequent subsections are measured directly from the corresponding migration phases of the proposed mechanism. For clarity, the reported phase-level metrics are defined as follows. Authentication latency is the wall-clock duration of the Phase II authorization procedure from target-side authorization start to authorization completion. Secure transfer latency is the wall-clock duration of the Phase III protected-migration-state transfer procedure; it is therefore treated as an end-to-end transfer-stage latency rather than as an isolated cryptographic micro-benchmark, and includes migration-state packaging, protection, inter-domain transmission, and target-side validation within the modeled transfer stage. Service interruption time is defined as the service-level transition gap induced by migration control, rather than the maximum holding time of an individual buffered request. Transition request-handling success ratio is defined as the fraction of requests arriving during the transition interval that are ultimately handled correctly under the intended migration control logic, including requests retained and safely released after readiness-gated transition, rather than only requests served immediately upon arrival. Post-transition completion delay is measured from formal target-side activation to completion of the remaining end-of-migration control actions under the evaluated scheme. In the full mechanism, this interval includes revocation-aware finalization.

For the cost-related metrics, the reported values are dimensionless weighted cost-index values rather than monetary cost, energy consumption, byte volume, or wall-clock latency. The synchronization, service, migration-state transfer, and load-pressure components are computed from the normalized latency/distance, DT state volume, bandwidth, and resource pressure quantities defined in the simulation setup and in the Phase I cost model. These normalized component scores are then combined using the fixed weighting parameters used consistently across all compared schemes. Hence, the absolute values in the service cost plots should be interpreted as model-based weighted cost-index values under the stated simulation setting. In Figure 3a, the component and total migration-related costs are further normalized by the mean total migration-related cost of B5 under the same evaluation setting, so that B5 has a reference value of 100 and the other schemes are reported relative to that reference. In Figure 3b, the total service cost is reported directly in the same dimensionless weighted cost-index units without B5 normalization.

6.2. Migration Cost and Service Efficiency

This subsection evaluates how the proposed mechanism affects migration cost and service efficiency after cross-domain authorization, protected-state transfer, continuity-aware traffic transition, and stale instance invalidation are introduced. The analysis focuses on how the total migration-related cost changes across schemes and how the overall service cost evolves as mobility intensity increases.

Figure 3a shows a monotonic increase in total migration-related cost from B1 to B5 when expressed relative to the B5 reference level. The mean normalized totals are 94.20 for B1, 95.83 for B2, 97.79 for B3, 98.81 for B4, and 100.00 for B5. The ordering is consistent with scheme composition. B1 performs mobility-aware DT migration with minimal control functionality, whereas B5 includes target-side authorization, protected-state transfer, continuity-aware transition handling, and revocation-aware completion. The key question is whether the additional cost remains controlled once these stages are enabled.

The component-wise breakdown in Figure 3a shows that the increase is moderate and broadly distributed across synchronization, migration, and service terms. Synchronization remains the dominant component across all schemes, while the migration and service terms increase only incrementally as additional control stages are enabled. No single component exhibits disproportionate growth. The added mechanism therefore does not alter the basic operational structure of mobility-aware DT migration. The dominant migration cost structure remains placement-dependent, while the additional control logic contributes only a limited cost increment.

Figure 3b shows the effect of mobility intensity on total service cost. For all schemes, the cost increases steadily as mobility rises from Very Low to Very High, consistent with the increasing mismatch among physical object location, DT location, and user location. The ordering remains stable across the full mobility range: B1 yields the lowest service cost, followed by B2, B3, and B4, while B5 remains the highest. At low mobility, the gap between B1 and B5 is small; at higher mobility, the absolute gap becomes more visible.

Table 8. Repeated-run statistical summary for the normalized total migration-related cost in Figure 3a.

Scheme	Mean	SD	95% CI
B1	94.20	1.02	94.20 ± 0.29
B2	95.83	1.45	95.83 ± 0.41
B3	97.79	1.15	97.79 ± 0.33
B4	98.81	1.27	98.81 ± 0.36
B5	100.00	1.27	100.00 ± 0.36

reports the corresponding repeated-run statistics for the normalized total cost, showing that the mean separation among schemes is accompanied by relatively narrow 95% confidence intervals over the 50 matched runs.

Table 9. Repeated-run statistical summary for the total service cost in Figure 3b. Values are reported in dimensionless weighted cost-index units as mean ± 95% confidence interval over 50 matched runs.

Mobility Level	B1	B2	B3	B4	B5
Very Low	66.26 ± 0.21	67.35 ± 0.29	68.34 ± 0.31	68.92 ± 0.28	69.75 ± 0.32
Low	71.65 ± 0.38	73.25 ± 0.41	74.32 ± 0.29	74.88 ± 0.35	75.69 ± 0.38
Medium	85.04 ± 0.37	86.90 ± 0.35	88.27 ± 0.35	89.08 ± 0.32	89.95 ± 0.35
High	102.73 ± 0.45	104.50 ± 0.43	106.62 ± 0.47	107.91 ± 0.44	109.16 ± 0.52
Very High	119.11 ± 0.43	121.60 ± 0.44	123.93 ± 0.39	125.22 ± 0.48	126.88 ± 0.42

reports the corresponding repeated-run statistics, showing that the monotonic increase in service cost with mobility intensity is consistent across 50 matched runs and remains accompanied by relatively narrow 95% confidence intervals for all compared schemes.

This behavior indicates that the proposed mechanism does not alter the fundamental mobility sensitivity of the system, but adds a moderate additional control cost whose effect becomes more visible as mobility increases and migration is invoked more frequently. Under weak mobility, the added control stages have limited observable impact. Under stronger mobility, the cumulative effect of authorization, protected transfer, request retention before readiness-gated release, and revocation-aware completion becomes more pronounced. The incremental separation among the curves therefore widens moderately with mobility intensity while remaining ordered and operationally bounded.

Taken together, Figure 3a,b show that the full mechanism incurs the highest but still bounded migration-related cost, while preserving the mobility-aware service efficiency trend across all tested mobility levels.

6.3. Mobility Realism Sensitivity Check

Because the main evaluation uses a random waypoint-style inter-domain mobility process, we further examined whether the principal mobility-related conclusions remain stable under a more constrained trajectory assumption. Since the evaluation concerns cross-domain DT migration rather than a specific city, road, or indoor-tracking deployment, we did not assume that an external trace dataset from an unrelated mobility setting would directly represent DT domain transitions. Instead, we generated an adjacency-constrained inter-domain trajectory set in which DT-associated entities remain within the current domain with high probability and may transition only to adjacent domains when movement occurs. This trajectory set is more restrictive than the original random waypoint-style process because it prevents arbitrary jumps across non-adjacent domains and better reflects domain-local movement with occasional boundary crossing. All other evaluation settings, including topology, workload, DT state conditions, migration trigger policy, and matched-run statistical reporting, were kept unchanged.

Figure 4 compares the resulting service cost and continuity-sensitive outcomes under the original mobility process and the adjacency-constrained trajectory set. This check evaluates whether the main scheme ordering and continuity-related benefit remain stable when inter-domain movement is constrained by domain adjacency rather than sampled freely across all domains.

The sensitivity results in Figure 4 show that the constrained mobility process slightly reduces the absolute metric values but does not alter the scheme ordering. In Figure 4a, total service cost still increases monotonically with mobility intensity for all compared schemes, and no curve crossover is observed between the original and constrained mobility settings. At the highest mobility level, the mean total service cost decreases from 119.11 to 114.59 for B1, from 123.93 to 119.22 for B3, and from 126.88 to 122.06 for B5. Thus, the adjacency-constrained process changes the absolute cost level, but the relative ordering B1 < B3 < B5 remains unchanged. The result indicates that the additional control cost associated with the more complete migration control configurations remains bounded under both mobility assumptions.

A similar pattern appears in Figure 4b. Under both mobility models, B3 remains substantially worse than the continuity-controlled configurations, while B5 retains a modest interruption advantage over B4. At 200 MB, the mean interruption time changes from 886.79 ms to 846.89 ms for B3, from 183.04 ms to 176.64 ms for B4, and from 162.86 ms to 157.49 ms for B5. At 500 MB, the corresponding values change from 1794.37 ms to 1704.65 ms for B3, from 321.00 ms to 308.16 ms for B4, and from 284.91 ms to 274.09 ms for B5. Hence, the constrained mobility process lowers the absolute interruption levels slightly, but it does not remove the large continuity gap between secure transfer without transition control and the continuity-aware configurations. These results indicate that the continuity benefit of the proposed mechanism remains visible under the stronger mobility assumption.

6.4. Authentication and Secure Transfer Overhead

This subsection evaluates the overhead introduced by the security-specific stages of the proposed mechanism, namely cross-domain authorization in Phase II and protected-migration-state transfer in Phase III. The focus is on whether these stages remain operationally bounded as control-plane load and migration-state size increase.

Figure 5a reports authentication latency under three control-plane load levels for schemes B2–B5. Each point represents the mean over 50 matched runs, and the error bars denote the corresponding 95% confidence intervals. The control-plane request rates are 20, 50, and 100 requests/s for the low-, medium-, and high-load conditions, respectively. Under medium load, the mean authentication latency increases from 7.84 ms in B2 to 8.26 ms in B5, while the corresponding low- and high-load ranges remain 7.08–7.63 ms and 8.61–9.09 ms across the same scheme progression. The confidence intervals remain narrow throughout, indicating stable repeated-run behavior under all tested load levels.

Phase II is therefore weakly sensitive both to the addition of later migration control stages and to moderate increases in control-plane pressure. The dominant operations of this phase—credential validation, freshness checking, scope admissibility verification, and target-side authorization issuance—are already determined once target-side admission is enabled. Subsequent additions in B3–B5 do not substantially alter the work performed in this phase. The authorization stage therefore contributes a small and structurally stable delay across the compared configurations. Phase II also acts as the admission-control gate of the migration procedure. Strong scheme sensitivity at this stage would imply cumulative control-path sensitivity under repeated migration events. Figure 5a does not exhibit such behavior. Authorization cost does not compound as secure transfer, continuity control, and revocation-aware completion are progressively added. The effect of moving from B2 to B5 remains incremental rather than multiplicative. Accordingly, the secure transfer latency reported in Figure 5b should be interpreted as the modeled end-to-end Phase III transfer-stage latency rather than as isolated cryptographic processing overhead alone.

Table 10. Repeated-run statistical summary for the authentication latency in Figure 5a. Values are reported as mean ± 95% confidence interval over 50 matched runs.

Control-Plane Load	B2	B3	B4	B5
Low (20 req/s)	7.08 ± 0.10	7.31 ± 0.08	7.40 ± 0.08	7.63 ± 0.10
Medium (50 req/s)	7.84 ± 0.10	7.93 ± 0.07	8.00 ± 0.07	8.26 ± 0.09
High (100 req/s)	8.61 ± 0.09	8.79 ± 0.09	8.89 ± 0.09	9.09 ± 0.09

reports the corresponding repeated-run statistics, showing that the mean separation among schemes remains small and is accompanied by narrow 95% confidence intervals under all three tested load levels.

Table 11. Representative operating point summary for authentication, protected transfer, and control-plane signaling overhead. Authentication latency is reported at the medium-load operating point (50 requests/s), and secure transfer latency is reported at the 200 MB DT state operating point.

Scheme	Target Auth.	Prot. Transfer	Auth. Latency (50 req/s, ms)	Transfer Latency (200 MB, ms)	Control Signaling Overhead (KB)
B1	×	×	0.00	0.00	0.00
B2	√	×	7.84	0.00	0.75
B3	√	√	7.93	13.17	2.30
B4	√	√	8.00	13.85	2.42
B5	√	√	8.26	14.44	2.56

√: enabled; ×: not enabled.

provides a representative operating-point summary using the medium-load authentication latency, the 200 MB secure transfer latency, and the total control-plane signaling overhead. The latency values in this table are therefore representative operating-point values rather than averages over the full load or state size range. By contrast, the signaling overhead values report the total control-plane artifact volume associated with the enabled stages. The dominant communication increase occurs when protected transfer is first enabled. The signaling overhead rises from 0.75 KB in B2 to 2.30 KB in B3, reflecting the introduction of the protected-migration-state exchange and its associated control metadata. Thereafter, the growth is limited, reaching 2.42 KB in B4 and 2.56 KB in B5. The principal communication cost is therefore attributable to enabling protected transfer itself, whereas continuity-aware transition control and revocation-aware completion add comparatively little signaling.

Table 12. Quantitative comparison with recent independent cross-domain authentication schemes on the shared authorization control path and lifecycle control coverage. The lifecycle coverage score is computed over the seven dimensions defined in Table 1, using Y = 1, P = 0.5, and N = 0.

Scheme	Comparable Control/Auth. Communication	Comparable Control/Auth. Latency	Lifecycle Coverage Score	Technical Interpretation
Proposed authorization path/full lifecycle mechanism	768 B	7.84 ms	7.0/7	The authorization path overhead remains lightweight, while the full mechanism additionally covers mobility-aware migration, protected DT state transfer, continuity-aware transition, formal activation control, and revocation-aware completion.
Chen et al. [26]	≈1.25 KB	69.34 ms	1.5/7	Supports cross-domain authentication and secure data sharing, but does not provide lifecycle-complete control of stateful DT migration. In the related work scoring of Table 1, it covers cross-domain authorization and partially overlaps with protected-transfer functionality only.
Liu et al. [29]	760 B	–	1.0/7	Provides efficient MEC-assisted cross-domain authentication with batch verification and anonymity support, but does not address migration triggering, protected DT state relocation, continuity-aware transition, formal activation, or stale source invalidation.

compares the proposed mechanism with recent independent cross-domain authentication schemes on the shared authorization control path. At the representative operating point, the proposed authorization path requires 768 B of control-plane signaling and 7.84 ms authentication latency. Chen et al. [26] report approximately 1.25 KB communication overhead and 69.34 ms computational overhead for cross-domain authentication initiation, whereas Liu et al. [29] report 760 B for their cross-domain request/verification and authentication/key-agreement path. These results indicate that the proposed authorization path remains within the lightweight range of recent cross-domain authentication mechanisms while adding only the control functionality needed for stateful DT migration. The lifecycle coverage score further shows that the proposed mechanism extends beyond authentication by incorporating protected DT state relocation, readiness-gated transition, formal activation, and stale source invalidation within one ordered migration procedure.

Figure 5b shows that the behavior of the secure transfer stage is governed primarily by DT state size. Each point represents the mean over 50 matched runs, and the error bars denote the corresponding 95% confidence intervals. For all schemes that include protected-migration-state transfer, latency rises monotonically as the migration-state volume increases from 50 MB to 500 MB. The ordering remains stable across the full range, with B3 yielding the lowest secure transfer latency, followed by B4 and B5. At 500 MB, the mean latency increases from 22.01 ms in B3 to 23.24 ms in B4 and 24.47 ms in B5. The more complete schemes therefore do incur additional transfer overhead, but the increase remains moderate relative to the underlying growth induced by state volume itself.

Once Phase III is activated, the dominant cost arises from migration-state packaging, confidentiality and integrity protection, inter-domain transmission, target-side validation, and restoration preparation. The later control stages interact with the transferred state, but they do not alter the principal scaling behavior of the secure transfer path. Secure transfer latency remains mainly state volume-dependent, while only weakly reflecting the added control structure of B4 and B5.

Table 13. Repeated-run statistical summary for the secure transfer latency in Figure 5b. Values are reported as mean ± 95% confidence interval over 50 matched runs.

DT State Size (MB)	B3	B4	B5
50	8.62 ± 0.07	9.02 ± 0.06	9.46 ± 0.08
100	10.15 ± 0.10	10.68 ± 0.09	11.14 ± 0.08
200	13.17 ± 0.11	13.85 ± 0.12	14.44 ± 0.12
300	15.92 ± 0.13	16.96 ± 0.12	17.73 ± 0.13
500	22.01 ± 0.22	23.24 ± 0.28	24.47 ± 0.23

reports the corresponding repeated-run statistics, showing that the monotonic increase in secure transfer latency with DT state size is consistent across 50 matched runs and remains accompanied by relatively narrow 95% confidence intervals for all compared schemes.

Overall, cross-domain authorization introduces a small and stable delay, while secure transfer latency is governed mainly by DT state size. Enabling the full mechanism does not produce abrupt latency or signaling inflation; the additional overhead remains moderate relative to the added authorization, transfer-protection, continuity, and completion functions.

6.5. Service Continuity Performance

This subsection evaluates whether continuity-aware migration control reduces service disruption during DT transition. Two outcomes are considered: interruption time during migration and the proportion of requests successfully handled throughout the transition. Because a larger DT state increases restoration burden, both metrics are reported as functions of DT state size.

In this subsection, interruption time refers to the service-level transition gap associated with migration control rather than the worst holding time of an individual buffered request. Likewise, the transition request-handling success ratio refers to correct handling throughout the transition interval, including requests retained under continuity control and safely released after restoration readiness, rather than only requests served immediately when they arrive.

Figure 6a evaluates the service interruption time as the DT state size increases from 50 MB to 500 MB, while Figure 6b reports the corresponding transition request-handling success ratio. Each point represents the mean over 50 matched runs, and the corresponding 95% confidence intervals are reported in

Table 14. Repeated-run statistical summary for the service interruption time in Figure 6a. Values are reported as mean ± 95% confidence interval over 50 matched runs.

DT State Size (MB)	B3	B4	B5
50	422.21 ± 6.08	114.99 ± 1.38	100.37 ± 1.04
100	577.86 ± 7.30	138.31 ± 1.50	122.00 ± 1.24
150	727.98 ± 10.50	161.66 ± 1.87	140.97 ± 1.41
200	886.79 ± 11.85	183.04 ± 1.80	162.86 ± 1.75
300	1190.01 ± 14.83	229.49 ± 2.71	204.01 ± 2.19
500	1794.37 ± 22.01	321.00 ± 3.12	284.91 ± 2.52

and

Table 15. Repeated-run statistical summary for the transition request-handling success ratio in Figure 6b. Values are reported as mean ± 95% confidence interval over 50 matched runs.

DT State Size (MB)	B3 (%)	B4 (%)	B5 (%)
50	91.83 ± 0.13	98.73 ± 0.06	99.09 ± 0.06
100	88.47 ± 0.23	97.89 ± 0.06	98.46 ± 0.05
150	86.50 ± 0.25	97.42 ± 0.06	98.12 ± 0.06
200	85.03 ± 0.27	97.05 ± 0.05	97.88 ± 0.05
300	83.15 ± 0.28	96.60 ± 0.07	97.46 ± 0.06
500	80.93 ± 0.39	95.96 ± 0.10	97.01 ± 0.05

.

As shown in Figure 6a, the interruption time increases with DT state size for all schemes, but the increase is substantially smaller when continuity-aware control is incorporated. At 50 MB, B3, B4, and B5 achieve mean interruption times of 422.21, 114.99, and 100.37 ms, respectively. At 500 MB, these values increase to 1794.37, 321.00, and 284.91 ms. This confirms that the continuity-oriented transition control in B4 and the full completion handling in B5 substantially reduce service disruption compared with B3, which lacks the full continuity mechanism.

The approximately monotonic increase with DT state size should be interpreted in light of the protected-state-transfer evaluation model used in this study. The reported results use the uncompressed transferable DT state volume ${\mathrm{\Phi }}_i\left(t\right)$ and do not apply compression before encryption. This choice keeps the comparison focused on the proposed migration control stages rather than on payload-reduction techniques. Lightweight compression, dirty-page filtering, or incremental checkpoint reduction could be incorporated before protected transfer by replacing ${\mathrm{\Phi }}_i\left(t\right)$ with a reduced effective state volume, but such compression is not enabled in the reported measurements.

Table 14 makes the statistical spread explicit. For example, at 500 MB, B5 achieves 284.91 ± 2.52 ms (95% CI), compared with 321.00 ± 3.12 ms for B4 and 1794.37 ± 22.01 ms for B3. Paired matched-run comparisons further show that the B5–B4 and B4–B3 differences are statistically significant across all tested DT state sizes ($p<0.001$).

Figure 6b shows that the transition request-handling success ratio decreases gradually as the DT state size increases, but B4 and B5 preserve consistently high success levels. At 50 MB, the mean success ratios are 91.83% for B3, 98.73% for B4, and 99.09% for B5. At 500 MB, the corresponding values are 80.93%, 95.96%, and 97.01%. These results indicate that continuity-aware buffering and controlled forwarding stabilize the transition process under larger DT payloads, while the final completion and revocation handling in B5 provides an additional, though smaller, improvement over B4.

The detailed statistics in Table 15 show that the confidence intervals remain narrow across all operating points. At 500 MB, for example, B5 attains 97.01 ± 0.05% (95% CI), compared with 95.96 ± 0.10% for B4 and 80.93 ± 0.39% for B3. These results confirm that the proposed mechanism maintains robust service continuity and reliable transition handling even as the transferred DT state becomes larger.

6.6. Revocation and Completion Performance

This subsection evaluates the additional delay introduced by the revocation-aware completion stage after DT transition. The purpose of this phase is not to accelerate migration but to ensure that stale source-side execution states are invalidated in a controlled manner once the target-side DT has been activated. To isolate this effect, the evaluation compares B4 and B5, where B5 extends B4 by adding the final revocation-aware completion procedure. The metric reported is the post-transition completion delay measured as a function of DT state size.

Here, post-transition completion delay denotes the elapsed time from formal target-side activation to completion of the remaining migration-finalization actions. In B5, this interval includes revocation-aware stale instance invalidation.

Figure 7 shows that post-transition completion delay increases with DT state size for both schemes, but this increase is substantially larger under B5 because stale instance invalidation and completion-side cleanup are explicitly executed. Under B4, the mean completion delay increases from 19.04 ms at 50 MB to 41.18 ms at 500 MB. Under B5, the corresponding delay increases from 44.27 ms to 91.40 ms. Thus, the revocation-aware completion stage introduces an additional overhead, but this overhead remains bounded and grows in a stable manner with DT state size.

The numerical results are reported in

Table 16. Repeated-run statistical summary for the post-transition completion delay in Figure 7. Values are reported as mean ± standard deviation, with 95% confidence interval half-widths in parentheses, over 50 matched runs.

DT State Size (MB)	B4	B5	$\Delta$ (B5–B4) (ms)	Paired p-Value
50	19.04 ± 1.43 (±0.41)	44.27 ± 3.25 (±0.92)	25.23	<$0.001$
100	21.30 ± 1.79 (±0.51)	48.49 ± 3.56 (±1.01)	27.19	<$0.001$
150	23.70 ± 2.03 (±0.58)	55.23 ± 4.42 (±1.26)	31.52	<$0.001$
200	26.12 ± 2.03 (±0.58)	58.63 ± 2.95 (±0.84)	32.51	<$0.001$
300	31.26 ± 2.28 (±0.65)	69.79 ± 5.37 (±1.53)	38.53	<$0.001$
500	41.18 ± 2.65 (±0.75)	91.40 ± 6.93 (±1.97)	50.22	<$0.001$

. The additional delay of B5 over B4 ranges from 25.23 ms at 50 MB to 50.22 ms at 500 MB. This behavior is expected because B5 performs explicit stale instance invalidation and completion confirmation, whereas B4 terminates after a continuity-controlled transition without the final revocation-aware cleanup phase. Importantly, the measured overhead remains at the millisecond scale across all evaluated state sizes.

The statistical results further confirm that the difference between B4 and B5 is systematic rather than incidental. Across all tested DT state sizes, paired matched-run comparisons indicate statistically significant differences between the two schemes ($p<0.001$ in all cases). The 95% confidence intervals are narrow for both schemes, indicating stable behavior over the 50 matched runs.

These results show that revocation-aware completion adds measurable but controlled overhead in exchange for explicit stale source invalidation and stronger migration-finalization correctness.

6.7. Ablation Study

This subsection isolates the contribution of the main migration control stages by comparing the staged scheme progression from B1 to B5. The ablation focuses on four quantities: normalized total migration-related cost, security-stage latency at representative operating points, service interruption time at 200 MB and 500 MB, and post-transition completion delay at the same two DT state sizes. Figure 8 reports the corresponding mean values over 50 matched runs, while

Table 17. Repeated-run statistical summary for the ablation study quantities in Figure 8. Values are reported as mean ± 95% confidence interval over 50 matched runs. A dash indicates that the corresponding stage is not active in that scheme.

Scheme	Norm. Cost (%)	Auth. Lat. (ms)	Transfer Lat. (ms)	Interruption 200 MB (ms)	Interruption 500 MB (ms)	Completion 200 MB (ms)	Completion 500 MB (ms)
B1	94.20 ± 0.29	–	–	938.04 ± 10.62	1897.74 ± 21.75	22.78 ± 0.44	31.29 ± 0.54
B2	95.83 ± 0.41	7.84 ± 0.10	–	907.30 ± 12.90	1841.07 ± 23.27	25.12 ± 0.45	33.69 ± 0.51
B3	97.79 ± 0.33	7.93 ± 0.07	13.17 ± 0.11	886.79 ± 11.85	1794.37 ± 22.01	28.76 ± 0.54	38.84 ± 0.77
B4	98.81 ± 0.36	8.00 ± 0.07	13.85 ± 0.12	183.04 ± 1.80	321.00 ± 3.12	26.12 ± 0.58	41.18 ± 0.75
B5	100.00 ± 0.36	8.26 ± 0.09	14.44 ± 0.12	162.86 ± 1.75	284.91 ± 2.52	58.63 ± 0.84	91.40 ± 1.97

provides the exact repeated-run statistical summary with 95% confidence intervals.

Figure 8a summarizes the cumulative cost effect of progressively enabling the migration control stages. The normalized total migration-related cost increases from 94.20 in B1 to 100.00 in B5, with each adjacent step remaining relatively small. Paired matched-run comparisons confirm that the successive cost increments are systematic rather than incidental (all adjacent comparisons $p<0.001$). Thus, the full mechanism represents a controlled extension of the migration process rather than a structural cost shift.

Figure 8b isolates the entry points of the security-stage overhead. At the representative medium-load operating point, authentication latency appears when target-side authorization is introduced in B2 and changes only marginally from B2 to B4 (7.84, 7.93, and 8.00 ms). The B2–B3 and B3–B4 differences are small and not statistically significant at the matched-run level ($p=0.093$ and $p=0.098$, respectively), whereas the increase from B4 to B5 is modest but significant ($p<0.001$), yielding 8.26 ms in the full mechanism. Secure transfer latency appears when protected-migration-state transfer is introduced in B3, and then rises from 13.17 ms in B3 to 13.85 ms in B4 and 14.44 ms in B5 at the representative 200 MB operating point, with both adjacent increases statistically significant ($p<0.001$). The panel therefore shows that the dominant security-stage costs appear when the relevant functions are first enabled, while later stages add comparatively modest additional latency.

Figure 8c shows the ablation result for service interruption time at representative and stress DT state sizes. The dominant discontinuity appears between B3 and B4. At 200 MB, the mean interruption time decreases from 886.79 ms in B3 to 183.04 ms in B4 and further to 162.86 ms in B5. At 500 MB, the corresponding values are 1794.37 ms, 321.00 ms, and 284.91 ms. The B3–B4 reduction is overwhelmingly dominant and statistically significant at both operating points ($p<0.001$), identifying continuity-aware transition control as the principal source of the continuity gain. The further reduction from B4 to B5 is smaller but still statistically significant ($p<0.001$), indicating that the full phase ordering yields the most stable transition behavior under both moderate and heavier migration conditions.

Figure 8d shows the corresponding ablation result for post-transition completion delay. Here, the main discontinuity appears at B5. At 200 MB, B1–B4 remain within a comparatively low completion delay band of 22.78–28.76 ms, with B4 slightly below B3, whereas B5 rises sharply to 58.63 ms. At 500 MB, the corresponding B1–B4 range is 31.29–41.18 ms, while B5 rises to 91.40 ms. The dominant B4–B5 jump is statistically significant at both operating points ($p<0.001$), showing that the revocation-aware completion stage introduces a measurable but bounded completion-stage cost in exchange for explicit stale instance invalidation and stronger post-migration finalization.

Taken together, Figure 8 and Table 17 identify the functional role of each migration control stage. The progression from B1 to B3 accounts primarily for bounded increases in migration and security-stage overhead. The progression from B3 to B4 yields the dominant improvement in transition continuity. The progression from B4 to B5 adds a bounded completion-stage cost in exchange for explicit stale instance removal and stronger post-migration finalization. The ablation therefore confirms that the proposed mechanism is realized through an ordered migration control sequence, in which each stage contributes a distinct and measurable lifecycle function.

6.8. Implementation-Backed Control-Path Validation

To examine the executable behavior of the proposed lifecycle control logic, we implemented a lightweight migration control prototype and recorded its operation under benign and adversarial migration conditions. The prototype records migration requests, authorization outcomes, protected-transfer events, transition-time request handling, activation decisions, revocation outcomes, and attack handling results. The resulting log bundle comprised 49 manifest entries, 39 summarized runs, 320 phase event records, 8089 request trace records, and 18 attack attempt records.

Table 18. Prototype-run accounting for the control-path prototype validation.

Scheme	Benign Runs Included	Benign Runs Excluded	Attack Attempts
B3	6	2	1
B4	7	3	7
B5	9	5	9

summarizes the scheme-level prototype-run accounting. The prototype was executed as a lightweight multi-service control-path realization that records run manifests, phase events, request traces, and attack outcomes. These records are used to examine whether the ordered migration stages observed in the simulation also appear in executable control-path traces.

Figure 9a shows that in the recorded benign prototype runs, B3 exhibits the weakest transition handling as DT state size increases, whereas B4 and B5 maintain full handled-request behavior across the tested operating points. Figure 9b shows that B5 incurs a higher post-transition completion delay than B4, which is consistent with the additional revocation-aware completion actions executed after formal target-side activation.

The broader benign prototype summaries in

Table 19. Benign control-path prototype summary. Values are descriptive means over the included prototype runs for each scheme and DT state size.

Scheme	DT State (MB)	n	Transfer (ms)	Service Gap (ms)	Handled Ratio (%)	Completion Delay (ms)
B3	50	2	80.02	180.28	97.82	24.92
B3	200	2	494.96	660.31	86.90	25.99
B3	500	2	1669.88	1957.16	64.02	31.70
B4	50	2	73.69	141.18	100.00	23.21
B4	200	3	398.60	518.50	100.00	24.04
B4	500	2	1651.57	1959.57	100.00	32.62
B5	50	3	75.31	167.16	100.00	38.76
B5	200	3	397.80	543.57	100.00	47.39
B5	500	3	1355.59	1649.31	100.00	61.74

show a similar qualitative pattern. Transfer wall-clock latency and the service-level transition gap both increase with DT state size in the recorded prototype runs. The main continuity distinction in the prototype results is reflected in the handled-request ratio: B3 degrades as DT state size increases, whereas B4 and B5 maintain full handled-request behavior across the recorded operating points. At 500 MB, the service-level transition gap is 1957.16 ms for B3, 1959.57 ms for B4, and 1649.31 ms for B5, while the handled-request ratios are 64.02%, 100.00%, and 100.00%, respectively. These prototype observations are consistent with the main MATLAB evaluation and provide execution-trace evidence that continuity-aware transition control and revocation-aware completion remain observable in the recorded control-path behavior.

Table 20. Attack handling summary for the control-path prototype validation.

Scheme	Attack Type	Attempts	Rejected	Defense Success Count	Defense Success Rate (%)
B3	Tampered protected transfer package	1	1	1	100.0
B4	Unauthorized migration request	1	1	1	100.0
B4	Replayed migration credential	2	2	2	100.0
B4	Tampered protected transfer package	1	1	1	100.0
B4	Premature forwarding attempt	2	2	2	100.0
B4	Stale source request	1	0	0	0.0
B5	Unauthorized migration request	3	3	3	100.0
B5	Replayed migration credential	1	1	1	100.0
B5	Tampered protected transfer package	2	2	2	100.0
B5	Premature forwarding attempt	3	3	3	100.0
B5	Stale source request	1	1	1	100.0

summarizes the recorded attack outcomes for the control-path prototype. Unauthorized migration requests, replayed migration credentials, tampered protected transfer packages, and premature forwarding attempts were rejected in all recorded B4 and B5 attack attempts. By contrast, the stale source request case distinguishes the two schemes: the recorded B4 attempt did not satisfy the intended security goal, whereas the recorded B5 attempt was rejected successfully. This pattern is consistent with the role of revocation-aware completion in removing stale source-side validity after cutover. Accordingly, the control-path prototype provides execution-trace evidence of stronger post-transition enforcement in B5 than in B4.

6.9. Attack Condition Control-Path Overhead

To complement the attack outcome results in Table 20, we further measured the control-path overhead incurred when representative hostile requests are processed and rejected. This experiment quantifies rejection latency, added signaling overhead, and the effect on concurrent benign control-path latency under representative hostile request conditions.

Table 21. Attack condition control-path overhead under representative hostile request conditions.

Attack Case	Scheme	n	Reject. Lat. (ms)	Signaling (KB)	Normal-Path Lat. (ms)	Benign Ref. Lat. (ms)	Increase (%)
Unauthorized migration request	B4	20	7.58 ± 0.11	0.34 ± 0.01	8.42 ± 0.08	8.00	5.25
Unauthorized migration request	B5	20	7.81 ± 0.10	0.37 ± 0.01	8.71 ± 0.09	8.26	5.45
Replayed migration credential	B4	20	7.89 ± 0.12	0.38 ± 0.01	8.47 ± 0.09	8.00	5.88
Replayed migration credential	B5	20	8.15 ± 0.11	0.41 ± 0.01	8.76 ± 0.08	8.26	6.05
Tampered protected transfer package	B4	20	6.31 ± 0.09	0.29 ± 0.01	8.36 ± 0.07	8.00	4.50
Tampered protected transfer package	B5	20	6.58 ± 0.10	0.32 ± 0.01	8.63 ± 0.08	8.26	4.48

summarizes the attack condition control-path overhead results for unauthorized migration requests, replayed migration credentials, and tampered protected transfer packages under the B4 and B5 control configurations. Values are reported as mean ± 95% confidence interval over repeated runs.

The results in Table 21 show that representative hostile requests are rejected with bounded delay and limited additional control-path signaling under both B4 and B5. For unauthorized migration requests and replayed migration credentials, the mean rejection latency remains in the 7.58–8.15 ms range, whereas tampered protected transfer packages are rejected slightly faster, with mean rejection latency in the 6.31–6.58 ms range. The added signaling overhead remains below 0.5 KB in all cases, indicating that hostile request rejection does not introduce substantial extra control traffic. The effect on concurrent benign authorization latency also remains modest: relative to the benign medium-load reference, the normal-path latency increase ranges from 4.48% to 6.05% across the tested attack conditions. B5 consistently incurs slightly higher rejection and concurrent latency costs than B4, which is consistent with the additional completion-side validation and stronger post-transition enforcement logic of the full mechanism. Overall, the attack handling logic imposes only limited additional control-path cost while preserving migration control safety under representative hostile request conditions.

The evaluation combines controlled scenario analysis, external authentication-path comparison, and execution-level control-path validation. The matched MATLAB runs quantify migration cost, authentication overhead, secure transfer delay, transition continuity, and completion delay with statistical uncertainty. The external comparison places the proposed authorization stage against recent cross-domain authentication schemes on the shared authorization control function. The prototype traces verify that the ordered control stages produce the intended execution-level outcomes under benign and adversarial cases. Together, these results support the claim that the proposed mechanism adds bounded overhead while improving continuity preservation and post-migration control correctness for stateful cross-domain DT migration.

7. Conclusions

This paper presents a lifecycle control mechanism for secure stateful DT migration across edge domains under mobility-aware service relocation. The proposed mechanism makes migration completion depend on ordered enforcement of target-side admission, protected state relocation, readiness-gated transition, formal activation, and revocation-aware stale source invalidation. The resulting procedure was specified through six coordinated phases covering migration triggering, target-side authorization, protected-state transfer, continuity-aware traffic transition, post-migration activation, and revocation-aware completion. Security analysis showed that the mechanism supports authorization soundness, migration-state confidentiality and integrity, transition safety, post-migration uniqueness, and resistance to common protocol-level attacks. Performance evaluation further showed that these properties are achieved with bounded overhead: the full mechanism increased migration-related cost only moderately, substantially reduced transition interruption, and added only a bounded completion-stage delay for revocation-aware finalization. The ablation results further showed that the main migration control stages contribute distinct and measurable lifecycle functions.

Overall, the results indicate that secure cross-domain DT migration can be enforced without sacrificing the operational benefit of mobility-aware relocation, while providing stronger continuity preservation and more reliable post-migration completion for stateful DT operation. Future work will extend the proposed mechanism to multi-hop cross-domain DT migration under heterogeneous inter-domain authorization policies; investigate lightweight compression, dirty-page filtering, and incremental state transfer strategies for reducing transition and completion overhead; and evaluate deployment-scale settings with containerized DT services, heterogeneous physical edge nodes, and network-emulated inter-domain links.