Three Key Challenges Facing Automotive Software Developers in 2026

03 Nov, 2026

Key takeaway

Automotive software development is shifting from managing individual systems to managing complex, interconnected platforms where safety, security and software architecture decisions must be considered together from the outset.

The automotive industry is undergoing a fundamental shift from hardware-centric vehicle designs to Software Defined Vehicles (SDVs), where functionality, performance and even safety capabilities are delivered through software. Unlike traditional vehicles, where functionality was largely tied to dedicated hardware, SDVs rely on centralized compute platforms, over-the-air updates and modular software architectures. While these approaches provide greater flexibility, scalability and feature innovation, they also introduce new challenges around system integration, real-time performance, functional safety and cybersecurity. Developers must also ensure software remains reliable, maintainable and supportable throughout a vehicle’s long operational life.

Here are three key challenges shaping automotive software development in 2026.

Challenge 1: Meeting functional safety requirements in complex systems

Functional safety remains a fundamental requirement throughout the development lifecycle, but meeting safety objectives is becoming more challenging as automotive software grows in scale and complexity. While traditional safety functions often relied on dedicated systems performing a specific task, modern ADAS features may combine data from multiple cameras, radar and LiDAR sensors to identify hazards and trigger actions such as autonomous emergency braking. These interconnected systems generate more software, more interfaces and more potential failure modes, significantly increasing the burden of verification, validation and safety assurance.

ISO 26262 provides the primary framework for functional safety in automotive systems, defining a risk-based approach to identifying hazards, assessing risks and implementing appropriate safety measures. A key component of the standard is the use of Automotive Safety Integrity Levels (ASILs), which determine the level of rigour required during development, verification and validation activities. Higher ASIL classifications require greater evidence, testing and safety mechanisms to demonstrate that applicable safety requirements have been met.

As a result, development teams face increased engineering effort, as meeting these requirements involves extensive verification, documentation and traceability throughout the development lifecycle. Safety-certified software components, supported by certification artefacts and technical documentation, can help reduce the engineering effort involved in demonstrating compliance, while the complete system must still satisfy its own applicable safety requirements.

Challenge 2: Addressing automotive cybersecurity threats

Cybersecurity has become a critical consideration for automotive software developers, especially in relation to SDV on board systems. Connectivity, cloud services, mobile applications and over-the-air (OTA) updates create new opportunities for innovation, but they also expand the potential attack surface and introduce new security risks.

To help manage these risks, the automotive industry has adopted standards such as ISO/SAE 21434, which promotes a structured approach to cybersecurity risk management throughout the vehicle lifecycle. A key element of this approach is Threat Analysis and Risk Assessment (TARA), which helps organisations identify critical assets, evaluate potential threat scenarios and attack paths, assess cybersecurity risks, and establish appropriate security goals and controls. The wider regulatory landscape is also evolving, with legislation such as the EU Cyber Resilience Act (CRA) placing increased emphasis on cybersecurity, vulnerability management and supply chain assurance across digital products and services.

As a result, organisations should adopt a secure-by-design approach, integrating security considerations into software architecture, development processes and lifecycle management activities from the outset.

Challenge 3: Adapting to Software-Defined Vehicle architectures

As we have seen, SDVs are transforming the automotive landscape, introducing greater connectivity and complexity while fundamentally reshaping how vehicle software architectures are designed, integrated and maintained.

Traditional vehicle designs based on numerous dedicated electronic control units (ECUs) are giving way to more integrated approaches, including centralised compute and zonal architectures, designed to manage software workloads more efficiently.

Industry frameworks such as AUTOSAR have played an important role in supporting software integration, standardisation and reuse across automotive platforms. However, with the rise of SDVs and zonal architectures, developers must determine how best to balance standardisation and software reuse with the flexibility, portability and scalability required for future vehicle programmes.

For engineers, this shift creates new challenges. Software must be deployed across shared computing platforms while maintaining predictable performance, safety isolation and long-term maintainability. Components must also be reusable across multiple vehicle programmes and hardware platforms to support efficient development and lifecycle management.

To address these challenges, automotive developers are exploring architectural approaches that help separate safety-critical functions from rapidly evolving application software. One example is the use of a safety island. Discover how in our latest white paper: Safety Islands: Enabling Safe Software-Defined Vehicles. The safety island is not a substitute for a complete ISO 26262 safety process, but it can provide a useful architectural boundary for partitioning safety responsibilities and limiting the impact of change.

This approach is particularly relevant where high-performance central compute runs complex or frequently updated software, while a smaller safety-oriented environment retains responsibility for monitoring and recovery.

Conclusion

Challenges rarely exist in isolation. Architectural decisions directly affect how cybersecurity controls are implemented, while both architecture and cybersecurity influence the effort required to demonstrate functional safety. As SDVs continue to evolve, developers must make decisions that balance all three disciplines simultaneously.

Success depends on managing software as a long-term asset, with vehicles requiring ongoing maintenance, security updates and feature enhancements long after production has ended. While SDV architectures offer opportunities for greater scalability, flexibility and software reuse, they also increase the importance of isolation, deterministic execution and clearly defined safety responsibilities.

In Issues Facing Automotive Software Developers, you’ll learn:

How ISO 26262, ISO/SAE 21434 and the CRA influence modern software development
Why safety and cybersecurity can no longer be treated separately
How SDV architectures are changing software integration and lifecycle management
The role of safety islands in centralised compute architectures
Key considerations for reusable and pre-certified software platforms

Download the white paper to explore these challenges in greater depth.

Author

Emiliano Costagli, Product Manager

Back to News