SEAL-DT: An End-to-End Security Engineering and Assurance Framework for Cross-Domain Digital Twins

1

SEAL-DT: An End-to-End Security Engineering and Assurance Framework for Cross-Domain Digital Twins

arXiv:2610.17097v1 [cs.CR] 12 Oct 2026

Iraklis Varlamis, Stelios Zindros, Christos Sardianos, Thomas Lagkas, Panagiotis Sarigiannidis, and Georgios Th. Papadopoulos

Abstract—Cyber-physical systems connect physical processes, software, networks and organizations. Securing these systems requires a clear account of what happened, what was observed, which actions were authorized and what evidence supports each decision. Digital Twin (DT) descriptions often do not explain how these elements remain consistent. They may also blur the distinction between physical events and uncertain observations, or leave simulation results disconnected from their requirements and assumptions. This paper presents SEAL-DT (Security Engineering and Assurance Lifecycle for Digital Twins), a structured approach to building and evaluating secure DTs. It brings entity definitions, process models, deterministic simulations, data contracts and evidence records, automated tests and reproducible results into one connected model. The main contribution is an end-to-end security framework for DTs, implemented from scenario definition and entity/process modelling through simulation, security decision logic, evidence handling, validation and reproducible reporting. This makes it possible to trace security decisions and simulation results back to their data, assumptions and requirements. In this approach, a DT is more than a copy of system state: it is a representation that clearly states what it can observe, how accurate and current its information is, where that information came from and which decisions it is allowed to support. We demonstrate the approach in five scenarios: Car2X protection, passive IoT- device detection, an industrial control surrogate, lawful acquisition in a smart home, and medical-IoT monitoring that preserves continuity of care. Each implementation includes formal models, deterministic and negative experiments, uncertainty analyses, schema-valid fixtures, technical reports and verified manifests. Across the scenario set, multiple configurations are tested under both normal and adverse conditions. The results show that the framework supports consistent model construction, traceable execution and comparable internal validation. They also demonstrate that security findings can be linked to observable evidence. Index Terms—Digital Twin, cyber-physical systems, modelbased security engineering, provenance, forensic readiness, reproducibility.

I. I NTRODUCTION IGITAL Twins are increasingly used to reason about systems whose physical, computational and human parts evolve together. They combine models with operational data to represent a system, track its changing state and support decisions throughout its life cycle [1]. Current standards and

D

I. Varlamis, S. Zindros, C. Sardianos and G. Th. Papadopoulos are with the Department of Informatics and Telematics, Harokopio University of Athens, Athens, Greece (e-mail: varlamis@hua.gr; itp23106@hua.gr; sardianos@hua.gr; g.th.papadopoulos@hua.gr). T. Lagkas is with the Department of Informatics, Democritus University of Thrace, Kavala, Greece (e-mail: tlagkas@cs.duth.gr). P. Sarigiannidis is with the Department of Electrical and Computer Engineering, University of Western Macedonia, Kozani, Greece (e-mail: psarigiannidis@uowm.gr).

industrial frameworks emphasize observable entities, synchronization, information exchange and interoperability [2]–[4]. However, security-focused deployments must keep five things separate: what actually happened, what sensors recorded, what the digital twin accepted as valid, what an analyst is authorized to see, and what evidence supports a conclusion. For example, a sensor may detect a device, but the twin may reject the report and privacy rules may prevent an analyst from seeing the device’s identity; treating the detection as confirmed and visible fact would make a simulation appear certain without enough evidence. The contribution of SEAL-DT is a Security Engineering and Assurance Lifecycle for Digital Twins: a complete framework for designing, implementing and validating securityoriented DT scenarios across heterogeneous cyber-physical domains. The framework represents these layers separately while linking every system transition, security decision and simulation result to its requirements, assumptions, data and supporting evidence. This structure makes security conclusions auditable and prevents model predictions from being mistaken for observations, authorized actions or validated claims. Its implementation covers the full lifecycle from source-governed scenario scoping to executable simulations, negative security experiments, evidence/custody records, automated tests and reproducible manifests. To demonstrate that the approach applies beyond a single domain, we evaluate it through a heterogeneous set of security-DT scenarios. Despite their different settings and dynamics, these scenarios share the same assurance questions: • Which physical, digital, logical, human, organizational and data entities exist, and which source justifies each one? • Which transitions are possible, what is observable, and how do delay, loss, ambiguity and stale state affect the digital representation? • Which detector or policy requested an action, which capability actually applied it, and which safety or authorization constraint overruled it? • Which visible observations and evidence records support a reconstructed claim, and can the result be reproduced from declared inputs? To address these questions systematically, SEAL-DT contributes the following elements: 1) a DT definition that binds identity, referent, state, observations, update rules, fidelity, freshness, provenance, policy and decision authority; 2) a source-governed case method that records scope, source precedence, assumptions, prohibited capabilities and integration boundaries;

2

3) a canonical entity and graph model linked to process and of a corresponding physical system [1]. Respectively, ISO behavioural views over events, queues, observation loss and 23247 provided terms, principles and a reference architecture twin updates; for manufacturing DTs, including observable manufacturing 4) a security-governance layer for detection, authorization, elements and information exchange [2]. In a similar spirit, safety guards, minimization, evidence, custody and recon- the Asset Administration Shell (AAS) specifies a metamodel, struction; submodels, identifiers and exchange mappings for interoper5) an assurance package method covering experiments, uncer- able representations of industrial assets [4], and the Digitainty analysis, competency queries, tests, reports, mani- tal Twin Consortium’s interoperability framework emphasizes fests and bounded claim discipline; and implementation-agnostic, secure and scalable interoperation 6) a comparative application to heterogeneous scenarios, with among independently operable systems [3]. measured synthetic results reported only where generated Together, these frameworks establish the architectural and artifacts exist. semantic baseline for DT work: how represented entities are Taken together, these contributions position the work as an identified and structured, how observations and asset informaimplemented security framework for DT-based cyber-physical tion are exchanged, and how interoperability, lifecycle scope threat scenarios, rather than only a conceptual modelling and fidelity are framed. SEAL-DT builds on this baseline, but proposal. The framework keeps physical events, observa- targets a security-specific problem: a security claim is useful tions, accepted twin state, authorized decisions, evidence and only when its origin, input data, reasoning steps, supporting claims distinct, while preserving the links needed to audit evidence and uncertainty can be checked. It therefore links and reproduce a result. It combines this separation with each protected entity to the security observations that describe source-governed assumptions, canonical entities, executable its state, the assessment or control decision derived from behaviour and assurance artifacts. The evaluation also shows them, the evidence supporting that decision and the confidence how the framework can be reused without removing domain- attached to the result. This makes a DT usable for security specific dynamics or constraints. work, where analysts must be able to inspect why an alert, The remainder of the article is organized as follows. Sec- risk score or control recommendation was produced and what tion II reviews relevant DT, security and provenance founda- evidence bounds the resulting claim. The same structure can tions. Section III defines the proposed framework as a chain be used for physical assets, logical services and security from source-governed case to assurance package. Section IV hypotheses, as long as each twin clearly states what it refers applies the framework to the use cases, while Section V to, what it may observe and what level of fidelity it claims. presents the simulation design and comparative results. Section VI discusses current limitations and future work, and B. Cyber-physical systems, security and model assurance Section VII summarizes the main conclusions. Finally, the The NIST CPS Framework treats cyber-physical systems Appendix provides the detailed UC1 implementation view. as interacting physical, digital and human components and organizes analysis through conceptualization, realization and II. R ELATED W ORK AND R ELATED F RAMEWORKS assurance facets, alongside concerns such as timing, data, trustTo position the proposed framework, this section reviews worthiness, boundaries and lifecycle [5]. This broad systems three complementary strands of prior work. First, Digital view motivates the cross-domain scope of SEAL-DT. Recent Twin definitions and reference architectures establish how CPS security surveys further show that attacks and defenses physical or logical referents are represented and kept aligned must be analyzed across the physical, cyber and cyber-physical with their digital counterparts. Second, cyber-physical security domains, since a software or network compromise can become and model-assurance research provides the concepts needed a physical safety or process-integrity problem [6]. Recent to reason about trustworthiness, uncertainty and operational DT surveys make the same point from the twin side: DT risk. Third, process, schema and provenance standards support security depends on the architectural layer being protected, the interoperable execution and auditable evidence. Taken together, application domain, the modeling technique and the operating these three strands identify the architectural, assurance and mode [7], [8]. provenance foundations adopted by SEAL-DT, while also exWork on DT-based cyber-attack detection in manufacturing posing the gap that motivates the framework chain introduced demonstrates how physics-based, data-driven and expert modin Section III: moving from source-governed case definition els can be combined to distinguish expected anomalies from to a reviewable assurance package. attacks [9]. CRYSTAL brings this idea closer to assurance by combining attack models, formal verification, runtime A. Digital Twin foundations and reference architectures monitoring and a compact “Tiny Digital Twin” reference Digital twin research and standardization have converged model for detecting CPS attacks at runtime [10]. SEAL-DT over the years around a set of foundational definitions, refer- generalizes these patterns to detection, policy, safety, evidence ence architectures and interoperability principles. The original and reconstruction, while requiring each operational inference aerospace formulation by Glaessgen and Stargel, developed to remain within its observation boundary, declared authority in the NASA and U.S. Air Force context, established the and stated uncertainty. central idea of a digital representation informed by onboard The closest prior work is the security-enhancing DT literand historical data and used to reason about the lifecycle ature, which treats a DT not only as an operational mirror

3

but also as a security instrument. Prior work shows DTs structured cyber threat intelligence and its exchange [25], [26], supporting CPS security design, testing, intrusion detection while CSAF 2.0 supports machine-readable security advisories and SOC/SIEM analysis for operational technology [11], [12]. about products, vulnerabilities, impact and remediation [27]. Security-enhancing DT surveys further define the characterSEAL-DT follows the same direction by treating security istics of twins that actively improve security and map the evidence as explicit typed artifacts rather than informal notes. area across models, tools, domains and operating modes [8], JSON Schema Draft 2020-12 supplies machine-validatable [13]. Recent industrial DT-security work is especially relevant structure and constraints for JSON artifacts [28]. W3C PROV because it treats twins as infrastructure for incident detection models entities, activities, agents and derivations [29]. NIST and response in IIoT, manufacturing and energy settings [14]. SP 800-86 separates collection, examination, analysis and SEAL-DT follows this positive direction, but makes the secu- reporting in digital forensics and emphasizes preservation and rity claim more explicit by binding observations, decisions, documented handling [30]. BPMN 2.0.2 defines a notation, policy actions and reconstruction claims to typed evidence metamodel and interchange format for business processes and and provenance. Industrial DT forensics is another close line collaborations [31]; SEAL-DT uses it only as a responsibility of work. Replication-based ICS twins emphasize state repli- and message-flow view, while schemas, configuration and code cation, replay and fidelity for post-incident analysis, where retain the executable behavioural semantics. In this way, the the physical plant cannot always be imaged or disturbed [15]. framework combines process structure, schema validation and ATT&CK-oriented DT work also shows how synchronized provenance through source records, evidence objects, derivaICS state changes can become evidence-preserving descrip- tion links and custody chains; it does not claim that a local tions and typed dependency graphs [16]. SEAL-DT shares hash chain alone makes evidence legally admissible. this forensic-readiness motivation, but extends it into an end-toAssurance-case standards clarify how evidence should be end evidence contract: the twin records what was observable, turned into an argument. Goal Structuring Notation (GSN) how observations were derived, which claims they support provides a graphical structure for claims, strategies, context, and which uncertainty or custody limits prevent stronger assumptions, justifications and evidence [32]. The OMG Strucconclusions. Model credibility and verification/validation work tured Assurance Case Metamodel (SACM) provides a metaalso shapes the assurance discipline. NIST, ASME V&V 40 model for machine-processable assurance cases and related and NASA-STD-7009 all treat credibility as tied to intended artifact references [33]. SEAL-DT does not require authors use, uncertainty, input pedigree, verification, validation and to use a specific assurance-case editor, but it follows the reporting [17]–[19]. SEAL-DT imports this stance into se- same claim–argument– evidence logic: every reported result curity DTs by separating executable behaviour from claim is treated as a qualified claim whose supporting observations, qualification: a run can complete deterministically while its tests, assumptions and residual uncertainty must be available assurance package still states limited fidelity, synthetic data for review. Forensic-readiness standards add the evidencescope, missing calibration or insufficient authority for an handling boundary. ISO/IEC 27037 focuses on identification, operational claim. Runtime assurance provides the comple- collection, acquisition and preservation of potential digital evmentary control perspective. The Simplex architecture sepa- idence, while ISO/IEC 27043 provides incident-investigation rates an advanced controller from a trusted safety controller principles and process models for scenarios involving digital and switches authority when monitored conditions leave the evidence [34], [35]. These standards reinforce a key distinction certified envelope [20]. Shielding and runtime-enforcement in SEAL-DT: the DT can prepare, preserve and explain work similarly places a monitor around a reactive component evidence-bearing artifacts, but admissibility and investigative so that critical properties are enforced online even when the sufficiency depend on broader organizational, legal and promain controller is too complex to fully verify [21]. SEAL- cedural controls. The framework therefore records custody, DT uses the same separation principle: DT-derived detections, minimization, hashes, source precedence and derivation, while policies and mitigations must state their authority boundary, avoiding the stronger claim that technical traceability alone and safety- or security-relevant actions are represented as establishes forensic validity. controlled transitions with evidence and failure modes. C. Process, schema and provenance standards Security assurance requires processes, schemas and provenance records that make security artifacts both interpretable by analysts and checkable by tools. Several standards illustrate this need. For example, NIST SP 800-61 frames incident response as part of cybersecurity risk management, linking preparation, detection, response and recovery to the NIST Cybersecurity Framework 2.0 [22]. NIST OSCAL represents control catalogs, baselines, system security plans, assessments and assessment results in machine-readable formats [23]. For operational data, the Open Cybersecurity Schema Framework (OCSF) defines a common schema for security events, findings and observables [24]. STIX 2.1 and TAXII 2.1 support

