If you supply software, electronics or connected components to the automotive industry, your information security posture is no longer just an internal matter, it’s a precondition for winning and keeping contracts. OEMs and Tier 1 suppliers increasingly require a valid TISAX label before awarding work and they cascade cybersecurity obligations from UNECE R155 and ISO/SAE 21434 down through the supply chain.
That means any external development partner you bring in has to meet the same bar. This article explains what TISAX actually requires, how it relates to the wider automotive cybersecurity stack and what to look for in a software development partner so that working with them strengthens your compliance position rather than putting it at risk.
Why this matters more in 2026 than it did two years ago
The modern vehicle is a software platform. Industry estimates put current vehicles at over 100 million lines of code across hundreds of electronic control units and UNECE forecasts suggest OEM vehicles could contain up to 300 million lines of code by 2030. Every line of that code and every piece of design and prototype data behind it, is a security surface and the industry has built a layered compliance regime to protect it.
For suppliers, three things have converged:
- First, TISAX has become a de facto gatekeeper. Major manufacturers including Volkswagen, BMW, Mercedes-Benz and Stellantis increasingly require a valid TISAX label before doing business with a supplier. It’s not a legal obligation, but in practice, no TISAX label can mean you don’t qualify to quote on new business.
- Second, the UNECE R155 regulation made vehicle cybersecurity mandatory for type approval and while the OEM is the party certified, the obligations cascade. System integrators and component suppliers must provide cybersecurity evidence, participate in threat-and-risk assessment processes and comply with cybersecurity interface agreements. And OEMs increasingly require ISO/SAE 21434 compliance as a contractual obligation.
- Third, the EU Cyber Resilience Act adds a product-level obligation on top of all this, with vulnerability and incident reporting duties for manufacturers of connected products beginning 11 September 2026.
This means that when you bring in an external software development partner, that partner becomes part of the supply chain your OEM customer is scrutinizing. Their security posture is now your concern.
TISAX, explained for suppliers who have to satisfy it
TISAX (Trusted Information Security Assessment Exchange) is the automotive industry’s standardized information security assessment, created by the German automotive association (VDA) and administered by the ENX Association. It was built to solve a specific problem: before TISAX, every OEM ran its own security audit, so suppliers were assessed repeatedly against different criteria. TISAX unified that into one framework whose results can be shared across participants.
It builds directly on ISO/IEC 27001, adding automotive-specific requirements, most notably prototype protection and specific data-handling rules. This overlap matters commercially: a company that already operates an ISO 27001-based information security management system has roughly 70% of TISAX requirements already covered and primarily needs to add prototype protection and the data-privacy module.
Assessment levels: AL2 vs AL3
TISAX defines three assessment levels that determine how rigorously you’re audited. For supply-chain purposes, two matter:
Assessment Level 2 (AL2) is the most common. The assessment is conducted remotely by an accredited audit provider – documentation review plus interviews by video or phone. Around 65% of all active TISAX labels sit at AL2. It’s typically required for suppliers handling sensitive but non-prototype information: technical documentation, design data, project plans.
Assessment Level 3 (AL3) is the highest level and requires a full on-site audit – the assessor physically inspects server rooms, access zones and workplaces and interviews staff individually to verify that documented procedures are actually followed. AL3 is mandatory if you have access to pre-release vehicle data, CAD drawings of prototypes, or test vehicles. Many major OEMs require AL3 for production-critical suppliers.
A crucial practical point: the level and label you need are specified in your supply contract, not chosen by you. Choosing the wrong one means repeating the assessment at your own expense. And since the April 2024 move to VDA ISA 6.0, the label system was overhauled; the old “Info High” and “Info Very High” labels were discontinued and replaced with labels that cleanly separate confidentiality and availability. All TISAX labels are valid for exactly three years, after which re-assessment is due.
How is this important for us, software development companies?
If you’re bringing in external development capacity, whether augmenting your team or handing over a project, these are the questions that protect your compliance position.
A valid TISAX label at the level your contract requires. Ask for the assessment level (AL2 or AL3), the label scope, and confirmation that the label is current in the ENX portal. “We follow TISAX principles” is not a label.
ISO 27001 underneath it. Since TISAX builds on ISO 27001, a partner with current ISO 27001 certification has the management-system foundation the automotive requirements extend. Without it, the prototype-protection and data-privacy modules sit on nothing.
EU jurisdiction and clear data handling. Prototype data, design specifications and pre-release information carry strict handling rules. A partner operating inside the EU, with EU-resident engineers and a clear data-processing agreement, removes a layer of complexity that non-EU vendors introduce.
Documentation discipline as a default. Asset inventory, network segmentation evidence, access-rights concepts, patch management, incident response, these are exactly what a TISAX assessor asks for and exactly what your development partner needs to be able to produce on demand. If pulling this together would take them weeks, that’s the gap the audit will find.
Named engineers with controlled, logged access. TISAX and the wider regime expect identifiable individuals with traceable permissions, not anonymous, rotating contractor capacity. You need to know exactly who can touch your data and code.
The ability to support component-level cybersecurity work. If your scope touches ISO 21434 obligations, your partner should understand TARA-derived controls, secure development practices and the traceability from threat to control to test that the standard expects.
Where Ascendro fits
We are TISAX certified and we hold ISO 27001 and ISO 9001 alongside it. That combination is the reason we are able to deliver software work for automotive clients including BMW and Audi.
For an automotive supplier, the practical value is straightforward. When we develop software for you, the documentation, access controls, network segmentation and incident-response procedures that a TISAX assessor or an OEM audit will ask about are already part of how we operate, because they have to be for our own label. We don’t become a gap in your evidence trail, we extend the standard you’re already held to.
The structure helps too. Engagements run through our German entity for the contracting relationship and our Romanian entity for delivery, both inside the EU, with EU-resident engineers and German-speaking project management. For a German automotive supplier, that means data residency, contractual clarity and communication all sit where your compliance and your procurement teams expect them to.
And because we offer staff augmentation, dedicated teams and full project delivery under the same certified structure, you can scale the engagement to your roadmap without the compliance posture changing as you grow, whether you’re adding a few specialists to an in-house team working on an ECU, or handing over a connected-feature build end to end.
If you’re evaluating development partners against your TISAX and OEM requirements, we’re happy to walk through exactly how we evidence each one. Contact us at info@ascendro.de.
This article is published for informational purposes and does not constitute legal or certification advice. TISAX, ISO 21434 and UNECE R155 obligations depend on your specific scope and contracts – consult your OEM requirements and a qualified assessor.
As a dedicated software development team with expertise in nearshore software development, software development outsourcing, IT staff augmentation and many more, we specialize in providing innovative solutions across industries, from custom manufacturing software development to business process optimization, ensuring that our clients remain competitive and efficient in their operations. Check out our software development projects here.
Dedicated to client satisfaction
Related Posts
June 10, 2026
Choosing a nearshore software development partner in Germany
A pattern is showing up across engineering teams in 2026 and it's the opposite…
June 2, 2026
NIS2 and DORA: What mid-Sized European companies are actually doing about it in 2026
For two years, NIS2 and DORA felt like distant problems. Big regulations, long…
June 3, 2025
Custom manufacturing software. Solving real problems with smart, secure solutions
Discover how we build custom manufacturing software that helps solve complex…




