Europe’s technological competitiveness will depend not only on semiconductors, artificial intelligence, and computing capacity, but on the ability to engineer embedded platforms in the most critical industries that remain secure, safe, and maintainable throughout long operational lifecycles.
Europe’s digital transformation and the evolving regulatory landscape
Europe’s technological strategy is increasingly focused on strategic capabilities such as semiconductor manufacturing, artificial intelligence, high-performance computing, advanced connectivity, and secure digital infrastructure. Initiatives such as the European Chips Act, together with the AI Act, and the Cyber Resilience Act, reflect a broader ambition to strengthen Europe’s technological autonomy and the resilience of its industrial base. Yet access to advanced technologies does not automatically translate into dependable industrial systems. A
processor, AI accelerator, or software framework creates value only when it can be integrated into a system that behaves predictably, protects critical assets, and remains maintainable over time. This is particularly important in automotive, aerospace, railway, medical technology, and industrial automation, where products may remain operational for ten, twenty, or even thirty years, far beyond the commercial lifecycle of many software components.
At the same time, European regulation is bringing cybersecurity and lifecycle responsibility closer to the center of product engineering. The Cyber Resilience Act introduces cybersecurity requirements covering the design, development, production, and maintenance of products with digital elements. The AI Act establishes a risk-based framework for artificial intelligence, while sector-specific standards continue to address functional safety, cybersecurity, and software assurance. The engineering effort is therefore changing. Manufacturers can no longer consider only whether a product satisfies its functional requirements when it is released. They must also consider whether the system can preserve its security, predictability, and operational integrity as vulnerabilities are discovered, software is updated, suppliers discontinue components, and new functions are introduced.
This makes software architecture increasingly strategic. Architecture determines where trust boundaries are placed, how failures are contained, how critical workloads are separated, and which components can evolve independently. It influences whether a vulnerability remains limited to a single subsystem or affects the entire platform, and whether a new function
can be introduced without destabilizing existing safety or security assumptions. Regulations define objectives and standards provide engineering frameworks. But the ability to create trustworthy embedded systems ultimately depends on architectural decisions made from the beginning.
Europe’s digital ambitions require more than technological innovation
Technological sovereignty is often associated with control over strategic technologies: processors, semiconductor manufacturing, communication infrastructure, cloud platforms, and AI models. For industrial Europe, however, sovereignty must also include the ability to integrate, operate, maintain, and evolve complex systems without becoming excessively dependent on opaque architectures, unsupported components or inaccessible engineering knowledge. Access to strategically important hardware does not by itself guarantee technological control over the complete system. An embedded platform also depends on development tools, in-house and third- party tightly coupled software components, or external services whose evolution and long-term support remain outside the system manufacturer’s direct control. Architecture can limit some of these dependencies.
Stable interfaces, controlled software dependencies, and clearly separated functional domains can make individual technologies easier to replace without redesigning the entire system. This does not eliminate supply-chain risk, but it makes dependencies more visible and manageable. Modern embedded products typically combine software from several sources:
operating systems, middleware, protocol stacks, open-source libraries, security components, diagnostic tools, and application software from specialised suppliers. Each of these dependencies introduces assumptions concerning performance, timing, update availability, licensing, vulnerability management, and long-term support.
Technological sovereignty should therefore include the capacity to understand and control the entire systems created as a composition of components, system of systems. This requires investment not only in hardware and computing infrastructure, but also in software architecture, verification, lifecycle engineering, and the technical expertise required to maintain complex systems over time. These capabilities may be less visible than semiconductor fabs or AI supercomputers, but they determine whether technological investment can ultimately
become dependable industrial infrastructure.
The growing complexity of modern embedded systems
The traditional embedded system was often designed around a relatively fixed set of functions. Software was closely coupled to hardware, connectivity was limited and substantial changes after deployment were uncommon. This model is rapidly changing. Embedded platforms are becoming connected, consolidated, and software- defined. Functions previously implemented on separate electronic control units are moving onto multicore processors and systems- on-chips. Cloud connectivity extends the system boundary beyond the device itself. AI workloads are increasingly executed at the edge, while software updates continue throughout the operational lifecycle
These changes offer significant advantages, including hardware consolidation, improved diagnostics, remote maintenance, and faster functional evolution. However, they also create new forms of complexity. A safety-related control application may share processors, memory bandwidth, network interfaces or accelerators with less critical software. Diagnostic services may require privileged access to several subsystems. Update mechanisms become part of the security perimeter. AI applications may depend on external frameworks and data pipelines that evolve independently of the underlying device. This creates several engineering challenges for ensuring high levels of safety, security, and time- predictability.
Failures can propagate across domains that were previously physically separated. Consolidating workloads onto a common computing platform may reduce hardware complexity while making isolation significantly more important. Furthermore, predictable execution depends on more than the operating system. A real-time task may be scheduled correctly and still miss its deadline because another workload saturates memory bandwidth or a shared hardware resource.
In addition, software with different levels of criticality and assurance increasingly needs to coexist. A safety-related control function may operate alongside an open-source networking stack, a graphical interface, and an AI inference engine. At the design phase, treating all these components as though they had identical security, safety, and lifecycle requirements is unsustainable. This is one reason mixed-criticality architectures are receiving increasing attention. They allow workloads to be separated according to their timing, safety, security, and assurance requirements while sharing a common computing platform.
The automotive industry provides an obvious example. Central computing architectures increasingly combine vehicle control, connectivity, infotainment, and advanced driver-assistance functions. Functional safety requirements defined through frameworks such as ISO 26262 coexist with cybersecurity engineering requirements such as ISO/SAE 21434. Comparable challenges exist in industrial automation, aerospace, railway systems, and medical devices. Complexity, in this context, is not simply the number of lines of code. It is the number of
software components and their interactions, dependencies, and potential failure paths that engineers must understand and control. Working at the software architectural design level is becoming a de-facto solution to better control these aspects.
Software architecture as the foundation of trustworthy embedded systems
Trustworthiness does not mean assuming that a system will never fail. Faults, vulnerabilities, and unexpected conditions cannot be eliminated completely. Instead, trustworthy architecture aims to ensure that critical properties remain understandable and defensible when failures occur, software changes or attacks are attempted. Indeed, one of its fundamental principles is the definition of explicit trust boundaries. Every system contains components that must behave correctly for its critical properties to hold. These form its trusted computing
base. The larger and more complex this trusted base becomes, the greater the number of components whose failure or compromise may affect the entire system. Reducing unnecessary privilege is therefore fundamental.
Memory protection, privilege separation, controlled interfaces, and least-privilege access can limit the impact of compromised or malfunctioning software. Hardware mechanisms such as virtualization, memory management units and controller I/O units provide useful building blocks, but they become effective only within a coherent architectural design. Spatial isolation prevents one workload from accessing memory, devices or data assigned to another. Temporal isolation aims to prevent one application from consuming resources in a way that compromises the timing requirements of another. Both are important in mixed-criticality environments.
Virtualization technology can provide mechanisms for partitioning workloads, if properly configured. The strength of the architecture also depends on shared resources, interrupt handling, memory behaviour, and the size and complexity of the privileged software layer. The same distinction applies to containers. Containers can provide useful software separation and deployment flexibility, but they generally share a common kernel and should not automatically be considered equivalent to stronger hardware-assisted partitioning.
In addition to the isolation, many software components with different criticality levels may communicate with each other to cooperate in accomplishing the same mission. As such, communication between domains must also be carefully controlled. Interfaces should be explicit, narrow, and independently testable. Data formats, access permissions, timing expectations, and failure behaviour should be treated as architectural properties. This limits the paths through which faults or attacks can propagate, also improving maintainability. Components connected through stable interfaces are generally easier to replace or update without affecting the entire system.
Once the software design is defined and developed, guaranteeing its integrity, and sometimes also its confidentiality, every time the device is powered on is crucial to ensure its properties and protect its assets. Secure boot, protected key storage, and device identity mechanisms can establish confidence in the software executing on a device. In distributed systems, attestation mechanisms may also be used to provide evidence about platform state. These mechanisms, however, are only parts of a broader security architecture. A correctly signed software image can still contain vulnerabilities, while weak key management can undermine otherwise strong cryptographic mechanisms. As such, software updates play a crucial role in the entire lifecycle of the device.
Connected embedded systems increasingly require security updates throughout their operational life. Update mechanisms must verify authenticity and integrity, handle interrupted installation and provide reliable recovery mechanisms. In critical environments, deployment may also require compatibility checks, staged roll-out, and operational approval. Being able to distribute an update is not the same as being able to activate it safely.
Furthermore, one important aspect is related to the software supply-chain visibility and controllability. Modern systems inevitably rely on open-source packages, third-party libraries, and externally developed firmware. Maintaining an accurate software bill of materials (SBOM) can help manufacturers identify components affected by newly disclosed vulnerabilities. Yet an SBOM is not itself a security assessment. Knowing that a vulnerable library exists in a product does not automatically determine whether that vulnerability is exploitable in the specific
system architecture. Effective vulnerability management therefore depends on both software visibility and architectural understanding, that typically requires threat analysis and risk assessments at the design phase.
From regulatory compliance to engineering trustworthiness
European regulation is increasingly reinforcing a principle already familiar to experienced engineering organisations: cybersecurity cannot effectively be added at the end of product development. The Cyber Resilience Act introduces cybersecurity and vulnerability-handling obligations for products with digital elements throughout their lifecycle. Its reporting obligations start to become applicable in September 2026, while the broader set of requirements applies from December 2027. However, for manufacturers of long-lived embedded products, the architectural implications begin much earlier.
A system being designed today may still be operational in the 2040s. Decisions concerning update mechanisms, component traceability, cryptographic technologies, and software isolation therefore need to anticipate future maintenance requirements. As such, component selection itself becomes a lifecycle decision. Performance, purchase cost, and development effort remain important, but manufacturers must increasingly consider the availability of security updates, supplier vulnerability- management processes, and the possibility of replacing technologies whose support ends before the product itself reaches end of life.
In addition, the AI Act introduces other architectural challenges. As artificial intelligence becomes increasingly embedded within industrial and cyber-physical systems, engineers must manage the relationship between probabilistic AI components, and conventional deterministic software. An AI model used for perception, anomaly detection, or decision support may not
behave in exactly the same way as traditional control software. This does not prevent its use in critical environments, but architecture must define its authority and its limits. An AI function may, for example, operate behind an independently designed monitoring mechanism, remain advisory rather than directly controlling an actuator, or be constrained by deterministic safety functions.
Functional safety, cybersecurity, and AI governance are separate disciplines with different objectives and evidence requirements, but they interact inside the same system. Architecture provides a common technical model through which these interactions can be understood and controlled. It identifies assets, trust relationships, communication paths, critical functions, and update boundaries. In doing so, it connects regulatory requirements to concrete engineering decisions. Compliance should therefore be seen as evidence that appropriate system properties have been applied and achieved, rather than as the primary purpose of engineering. A platform designed mainly to pass an assessment can still be fragile. A platform built around explicit boundaries, controlled dependencies, and predictable behaviour is more likely to remain trustworthy as both technology and regulation evolve.
Building embedded systems that remain trustworthy over decades
One of the most difficult challenges for embedded systems is the mismatch between industrial lifecycles and digital technology lifecycles. Industrial machinery, railway infrastructure, aircraft, or medical equipment can remain operational for decades. The technologies on which they depend, however, often evolve on much shorter commercial and support cycles. Semiconductor components may become difficult to source, while operating systems, development tools, and software libraries may no longer receive maintenance or security updates.
Architecture cannot eliminate this lifecycle mismatch, but it can reduce its impact by making critical dependencies easier to identify, isolate and, where necessary, replace. Hardware abstraction layers, stable interfaces, and portable application environments can reduce unnecessary dependencies on specific technologies. Abstraction should not become an objective in itself. Excessive abstraction can reduce performance and complicate timing analysis. The goal is to create flexibility where future change is likely while preserving predictability
where hardware-specific behaviour is essential. Long-term maintainability also depends on preserving engineering knowledge.
Architectural decisions, security assumptions, timing requirements, and critical interfaces must remain understandable after the original development team has moved on. Configuration, build environments, and test evidence should remain reproducible wherever possible. Furthermore, a trustworthy architecture should also enable controlled evolution. Partitioning may allow a non-critical analytics application to be updated while a critical control function remains unchanged, provided that isolation mechanisms and interfaces remain valid. This does not automatically eliminate the need for impact analysis or recertification. It can, however, reduce the scope of change and make long- term evolution more manageable.
Cryptographic agility is another important consideration. Algorithms and security assumptions considered adequate today may become obsolete during the lifetime of a long-lived industrial platform. The ability to replace cryptographic mechanisms without redesigning the complete system is therefore an architectural advantage. Lifecycle engineering should also address system decommissioning. Embedded devices may retain cryptographic keys, credentials, configuration data, or operational information after they are removed from service. Their architecture should therefore support appropriate end-of-life procedures, including credential revocation, secure data removal, and the controlled disconnection of external services. Considering these requirements early in the design process helps to ensure that security and maintainability can be managed throughout the entire operational lifecycle of the system.
Software architectures as a European competitive differentiator
Europe’s regulatory framework is sometimes described primarily as a constraint on innovation. Cybersecurity, lifecycle support, and functional safety requirements address genuine industrial risks. Connected devices operate in increasingly complex environments, software supply chains continue to expand, and critical products often remain operational long after their original technology has become obsolete. Responding to these challenges only through compliance activities performed late in development can increase costs without correcting fundamental design weaknesses.
An engineering-driven approach starts earlier. It establishes trust boundaries, controls communication, limits unnecessary privilege, separates workloads with different assurance requirements, anticipates updates, and technological change. These principles support not only compliance, but innovation itself. When critical functions are clearly separated, new software can be introduced with less disruption. When interfaces are stable, components can be replaced more easily. When dependencies are visible, supply-chain risks become more manageable.
Europe’s technological competitiveness will therefore depend not only on the processors, AI technologies, and computing infrastructure it develops, but also on the quality of the systems built around them. Software architecture is the level at which technologica innovation becomes dependable industrial capability, and where technological sovereignty becomes something that can be engineered, operated, and sustained.
Key insights
Software architecture contributes directly to technological sovereignty.
Control over strategic technologies has limited value without the ability to integrate, maintain, and replace them.
Mixed-criticality systems require more than
software separation. Timing, memory, I/O, and shared hardware resources must also be considered.
Cybersecurity is a lifecycle responsibility.
Vulnerability management, updates, and software-component visibility need architectural support from the beginning.
Compliance is an outcome of engineering.
Regulations and standards define obligations, but trustworthy behaviour depends on architectural decisions.
Maintainability contributes to safety and security.
Systems that cannot be understood, updated, or migrated become increasingly difficult to defend over time.
Giorgiomaria Cicero
CEO & Co-Founder of Accelerat
Giorgiomaria Cicero is an Embedded Software Engineer, now CEO and Co-Founder of Accelerat, a deep-tech start-up company focused on advanced software solutions for next-generation cyber-physical systems like autonomous vehicles (e.g., automobiles, trains, drones, etc.), advanced robots, and factory automation. Giorgiomaria has an academic research background matured at the ReTiS Laboratory and experience in industrial R&D projects in real-time systems, virtualization technologies, and cyber-security solutions for modern heterogeneous embedded platforms.
About Accelerat
Accelerat is an Italian deep-tech company developing software technologies for safe, secure, and predictable cyber-physical systems. Its portfolio includes CLARE, a hypervisor-centric software stack, and the Bunkers family of secure edge-computing solutions through on-chip zero-trust architecture.