D. Gap addressed The related work shows several mature but partial answers to the security DT problem. ISO 23247, AAS and the Digital Twin Consortium define how twins, industrial assets and interoperable DT systems can be structured [2]–[4]. DT-based detection frameworks, including manufacturing attack detection and CRYSTAL, show how model-based, data-driven and formal techniques can support CPS attack detection and runtime assurance [9], [10]. Security-enhancing DT work shows how twins can support security analysis, SOC simulation, intrusion detection, incident response and ICS forensic replay [8], [11]– [16], [38]. Process and evidence standards such as OSCAL, OCSF, STIX/TAXII, CSAF, JSON Schema and PROV define

4

TABLE I C OMPARISON OF RELATED SECURITY-DT FRAMEWORKS AND THE PROPOSED FRAMEWORK . Framework

Twin model

Monitoring / detection

Trust / provenance

Incident response

Formal / runtime assurance

End-to-end Main limitation relative to assurance chain SEAL-DT

CPS cybersecurity DT [36]

✓

✓

∼

∼

—

—

Trusted Twins [37]

✓

∼

✓

—

—

—

SEDT incident-response framework [38]

✓

∼

∼

✓

—

∼

Cybersecurity DT blueprint [39]

✓

✓

∼

✓

∼

∼

SEAL-DT

✓

✓

✓

✓

✓

✓

Focuses on CPS cybersecurity analysis, but does not define a full typed evidence chain from source declaration to qualified result. Strengthens trust and integrity through blockchain, but does not cover process-level assurance, decision authority and reconstruction together. Covers the SEDT lifecycle for incident response, but does not formalize a cross-use-case executable evidence and uncertainty contract. Addresses federated security operations across service chains, but leaves the artifact-level assurance chain and validation contract less explicit. Integrates entity modeling, observations, policy, evidence, provenance, uncertainty and reconstruction in one executable assurance discipline.

useful building blocks for controls, events, advisories, valida- considered together. Security-enhancing DTs, model credibiltion and provenance [23]–[29]. Credibility, runtime-assurance, ity, runtime assurance, assurance cases and forensic readiness assurance-case and forensic-readiness standards add discipline each address part of the problem, but they are usually apfor deciding when a DT result can support a security or safety- plied separately. SEAL-DT contributes the connective tissue: relevant claim [17]–[21], [32]–[35]. source-governed scenario definition, typed entities, executable Several works move toward such composition. CPS cy- simulations, schema-validated evidence, provenance, uncerbersecurity DT frameworks link the physical system, cyber tainty statements, policy authority and reconstruction claims representation and security analysis tasks, with emphasis on are kept in one reviewable package. SEAL-DT addresses monitoring and attack analysis [36]. Trusted Twins combine this gap as a composition and assurance discipline, not as blockchain-backed trust mechanisms with DT-based CPS sit- a replacement for the standards above. Its benefit is to make uational awareness, strengthening integrity and trust in the security DT claims explicit, executable and inspectable: inputs twinning process [37]. Security-enhancing DT lifecycle work are typed, transitions are controlled, decisions remain within for incident response covers design, deployment, operation and declared authority, evidence is linked to its sources and results end-of-life considerations [38]. Cybersecurity DT blueprints carry provenance and uncertainty. This allows the same framefor federated, multi-ownership digital service chains empha- work to support detection, policy assessment, safety reasoning size cross-domain cooperation, threat hunting and adaptive and forensic reconstruction while preserving a clear boundary between what the twin observes, what it infers, what it is response [39]. Table I summarizes how these works relate to the building allowed to decide and what the assurance package is strong blocks used by SEAL-DT. The comparison is qualitative: ✓ enough to claim. denotes explicit support, ∼ denotes partial or domain-specific support, and — denotes that the feature is not a main concern Compared with the surveyed literature, four elements apof the cited work. pear most distinctive. SEAL-DT keeps five layers separate– What remains less well supported in the related work is physical, observed, accepted-twin, decision/action and evithe composition of these concerns into one testable assurance dence/claim state–and applies a no-leakage rule across them. chain. A security DT does not only need an asset model, an It also uses a richer DT definition than a synchronized replica, event schema, a detection model or a provenance record in requiring the twin to declare its referent, observation boundisolation. It needs a way to keep source precedence, assump- ary, fidelity, provenance, uncertainty and decision authority. tions, entity identifiers, observation boundaries, process views, Requested and applied security actions are separated by one policy limits, evidence objects and uncertainty statements guard pattern reused across the five domains. Finally, claim consistent from case definition to executable result and claim discipline and evidence-maturity labels state whether a result is qualification. Without that chain, a twin may produce alerts supported by executable evidence, synthetic validation, partial or recommendations that are difficult to audit, compare across calibration, expert assumption or an open obligation. Together use cases, reproduce or challenge. these elements turn DT security functionality into a reviewable This gap is especially visible when the closest prior work is assurance chain.

5

III. T HE SEAL-DT F RAMEWORK FOR D IGITAL -T WIN S ECURITY T HREAT S CENARIOS SEAL-DT is an engineering framework for turning a broad cyber-physical security scenario into an executable, traceable and reviewable Digital Twin package. It covers different application scenarios without forcing them into the same domain model or threat pattern. In each case the starting point is a narrative problem statement. The end point is a reviewable package containing source decisions, assumptions, canonical entities, process models, schemas, executable runs, evidence objects, graph queries, tests, results and a hash manifest. The framework therefore treats a DT as more than a synchronized model of an asset. A secure and verifiable DT in SEALDT is a declared representation with an identifier idi , a referent ri , an accepted digital state x̂i , admissible observations Oi , an update rule Ui , declared fidelity Φi , freshness Fi , provenance and uncertainty ∆i , policy constraints Pi and decision authority Ai : Ti = (idi , ri , x̂i , Oi ,Ui , Φi , Fi , ∆i , Pi , Ai ). (1) This compact tuple formally defines the questions that had to be answered for each implementation: what is being twinned, which observations may update it, how stale or uncertain the state may be, which decisions it may influence, and which evidence supports each claim. A. Source-Governed Case to Assurance Package Figure 1 presents the framework as a layered assurance chain, linking identifiers, assumptions and source references at the top to executable results and the final report at the bottom, while keeping each intermediate component traceable and visible. 1. Source-governed case: scope, source precedence, assumptions, prohibited capabilities, integration boundary

2. Canonical model: reusable entities, typed relationships, zones, roles and schema references

3. Process and behaviour: BPMN/lifecycle views, state variables, events, queues, observation loss and twin updates

4. Security governance: detection, authorization, safety guards, minimization, evidence, custody and reconstruction

5. Assurance package: experiment matrix, Monte Carlo design, runtime graph, competency queries, tests, reports and manifest Fig. 1. The SEAL-DT chain from source intent to validated result. The dashed arrow shows how failed checks lead to revisions.

The same chain can be instantiated for different securitythreat scenarios. In a Car2X attack setting, it can separate malicious or untrusted message validation from the authority to influence traffic-control decisions. In smart-home forensics, it can keep incident truth, observations, lawful collection, custody and claims distinct.

B. Source-Governed Case The source-governed case layer reduces the broad problem to one bounded scenario with explicit scope, source precedence, assumptions, prohibited capabilities and integration boundary. This is where SEAL-DT prevents two common failures: modelling everything too vaguely, or implementing a narrow simulator whose assumptions are invisible. For each scenario, the boundary records: • the scope of the protected or investigated referents, such as vehicle messages and roadside-unit requests; • the source precedence among declared scenario requirements, roadmap obligations, user decisions, engineering assumptions and TBD values; • the assumptions, affected artifacts, default values, owners, replacement paths and impacts; • the actions explicitly prohibited in the synthetic model, such as live RF transmission or real traffic-control actuation; and • the integration boundary for the services allowed to observe, decide, collect or share Car2X evidence. The output is a scenario contract rather than an informal description. The contract does not eliminate uncertainty. It makes uncertainty operational by registering assumptions with affected artifacts, default values, owner, replacement path and impact. This is what allows a scenario package to state both what the synthetic model showed and what it did not show. Example scenario contract: the Car2X simulation models a synthetic test vehicle that sends a roadsideunit request to influence a traffic-control decision during a bounded run of Tmax seconds. The security scenario is a forged, replayed or stale request that attempts to pass trust validation and affect the traffic controller. The in-scope referents are the vehicle message, the roadside-unit request, the gateway decision and the traffic-controller command interface. The simulation records any missing Car2X profile, timing parameter or trust threshold as assumption Y with an owner, replacement source and affected artifacts. The run must not transmit live RF, connect to a real roadside unit or actuate a real traffic controller. The integration boundary permits only synthetic observations, policy decisions, evidence records and reports. A successful run must show which request was accepted or rejected, which authority allowed or blocked the decision, which evidence supports the result and which assumptions still limit the claim.

C. Canonical Model The canonical model layer defines reusable entities and their typed relationships. Zones, roles, data objects and schema references are recorded as entity attributes where needed. Every relevant object is named as an entity and receives a stable identifier before it appears in a process, equation, event stream, evidence package or report. The inventory of reusable entities is: I = {ei | ei = (idi , τi , namei , srci , zi , ρi , σi , ℓi , θi )}.

(2)

6

Here idi is the stable identifier, τi is the entity type, namei is the human-readable name, srci is the source or assumption status, zi is the zone or boundary, ρi is the role, σi is the sensitivity label, ℓi is the lifecycle state and θi is an optional twin reference. The same entity may appear in several views, but it must keep the same identifier. This rule is what allows SEAL-DT to cover different domains without erasing their differences. A roadside unit and a traffic controller, for example, are domain-specific objects. In SEAL-DT, each domain-specific object is still represented as an entity with source status, sensitivity, zone, lifecycle state, relationships and optional twin reference. Relationships are typed because “observes”, “controls”, “mirrors”, “authorizes”, “supports” and “shares” have different security meanings. The canonical graph has two parts. The design graph records the declared entities and allowed relationships: G0 = (V0 , E0 ),

V0 = I ,

E0 ⊆ V0 × R ×V0 .

