Industry · Automotive Software

Automotive Software for Connected Vehicles and Tier-1 Suppliers

Automotive software is shifting from the ECU to the platform. Software-Defined Vehicle, OTA updates, Catena-X data flows, and a tightened cybersecurity framework — UN-R155, UN-R156, ISO/SAE 21434 — hit Tier-1 and Tier-2 suppliers that today must make every software path auditable for their OEM customer. Anyone building companion apps, workshop tools, diagnostics backends, or OTA infrastructure here is not building “an app” — they are building auditable automotive software that ages with the vehicle lifecycle.

Contact

Industry context

Stuttgart, Baden-Württemberg, and Bavaria form Europe’s densest automotive software cluster — Mercedes-Benz Group, Porsche, Audi, BMW, and their suppliers Bosch, ZF, Mahle, Continental, Schaeffler. Around these hubs sits a four- to five-figure Mittelstand of Tier-2 and Tier-3 suppliers that increasingly must deliver software themselves — diagnostics stacks, service apps, telemetry backends for connected components.

Three shifts define the industry in 2026: First, the Software-Defined Vehicle — BMW “Neue Klasse”, Mercedes-Benz MB.OS, ZF reference architectures, Bosch AI cockpit. Function migrates from distributed ECUs to zonal compute nodes, complemented by cloud-side services. Second, the cybersecurity cascade: UN-R155 has been mandatory for all EU new production since 07/2024, and ISO/SAE 21434:2021 is the de-facto evidence path — both propagate via CSMS obligations from OEM down to Tier-2 and Tier-3. Third, the data layer: Catena-X, with roughly 190 members and a growing list of CX standards (e.g. CX-0018 Dataspace Connectivity, CX-0126 Industry Core: Part Type), has matured from concept to operational ecosystem — no longer a thought experiment but a delivery condition.

For software suppliers this means: automotive software without a documented ISO/SAE 21434 process, without a signed update path, and without compatibility with Catena-X data formats fails OEM supplier audits — regardless of how elegant the code is.

Typical challenges

Cybersecurity evidence through the supply chain

Tier-1 suppliers contractually pass their OEM customer’s UN-R155 CSMS obligations down to Tier-2 and Tier-3. Anyone delivering automotive software without a documented ISO/SAE 21434-conformant engineering process — TARA, threat catalog, vulnerability management, secure development lifecycle — fails supplier audits. The evidence is not a “nice to have” certificate, it is a precondition for the next framework agreement. Equally demanded: a TISAX assessment level (AL2 or AL3, valid three years) covering information security of the development environment itself.

OTA update infrastructure under UN-R156

UN-R156 demands a Software Update Management System (SUMS) with signed manifests, a documented approval chain, rollback capability, and a complete audit trail over every rolled-out version. An OTA infrastructure not designed from day one as an append-only event log with auditable version history cannot be retrofitted to be UN-R156-fit — it must be rebuilt. The same applies on the device side: bootloader, signature verification, and A/B partitioning are not optimisations but the entry ticket.

Companion apps with real-world connectivity

Automotive software that shows live vehicle data — service apps for Tier-1 suppliers, workshop apps with an OBD-II/UDS bridge, end-customer companions for in-vehicle sensors — must cleanly handle BLE disconnects, workshop Wi-Fi latency, mobile coverage gaps on the road, and offline scenarios during service. An online-only architecture relying on 4G does not survive day one in the workshop. The robust pattern: a local event log on device, sync with the backend via structured resync points, idempotent APIs.

Catena-X compatibility as a delivery condition

OEMs increasingly build supplier data flows on Catena-X — traceability, quality management, Product Carbon Footprint, demand and capacity management. Tier-1 and Tier-2 suppliers need an Eclipse Dataspace Connector (EDC, CX-0018-conformant), clean mappings to CX standards (e.g. CX-0126 Industry Core: Part Type), and data sovereignty that stays in their own hands even under OEM access obligations. Building the backend without this connectivity concept means a second data path grows alongside the actual system — doubling the compliance load.

Lifecycle data across 15 years of vehicle operation

A passenger car stays in operation well over a decade on average — for software, that means update capability, diagnostics compatibility, and data model must remain consistent for more than ten years. An automotive software architecture that handles schema migrations only retrograde loses the first device generations on the first major refactor. The proven path: a versioned lifecycle data model with an immutable birth snapshot per component and an event-log-based service history — the refactor path stays open without losing historical data.

Regulatory framework

UN-R155 (Cybersecurity Management System)

UN Regulation No. 155 requires a Cybersecurity Management System (CSMS) certificate for type approval and concrete mitigations against the threats listed in Annex 5 — across the full vehicle lifecycle. Scope: categories M (passenger transport), N (goods), O (trailers with an ECU), and L (level-3+ automation). Supplier relevance: OEMs contractually pass CSMS obligations down to Tier-1, who pass them to Tier-2/Tier-3 — every piece of automotive software in the chain becomes subject to evidence. Supplement 3, in force since 10 Jan 2025, refines scope and audit requirements.

