ELASTIC D5.1: Specification of the ELASTIC Demonstrators and Validation Plan

Horizon Europe Framework Programme HORIZON JU Research and Innovation Action Reliable Services and Smart Security Efficient, portabLe And Secure orchesTration for reliable servICes D5.1: Specification of the ELASTIC Demonstrators and Validation Plan Abstract: This deliverable elaborates the specification of the ELASTIC demonstrators for validating the developed solutions based on WebAssembly, TEE-enabled Confidential Computing and eBPF with XDP for service orchestration in distributed environments. The validation process is based on the ELASTIC demonstrator use case processes and workflows developed and specified in detail in the document, the specific defined evaluation criteria, and on the extended and enhanced initially defined demonstration KPIs from the project proposal. Finally, the preparatory actions for the validation of the demonstrators, and necessary protocol steps to smoothly execute the validation, are defined in the validation plan. Contractual Date of Delivery 31/08/2025 Actual Date of Delivery 30/09/2025 Deliverable Security Class Public Editor Ana Kovačević, Nenad Gligorić, Vladimir Urošević (ZEN) Contributors ZEN, TUC, ERF, THS, THD, IMEC, UVC, AAL, LUN, AMA, POLITO Internal Reviewers Riccardo Sisto (POLITO) Merlijn Sebrechts (IMEC) ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 2 - August 31, 2025 Document Revisions & Quality Assurance Internal Reviewers 1. Dusan Borovcanin, UVC 2. Merlijn Sebrechts, IMEC Revisions Version Date By Overview 1.2 30/09/2025 TUC Comments and approval from the PC and the STPM 1.1 30/09/2025 TUC Quality check 1.0 29/09/2025 POLITO, IMEC Approval from the IRs 0.9 29/09/2025 ZEN, TUC, ERF, THD, UVC 4th draft 0.8 17/09/2025 POLITO, IMEC, THS Comments on the 3rd draft 0.7 10/09/2025 ZEN, TUC, ERF, THS, THD, IMEC, UVC, AAL, LUN, AMA, POLITO 3rd draft 0.6 28/06/2025 ZEN, UVC, THS, TUC 2nd draft, initial validation protocol and plan, revised document structure and ToC 0.5 06/03/2025 ERF, THD Updates to Demonstrator descriptions 0.4 26/02/2025 THD Demonstrator 2 description version 2 0.3 30/01/2025 ERF Demonstrator 1 description initial outline 0.2 23/01/2025 THD Demonstrator 2 description initial outline 0.1 15/01/2025 ZEN ToC Disclaimer The work described in this document has been conducted within the ELASTIC project. This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101139067. This document does not reflect the opinion of the European Union, and the European Union is not responsible for any use that might be made of the information contained therein. This document contains information that is proprietary to the ELASTIC Consortium partners. Neither this document nor the information contained herein shall be used, duplicated, or communicated by any means to any third party, in whole or in parts, except with prior written consent of the ELASTIC Consortium. The quality of this deliverable was improved with the assistance of digital tools; all content was reviewed and approved by the authors ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 3 - August 31, 2025 Table of Contents List of Tables .......................................................................................................................................... 6 List of Figures ......................................................................................................................................... 7 List of Abbreviations.............................................................................................................................. 8 1 Introduction ................................................................................................................................. 12 1.1 Purpose and Scope of the Document ................................................................................... 12 1.2 Relation to Work Packages, Deliverables and Activities .................................................... 12 1.3 Contribution to WP5 and Project Objectives ...................................................................... 13 1.4 Structure of the Document ................................................................................................... 13 2 Demonstrators Overview and Methodology ............................................................................. 15 2.1 Methodological Approach .................................................................................................... 15 2.2 Demonstrator 1 Overview .................................................................................................... 16 2.3 Demonstrator 2 Overview .................................................................................................... 16 3 Demonstrator 1: An IoT Data Fabric as a Native 6G Infrastructure Capability ................. 17 3.1 Objectives and Context ........................................................................................................ 17 3.1.1 Demonstrator Motivation and Background ..................................................................................................... 17 3.1.1.1 Industrial Context and Strategic Importance ........................................................................................ 17 3.1.1.2 Industrial Challenges Addressed ........................................................................................................... 19 3.1.1.3 Validation Objectives and Strategic Goals ........................................................................................... 21 3.1.2 Background Research ...................................................................................................................................... 23 3.2 Demonstration Use Cases Specification ............................................................................... 24 3.2.1 Scenario 1: Predictive Maintenance ................................................................................................................ 24 3.2.1.1 Problem Statement ................................................................................................................................ 24 3.2.1.2 Solution Approach ................................................................................................................................ 25 3.2.1.3 Operational Flow Overview .................................................................................................................. 25 3.2.1.4 Benefits from ELASTIC Architecture .................................................................................................. 26 3.2.1.5 Key Stakeholders and Roles ................................................................................................................. 26 3.2.1.6 Detailed User Stories ............................................................................................................................ 27 3.2.2 Scenario 2: Cross-Factory Data Sharing.......................................................................................................... 28 3.2.2.1 Problem Statement ................................................................................................................................ 28 3.2.2.2 Solution Approach ................................................................................................................................ 28 3.2.2.3 Operational Flow Overview .................................................................................................................. 28 3.2.2.4 Benefits from ELASTIC Architecture .................................................................................................. 29 3.2.2.5 Key Stakeholders and Roles ................................................................................................................. 29 3.2.2.6 Detailed User Stories ............................................................................................................................ 30 3.2.3 Scenario 3: Real-Time Robot Control ............................................................................................................. 30 3.2.3.1 Problem Statement ................................................................................................................................ 30 3.2.3.2 Solution Approach ................................................................................................................................ 31 3.2.3.3 Operational Flow Overview .................................................................................................................. 31 3.2.3.4 Benefits from ELASTIC Architecture .................................................................................................. 32 3.2.3.5 Key Stakeholders and Roles ................................................................................................................. 32 3.2.3.6 Detailed User Stories ............................................................................................................................ 32 3.3 Requirement Analysis .......................................................................................................... 33 3.3.1 Functional Requirements ................................................................................................................................. 34 3.3.2 Non-Functional Requirements ......................................................................................................................... 35 3.4 Architecture Instantiation & System Components ............................................................. 37 3.5 Technical Workflow and Key Technologies ........................................................................ 47 3.5.1 Scenario 1: Predictive Maintenance ................................................................................................................ 48 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 4 - August 31, 2025 3.5.1.1 Overview ............................................................................................................................................... 48 3.5.1.2 Integration Flow & Technical Architecture .......................................................................................... 48 3.5.1.3 Phase 1: Prerequisites & Security Setup ............................................................................................... 48 3.5.1.4 Phase 2: Application Development & Deployment .............................................................................. 50 3.5.1.5 Phase 3: Secure Data Pipeline ............................................................................................................... 51 3.5.1.6 Phase 4: Comprehensive Observability ................................................................................................ 54 3.5.2 Scenario 2: Cross-Factory Data Sharing.......................................................................................................... 56 3.5.2.1 Overview ............................................................................................................................................... 56 3.5.2.2 Integration Flow & Technical Architecture .......................................................................................... 56 3.5.2.3 Phase 1: Trust Establishment & Policy Setup ....................................................................................... 56 3.5.2.4 Phase 2: Federated Learning Infrastructure .......................................................................................... 57 3.5.2.5 Phase 3: Secure Data Collaboration ...................................................................................................... 59 3.5.3 Scenario 3: Real-Time Robot Control ............................................................................................................. 61 3.5.3.1 Overview ............................................................................................................................................... 61 3.5.3.2 Integration Flow & Technical Architecture .......................................................................................... 61 3.5.3.3 Phase 1: Safety-Critical Control Module Deployment ......................................................................... 61 3.5.3.4 Phase 2: Deterministic Network Infrastructure ..................................................................................... 63 3.5.3.5 Phase 3: Real-Time Control Loop Execution ....................................................................................... 64 3.6 Deployment and Integration ................................................................................................ 66 3.6.1 Hardware and System Infrastructure Requirements ........................................................................................ 66 3.6.2 Software Requirements .................................................................................................................................... 68 3.7 Testbed & Infrastructure Setup .......................................................................................... 69 3.8 Datasets ................................................................................................................................ 71 3.9 Demonstrator 1 – Minimum Viable Product ....................................................................... 72 3.10 Evaluation Strategy .............................................................................................................. 75 3.10.1 KPIs for Demonstrator 1 ............................................................................................................................ 75 3.10.2 Evaluation Criteria and Protocols............................................................................................................... 78 3.10.3 Feedback Collection and Assessment Methodology .................................................................................. 79 3.10.4 Validation Methodology, Timeline and Execution Plan ............................................................................ 80 3.10.4.1 Validation Methodology ....................................................................................................................... 80 3.10.4.2 Timeline ................................................................................................................................................ 80 3.10.4.3 Execution Plan ...................................................................................................................................... 81 4 Demonstrator 2: IT/OT - Privacy-preserving CC Platform to Migrate On-premise Sensitive IT Services to the Cloud ...................................................................................................................... 82 4.1 Objectives and Context ........................................................................................................ 82 4.1.1 Demonstrator Motivation and Background ..................................................................................................... 82 4.1.2 Overall Objectives of the demonstrator ........................................................................................................... 84 4.2 Demonstration Use Case Specification ................................................................................ 87 4.2.1 Summary of the Use Case................................................................................................................................ 87 4.2.1.1 Problem Statement ................................................................................................................................ 88 4.2.1.2 Solution Approach ................................................................................................................................ 88 4.2.1.3 Benefits from ELASTIC’s Architecture and Technologies .................................................................. 88 4.2.2 Scenario Description ........................................................................................................................................ 89 4.2.3 Key Target Users or Stakeholder Groups/Roles .............................................................................................. 90 4.2.3.1 Main Actors in the Use Case................................................................................................................. 90 4.2.3.2 Main System Components involved in the Use Case ........................................................................... 91 4.2.3.3 Main Actors User Stories ...................................................................................................................... 91 4.3 Requirement Analysis .......................................................................................................... 92 4.3.1 Functional Requirements ................................................................................................................................. 93 4.3.2 Non-Functional Requirements ......................................................................................................................... 94 4.4 Architecture Instantiation & System Components ............................................................. 94 4.5 Technical Workflow and Key Technologies ...................................................................... 100 4.6 Deployment and Integration .............................................................................................. 106 4.6.1 Hardware and System Infrastructure Requirements ...................................................................................... 106 4.6.2 Software Requirements .................................................................................................................................. 108 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 5 - August 31, 2025 4.7 Testbed & Infrastructure Setup ........................................................................................ 109 4.7.1 Staging infrastructure..................................................................................................................................... 110 4.7.2 Demonstrator Infrastructure (hosted by THD) .............................................................................................. 111 4.8 Datasets .............................................................................................................................. 112 4.9 Demonstrator 2 – Minimum Viable Product ..................................................................... 114 4.10 Evaluation Strategy ............................................................................................................ 116 4.10.1 KPIs for Demonstrator 2 .......................................................................................................................... 116 4.10.2 Evaluation Criteria and Protocols............................................................................................................. 118 4.10.3 Feedback Collection and Assessment Methodology ................................................................................ 119 4.10.4 Validation Methodology, Timeline and Execution Plan .......................................................................... 119 4.10.4.1 Validation Methodology ..................................................................................................................... 119 4.10.4.2 Timeline .............................................................................................................................................. 120 4.10.4.3 Execution Plan .................................................................................................................................... 122 5 Summary and Next Steps.......................................................................................................... 123 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 6 - August 31, 2025 List of Tables Table 1: Key Stakeholders and Roles in Predictive Maintenance Scenario .......................................... 26 Table 2: User Stories for Predictive Maintenance Scenario .................................................................. 27 Table 3: Key Stakeholders and Roles in Cross-Factory Data Sharing Scenario ................................... 29 Table 4: User Stories for Cross-Factory Data Sharing Scenario............................................................ 30 Table 5: Key Stakeholders and Roles in Real-Time Robot Control Scenario ....................................... 32 Table 6: User Stories for Real-Time Robot Control Scenario ............................................................... 33 Table 7: Functional Requirements for Demonstrator............................................................................. 34 Table 8: Non-Functional Requirements for Demonstrator 1 ................................................................. 36 Table 9: Preliminary Mapping of ELASTIC Components to Demonstrator 1 Scenarios...................... 38 Table 10: Mapping of Demonstrator 1 Challenges to ELASTIC Architecture Components and Rationale ................................................................................................................................................................ 39 Table 11: Hardware Infrastructure Requirements – Demonstrator 1 ..................................................... 66 Table 12: Software Environment Requirements – Demonstrator 1 ....................................................... 68 Table 13: Overview of ELASTIC Components, Their Purpose, and Inclusion in the Demonstrator 1 MVP ....................................................................................................................................................... 74 Table 14: KPIs Derived from the Functional and Non-Functional Requirements of Demonstrator 1 .. 77 Table 15: Timeline and Execution Plan for Demonstrator 1 ................................................................. 80 Table 16: Key Stakeholders and Roles in BRT use case in Demonstrator 2 ......................................... 91 Table 17: Main System Components Supporting the BRT Use Case in Demonstrator 2...................... 91 Table 18: User Stories of Key Stakeholders in the BRT Use Case ....................................................... 92 Table 19: Functional Requirements for Demonstrator 2........................................................................ 93 Table 20: Non-Functional Requirements for Demonstrator 2 ............................................................... 94 Table 21: Key ELASTIC Components Across ELASTIC Architectural Blocks .................................. 96 Table 22: Mapping of Use Case Goals to ELASTIC Components and Their Rationale ....................... 97 Table 23: Functional Overview and Interactions of Key ELASTIC Components ................................ 98 Table 24: Hardware Requirements for Demonstrator 2 Components .................................................. 107 Table 25: Software Requirements for Demonstrator 2 Components ................................................... 108 Table 26: Overview of ELASTIC Components, Their Purpose, and Inclusion in the Demonstrator 2 MVP ..................................................................................................................................................... 115 Table 27: KPIs Derived from the Functional and Non-Functional Requirements of Demonstrator 2 117 Table 28: Timeline and Execution Plan for Demonstrator 2 ............................................................... 120 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 7 - August 31, 2025 List of Figures Figure 1. In-network Application Data Fabric ....................................................................................... 24 Figure 2. Instantiated ELASTIC Architecture for Demonstrator 1........................................................ 38 Figure 3. Integration Flow & Technical Architecture - Scenario 1 | Demonstrator 1 ........................... 48 Figure 4. Prerequisites & Security Setup - Scenario 1 | Demonstrator 1 ............................................... 49 Figure 5. Application Development & Deployment - Scenario 1 | Demonstrator 1 .............................. 50 Figure 6. Secure Data Pipeline - Scenario 1 | Demonstrator 1............................................................... 52 Figure 7. Comprehensive Observability - Scenario 1 | Demonstrator 1 ................................................ 54 Figure 8. Integration Flow & Technical Architecture - Scenario 2 | Demonstrator 1 ........................... 56 Figure 9. Trust Establishment & Policy Setup - Scenario 2 | Demonstrator 1....................................... 56 Figure 10. Federated Learning Infrastructure - Scenario 2 | Demonstrator 1 ........................................ 58 Figure 11. Secure Data Collaboration - Scenario 2 | Demonstrator ....................................................... 60 Figure 12. Integration Flow & Technical Architecture – Scenario 3 | Demonstrator 1 ......................... 61 Figure 13. Safety-Critical Control Module Deployment – Scenario 3 | Demonstrator 1 ...................... 62 Figure 14. Deterministic Network Infrastructure – Scenario 3 | Demonstrator 1 .................................. 63 Figure 15. Real-Time Control Loop Execution – Scenario 3 | Demonstrator 1 .................................... 65 Figure 16. ELASTIC architecture highlighting components used in the MVP for Scenario 1 of Demonstrator 1 ....................................................................................................................................... 73 Figure 17. Execution flow diagram for Scenario 1 of Demonstrator 1 .................................................. 74 Figure 18. Instantiated ELASTIC Architecture for Demonstrator 2...................................................... 96 Figure 19. BRT 3-tier architecture as deployed today on-premise ...................................................... 101 Figure 20. BRT 3-tier architecture using Wasm runtime on-premise .................................................. 101 Figure 21. BRT 3-tier architecture using ELASTIC stack on-premise ................................................ 102 Figure 22. BRT 3-tier architecture using ELASTIC stack on-premise with integrated edge-based AIIDS nodes ............................................................................................................................................. 103 Figure 23. Diagram of the migration phase of the BRT application .................................................... 105 Figure 24. BRT 3-tier architecture using ELASTIC stack deployed in Public Cloud ......................... 105 Figure 25. BRT 3-tier architecture using ELASTIC stack on-premise with integrated cloud-based AIIDS solution ......................................................................................................................................... 106 Figure 26. Database structure of BRT application ............................................................................... 113 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 8 - August 31, 2025 List of Abbreviations 6GSNS 6G Smart Networks and Services ABAC Attribute-Based Access Control AI Artificial Intelligence AI-IDS AI-based Intrusion Detection System AMD Advanced Micro Devices API Application Programming Interface ARM Advanced RISC Machine AS Autonomous System AWS Amazon Web Services BRT Badge Request Tool CBAC Capability-Based Access Control CBOR Concise Binary Object Representation CC Confidential Computing CNC Computer Numerical Control CoAP Constrained Application Protocol CSP Cloud Service Provider CPU Central Processing Units CVE Common Vulnerabilities and Exposures CVM Confidential VM D Deliverable DB Database DoA Description of Actions DPI Deep Packet Inspection eBPF extended Berkeley Packet Filtering ER DC Ericsson Research Data Center EU European Union FL Federated Learning FPGA Field Programmable Gate Array FR Functional Requirement GA Grant Agreement GCP Google Cloud Platform GDPR General Data Protection Regulation GPIO General-Purpose Input/Output ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 9 - August 31, 2025 GPU Graphics Processing Unit IETF Internet Engineering Task Force HAL Hardware Abstraction Layer HSM Hardware Security Module IT Information Technology JSON JavaScript Object Notation (format) KBS Key Broker Service KMS Key Management System KPI Key Performance Indicator ML Machine Learning MQTT Message Queuing Telemetry Transport MVP Minimum Viable Product NFRs Non-Functional Requirements OCI Open Container Initiative OEE Overall Equipment Effectiveness OS Operating System OT Operational Technology OTA Over-the-Air OVMF Open Virtual Machine Firmware RAP Remote Attestation Platform RATS Remote ATtestation ProcedureS RBAC Role-Based Access Control RDMA Remote Direct Memory Access RTOS Real-Time Operating System SDK Software Development Kit SDV Software-Defined Networking SEV Secure Encrypted Virtualisation SGX Software Guard Extensions SMA Software Management Agent SNP Secure Nested Paging SSLA Security Service Level Agreement SQL Structured Query Language TCB Trusted Compute Base TDX Trust Domain Extensions ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 16 - August 31, 2025 2.2 Demonstrator 1 Overview Demonstrator 1 aims to validate the ELASTIC framework within the Smart Manufacturing use case by enabling users to build processing pipelines that deploy portable modules (e.g., Wasm/eBPF) across heterogeneous nodes. It focuses on discovering computation-capable devices, verifying their secure runtimes and attestation status, managing a library of portable functions, and ensuring user-friendly pipeline construction. An orchestrator will translate user designs into workflow instructions, validate them against defined policies, and deploy processing units accordingly. Additionally, the demonstrator will explore data-processing optimisations based on observed node metrics, offering actionable recommendations to users. The validation of Demonstrator 1 is based on three scenarios: 1. The Predictive Maintenance scenario applies ELASTIC’s edge computing to minimise unplanned downtime by analysing machine sensor data locally with WebAssembly and TEEs. This approach ensures data sovereignty, enables early fault detection, and improves safety and efficiency in manufacturing. 2. The Cross-Factory Data Sharing scenario leverages ELASTIC’s federated learning and access control to let manufacturing sites of the same company securely share insights, benchmark performance, and coordinate decisions without compromising data sovereignty. 3. The Real-Time Robot Control scenario applies ELASTIC’s eBPF network optimisations, secure WebAssembly runtimes, and formal verification to ensure safe, low-latency, and deterministic robot operations. 2.3 Demonstrator 2 Overview Demonstrator 2 validates the ELASTIC framework for cloud migration of IT services, focusing on secure transfer of sensitive workloads from private data centers while complying with company internal security policies, security compliance framework (ISO/IEC 27001) and privacy regulation (GDPR). It evaluates confidential computing platforms (e.g., Intel TDX, AMD SEV) other with attestation mechanisms for portability, automation, and ease of deployment, ensuring efficient, secure, and low-latency orchestration across cloud, edge, and far-edge networks. Demonstrator 2 will be validated by demonstrating a secure migration of the BRT, a legacy application that manages the complete lifecycle of employee security badges, from a controlled on-premise environment to a public cloud infrastructure under the same IT organisation. While currently hosted in Thales’ private cloud due to strict security requirements, BRT has been identified as an early candidate for cloud migration as part of the organisation’s digital transformation. Remote attestation will be used to demonstrate data-in-use protection, while Wasm will serve as a runtime that decouples application logic from specific hardware. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 17 - August 31, 2025 3 Demonstrator 1: An IoT Data Fabric as a Native 6G Infrastructure Capability Ericsson (ERF) participates in ELASTIC to advance its vision for programmable, secure, and trusted 6G infrastructures. The project provides Ericsson with the opportunity to explore early prototyping of secure orchestration and in-network computing mechanisms that align with evolving mobile core architectures. By validating novel concepts such as Wasm-based secure service offloading and trusted enclaves, in interoperable, distributed testbeds, ELASTIC enables Ericsson to gain valuable insights that inform long-term platform evolution. Building on this strategic perspective, this section is dedicated to Demonstrator 1, which presents the IoT Data Fabric as a native 6G infrastructure capability. Its objective is to showcase how the technologies developed within the ELASTIC project can be applied in industrial environments to enable secure, portable, and intelligent orchestration of data and processes across the edge-to-cloud continuum. The section is divided into ten subsections. In 3.1, the objectives and context are presented, including the research background and motivation behind the demonstrator. 3.2 specifies the use cases through three scenarios - predictive maintenance, cross-factory data sharing, and real-time robot control - that illustrate different aspects of ELASTIC technology applications. 3.3 provides the requirements analysis, covering both functional and non-functional requirements necessary for successful realisation. Subsection 3.4 introduces the instantiated architecture and system components, while 3.5 describes the technical workflows and key technologies with particular emphasis on the three defined scenarios. The following parts, 3.6 and 3.7, address deployment and integration, hardware and software requirements, and the testbed infrastructure needed for the demonstrator. In 3.8, the datasets used for validation are presented. 3.9 defines the Minimum Viable Product (MVP) of Demonstrator 1 and its role in the validation process. Finally, 3.10 provides an overview of the KPIs, evaluation parameters, and validation plan, together with the methodology and protocols for assessing the demonstrator’s success. In this way, Section 3 delivers a comprehensive specification of Demonstrator 1, from strategic context and industrial use cases, through architecture and technical realisation, to the evaluation and validation of results. 3.1 Objectives and Context This section introduces the foundational rationale behind the ELASTIC Demonstrator 1, detailing the strategic significance of IT/OT convergence, the challenges posed by industrial IoT environments, and the transformative impact of ELASTIC’s technological enablers. It sets the stage for a comprehensive understanding of the demonstrator’s ambition to revolutionise manufacturing processes through a secure, portable, and intelligent orchestration of edge-tocloud services. 3.1.1 Demonstrator Motivation and Background 3.1.1.1 Industrial Context and Strategic Importance The manufacturing industry is undergoing a fundamental transformation driven by the convergence of Information Technology (IT) and Operational Technology (OT), the emergence of Industry 4.0 paradigms, and the promise of 6G-enabled smart factories. This evolution goes beyond technological advancement - it represents a critical strategic shift required to remain competitive in a rapidly digitising and interconnected global industrial landscape. The success ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 18 - August 31, 2025 of this transition relies on the adoption and integration of several foundational technologies that support secure, scalable, and intelligent industrial operations. Why IoT Data Fabric is Critical Now: Modern manufacturing faces unprecedented challenges that traditional approaches cannot address. An IoT Data Fabric - a unified, intelligent layer for collecting, integrating, and processing data across distributed environments - has become essential to support this shift. Manufacturing facilities generate large volumes of operational data daily from numerous sensors, yet a significant portion remains unused due to integration complexity. In 2022, global IoT generated ≈ 86 PB of data—with projections to exceed 1,100 PB by 2027. Many organisations process only a fraction of that flow due to ingestion and transformation limitations 2 . Competitive advantage increasingly depends on rapid responses to operational changes. Real-time edge processing can reduce overall latency significantly compared to cloudcentered systems. Industrial edge models have been shown to process local sensor-generating hotspots with tens to low hundreds of ms latency—providing marked improvements over centralised architectures. In distributed control contexts, manufacturing-grade decision pipelines often require sub-200 ms responsiveness for effective closed-loop operations 3 . These data-centric challenges have been historically difficult to address due to fundamental limitations in computing architectures, network capabilities, and security frameworks. Legacy systems were not designed to support real-time analytics, distributed data flows, or strong isolation guarantees - all of which are now critical requirements for modern industrial operations. However, the convergence of several breakthrough technologies is enabling the design of comprehensive and secure solutions capable of addressing these constraints. The ELASTIC framework uniquely addresses these opportunities by providing technical enablers that, when used in solutions such as IoT Data Fabric, have the potential to significantly improve the security, portability, and performance of the solution: • TEE: Secure area within a processor that protects sensitive data and code. • WebAssembly: Portable binary instruction format for secure, high-performance execution. • WASI: System interface for WebAssembly that provides secure access to system resources. A system interface for WebAssembly that allows Wasm modules to run as standalone applications outside the browser. By securely abstracting system resources (e.g., files, sockets, clocks), WASI enables consistent execution across heterogeneous edge and cloud environments. It is a key enabler of the Wasm “standalone shift,” supporting ELASTIC’s goal of secure, portable execution decoupled from underlying hardware. • eBPF: Technology for running programs in the Linux kernel without changing kernel source code. • Access Control: Security mechanisms that regulate system access, including RoleBased (RBAC), Attribute-Based (ABAC), and Capability-Based (CBAC) approaches. • Federated Learning: Collaborative intelligence without exposing sensitive competitive data. 2 How modern enterprises are using IoT data to spur innovation https://www.ibm.com/think/insights/how-modern-enterprises-are-using-iot-data-to-spur-innovation 3 Weimin Liu, et al, Research on the optimization of IIoT data processing latency, Computer Communications Volume 151, 1 February 2020, Pages 290-298 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 19 - August 31, 2025 3.1.1.2 Industrial Challenges Addressed As the manufacturing sector advances toward digital transformation, several structural and operational barriers continue to hinder the full realisation of Industry 4.0 and beyond. The integration of heterogeneous systems, increased interconnectivity, and elevated performance demands reveal deep-rooted challenges that must be addressed to unlock the potential of smart, secure, and scalable industrial operations. This subsection outlines the primary technical and organisational obstacles that modern industrial environments face - from fragmented data landscapes and cybersecurity vulnerabilities to strict performance and compliance requirements. Data Integration and Interoperability Crisis: Industrial networks present significant data integration challenges. Legacy systems with proprietary interfaces require integration with modern IIoT deployments. Key integration requirements include: • Protocol Diversity: MQTT, CoAP, OPC-UA, Modbus, and proprietary protocols coexist in single facilities. • Data Format Heterogeneity: JSON, CBOR, binary formats, and legacy data structures require complex transformation pipelines. • Semantic Gaps: Equipment from different vendors uses incompatible data models and terminology. These integration challenges result in data silos that prevent comprehensive operational intelligence and limit the effectiveness of advanced analytics. Security and Compliance in Connected Manufacturing: The convergence of IT and OT creates unprecedented security challenges: • Expanded Attack Surface: Every connected device becomes a potential entry point for cyber threats. • Legacy System Vulnerabilities: Older OT systems lack modern security features and cannot be easily updated. • Regulatory Compliance: GDPR, industry-specific regulations, and emerging cybersecurity frameworks require comprehensive data protection. • Data Sovereignty: Multinational manufacturers must comply with varying data residency and processing requirements. • Intellectual Property Protection: Manufacturing processes and operational data represent critical competitive advantages that must be protected. Performance and Reliability Requirements: Industrial applications demand performance characteristics that traditional cloud and IT architectures cannot reliably provide: • Deterministic Latency: Robot control and safety systems require guaranteed response times for safe operation. • High Availability: Manufacturing downtime represents significant operational costs across different industries. • Scalability: Facilities may have numerous connected devices with varying computational and communication requirements. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 20 - August 31, 2025 Opportunities for Network Operators Beyond addressing developer and manufacturing challenges, the transition from 5G to 6G also introduces strategic opportunities for network operators. In current 5G deployments, operators are largely positioned as connectivity providers, limiting their ability to capture value beyond transport services. With 6G, operators can productise their infrastructure as a service platform, offering developers and enterprises cloud-like experiences directly on top of the network. By embedding capabilities such as secure edge execution, real-time orchestration, and intelligent data handling, operators can shift from a communication-centric role to a service-centric role, monetizing their infrastructure investments more effectively. This evolution not only improves developer adoption but also creates sustainable business models that reinforce the competitiveness of European operators in global markets. Demonstrator strategic alignment The demonstrator contributes directly to several high-level strategic priorities set by the European Union, particularly those outlined in the Digital Decade policy programme, the European Industrial Strategy, and the EU Cybersecurity Strategy 4 . By addressing critical challenges in secure data handling, edge-to-cloud orchestration, and operational autonomy, the demonstrator supports Europe's ambition to lead in the development of trusted, resilient, and digitally sovereign industrial ecosystems. The demonstrator reinforces Europe’s objective to achieve greater control over digital infrastructure and industrial data flows: • Reduces dependence on proprietary cloud platforms through open, portable technologies. • Enables European manufacturers to maintain control over critical operational data. • Supports the development of European technology standards and capabilities. • Maintains European leadership in advanced manufacturing technologies. • Enables small and medium enterprises to access advanced capabilities previously available only to large corporations. • Supports the development of new business models and service offerings. • Demonstrates practical implementation of zero-trust security principles in industrial environments. • Provides frameworks for protecting critical infrastructure from cyber threats. • Supports compliance with the EU Cybersecurity Act 5 and NIS2 Directive 6 . To achieve these objectives, the demonstrator leverages WebAssembly as a lightweight, platform-neutral runtime environment particularly well suited for industrial applications requiring deterministic performance, high availability, and horizontal scalability. Its low overhead and near-native execution speeds enable latency-sensitive functions, such as closedloop robot control, to be deployed directly at the edge. Unlike traditional VM-based solutions, 4 The Digital Decade policy programme is the EU’s strategic roadmap for digital transformation up to 2030, jointly endorsed by the European Commission, Parliament and Council, available online 5 Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on ENISA, the EU Cybersecurity Agency, and on information and communications technology cybersecurity certification, Official Journal of the European Union, vol. L 151, pp. 15–69, Jun. 7, 2019. [Online]. Available: https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A32019R0881. Accessed: Jul. 21, 2025. 6 Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Directive (EU) 2016/1148, Official Journal of the European Union, vol. L 395, pp. 1–89, Dec. 27, 2022. [Online]. Available: https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A32022L2555. Accessed: Jul. 21, 2025. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 21 - August 31, 2025 Wasm runtimes can be embedded in constrained devices or deployed within TEEs, ensuring both real-time responsiveness and data confidentiality. Furthermore, Wasm’s modularity and portability reduce operational downtime by simplifying deployment, upgrade, and rollback procedures, thus contributing to system availability targets of 99.99% or greater. In large-scale factory environments, Wasm's compact binary format and resource-efficient design allow orchestration of hundreds to thousands of parallel workloads across heterogeneous nodes, facilitating elastic workload distribution across edge–fog–cloud hierarchies. Collectively, these properties position Wasm as a critical enabler for meeting the stringent performance, reliability, and scalability requirements of Industry 4.0. 3.1.1.3 Validation Objectives and Strategic Goals Primary Strategic Goal: The demonstrator aims to create a semi-virtualised experimentation platform that enables realistic validation of Industry 4.0 scenarios by integrating hardware and software components, sensors, actuators, and powerful servers running control processes. The experimentation platform addresses challenges related to hyper-scale IoT data processing within a future 6G network, targeting discrete and process manufacturing contexts where real-time, low-latency control, predictive maintenance, and quality control are critical. The primary strategic goal of this demonstrator is to validate ELASTIC’s vision of secure, portable, and efficient orchestration of services across heterogeneous industrial infrastructures. It addresses the critical gap between traditional manufacturing systems and the requirements of next-generation smart factories by demonstrating practical solutions to real-world industrial challenges. Specific Validation Objectives: • Technology Integration: Prove that ELASTIC components can work together seamlessly in realistic industrial scenarios. • Performance Validation: Demonstrate that ELASTIC components help to address some of the stringent industrial performance requirements. • Security Assurance: Validate security mechanisms in realistic threat environments. • Scalability Proof: Show that the approach scales from pilot deployments to enterprisewide implementations. • Business Value: Quantify operational improvements and cost reductions achievable through ELASTIC technologies. ELASTIC Technology Integration: The IoT Data Fabric benefits from ELASTIC outcomes (WP1–WP4 components) in multiple ways: • FaaS Orchestration: Dynamic and scalable orchestration with lower operational expenses compared to traditional always-running service architectures. • WebAssembly Portability: Helps with portability across different infrastructures while isolation guarantees are met through Wasm sandboxing capabilities. • eBPF Observability: Improved observability at the network layer through real-time monitoring and performance optimisation. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 22 - August 31, 2025 • Policy Enforcement: Simplified abstractions in the form of policies and intents, with ELASTIC system handling enforcement of various access control lists and security rules. • Trusted Execution: TEE-based confidential computing ensures secure processing of sensitive operational data. Benefits for Ericsson Factories and Industrial Users: • Cost Reduction: Savings through reduced data transfer to cloud and optimised device battery usage. • Enhanced Security: Strong channel and data security with secure execution environments for processing tasks. • Operational Efficiency: Isolated processing in multi-tenant cases with policy enforcement based on data type and sovereignty requirements. • Simplified Development: Low-code platforms and mechanisms making technology accessible to non-programmers. • Advanced Capabilities: Applications automatically taking advantage of advanced network capabilities. Benefits for Network Operators: • Service Monetisation: Ability to productise network infrastructure by offering secure edge and data services similar to cloud providers. • Developer Adoption: Providing cloud-like developer experiences directly on 6G networks encourages broader use of operator platforms. • Value Shift: Enables operators to evolve from pure connectivity providers to servicecentric players, unlocking new revenue streams. Use Case Selection Methodology: The use cases for this demonstrator were selected based on a comprehensive analysis of realworld industrial requirements and future technology trends. This approach ensures that the demonstrator not only addresses immediate operational challenges faced by industry but also aligns with evolving standards and visions for smart manufacturing. Importantly, Ericsson’s role in this process is two-fold: as a factory operator, leveraging its Smart Factory operations to validate requirements from an end-user perspective, and as a network technology provider, ensuring that the demonstrator aligns with operator needs for productising infrastructure and services. The methodology integrates insights from three key sources: 1. Ericsson Smart Factory Requirements: Analysis of Ericsson’s next-generation supply chain challenges and manufacturing digitalisation needs, including operational technology integration and smart factory transformation requirements 7 , 8 . This included an in-depth assessment of OT integration challenges and the specific needs arising from the transition towards smart factories. Key factors considered were the interoperability of heterogeneous systems, real-time data acquisition and processing demands, and the need for enhanced automation and predictive capabilities. This analysis helped identify 7 Ericsson, "Next-generation supply chain," Ericsson, [Online]. Available: https://www.ericsson.com/en/about-us/companyfacts/next-generation-supply-chain. [Accessed: Jul. 21, 2025]. 8 Ericsson, "Manufacturing," Ericsson, [Online]. Available: https://www.ericsson.com/en/industries/manufacturing. [Accessed: Jul. 21, 2025]. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 23 - August 31, 2025 critical pain points in current manufacturing processes and framed requirements for future-proof solutions capable of supporting seamless digital transformation. 2. 5G-ACIA Manufacturing Standards: The demonstrator’s use cases were aligned with the standards and whitepapers produced by the 5G Alliance for Connected Industries and Automation (5G-ACIA) 9 . These documents provide authoritative guidance on essential 5G-enabled industrial manufacturing use cases, including stringent performance benchmarks for industrial IoT applications, network slicing for dedicated factory network resources, and edge computing requirements tailored to manufacturing environments. By mapping these standards to real-world requirements and user stories, the selection process ensured that the demonstrator supports industry-recognised best practices and future-ready network architectures. 3. HEXA-X II 6G Vision: Future connectivity requirements for smart manufacturing, human-centric industrial applications, and sustainability-focused manufacturing scenarios that will define next-generation factory operations 10 . Looking beyond current 5G capabilities, the HEXA-X II project’s 6G vision was integrated into the use case analysis. This forward-looking perspective identifies emerging connectivity requirements critical for the evolution of smart manufacturing, emphasising humancentric industrial applications, ultra-low latency communications, enhanced security, and sustainability-driven production processes. The 6G vision highlights how future network technologies can support increasingly autonomous, adaptive, and energyefficient factory operations, aligning perfectly with ELASTIC’s goals for nextgeneration industrial infrastructures. The selected scenarios (predictive maintenance, cross-factory data sharing, and real-time robot control) represent the intersection of these requirements, providing comprehensive coverage of industrial IoT challenges while showcasing ELASTIC’s unique capabilities in edge computing, security, and distributed orchestration. The next section (3.2) further elaborates these scenarios, defining their scope and detailing how they will be implemented within Demonstrator 1. In parallel with these industry-driven requirements, Ericsson Research Finland has been developing architectural concepts to address recurring data-integration challenges. This prior research provides valuable insights and foundations for the ELASTIC demonstrator, as outlined in the following subsection 3.1.2 Background Research Ericsson Research Finland (ERF) has been investigating network-based architectures and technologies to simplify common and recurring data-integration challenges, and conceptualised a broad generic framework called In-network Application Data Fabric as depicted in the diagram below (Figure 1). 9 5G‑ACIA, Key 5G Use Cases and Requirements, White Paper, 5G Alliance for Connected Industries and Automation. [Online]. Available: https://5g-acia.org/whitepapers/key-5g-use-cases-and-requirements/ [Accessed: Jul. 28, 2025]. 10 Hexa-X II Consortium, “Hexa-X-II D1.2: Overall 6G system view and use cases – Slide Set,” Hexa-X II, Jan. 2024. [Online]. Available: https://hexa-x-ii.eu/wp-content/uploads/2024/01/Hexa-X-II-D1.2_slideSet.pdf. [Accessed: Jul. 21, 2025] ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 24 - August 31, 2025 Figure 1. In-network Application Data Fabric The In-network Application Data Fabric enables a data-oriented approach towards Enterprise applications. On the “southbound”, it interfaces with mobile and enterprise networks and is deployed on the same distributed infrastructure as the network infrastructure. East-west interactions include interfaces with Device Integration and Management systems and Enterprise IT/OT systems, treating these systems not only as data sources and sinks, but also as ways to discover and learn about the application needs and requirements. With these southbound and east-west interfaces in place, the Data Fabric would have the necessary context to make decisions (e.g., transferring and operating on data) in an intelligent and optimised manner. Hence, some of the complexity of applications that need to use the data and network capabilities can be offloaded to the Data Fabric. This not only makes application development and integration easier, but also provides opportunities to develop low-code platforms and mechanisms to make the technology more accessible to non-programmers and enables applications automatically taking advantage of advanced network capabilities. 3.2 Demonstration Use Cases Specification The ELASTIC Demonstrator 1 focuses on a single use case: “An IoT Data Fabric as a Native 6G Infrastructure Capability.” This use case envisions a future-proof, secure, and flexible IoT data infrastructure that can support industrial applications across cloud, edge, and in-network computing layers. It leverages the programmability, observability, and orchestration capabilities of 6G-native infrastructures to enable scalable, policy-compliant, and latencyaware data-driven operations. To operationalise and validate this use case, three complementary demonstration scenarios have been defined. Each scenario leverages different combinations of ELASTIC technologies while maintaining consistent security, orchestration, and observability principles across the entire Demonstrator-1 realisation. 3.2.1 Scenario 1: Predictive Maintenance 3.2.1.1 Problem Statement Traditional manufacturing environments face significant challenges with unplanned equipment downtime, which represents a considerable portion of production losses in industrial facilities. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 25 - August 31, 2025 Reactive maintenance approaches create multiple problems: • Costly production interruptions • Suboptimal resource utilisation • Safety risks from unexpected equipment failures • Difficulty maintaining data sovereignty while enabling advanced analytics 3.2.1.2 Solution Approach The predictive maintenance use case focuses on ELASTIC’s edge computing capabilities to enable secure, near real-time analysis of machine sensor data while maintaining data sovereignty. The solution processes equipment health indicators locally through WebAssembly-based functions and TEEs, allowing maintenance teams to identify potential failures before they occur without exposing sensitive operational data. 3.2.1.3 Operational Flow Overview This section outlines the comprehensive Predictive Maintenance business process enabled by the ELASTIC architecture. It highlights the interactions between key stakeholders and the sequential flow of activities from continuous equipment monitoring to maintenance scheduling and performance tracking. Business Process: The end-to-end predictive maintenance process involves four key stakeholders: 1. Equipment Monitoring: Manufacturing equipment with integrated sensors continuously collects health data (vibration, temperature, pressure, electrical parameters). 2. Data Analysis: Edge processing systems analyse sensor data locally to identify potential equipment failure patterns while maintaining data sovereignty. 3. Alert Generation: System generates maintenance alerts when failure probability exceeds configured thresholds, providing advance notice to maintenance engineers. 4. Maintenance Scheduling: Maintenance engineers receive predictive alerts and coordinate with plant operators to schedule preventive maintenance during planned downtime windows. Key Business Outcomes: • High prediction accuracy with advance notice for maintenance planning • Significant reduction in unplanned downtime • Extended equipment lifespan through optimised maintenance • Reduced maintenance costs through predictive approaches Data Sovereignty Assurance: • All sensitive equipment data processed locally within factory premises. • No operational data transmitted to external systems. • Secure processing environments protect competitive information. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 32 - August 31, 2025 3.2.3.4 Benefits from ELASTIC Architecture The Real-Time Robot Control scenario capitalises on key features of the ELASTIC architecture to deliver deterministic, secure, and resilient robotic operations in industrial environments: • Deterministic Latency: Kernel-bypass networking eliminates traditional network stack overhead for robot control communications. • Distributed State Sync: eBPF-based synchronisation maintains consistent robot state across control components. • Secure Runtime: WASI security adaptations provide fine-grained control over WebAssembly module permissions. • Static security analysis: Static analysis ensures safe interactions between safety-critical control modules. • Live Migration: Reliable enclave protocols enable seamless control application migration between edge nodes. 3.2.3.5 Key Stakeholders and Roles This scenario involves a set of specialised roles responsible for ensuring the safety, precision, and reliability of real-time robotic operations. Table 5 below outlines the key stakeholders, their responsibilities, system interactions, and success criteria within the ELASTIC-enabled robot control environment. Table 5: Key Stakeholders and Roles in Real-Time Robot Control Scenario Stakeholder Primary Responsibilities System Interactions Success Criteria Robotics Engineer Develop robot control algorithms, optimise control loop performance, validate system safety Deploys WebAssembly control modules, configures WASI capabilities, monitors control loop timing Achieve deterministic control loop response times with consistent timing guarantees. Security Specialist Configure security policies, validate safety-critical interactions, ensure compliance with robotics safety standards Defines WASI security constraints, reviews static analysis reports, monitors safety system status Zero unauthorised hardware access attempts and 100% validation of safety-critical module interactions Control Systems Specialist Optimise network performance, manage distributed state synchronisation, coordinate system migration Configures kernel-bypass networking, manages eBPF state sync, orchestrates live migration procedures Maintain deterministic control timing and seamless migration capabilities 3.2.3.6 Detailed User Stories The following table (Table 6) maps detailed user stories to the key stakeholders involved in the real-time robot control scenario. These user stories capture specific needs and objectives that align with the roles and responsibilities defined in the previous subsection. This structured mapping ensures clear traceability from stakeholder requirements to system functionalities, facilitating focused development and validation efforts for the ELASTIC architecture’s robotic control use case. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 33 - August 31, 2025 Table 6: User Stories for Real-Time Robot Control Scenario ID Role User Story US-RC-01 Robotics Engineer As a Robotics Engineer, I need to deploy robot control functions as WebAssembly modules with deterministic response times, so that I can achieve precise robot movements while maintaining security through WASI capability restrictions US-RC-02 Security Specialist As a Safety Officer, I need to configure WASI security policies that restrict robot control modules to only necessary hardware access permissions, so that I can prevent unauthorised or unsafe robot operations while ensuring compliance with safety standards. US-RC-03 Control Systems Specialist As a Control Systems Specialist, I need kernel-bypass networking between robot control services with guaranteed timing, so that I can maintain consistent control loop performance regardless of system load. US-RC-04 Robotics Engineer As a Robotics Engineer, I need static analysis validation of interactions between safety-critical control modules, so that I can ensure safe robot operations before deploying control logic to production systems. US-RC-05 Robotics Engineer As a Robotics Engineer, I need WebAssembly hardware abstraction layers for robot sensors and actuators, so that I can develop portable control functions across different robot platforms. The three scenarios together demonstrate how the IoT Data Fabric concept can be operationalised across different industrial contexts. Having defined the use cases, the next section (3.3) focuses on the requirements analysis, specifying the functional and non-functional conditions that must be met for successful implementation of Demonstrator 1. 3.3 Requirement Analysis To ensure that the ELASTIC architecture meets the needs of its intended use case - An IoT Data Fabric as a Native 6G Infrastructure Capability - a thorough requirements analysis has been conducted. This analysis is grounded in the technical and operational demands of the three demonstration scenarios, which collectively represent a wide spectrum of industrial IoT challenges. This section is structured into Functional Requirements and Non-Functional Requirements, each of which has been prioritised using a MUST/SHOULD/MAY classification scheme to indicate the criticality of the feature or quality attribute 11 . • MUST: mandatory and critical to system viability • SHOULD: recommended and valuable but not essential • MAY: optional features that add flexibility or enhancements All requirements are identified by a unique Requirement ID and, where applicable, are linked to one or more of the three defined scenarios. The objective of this requirements analysis is to define the capabilities and constraints that the system must satisfy in order to provide secure, efficient, and interoperable IoT data services 11 S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, IETF, Mar. 1997. [Online]. Available: https://www.rfc-editor.org/rfc/rfc2119. [Accessed: Jul. 26, 2025]. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 34 - August 31, 2025 across edge-to-cloud infrastructures. The analysis draws from contributions across several technical work packages (WP1 - WP4), as well as the demonstrator definition activities in WP5. 3.3.1 Functional Requirements Functional requirements define the specific capabilities, behaviours, and services that the ELASTIC system must provide to fulfil the objectives of the demonstrator use case and its three related scenarios. These requirements reflect what the system shall do, ensuring that all necessary features are in place to enable secure, efficient, and scalable operation across distributed industrial environments. They span all layers of the ELASTIC architecture, from low-level device integration and data acquisition, to in-network function orchestration, portable execution environments, secure data handling, and intelligent policy enforcement. All functional requirements are presented in Table 7, categorised by domain (e.g., Data Handling, Security). Each entry includes a Requirement ID (Req. ID), a Description, its assigned Priority Level, the Related Scenario(s), and the Source identifying the ELASTIC component(s) or framework(s) that fulfil the requirement. Table 7: Functional Requirements for Demonstrator Req. ID Description Level Related Scenario Source Data Handling & Integration D1-FR1 The system shall ingest data from heterogeneous IoT devices using multiple protocols (e.g., MQTT, CoAP) to ensure compatibility with diverse industrial equipment and network environments MUST All Scenarios Data Fabric, Propeller orchestrator D1-FR2 The system shall support multiple data serialisation formats (e.g., JSON, CBOR) to facilitate smooth processing regardless of device-specific data formats SHOULD All Scenarios Data Fabric D1-FR3 The system shall normalise and enrich incoming data with metadata (e.g., timestamps, device identity) to enhance data quality and traceability for downstream applications SHOULD Scenario 1, 2 Data Fabric Processing & Orchestration D1-FR4 The system shall support deployment and orchestration of in-network FaaS functions for realtime data processing, enabling dynamic management close to data sources MUST Scenario 1 Propeller orchestrator, Wasm-operator D1-FR5 The system shall support Wasm-based portable functions to run at edge and in-network locations, ensuring consistent execution across heterogeneous hardware platforms MUST Scenario 1 Propeller orchestrator, Wasm-operator D1-FR6 The system shall enable WebAssembly hardware abstraction through standardised interfaces for sensor integration (e.g., I2C, USB) in factory environments SHOULD Scenario 1 WasmHAL hardware/ interfaces/ runtime extensions Security & Access Control D1-FR7 The system shall allow sensitive data to be processed locally on edge devices to minimise exposure and improve response times for critical operations MUST Scenario 1 Data Fabric, Propeller orchestrator ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 35 - August 31, 2025 D1-FR8 The system shall support secure communication channels between devices, gateways, and cloud components using encryption and authentication mechanisms MUST Scenario 2 Data protection at-rest at the edge with TEE solution + Hardware-based cryptography module D1-FR8a The system shall implement WASI security adaptations to restrict WebAssembly modules to only necessary hardware access permissions SHOULD Scenario 3 WASI Security, WASI flexibly-defined capabilities D1-FR9 The system shall implement attribute-based access control (ABAC) for fine-grained policy enforcement MUST Scenario 2 Light-weight ABAC solution Observability & Policy Enforcement D1-FR10 The system shall support eBPF-based observability to monitor data flows and system behaviour in near real-time with low overhead SHOULD Scenario 1, 3 Observability framework for serverless workloads, NETTO D1-FR11 The system shall enforce configurable policies (e.g., data retention, filtering, anonymisation) during data processing and transfer SHOULD Scenario 1 Data Fabric D1-FR12 The system shall provide static analysis capabilities for security validation of eBPF code and interactions between bound groups of WebAssembly modules SHOULD Scenario 1, 3 Static eBPF Analyser, Static Wasm interaction analysis Scenario-specific Support D1-FR13 The system shall support predictive maintenance use cases by providing timely machine data collection and maintenance alert generation MUST Scenario 1 WebAssembly Runtime, TEE Components, eBPF Tools, Orchestration Framework, Observability Platform D1-FR14 The system shall support factory robot control through deterministic, low-latency data flows meeting real-time control requirements MUST Scenario 3 WebAssembly Runtime, WASI Security Framework, eBPF Infrastructure, Static Analysis Tools, TEE Components, Orchestration Platform D1-FR15 The system shall support cross-factory data sharing with federated learning capabilities while maintaining data sovereignty and interface boundaries MUST Scenario 2 Federated Learning Framework, ABAC Policy Engine, Attestation Platform, Encryption Services, Basic Monitoring 3.3.2 Non-Functional Requirements Non-Functional Requirements (NFRs) define the system-wide properties and quality attributes that the ELASTIC architecture must fulfil to ensure robustness, usability, and long-term maintainability. Unlike functional requirements, which specify what the system should do, NFRs describe how well the system performs under various conditions and constraints. These NFRs are essential for supporting the diverse and demanding scenarios of Demonstrator 1 and ensuring the ELASTIC solution meets industrial-grade expectations. They are classified and presented in Table 8 using a MUST/SHOULD/MAY priority scheme to reflect their criticality to system implementation and alignment with project goals. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 36 - August 31, 2025 Table 8: Non-Functional Requirements for Demonstrator 1 Req. ID Description Level Related Scenario Source Performance & Scalability D1-NFR1 The system shall support low-latency data processing with response times suitable for critical applications like robot control MUST Scenario 3 Accelerated microservices interconnection D1-NFR2 The system shall scale to handle concurrent data streams from multiple IoT devices SHOULD All Scenarios Propeller orchestrator, Accelerated microservices interconnection Security & Privacy D1-NFR3 The system shall isolate function execution environments to prevent data leakage between tenants in multi-tenant deployments MUST All Scenarios All ELASTIC components related to access control & isolation for workloads D1-NFR4 The system shall comply with data sovereignty constraints such as ensuring sensitive data remains within designated boundaries unless explicitly authorised MUST Scenario 1 & 2 Federated Learning Toolbox, Data protection at-rest at the edge with TEE D1-NFR5 The system shall encrypt all data transfers using secure protocols (e.g., TLS 1.3, VPNs) to protect integrity and confidentiality MUST All Scenarios Data Fabric D1-NFR6 The system shall provide TEE-based secure processing for sensitive operational parameters with attestation verification SHOULD Scenario 1 TEE Software Management Agent, Propeller orchestrator, Multi-platform attestation component Portability & Interoperability D1-NFR7 Functions developed for the Data Fabric shall be portable across edge devices, in-network nodes, and cloud platforms without modification SHOULD All Scenarios WASI Security, WASI flexibly-defined capabilities D1-NFR8 The system shall support reliable TEE application migration between edge nodes SHOULD Scenario 2 Reliable enclave migration protocols, TEE Software Management Agent Maintainability & Usability D1-NFR9 Developers shall be able to register and manage data processing functions through simple declarative interfaces or low-code tools SHOULD All Scenarios Data Fabric D1-NFR10 The system shall provide comprehensive logging and metrics for monitoring, debugging, and performance optimisation MAY All Scenarios Observability framework for serverless workloads, NETTO The requirements analysis has outlined both functional and non-functional conditions that the ELASTIC architecture must satisfy to realise the IoT Data Fabric use case. With these requirements established, the next section (3.4) presents the instantiated architecture and system components that will implement them within Demonstrator 1. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 37 - August 31, 2025 3.4 Architecture Instantiation & System Components In Demonstrator 1, the ELASTIC conceptual architecture is instantiated to address the multidimensional challenges of secure, real-time, and scalable data analytics and control in manufacturing environments. This instantiation aims to validate that the abstract technologies, architectural principles, and software components developed across ELASTIC’s WPs can operate cohesively in a realistic industrial setting characterised by heterogeneity, performance constraints, and strict data governance requirements. The instantiation enables ELASTIC technologies to be deployed across a layered and modular architecture, bridging the gap between advanced research and operational needs in smart factory systems. It integrates foundational innovations such as WebAssembly-based workloads for portable, sandboxed function execution; TEEs for secure processing of sensitive machine data; eBPF-based monitoring and distributed state synchronisation for real-time performance; federated learning and access control mechanisms for secure cross-factory collaboration; and orchestration frameworks (e.g., Wasm-operator, Propeller) for scalable, low-overhead function management. Each of these components plays a defined role in enabling the three demonstrator scenarios with targeted benefits such as latency determinism, data sovereignty assurance, and policydriven security. The instantiation supports the validation of key features including seamless deployment of WebAssembly functions across edge nodes, TEE-based execution of sensitive workloads, secure workload migration, and fine-grained policy enforcement through ABAC. By operationalising the ELASTIC architecture in this context, the demonstrator provides both technical validation and a replicable reference model for industrial stakeholders seeking to adopt trustworthy edge-to-cloud computing solutions in complex, mission-critical environments. Figure 2 below provides a high-level representation of how the ELASTIC architecture is instantiated in Demonstrator 1, showing the layered interactions between components, data flows, and orchestration logic across industrial devices, edge nodes, and cloud infrastructure. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 38 - August 31, 2025 Figure 2. Instantiated ELASTIC Architecture for Demonstrator 1 To illustrate how ELASTIC technologies support the concrete scenarios of Demonstrator 1, Table 9 maps each technical component to its corresponding use case. This mapping is preliminary and subject to change as integration and testing progress. Table 9: Preliminary Mapping of ELASTIC Components to Demonstrator 1 Scenarios Component Main WP Provider Block Scenario 1 Scenario 2 Scenario 3 Wasm-operator WP2 IMEC Orchestration Y N N Light-weight Security orchestrator for Edge devices WP3 THS N Y N Federated Learning Toolbox WP4 ZEN N Y N TEE Software Management Agent WP3 UVC Y N N Reliable enclave migration protocols WP1 AAL N N Y Propeller Orchestrator WP2 AMA Y N N Data protection at-rest at the edge with TEE solution + Hardware-based cryptography module WP4 THS, TUC Isolation & Confidentiality N Y N WASI Security WP1 IMEC N N Y WasmHAL Hardware WP2 IMEC Y N N ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 39 - August 31, 2025 Static eBPF code security Analyser WP1 POLITO N N Y Static analysis of interaction between Wasm modules WP1 AAL Communication N N Y Accelerated microservices interconnection WP2 POLITO N N Y eBPF distributed state synchronisation WP2 POLITO N N Y NETTO WP2 POLITO Monitoring & Detection Y N Y AI Intrusion Detection System WP1 TUC Y N N Observability framework for serverless workloads WP2 ERF Y N N Multi-platform attestation component WP3 ERF Trust & Access Control Y Y N Light-weight Attribute-based Access Control (ABAC) solution WP2 THS N Y N The Demonstrator 1 use case tackles some of the most pressing structural and operational challenges that modern industrial environments face as they progress toward secure and intelligent manufacturing as presented in Section 3.1.2.2. These include deeply rooted integration complexities, heightened security and regulatory pressures, and strict performance expectations. The ELASTIC architecture offers a cohesive and modular approach to address these challenges through its combination of portable execution environments, confidential computing, dynamic orchestration, and distributed observability. Table 10 below maps each identified industrial challenge to specific ELASTIC technologies and components, explaining how the architecture provides a practical, scalable, and secure foundation for next-generation manufacturing. Table 10: Mapping of Demonstrator 1 Challenges to ELASTIC Architecture Components and Rationale Industrial Challenges Relevant ELASTIC Components Architecture Rationale Data Integration and Interoperability Crisis WasmHAL Hardware Interfaces Wasm-operator Federated Learning Toolbox WebAssembly provides standardised, portable functions for integrating heterogeneous devices and protocols. WasmHAL abstracts sensor/hardware interfaces, while FL enables analytics even when data structures vary across factories. Protocol and Format Diversity WasmHAL Proplet Runtime ELASTIC components can ingest and normalise data from multiple IIoT protocols and formats using WebAssembly-based functions deployed on edge nodes. Semantic Gaps Orchestration & Policy Engine eBPF Observability Tools Time-synchronised observability tools help align streams, while policies enforce semantic translation and normalisation at the edge. Security and Compliance in Connected Manufacturing TEE Software Management Agent Multi-platform Attestation WASI Security Lightweight ABAC AI IDS ELASTIC enables confidential computing using TEEs and attestation. WASI and ABAC ensure policy-based enforcement of access control, and AI-based intrusion detection adds runtime security. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 40 - August 31, 2025 Data Sovereignty & IP Protection Propeller Orchestrator TEE Processing ABAC & Policy Engine Data remains at the edge, orchestrated securely by Propeller, while sensitive workloads are executed within TEEs to guarantee confidentiality and integrity. Fine-grained access control ensures only authorised users/functions access sensitive operational data. Regulatory Compliance (e.g., GDPR) TEE Processing Key Management Policy Enforcement Engine All data is processed within TEEs with encryption and audit-ready logs. Compliance policies are enforced at runtime and function deployment levels. Performance and Reliability Requirements Accelerated Microservices Interconnection eBPF Distributed State Synchronisation Reliable Enclave Migration Protocols These components reduce latency, support realtime control loops, and enable seamless migration of functions with minimal downtime for high availability. Low-Latency Requirements eBPF Networking Stack Wasm Runtime Deterministic Orchestration Kernel-bypass and WebAssembly runtimes deliver low-overhead execution, ensuring real-time processing for robot control and safety systems. Scalability Wasm-operator FaaS Orchestration (Propeller) Distributed Observability ELASTIC supports horizontal scaling of workloads, coordinated through lightweight operators. Observability tools help maintain performance even in large deployments. Following the architectural overview and challenge-response mapping, the sections below provide a targeted analysis of each ELASTIC component integrated into Demonstrator 1. For each technology, we highlight its intended role, relevance to one or more scenarios, and its contribution to achieving the demonstrator’s functional and non-functional objectives. Observability Framework for Serverless Workloads (ERF) This component supports tracing of serverless Wasm workloads based on the Spinkube platform. The component can be used for alerting of errors near-real time for various purposes, including preventive maintenance. Within Demonstrator 1, its main purpose is to provide comprehensive monitoring and observability primarily for Scenario 1, integrating with eBPF and cloud-native observability tools like OpenTelemetry to track performance metrics, resource utilisation, and system behaviour across the distributed edge infrastructure. Multi-platform Attestation Component (ERF) This component supports dynamic, automated trust establishment between data consumers, data producers, data handling functions, and other entities within the data fabric in Demonstrator 1. The component abstracts vendor-specific attestation procedures with unified interfaces, and thus enables attestation across various TEE architectures and cloud service providers. This capability is particularly relevant for factory systems and cross-factory data sharing scenarios, where policies may require TEEs for certain data. Its purpose is to ensure consistent, standards-based trust establishment, aligned with IETF RATS concepts, thereby facilitating secure collaboration across heterogeneous industrial infrastructures. TEE Software Management Agent (UVC) The role of the Software Management Agent (SMA) is to perform the remote attestation procedure. The goal of remote attestation is to prove to the user of the TEE that the TEE is ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 41 - August 31, 2025 configured correctly, meaning the TEE is running on the expected hardware and is running the expected software. Critical for the predictive maintenance use case where sensitive machine data must be processed within secure enclaves while maintaining operational efficiency. In the future, it is envisioned that the attestation verification process is performed by a dedicated component called the Verifier. The idea is for the Verifier to verify the attestation report and issue the SMA a certificate that the SMA will use in communication with other components of the system. That way, the remote attestation process is done only once, and other components can verify the SMA's trustworthiness based on the certificate the SMA is using. This modification applies both to Demonstrator 1 and 2. Wasm-operator (IMEC) Wasm-operator is used in the control plane to run the analytics operators in the predictive maintenance scenarios. It specifically allows to run these operators very efficiently to reduce their resource usage footprint. Its integration points are the following. • Orchestrator: Wasm-operator is deployed as a plugin to the Kubernetes orchestrator. It uses the Kubernetes API in order to request, read, and modify custom resources and other Kubernetes objects in order to perform the control-plane logic of the operators running inside of wasm-operator. • Operator: The operator created for this demonstrator uses the kube-rs framework and has been compiled using our custom patched kube-rs version that intercepts calls to the Kubernetes API to route them through the wasm-operator framework instead. The value of this framework is that it greatly reduces the resource usage of Kubernetes Operators, freeing up more resources to the actual compute logic and/or allowing for more complex control-plane logic on edge and IoT devices. WASI Security (IMEC) WASI Security is used in this demonstrator to enforce fine-grained hardware access control for the robot control use-case. It ensures unauthorised workloads cannot access the robot controls. It does this by blocking and mediating calls from WebAssembly components to the underlying host system and connected hardware. Access control policies are provided by orchestrators using standardised metadata formats. Its integration points are the following: • Wasm Runtime: WASI Security is added to the Wasmtime runtime as a plugin. • Orchestrator: the orchestrator deploying the workloads uses the WASI Security format to describe the access control a workload is allowed to have. • Workloads indirectly use WASI security in that their system calls are filtered through WASI security, but its operation is invisible to the workloads in practice. The value of this framework is multi-faceted. • Ensures only authorised workloads can access the robot control. • Limit the impact of an exploit in workload code using least-privileges concept. • Ensures the orchestration layer can communicate access control policies to the runtime sandbox. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 48 - August 31, 2025 demonstrate the feasibility of trustworthy, high-performance industrial data operations in realworld contexts. 3.5.1 Scenario 1: Predictive Maintenance 3.5.1.1 Overview This workflow demonstrates ELASTIC predictive maintenance through 4 sequential phases, focusing on how components are designed to integrate and deliver secure factory analytics. 3.5.1.2 Integration Flow & Technical Architecture The complete workflow integrates through designed interfaces: Figure 3. Integration Flow & Technical Architecture - Scenario 1 | Demonstrator 1 3.5.1.3 Phase 1: Prerequisites & Security Setup What Happens Security foundation is established through code validation, TEE attestation, and policy configuration before any workload deployment. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 49 - August 31, 2025 Figure 4. Prerequisites & Security Setup - Scenario 1 | Demonstrator 1 Technical Implementation Design Static eBPF Code Security Analyser (POLITO) • Implementation: Designed as a development-time tool that scans eBPF programs for security vulnerabilities • How it works: o Performs static analysis to identify issues that would cause kernel verifier rejection o Integrates into CI/CD pipeline for automated validation o Provides developer feedback to improve eBPF code security before deployment • Integration: Validates eBPF code used by NETTO and other monitoring components Multi-platform Attestation Component (ERF) • Implementation: Designed as a unified attestation service abstracting vendor-specific TEE implementations • How it works: o Implements IETF RATS-compliant attestation procedures o Provides standardised APIs for AMD SEV-SNP and Intel TDX attestation o Generates attestation evidence and verification reports ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 50 - August 31, 2025 • Integration: Establishes trust foundation for TEE Software Management Agent Security Policy Configuration • Implementation: Designed as a centralised policy management system • How it works: o Configures ABAC policies for fine-grained access control o Defines data sovereignty rules and processing boundaries o Enforces capability-based permissions for Wasm workloads • Integration: Provides policy framework for WASI Security and TEE environments 3.5.1.4 Phase 2: Application Development & Deployment What Happens Predictive maintenance applications are packaged as Wasm modules and orchestrated across edge infrastructure with resource optimisation. Figure 5. Application Development & Deployment - Scenario 1 | Demonstrator 1 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 51 - August 31, 2025 Technical Implementation Design Propeller Orchestrator (AMA) • Implementation: Designed as a distributed orchestration system with Manager-Proplet architecture • How it works: o Manager component runs on cloud/fog infrastructure for centralised control o Proplet runtime executes on constrained edge devices (ESP32-C6, Raspberry Pi) o Uses MQTT broker (SuperMQ) for messaging between Manager and Proplets o Supports OCI-compliant container registries for Wasm artifact distribution o Implements OTA update mechanisms for remote function deployment • Integration: Coordinates with Wasm-operator for Kubernetes environments and WASI Security for access control Wasm-operator (IMEC) • Implementation: Designed as a Kubernetes plugin that runs control-plane logic in WebAssembly • How it works: o Intercepts Kubernetes API calls through custom patched kube-rs framework o Automatically swaps inactive operators to disk during low-activity periods o Provides resource-efficient alternative to traditional Kubernetes operators o Manages custom resources and Kubernetes objects for Wasm workload lifecycle • Integration: Deployed as plugin to Kubernetes orchestrator, works with Propeller for edge deployment WASI Security (IMEC) • Implementation: Designed as a Wasmtime runtime plugin for capability-based access control • How it works: o Mediates system calls from WebAssembly components to host system o Enforces fine-grained hardware access permissions through standardised metadata o Implements least-privilege principle for sensor and actuator access o Blocks unauthorised workloads from accessing critical factory systems • Integration: Integrated into Wasmtime runtime, configured by orchestrators using WASI Security format 3.5.1.5 Phase 3: Secure Data Pipeline What Happens ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 52 - August 31, 2025 Factory sensor data flows through secure processing pipeline with TEE protection, transparent encryption, and local analytics execution. Figure 6. Secure Data Pipeline - Scenario 1 | Demonstrator 1 Technical Implementation Design WasmHAL Hardware Interfaces (IMEC) • Implementation: Designed as SDK and runtime extension for WebAssembly hardware integration • How it works: ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 53 - August 31, 2025 o Provides standardised APIs for I2C, USB, and GPIO communication o Compiles sensor drivers into portable WebAssembly modules o Enables multi-protocol support (MQTT, CoAP, OPC-UA) with automatic translation o Implements data format conversion (JSON, CBOR, binary) for heterogeneous devices • Integration: Added to Wasmtime runtime as plugin, enables Wasm applications to access factory sensors TEE Software Management Agent (UVC) • Implementation: Designed to manage secure workload lifecycle within TEE environments • How it works: o Performs remote attestation procedures to prove TEE integrity o Manages deployment, execution, and termination of Wasm workloads in TEE o Coordinates with Multi-platform Attestation Component for trust establishment o Issues certificates based on attestation verification for secure communication • Integration: Operates within TEE environments, interfaces with attestation platform and key management Data Protection at-rest at the Edge with TEE Solution (THS) • Implementation: Designed for transparent encryption of WebAssembly workload data • How it works: o Intercepts data read/write operations within TEE environment o Provides automatic encryption/decryption using PKCS11 interface o Manages cryptographic keys through hardware root of trust (TPMs, Secure Elements) o Enables secure cross-site data sharing with hardware-backed encryption • Integration: Compiled and embedded inside TEE enclaves, configured during enclave initialisation Predictive Analytics Processing • Implementation: Designed as Wasm-based analytics functions that process sensor data locally • How it works: o Wasm workloads analyse vibration, temperature, and pressure data in real-time o Implements threshold-based anomaly detection and trend analysis o Generates maintenance alerts when failure probability exceeds configured thresholds o Processes data within TEE boundaries to ensure data sovereignty ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 54 - August 31, 2025 • Integration: Deployed via Propeller Orchestrator, secured by WASI Security, executed in TEE environments 3.5.1.6 Phase 4: Comprehensive Observability What Happens System-wide monitoring provides visibility into network performance, security threats, and Wasm workload behaviour across the distributed infrastructure. Figure 7. Comprehensive Observability - Scenario 1 | Demonstrator 1 Technical Implementation Design NETTO (POLITO) • Implementation: Designed as eBPF application for Linux networking subsystem monitoring • How it works: o Uses eBPF probing and tracing to extract detailed CPU usage metrics o Implements sampling-based approach for high accuracy with minimal overhead ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 55 - August 31, 2025 o Dissects monolithic system/softirq CPU consumption into individual network functions o Exports metrics in Pyroscope textual format for Grafana consumption • Integration: Deployed on VMs with network load, feeds centralised Grafana dashboard Artificial Intelligence Intrusion Detection System (TUC) • Implementation: Designed as hardware-accelerated network security monitoring system • How it works: o Hardware IDS implemented on FPGA (Xilinx Alveo U200) for parallelised pattern matching o Derives from Snort framework for established signature-based detection o AI/ML module applies semi-supervised online learning to update signature database o Processes live network traffic with deep packet inspection capabilities o Reports alerts to centralised Grafana dashboard for security visualisation • Integration: Takes network traffic input, integrates with cloud dashboard for alert visualisation Observability Framework for Serverless Workloads (ERF) • Implementation: Designed for comprehensive Wasm workload monitoring using cloud-native tools • How it works: o Traces serverless Wasm workloads based on Spinkube platform integration o Integrates with OpenTelemetry for standardised observability data collection o Provides distributed tracing across edge infrastructure components o Enables near real-time alerting for preventive maintenance scenarios o Supports performance metrics, resource utilisation, and system behavior tracking • Integration: Works with eBPF tools and cloud-native observability stack, feeds cloud dashboard Static eBPF Code Security Analyser Integration • Implementation: Designed to ensure security of deployed eBPF monitoring components • How it works: o Validates eBPF code used by NETTO and other monitoring tools o Performs compile-time security analysis to prevent runtime issues o Improves developer productivity by catching security issues early o Ensures reliable deployment of eBPF-based monitoring infrastructure ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 56 - August 31, 2025 • Integration: Validates eBPF code before deployment in monitoring components 3.5.2 Scenario 2: Cross-Factory Data Sharing 3.5.2.1 Overview This workflow demonstrates ELASTIC cross-factory data sharing through 3 sequential phases, focusing on how components are designed to integrate and deliver policy-driven collaborative analytics between autonomous manufacturing facilities using federated learning and access control capabilities. 3.5.2.2 Integration Flow & Technical Architecture The complete workflow integrates through designed interfaces: Figure 8. Integration Flow & Technical Architecture - Scenario 2 | Demonstrator 1 3.5.2.3 Phase 1: Trust Establishment & Policy Setup What Happens Trust establishment and factory registration creates secure communication channels between participating manufacturing facilities through standardised attestation procedures and policy configuration. Figure 9. Trust Establishment & Policy Setup - Scenario 2 | Demonstrator 1 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 57 - August 31, 2025 Technical Implementation Design Multi-platform Attestation Component (ERF) • Implementation: Designed as a unified attestation service for cross-factory trust establishment • How it works: o Implements IETF RATS-compliant attestation procedures across heterogeneous TEE architectures o Provides standardised APIs for AMD SEV-SNP and Intel TDX attestation verification o Establishes cryptographic trust between participating factories o Generates factory-specific certificates and identity tokens for secure authentication • Integration: Establishes trust foundation for TEE Software Management Agent and cross-factory communication Light-weight Attribute-based Access Control (ABAC) Solution (THS) • Implementation: Designed for fine-grained cross-factory data sharing control • How it works: o Enforces attribute-based policies on data types (OEE metrics, energy consumption, quality indicators) o Supports complex policy expressions with real-time evaluation o Provides dual-plane control for data plane and control plane enforcement o Enables selective collaboration based on business agreements and data sensitivity • Integration: Deployed in WebAssembly environment, configured via orchestrator, interfaces with TEE processing Hardware-based Cryptography Module (THS) • Implementation: Designed for secure cross-factory encryption and key management • How it works: o Provides hardware-backed key storage and cryptographic operations o Enables end-to-end encryption for cross-site data sharing o Implements secure key exchange protocols between factories o Ensures private keys never leave hardware security boundaries • Integration: Integrates with Data Protection at-rest component for transparent encryption operations 3.5.2.4 Phase 2: Federated Learning Infrastructure What Happens ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 64 - August 31, 2025 • How it works: o Implements kernel-bypass mechanisms for intraand inter-node communication o Uses eBPF and RDMA solutions to achieve low and deterministic latency o Provides customised fast path for host-local TCP/IP communication o Enables per-connection basis control via eBPF control plane program • Integration: Integrates into factory infrastructure through custom kernel patches and user-space TCP-to-RDMA proxy eBPF Distributed State Synchronisation (POLITO) • Implementation: Designed to extend eBPF maps functionality for network domain data sharing • How it works: o Coordinates collaborating eBPF programs running on networked hosts o Maintains consistent robot state across distributed control components o Provides remarkably low data convergence delay for state synchronisation o Enables networked data sharing capabilities between servers • Integration: Deployed as companion eBPF probe and user-space program for each target eBPF map NETTO (POLITO) • Implementation: Designed as eBPF application for detailed CPU usage metrics extraction • How it works: o Uses eBPF probing and tracing capabilities for networking subsystem monitoring o Achieves high measurement accuracy with sampling-based approach o Dissects monolithic system and softirq CPU consumption into individual network functions o Exposes metrics using Pyroscope textual format for Grafana consumption • Integration: Deployed on VMs with considerable network load to provide infrastructure observability 3.5.3.5 Phase 3: Real-Time Control Loop Execution What Happens Real-time robot control executes with deterministic scheduling, secure live migration capabilities, and continuous safety monitoring for precision robotic operations. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 65 - August 31, 2025 Figure 15. Real-Time Control Loop Execution – Scenario 3 | Demonstrator 1 Technical Implementation Design Real-time Control Algorithm Execution • Implementation: Designed as WebAssembly-based control functions with guaranteed timing • How it works: o Executes with deterministic scheduling using real-time operating system (RTOS) o Provides priority-based scheduling and deadline guarantees o Processes real-time sensor data (position encoders, force sensors, vision systems) o Maintains continuous tracking of control loop timing, jitter, and execution overhead • Integration: Managed by Propeller Orchestrator for dynamic deployment and lifecycle management Reliable Enclave Migration Protocols (AAL) • Implementation: Designed for secure and reliable transfers of responsibility • How it works: o Implements protocols for secure responsibility transfers under adverse network conditions o Provides non-repudiable receipts for responsibility demonstration o Enables secure migration of robot arm control loop components o Validates correct migration to new nodes during handover ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 66 - August 31, 2025 • Integration: Invoked by system components to initiate responsibility transfers with proof mechanisms Safety Verification and Runtime Monitoring • Implementation: Designed for continuous validation of control parameters and safety constraints • How it works: o Performs runtime monitoring with immediate shutdown capabilities o Detects sensor failures, actuator malfunctions, and communication errors in realtime o Implements hardware-level emergency stop mechanisms independent of software control o Uses cryptographic hash verification to prevent state corruption • Integration: Operates alongside control execution with direct hardware safety interfaces 3.6 Deployment and Integration This section presents the hardware and software requirements for the deployment of Demonstrator 1. These requirements were originally collected during the development of the ELASTIC architecture in Deliverable D1.1, using the common requirements template, and are consolidated here to guide the deployment and integration strategy. The demonstrator targets a heterogeneous environment, reflecting realistic industrial settings where lightweight edge devices, mid-tier fog nodes, and cloud infrastructures coexist. Accordingly, the deployment follows an edge–fog–cloud continuum, ensuring that the components can be validated across diverse platforms, from resource-constrained IoT devices to TEE-enabled servers and cloudnative orchestration systems. 3.6.1 Hardware and System Infrastructure Requirements This subsection describes the required hardware resources, such as CPU type, memory, accelerators, storage, and network capabilities. Components vary in their dependencies: some require specialised hardware (e.g., Intel SGX/TDX, AMD SEV-SNP, or FPGA boards), while others can run on lightweight edge devices (e.g., ESP32-C6 or Raspberry Pi). Table 11 below summarises the hardware requirements for all Demonstrator 1 components, structured by Edge, Fog, and Cloud layers. Table 11: Hardware Infrastructure Requirements – Demonstrator 1 Component Hardware Requirements Edge Layer Propeller Orchestrator Minimal edge device spec: ~128–500 MHz MCU (e.g. ESP32-C6), ≥512 KB RAM, with network connectivity (e.g. Wi-Fi). Light-weight Security orchestrator for Edge devices TEE-enabled edge device Federated Learning Toolbox Basic edge devices running standard Linux distributions (Raspberry PI 3+ or Arduino Nano referent) Data protection at-rest at the edge with TEE solution Secure Element, Risc-V, Disk storage ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 67 - August 31, 2025 Hardware-based cryptography module Reconfigurable hardware platforms—specifically FPGA-based boards—deployed as edge devices in cluster computing environments. Artificial Intelligence Intrusion Detection System AI-IDS Cloud-based integration on Xilinx Alveo U200 FPGA: • PCIe Interface: PCIe Gen3 ×16 (up to 64 GB/s) • Power Supply: Max board power: ~225 W • Cooling: Passive cooling • Host Server Requirements: ○ Minimum 64 GB system RAM ○ Linux distributions: Ubuntu, RHEL/CentOS with XRT drivers Fog Layer Propeller Orchestrator • For Manager/Proxy: Linux server with ≥2 cores, ≥1 GB RAM, network access to registries and brokers • Storage requirements: minimal (Wasm binaries are small; requires enough to buffer/download module chunks). NETTO - A tool to measure the cost of the Linux network stack in real-time Any host capable of running Linux eBPF distributed state synchronisation Any host capable of running Linux, plus RDMA compatible NICs Static eBPF code security Analyser Any host capable of running Linux kernel 6.8 Static analysis of interaction between Wasm modules Roots of trust for attestation Cloud Layer Wasm-operator Any platform capable of running Kubernetes TEE Software Management Agent AMD SEV-SNP TEE or Intel TDX TEE support Reliable enclave migration protocols Any host with network access to other migration target hosts WASI Security Any host capable of running Linux WasmHAL hardware Any host capable of running Linux Accelerated microservices interconnection Any host capable of running Linux, plus RDMA compatible NICs Observability framework for serverless workloads Servers/cloud capable of running full Kubernetes system (minimum: one controller and one worker) Multi-platform attestation component The component does not need to be executed on specific hardware, but it requires inputs from TEEs (currently SEV-SNP or TDX). Light-weight Attribute-based Access Control (ABAC) solution User plane component (PEP): x86 / RISC-V 64 bit CPU, 2GB RAM or less (very much depends on the WASM runtime). Control plane component (PDP): x86-64 bit CPU, 10GB storage, 4GB RAM. This tiered mapping highlights that while many components can run on commodity Linux hosts, others require specialised TEEs or accelerator hardware. This heterogeneity reflects realistic industrial scenarios, but also introduces constraints: for example, FPGA availability may limit portability, and Linux kernel dependencies (≥6.8) may not align with legacy environments. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 68 - August 31, 2025 3.6.2 Software Requirements This subsection describes the software environment required for the deployment of Demonstrator 1 components. It includes operating systems, runtimes, libraries, orchestration frameworks, and security services that each component depends on. While some components require only a lightweight Wasm runtime, others rely on full Kubernetes clusters, modern Linux kernels, or additional orchestration and monitoring tools. Table 12 below presents the software requirements for all Demonstrator 1 components, also structured by Edge, Fog, and Cloud layers. Table 12: Software Environment Requirements – Demonstrator 1 Component Software Requirements Edge Layer Propeller Orchestrator No dependency on Kubernetes; runs standalone or within existing CI/CD pipelines; containerisation optional. Light-weight Security orchestrator for Edge devices Wasm runtime Federated Learning Toolbox Common widely used ML and cryptography libraries infrastructure stack, yet to be determined in detail. Data protection at-rest at the edge with TEE solution Keystone enclaves, Secure Element's pkcs11 API, WASM orchestrator, WASM workload with read/write access to storage Hardware-based cryptography module None Artificial Intelligence Intrusion Detection System • Ubuntu Linux distribution with XRT drivers • Support for JSON/CBOR data parsing libraries. • Python for the communication with the rest ELASTIC framework Fog Layer Propeller Orchestrator • Requires MQTT broker (SuperMQ) for messaging; supports integration with Prometheus/OpenTelemetry for observability. • Uses OCI-compliant container registries for Wasm artefact storage and distribution. NETTO - A tool to measure the cost of the Linux network stack in real-time Modern Linux kernel (>= 5.11) eBPF distributed state synchronisation Modern Linux kernel (>= 5.8) Static eBPF code security Analyser The component is being designed to work with Linux Kernel 6.8 Static analysis of interaction between Wasm modules Attestation framework Cloud Layer Wasm-operator One of the Kubernetes latest three minor releases (1.34, 1.33, 1.32) TEE Software Management Agent Linux Kernel that supports AMD SVE-SNP or Intel TDX Reliable enclave migration protocols None WASI Security WebAssembly runtime: wasmtime. OS: Linux (Ubuntu 24.04 as reference) WasmHAL hardware Runtime: Wasmtime OS: Linux ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 69 - August 31, 2025 Accelerated microservices interconnection Modern Linux Kernels Observability framework for serverless workloads Tested to work with Linux kernel version (5.15.0-25), Kubernetes (1.29.15), containerd shim spin (0.19.0) and spin (3.2.0) Multi-platform attestation component The component itself requires a WebAssembly runtime, integrated into a verification framework that runs on Linux. Rather than distributed as software, the verification service is expected to be provided as a service via an HTTP API. Light-weight Attribute-based Access Control (ABAC) solution Ubuntu 24.04 LTS 64-bit, JDK 21 TLS This tiered mapping of software environments shows that some components are lightweight and self-contained (e.g., Wasm runtimes on edge devices), while others rely on more complex infrastructures such as Kubernetes clusters or modern Linux kernels with specific features (e.g., eBPF support). Dependencies on emerging technologies — such as attestation frameworks, verification services, or observability stacks — highlight both the innovative scope of Demonstrator 1 and the integration challenges of aligning diverse toolchains across the distributed infrastructure. The layered organisation of hardware and software requirements ensures that each component can be deployed and validated in the environment best suited to its resource profile. This mapping also clarifies the dependencies that may affect integration — such as FPGA availability, TEE support, or Kubernetes deployment overhead — and provides a clear blueprint for orchestrating Demonstrator 1 across all three deployment layers. To operationalise these requirements, Demonstrator 1 relies on a combination of Ericsson’s research datacenter infrastructure, public cloud resources, and specialised IoT/edge devices. The next section details the testbed and infrastructure setup, describing the facilities and platforms where the demonstrator will be deployed and validated. 3.7 Testbed & Infrastructure Setup Demonstrator 1 testbed is primarily hosted by Ericsson. It is referred to formally as Ericsson Research Data Center (ER DC) and informally as Xerces. ERDC is located in Lund, Sweden. It is an OpenStack environment that is accessible from the internet. Thus, it is used by projects that run services that have to be reached from outside Ericsson's corporate network. The goal of this environment is to provide a laboratory for cloud research and at the same time offer a computer platform for big data, analytics, and simulations. IaaS is an agile and flexible cloud lab with hands-on support and services for cloud technology research, user-friendly data analytics, run by datacenter operation experts. ER DC is operated by a team of IT professionals and adhere to strict Ericsson security and safety policies.This is important in order to protect potentially sensitive user data. To this end ER DC is designed to provide a satisfactory security level for ERDC, both physically and network-wise. At present it looks like this: • Autonomous System (AS) with redundant 2x10Gb connection to the internet (AS Ericsson to route the traffic to the services over multiple service providers and thus provide a high-level of network redundancy.). • Redundant power and cooling. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 70 - August 31, 2025 • Shell protection with ID system and strictly limited access. • Fire extinguishing system. • Redundant storage and backup. • Active automated penetration tests for all known safety holes (CVE). • Monitoring of all compute, storage, and network systems. • Central logging from all facilities systems. ER DC is designed and maintained according to ISO 27001, ASIS Protection of Assets, ISO 9001 (Ericsson Blue Review) and all data management is in accordance with GDPR. The current network fabric is based on Mellanox SDN technology and provides a high level of isolation. Data at rest can be encrypted as part of the standard offering. Tenants with special needs may choose to handle the encryption and keys themselves. Decommissioned disks are always destroyed per Ericsson standard IT routines. We offer limited support for secure compute enclaves (SGX2) but intend to increase this when the hardware standards mature. Server and router hardware that have been exposed to the Internet domain are never reused for a domain or cluster with higher security requirements, per Ericsson standard IT routines. The entire data hall was designed for 2MW, but currently has only redundant power and cooling for 1MW. The hardware setup on Xerces includes the following and is shared among all the projects hosted in the Data Center. For the purpose of Demonstrator-1, required hardware has already been allocated with the possibility to increase the allocation as the need arises. • >300 physical host, all HP servers with 20+ cores, 256+ GB RAM, gives >6k CPU cores • 16 Nvidia V100 GPUs • 48 Nvidia A100 GPUs (with MIG support we get 224 virtual GPUs) • 36 Nvidia GTX1080Ti GPUs • 2 PB storage (spinning disc) • 50 TB NVMe storage • Dell 100 Gbps network fabric • External Internet 2 x 10 Gbps In addition to the ER DC environment, Demonstrator 1 has access to hyper-scale cloud environments provided by Azure and AWS. The current plan is to use the Azure environment for TEE related components. Lastly, for IoT and Edge environments, the following hardware is available: • ERF has 1 Niryo One 13 (Robot arm + Raspberry Pi + ROS2) (for scenario 3). 13 "Niryo One, an accessible robot for makers powered by open source," Niryo, Jul. 11, 2017. [Online]. Available: https://niryo.com/niryo-one-accessible-robot-open-source/. [Accessed: Aug. 28, 2025]. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 71 - August 31, 2025 • ERF has acquired 1 Ericsson Cradlepoint R980 14 and 1 Ericsson Cradlepoint E3000 15 mainly for the purpose of ELASTIC (for scenario 1). In addition, the following hardware is also available and may be utilised as the need emerges: • Raspberry Pi 3 • NVIDIA Jetsons • ERF has 1 Siemens SIMATIC IOT2050 16 “Edge IoT Gateway” 3.8 Datasets This section outlines the datasets that will be used for each of the three use case scenarios within Demonstrator 1. The datasets include real-world industrial sources as well as synthetic data to ensure comprehensive, scalable, and privacy-aware evaluation of ELASTIC technologies. Data sensitivity, anonymisation methods, licensing, and processing approaches are also addressed to ensure compliance with ethical and legal requirements. Scenario 1 – Predictive Maintenance This scenario relies on machine sensor data and maintenance logs from CNC machines, lathes, and milling equipment. The dataset includes: • Sensor readings: motor temperature (°C), vibration measurements (X, Y, Z axes), hydraulic pressure (bar), tool wear (%), machine ID, and timestamp. • Fault and maintenance records: fault codes (F0–F3), failure occurrence flags, maintenance timestamps, and equipment downtime durations. Sensitivity: Moderate – data may include machine identifiers and potentially linkable operational information. Anonymisation & Processing: All machine IDs are pseudonymised; timestamps and fault events are retained for analytical accuracy. Source: Siemens Smart Manufacturing Dataset (CC BY-NC-SA 4.0) and supplemented with synthetic data Scenario 2 – Cross-Factory Data Sharing This use case utilises federated learning across multiple factory sites, leveraging: • Operational metrics: OEE, quality defect rates, production throughput, and site identifiers. Sensitivity: High – data reflects factory-level productivity and defect metrics. Anonymisation & Processing: Factory identifiers are generalised; statistical noise may be applied in future versions to protect competitive information. Source: We have not yet identified any open data sets and are working with stakeholders to identify the relevant metrics for cross-data sharing and how those metrics are derived from the 14 “Ericsson Cradlepoint R980 – Small, versatile 5G router for advanced vehicle and IoT connectivity,” Cradlepoint, 2025. [Online]. Available: https://cradlepoint.com/product/endpoints/r980/. [Accessed: Aug. 28, 2025]. 15 “Ericsson Cradlepoint E3000 – 5G, SD-WAN, and security appliance for hybrid WAN sites,” Cradlepoint, 2025. [Online]. Available: https://cradlepoint.com/product/endpoints/e3000/. [Accessed: Aug. 28, 2025]. 16 “SIMATIC IOT2050 – the smart gateway for Industrial Edge and cloud connections,” Siemens, 2025. [Online]. Available: https://www.siemens.com/global/en/products/automation/industrial-computing/iot-gateways/simatic-iot2050.html. [Accessed: Aug. 28, 2025]. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 72 - August 31, 2025 datasets in Scenario 1. A data set for scenario 2 will either be found from open sources at a later stage or synthetic data sets will be designed for this scenario. Scenario 3 – Real-Time Robot Control Data required for this scenario includes: • Robot telemetry and control: joint positions, velocity/acceleration profiles, safety zone indicators, and control loop timing. Sensitivity: Low – mostly system-level, non-identifiable telemetry data. Anonymisation & Processing: Data is anonymised at the source; no personal or facilityidentifiable information is included. Source: This scenario doesn’t require any extensive data sets since it focuses on security orchestration. The key data elements are modelled within the ELASTIC system and this configuration shall be made available along with the final results. Data Sources and Licensing • Siemens Smart Manufacturing Dataset 17 o License: Creative Commons BY-NC-SA 4.0 o Contains over 1.5M records from a real industrial site (Hamburg) spanning three years of CNC operations. • Industrial IoT Synthetic Dataset 18 o License: Apache 2.0 o Simulates 500,000 machine profiles and includes maintenance and telemetry data from 30+ equipment types. Future Dataset Plans To ensure complete scenario coverage and compliance with data sovereignty principles, additional synthetic datasets may be generated. These will reflect realistic factory conditions while preserving privacy and enabling experimentation with ELASTIC security, orchestration, and monitoring components. 3.9 Demonstrator 1 – Minimum Viable Product The MVP for Demonstrator 1 represents the first integrated version of the ELASTIC framework, focused specifically on Scenario 1 – Predictive Maintenance. Although not a contractual obligation, the consortium considered it strategically important to have a functional MVP in place by M18 to validate early-stage integration efforts, demonstrate technological feasibility, and collect actionable feedback. Work towards the MVP began at M10 with demonstrator design activities, including the definition of use cases and scenarios, mapping of relevant ELASTIC components, and alignment across partners. In this phase, ERF coordinated bi-weekly demonstrator meetings to consolidate objectives, priorities, and integration sequences, complemented by one-to-one meetings with each technical partner to capture component roles, capabilities, and 17 Dataset Engineer, "Siemens Smart Manufacturing Maintenance Dataset," Kaggle, Jul. 2022. [Online]. Available: https://www.kaggle.com/datasets/datasetengineer/siemens-smart-manufacturing-maintenance-ds/data. [Accessed: Jul. 31, 2025]. 18 C. Ozensoy, "Industrial IoT Dataset (Synthetic)," Kaggle, Mar. 2022. [Online]. Available: https://www.kaggle.com/datasets/canozensoy/industrial-iot-dataset-synthetic/data. [Accessed: Jul. 31, 2025]. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 73 - August 31, 2025 dependencies. This groundwork ensured that requirements were clearly defined and integration blockers identified early. Building on this design phase, MVP development and integration started around M16. The MVP addresses a representative industrial environment, where edge intelligence and security are critical. It showcases the deployment of a lightweight, secure, and orchestrated data processing pipeline across edge and gateway nodes. The selected scenario simulates a manufacturing facility with multiple production lines that must monitor machine performance in real time. WebAssembly-based analytics functions are deployed across edge devices, with selected sensitive computations running in TEEs. Secure workload orchestration, monitoring, attestation, and threat detection mechanisms are integrated to ensure resilience, low latency, and compliance with trust and privacy requirements. To visualise the scope and integration, Figure 16 presents the overall ELASTIC architecture, with the MVP-included components highlighted in magenta. This provides a clear view of which parts of the full stack were activated and tested during this early phase. Figure 17 illustrates the high-level flow of scenario execution, from sensor data ingestion at the factory floor to analytics, security enforcement, and dashboard visualisation. Figure 16. ELASTIC architecture highlighting components used in the MVP for Scenario 1 of Demonstrator 1 ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 80 - August 31, 2025 3.10.4 Validation Methodology, Timeline and Execution Plan 3.10.4.1 Validation Methodology The validation methodology defines how each ELASTIC technology integrated into Demonstrator 1 will be assessed for functionality, performance, security, and usability. Validation is structured around two complementary pillars: • Internal validation via KPIs – quantitative assessment based on requirements and success criteria. • External validation via feedback – qualitative assessment by end-users and stakeholders, focusing on usability, trust, and operational relevance. Each ELASTIC component will be validated for functional behaviour (e.g., workload execution, access enforcement), non-functional properties (e.g., latency, scalability, compatibility), and trust/security characteristics (e.g., attestation success, isolation guarantees). All results will be compiled and reported in the corresponding project deliverables, ensuring transparency and traceability. 3.10.4.2 Timeline The validation of Demonstrator 1 will follow a phased approach aligned with the progressive integration and maturity of ELASTIC technologies and use case scenarios. The timeline below (Table 15) outlines four key phases, each focusing on a specific set of technical priorities, validation activities, and demonstration scenarios. Table 15: Timeline and Execution Plan for Demonstrator 1 Phase Time Description Risks Mitigation Measures Foundation M13–M18 Implement Scenario 1 (Predictive Maintenance) as baseline. Establish TEE security framework and attestation mechanisms. Deploy basic WebAssembly runtime and orchestration capabilities. Immature components; unclear security policies; integration delays. Prioritise mature features; early alignment meetings on TEE requirements; set up minimal viable deployment. Federation M19–M24 Extend to Scenario 2 (CrossFactory Data Sharing). Implement federated learning and ABAC policy frameworks. Validate multi-site security and compliance mechanisms. Policy enforcement gaps; data interoperability issues; compliance concerns.. Early ABAC testing with synthetic data; shared API specs; legal/data governance pre-checks. Real-Time M25–M30 Deploy Scenario 3 (Real-Time Robot Control). Implement deterministic networking and safety validation. Complete integration testing and performance validation. Timing constraints not met; deterministic behaviour not guaranteed. Pre-test real-time constraints in lab; refine orchestration workflows for latency minimisation. Optimisation M31–M36 Conduct performance tuning and scalability optimisation. Integrate advanced security features and threat detection. Carry out end-toend validation of all three scenarios against defined KPIs, Inconsistent performance across scenarios; KPI gaps; delayed stakeholder feedback. Early validation planning; assign scenario leads; establish baseline metrics and success thresholds. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 81 - August 31, 2025 complemented by stakeholder and external feedback assessment, to prepare for industrial deployment and user acceptance testing. 3.10.4.3 Execution Plan The execution of validation activities in Demonstrator 1 is organised around two complementary dimensions: internal KPI-based validation and external feedback validation. Dimension 1: Internal KPI-based Validation focuses on quantitative assessment of ELASTIC components and the demonstrator as a whole. Each component will first be validated individually in partner laboratories or testbeds to ensure correct functionality in isolation. This is followed by system-level and end-to-end validation within the integrated demonstrator, where interoperability, scalability, and performance are assessed under realistic workloads. Component owners are responsible for executing local tests and reporting results, while scenario leads coordinate cross-partner integration and the measurement of KPIs. Validation will rely on synthetic datasets, static and dynamic analysis tools, and observability dashboards to capture key performance metrics. All results will be documented with clear test objectives, outcomes, and identified issues, and will be included in the project’s deliverables to ensure traceability against defined KPIs. Dimension 2: External Feedback Validation complements this by incorporating qualitative assessment from end-users and stakeholders. Feedback will be collected through workshops, demonstration sessions, and structured surveys, focusing on usability, trust, and the perceived value of ELASTIC technologies in industrial contexts. Feedback will be analysed, summarised, and systematically linked to relevant technical areas, with results shared with responsible partners to guide refinements and optimise the demonstrator’s evolution. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 82 - August 31, 2025 4 Demonstrator 2: IT/OT - Privacy-preserving CC Platform to Migrate On-premise Sensitive IT Services to the Cloud Thales DIS brings its expertise in secure, mission-critical systems to evaluate how confidential computing and TEE-based service protection can be leveraged in real-time, safety-critical scenarios. Through ELASTIC, Thales is testing advanced mechanisms for secure enclave migration, enabling high-assurance services to be moved from on-premise to the public cloud, without breaking trust or compromising state. The demonstrators provide Thales with a controlled environment to validate these complex features at an early stage, ensuring production readiness and compliance with operational and regulatory standards. Building on this industrial perspective, Section 4 introduces Demonstrator 2: IT/OT – Privacypreserving CC Platform to Migrate On-premise Sensitive IT Services to the Cloud. This section is structured into ten subsections. In 4.1, the objectives and context are outlined, including the motivation and overall goals of the demonstrator. 4.2 specifies the use case in detail, presenting the summary, domain relevance, scenario description, and identification of key stakeholders. 4.3 follows with the requirements analysis, addressing both functional and non-functional aspects. Subsection 4.4 describes the instantiated architecture and system components developed and contributed by project partners, while 4.5 elaborates on the technical workflow and key enabling technologies, providing an overview of the demonstrator’s operation. In 4.6, the focus shifts to deployment and integration, including hardware and software infrastructure requirements. 4.7 presents the testbed and infrastructure setup required for execution. 4.8 introduces the datasets used in the validation process. The next part, 4.9, defines the MVP for Demonstrator 2, while 4.10 provides the KPIs, evaluation parameters, validation plan, and protocols, detailing the methodology and assessment framework that will be applied. In this way, Section 4 offers a comprehensive overview of Demonstrator 2—from industrial motivation and use case specification, through architecture, workflows, and integration, to validation and performance assessment. 4.1 Objectives and Context 4.1.1 Demonstrator Motivation and Background The migration of sensitive IT services from on-premise infrastructures to public cloud environments is an accelerating trend, driven by the imperatives of scalability, cost-efficiency, and performance optimisation. However, this transition is frequently constrained by legitimate concerns regarding data confidentiality, regulatory compliance, and the inherent trust limitations of shared cloud infrastructures. For stakeholders such as THD, operating within highly regulated environments, the need for robust assurances around data protection and runtime integrity is paramount. Relevance and Impact of the Demonstrator This demonstrator is instrumental in validating the ELASTIC project’s overarching vision: to enable secure, portable, and efficient orchestration of services across heterogeneous infrastructures. It addresses a pressing and widespread industrial challenge—facilitating the secure migration of sensitive IT services, traditionally hosted in secure on-premise environments, to public cloud platforms without compromising data confidentiality, service integrity, or operational continuity. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 83 - August 31, 2025 The demonstrator’s significance is highlighted by its capacity to: • Bridge the IT/OT Security Gap: By integrating Confidential Computing technologies—such as TEEs, Remote Attestation, and Key Broker Services—the demonstrator ensures that sensitive data and applications remain protected, even within untrusted cloud environments. This is a critical enabler for secure IT/OT convergence in regulated sectors. • Enable Real-World Migration Scenarios: The selected use case, the BRT, is a legacy IT service with stringent security requirements. Its migration exemplifies the challenges faced by many industrial actors and demonstrates the practical applicability of ELASTIC technologies. • Showcase Portability through Wasm: Wasm serves as a runtime abstraction layer, enabling seamless deployment across diverse hardware and cloud platforms. This significantly reduces the complexity and cost associated with service migration. • Demonstrate Integration of ELASTIC Innovations: The demonstrator consolidates key outcomes from WP1 to WP4 - ranging from secure Wasm runtimes and orchestration mechanisms to lightweight confidential computing platforms - into a unified, operational scenario. • Support Industrial Adoption: By validating a secure and efficient migration workflow, the demonstrator offers a replicable blueprint for industrial stakeholders aiming to modernise their IT infrastructure while maintaining compliance and control. Furthermore, this demonstrator contributes to the strategic objectives of both the ELASTIC project and the European Union. By promoting open, portable, and secure technologies such as Wasm and TEEs, it supports the EU’s digital sovereignty agenda—reducing reliance on proprietary cloud platforms and fostering trust in European cloud and edge infrastructures. It also aligns with EU priorities on cybersecurity, data protection, and resilience, positioning itself as a key enabler for secure digital services in the 6G era. Key Challenges in Migrating IT Services to the Public Cloud The migration of IT services—particularly those handling sensitive data or operating under strict regulatory frameworks—presents a multifaceted set of challenges spanning technical, organisational, and legal domains. Key challenges include: Security and Privacy Concerns • Data Confidentiality: Ensuring the protection of sensitive data during transmission, storage, and processing in inherently less trusted public cloud environments. • Runtime Integrity: Guaranteeing that applications execute in secure, tamper-proof environments, especially for services managing personal or classified information. • Regulatory Compliance: Adhering to legal frameworks such as the GDPR, which impose stringent requirements on data handling in multi-tenant cloud infrastructures. Platform Heterogeneity ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 84 - August 31, 2025 • Infrastructure Disparities: On-premise systems often depend on specific hardware or OS configurations, while cloud platforms may differ in CPU architectures and virtualisation layers. • Service Model Fragmentation: The diversity of cloud service models (IaaS, PaaS, FaaS) introduces varying constraints and APIs, complicating portability and interoperability. • Vendor Lock-in: Proprietary runtimes and APIs hinder seamless migration across cloud providers or back to on-premise environments. Legacy Applications Constraints • Tight Coupling to On-Premise Environments: Many legacy applications are not cloud-native and rely on specific network, file system, or security configurations. • Refactoring Overhead: Adapting legacy code for cloud environments is resourceintensive, particularly when security and compliance must be preserved. Operational Complexity • Migration Downtime and Risk: Ensuring business continuity during migration requires meticulous planning, testing, and rollback strategies. • Monitoring and Observability: Achieving visibility into application behaviour in distributed cloud environments is challenging due to limited access to underlying infrastructure. Background on IT/OT convergence context • The convergence of IT and OT systems introduces new security, interoperability, and governance challenges. Traditionally isolated, OT systems are increasingly connected to IT networks, exposing them to broader threat surfaces. This convergence necessitates robust, scalable, and secure orchestration frameworks—such as those developed in ELASTIC—to ensure operational integrity and regulatory compliance across both domains. 4.1.2 Overall Objectives of the demonstrator The primary objective of this demonstrator is to validate the ELASTIC framework’s capacity to enable the secure, efficient, and portable migration of sensitive IT services from on-premise infrastructures to public cloud environments. It serves as a concrete implementation of ELASTIC’s core technological innovations, particularly in the context of IT/OT convergence and cloud-native security paradigms. High-level objectives of the demonstrator aims to achieve: Enable Secure Migration of Sensitive IT Services • Demonstrate the secure migration of a legacy application—specifically, the BRT—from a private, on-premise infrastructure to a public cloud environment. • Ensure end-to-end protection of application and data confidentiality and integrity throughout the migration and execution lifecycle, leveraging Confidential Computing technologies based on TEEs such as Intel TDX and AMD SEV. Address Platform Heterogeneity through Wasm ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 85 - August 31, 2025 • Validate the role of WebAssembly as a portable runtime abstraction that decouples application logic from hardware-specific and cloud-native dependencies. • Demonstrate seamless deployment of Wasm-based services across heterogeneous environments (e.g., x86_64 and ARM architectures, IaaS and FaaS models) with minimal code adaptation. • Explore the integration of Wasm runtimes within TEEs, assessing their effectiveness in delivering secure, portable, and isolated execution across diverse infrastructures. Demonstrate Attested and Trusted Execution • Employ Confidential Computing to ensure that sensitive data is protected not only at rest and in transit, but also during execution (data-in-use)—a critical requirement for applications like BRT that handle personal and security-sensitive information. • Utilise TEEs to provide hardware-enforced isolation, shielding workloads from the host system, including privileged software layers such as hypervisors and operating systems. • Implement Remote Attestation mechanisms to enable external verification of the TEE’s integrity and authenticity prior to processing sensitive data. • Integrate secure key provisioning and delivery mechanisms that bind encryption keys to attested TEEs, ensuring that data remains inaccessible unless the execution environment is verified and trusted. Provide a Blueprint for Industrial Adoption • Deliver a replicable and scalable migration workflow that can be adopted by other industrial stakeholders facing similar challenges. • Highlight the benefits of adopting open, portable, and secure technologies to reduce vendor lock-in and support compliance with European data protection and digital sovereignty requirements. Leveraging ELASTIC Outcomes in the Demonstrator (WP1–WP4) The demonstrator acts as a convergence point for the ELASTIC project’s core technological outcomes, integrating innovations from WP1 to WP4 into a cohesive, operational scenario that exemplifies secure and portable service migration. WP1 – WASI flexibility-defined capabilities • Contribution: Introduction of configurable access control mechanisms for WASI interfaces, enabling fine-grained, domain-specific restrictions on Wasm workloads. • Application: The demonstrator integrates these APIs and tools to enforce tailored access policies for the BRT application, aligning runtime behaviour with operational and regulatory requirements. WP2 – TEE Software Management Agent and Propeller Orchestrator • Contribution: Development of a Wasm execution environment within TEEs, supported by a Software Management Agent and the Propeller orchestrator for lifecycle management. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 86 - August 31, 2025 • Application: The BRT service is deployed as a Wasm workload inside a TEE, orchestrated by Propeller, which manages secure provisioning, scaling, and termination across heterogeneous cloud nodes. WP3 – Confidential Computing and Trust Infrastructure WasmHAL-Trust • Contribution: Provides a reference implementation of the WASM HAL-Trust interface, extending Wasm for TEE compatibility. • Application: Used during Wasm payload generation to ensure compatibility with TEE runtimes, enabling seamless integration into secure enclaves. Reliable Enclave Migration Protocol • Contribution: Ensures resilient migration of Wasm workloads between attested TEEs, even under adverse conditions. • Application: The demonstrator uses this protocol to support live migration of the BRT service between cloud nodes without compromising security or availability. Remote Attestation Platform • Contribution: Offers a Verifier platform with APIs for attestation evidence validation and policy-based appraisal. • Application: Before deployment, the demonstrator verifies the integrity of the target TEE environment using this platform, ensuring trust in the execution context. Key Broker Service • Contribution: Acts as a relying party that issues cryptographic keys based on attestation results. • Application: The BRT application uses keys from the Key Broker to seal and unseal sensitive data, ensuring confidentiality throughout the workload lifecycle. WP4 – AI-based Intrusion Detection System (AI-IDS) • Contribution: Delivers an AI-powered network intrusion detection system implemented on FPGA hardware, capable of deep packet inspection (DPI). • Application: The AI-IDS enables real-time threat detection, enhancing the security of the BRT service in hybrid IT/OT scenarios Benefits of the Demonstrator for THD and Industrial Stakeholders The ELASTIC demonstrator offers THD and other industrial users a concrete pathway to modernise their IT infrastructures while upholding stringent requirements for security, compliance, and operational excellence. Its value proposition spans multiple strategic dimensions: • Advanced Data Security and Privacy: Ensures sensitive workloads are protected through confidential computing and attestation mechanisms. • Trusted and Verifiable Migration: Enables secure, policy-driven migration of applications across trusted environments with integrity verification. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 87 - August 31, 2025 • Cross-Platform Portability: Facilitates seamless deployment of Wasm-based services across heterogeneous hardware and cloud infrastructures. • Operational and Cost Efficiency: Reduces overhead through lightweight orchestration and serverless execution models. • Regulatory and Compliance Readiness: Aligns with industry-specific security and data protection standards, supporting auditability and governance. • Industrial Scalability and Replicability: Provides a blueprint for secure digital transformation applicable across diverse industrial contexts. Use Case Selection Methodology The selection of the use case for Demonstrator 2 was guided by practical relevance and strategic alignment with ELASTIC’s objectives, rather than a rigid methodological framework. The Badge Request Tool (BRT) was chosen based on the following considerations: • Relevance: BRT is a legacy IT service integral to daily operations, managing sensitive personal and operational data—making it an ideal candidate for secure migration and execution in the cloud. • Data Sensitivity: As BRT handles employee identity and access credentials, it is subject to stringent internal and regulatory controls, making it well-suited for testing Confidential Computing and secure orchestration. • Strategic Fit: BRT had already been identified within THD’s digital transformation roadmap as a candidate for cloud migration. • Technical Feasibility: The architecture of BRT allows for integration with ELASTIC components such as Wasm and TEEs with manageable adaptation effort. • Narrative Strength: The BRT migration journey—from on-premise to secure cloud deployment—provides a compelling narrative to illustrate the value of ELASTIC’s innovations. • Broader Applicability: The challenges addressed in the BRT use case are representative of those faced by many industrial IT services, making the demonstrator a valuable reference model for wider adoption 4.2 Demonstration Use Case Specification 4.2.1 Summary of the Use Case This use case demonstrates the secure migration of a sensitive IT service, specifically, the BRT, from an on-premise environment to a public cloud infrastructure, both under the control of the same IT organisation. The BRT is a legacy application responsible for managing the full lifecycle of employee security badges, including creation, configuration, manufacturing, delivery, incident reporting, and renewal. Currently, BRT is hosted in Thales’ private cloud due to stringent security requirements, but it has been identified as an early candidate for cloud migration as part of the organisation’s digital transformation. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 88 - August 31, 2025 4.2.1.1 Problem Statement The main challenge addressed by this use case is the secure and efficient migration of a legacy, security-sensitive IT application from a controlled on-premise environment to a public cloud, while maintaining compliance with internal and regulatory security requirements. Key issues include: • Security and Confidentiality: Ensuring that sensitive personal and operational data remains protected during and after migration. • Platform Heterogeneity: Bridging the gap between different hardware, virtualisation, and operating system environments in on-premise and cloud infrastructures. • Legacy Constraints: Minimising the need for extensive refactoring of legacy applications to enable cloud compatibility. • Operational Continuity: Guaranteeing service integrity and minimal disruption during migration. 4.2.1.2 Solution Approach Until recently, such cloud migration was not feasible for highly sensitive workloads due to the lack of adequate security guarantees in public cloud environments. The emergence of confidential computing in cloud service provider (CSP) offerings has been a key enabler, allowing sensitive applications to benefit from hardware-based isolation and protection of data in use. However, current confidential computing solutions are typically specific to each CSP and to the underlying confidential computing platform (e.g., Intel SGX or TDX, AMD SEV, AWS Nitro Enclave), which introduces a significant risk of vendor lock-in and limits portability. Without an unifying framework, migrating sensitive workloads across different CSPs or confidential computing technologies would require substantial adaptation efforts and could compromise long-term flexibility. The ELASTIC framework directly addresses these challenges by providing an abstraction layer that enables secure, portable migration of legacy applications across heterogeneous confidential computing environments, thus mitigating vendor lock-in and supporting compliance with both internal and regulatory security requirements. 4.2.1.3 Benefits from ELASTIC’s Architecture and Technologies This use case is highly relevant for the IT/OT (Information Technology/Operational Technology) domain, especially in regulated sectors such as defense, critical infrastructure, and large enterprises. Many organisations face similar challenges as they seek to modernise legacy applications and leverage the scalability and flexibility of cloud environments, while remaining compliant with strict security and privacy regulations (e.g., GDPR). The BRT migration scenario is representative of broader industry needs for secure, portable, and efficient migration workflows. The ELASTIC project provides a set of innovative technologies that directly address the challenges outlined above: • WebAssembly Runtime Abstraction: By recompiling the BRT application to run as a Wasm workload, the migration process is simplified, reducing the need for major redesign and enabling portability across heterogeneous environments (on-premise and cloud, x86 and ARM, IaaS and FaaS). ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 89 - August 31, 2025 • Confidential Computing with TEEs: The migrated BRT application is executed within confidential computing environments (e.g., Intel TDX, AMD SEV), ensuring that sensitive data is protected not only at rest and in transit, but also during execution (“data-in-use”). • Remote Attestation and Key Management: ELASTIC’s remote attestation platform and key broker service ensure that only trusted, attested environments can run the BRT workload and access cryptographic keys, providing strong guarantees of integrity and confidentiality. • Seamless Migration Protocols: The use case leverages ELASTIC’s reliable enclave migration protocol to support live migration of the BRT service between cloud nodes without compromising security or availability. • AI-based Intrusion Detection: Integration with ELASTIC’s AI-powered intrusion detection system (AI-IDS) enhances the security posture of the migrated application, enabling real-time threat detection and response. 4.2.2 Scenario Description This scenario describes the business process behind the secure migration of the BRT from onpremise infrastructure to the cloud, enabled by ELASTIC technologies. The step-by-step flow below captures the triggers, actions, and safeguards across the migration lifecycle. Business Process 1. Initiation and Trigger ○ The migration process is initiated by the Cloud Transformation team from IT Organisation, based on a strategic decision to modernise legacy applications and leverage cloud scalability by the IT team. ○ The trigger event is the selection of the BRT as a pilot candidate for secure migration, following internal risk assessment and alignment with digital transformation goals. 2. Preparation and Assessment ○ The IT team performs a technical and security assessment of the BRT application, identifying dependencies, data sensitivity, and compliance requirements. ○ A migration plan is developed, specifying minimal redesign to enable BRT to run as a Wasm workload. 3. Wasm Recompilation and On-Premise Deployment ○ The BRT application is recompiled and containerised to run as a Wasm module, ensuring compatibility with both on-premise and cloud environments. ○ The Wasm-based BRT is deployed on the existing on-premise infrastructure, inside a TEE such as Intel TDX or AMD SEV, providing hardware-based isolation. 4. Data Handling and Security (On-Premise) ○ Employee badge data is generated and managed by the BRT application as usual. ○ All data at rest is encrypted using keys managed by a secure key broker, and all data in transit (e.g., between BRT and other internal systems) is protected using TLS. ○ Key Broker is only releasing keys if a Remote Attestation has been successfully performed on the TEE and the BRT ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 96 - August 31, 2025 Figure 18. Instantiated ELASTIC Architecture for Demonstrator 2 It can be observed that the identified components are distributed across different feature layers of the ELASTIC Software Stack, thereby providing value at multiple levels of the architecture. Table 21 summarises the key ELASTIC components across the main architectural blocks, highlighting their corresponding WP, provider, and functional role. Table 21: Key ELASTIC Components Across ELASTIC Architectural Blocks Component Main WP Provider Block WASI flexibility-defined capabilities WP1 AAL Trust & Access Control TEE Software Management Agent WP2 UVC Orchestration Propeller Orchestrator WP2 AMA Management & Orchestration WasmHAL-Trust WP3 LUN Isolation & Confidentiality Reliable Enclave Migration Protocol WP3 AAL Management & Orchestration Remote Attestation Platform WP3 THD Trust & Access Control Key Broker Service WP3 THD Trust & Access Control ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 97 - August 31, 2025 AI-based Intrusion Detection and System WP1 TUC Monitoring & Detection The use case of the Demonstrator 2, is facing some challenges, already explained in details in Section 4.1.1 (Key Challenges in Migrating IT Services to the Public Cloud), that can be summarised into the following goals: • Security and Privacy of data: Protect sensitive data during transmission, storage, and processing. • Runtime Integrity: Guarantee secure, tamper-proof execution for services handling personal data. • Regulatory Compliance: Embed compliance with legal frameworks (e.g., GDPR) into data handling processes with auditability and policy enforcement. • Platform Heterogeneity: Abstract infrastructure disparities between on-premise and cloud platforms by using an open set of APIs. • Vendor Lock-in Mitigation: Promote open standards and modular runtimes to ease migration. • Migration of legacy Application to the Cloud: Minimise refactoring overhead while preserving security and compliance. • Operational Complexity Reduction: Enhance observability and monitoring in distributed cloud environments. These goals are supported by the overall ELASTIC architecture and the components used for this use case as listed in Table 22 below. Table 22: Mapping of Use Case Goals to ELASTIC Components and Their Rationale Goals Components Contributing Rational Security and Privacy of data Remote Attestation Platform Key Broker Service TEE Software Management Agent Propeller Orchestrator WASI flexibility-defined capabilities By combining the TEE Software Management Agent and Propeller Orchestrator with the Remote Attestation Platform and Key Broker Service—alongside finegrained control over the WASI interface—ELASTIC establishes a robust Confidential Computing environment that ensures end-to-end security, privacy, and runtime integrity, while facilitating adherence to regulatory compliance requirements. Runtime Integrity Regulatory Compliance Platform Heterogeneity WasmHAL-Trust Remote Attestation Platform The Wasm Runtime and WasmHAL-Trust components defined in ELASTIC enhance compatibility across diverse Trusted Execution Environment (TEE) runtimes, abstracting away cloud vendor-specific implementations and enabling greater interoperability. The ELASTIC Verifier Platform enables cross-TEE and cross-cloud attestation evidence validation, fostering interoperability among diverse Trusted Execution Environments and cloud vendor implementations. Vendor Lock-in Mitigation By addressing platform heterogeneity, WasmHAL-Trust and RAP mitigate vendor lock-in challenges inherent to current Confidential Computing implementations, which are often tightly coupled to proprietary cloud-specific architectures. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 98 - August 31, 2025 Migration of legacy Application to the Cloud Reliable Enclave Migration Protocol In addition to ensuring the confidentiality and integrity of data and code during migration through the use of Confidential Computing, this component also guarantees functional reliability throughout the migration process. Continuous security monitoring of operational systems AI-based Intrusion Detection System The AI-based Intrusion Detection System (AI-IDS) enhances observability and monitoring of running applications and their network traffic by enabling realtime threat detection and automated response, ensuring continuous security oversight. These components interact with one another, and while each will be described in detail in the following sections, Table 23 provides a brief functional overview of their interactions: Table 23: Functional Overview and Interactions of Key ELASTIC Components Component Purpose Interactions with other key components WASI flexibility-defined capabilities Fine-grained Wasm API access control Used by TEE Agent, and by AI-IDS for remote traffic capture TEE Software Management Agent Workload lifecycle in TEE Works with Propeller orchestrator, and interacts with RAP and KBS Propeller Orchestrator Workload orchestration Coordinates with TEE Agent WasmHAL-Trust Abstraction for Wasm in TEE Used by workload as abstraction layer Reliable Enclave Migration Protocol Secure and reliable workload migration Used by Propeller orchestrator, TEE agent, RAP and KBS for coordination Remote Attestation Platform (RAP) TEE and application integrity verification Verifies the attestation measurements provided by the TEE Agent, interacts with KBS and TEE agent. Key Broker Service (KBS) Secure Key Provisioning Releases keys post-attestation verification, interacts with RAP and TEE Agent AI-based Intrusion Detection and System (AI-IDS) Real-time threat detection and response Monitors network exchanges with workloads, interacts with orchestrator to inform and trigger actions The section below describes each of the components and how they are planned to be employed in Demonstrator-2. TEE Software Management Agent (UVC) The role of the SMA is the same as for Demonstrator 1. The SMA performs the remote attestation procedure. The goal of remote attestation is to prove to the user of the TEE that the TEE is configured correctly, meaning the TEE is running on the expected hardware and is running the expected software. WasmHAL-Trust (UVC) WasmHAL, as defined in WP3, focuses on portable computing in TEEs, with the goal of enabling WebAssembly applications to run seamlessly across different confidential computing container platforms. WasmHAL provides the foundation for executing portable functions under strict security and privacy requirements. The WasmHAL is designed to support interoperability across a wide range of current and future confidential computing platforms, enabling on- ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 99 - August 31, 2025 demand execution, orchestration, and integration with other ELASTIC frameworks. While the HAL alone cannot deliver full platform-agnostic functionality—for instance, in attestation handling—it represents a critical step toward consistent, secure resource access across diverse environments. Artificial Intelligence Intrusion Detection System (TUC) The AI IDS tool is a hardware-accelerated, AI-driven intrusion detection system for real-time, adaptive traffic monitoring within the ELASTIC framework. It operates under strict data security safeguards to ensure confidentiality, integrity, and controlled access. The system is integrated into Demonstrator 2 with two different deployment modes: (i) cluster-based, with a high-performance FPGA-implemented IDS module enabling parallelised, hardware-efficient pattern matching on cluster servers, and (ii) edge-based, with a compact FPGA IDS module deployed on edge devices detection. In both modes, an AI/ML module uses semi-supervised online learning to dynamically update signatures, improving detection of both known and novel threats. Within the context of Demonstrator 2, the integrated tools ingest live network traffic from the deployed infrastructure, continuously monitor workload flows, and transmit detected intrusion alerts to a centralised visualisation platform, specifically a Grafana dashboard, which aggregates and presents the collected results. The mapped components interface directly with the WASI tool, enabling it to replicate the captured network traffic to the AI Intrusion Detection Prediction System instances. Propeller Orchestrator (AMA) Propeller extends its orchestration capabilities to confidential computing environments in Demonstrator 2. Within TEE-equipped VMs, the Proplet (Propeller’s lightweight orchestration agent) will be deployed inside the enclave to securely retrieve Wasm modules from remote OCI registries and launch them within the trusted execution context. This setup ensures that sensitive workloads are pulled, deployed, and executed entirely within confidential enclaves, maintaining both integrity and confidentiality of the applications and data processed. Reliable Enclave Migration Protocols (AAL) This component provides a mechanism for secure and atomic transfers of responsibility between physically-separate environments. When a key, an application, a piece of data, or other resource is migrated from one environment to another, an attacker can interfere with the migration process, causing the source and destination either to both believe that they are responsible for the resource, or to both believe that the other is responsible. As well as the direct issues that this will cause, it also undermines accountability, since it allows the participants to repudiate their obligations by reference to ephemeral network conditions. It will run within the TEE, provide a WRPC interface that other functionalities will use to securely orchestrate transfers of responsibility, such as finalising the transfer of responsibility of traffic from the private to the public cloud, or the transfer of a key that should be accessible by only a single hardware platform. The source functionality specifies both the destination and a secure identifier for the transfer (e.g. the hash of the data being transferred and its metadata). The migration component will communicate with a similar component in the destination environment, which will seek confirmation from the destination functionality that it wishes to accept the transfer, then run the protocol, providing both source and destination functionalities with a receipt that will verifiably indicate whether source or destination is responsible for the resource. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 100 - August 31, 2025 WASI Flexibly-Defined Capabilities (AAL) This component provides a mechanism for component interfaces (and especially WASI interfaces) to be shimmed by a custom Wasm module that can filter a component's access to the outside world, or provide alternative implementations for functionality that is not accessible by the runtime. The pre-existing WASI Virt tool has a similar goal of virtualising WASI interfaces by creating a component that can be linked to a component to wrap its interfaces. However, this has the limitation of being an additional tool that cannot be applied to already-composed modules. This component will allow the insertion of shims within a larger, possibly already-composed component, and more concretely for Demonstrator 2, it will be used to mirror network traffic to the AI Intrusion Detection System. Remote Attestation Platform (THD) The Remote Attestation Platform (RAP) ensures the trustworthiness of TEEs by performing layered integrity verification across heterogeneous environments. It collects cryptographic measurements from multiple system layers—hardware, firmware, hypervisor, OS, TEE runtime, and application—signed by TEE hardware keys, and compares them against environment-specific golden values. This policy-based appraisal enables accurate trust decisions even when on-premise and cloud stacks differ. Beyond verification, RAP propagates trust by securely communicating attestation results to relying services such as the Key Broker Service (KBS), ensuring that sensitive keys and secrets are only released to verified TEEs. By doing that, it supports the full migration lifecycle: validating the source environment before encryption and transfer, and re-attesting the destination environment post-migration, including verifying workload integrity. RAP also provides audit trails and can trigger remediation actions if attestation fails, maintaining a strong security posture across the demonstrator. Key Broker Service (THD) The KBS is the central service for cryptographic key management and controlled release in the demonstrator. It ensures keys are only provisioned to TEEs that have been positively attested by the RAP. It manages key generation, secure storage, distribution, and revocation under strict policy controls. Keys are released only after verifying RAP attestation and matching the request to the correct context (e.g., workload hash, environment identity), preventing unauthorised access. During migration, KBS releases encryption keys to the on-premise TEE after attestation, enabling secure workload encryption. Post-migration, it provides decryption keys to the cloud TEE only after confirming its integrity and workload consistency. All exchanges occur over secure, authenticated channels, with full logging for compliance and traceability. 4.5 Technical Workflow and Key Technologies Demonstrator 2 showcases the secure migration of the BRT, a sensitive legacy IT application, from an on-premise infrastructure to a public cloud environment, leveraging the ELASTIC technologies. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 101 - August 31, 2025 The workflow is designed to ensure end-to-end security, compliance, and operational continuity, while demonstrating the application of ELASTIC’s key technologies for confidential computing, orchestration, attestation, and monitoring. The technical workflow can be divided into the following main phases: Preparatory Phases (not part of Demonstrator flow) Initial State: • BRT operates on-premise (G), using a traditional deployment. • BRT is used through a Web Access by an Employee (C) Figure 19. BRT 3-tier architecture as deployed today on-premise As illustrated in Figure 19, BRT application is split into an UI (BRT-UI) running in the web browser of an Employee’s device and into three other parts running in an On-Premise Infrastructure (G): a front (BRT-B1), a back (BRT-B2) and a database (BRT-B3). As explained in the Step-by-Step Operational Flow of the scenario description (Section 4.2.2), it is a decision by the IT Team to modernise legacy applications that is triggering the Wasm Recompilation of the BRT application. Preparation: BRT is transformed to a Wasm-based workload, ready for confidential execution. The results of the transformation is looking like the following diagram: Figure 20. BRT 3-tier architecture using Wasm runtime on-premise ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 102 - August 31, 2025 This transformation is not part of the Use case workflow, as such it will not be demonstrated. It consists in keeping the same three-tier architecture and to convert each block in a Wasm payload intended to run on top of the ELASTIC stacks as shown in Figure 20. For that purpose, two ELASTIC components will be actively used: • WASI flexibility-defined capabilities: Used as a tool at compilation time to insert the mirror network traffic shim that will permit redirection of the traffic to the AI-IDS for threat detection. • WasmHAL-Trust: Offering the necessary interfaces to Wasm payload to benefit from TEE services compliant with ELASTIC architecture: ○ Random: used during attestation of the TEE environment ○ Object Storage: used for secure storage of the database used by BRT-B3 ○ Sockets, Event Handling: used by all BRT parts to communicate between each other, to access external services and to serve the BRT services to BRT-UI. Use Case Phases On-premise TEE Execution: Each of the BRT parts running on-premise are executing inside a TEE that is using either Intel TDX or AMD SEV (see Figure 21). Figure 21. BRT 3-tier architecture using ELASTIC stack on-premise In addition to use the two components described above (“WASI flexibility-defined capabilities” and “WasmHAL-Trust”), the following components are also leveraged: • TEE Software Management Agent • Propeller Orchestrator • Remote Attestation Platform (RAP) • Key Broker Service (KBS) • AI-based Intrusion Detection System (AI-IDS) To permit secure execution of the BRT parts inside TEE, the Propeller Orchestrator collaborates closely with the TEE Software Management Agent to ensure that any of them pulled from the IT App Image Registry is instantiated strictly within an attested TEE. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 103 - August 31, 2025 This process is not limited to a simple launch: before execution, the TEE Agent collects cryptographic measurements across multiple layers of the platform stack, including hardware, firmware, hypervisor, operating system, TEE runtime, and the application itself. These measurements are then transmitted to the RAP, which verifies the integrity and authenticity of each layer against predefined golden values. Only after successful attestation by the RAP does the Propeller Orchestrator authorise the workload to run, ensuring that sensitive applications are executed exclusively in environments that have been independently validated as secure and trustworthy. Propeller Orchestrator, as the name suggests, is an orchestrator for WASM workloads across the Cloud-Edge continuum. The worker component of Propeller, or the component that executes WASM workloads, is called the proplet. The central service of the Propeller Orchestrator is a service called the Manager. The Manager provides a set of APIs for task and proplet management, handles task scheduling and execution, and monitors the state of tasks and proplets. Furthermore, once the BRT-B3 (DB) part has been launched inside the attested TEE, it leverages the services of WasmHAL-Trust to securely retrieve and access the encrypted database using the Object Storage and Unseal API. During its execution, the BRT-B3 (BD) will use the Object Storage and Seal API for maintaining the correct state of the DB. To further enhance runtime security, all inbound network exchanges with the BRT application are transparently routed through the AI-IDS. This is achieved by leveraging the WASI flexibility-defined capabilities, which allow the insertion of an interposed shim layer between the BRT workload and the network stack. This shim intercepts incoming network packets and diverts them to the AI IDPS, where advanced AI algorithms—executing on a dedicated FPGA—analyse the traffic in real time for signs of malicious activity or anomalies. To enhance runtime security, all inbound network traffic directed toward the BRT application is transparently routed through the AI-IDS. The on-premise deployment model of the AI-IDS integration is illustrated in Figure 22. Figure 22. BRT 3-tier architecture using ELASTIC stack on-premise with integrated edge-based AI-IDS nodes ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 104 - August 31, 2025 In this architecture, the WASI tool enables the insertion of an interposed shim layer between the BRT workload and the network stack without necessitating modifications to the application logic. The shim intercepts incoming traffic, applies validation rules specified by the WASI tool, and forwards the packets to a cluster-based AI-IDS. Within the cluster, FPGA-accelerated Deep Packet Inspection (DPI) modules perform high-throughput pattern matching, while AI/ML algorithms dynamically analyse traffic features to identify both known and previously unseen threats. The presented solution is designed for on-premise environments providing monitoring capabilities for virtualised infrastructures and leveraging FPGA acceleration to secure largescale, distributed workloads. The deployment model ensures robust, real-time, and scalable intrusion detection across heterogeneous edge environments. Migration: The migration of the BRT application and of its data from an On-premise environment to a Cloud environment is performed using the following steps • Preparation ○ The BRT application, via the WasmHAL-Trust component, retrieves the platform’s attestation evidence, containing cryptographic measurements of the hardware, firmware, OS, TEE runtime, and the BRT application itself. ○ The attestation evidence is sent to the RAP, which verifies the integrity of the environment against predefined golden values. ○ Upon successful attestation, RAP notifies the KBS, which releases the encryption key required to cipher the BRT database. ○ The BRT application uses the key provided by the KBS to encrypt its database within the TEE. This step ensures that sensitive data remains protected during transit. • Migration ○ The Reliable Enclave Migration Protocol is used to orchestrate the secure and atomic transfer of the BRT application and its encrypted database from the onpremise TEE to the cloud TEE. ○ This protocol ensures that only one environment (source or destination) is responsible for the resource at any time, preventing data duplication or loss. ○ Upon arrival, a TEE is initialised and attested, then the BRT application is deployed inside this environment. • Resumption ○ As in the on-premise phase, the BRT application retrieves the platform’s attestation evidence via the WasmHAL-Trust component, which is sent to the RAP for verification. ○ If verification is successful, the KBS is notified to release the decryption key required to decipher the BRT database. ○ The BRT application uses the key to decrypt the database and resumes normal operations in the cloud, maintaining the same security guarantees as on-premise These three steps and the different flows are summarised in the diagram in Figure 23. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 105 - August 31, 2025 Figure 23. Diagram of the migration phase of the BRT application Cloud TEE Execution: Each of the BRT parts running in a public cloud are executing inside a TEE that is using either Intel TDX or AMD SEV. Figure 24. BRT 3-tier architecture using ELASTIC stack deployed in Public Cloud ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 112 - August 31, 2025 • Confidential computing: All Wasm workloads run inside confidential computing environments (TDX/SEV) • Remote attestation: Only trusted, attested cloud environments can execute sensitive workloads; attestation is enforced before any sensitive data or keys are released. • Key management: All key management and access provisioning are handled via a brokered architecture, ensuring encryption keys are only accessible to attested TEEs. • Intrusion detection: The AI-based IDPS detects and reports suspicious activity in the cloud environment. • Secure migration: Enables secure migration of IT services to the public cloud, ensuring data confidentiality and integrity. • Security and compliance: All communication is encrypted and authenticated; sensitive data is protected at rest, in transit, and in use. The infrastructure is designed to comply with GDPR and relevant industry regulations. • Access control: Fine-grained, domain-specific access control policies are enforced for Wasm workloads. • Interoperability and scalability: The platform supports deployment across heterogeneous environments. 4.8 Datasets The dataset involved in Demonstrator 2 is a SQL database used by the BRT application. For the purposes of the demo, the database schema (Figure 26) consists of seven tables, each representing a key aspect of badge management and access control (e.g., Employees, Badges, Locations, Access_Permissions, Badge_History, Access_Log, Admins). The database will be truncated to a minimal set of synthetic records, sufficient to illustrate the operational flow of the BRT application without exposing real or production data: • Type: Relational SQL database (schema provided below in Figure 26 as a Mermaid diagram). • Size: 7 tables, handling data corresponding to a few hundreds of employees and the log activity for a few months. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 113 - August 31, 2025 Figure 26. Database structure of BRT application In the Demonstrator 2, the SQL database is only composed of synthetic data that will still be considered sensitive, as if they were real data, for two main reasons: • Security: The data is modeling access control and badge issuance, which are critical. • GDPR: The schema includes fields that would, in a real deployment, contain personal information (e.g., name, badge IDs, access logs). To address this high sensitivity, the BRT database is considered confidential, and the following measures are enforced: ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 114 - August 31, 2025 • The database is processed exclusively within TEEs, both on-premise and in the cloud, as part of the confidential computing demonstration. • Data at rest is encrypted; data in transit is protected by TLS. • Access to the database is strictly limited to attested, trusted environments, enforced by remote attestation and key broker mechanisms. • The dataset is synthetically generated within the ELASTIC project using scripts and manual input, ensuring that no real-world identifiers or personal data are included. • The dataset is used solely for Demonstrator 2 and may be shared among project partners only for development, integration, and validation purposes. • The data is not intended for publication or reuse outside the project context. • The data is not intended for publication or reuse outside the project. Any further use would require explicit authorisation from the data owner (THD). 4.9 Demonstrator 2 – Minimum Viable Product Description of MVP Scope and Objectives The MVP for Demonstrator 2 aims to showcase the foundational capabilities required for the secure migration of sensitive IT services from on-premises infrastructure to the public cloud as exposed in the previous sections. The MVP focuses on a simplified scenario deployed within the Staging Infrastructure: running the BRT application inside an attested TEE, with at least one of its essential services implemented as a Wasm workload and deployed using Propeller. This service is intentionally designed to divert specific network traffic to the AI-IDS for deep security inspection. This service leverages WasmHAL-Trust to ensure secure and trusted execution.. This intermediary step is designed to validate the core building blocks—attestation, secure workload execution, and integration of key ELASTIC components—before extending to full migration and cloud deployment. Summary of Objectives: • Demonstrate the ability to launch, attest, and execute a Wasm-based IT service used by BRT within an on-premises TEE. • Showcase the integration and readiness of critical ELASTIC components that will be leveraged in the final demonstrator. • Provide early evidence of value and technical feasibility at project M18. Technologies and Components Included in the MVP This section provides an overview of the key technologies and components integrated into the MVP of the ELASTIC platform for Demonstrator 2. Each component listed contributes to the core functionalities of the system. Table 26 below indicates whether each component is included in the MVP at M18 and provides relevant comments where necessary. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 115 - August 31, 2025 Table 26: Overview of ELASTIC Components, Their Purpose, and Inclusion in the Demonstrator 2 MVP Component Purpose In MVP WASI flexibility-defined capabilities Fine-grained wasm API access control Y TEE Software Management Agent Remote Attestation process in TEE Y Propeller Orchestrator Workload orchestration and lifecycle Y WasmHAL-Trust Abstraction for Wasm in TEE Y Reliable Enclave Migration Protocol Secure and reliable workload migration N Remote Attestation Platform (RAP) TEE and application integrity verification N Attestation Service (AS)19 Provides attestation of on-premise TEE, ensuring that only a verified environment can execute the BRT workload Y Key Broker Service (KBS) Secure Key Provisioning N AI-based Intrusion Detection System Real-time threat detection and response Y Limitations and Known Exclusions The MVP is intentionally scoped to demonstrate only the minimal, yet essential, capabilities required for secure workload execution in an attested on-premises TEE. The following limitations and exclusions apply: • No Cloud Migration: The MVP does not include migration to or execution in a public cloud environment. All operations are confined to the on-premises infrastructure. • No KBS: Key management and policy-based key release are not demonstrated at this stage, as KBS integration is planned for the final demonstrator. • Simplified Attestation: The RAP is replaced by a simpler Attestation Service (AS) limited to the attestation of the on-premise TEE. Integration Maturity Status At M18, the MVP demonstrates a functional integration of the selected components, with the following maturity highlights: • TEE Software Management Agent & Propeller Orchestrator: Successfully integrated, enabling automated workload lifecycle management and secure execution of essential security services. • Attestation Service: Operational for on-premises TEE, providing reliable evidence collection and verification. • WASI Capabilities & WasmHAL-Trust: Implemented and validated for with an essential security services of BRT workload, ensuring secure and portable execution. 19 AS is used here instead of RAP, as RAP and KBS will not be fully available at M18. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 116 - August 31, 2025 • AI-based IDS: Connected to the runtime environment, providing real-time anomaly detection and reporting. Value showcased at M18 The MVP is a step forward the final demonstrator allowing to: • De-risk Key Components: Early validation of core security and orchestration mechanisms establishing a robust foundation for implementing the full migration scenario. • Demonstrate Components Readiness: Ensure that key ELASTIC technologies are operational and can be composed to deliver secure, attested Wasm workload execution inside TEE. • Establish a Blueprint for Full Integration: Facilitate the future integration of additional components such as RAP, KBS, Reliable Enclave Migration Protocol. • Support Project Milestones: Deliver tangible proof of progress in the development and integration of ELASTIC technologies, aligning with project objectives and timelines. • Identify Obstacles and Collect Early Feedbacks: Engage stakeholders early to surface potential blockers and gather feedback, guiding the design and integration of the final demonstrator. 4.10 Evaluation Strategy The evaluation strategy for Demonstrator 2 follows the same dual approach defined for Demonstrator 1, combining internal KPI-based validation with external end-user feedback. While the methodology remains consistent across both demonstrators, the focus here is tailored to the specific challenges of migrating sensitive IT services to the cloud. In particular, the KPIs emphasise confidentiality, privacy compliance, secure workload execution, interoperability, and system resilience during migration, while external validation captures usability, trust, and perceived value in operational contexts. 4.10.1 KPIs for Demonstrator 2 The KPIs for Demonstrator 2 also begin with a core set of high-level indicators defined in the GA (Section 1.2.21 of Part B), each aiming to quantify the added value of the ELASTIC framework in enabling secure and privacy-preserving cloud migration of sensitive IT services (D2.1–D2.3). Strategically, these KPIs are designed to capture measurable improvements in areas such as trust establishment, remote attestation efficiency, deployment interoperability, and overall system performance. They reflect ELASTIC’s ambition to transform sensitive data handling and workload migration processes through trusted execution technologies, advanced orchestration, and policy-based governance. Each KPI is linked to a specific performance objective and will be validated by the corresponding technical partners using precise measurement criteria throughout the demonstrator lifecycle. KPI ID D2.1 Title: Enhancing the efficiency of VMs deployment by 50% Definition To enhance the efficiency of the VMs deployment framework by 50% compared to scenarios where ELASTIC is not applied ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 117 - August 31, 2025 KPI ID D2.2 Title: Improving the efficiency the remote attestation handling configuration by 30% Definition To improve the efficiency of the remote attestation handling configuration by 30% in comparison to cases where ELASTIC framework is not utilised KPI ID D2.3 Title: 90% compatibility rate with existing confidential computing infrastructure protocols for the deployment Definition To achieve 90% compatibility rate with existing confidential computing infrastructure protocols for the deployment of ELASTIC VM framework, spanning from cloud environments to edge networks. The second category consists of KPIs derived from the functional and non-functional requirements of Demonstrator 2, as defined during the architecture and use case analysis, and explicitly linked to the KPI framework set out in the Grant Agreement. The Grant Agreement KPIs establish the high-level performance goals for the project (covering operational efficiency, security, privacy, and integration), while the newly defined KPIs translate these goals into measurable, implementation-level indicators that are directly connected to specific requirements within the demonstrator. The definition process began with gathering all functional and non-functional requirements, assigning each a priority level (MUST, SHOULD, MAY), and mapping them to the ELASTIC components and technologies capable of fulfilling them. From this mapping, each requirement was linked to one or more Grant Agreement KPIs to ensure direct traceability between strategic objectives and operational measurements. Each requirement was then translated into a new KPI with a clearly defined metric, target value, and responsible partners. A review process with the relevant component owners confirmed their participation in each KPI and validated or refined the measurement definitions and targets. This process guarantees alignment between the demonstrator’s technical objectives, its implementation scope, and the overarching Grant Agreement KPI structure, ensuring that performance evaluation is both comprehensive and directly tied to the project’s contractual obligations. Table 27 below presents the KPIs identified for Demonstrator 2 through this requirement-driven and GA-linked process, including their measurement definitions, target values, relevance ratings, and associated ELASTIC components and responsible partners. Table 27: KPIs Derived from the Functional and Non-Functional Requirements of Demonstrator 2 KPI ID KPI Name Req.ID Metric Target Value Relevance ELASTIC Components KPI D2.1 D2.1.1 Migration Security D2-FR1 % of migrations with no security issues 100% High Reliable Enclave Migration Protocol D2.1.2 Migration Reliability D2-FR7 % of migrations without interruption or data loss ≥ 99% Medium Reliable Enclave Migration Protocol D2.1.3 Confidential Computing Scalability Efficiency D2NFR1 Max concurrent workloads supported ≥ 100 High Propeller Orchestrator, TEE Software Management Agent ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 118 - August 31, 2025 D2.1.4 Secure Operation Latency D2NFR2 Time for migration protocol completion ≤ 500 ms High Reliable Enclave Migration Protocol D2.1.6 Usability Satisfaction Score D2NFR5 % of users rating interface as usable (survey-based) ≥ 80% Medium Propeller Orchestrator KPI D2.2 D2.2.1 Cloud Attestation Rate D2-FR2 % of executions completing attestation securely 100% High Remote Attestation Platform, TEE Software Management Agent, Propeller Orchestrator D2.2.2 On-premise Attestation Rate D2-FR3 % of executions completing attestation securely 100% High Remote Attestation Platform, TEE Software Management Agent, Propeller Orchestrator D2.2.3 Key Provisioning Success Rate D2-FR4 % of key provisioning operations completed securely 100% High Key Broker Service D2.2.4 On-premise Threat Detection Accuracy D2-FR5 % of accurate detections ≥ 95% Medium AI-based Intrusion Detection System (AIIDS) D2.2.5 Cloud Threat Detection Accuracy D2-FR6 % of accurate detections ≥ 95% Medium AI-based Intrusion Detection System (AIIDS) KPI D2.3 D2.3.2 Policy Enforcement Accuracy D2-FR8 % of correctly enforced policies 100% Medium WASI Flexibilitydefined capabilities D2.3.3 Deployment Portability Score D2-FR10 # of platforms to which WASM workloads deployed without code changes ≥ 3 Medium WasmHAL-Trust D2.3.4 Secure Communication Rate D2NFR3 % of encrypted/authenticated traffic 100% High Key Broker Service, Remote Attestation Platform D2.3.5 Compliance Alignment Score D2NFR4 % of application personal data stored within the EU 100% High TEE Execution Environment, Remote Attestation Platform D2.3.6 Interoperability Coverage D2NFR6 # of supported registries or other Wasm module/component sources ≥ 2 High WasmHAL-Trust, TEE Software Management Agent, Propeller Orchestrator 4.10.2 Evaluation Criteria and Protocols The evaluation of Demonstrator 2 builds on the KPIs defined in the previous section. In the following, the protocols and methods used to measure these KPIs during the execution of the demonstrator are described. For that purpose, a combination of tools, monitoring frameworks and controlled execution environments are used, ensuring that results are consistent, reproducible and aligned with the objectives of the ELASTIC project. ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 119 - August 31, 2025 Below is the list of methods, tools and sources that will be used: • Attestation and cryptographic verification tools 20 (such as signature checks and tools for encryption and decryption of the binary payload) to assess the correctness and robustness of trust mechanisms and remote attestation protocols. • Runtime and migration performance monitoring based on system logs and observability platform to capture key metrics such as success rate and performance of migration, attestation and key provisioning. • Security and Policy validation tools to assess communication security and evaluate enforcement of policies, including automatic penetration tests, static and runtime analysis tools. • Manual and semi-automated procedures to validate interoperability across partner technologies and ensure seamless cloud-to-edge deployment scenarios. • Synthetic test data and controlled demonstrator setups to simulate real operational conditions and stress-test components for resilience and scalability. Each partner involved in Demonstrator 2 will be responsible for selecting and applying the most appropriate validation method for their assigned KPIs, ensuring results are consistent, measurable, and reproducible across the different evaluation stages. 4.10.3 Feedback Collection and Assessment Methodology As with Demonstrator 1, stakeholder feedback will be an essential part of the validation loop for Demonstrator 2. The same suite of techniques will be employed to capture insights from both technical partners and end-users, with adjustments made to fit the specific context of cloud migration and IT/OT integration. Feedback will be gathered through: • Online surveys and structured questionnaires to assess usability, system reliability, and deployment experience. • Feedback forms distributed during workshops and review sessions to gather comments on integration quality, transparency, and perceived trust. • Interactive sessions and demonstrations with stakeholders to solicit real-time impressions and suggestions for improvement. Once collected, feedback will be analysed using both quantitative (e.g., statistical summaries, trend analysis) and qualitative (e.g., thematic analysis of open responses) methods. These insights will be reviewed collaboratively with technical leads and used to guide potential corrective actions or design refinements. 4.10.4 Validation Methodology, Timeline and Execution Plan 4.10.4.1 Validation Methodology The validation of Demonstrator 2 follows the common approach already defined for Demonstrator 1, structured around two complementary dimensions: internal validation via KPIs (quantitative assessment against functional and non-functional requirements) and external 20 One of the attestation tools used can be found at https://github.com/google/go-tdx-guest ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 120 - August 31, 2025 validation via feedback (qualitative assessment by end-users and stakeholders, focusing on usability, trust, and operational relevance). Building on this shared methodology, Demonstrator 2 tailors its validation to the context of secure and privacy-preserving migration of sensitive IT services to the cloud. Internal KPIs focus on aspects such as migration downtime, attestation reliability, encryption coverage, and interoperability, while external feedback captures end-user confidence in confidentiality guarantees, ease of migration, and operational trust. All results will be documented in the upcoming WP5 deliverables, ensuring traceability to requirements and enabling continuous refinement of the demonstrator. 4.10.4.2 Timeline The validation of Demonstrator 2 will follow a phased plan that reflects the incremental integration of ELASTIC technologies and the gradual build-up of the cloud migration and confidential computing capabilities. Each phase is aligned with specific technical milestones, ranging from initial component validation to full deployment in a realistic operational environment. The timeline in Table 28 details the sequence of these phases, highlighting the main validation objectives, key activities, and expected outcomes at each stage. Table 28: Timeline and Execution Plan for Demonstrator 2 Phase Time Description Risks Mitigation Measures Use Case Definition & MVP Implementatio n M13–M18 Finalise the detailed definition of the Demonstrator 2 migration scenarios, security and privacy requirements, and implement the MVP integrating the essential components to enable early functional validation. Misalignment on use case scope; incomplete MVP functionality; integration gaps between early components. Early stakeholder workshops to confirm scope; prioritisation of critical features for MVP; preliminary integration tests. Preparation Mid-project Review MVP M19 Mid-project review of MVP outcomes, validating alignment with Demonstrator 2 objectives, confirming component maturity, and refining integration priorities before detailed testing. Misalignment between MVP results and project objectives; insufficient readiness for next phase. Internal review meeting; stakeholder feedback session; refinement of test plan and integration roadmap. Component Level Testing M20-M22 Validation of individual D2 components (e.g., VM deployment framework, TEE management, migration protocols) using synthetic or anonymized datasets. Incomplete features; incompatibility between tools; unclear performance baselines. Early agreement on validation metrics; use of reference datasets; close partner coordination. Attestation Component M20-M22 Development and validation of the Mismatch with WasmHAL API Early identification before integration phase ELASTIC D5.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 121 - August 31, 2025 Attestation service (HAL + RAP) Initial Integration & Secure Workflow Validation (staging) M22-M24 Integration of key components in a controlled environment to validate secure data flows, VM instantiation, and attestation workflows. Interface mismatches; incomplete security enforcement; latency bottlenecks. Shared API specifications; incremental integration; prevalidation of security modules. Key Broker Service Component M22-M24 Development and validation of the KBS No possible in masked time Early definition of KBS APIs and integration points; incremental testing with attestation and migration components; security review of design and implementation. End-to-End Migration Scenarios (Staging) M25-M26 Execution of full migration workflows from on-premise to cloud environments, including security, privacy, and resilience tests in a lab/testbed. Downtime exceeding thresholds; partial migration; failure recovery gaps Missing alignment with D5.2 deliverable Simulated stress tests; redundancy mechanisms; phased migration rehearsal. “Pilot” Operation and Feedback Loop (Staging) M27-M30 Development of tools and deployment of methodology to collect feedback and perform assessment on migration simulated on Staging. Validation by stakeholders and externals Data gaps in long-term monitoring Continuous monitoring dashboards; periodic stakeholder review sessions; proactive issue tracking. Initial Integration & Secure Workflow Validation (THD) M27-M30 Integration of key components in a THD environment to validate secure data flows, VM instantiation, and attestation workflows. Incompatibility with Cloud Service constraints Identify early incompatibilities for remediation during integration in staging environment End-to-End Migration Scenarios (THD/Staging) M31-M33 Execution of full migration workflows from on-premise to cloud environments, including security, privacy, and resilience from Staging (onpremise) to THD (cloud) Downtime exceeding thresholds; partial migration; failure recovery gaps Simulated stress tests; redundancy mechanisms; phased migration rehearsal. “Pilot” Operation and Feedback Loop (THD/Staging) M34-M36 Re-use tools and methodology employed on staging Validation by Data gaps in long-term monitoring Continuous monitoring dashboards; periodic stakeholder review sessions; proactive issue tracking.