(3)

In this notation, V0 is the set of reusable design-time entities, E0 is the set of typed design-time relationships and R is the allowed relationship vocabulary, such as sends, observes, validates, forwards, authorizes, controls and supports. Runtime execution adds observations, alerts, decisions, evidence, custody events and claims: G(t) = (V0 ∪Vr (t), E0 ∪ Er (t)).

(4)

Here V0 is the stable entity inventory, Vr (t) is the set of runtime vertices accumulated up to time t, and Er (t) is the set of runtime edges linking those vertices to design-time entities and to each other. This graph can support competency queries such as: which evidence supports this claim, which authorization allowed this collection, which twin state was stale, which source assumption affected the metric, and which process step generated the decision. For example, in the Car2X scenario, a minimal canonical inventory may define reusable entities such as: e1 = (veh1 , physical, test vehicle,Y, test-zone, sender, restricted, active, dtveh ), e2 = (rsu1 , cyber, roadside unit,Y, edge-zone, receiver, restricted, simulated, dtrsu ), e3 = (gw1 , logical, gateway decision,Y,

(5)

control-zone, validator, internal, simulated, dtgw ), e4 = (tc1 , cyberphysical, traffic controller,Y, control-zone, actuator, restricted, simulated, dttc ). In these tuples, veh1 , rsu1 , gw1 and tc1 are stable entity identifiers; Y denotes the assumption record introduced by the scenario contract; and dtveh , dtrsu , dtgw and dttc are optional twin references for the corresponding entities. The roadside unit is typed as cyber because it handles the digital request path, while the traffic controller is typed as cyberphysical because its command interface is coupled to the traffic-control process, even though real actuation is excluded from the

simulation. The corresponding design graph can be written as: E0 = {(veh1 , sends, rsu1 ), (rsu1 , forwards, gw1 ),

(6)

(gw1 , authorizes,tc1 )}. The security test then adds runtime vertices for a forged, replayed or stale request, its validation result, the allow/block decision and the evidence record supporting the final claim. In Figure 2, msgr ∈ Vr (t) denotes the runtime request record, where r indexes the request instance; dect ∈ Vr (t) denotes the decision created at time t; and evt ∈ Vr (t) denotes the evidence record created at time t. The orange runtime relationships observed by, validated by and supports are elements of Er (t). Figure 2 illustrates the same example as a compact graph. D. Process and Behaviour Views The process and behaviour layer contains BPMN/lifecycle views, state variables, events, queues, observation loss and twin updates. It defines process responsibilities and behavioural views over the same reusable entities used by the canonical model. Scenario packages may contain BPMN and lifecycle artifacts, but SEAL-DT does not treat BPMN as the source of executable truth. Their role is to show responsibility, message flow, denial paths and handoff points. The executable semantics remain in schemas, configuration and code. The reusable process-family vocabulary is: F = {nominal, attack, detection, policy, evidence, lifecycle}.

(7)

These families separate normal operation, adversarial or abnormal behaviour, security assessment, governed response, evidence handling and recovery or state-change management. This vocabulary covers a wide range of simulation scenarios because every process step must either establish the baseline, introduce or observe a threat, assess it, decide a governed response, preserve supporting evidence or move the scenario into a later lifecycle state. It is not intended as a universal process taxonomy; domain-specific substeps can be added under one of these families without changing the framework structure. For a scenario, the process view is an inventory: P = {p j | p j = (pid j , f j ,W j , pre j , post j , in j , out j , deny j )}. (8) Here pid j is the process identifier, f j ∈ F is the process family, W j ⊆ V0 is the set of responsible entities or roles, pre j and post j are the entry and exit conditions, in j and out j are the consumed and produced messages or artifacts, and deny j records the explicit denial or failure branch. This notation keeps the process view focused on who observes, reviews, mitigates, collects or shares, while the executable model decides what actually happens under a given seed and configuration. Failure paths are first-class. A missing observation, expired authorization, queue overflow, unavailable service, tampered custody link or absent backup is not a crash in the method; it is an expected branch with observable consequences. In graph

7

veh1 test vehicle

sends

rsu1 roadside unit

forwards

observed by

validated by

msgr forged/replayed request

gw1 gateway decision

dect allow/block decision

authorizes

tc1 traffic controller

supports

evt evidence record

Fig. 2. Example canonical Car2X graph for the Section III-B simulation contract. Blue edges are reusable design relationships; orange edges are runtime relationships created by the security test.

terms, each process may also be linked to the canonical entity graph by responsibility and artifact edges: EP ⊆ P × RP × (V0 ∪Vr (t)),

(9)

where RP contains process-view relationships such as performed by, consumes, produces, reviews, blocks and hands off. For the Car2X simulation contract, the process view can be instantiated as: p1 = (P-NOM, nominal, {veh1 , rsu1 , gw1 }, valid request, request routed, msgr , msgr , ∅), p2 = (P-ATT, attack, {veh1 , rsu1 }, forged/replayed request, request observed, msgr , msgr , ∅), p3 = (P-DET, detection, {gw1 }, request observed, trust result produced, msgr , dect , reject), p4 = (P-POL, policy, {gw1 ,tc1 }, decision available, allow or block recorded, dect , dect , block), p5 = (P-EVI, evidence, {gw1 }, decision recorded, evidence preserved, dect , evt , ∅).

(10)

accepted twin states and reconstructed claims are derived from visible observations and evidence only. The shared event vocabulary is: E = {εk | εk = (eidk ,tk , tˆk , srck , dstk ,

(12)

κk , cidk , νk , χk )}. Here eidk is the event identifier, tk is the event time, tˆk is the ingest time, srck , dstk ∈ V0 ∪Vr (t) are the source and destination, κk is the event type, cidk is the correlation identifier, νk is the visibility class and χk is the schema or payload contract. Each scenario must state which events exist, which entities produced or consumed them, and whether records were visible, withheld, delayed or lost. Accepted twin state is updated only from visible observations: Tk+1 = U(Tk , Ok ; Θ), (13) Ok = Ω(Hk , εk ; Λ). In this notation, Tk is the accepted twin state at step k, U is the twin update rule, Ok is the observation available to the twin, Θ contains model parameters, Ω is the observation function and Λ contains loss, delay, retention and visibility settings. Queues, losses and delays are explicit. For a queue with arrivals Ak , service Sk , drops Dk and occupancy Bk , the invariant is: Bk+1 = Bk + Ak − Sk − Dk ,

0 ≤ Bk+1 ≤ Bmax .

(14)

This example shows that the forged or replayed request is Here Ak is the number of arriving events, Sk is the number represented both as a simulator event and as a process artifact. served, Dk is the number dropped, Bk is queue occupancy It is carried by an attack process, reviewed by a detection and Bmax is capacity. Recording why an event is missing process, constrained by a policy process and preserved by matters because channel loss, observer loss, queue overflow, an evidence process. The denial branch is explicit: the same retention expiry and policy denial have different security process view can show a blocked traffic-control influence meanings. In the Car2X example, the gateway twin therefore validates observable message features, records the reason for without treating the simulation as a failed run. 1) Process and Behaviour Semantics: The process view an allow/block decision, and preserves that reason as evidence becomes executable only after its steps are tied to event se- without reading the simulator’s private attack label. mantics. This adds deterministic ordering, declared uncertainty, explicit queues, observation loss and twin updates, while E. Security Governance preserving the same visibility boundary used in the process The security governance layer covers detection, authorizaview: tion, safety guards, minimization, evidence, custody and reH −→ O −→ T −→ E −→ C, C ̸← H, (11) construction. Its role is to decide what may be done with a detection result, which records may become evidence and where H is hidden truth, O observable records, T accepted which claims may later be reconstructed. SEAL-DT treats twin state, E verified evidence and C reconstructed claims. alerts and recommendations as inputs to governed decisions, Hidden truth may evaluate a synthetic run after the fact, but not as automatic authority. A detector may score an untrusted

8

p4 allow path yes start

p1 nominal request

p2 attack request

msgr

p3 trust detection

dect

p5 evidence record

trusted?

evt

end

no p4 block path Fig. 3. BPMN-style Car2X process view matching the Section III-B simulation contract. The dashed branch is the explicit denial path for a forged, replayed or stale request.

control message or an anomalous device-flow pattern, but the applied decision is still constrained by capability, authorization and safety: atreq = π(alertt , Xt , capt , autht ), atapp = Γ(atreq , capt ,

(15)

autht , sa f e(Xt )). Here alertt is the detection output at time t, Xt is the governance state available to the policy, capt records what the simulated system is allowed to do, autht records the applicable authorization and sa f e(Xt ) is the safety predicate. The policy π proposes a requested action atreq , while the guard Γ converts it into the applied action atapp after checking capability, authorization and safety. The requested and applied actions are separate records. This separation allows the framework to express scenario-specific guards: detecting an attack does not automatically authorize the strongest available response. In practice, Xt is the information that the policy is allowed to see at the moment of decision. It is not the simulator’s hidden truth. It may include the accepted twin state, the current validation result, whether the message is fresh, whether the queue is overloaded, the current operating mode, the declared simulation boundary and whether an evidence record can be preserved. For Car2X, the policy receives a visible validation result for a roadside-unit request. If the request is fresh, authorized and safe for the current controller state, the policy may request that the simulated command be applied. If the request is a replay, is stale, comes from an unauthorized source or asks for an unsafe traffic-control effect, the requested action is to block it. The final guard then checks the scenario boundary: because the experiment prohibits live RF and real trafficcontrol actuation, the applied action is recorded as blockrecord. The governance record keeps the request, validation reason, allow/block decision and evidence record together, so a reviewer can see both why the request was blocked and which visible evidence supports that decision. Evidence follows the same discipline. A source record becomes evidence only after authorization, minimization, canonicalization and hashing. Custody links record how evidence was handled, but the framework does not claim that a local hash chain alone establishes legal admissibility. Reconstruction consumes verified visible evidence, not hidden truth. A claim

therefore carries its supporting evidence, time interval, missing expected evidence, alternatives, limitations and confidence or support score. F. Assurance Package The assurance package layer collects the experiment matrix, Monte Carlo design, runtime graph, competency queries, tests, reports and manifest. These artifacts make the framework falsifiable. A scenario package is not complete when the simulator runs once; it is complete when its artifacts can be checked as a chain. Table II summarizes the common delivery method. The table is intentionally procedural: it states what must exist before a result can be reviewed, rerun or challenged. The important property is not identical domain logic across scenarios, but a shared traceability spine. A reviewer should be able to start from a reported result and find the requirement or assumption that motivated it, the entities and process steps involved, the configuration and seed that produced it, the evidence record that supports it, the tests that checked it and the manifest entry that identifies the exact artifacts. For the Car2X scenario, this means that a replayed-request experiment is not reported only as “blocked”. The assurance package also records which request was observed, which validation reason was produced, why the policy applied blockrecord, whether any queue or freshness condition limited the result, whether the traffic controller remained unactuated and which evidence object and manifest hash support the statement. If the message observation is lost or delayed, the package should report an unsupported or limited claim rather than presenting the run as a successful detection. The final assurance-package step is claim discipline: limiting conclusions to the evidence actually present in the package. A scenario may be planned, formalized, executable, internally validated, externally calibrated or deployed; these labels describe evidential maturity, not the ambition of the use case. In this paper, the implemented packages support internally validated synthetic claims: the declared models, controls, evidence paths, experiments, tests and reports behave as specified under stated synthetic assumptions. They do not establish operational safety, legal compliance, standards conformance, radio performance, industrial fidelity or pilot KPIs. For Car2X, for example, the package may claim that a forged or replayed

9

TABLE II C OMMON SEAL-DT DELIVERY METHOD FOR SECURITY-DT SCENARIOS . Stage

Gate

Required outcome

1 2 3 4 5 6 7 8 9 10

Source-governed case Canonical model Process and behaviour Security governance Implementation Experiments Evidence graph Uncertainty Verification Handoff