Applicability: In force since 22 Jan 2021 · Mandatory for new vehicle types since 07/2022 · For all EU new production since 07/2024 · Supplement 3 since 10 Jan 2025

UN-R156 (Software Update Management System)

UN Regulation No. 156 requires a documented Software Update Management System (SUMS) and secure update processes for every approved vehicle type. Content: signed manifests, a documented approval chain, rollback capability, user notification for safety-relevant updates, a complete audit trail. UN-R156 accompanies UN-R155 on the same timeline — and is the prerequisite for any over-the-air update to an approved vehicle type. For Tier-1 and Tier-2 suppliers delivering OTA backends or update components, SUMS conformity of their path is explicitly auditable by the OEM customer.

Applicability: Same timeline as UN-R155 · Mandatory for new types since 07/2022 · For all EU new production since 07/2024

ISO/SAE 21434:2021

International standard for cybersecurity engineering of electrical/electronic systems in road vehicles. Published 31 Aug 2021. Defines an engineering process across the full lifecycle — concept, product development, production, operation, maintenance, decommissioning. Applicable to systems whose development or modification begins after 2021. Complements ISO 26262 (functional safety) but addresses cybersecurity risks explicitly — TARA (Threat Analysis and Risk Assessment), asset identification, risk treatment. Practical relevance: ISO/SAE 21434 is the de-facto path to traceably fulfil the UN-R155 CSMS obligation of the OEM.

Applicability: Published 31 Aug 2021 · Edition 1 in force

ISO 26262 (Funktionale Sicherheit)

International standard for functional safety of electrical/electronic vehicle systems. First edition 2011, current second edition 2018 with scope extended to all road vehicles except mopeds. Classifies risks via ASIL (A through D, with ASIL D imposing the strictest requirements). For safety-relevant automotive software the ASIL path must be traceably documented — from requirement through architecture and implementation to validation and configuration. Complementary to ISO/SAE 21434: functional safety and cybersecurity are two distinct engineering processes with overlapping artefacts.

Applicability: First edition 2011 · Second edition 2018 (current)

TISAX (VDA Information Security Assessment)

Audit and exchange mechanism, jointly developed by VDA and ENX, based on the VDA ISA catalogue. TISAX assesses information security of the development and supplier environment. Three assessment levels: AL1 (self-assessment), AL2 (self-assessment plus remote plausibility check), AL3 (full on-site inspection). Certificates valid for three years. OEMs and Tier-1 suppliers typically require TISAX as a precondition for any supplier handling prototype data, design documents, or personal data — automotive software suppliers without TISAX status are often not even invited into the procurement process.

Applicability: Required in OEM supplier onboarding · Certificate valid 3 years

EU Cyber Resilience Act (CRA)

Regulation (EU) 2024/2847 mandates security-by-design for products with digital elements on the EU market: vulnerability handling, security updates, conformity assessment, incident reporting. The boundary against automotive is precise: type-approved vehicle components covered by UN-R155 / EU 2019/2144 are excluded from CRA scope. What stays in CRA: aftermarket software, retrofit modules, charging infrastructure, companion apps, third-party infotainment software, commercial vehicles outside the UN-R155 scope (construction, agriculture, forestry). Anyone delivering automotive software there needs CE marking.

Applicability: In force since 10 Dec 2024 · Reporting obligations from 11 Sep 2026 · Fully applicable 11 Dec 2027

EU Data Act

Glossary →

Regulation (EU) 2023/2854 grants users of connected products the right to access, use, and share the data generated by their use — applicable also to connected vehicle data and after-sales telemetry. Manufacturers and their software suppliers must design related services so this access is technically possible — structured data export, a clear API layer, separation between manufacturer-internal and user-accessible data. For service apps and workshop backends: the data model must know data categories and access rights explicitly, not implicitly.

Applicability: Applicable since 12 Sep 2025

Architecture pattern for B2B apps

Vehicle / component interface
BLE 5+ · WiFi Direct · UDS-on-IP · CAN-FD gateway · OBD-II · MQTT 5 (TLS, client cert)

Multiple parallel connectivity paths — app-to-vehicle, app-to-diagnostics-gateway, component-to-backend. Device authentication via X.509 certificates from a dedicated PKI, never via static pre-shared keys in code. Robustness against disconnects is mandatory, not optimisation.

Mobile app layer (companion / workshop)
Cross-platform app (e.g. Flutter) for 80–90 % of logic · native bridges for safety-critical paths · offline-first data model · local event log

Cross-platform for the bulk of functionality, native bridges for safety-critical or hardware-near operations (UDS stack, bootloader communication). The app data model is offline-first: every action is written locally as an event, sync with the backend via structured resync points and idempotent APIs.

Telemetry ingestion & event log
MQTT broker · streaming platform (e.g. Kafka, NATS JetStream) · typed ingestion API · TimescaleDB · append-only event log

