Connected Cars: Technical Architecture, Data Flows and Regulatory Pressure

Highly equipped connected vehicles can generate or handle up to 25 GB of data per hour. Most documentation stops at “the car talks to the cloud.” What it skips are the exact data categories flowing through connected car systems, the protocols carrying them, and the regulatory obligations that now determine how OEMs and suppliers store, share, and process this data.

Connected Cars: Key takeaways

• Connected car data spans several categories, each with different latency requirements, privacy implications, and regulatory relevance.
• MQTT is widely used for vehicle-to-cloud communication because its persistent sessions and QoS levels help handle mobile network interruptions reliably while reducing application-level retry logic.
• The EU Data Act, GDPR, the Cyber Resilience Act, and UN ECE WP.29 apply simultaneously to connected car data, making compliance a system architecture requirement, not an afterthought.
• Cedalo’s enterprise MQTT platform, built on Eclipse Mosquitto with 600M+ Docker pulls, delivers the clustering, RBAC, audit logging, and Kafka integration that connected car backends need at fleet scale.

What Data Does a Connected Car Actually Generate?

Modern vehicles with full sensor suites produce data across six distinct categories. Each carries different latency requirements, privacy implications, and regulatory relevance.

The volume is not the defining challenge. The architecture decisions around which data travels to the cloud in real time, which gets processed locally, and which requires explicit user consent drive the real complexity.

How Does a Connected Car System Route Data from Sensor to Cloud?

The connected car system routes data through four distinct layers before it reaches any cloud service. Each layer performs a specific transformation:

• In-vehicle network (CAN, LIN, Automotive Ethernet): raw sensor and ECU data circulates across different bus systems with different bandwidths. Classical CAN and CAN FD handle control and diagnostic data, while Automotive Ethernet covers high-bandwidth domains like ADAS camera feeds.
• Telematics Control Unit (TCU): the TCU acts as the vehicle’s gateway to external networks. It aggregates relevant signals, applies initial filtering, and translates from OT protocols to IP-based communication over 4G/5G.
• Transport layer (MQTT over mobile network): structured payloads leave the TCU via MQTT. Local buffering in the TCU, combined with MQTT QoS and persistent session handling, helps deliver relevant messages once connectivity returns.
• Cloud ingestion and backend: an MQTT broker cluster receives incoming vehicle connections, routes topics to processing pipelines, and feeds analytics, storage, and enterprise systems.

Why Is MQTT Widely Used for Connected Car Data Transmission?

The choice between MQTT and HTTP for connected car data is not primarily about performance under ideal conditions, it is about behavior when mobile networks degrade. MQTT’s QoS levels and persistent sessions help vehicles resume message delivery after network interruptions while reducing custom retry logic on the application layer.

An HTTP-based architecture requires polling or long-polling to simulate push delivery, which multiplies request overhead across millions of concurrent vehicle connections. A properly designed MQTT broker cluster can handle large numbers of persistent sessions with lower protocol overhead than request-based patterns.

For OEM-scale deployments, this architectural difference directly determines infrastructure cost, reliability SLAs, and the feasibility of real-time fleet monitoring.

Does Your Connected Car Cloud Architecture Handle What the Backend Actually Demands?

The connected car cloud is not a single system but a pipeline with distinct processing stages. Ingestion, stream processing, storage, and delivery all run as separate components with different scaling requirements.

At the ingestion layer, MQTT broker clusters handle incoming vehicle connections. A cluster serving one million concurrent vehicles requires automated load balancing, failover handling, and topic-level authorization per vehicle identity. Any broker architecture without clustering creates a single point of failure for the entire fleet.

Edge Processing in Connected Vehicles: What Does Not Leave the Car

Not all connected car data is a cloud candidate. ADAS processing, emergency braking decisions, and lane-keeping assistance run at latencies below 10 ms, ruling out cloud round trips entirely.

Locally processed data includes sensor fusion output for real-time driving decisions, privacy-sensitive cabin data that requires consent before transmission, and buffered telemetry during connectivity loss. A store-and-forward mechanism in the TCU or an on-board edge runtime retains this data and synchronizes it once the mobile connection recovers. This is the edge-to-cloud pattern applied directly at vehicle level.

What Regulatory Requirements Apply to Connected Car Data?