Bounded scenario, source precedence, assumptions, prohibited capabilities and integration boundary. Stable entities, relationships, zones, roles, twins, data objects and schema-valid inventories. BPMN/lifecycle views, state variables, events, queues, observation loss, twin updates and failure branches. Detection, authorization, safety guards, minimization, evidence, custody, reconstruction and policy metrics. Deterministic simulator, named seeds, adapters, validation rules and complete run export. Nominal case, negative or degraded branches, expected assertions and comparison report. Runtime graph, evidence manifest, custody links, reconstruction and competency-query answers. Predeclared Monte Carlo design, null-aware summaries and sensitivity interpretation. Schema, invariant, privacy, safety, determinism, tamper, experiment and report-completeness tests. Integration contracts, dependency lock, technical report, validation matrix and SHA-256 artifact manifest.

request was blocked within the declared synthetic run and that visible evidence supports the decision. It may not claim protection of a real road junction, nor successful detection when the observation is missing or stale. Stronger claims require calibrated data, confirmed authority, real integration boundaries and operational safety evidence. IV. A PPLICATION TO SELECTED USE CASES A general assurance framework is useful only if it can be instantiated and checked across scenarios with different assets, observations, risks and authority constraints. The evaluation therefore asks whether the same source-governed, evidencebounded structure can be applied across heterogeneous cyberphysical settings without erasing their domain-specific constraints. The five use cases below were selected for this purpose because each stresses a different part of the framework: trust before control, passive and privacy-preserving observation, safety-constrained response, lawful evidence acquisition, and continuity-aware mitigation. The broad use-case titles are larger than any executable model can responsibly claim. For evaluation, each one is reduced to a bounded scenario with explicit assumptions and prohibited capabilities. Simulation is then needed to exercise the framework rather than merely describe it: each scenario must generate observations, decisions, evidence, degraded branches and claim limits that can be checked against the assurance package. Table III fixes the mapping used throughout the remainder of the paper and identifies the main framework aspect tested by each scenario. The subsections below state how each use case instantiates the framework. They do not yet report performance results; instead, they identify the domain specialization, canonical entities, executable implementation and expert-owned parameters needed before the simulations in Section V can be interpreted. To make the implementation logic inspectable without overloading the main text, UC1 is used as the detailed worked example: its entities, relationships, deterministic configuration, experiment branches and validation evidence are summarized in Section IV and reported in the Appendix. For space reasons, UC2–UC5 are presented in a shorter but comparable form, focusing on the scenario description, evaluation role, model content and expert parameters. The complete executable packages, proof artifacts, test evidence, configurations and generated reports for all use cases are available through the project repository: project repository.

A. UC1: Car2X attack-surface modelling Scenario description. A police test vehicle approaches a signalized junction and uses its on-board Car2X unit to exchange priority-related messages with roadside infrastructure. During the same run, a red-team transmitter injects forged or replayed messages that appear structurally plausible but should not be allowed to influence the traffic-signal controller. The digital twin must therefore follow the message, decide what is observable, validate trust and freshness, record any security decision, and show that an untrusted request was contained before it became a physical control effect. Evaluation role. UC1 tests whether the framework can distinguish an observed communication attack from authority to influence a physical controller. It is the trust-and-control case: the important outcome is not only that an attack is detected, but that the framework can explain why a visible request is not equivalent to an authorized command. The scenario therefore checks the full chain from observed message to validation result, policy action, controller guard and evidence-backed reconstruction. Definition. The simulated scenario contains a synthetic police test vehicle, its on-board unit (OBU), a roadside unit (RSU), a bounded traffic-signal controller and supporting trust, detection, policy, twin and evidence services. The OBU and RSU exchange abstract authenticated requests over a declared Car2X channel; the controller is reachable only through the RSU and only after validation and policy checks. The adversarial transmitter does not compromise a real vehicle or radio stack. It injects symbolic forged, replayed or flooded messages into the same abstract channel so that the framework can test denial, degradation and evidence paths under controlled conditions. No live radio, vehicle or traffic-control interface exists. Entities. The canonical model contains 30 entities and 60 typed relationships: vehicle, OBU, gateway, RSU, in-vehicle and signal controllers, traffic signal, adversarial transmitter, road-and-lab environment, four zones, operator, red-team and analyst roles, trust, detection, policy, twin and evidence services, and four physical–digital pairs. These entities make the scenario auditable: each message has a producer and receiver, each validation or policy decision is attached to the service that made it, each possible controller effect is linked to a protected physical endpoint, and each claim can be traced back to evidence rather than hidden simulator truth. The implementationlevel entity inventory, functional relationships, deterministic

10

TABLE III SEAL-DT USE - CASE NUMBERS , BOUNDED SCENARIOS AND THE FRAMEWORK PROPERTIES EXERCISED BY EACH SCENARIO .

UC

Name

Modelled scenario

Framework aspect tested

UC1

Identification and penetration of attack surfaces during Car2X communication On-the-spot detection and categorization of IoT devices in public spaces

A forged or replayed abstract request crossing an OBU–RSU trust boundary toward a safety-gated traffic-signal controller. Passive, pseudonymized multi-interface observation, association, classification and approval checking for a synthetic unapproved device. A non-sensitive one-vessel control surrogate subjected to symbolic protocol-aware fuzzing, unauthorized writes and bounded application load. Scoped CPE/Home Assistant evidence acquisition after unauthorized entry and door-sensor tampering, with authorization, minimization and custody. A synthetic patient-monitor flow anomaly whose response is constrained by clinical continuity, followed by redacted authorized evidence sharing.

Trust validation, authority and fail-safe separation from control effects.

UC2

UC3

UC4

UC5

Industrial cyberattacks and safety anomalies in nuclear/radiation emergency contexts Lawful forensic investigation in a smart home for IoT-enabled crime Monitoring and safeguarding connected medical devices in a hospital

Observation ambiguity, privacy limits and hypothesis-level twins. Hybrid process dynamics, safety guards and symbolic industrial attacks. Full evidence chain, authorization, minimization, custody and reconstruction. Safety-critical mitigation, continuity constraints and redacted evidence sharing.

configuration, experiment branches and validation evidence are enforcement capabilities, evidence authority/retention and the role of the DS1 in-vehicle dataset. These replace assumptions reported in the Appendix. DT implementation. The execution is organized as a trust- through versioned configuration or adapters without weakengated message pipeline. Messages first enter a finite channel ing safety and truth separation. queue, so delay, congestion and loss are explicit rather than implicit. Second, the RSU and trust service evaluate whether the message can be parsed, whether the trust service is B. UC2: Passive detection and categorization of IoT devices available, whether the credential is valid, whether the sender is Scenario description. A public-space-inspired synthetic authorized, and whether the timestamp, sequence and replay monitoring scene represents the kind of setting targeted by window are acceptable. The detector scores the visible vali- UC2, such as a transport hub, campus area or event venue, dation and traffic features with declared weights, producing without modelling a real location. Three passive observers an explainable alert rather than an opaque label. The policy generate abstract 3GPP, Wi-Fi and Bluetooth observations service translates the alert into an allowed mitigation such as from approved device classes and from one unapproved device drop, rate-limit, isolate or alert-only, and records whether that hypothesis. The system must support situational awareness mitigation was actually applied. Finally, the controller safety in this public-space domain, but it must not turn uncertain gate accepts only messages that have survived the trust and radio observations into confirmed identity, capture payloads policy path; rejected or untrusted requests can still be recorded or trigger active interference. as attempted transitions, but they do not change the controller Evaluation role. UC2 tests whether the framework can state. model partial observation without converting uncertain passive The DT state follows the same visibility discipline as signals into confirmed identity. It exercises hypothesis twins, the general framework. The vehicle, OBU, RSU and signal- privacy-preserving evidence and fail-closed behaviour under controller twins are updated only from observed message and loss, ambiguity and stale registry state. state events. The simulator may know that an injected message Definition. The model represents a synthetic public-space is an attack, but the operational twin and reconstruction logic observation area rather than a private home, vehicle, industrial cannot read that hidden label directly. They must infer from plant or real venue. Three approved device classes and one visible credentials, freshness, sequence behaviour, validation unapproved device hypothesis emit a small deterministic set results, alerts and policy records. Evidence is then minimized, of abstract 3GPP, Wi-Fi or Bluetooth observations. Passive hashed and custody-linked, allowing the final claim to state, observers pseudonymize metadata; analytics associates obserfor example, that a forged request was observed, rejected vations, estimates a device class, consults an approval registry and prevented from producing a controller effect within the and requests bounded review. Active interception, payload capdeclared synthetic model. ture, subscriber identity and location tracking are prohibited. Entities. The canonical model contains 25 entities and 26 Expert parameters. UC experts must confirm the Car2X profile (ITS-G5/C-V2X), message taxonomy and permissions, relationships: three passive observers and their twins, approved PKI semantics, radio/channel calibration, OBU/RSU/controller and unapproved device classes and hypothesis twins, scene, topology and telemetry, controller phases and minimum times, analytics and forensic zones, association and classification

11

TABLE IV UC1 CANONICAL ENTITIES USED BY THE EXECUTABLE PACKAGE . ID

Name

Class

Role in implementation

UC1 UC1-ENV01

Car2X scenario Controlled environment

UseCase Physical environment

UC1-NZ01

In-vehicle network

NetworkZone

UC1-NZ02

Car2X channel zone

NetworkZone

UC1-NZ03

Roadside backhaul

NetworkZone

UC1-NZ04

Security services zone

Network zone

UC1-D01 UC1-D02 UC1-D03

Police test vehicle On-board unit Vehicle gateway

ConnectedVehicle Vehicle comms unit Gateway

UC1-D04 UC1-D05

In-vehicle controller Roadside unit

Controller RoadsideUnit

UC1-D06

Traffic-signal controller

Controller

UC1-D07 UC1-D08

Traffic signal Adversarial transmitter

Actuator Test asset

UC1-D09

Observation component

Monitoring asset

UC1-S01

Traffic-management service

Service

UC1-S02

PKI/trust service

Security service

UC1-S03 UC1-S04

Detection service Policy service

Security service Security service

UC1-S05

Twin synchronization

DT service

UC1-S06

Evidence/custody service

Forensics service

UC1-S07 UC1-A01 UC1-A02 UC1-A03

Reconstruction service Vehicle operator Infrastructure operator Red-team operator

Forensics service HumanActor Organisation actor Human actor

UC1-A04

LEA analyst

LEAUser

UC1-DT01 UC1-DT02 UC1-DT05 UC1-DT06

Vehicle DT OBU DT RSU DT Signal-controller DT

TwinEntity TwinEntity TwinEntity TwinEntity

Bounds the controlled scenario proposal Contains synthetic vehicle and proposal roadside roles Separates OBU/gateway from assumed vehicle controllers Abstract V2I communication proposal boundary Connects RSU and traffic-control assumed services Hosts detection, policy, twin and eng. evidence services Protected demonstration platform proposal Vehicle Car2X endpoint proposal Abstract boundary to in-vehicle assumed systems Bounded downstream cyber target assumed Infrastructure endpoint and proposal validation point Evaluates accepted requests under assumed safety interlocks Displays simulated controller phase proposal Injects symbolic forged, replayed or eng. flood messages Produces bounded message and flow eng. observations Provides supervisory infrastructure assumed context Produces abstract credential, proposal freshness and authorization decisions Scores validation and traffic features eng. Requests mitigation and records proposal acknowledgement Maintains versioned observable proposal entity state Minimizes, hashes and registers eng. evidence Builds evidence-linked claims eng. Operates the synthetic test drive proposal Owns or supervises roadside assets proposal Initiates the controlled symbolic eng. attack Reviews minimized evidence and proposal reconstruction Mirrors observable vehicle state proposal Mirrors observable OBU state proposal Mirrors observable RSU state proposal Mirrors observable controller state proposal

Status

Assumption(s) UC1-001 UC1-002 UC1-003 UC1-004 UC1-005 UC1-006 UC1-007 UC1-004; UC1-008 UC1-003 UC1-009 UC1-010 UC1-011 UC1-011 UC1-001 UC1-012 UC1-005 UC1-013

UC1-014 UC1-015 UC1-016 UC1-017 UC1-018 UC1-019 UC1-020 UC1-001 UC1-017 UC1-016 UC1-016 UC1-016 UC1-016

