-
2026 State of Automotive Software Development Report
- Chapter 1 - What Are the Top Market Challenges Impacting Automotive Software Development?
- Chapter 2 - The Leading Concerns in Automotive Software and Technology Development
- Chapter 3 - Areas of Automotive Software Development
- Chapter 4 - Adoption & Implementation of Shift-Left
- Chapter 5 - Recalls and Software Vulnerabilities
- Chapter 6 - Automotive Software Security
- Chapter 7 - How Are Software-Defined Vehicles (SDVs) Affecting Developers?
- Chapter 8 - Leading Trends in Automotive AI
- Chapter 9 - Why Standards Compliance Remains Vital for Automotive Development
- Chapter 10 - Key Coding Standards for Automotive Software Development
- Chapter 11 - How Development Teams Manage Their Work
- Chapter 12 - Which Software Tools Development Teams Are Using
- Chapter 13 - Open-Source Automotive Software
- Chapter 14 - Why Perforce Software Solutions Remain Essential for Automotive Software Development
- About the Survey — Appendix
Report > 2026 State of Automotive Software Development Report
Chapter 9 - Why Standards Compliance Remains Vital for Automotive Development
The Automotive Industry Remains Highly Regulated
All vehicle components — regardless of whether they are for autonomous, semi-autonomous, electric, connected, or traditional vehicles — have safety and security requirements, but the level of coverage varies depending on the functionality of the component. However, for all levels, ensuring that software is compliant with key industry coding standards and guidelines is an essential part of the automotive software development process for all types of vehicles.
ISO 26262 Is Still Key
ISO 26262 is a key functional safety standard for the automotive industry. A majority of those we surveyed are still required to comply with ISO 26262. For further context, while most regions are required to meet ISO 26262 compliance, suppliers had a higher requirement compared to manufacturers, and respondents with the less experience either had less knowledge about ISO 26262 requirements or did not need to comply compared to those with more experience.
Why Developers Need to Comply With ISO 26262
For those who need to comply with ISO 26262:
- 32% need to comply due to a market requirement, a decrease of 13% over last year.
- 52% need to comply due to a customer requirement, an increase of 12% over last year.
- 13% have an internal requirement, a slight decrease of 1% over last year.
Organization Type
The type of organization matters for ISO 26262 compliance. Suppliers (Tiers 1-3) had a higher customer requirement to ensure compliance with ISO 26262 because OEMs are their customers, while OEMs had a higher market requirement to comply with the standard.
Region
ISO 26262 compliance is a nearly universal expectation, yet the reasoning for compliance with it differs. For example, most regions’ respondents cited that ISO 26262 is a customer requirement, from a mix of different organization types. However, there were more respondents from OEMs in North America and Africa, reflected in the higher percentages for a market requirement than in other regions.
Automotive Development Focus
The leading reason for ISO 26262 compliance by automotive development focus was a customer requirement for most areas. The market requirement majority included Access Control and Comfort Systems, LiDAR, Dealer Management, Supply Chain, and 3D Visualization.
ASIL Levels
The Automotive Safety Integrity Level (ASIL) is a key component of ISO 26262. ASIL A is the minimum level of risk and ASIL D is the maximum level of risk. Going from A to D, the compliance requirement gets stricter. As 33% of survey respondents said that they are required to achieve ASIL D, most respondents are working on higher-risk automotive systems/components. Even for organizations designing individual components as opposed to whole vehicle systems, customers want these to be at ASIL D so they can be used anywhere. It is interesting to note that while there was a decrease in those needing to achieve ASIL C and ASIL D, there was a 7% increase in those who need to achieve ASIL B, year over year, likely because there are more respondents working on IVI systems than braking systems.
Region
Last year, respondents in most regions needed to achieve the highest level, ASIL D. This year, ASIL levels were more varied across regions, with Europe/UK having the highest percentage of respondents still needing to achieve ASIL D.
ISO/SAE 21434 Highlights the Growing Need for Software Security
ISO/SAE 21434 is a relatively recent automotive standard that focuses on cybersecurity risk in road vehicle electronic systems. A majority of those surveyed will be required to comply with ISO/SAE 21434 (66%).
Why Developers Need to Comply With ISO/SAE 21434
For those who need to comply with ISO/SAE 21434:
- 40% need to comply due to a market requirement, a decrease of 5% over last year.
- 48% need to comply due to a customer requirement, an increase of 11% over last year.
- 9% have an internal requirement, a decrease of 9% over last year.
Region
Overall, ISO/SAE 21434 compliance was more of a customer requirement than a market requirement compared to the 2025 report. However, this differed by region. Automotive professionals in North America cited a market requirement for compliance, while other regions cited a customer requirement.
Automotive Development Focus
Compliance with ISO/SAE 21434 was more of a market requirement for areas like Chassis and Safety, Access Control and Comfort Systems, Instrument Clusters/HVAC/Lighting, Dealer Management, Manufacturing, Supply Chain, and 3D Visualization/Digital Twins/Immersive Design.
Many other components are still needing to comply primarily as a customer requirement. This makes sense as it is not yet an industry requirement, but will become mandatory in the future. In addition, customers have to conform with regulatory guidance regarding security.
SOTIF (ISO 21448) Continues to Be Important
SOTIF (ISO 21448) was developed to address the additional safety challenges for autonomous and semi-autonomous vehicles. In a shift from last year, the majority of those we surveyed stated that SOTIF (ISO 21448) was not part of their software development process. While this standard is not typically a requirement — rather, it is more of a guidance — this is still concerning, because safety challenges will continue to grow. This standard, which is applicable to any system including AI, will become more important as AI use increases. Already, SOTIF (ISO 21448) helps connect ISO 26262 with the newer AI standard, ISO/PAS 8800.
Why Developers Need to Comply with SOTIF (ISO 21448)
For those who need to follow SOTIF (ISO/PAS 21448):
- 35% need to comply due to a market requirement, a decrease of 15% over last year.
- 48% need to comply due to a customer requirement, an increase of 16% over last year.
- 15% have an internal requirement, a decrease of 3% over last year.
Region
Market requirements for following SOTIF (ISO 21448) were the leading reason among respondents from North America and Oceania. For other regions, it was more of a customer requirement.
Automotive Development Focus
While the customer requirement was the leading reason to follow SOTIF (ISO 21448), some areas of automotive software development focus have a higher market demand for SOTIF (ISO 21448). For example, Chassis and Safety, LiDAR, Connected Car and V2X, and 3D Visualization.
Leading Challenges in Proving Compliance
Proving compliance with key automotive functional safety and security standards can be a challenging and time-consuming process, but we continue to see increased market and customer demand for meeting these standards.
Consistent with the 2025 report, most of those we surveyed struggled to fulfill safety requirements and prove that those requirements have been fulfilled (36%). In addition, 15% find qualifying tools challenging. Development teams can easily fulfill safety requirements (and prove it) by using a qualified tool for use in safety-critical applications.
Fulfilling safety requirements and providing documentation proving that the criteria have been met is the leading challenge with automotive software compliance.
Organization Size
When looking at the collected responses by organization size, Small organizations struggled more with qualifying tools and analyzing risk over enforcing coding standards, compared to larger organizations; while Enterprise organizations were concerned with enforcing standards and documenting versions of files and assets equally after the main concern of fulfilling safety requirements overall.
Respondent Experience Level
After fulfilling safety requirements, industry professionals with 1-3 years and 3-5 years of experience were more concerned about qualifying tools over enforcing coding standards.