Three regulatory frameworks now intersect directly on connected car data. Architects and product teams who treat compliance as an afterthought end up redesigning systems after type approval.

Who Has Access Rights to Connected Car Data Under the EU Data Act?

The Data Act’s answer is unambiguous. The user holds data access rights, not the manufacturer. What this means in practice:

• OEMs must provide a technical interface for real-time data access by the vehicle user or their designated third party.
• Data portability should not be undermined by proprietary formats or restrictive licensing terms, subject to Data Act limitations such as security, trade secrets, and data protection.
• Backend authorization models must distinguish between OEM-internal access, regulatory audit access, and user-delegated third-party access.

Topic-level RBAC in the MQTT layer is one mechanism to implement these permission tiers. The technical foundation for securing these connections starts at the transport layer. A solid MQTT TLS configuration defines which clients authenticate, how, and under what conditions.

ISO/SAE 21434 and UN ECE WP.29: Cybersecurity as a Type Approval Requirement

ISO/SAE 21434, published in 2021, is the technical framework for a Cybersecurity Management System (CSMS). It defines the engineering process for automotive cybersecurity and is the technical basis for compliance with UNECE Regulations R155, R156, and R157. It supports documented Threat Analysis and Risk Assessment (TARA) for road-vehicle E/E systems and relevant connected interfaces, including the TCU, vehicle-facing backend interfaces, and OTA update channels.

UNECE Regulation No. 155 took effect in 2021 and became mandatory in 2022 for every new vehicle. Since 2024 it applies in all European countries and in other adopting countries, including Japan and South Korea. OEMs must hold a certified CSMS to obtain type approval. The regulation applies across the vehicle lifecycle, not just the development phase.

Security Architecture for Connected Car Systems: From mTLS to Audit Logging

A connected car’s attack surface spans the in-vehicle network, the mobile communication channel, and the cloud backend. Securing it requires controls at each layer simultaneously.

Minimum requirements for production-grade connected car security:

• Mutual TLS (mTLS) for all MQTT connections between TCU and broker: vehicle identity authentication, not just server certificate validation
• Per-vehicle topic namespacing: each vehicle publishes and subscribes only within its own topic hierarchy. No lateral access across the fleet
• Certificate lifecycle management: vehicle certificates issued at production must remain valid and rotatable over a 10-to-15-year lifespan
• Audit logging: all authentication events, topic access attempts, and configuration changes are logged and retained for regulatory review

How to Build a Scalable Connected Car Backend with MQTT and Kafka

The most resilient connected car backends separate the device connectivity layer from the data processing layer. MQTT excels at maintaining millions of persistent vehicle sessions with reliable message delivery. Kafka takes over where MQTT stops, providing durable event streaming, parallel consumer groups, and long-term data retention for AI model training and fleet analytics.

A practical five-layer architecture for connected car data at OEM scale:

• Device Layer: vehicle fleets across regions connect via 4G/5G, publishing telemetry, diagnostics, and event data over MQTT.
• MQTT Broker Cluster: receives all vehicle connections, enforces topic-level access control, and routes payloads to backend consumers. Clustering and high availability are non-negotiable at fleet scale.
• MQTT-to-Kafka Bridge: forwards relevant topics into Kafka partitions organized by vehicle group, data category, or geography. The MQTT-to-Kafka integration decouples the connectivity layer from the processing layer and can reduce data-loss risk when configured with persistence, acknowledgements, retries, and monitoring.
• Stream Processing and Storage: Apache Flink or Kafka Streams run real-time detection for anomalies and predictive maintenance signals. A data lake retains historical telemetry for AI training and regulatory audits.
• Integration Layer: ERP systems, fleet management platforms, and Data Act-compliant third-party APIs consume structured data through defined delivery channels.

The complete MQTT protocol guide covers topic design, QoS selection, and session handling for deployments at this scale. For OEMs working with semantic data models across plants, production systems, and industrial data environments, MQTT Sparkplug B defines a standardized MQTT topic namespace and payload structure that can bring consistency to heterogeneous IIoT and SCADA integrations.

Is Your Data Infrastructure Ready for What Connected Cars Technology Will Demand by 2030?

Three technology shifts will reshape connected car data architectures before the end of the decade.