components, registry, explainable detection, policy, consulta- review responses. Evidence is minimized, hashed and custodytion and forensic services, stakeholder and human roles, and linked; reconstruction uses evidence rather than hidden truth. Expert parameters. Experts must supply permitted obsersynthetic and future-data boundaries. DT implementation. The executable model treats each vation fields, legal/ethical authority, event topology, interface passive radio observation as a lossy and uncertain record. generations/bands, device taxonomy, approval-list governance, Whether a device is seen depends on the declared coverage of coverage/loss/delay and clock profiles, pseudonym rotation, asthe observer, the configured loss rate and the interface being sociation window, classifier calibration/confusion, thresholds, monitored. The observed features are intentionally noisy: they response capabilities, retention and DS2/DS3 licensing/mapsupport association and classification, but they do not expose ping. payloads, subscriber identity or precise location. Observations can be associated only when they fall within the declared C. UC3: Industrial cyber-physical surrogate time window and interface constraints. The classifier then Scenario description. A synthetic industrial control cell returns a most likely device class, alternative classes and a regulates the level of a single process vessel using a level senconfidence value; the approval state is represented separately sor, PLC, inlet pump and outlet valve. The HMI, engineering as approved, unapproved, unknown or stale. Here the twin workstation, historian, industrial gateway and passive monitor referent is explicitly a device hypothesis as well as observer are represented as supervisory and control-network assets state, so hypothesis fidelity and ambiguity are reported. The around that process. During the run, configured symbolic deterministic engine separates restricted emitter truth from events exercise smart fuzzing, unauthorized write attempts, lossy passive observations, enforces a bounded queue, exports application load, sensor-fault and observation-loss branches. class alternatives and confidence, and permits only non-RF The twin must follow both the cyber events and the evolving

12

TABLE V UC1 FUNCTIONAL RELATIONSHIPS , EXCLUDING SIMPLE BELONGS - TO - USE - CASE MEMBERSHIP EDGES . ID

Source

Relation

Target

Implementation meaning

UC1-REL-006 UC1-REL-007 UC1-REL-008 UC1-REL-009 UC1-REL-010 UC1-REL-011 UC1-REL-012 UC1-REL-013 UC1-REL-014 UC1-REL-015 UC1-REL-016 UC1-REL-017 UC1-REL-018 UC1-REL-019 UC1-REL-020 UC1-REL-021 UC1-REL-022 UC1-REL-023 UC1-REL-024 UC1-REL-025 UC1-REL-026 UC1-REL-027 UC1-REL-028 UC1-REL-029 UC1-REL-030 UC1-REL-031 UC1-REL-032 UC1-REL-033 UC1-REL-034 UC1-REL-035 UC1-REL-036

UC1-D01 UC1-D05 UC1-D02 UC1-D05 UC1-D02 UC1-D05 UC1-D05 UC1-D06 UC1-D08 UC1-D08 UC1-D09 UC1-S02 UC1-S03 UC1-S04 UC1-D06 UC1-D01 UC1-D02 UC1-D05 UC1-D06 UC1-S05 UC1-S05 UC1-S05 UC1-S05 UC1-S03 UC1-S02 UC1-S04 UC1-S06 UC1-S07 UC1-A01 UC1-A02 UC1-A03

DEPLOYED_IN DEPLOYED_IN communicates with communicates with communicates with validated by routes to CONTROLS TARGETS attempts to trigger FEEDS FEEDS TRIGGERS mitigated by protected by mirrored by mirrored by mirrored by mirrored by synchronizes with synchronizes with synchronizes with synchronizes with produces evidence produces evidence produces evidence FEEDS FEEDS OPERATED_BY OWNED_BY OPERATED_BY

UC1-ENV01 UC1-ENV01 UC1-NZ02 UC1-NZ02 UC1-D05 UC1-S02 UC1-D06 UC1-D07 UC1-D05 UC1-D06 UC1-S03 UC1-S03 UC1-S04 UC1-D05 UC1-S04 UC1-DT01 UC1-DT02 UC1-DT05 UC1-DT06 UC1-DT01 UC1-DT02 UC1-DT05 UC1-DT06 UC1-S06 UC1-S06 UC1-S06 UC1-S07 UC1-A04 UC1-D01 UC1-D05 UC1-D08

Vehicle is placed in the controlled environment. RSU is placed in the controlled environment. OBU uses the abstract Car2X channel. RSU receives through the abstract Car2X channel. OBU and RSU exchange abstract requests. RSU messages use trust validation. Accepted requests may reach the controller. Controller determines simulated signal phase. Symbolic transmitter targets the RSU. Attack attempts a controller effect. Observations feed detection. Trust results feed detection. Alerts trigger policy decisions. Mitigation is applied at the RSU boundary. Controller path is policy-protected. Vehicle has an observable DT. OBU has an observable DT. RSU has an observable DT. Controller has an observable DT. Twin service updates vehicle twin. Twin service updates OBU twin. Twin service updates RSU twin. Twin service updates controller twin. Alerts can become evidence. Trust decisions can become evidence. Policy decisions can become evidence. Verified evidence feeds reconstruction. Reconstruction is reviewed by analyst. Authorized operator runs the vehicle. Infrastructure operator owns the RSU role. Red-team operator controls the symbolic transmitter.

TABLE VI UC1 DETERMINISTIC SCENARIO CONFIGURATION USED FOR THE NOMINAL FORGED - REQUEST RUN .

Configuration area

Implemented value

Purpose in the UC1 evaluation

Scenario and seed

UC1 forged-control affecting-request; seed 1101; 120 s

Attack schedule

Forged request; start 45 s; count 3; interval 0.1 s; untrusted credential 20 messages/s; buffer 20; 20 ms base delay; 5 ms jitter; zero nominal loss; observation probability 1.0 Service available; freshness window 2 s; valid sender UC1-D02 Threshold 0.4; weights auth 0.45, freshness 0.25, and sequence, rate and plausibility 0.10 each Supported actions drop, rate-limit, isolate, alert-only; selected action drop; enforcement delay 0.05 s Initial phase safe-all-red; minimum phase 3 s; control requests synthetically allowed Enabled; message, trust, alert, policy and controller records; 3600 s retention OBU 0.01 s, RSU -0.01 s, detector 0.0 s

Makes the run deterministic and reproducible. Exercises trust validation and policy before control. Makes queueing, delay and observation explicit. Separates credential, freshness and sender authority. Produces explainable alerts rather than opaque scores. Tests requested versus applied mitigation.

Channel Trust validation Detector Policy Controller safety Evidence Clock offsets

Ensures no controller effect occurs without accepted authority. Defines what can support claims and reconstruction. Makes time provenance explicit.

Attack messages are scheduled from configuration and validated without constructing real protocol payloads or opening industrial-control adapters. Symbolic protocol-aware fuzzing, unauthorized writes, bounded application load and sensor-fault Evaluation role. UC3 tests the framework on a hybrid branches are tested; any mitigation is constrained by process process-control setting in which cyber events may have physsafety. The model does not expose or represent an operational ical consequences. Its value is to exercise process state, scannuclear facility. cycle control, symbolic protocol checks and safety-constrained mitigation without claiming nuclear-plant fidelity. Entities. There are 36 canonical entities and 60 relationDefinition. A deterministic one-vessel level-control surro- ships, including nine physical/logical twins, four zones, progate models a sensor, PLC, pump, outlet valve, HMI, engineer- cess and control assets, security and forensic services, stakeing workstation, historian, gateway and passive monitoring. holder roles and synthetic/SWaT/operations data boundaries. process state, but any mitigation must respect safe operating limits and scan-cycle control rather than react to detection alone.

13

TABLE VII UC1 EXPERIMENT MATRIX USED TO TEST NOMINAL , DEGRADED AND NEGATIVE BRANCHES .

Experiment branch

Perturbation

Expected framework property

baseline nominal forged request expired certificate revoked certificate replay outside window message flood

Attack disabled Base configuration Credential state expired Credential state revoked Replay, valid credential, replay age 10 s 50 messages, 0.01 s interval, buffer 3, service 5 messages/s Trust service unavailable Enforcement unavailable Observation probability 0.0

No alert or safety violation is invented. Alerts occur; controller effects remain zero. Trust failure is detected and blocked. Revocation is treated as a trust failure. Freshness violation prevents authority. Queue loss is explicit; no safety violation.

trust unavailable policy enforcement failed observation loss

Dependency failure fails closed. Alert and safety records remain inspectable. Hidden truth does not create alerts or claims.

TABLE VIII UC1 VALIDATION EVIDENCE SHOWING WHY THE IMPLEMENTATION CAN SUPPORT AN INTERNAL FRAMEWORK - VALIDITY CLAIM .

Requirement area

Status

Evidence retained in the package

Scenario, sources and assumptions Entities and stable IDs Relationships and graph Formal model and BPMN views Deterministic simulation Trust, detection and policy Controller safety Evidence, custody and reconstruction Experiment and uncertainty matrix Clean-environment validation

Complete Complete Complete Complete

Use-case document and assumption register; partner confirmation remains calibration work. models/instances/uc1_entities.json; schema tests. 60 relationships; graph tests; models/graph/uc1_graph.json. Formal model plus seven BPMN process files.

Complete Complete Complete Complete

Simulation, reproducibility tests and generated run artifacts. Validation events, explanation records and negative branches. Zero violations across tests and experiments; not a safety certification. Hashing, minimization, tamper tests and evidence-linked reconstruction.

Complete

Nine passing branches and 100 predeclared synthetic samples.

Partial

Lock file and passing tests; independent CI/platform run remains future work.

DT implementation. The executable model updates the vessel level from configured inflow, outflow and actuator settings while keeping the value within declared bounds. The PLC reads the level at scan boundaries and applies a simple hysteretic control rule, so commands do not change continuously or outside the control cycle. Cyber requests traverse a bounded queue and symbolic protocol/authorization checks before they can influence detector scores or policy decisions. The nine twins accept only versioned observations, and the reconstruction step is built from retained evidence rather than from hidden simulator truth. Expert parameters. Experts must confirm a non-sensitive abstract topology, vessel, flow, sensor and scan parameters, safe envelopes and interlocks, protocol and request abstraction, observation coverage, gateway capability, detection/policy calibration, retention and human responsibilities. SWaT and operations datasets remain unavailable until licensing, checksum, field mapping and scope review are complete. D. UC4: Smart-home lawful forensic acquisition Scenario description. A synthetic smart home records an unauthorized door opening followed shortly by door-sensor tampering and disconnection. Home Assistant may trigger an entry-light automation, while CPE flow records and device state events provide partially overlapping source evidence. A case trigger starts the investigation workflow, but evidence may

be collected only through scoped authorization, minimization, custody and reconstruction rules. Evaluation role. UC4 is the evidence-chain stress test. It exercises the largest graph, the deepest evidence model and the strongest reconstruction requirements, including explicit authorization, minimization, custody, tamper handling and qualified claims under missing or degraded sources. Definition. Unauthorized door entry and door-sensor tampering occur in a synthetic armed, unoccupied smart home. Home Assistant may trigger a light; CPE and application records overlap imperfectly. A case trigger remains separate from authorization. A valid scoped request collects minimized records through an abstract lawful-interception module, preserves custody and supports a qualified reconstruction. Entities. The model contains 38 entities and 123 relationships: premises, CPE, Home Assistant, door and presence sensors, smart plug, smart light, optional cloud, six twins, resident, unauthorized, investigator, auditor and authority roles, policy, alert and data records, evidence, custody and reconstruction services across three zones. Nine common schemas are augmented by nine legacy device inventory schemas. DT implementation. UC4 instantiates the full evidence workflow. The simulation keeps imperfect sensing, source clocks, CPE flow consistency and monotonic twin versions visible. Authorization is checked before acquisition using the declared purpose, validity, evidence window, entities, record

14

