Autonomous systems are a key technology for future-oriented mobility and industry. Yet their greatest strength—intelligent connectivity—is also their greatest vulnerability. In a world where software determines physical safety, security and safety mustbe considered together from the very beginning and be seamlessly integrated. In this blog post, we explore why the traditional separation between functional safety and IT security in software development poses a critical risk today. Learn why modern standards such as VDE AR 28461 emphasize holistic trustworthiness and how model-based safety and security co-engineering helps to efficiently and legally compliantly meet complex requirements. We’ll show you how to bridge the gap between regulatory requirements and technical implementation to make your systems robust for the future.
Imagine an autonomous shuttle safely transporting passengers through the city center. The sensors work perfectly; the algorithms detect every obstacle. The safety (functional safety) is certified according to all state-of-the-art standards. But what happens if an attacker gains access to the steering system via a maintenance interface? At that moment, a cybersecurity problem immediately becomes a deadly threat to life and limb.
For a long time, engineers were able to treat safety and security as separate disciplines. There was expertise for functional safety and for cybersecurity. However, with the growing interconnectivity of autonomous systems, these boundaries are blurring.
Safety and Security in the Context of Autonomous Systems
Before we delve deeply into methodological integration, it is important to briefly examine the traditional way of thinking:
-
Safety (also operational safety or functional safety)
In this article, we define safety as functional safety—that is, the protection of people and the environment from hazards that may arise from the system.
-
Security (also cybersecurity or information security)
Security refers to the protection of the system and its data against malicious manipulation and unauthorized access.
> You can find a detailed introduction to the terms safety and security on our “Security” trends page.
The New Reality
In autonomous systems, security is no longer purely an “IT issue.” It is an integral part of functional safety. Anyone developing autonomous systems today must no longer plan safety and security separately, but must understand them as interlinked quality requirements.
A system can no longer be “safe” unless it is simultaneously highly “secure” against external attacks.
Why the separation of safety and security no longer works today
Many companies still adhere to a strict separation of safety and security in their development processes. The reasons for this are often historical or organizational, but in practice, these conventional models have long since fallen short. At the AI Standardization Conference of the Federal Network Agency (December 2025), it became clear that significant uncertainty still prevails: How can a genuine methodological integration of safety and security be achieved? A look at the scientific literature reveals why the old guidelines no longer hold up.
Protection objectives are no longer clearly distinguishable
In scientific models such as Laprie’s taxonomy [1][2] , safety and security are clearly defined as distinct concepts. Safety is viewed, like confidentiality, integrity, and availability, as a distinct attribute of reliability, while security is seen as the combination of confidentiality, integrity, and availability. In the practice of modern, networked systems, however, this distinction becomes blurred. In security engineering today, we consider all consequences of an attack—including personal injury.
Example: For example, if a hacker manipulates a truck’s braking system, the target of the attack is technical in nature, but the consequence is a classic safety event (personal injury). Thus, a distinction based solely on the protection objective no longer works in practice.
Causes of security problems are converging
Laprie also distinguishes between “malicious faults” (intentional manipulations) and “non-malicious faults.” In traditional software development, “security for safety” was therefore often reduced to excluding malicious attacks, such as hacker attacks, as causes of safety problems. This isolated view falls short. Modern security engineering has long since taken into account non-malicious causes as well, such as natural disasters that can have physical effects on data centers or communication infrastructure.
Example: In an adversarial attack, the causes ultimately merge. If an attacker manipulates a stop sign using minimal stickers barely visible to humans so that the AI misinterprets it as a speed limit, the cause is malicious (security). The effect, such as the vehicle failing to brake, is, however, a classic safety failure.
System boundaries dissolve
Similarly, Laprie’s taxonomy distinguishes between internal and external errors. When it comes to security, many people initially think of “external errors” and the idea that the environment should not have any negative impact on the system. In safety, the focus has traditionally been on ensuring that the system does not cause personal injury. “Security for safety” is therefore often interpreted to mean that no harmful influence from the environment on the system should lead to a safety problem. In the practice of connected, autonomous systems, however, this distinction is no longer clear-cut. Safety engineering certainly takes external errors into account.
Example: Today, networked autonomous systems operate within a “system of systems.” They continuously receive information from external sources, such as cloud services or infrastructure data. As a result, the boundaries of the system become blurred, both physically and digitally. An autonomous vehicle must reliably detect pedestrians even under difficult visibility conditions or when they are wearing unusual clothing in order to operate safely. If a pedestrian is not detected due to distinctive clothing, this constitutes a classic safety engineering challenge. This example illustrates that the environment is critical for both safety and security. In modern, AI-based systems, it is virtually impossible to consider sources of error in isolation along rigid system boundaries.
The Gap in Conventional Engineering
The examples above show that safety and security can no longer be clearly separated in modern systems from a technical standpoint. Nevertheless, established processes and standards are still mostly organized along these old lines of separation. This leads to a safety-critical gap in engineering.
Why Security Engineering Alone Is Not Enough
At first glance, it seems reasonable to assume that consistently applied security engineering could suffice for safety. Security can consider safety as one of several protection goals while keeping all causes in view—not only malicious ones, but also accidental or external errors.
This is precisely where a dangerous fallacy lies:
- Safety Engineering defines how measures are selected based on risk and implemented in a verifiable manner.
- This approach is defined in safety standardsbased on the ISO/IEC Guide 51 , which are regulated in detail
(e.g., hazard analysis, risk assessment, safety functions, verification).
Security engineering cannot simply replace this structured, risk-based approach. It complements safety, but it does not render traditional safety engineering obsolete.
Why conventional safety engineering is no longer sufficient
Conversely, however, conventional safety engineering is no longer sufficient to meet today’s challenges.
It currently has two key gaps:
- The selection of measures against malicious errors that no longer fall within the scope of foreseeable misuse.
- The selection of measures against errors in safety-relevant AI components.
Security engineering plays a crucial role in closing these gaps. It has a strong focus on malicious errors and makes it clear that attacks such as backdoor attacks must also be considered as potential causes of errors in AI components. Only when this perspective is systematically integrated into safety engineering will a foundation be established for truly robust safety in modern, autonomous systems.
Safety Engineering alone: too blind to malicious and AI-specific errors.
Security Engineering alone: does not provide a complete, standards-compliant safety argument.
The logical consequence: Trustworthiness as a holistic goal
In addition to norms and technical standards, legal regulations and liability issues are increasingly coming into focus. European initiatives such as the AI Act or the Cyber Resilience Act are tightening requirements for manufacturers and operators. They must not only demonstrate that their products were developed safely, but also that risks are appropriately managed and documented throughout the entire lifecycle.
An integrative perspective on reliability and trustworthiness
The preceding discussion makes it clear that safety and security cannot be considered in isolation. However, measures to increase safety have an impact on other quality attributes. An emergency shutdown, for example, increases personal safety but has a negative effect on system availability.
In railway technology, this relationship has been taken into account for quite some time.
The EN 50126 standard considers the four RAMS properties together:
- Reliability
- Availability
- Maintainability
- Safety
This framework is no longer sufficient for autonomous and cognitive systems. The Application Rule VDE AR 28461 extends the RAMS scope of EN 50126 to include additional quality attributes such as privacy. At the same time, it considers various types of errors as causes, thereby adopting an integrative perspective in which safety and security are no longer treated separately. VDE AR 28461 thus considers not only the reliability of a system, but its overall trustworthiness. This encompasses technical, organizational, and normative aspects and provides a holistic reference framework for modern autonomous systems.
The following figure outlines this holistic perspective on trustworthiness:
Applied research plays an important role in the development of this integrative perspective. Fraunhofer IESE contributes its experience from industrial projects to standardization work, thereby supporting the development of standards such as VDE AR 28461. In this way, practical insights from specific safety and security applications are directly incorporated into the definition of trustworthiness in autonomous systems.
The Standards Jungle: An Overview of Safety and Security Standards
With its integrative perspective on safety and security, VDE AR 28461 has so far been the exception rather than the rule. In many application areas, separate standards for functional safety and cybersecurity still exist. This makes integration challenging in practice, especially for companies operating in multiple industries.
| Industry | Safety Standard | Security Standard |
|---|---|---|
| Automotive | ISO 26262, ISO/TS 5083 | ISO/SAE 21434 |
| Agriculture | ISO 25119 | ISO 24882 |
| Industry | IEC 61508, ISO 13849 | IEC 62443 |
In the field of Automotive the ISO 26262 provides the basis for functional safety, and ISO/SAE 21434 provides the basis for protection against cyberattacks. ISO/TS 5083 addresses safety in automated driving and takes security aspects into account in this context.
In agricultural machinery , the ISO 25119 for functional safety and the ISO 24882 for protection against cyberattacks.
In industrial automation , the IEC 61508 and the ISO 13849 form the basis for functional safety, and the IEC 62443 form the basis for cybersecurity.
There are many other application areas with specific standards for safety and security. Many of the application-specific standards for functional safety are derived from IEC 61508. Accordingly, this standard is of particular importance. IEC 62443 also has a fairly broad scope of application, as it covers all industrial sectors and critical infrastructure (KRITIS).
To bring these two worlds together, the joint DKE/GAK 931.1.3 working group “Functional and IT Safety” is working on the interface between IEC 61508 and IEC 62443. It analyzes differences and similarities, particularly in the lifecycle, and identifies shortcomings in IEC 62443 from the perspective of functional safety. These findings, in turn, are incorporated into the further development of the standards.
The Solution: Model-Based Safety and Security Co-Engineering
Model-based safety and security co-engineering offers an effective solution for integrating safety and security in practice. In systems and software engineering, various aspects of product development are integrated through collaborative work on a single model. This provides the various stakeholders with an appropriate view of the model. However, conventional tools do not provide safety and security views. For example, the modeling tool Enterprise Architect does not offer safety engineers a view to model fault propagation through the system.
Basic Concept of Model-Based Safety and Security Co-Engineering
- Model-based safety and security co-engineering specifically extends existing model-based product development to include safety and security views.
- Safety engineers see relevant product development aspects as well as relevant security aspects in their view.
- Security engineers see relevant product development aspects as well as relevant safety aspects in their view.
- The shared underlying model integrates all aspects in a consistent manner.
- Inconsistencies are constructively avoided or automatically identified and resolved with the help of the engineers.
- The model-based formalization of safety and security aspects enables not only automatic consistency checks but also extensive automation support for performing safety and security analyses.
An integrated, model-based approach also lays the foundation for systematically addressing safety requirements not only during development but also during operation and maintenance. This applies, for example, to the planning of monitoring and update processes as well as the handling of safety incidents in field operations.
The tool SafeTbox from Fraunhofer IESE offers a range of proven automation solutions for the points mentioned above. Fraunhofer IESE is currently conducting research to further increase the automation potential through generative AI and is contributing to relevant standards in this field.
Where does your company stand in terms of integrated safety and security engineering?
Whether you’re facing shortages of skilled personnel, new AI capabilities, or increasing regulatory pressure—we support you from the initial analysis through to model-based implementation with SafeTbox.
Whether in the automotive and commercial vehicle sector or in other safety-critical domains—we guide you through the implementation process. Further information on our activities in the field of Automotive & Commercial Vehicles can be found here.
Schedule a no-obligation consultation with our experts at Fraunhofer IESE and explore how you can make your systems future-proof in an efficient and standards-compliant manner.
Contact us now!
References
[1] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” in IEEE Transactions on Dependable and Secure Computing, vol. 1, no. 1, pp. 11–33, Jan.–March 2004, doi: 10.1109/TDSC.2004.2.