• Software-Defined Vehicles (SDV): OTA shifts from occasional patch to permanent operational channel. Every software release across the fleet requires version control, rollback capability, and audit logging.
• V2X at scale: Vehicle-to-Infrastructure and Vehicle-to-Network communication can demand low end-to-end latency and regional processing close to the vehicle. For cloud-connected V2N use cases, this puts pressure on broker placement, edge processing, and geographic distribution.
• Federated AI in vehicles: Model training without centralizing raw driver data requires topic structures that support differential privacy and data residency rules by design, not as a retrofit.

The regulatory framework expands in parallel. Gaia-X-based initiatives such as Mobility Data Space and Catena-X support trusted cross-organization data exchange. Open standards help teams adapt without full architectural rewrites.

Connected Cars Run on Data Infrastructure Built for Resilience

Connected car systems expose weak points in your messaging architecture: dropped sessions, backends that cannot scale, and access models that may not withstand a Data Act audit. Regulatory pressure is already shaping production architectures.

Teams that get this right build on a single integrated layer for connectivity, security, and compliance. Fewer incidents, faster time-to-compliance, and a backend that scales with the fleet. Cedalo delivers exactly that stack, built on the world’s most widely deployed MQTT broker.

Your Advantages with Cedalo:

• Proven at scale: Eclipse Mosquitto with 600M+ downloads, maintained and developed by Cedalo
• Enterprise-ready out of the box: Pro Mosquitto adds clustering, high availability, RBAC, and audit logging, together with mTLS, in a single platform, with no need to stitch together separate tools
• Regulatory fit by design: role-based access control, audit trails, and topic-level authorization address Data Act and WP.29 requirements at the architecture level
• Full-stack integration: native bridges to Kafka, with MQTT-based connectivity for AWS, Azure, GCP, SCADA, and ERP systems, reduce integration overhead from months to days

Connected Cars: Frequently Asked Questions

What Is the Difference Between a Connected Car and an Autonomous Car?

A connected car exchanges data with external systems, including cloud backends, infrastructure, and other vehicles, but the driver retains full control. An autonomous car uses onboard AI to make driving decisions independently. Connectivity is a prerequisite for autonomy, but most connected cars on the road today operate at SAE Level 0 to 2.

Which Wireless Technologies Do Connected Cars Use to Transmit Data?

Connected cars rely on a combination of 4G LTE, 5G, DSRC (Dedicated Short-Range Communications), and C-V2X (Cellular Vehicle-to-Everything) depending on the use case. 5G can support high-bandwidth telemetry and OTA updates, while C-V2X supports low-latency V2I and V2V communication for use cases with strict latency requirements.

How Do Connected Cars Handle Data Transmission When There Is No Mobile Network Coverage?

The Telematics Control Unit (TCU) can buffer data locally using a store-and-forward mechanism. Once connectivity is restored, buffered messages can be transmitted according to the client and broker configuration. MQTT’s QoS and persistent session handling support this process, while application-level recovery logic may still be required.

What Role Does MQTT Play in Connected Car Communication?

MQTT is widely used for vehicle-to-cloud communication because it handles intermittent mobile connections efficiently through persistent sessions and QoS levels. Its low protocol overhead makes it practical at fleet scale, where request-based patterns like HTTP can create higher connection and polling overhead.

How Does Cedalo Support Connected Car Data Infrastructure at Scale?

Cedalo provides an enterprise MQTT broker platform built on Eclipse Mosquitto, the most widely deployed MQTT broker globally. It adds clustering, high availability, mTLS, and role-based access control to handle fleet-scale vehicle connections while meeting the security and audit requirements of WP.29 and the EU Data Act.

Can a Connected Car Backend Integrate with Existing ERP and SCADA Systems?

Yes. Modern connected car backends route vehicle data through MQTT broker clusters into Kafka pipelines, which feed ERP, MES, SCADA, and analytics platforms. Cedalo supports native bridges to Apache Kafka and major database systems, and MQTT-based connectivity for AWS, Azure, and GCP, reducing the integration effort between vehicle data and enterprise IT environments significantly.

What Happens to Connected Car Data After the Vehicle Reaches End of Life?

Data retention obligations under GDPR require OEMs to define clear retention and deletion timelines for personal data tied to a specific vehicle or driver. After the end of life, residual personal data in cloud backends must be deleted or anonymized once the applicable purpose or legal basis no longer applies, subject to statutory retention obligations. This affects how topic structures and storage policies are designed from the start.