types and requested action. Before disclosure, records are projected to the permitted fields, hashed in canonical form, linked into custody and used to build an interval-based reconstruction with explicit alternatives. Expert parameters. Experts must confirm device makes and capabilities, protocols, CPE and Home Assistant APIs and retention, evidentiary fields, real authorization and purpose semantics, network, clock and sensor calibration, cloud scope, identity handling and calibrated claim weights. Current legal and privacy controls are executable safeguards, not a legal opinion or admissibility claim. E. UC5: Clinical-continuity-aware medical IoT monitoring

distributions, attack abstraction, observation and clock profiles, detection calibration, mitigation rights and review, evidence purpose, redaction/sharing authority, retention, stakeholder ownership, and DS8 licensing and field mapping. V. S IMULATION D ESIGN AND R ESULTS The use-case descriptions above define what each scenario must represent, which entities and relationships are in scope, and which expert assumptions still bound the model. The next step is to test whether these descriptions can be executed as consistent DT packages rather than remaining conceptual examples. For this reason, the evaluation focuses on simulation evidence: each scenario is run under nominal, degraded and negative conditions, and the resulting artifacts are checked against the framework’s requirements for observation boundaries, policy decisions, evidence handling and claim discipline. The results should therefore be read as framework-validity evidence. They show whether the proposed modelling chain can be instantiated across different application domains, whether the generated simulations expose the intended guards and failure modes, and whether the final claims are supported by observable records rather than hidden simulator truth. They do not claim field performance, operational calibration, legal admissibility, clinical safety or industrial fidelity.

Scenario description. A synthetic hospital patient monitor emits normal abstract flows and then shows anomalous egress to a new destination. In the nominal run the monitor is essential and no approved backup monitoring is active, so an isolation request must be rejected even when an alert is raised. A separate backup-active branch shows when bounded isolation becomes eligible. The framework must show whether a security response is permitted only when clinical continuity and evidence-sharing constraints are satisfied. Evaluation role. UC5 tests whether governance can encode a domain-specific safety priority that overrides a plausible security response. It exercises requested-versus-applied mitigation, continuity constraints, redaction and authorized sharing A. Evaluation Design and Evidence Status in a clinical setting. Each use case follows the same experimental structure. A Definition. A synthetic patient monitor produces normal baseline or nominal scenario checks the expected path through abstract flows. A symbolic compromise produces anomalous the model. Negative or degraded branches then test whether egress and inconsistent health metadata. Detection and policy missing observations, unavailable services, invalid authority, must preserve essential monitoring: isolation is ineligible in queue pressure, tampering or unsafe response conditions are the no-backup nominal configuration and eligible only in the represented as explicit outcomes. A 100-sample uncertainty backup-active branch. Evidence is minimized, redacted and design varies declared synthetic parameters to show which shared only under explicit authority. No patient data, diagnosis, assumptions dominate the reported metrics. Finally, schema, treatment or medical actuation is permitted. invariant, determinism, privacy/safety and report completeness Entities. The canonical model contains 34 entities and 45 tests check whether the generated artifacts support the stated relationships: a patient monitor and inactive future device claim. classes, gateway, switch, collector and console assets, four All simulations are deterministic and synthetic. Their exzones, registry, explainable detection, clinical-safety policy, ev- periment matrices probe designed edge cases, while the 100idence and custody, redaction and sharing, reconstruction and run analyses vary declared uncertain parameters. Results are threat-context services, seven twins, synthetic and future-data descriptive model outcomes and are not statistical estimates boundaries, and clinical, security and investigator stakeholder of field performance. “Complete” therefore means complete roles. against the internal implementation contract, not externally DT implementation. The executable DT records observable calibrated or deployed. device health, flow behaviour, destination changes, care depenTable IX summarizes the implementation evidence available dency, freshness and safety decisions. Isolation is allowed only for each use case. Its purpose is to show that all scenarios were when the request is authorized, the capability exists and conti- implemented and internally validated against the same artifact nuity of essential monitoring is preserved through an approved contract, while still allowing different numbers of entities, backup or a non-essential device status. The implementation relationships, schemas, process views and tests according to separates restricted attack truth from observations, exports domain complexity. feature contributions and alternatives, records requested versus Together, the implementations comprise 163 canonical entiapplied response, rejects unsafe isolation, verifies evidence ties, 314 typed relationships, 37 BPMN artefacts, 52 passing and custody, redacts shared packages and reconstructs from experiment branches, five 100-sample uncertainty analyses and evidence only. 114 passing tests. Each package also contains source and Expert parameters. Hospital and UC experts must de- configuration documentation, inventories and data mappings, fine device and zone inventory, vendor-neutral flow/health restricted-data boundary instructions, schema-valid event and contracts, clinical criticality and backup criteria, normal-flow evidence fixtures, integration contracts, a compiled technical

15

TABLE IX VALIDATED IMPLEMENTATION SUMMARY FOR THE FIVE COMPLETED USE CASES .

UC

Entities

Relations

Core schemas

BPMN

Tests

UC1 UC2 UC3 UC4 UC5

30 25 36 38 34

60 26 60 123 45

9 9 9 9+9 9

7 7 8 7 8

22 11 21 47 13

report, retained validation evidence, a final handoff and a verified SHA-256 manifest. B. Simulation and Results The following subsubsections report the simulation design, observed results and framework-validity interpretation for each use case. The ordering follows the use-case descriptions in Section IV, so that each result can be read against the corresponding scenario assumptions and model boundaries. 1) UC1: Trust Before Control: Simulation design. UC1 uses three nominal requests and an abstract channel. It applies fail-closed trust validation, transparent weighted detection, bounded policy actions and a signal safety interlock. Nine branches cover baseline, forged requests, expired or revoked credentials, replay, flood, trust-service unavailability, enforcement failure and complete observation loss. Results. In the nominal run, all 3 attack messages were observed and alerted (recall 1.0); validation and policy rejected them; controller effects, safety violations, integrity failures and unauthorized disclosures were all zero; evidence capture recall was 1.0. In the flood branch, 50 attacks were generated, only 3 observed and 47 dropped by queue overflow, producing recall 0.06. Under complete observation loss, no alert was emitted. Across 100 predeclared samples, mean attack-detection recall was 0.28 (normal-approximation 95% interval 0.200–0.360), evidence capture recall was 1.0, and controller effects and safety violations remained zero. Framework-validity interpretation. The implementation demonstrates fail-safe separation of untrusted requests from controller effects. It also demonstrates that perfect nominal recall depends on ideal observation and queue conditions: when coverage and capacity are varied, detection drops while the safety gate still prevents controller effects. 2) UC2: Passive Observation and Privacy: Simulation design. The versioned configurations define a 60-s passive scene with three approved devices, one nominal unapproved device, four emissions per device, three interface families, 0.95 coverage, 0.02 loss, a 2-s association window, capacity 50, classifier accuracy parameter 0.90 and threshold 0.70. The nine configured branches cover baseline, nominal, singleinterface, observation loss, overflow, registry unavailable/stale, low confidence and policy unavailability. A 100-sample design varies coverage, loss, association window, classifier accuracy and threshold. Results. The nominal run delivered 45 observations, recorded three lost observations, formed four classifications

and raised one explainable alert. Queue overflow, process effects, safety violations, active RF actions and unauthorized disclosures were zero. All nine branches passed their assertions: complete observation loss and severe queue overflow suppressed alerts rather than inventing certainty; unavailable/stale registry and low-confidence cases also failed closed. Across 100 predeclared samples, mean alert count was 0.60; active RF actions, unauthorized disclosures and safety violations remained zero. Eleven retained tests passed. Framework-validity interpretation. UC2 demonstrates the framework’s passive and privacy invariants and makes information loss visible. Its alert behavior is an internally consistent synthetic baseline, not evidence of field identification accuracy or lawful operational authority. 3) UC3: Safety-Constrained Industrial Response: Simulation design. UC3 selected a deliberately non-sensitive onevessel surrogate with fixed scan-boundary control. Six symbolic attack requests drive the nominal scenario. Nine branches distinguish unauthorized write, application flood, sensor fault, observation loss, enforcement failure, unsafe isolation and clock skew from baseline. Safety is enforced independently of alerting. Results. The nominal run generated and validated 6 attack messages and 6 alerts, with attack-detection recall 1.0. Process level remained at 5.0 m in the retained nominal output; process effects, safety violations, integrity failures and unauthorized disclosures were zero. All nine branch assertions passed. Application flood produced four alerts; complete observation loss produced none. Across 100 runs, mean alert count was 3.88, while mean process effects and total safety violations were zero. Twenty-one retained tests passed. Framework-validity interpretation. The model verifies its architectural safety invariant and attack/fault branch mechanics, not industrial-plant realism. A constant nominal level and zero effects show containment in this abstraction; they do not validate process fidelity or real detection quality. 4) UC4: Lawful Evidence and Reconstruction: Simulation design. UC4 fixed a 1,800-s horizon: warm-up at 300 s, entry at 600 s, tampering and disconnection at 610 s, case trigger at 900 s and acquisition at 920 s. Case and authority are separate. Payload capture is disabled; every record is independently checked and minimized. Sixteen branches probe authorization absent/invalid/expired/revoked, out-of-scope data, missing events, record eviction, CPE overflow/unavailability, clock skew, evidence/custody tampering and Home Assistant failure. Results. The nominal branch collected and verified 17/17 relevant items (capture recall and evidence precision 1.0), released zero unauthorized bytes, and produced three strong claims. Collection p95 was 0.016 s and investigation latency 20.017 s. Reconstruction recall was 1.0, precision 0.5, timestamp MAE 0.0424 s, mean twin lag 0.488 s, acquisition utilization 0.190 and peak acquisition occupancy 4,040 bytes. Precision 0.5 reflects ten reconstructed relevant candidates for five matched truth events, and must not be hidden by the perfect recall. Negative branches behaved as designed. Missing, invalid or expired authorization released no evidence. A one-byte CPE queue dropped 12 records (loss rate 0.869) but retained 11 ver-

16