High-throughput device data intake, cleanly separated from the application API. Every telemetry event is additionally written to an append-only event log — the foundation for UN-R155 incident analysis, ISO/SAE 21434 audits, and an auditable service history. Time-series aggregation in TimescaleDB, raw events remain immutable.

Secure OTA update path (UN-R156)
S3-compatible object store · HSM-issued signatures · A/B partition · rollback · manifest registry · approval workflow

Update artefacts (firmware, app bundle, configuration) live in an S3-compatible object store, manifests are signed from a Hardware Security Module, release passes a documented approval workflow with four-eyes principle. Device side: A/B partition with automatic rollback on failed signature verification. Every action lands in the audit trail — the prerequisite for SUMS conformity.

Catena-X connectivity & data sovereignty
Eclipse Dataspace Connector (EDC, CX-0018) · CX standard mappings (CX-0126 et al.) · policy engine · OEM portal SSO via OIDC

Data is modelled to be Catena-X-compatible — exchanged via the Eclipse Dataspace Connector with policy-based access. The backend keeps raw data in its own hands; Catena-X is a distribution, not storage, layer. SSO to the OEM supplier portal via OIDC, separated from end-customer auth.

Identity, keys & audit
OIDC identity provider (e.g. Authentik, Keycloak, Auth0) · mutual TLS · HSM for signing keys · code-signing pipeline · platform observability

Separated identity domains: workshop staff and OEM contacts via OIDC, end customers via a separate auth provider. All signing keys in a Hardware Security Module, never in code. Platform-wide error tracking and metrics — the prerequisite for traceable UN-R155 incident analysis.

How we pick the stack

The concrete stack is decided per project — driven by data volume, compliance, existing systems, and team skills. This table lists the capabilities we cover and two to three tools we have shipped in production for each.

Capability How we deliver it
Cross-platform app with hardware-near path

One codebase for iOS and Android, robust BLE and Bluetooth integration, fast iteration in OEM, Tier-1, and workshop contexts. Typical pick: Flutter with native bridges for safety-critical paths; pure native (Swift/Kotlin) where the UDS or bootloader stack demands it.
Typed backend for regulated platforms

Structured architecture with clear module separation for compliance audits, performant HTTP, WebSocket, and MQTT layer for live telemetry. We default to TypeScript (NestJS, Fastify); Go or Rust where throughput demands it.
Hybrid relational + time-series storage

Relational integrity for lifecycle and service history, time-series extension for telemetry. Postgres + TimescaleDB as default; ClickHouse or Influx where telemetry volume demands it. Append-only event log in the same schema — no multi-DB plumbing.
Event-driven telemetry under load

Event-driven ingestion with replay capability. Kafka where an existing Confluent/Strimzi stack is in place; NATS JetStream for a lighter self-operated path; pure MQTT pipelines for lower volume classes.
Signed, content-addressed OTA artefact store

OTA artefacts (firmware, bundles, configuration) versioned and content-addressed in an S3-compatible store, signed from an HSM. Provider chosen by data sovereignty: EU-managed storage, MinIO/Garage in own cloud, or a hyperscaler — the integration remains swappable.
OIDC identity in your own hands

OEM/workshop and end-customer identities separated via OIDC providers. Self-hosted options (e.g. Authentik, Keycloak) where data residency or audit demands it; managed providers (e.g. Auth0) where time-to-market and team skills favour it.
Catena-X connectivity via Eclipse Dataspace Connector

Catena-X connectivity via the CX-0018-conformant Tractus-X EDC reference implementation. Policy-based, sovereign data exchange with OEMs and Tier-1 partners without raw data leaving your backend — the standard is mandatory, the concrete build (Tractus-X, Fraunhofer AISEC, Sovity) is your choice.
Platform observability for UN-R155 incident analysis

Error tracking, metrics, and distributed tracing as data basis for UN-R155 incident analysis and ISO/SAE 21434 monitoring. Depending on setup we run OpenTelemetry with Sentry, the Grafana stack (Loki, Tempo, Prometheus), or Datadog — no vendor lock to a single telemetry provider.

Sources

As of: 2026-05-01

Read on

Other industries

Industry 4.0

Industry 4.0 platform development & software for connected production: Asset Administration Shell, OPC UA, EU Data Act and Cyber Resilience Act — built for the DACH Mittelstand.

IoT & Connected Products

IoT platform development, B2B apps, and backend software for connected devices — from BLE sensors to EU Data Act-compliant telemetry platforms.

Mechanical Engineering

Mechanical engineering software, service apps, MES integration, and OPC UA connectivity for DACH Mittelstand — VDMA-umati-compatible.

Facility Management

Facility management software & platforms for CAFM, smart building, and EU energy-efficiency compliance — aligned with GEFMA 444/445.

Construction & Trades

Custom handwerker app and construction software for DACH Mittelstand businesses — mobile-first, offline-capable, from on-site measurement and site diary through e-invoicing (ZUGFeRD / X-Rechnung) to BIM connectivity.

Concrete project in this industry?

We build software that fits the regulatory, technical, and organisational realities of your industry — without excess complexity.

Send email