ified items. Content tampering quarantined one item; custody- the cells contain only numeric outcomes. Blank cells denote link tampering quarantined all 17 and left claims unsupported. metrics that are not defined by the corresponding simulator. Home Assistant unavailability removed the automation claim The column headings and captions define the metric, while the while entry and tamper remained strong. Maximum clock skew preceding use-case text explains the domain-specific meaning widened maximum uncertainty from 4.43 s to 60.43 s. All 16 of each number. branch assertions and 47 final tests passed. TABLE X Across 100 runs, mean capture recall was 0.899 (95% N OMINAL EXPERIMENT RESULTS . “G EN .” AND “O BS .” COUNT interval 0.839–0.959, n = 99), mean reconstruction recall GENERATED AND OBSERVED MESSAGES , OBSERVATIONS , FLOWS OR EVIDENCE - SOURCE RECORDS ; “E VID .” IS EVIDENCE - CAPTURE RECALL 0.665 (0.605–0.725), mean strong-claim count 2.03 (1.83– 2.23), and zero-unauthorized-disclosure occurred in 100/100 FOR UC1 AND PRESERVED / SHARED EVIDENCE ITEMS FOR UC4 AND UC5; “R EC .” AND “P REC .” ARE RECONSTRUCTION RECALL AND PRECISION . runs (Wilson 95% interval 0.963–1.0). Mean twin lag was 4.87 s; its strongest reported linear sensitivity was clock-offset UC Gen. Obs. Lost Alerts Evid. Rec. Prec. Effects Viol. bound (r = 0.883). Collection start delay was nearly perfectly UC1 3 3 0 3 1.0 0 0 UC2 48 45 3 1 0 0 correlated with collection and investigation latency in the UC3 6 6 0 6 0 0 declared design, a structural consequence rather than a causal UC4 17 17 0 17 1.0 0.5 0 UC5 80 80 0 1 84 0 0 field finding. Framework-validity interpretation. UC4 is the most complete demonstration of the framework. It shows that authoTABLE XI rization, minimization and tamper detection can be tested as S TRESS AND DEGRADED - BRANCH EXPERIMENT RESULTS . “PASS ” executable invariants and that useful claims can survive partial COUNTS PASSING BRANCHES ; “OVERFLOW ” AND “O BS L OSS ” REPORT source loss. Its reconstruction precision, stale-state fraction THE MAXIMUM OBSERVED LOSS COUNTS IN OVERFLOW AND OBSERVATION - LOSS BRANCHES ; “L OSS A LERTS ” COUNTS ALERTS WHEN and delay sensitivities also show why a successful nominal OBSERVATIONS ARE COMPLETELY LOST; “B LOCKS ” COUNTS EXPLICIT narrative must not be mistaken for calibration. AUTHORITY OR SAFETY BLOCKING DECISIONS ; “Q UAR .” COUNTS QUARANTINED EVIDENCE ITEMS ; AND “E FFECTS ” REPORTS THE 5) UC5: Clinical Continuity Before Isolation: Simulation MAXIMUM SIMULATED PROCESS EFFECT COUNT. design. The versioned 60-s configurations define an essential patient monitor with no nominal backup, 20 normal flows of UC Branches Pass Overflow ObsLoss LossAlerts Blocks Quar. Effects 1,000 bytes, a symbolic fourfold anomalous-egress multiplier UC1 9 9 47 6 0 6 0 0 and a new destination. The detector weights rate/bytes/destiUC2 9 9 46 48 0 0 0 0 UC3 9 9 0 0 1 0 0 nation/health as 0.25/0.25/0.30/0.20 at threshold 0.5. Isolation UC4 16 16 12 1 1 17 0 is requested but must be safety-rejected without backup. Nine UC5 9 9 100 80 0 1 0 1 configured branches cover baseline, nominal, flood, observation loss, backup state, enforcement failure, health fault and sharing denial; a 100-sample design varies attack multiplier, TABLE XII U NCERTAINTY EXPERIMENT RESULTS . VALUES ARE M ONTE C ARLO observation/loss and threshold. MEANS OVER 100 PREDECLARED SIMULATION RUNS PER USE CASE . Results. The nominal run generated and observed 80 ab“D ET R EC ” DENOTES ATTACK - DETECTION RECALL , “C AP R EC ” stract flows, raised one explainable alert and requested isola- EVIDENCE - CAPTURE RECALL , “R ECON R EC ” RECONSTRUCTION RECALL , “C LAIMS ” STRONG RECONSTRUCTED CLAIMS , “L OSS ” OBSERVATION tion. The safety gate rejected that request because the essential LOSS AND “R EJECT ” SAFETY REJECTIONS . monitor had no approved backup; consequently process effects and essential-monitoring interruptions were zero. It verified UC Alerts DetRec CapRec ReconRec Claims Loss Reject Viol. and shared 84 minimized evidence items with zero patient-data UC1 0.28 1.0 0 UC2 0.60 13.07 0 disclosures, privacy violations, safety violations or integrity UC3 3.88 0 failures. In the backup-active branch, one bounded isolaUC4 0.899 0.665 2.03 0 UC5 1.0 1.0 0 tion was eligible while interruption remained zero. All nine branches passed; unauthorized sharing exported no evidence IDs and a health-only fault produced no cyber alert. Across TABLE XIII 100 runs, mean alert and safety-rejection counts were both 1.0, VALIDATION AND IMPLEMENTATION EVIDENCE . A LL LISTED PACKAGES with zero essential interruptions, patient disclosures, privacy ARE INTERNALLY VALIDATED AGAINST THE SAME ARTIFACT CONTRACT. violations and safety violations. Thirteen retained tests passed. UC Tests Branches Entities Relations Schemas BPMN Framework-validity interpretation. UC5 makes clinical continuity an executable hard constraint and demonstrates UC1 22 9 30 60 9 7 UC2 11 9 25 26 9 7 fail-closed evidence sharing. These synthetic invariants do UC3 21 9 36 60 9 8 not establish clinical safety, hospital fidelity or regulatory UC4 47 16 38 123 18 7 UC5 13 9 34 45 9 8 compliance. C. Framework-Validity Findings Across Use Cases Tables X–XIII summarize the simulation evidence by experiment type. In each table, the use cases are rows and

Table XIV summarizes the main result and supported claim for each use case. The results support the framework’s internal validity in four ways. First, the cases could be represented through

17

TABLE XIV S UMMARY OF SIMULATION RESULTS AND FRAMEWORK - VALIDITY INTERPRETATION ACROSS THE USE CASES .

UC

Primary decision

Nominal observable result

Stress evidence

Defensible claim

UC1

Trust and safety before control Passive, pseudonymous observation Safety guard before mitigation Authority and minimization before release Care continuity before isolation

3/3 attacks alerted; no controller effect 45 observations; 4 classes; 1 alert

Flood recall 0.06; loss gives no alerts Loss/overflow and stale dependencies fail closed

Fail-safe path works in synthetic model Passive/privacy invariants hold

6 alerts; no process effect

Loss gives no alerts; all branches pass Tamper quarantined; source loss degrades claims

Surrogate invariants hold

UC2 UC3 UC4 UC5

17 verified items; three strong claims; zero disclosure 1 alert; isolation rejected; no interruption

Backup permits bounded isolation; unauthorized share denied

Full synthetic assurance chain works Continuity/privacy invariants hold

the same source-governed case, canonical model, process/be- action, and in UC5 it isolates an essential monitor without an haviour, security-governance and assurance-package structure. approved backup. UC4 shows the same problem in evidenceThis supports wider applicability, because the cases differ governance form: a request for access is treated as if it were an in referents, observations, policies, evidence rules and safety authorization grant. The unqualified-claim twin keeps strong constraints. Second, the simulations made failed or degraded claims after the evidence base has degraded; the UC4 case conditions observable rather than hiding them: observation is the clearest example, because strong entry, automation and loss removed alerts, tampering quarantined evidence, unsafe tamper claims survive custody tampering or total source-record isolation was rejected and source loss weakened claims. Third, loss. These ablations do not measure detector performance. They zero harmful effects were meaningful only where attempted transitions and guard rejections were also recorded; otherwise test whether attractive but invalid conclusions are blocked by a scenario could simply be inert. Fourth, Eq. (15) was reusable the framework. The answer is positive in all five packages. as a governance pattern, but the meaning of safety or authority Hidden truth is not allowed to become observed evidence, reremained domain-specific: trust in UC1, passive privacy in quested mitigations are not allowed to become applied actions UC2, process safety in UC3, authorization in UC4 and clinical without a guard, and claims are not allowed to remain strong continuity in UC5 required different expert-owned predicates. when their evidence support has been damaged. This is the The same results also bound the validity claim. They val- same discipline exercised in the nominal and degraded experidate the framework as a reproducible method for building iments, but viewed from the opposite direction: by removing internally consistent, evidence-qualified security-DT simula- the discipline, the model immediately produces overconfident tions. They do not validate operational performance, detec- alerts, unsafe or unauthorized actions and unsupported claims. tor accuracy, legal admissibility, clinical safety or industrial VI. L IMITATIONS AND F UTURE W ORK fidelity. Those stronger claims require the future calibration and external validation steps listed in Section VI. The evaluation shows that the framework can be implemented consistently across different security-DT scenarios, but D. Counterfactual Assurance Checks the evidence remains deliberately bounded. The simulations As a final negative check, we ran three deliberately naive test internal coherence, traceability, visibility control, policy variants against the same five generated packages. The first enforcement and evidence handling under declared assumpvariant lets the twin read hidden attack or incident truth tions. They are not intended to stand in for field measureeven when the observation layer does not contain it. The ments, certified safety cases, legal admissibility assessments second treats a requested security action as if it had also been or deployment KPIs. The main limitations therefore concern authorized and applied. The third removes claim qualification, the distance between an internally validated synthetic package so that strong claims are not downgraded after evidence loss, and an externally calibrated operational system. The most important limitations are the following. tampering or source degradation. These ablations are not proposed alternatives; they are controlled anti-patterns used • Synthetic and uncalibrated dynamics. The parameters used in the experiments are explicit simulation assumptions. to test whether the framework rules prevent invalid certainty. Table XV shows the expected pattern. The oracle-leaking The reported values should therefore be read as evidence twin looks better than the framework in the wrong places: about the framework implementation, not as estimates of UC1, UC3 and UC5 recover high-confidence attacks under operational performance in the corresponding real environcomplete observation loss, while UC2 identifies an unapproved ments. device with no passive observations. The requested-equals- • Uneven implementation depth. Each package satisfies the applied twin fails where action semantics matter. In UC3 common internal completion contract. However, UC1–UC3 it turns an unsafe isolation request into an applied process and UC5 use compact formal models, whereas UC4 contains

18

TABLE XV NAIVE - TWIN ABLATION OUTCOMES . E ACH CELL REPORTS WHAT THE CORRESPONDING NAIVE VARIANT WOULD CLAIM OR DO AFTER ONE SEAL-DT DISCIPLINE IS REMOVED . UC

Oracle-leaking twin

Requested = applied

UC1

Observation-loss branch changes from 0 observed attacks and 0 alerts to confident recall 1.0. Zero passive observations still produce an unapproved-device claim. Missing observations still produce 6 alerts and recall 1.0. Source-record eviction still reconstructs a complete incident narrative. Zero observed flows still produce a confident compromised-monitor alert.

Failed enforcement is recorded as applied, overstating A forged-message claim remains strong despite mitigation success. missing attack observations. Passive monitoring invents an active applied response. A strong classification survives a two-observation overflow record. Unsafe isolation becomes an applied process action, A strong attack claim survives no observable attack yielding a safety violation. evidence. An authorization request is treated as a release grant. Three strong claims survive custody tampering or total source-record loss. Isolation is applied without backup, causing a A strong compromise claim survives missing clinical continuity violation. flow evidence.

UC2 UC3 UC4 UC5

deeper equations, experiments and assurance artefacts. This limits the breadth of cross-UC comparison without changing the completion status of the individual packages. • Simplified detection models. The detectors use transparent weighted rules rather than trained or externally validated AI models. The Monte Carlo ranges capture designer-specified uncertainty, not learned parameter distributions. • Limited physical fidelity. The network models use event and flow queues rather than packet-level or RF emulation. Controllers and sensors are bounded surrogates, and the simulations do not include geometry, protocol stack behaviour or hardware timing. • Bounded evidence claims. Hashes and custody chains detect modelled alteration within the package. They do not authenticate external collectors or keys, prove legal authority, or establish legal admissibility. • Limited metric comparability. Similar metric labels can refer to different domain populations. Cross-UC aggregation would require a common measurement ontology, shared denominators and agreed reporting conventions. • No independent validation yet. The tests were produced within the project and focus on implementation. External datasets, testbeds, domain experts and red-team review are needed to challenge the model structure. • Cross-package drift risk. Keeping per-UC packages protects domain distinctions, but it also duplicates schemas and utilities. Premature consolidation would hide important differences; leaving everything separate indefinitely would allow divergence. A. Prioritized future work The next phase should move from implementation closure to expert calibration and independent evaluation. The first step is to convene use-case expert reviews that resolve the open parameters listed in the scenario descriptions. Each accepted value should be recorded with its source, unit, uncertainty, owner and effective version. Candidate datasets should then be introduced only after their licence, checksum, field mappings, time mappings, identity mappings and missingness assumptions are approved. The synthetic modes should remain as reproducible controls. A second line of work is architectural. The project should define a minimal common kernel for stable identifiers, event envelopes, visibility labels, canonical hashing, custody, null-

No claim qualification

aware metrics and manifests, while keeping physical dynamics, observation models, policy predicates and domain schemas in the per-UC packages. Canonical entities and provenance records should then be mapped to interoperable representations such as AAS and W3C PROV, with round-trip loss measured explicitly. A third line of work is validation. Mutation and property tests, model checking of critical invariants, differential checks between equations and code, independent security review and continuous manifest verification would make the assurance packages harder to satisfy accidentally. After that, calibration, hardware/software-in-the-loop experiments and pilot validation can be introduced under a staged claim protocol: calibrated results must identify their dataset and uncertainty, while deployed results must identify their adapter, authorization path and safety case. Operational KPIs should be reported only after denominators, baselines and validation protocols have been agreed. VII. C ONCLUSIONS The primary outcome is a framework for making cyberphysical Digital Twin work auditable from definition to result. SEAL-DT treats an entity graph, mathematical model, process diagram, simulator, evidence record and test report as mutually constraining views of one system. Its proposed DT definition adds observation admissibility, fidelity, freshness, provenance and authority to the usual physical–digital correspondence. Its central invariant prevents hidden simulation truth from silently entering operational state or forensic claims. The evaluation indicates that this structure can be applied beyond a single case without reducing every system to the same model. The important result is not that the simulations reproduce operational environments, but that they preserve the same assurance discipline while allowing different assets, observations, policies, safety constraints and evidence rules. In each case, normal and degraded runs remain traceable to declared assumptions, and failed conditions become explicit results rather than silent gaps in the model. The broader conclusion is that secure DTs need an assurance architecture, not only a synchronized state model. A useful DT for security analysis must say what it can observe, what it cannot observe, which actions it may support, which claims are evidence-backed and where uncertainty remains. SEALDT provides a practical way to encode those boundaries so that simulations, tests and reports can be reviewed together.

19

The framework’s value is therefore not a promise of universal fidelity or deployment readiness. It is a disciplined way to state what is known, what is assumed, what was observed, what was decided and what evidence supports each claim. That discipline is a necessary foundation for later interoperability, expert calibration, independent validation and responsible deployment of security-oriented Digital Twin systems. ACKNOWLEDGMENT This work has received funding from the European Union’s Horizon Europe research and innovation programme under Grant Agreement No. 101225719 (SALUS: Strengthening law enforcement with advanced IoT forensic tools and enriched investigation schemes, realised by a Software Defined Network Security-as-a-Service architecture). Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the granting authority. Neither the European Union nor the granting authority can be held responsible for them. A PPENDIX This appendix records the implementation-level content behind the UC1 Car2X evaluation. The purpose is not to claim operational Car2X fidelity, but to make the synthetic implementation inspectable: the reader can see which entities exist, which relationships bind them, which assumptions remain, and which experiment branches were used to test the framework. These details are reported in Tables IV–VIII. R EFERENCES [1] E. H. Glaessgen and D. S. Stargel, “The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles,” 53rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, AIAA 2012-1818, 2012. doi: 10.2514/6.2012-1818. [2] International Organization for Standardization, ISO 23247-1:2021, Automation systems and integration—Digital twin framework for manufacturing—Part 1: Overview and general principles, 2021. https: //www.iso.org/standard/75066.html. [3] Digital Twin Consortium, Digital Twin System Interoperability Framework, 2021. https://www.digitaltwinconsortium.org/wp-content/uploads/ sites / 3 / 2022 / 06 / Digital - Twin - System - Interoperability - Framework 12072021.pdf. [4] Industrial Digital Twin Association, Specification of the Asset Administration Shell, Part 1: Metamodel, IDTA 01001, version 3 series. https://industrialdigitaltwin.org/en/content-hub/aasspecifications. [5] E. R. Griffor, C. Greer, D. A. Wollman, and M. J. Burns, Framework for Cyber-Physical Systems: Volume 2, Working Group Reports, NIST SP 1500-202, 2017. doi: 10.6028/NIST.SP.1500-202. [6] Z. Yu, H. Gao, X. Cong, N. Wu, and H. H. Song, “A Survey on CyberPhysical Systems Security,” IEEE Internet of Things Journal, vol. 10, no. 24, pp. 21670–21686, 2023. doi: 10.1109/JIOT.2023.3289625. [7] S. R. Jeremiah, A. El Azzaoui, N. N. Xiong, and J. H. Park, “A Comprehensive Survey of Digital Twins: Applications, Technologies and Security Challenges,” Journal of Systems Architecture, vol. 151, Art. no. 103120, 2024. doi: 10.1016/j.sysarc.2024.103120. [8] A. R. Qureshi, A. Asensio, M. Imran, J. Garcia, and X. Masip-Bruin, “A Survey on Security Enhancing Digital Twins: Models, Applications and Tools,” Computer Communications, vol. 238, Art. no. 108158, 2025. doi: 10.1016/j.comcom.2025.108158. [9] E. Balta, M. Pease, J. Moyne, K. Barton, and D. Tilbury, “Digital Twin-Based Cyber-Attack Detection Framework for Cyber-Physical Manufacturing Systems,” IEEE Transactions on Automation Science and Engineering, 2023. doi: 10.1109/TASE.2023.3243147.

[10] F. Moradi, S. Abbaspour Asadollah, B. Pourvatan, Z. Moezkarimi, and M. Sirjani, “CRYSTAL Framework: Cybersecurity Assurance for Cyber-Physical Systems,” Journal of Logical and Algebraic Methods in Programming, vol. 139, Art. no. 100965, 2024. doi: 10.1016/j.jlamp.2024.100965. [11] M. Eckhart and A. Ekelhart, “Digital Twins for Cyber-Physical Systems Security: State of the Art and Outlook,” in Security and Quality in Cyber-Physical Systems Engineering, Springer, 2019, pp. 383–412. doi: 10.1007/978-3-030-25312-7_14. [12] M. Dietz, M. Vielberth, and G. Pernul, “Integrating Digital Twin Security Simulations in the Security Operations Center,” in Proceedings of the 15th International Conference on Availability, Reliability and Security (ARES 2020), ACM, 2020. doi: 10.1145/3407023.3407039. [13] M. Eckhart, A. Ekelhart, D. Allison, M. Almgren, K. Ceesay-Seitz, H. Janicke, S. Nadjm-Tehrani, A. Rashid, and M. Yampolskiy, “SecurityEnhancing Digital Twins: Characteristics, Indicators, and Future Perspectives,” arXiv:2305.00639, 2023. https://arxiv.org/abs/2305.00639. [14] K. E. Kampourakis, V. Gkioulos, and S. Katsikas, “Cybersecurity Digital Twins for Industrial Systems: From Literature Synthesis to Framework Design,” Information, vol. 17, no. 3, Art. no. 286, 2026. doi: 10.3390/info17030286. [15] M. Dietz, L. Englbrecht, and G. Pernul, “Enhancing Industrial Control System Forensics Using Replication-Based Digital Twins,” in Advances in Digital Forensics XVII, IFIP Advances in Information and Communication Technology, vol. 612, Springer, 2021, pp. 21–38. doi: 10.1007/978-3-030-88381-2_2. [16] K. E. Kampourakis, V. Kampourakis, V. Gkioulos, and S. Katsikas, “Digital Twin-Assisted Mapping of ICS Telemetry to ATT&CK for ICS with Evidence-Driven Dependency Reasoning,” arXiv:2610.02955, 2026. https://arxiv.org/abs/2610.02955. [17] Y. Lu, S. Y. Liang, and K. Morris, “Credibility Consideration for Digital Twins in Manufacturing,” NIST, 2023. doi: 10.6028/NIST.AMS.100-49. [18] ASME, V&V 40-2018: Assessing Credibility of Computational Modeling Through Verification and Validation: Application to Medical Devices, 2018. https://www.asme.org/codes-standards. [19] National Aeronautics and Space Administration, NASA-STD-7009B: Standard for Models and Simulations, 2024. https://standards.nasa.gov/ standard/nasa/nasa-std-7009. [20] J. G. Rivera, A. A. Danylyszyn, C. B. Weinstock, L. Sha, and M. J. Gagliardi, An Architectural Description of the Simplex Architecture, CMU/SEI-96-TR-006, Software Engineering Institute, Carnegie Mellon University, 1996. https://www.sei.cmu.edu/library/an-architecturaldescription-of-the-simplex-architecture/. [21] R. Bloem, B. Könighofer, R. Könighofer, and C. Wang, “Shield Synthesis: Runtime Enforcement for Reactive Systems,” in Tools and Algorithms for the Construction and Analysis of Systems, Springer, 2015, pp. 533–548. doi: 10.1007/978-3-662-46681-0_51. [22] A. Nelson, S. Rekhi, M. Souppaya, and K. Scarfone, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, NIST SP 800-61 Rev. 3, 2025. doi: 10.6028/NIST.SP.800-61r3. [23] National Institute of Standards and Technology, OSCAL: Open Security Controls Assessment Language, 2026. https://pages.nist.gov/OSCAL/. [24] Open Cybersecurity Schema Framework, OCSF Schema, version 1.9.0, 2026. https://github.com/ocsf/ocsf-schema/releases/tag/1.9.0. [25] OASIS Cyber Threat Intelligence Technical Committee, STIX Version 2.1, OASIS Committee Specification 01, 2021. https : / / docs.oasis open.org/cti/stix/v2.1/stix-v2.1.html. [26] OASIS Cyber Threat Intelligence Technical Committee, TAXII Version 2.1, OASIS Committee Specification 01, 2021. https://docs.oasisopen.org/cti/taxii/v2.1/taxii-v2.1.html. [27] OASIS Common Security Advisory Framework Technical Committee, Common Security Advisory Framework Version 2.0, OASIS Standard, 2022. https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html. [28] A. Wright, H. Andrews, B. Hutton, and G. Dennis, JSON Schema: A Media Type for Describing JSON Documents, Draft 2020-12, 2022. https://json-schema.org/draft/2020-12/json-schema-core.html. [29] World Wide Web Consortium, PROV-DM: The PROV Data Model, W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-dm/. [30] K. Kent, S. Chevalier, T. Grance, and H. Dang, Guide to Integrating Forensic Techniques into Incident Response, NIST SP 800-86, 2006. doi: 10.6028/NIST.SP.800-86. [31] Object Management Group, Business Process Model and Notation (BPMN), Version 2.0.2, 2014. https://www.omg.org/spec/BPMN/2.0.2/ PDF/.

20

[32] Assurance Case Working Group, Goal Structuring Notation Community Standard, Version 3, Safety-Critical Systems Club, 2021. https://scsc.uk/ scsc-141B. [33] Object Management Group, Structured Assurance Case Metamodel (SACM), Version 2.0, 2018. https://www.omg.org/spec/SACM/2.0/PDF. [34] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27037:2012, Information technology—Security techniques— Guidelines for identification, collection, acquisition and preservation of digital evidence, 2012. https://www.iso.org/standard/44381.html. [35] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27043:2015, Information technology—Security techniques— Incident investigation principles and processes, 2015. https://www.iso.org/standard/44407.html. [36] T. Zhao, E. Foo, and H. Tian, “A Digital Twin Framework for Cyber Security in Cyber-Physical Systems,” arXiv:2204.13859, 2022. https:// arxiv.org/abs/2204.13859. [37] S. Suhail, S. U. R. Malik, R. Jurdak, R. Hussain, R. Matulevičius, and D. Svetinovic, “Towards Situational Aware Cyber-Physical Systems: A Security-Enhancing Use Case of Blockchain-Based Digital Twins,” Computers in Industry, vol. 141, Art. no. 103699, 2022. doi: 10.1016/j.compind.2022.103699. [38] S. Suhail, M. Iqbal, K. McLaughlin, B. Lee, and B. Imtiaz, “A Framework for Enhancing Cyber Incident Response with Security-Enhancing Digital Twins in Cyber–Physical Systems,” Internet of Things, vol. 31, Art. no. 101547, 2025. doi: 10.1016/j.iot.2025.101547. [39] M. Repetto, “Cybersecurity Digital Twins: Concept, Blueprint, and Challenges for Multi-Ownership Digital Service Chains,” Journal of Information Security and Applications, vol. 96, Art. no. 104299, 2026. doi: 10.1016/j.jisa.2025.104299.

Related documents

• SEAL-DT: An End-to-End Security Engineering and Assurance Framework for Cross-Domain Digital Twins#1341977
• A Posture Transport Protocol over TLS (PT-TLS)#501726
• Information Society Services and Their Cybersecurity#1178871
• Digital Health and Wireless Solutions: Connected Digital Health: Digital Twins, Wearables, Wireless Systems, and Secure Architectures : Second Nordic Conference, NCDHWS 2026, Oulu, Finland, June 16–17, 2026, Proceedings, Part III / edited by Mariella Särestöniemi, Daljeet Singh, Erika Jarva, Jarmo Reponen#1132641
• Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension#501588