EU Data Act for Connected Vehicles: Build a Secure, Traceable Data-Access Operating Model

The EU Data Act changes who can access and use data generated by connected products, including connected vehicles. Since 12 September 2025, users have stronger rights to obtain in-scope data and, in many cases, to direct a data holder to make that data available to a third party.

For automotive companies, this creates opportunity and tension at the same time. Vehicle data can support repair, maintenance, insurance, fleet optimization, charging, roadside assistance, and new mobility services. Yet the interfaces used to deliver that value can expose personal data, security-sensitive telemetry, proprietary know-how, diagnostic capability, or information that becomes dangerous when combined with a command path.

The practical question is therefore not whether an OEM should "open" or "close" vehicle data. It is whether the organization can provide the right data to the right party, through the right interface, while preserving cybersecurity, privacy, safety, trade-secret protection, and evidence.

EU Data Act implementation is therefore more than a legal or API project. Each new recipient and interface changes the connected attack surface, so the access decision must remain linked to architecture, threats, controls, tests, suppliers, and incidents.

This guide explains how to build that operating model and how ThreatZ can serve as the automotive cybersecurity and evidence layer without pretending to replace legal interpretation, privacy case management, consent systems, API gateways, or customer identity platforms.

Why the Data Act becomes a CSMS and evidence problem

Chapter II compliance creates recurring engineering decisions. A request may be lawful in principle while the implementation remains unsafe. The same dataset can be low risk as an aggregated export and high risk as a real-time stream with vehicle identifiers. A legitimate recipient may still use weak client identity, token storage, or subcontractor controls.

A Cybersecurity Management System should therefore treat material data-access changes as lifecycle events and answer:

• Which vehicle, function, ECU, backend, API, and supplier produce or process the data?
• Which threat scenarios change because of the access path?
• Which controls reduce those risks, and how were they verified?
• Which policy, software, schema, and architecture version supported the decision?
• What reopens review when ownership, recipients, software, or threats change?

These relationships are difficult to maintain when legal analysis, catalogs, TARA, API tests, supplier evidence, and incidents live in separate systems. The objective is a connected evidence chain, not one giant repository.

What the Data Act changes for automotive

The Data Act establishes harmonized rules for access to and use of data generated by connected products and related services. The European Commission's vehicle-data guidance provides tailored interpretation for automotive stakeholders and focuses on the Chapter II access rules.

In practical terms, a vehicle user may be able to:

• Access relevant data generated through use of the vehicle or related service.
• Receive information about what data is generated and how access works.
• Ask the data holder to make relevant data available to a selected third party.
• Use that data to obtain aftermarket or ancillary services instead of relying only on the original manufacturer.

The obligation does not erase other duties. Personal-data processing remains subject to data-protection law. Trade secrets receive safeguards. Security and safety requirements still apply. The organization therefore needs a consistent process that can explain why a dataset was provided as requested, transformed into a safer representation, restricted under defined conditions, delayed for a justified reason, or escalated for legal review.

Before publication, legal teams should validate the latest official guidance and the role of each entity for the specific vehicle, service, and contract. This article focuses on the engineering and cybersecurity operating model, not legal advice.

Identify the actors before designing the interface

A connected-vehicle request can involve more parties than a typical consumer IoT service:

• The owner, lessee, driver, fleet operator, or another recognized user.
• The OEM or another entity acting as data holder.
• A mobile-app or connected-service operator.
• A repairer, insurer, charging provider, fleet platform, roadside service, or independent developer acting as data recipient.
• A Tier-1 supplier operating a backend, analytics service, telematics component, or data broker.
• A cloud, identity, or API-management provider.
• Other people whose personal data appears in the dataset even though they did not make the request.

Roles can change by dataset and service. An OEM may be data holder for one flow and a processor or recipient for another. A fleet customer may be the vehicle user while employees or passengers remain data subjects.

Build a role map for each service. Record the legal entity, contract, vehicle relationship, data source, intended purpose, technical client, permissions, and accountable owner. Give the map stable identifiers so its decisions can be linked to the corresponding API, vehicle program, supplier, and cybersecurity analysis.

Without that mapping, teams can build a technically correct interface that delivers data to the wrong party, for too long, under an entitlement that no longer exists.

Build a vehicle-data catalog that links to the architecture

The central implementation artifact is a vehicle-data catalog connected to technical lineage. For each data element or dataset, record:

• Name and plain-language description.
• Source function, ECU, sensor, application, or related service.
• Generation trigger, frequency, precision, and latency.
• Raw, pre-processed, inferred, or derived status.
• Vehicle, user, and account identifiers attached to it.
• Personal-data, trade-secret, safety, and cybersecurity classifications.
• Storage location, retention, residency, and supplier involvement.
• Available access channel, API version, and service owner.
• User entitlement and third-party-sharing status.
• Required transformation, redaction, aggregation, or security conditions.
• Data quality, units, timestamps, semantic model, and versioning.
• Threat scenarios, security controls, and verification evidence.
• Responsible owner and approval authority.

Do not begin with a list of database tables. One business concept can originate in multiple ECUs, be enriched in the telematics unit, transformed in a cloud service, and exposed through several API versions. The catalog must show lineage from vehicle generation to external delivery.

In a graph-based cybersecurity model, the dataset links to its source component, transport interface, exposing API, recipient category, threats, controls, and tests.

The catalog should also distinguish readily available data from new analysis that would require substantial derivation. The Data Act is not a general obligation to create every possible insight from raw signals.

Separate legal entitlement from technical authorization

A lawful user instruction does not automatically prove that a specific API request should succeed. The operating model needs two related but distinct decisions:

• Entitlement decision: Is this user entitled to request access for this vehicle, dataset, period, and recipient?
• Enforcement decision: Does this authenticated client possess a valid, current, least-privilege authorization for this exact request?

A robust flow includes:

• Verification of the owner, lessee, fleet administrator, driver, or delegated representative.
• Proof of the user's relationship to the vehicle or account.
• Verification of the third-party organization and its technical client.
• Explicit scope for datasets, vehicles, time range, frequency, and duration.
• A record of the user's instruction and any required conditions.
• Short-lived credentials with granular scopes.
• Server-side object and function authorization.
• Revocation when ownership, employment, delegation, or service ends.
• Evidence that the enforced token matched the approved instruction.

Avoid long-lived, all-fleet API keys. For fleets, separate organizational administration from individual vehicle and driver permissions. For partners, isolate tenants and require a distinct workload identity for every production client.

ThreatZ should not become the token issuer or customer-consent engine. It can link the entitlement record or policy reference to the vehicle, data asset, interface, threats, controls, and test evidence, allowing cybersecurity teams to prove why the technical policy is sufficient.

Direct access versus data-holder-mediated access

Two architecture patterns are common.

Direct access from the connected product

The user or recipient retrieves data from the vehicle or a local interface. This reduces backend dependency but raises bandwidth, availability, authentication, version, and safety-isolation constraints. Use a dedicated read model rather than a generic route into diagnostics or control.

Access through the data holder

The vehicle sends data to a backend that exposes it by API, portal, export, or stream. This is easier to scale, but introduces concentration risk, latency, and questions about completeness.

Many OEMs will use a hybrid. Document the assumptions, failure modes, and evidence required for each data class; a mobile-app view alone is not a machine-readable third-party access strategy.

Treat every new data path as a cybersecurity change

A new data recipient or API is not only a commercial integration. It can change trust boundaries, attack paths, credentials, data aggregation, supplier dependencies, and operational monitoring.

Trigger a focused TARA or change-impact assessment when the program introduces:

• A new external recipient category.
• A new dataset, precision level, or update frequency.
• A new direct vehicle interface or gateway rule.
• A new API version, authentication method, or token scope.
• A new cloud, identity, analytics, or integration supplier.
• A new correlation of datasets that increases sensitivity.
• A new ability to infer vehicle state, location, security posture, or user behavior.
• A connection between data access and diagnostics, commands, or software updates.

The analysis should model disclosure and service-abuse scenarios, not only manipulation. Examples include fleet enumeration, cross-vehicle object access, recipient credential theft, data aggregation for theft or stalking, architecture reconnaissance, denial of access, and exploitation of a shared backend service.

In ThreatZ, the data asset and access path can be linked to the relevant system elements, threats, risks, controls, tests, suppliers, and incidents. That makes a later change review a graph query rather than a manual comparison of unrelated documents.

Use threat-based restrictions, not blanket labels

Some teams may classify every vehicle signal as security-sensitive. That is difficult to defend and undermines the regulation's objective. Other teams may expose data without recognizing that precision, frequency, or correlation can create risk.

Use a defined security classification:

• Low sensitivity: disclosure creates little meaningful security impact.
• Operational sensitivity: data can aid profiling, fraud, theft, or service abuse.
• Architecture sensitivity: data reveals versions, network structure, diagnostic capability, or defensive controls.
• Control sensitivity: information can support privilege escalation, command abuse, or bypass of protection.
• Safety-critical sensitivity: disclosure or access could contribute to unsafe behavior when combined with another capability.

For a restriction, connect the rationale to a specific threat scenario, impact, and control gap. State whether the risk comes from the field itself, precision, update frequency, historical depth, combination with other datasets, recipient environment, or access mechanism.

Where possible, offer a safer representation: aggregated values, reduced frequency, pseudonymized identifiers, controlled query access, a secure processing environment, or data that supports the service without revealing diagnostic secrets. The decision is stronger when the organization can show that it considered proportionate alternatives rather than defaulting to refusal.

Protect personal data and trade secrets in the same decision chain

The Data Act and GDPR operate together. The workflow must identify personal and mixed datasets, relevant data subjects, lawful basis, minimization, pseudonymization, retention, transfers, and ownership-transition rules.

Trade-secret handling also needs a specific rationale: the business value at risk, requested fields, recipient safeguards, and proportionate mitigation. Field reduction, controlled queries, confidentiality commitments, aggregation, or disclosure of measurements without proprietary variables may preserve both access and protection.

Privacy, trade-secret, and cybersecurity teams should use the same lineage and decision identifiers so parallel records do not drift.

Build an API product, not a compliance endpoint

A technically available endpoint can still fail users if it is unreliable, undocumented, semantically inconsistent, or impractical to integrate.

A mature vehicle-data API should provide:

• Clear definitions, units, timestamps, quality flags, and schema versions.
• Stable vehicle and dataset identifiers with lifecycle rules.
• Granular authorization scopes and tenant isolation.
• Rate limits tied to legitimate usage patterns.
• Pagination, filtering, bulk export, and subscriptions where appropriate.
• Error responses that do not reveal sensitive architecture details.
• Service-level objectives and maintenance communication.
• Deprecation, migration, and recipient-conformance policies.
• A sandbox for approved recipients.
• Security-event, access, and administrative logging.

Inventory every production, test, regional, partner, and legacy version. Forgotten APIs are a common exposure path. Link each version to its architecture baseline, software components, control set, and test status so deprecation and vulnerability decisions are visible across programs.

Prevent data access from becoming vehicle control

Read access should be architecturally separate from commands. A recipient authorized to read odometer, battery, or maintenance data should not inherit the ability to unlock doors, change charging limits, clear faults, invoke diagnostics, or trigger updates.

Use separate domains, credentials, gateways, and policies for:

• Read-only product data.
• User and account administration.
• Remote vehicle commands.
• Diagnostic and service functions.
• Software updates.
• Engineering access.

Apply authorization to every object and function on the server. Test that a token for Vehicle A cannot retrieve Vehicle B, that a fleet sub-user cannot access the entire fleet, and that read scopes cannot invoke write functions. Include negative tests for identifier manipulation, stale entitlements, token replay, cross-tenant access, and hidden legacy routes.

This separation also creates a cleaner cybersecurity case. Teams can assess the Data Act access service independently while explicitly showing that command and diagnostic paths remain outside its trust boundary.

Build a Data Access Cybersecurity Case

Instead of collecting screenshots at the end, define a small assurance case for every material access pattern. The top-level claim might be:

The vehicle-data access service makes the approved dataset available to the authorized recipient without creating unacceptable cybersecurity or safety risk.

Support that claim with subclaims such as:

• The dataset and technical lineage are complete and correctly classified.
• The user's relationship to the vehicle and the recipient's identity are verified.
• Authorization is least privilege, time bound, revocable, and enforced server side.
• Read access is isolated from commands, diagnostics, and updates.
• Privacy and trade-secret transformations are applied as approved.
• Security controls are verified against representative misuse scenarios.
• Software, schema, and supplier changes trigger impact analysis.
• Monitoring can detect abuse and incidents can be traced to affected vehicles and decisions.

Evidence can include the architecture baseline, data catalog, TARA, policy version, authorization matrix, API-security tests, penetration-test findings, software and SBOM versions, supplier attestations, access logs, incident exercises, and approval record.

ThreatZ is well suited to hold the cybersecurity side of this case because its knowledge graph connects architecture, assets, threats, risks, controls, requirements, tests, software components, vulnerabilities, suppliers, incidents, and reports. Legal opinions, privacy records, contracts, and consent remain in their authoritative systems; ThreatZ can store references and trace links rather than duplicating those systems.

This turns "security approved" into an inspectable argument and shows which services depend on a given identity provider, control, library, supplier, or policy version.

Connect changes and incidents back to the original decision

Data access is a lifecycle service. Ownership transfers, supplier changes, API releases, new CVEs, failed tests, or abuse incidents can invalidate the assumptions used at approval time.

Define triggers that automatically reopen review, including:

• Identity or authorization control failure.
• New vulnerability in an exposed API component.
• Schema change that adds sensitive fields.
• New recipient purpose or access frequency.
• Supplier ownership or hosting change.
• Incident involving token theft, scraping, enumeration, or data leakage.
• Vehicle architecture or gateway change.
• End of support for a dependent component.

The response should identify affected datasets, APIs, vehicle variants, recipients, controls, and evidence packs. ThreatZ's Operations and SBOM/Supply Chain capabilities can connect an incident or vulnerability to the underlying assets, risks, controls, components, and responsible teams, while the external API gateway and SIEM continue to enforce and detect in real time.

A 12-week ThreatZ-centered pilot

Choose one high-value, bounded use case such as independent repair or fleet maintenance.

Weeks 1-3: Model scope and lineage

Map the user, vehicle, dataset, source function, backend, API, recipient, suppliers, and legal decision identifiers. Import the relevant architecture into ThreatZ or create a focused system model. Establish the data asset and trust boundaries.

Weeks 4-6: Analyze risk and define controls

Run a focused TARA for the access path. Define identity, authorization, isolation, minimization, logging, change-control, and supplier controls. Link each control to the threat and decision it supports.

Weeks 7-9: Connect verification evidence

Implement or update the API, gateway policy, tokens, revocation, and logging. Link authorization-matrix tests, object-level access tests, penetration-test evidence, and software/SBOM context to the relevant controls and risks.

Weeks 10-12: Prove lifecycle governance

Run a complete request from user instruction through third-party delivery and revocation. Then simulate one change or incident, such as a vulnerable API library or stolen recipient credential. Produce the Data Access Cybersecurity Case and measure how quickly the team can identify impact and evidence.

The pilot should leave behind reusable catalog classes, threat patterns, controls, tests, and report templates - not one bespoke integration.

Metrics for Data Act readiness

Track the percentage of in-scope datasets linked to architecture and interfaces; access patterns with current TARA, controls, and tests; supplier-operated paths with current evidence; active unsupported API versions; authorization-test coverage; revocation time; vulnerability blast-radius time; and incidents linked back to data assets and risks.

The best metric is not data volume. It is whether the organization can provide the right data to the right party through a controlled process that remains explainable after change.

How ThreatZ strengthens the Data Act operating model

ThreatZ can act as the automotive cybersecurity evidence layer across five connected activities:

• Model the access path. Link the data asset to vehicle functions, ECUs, cloud services, interfaces, APIs, recipients, and suppliers.
• Analyze the threat. Use the TARA workflow and reusable security catalog to assess disclosure, authorization, service-abuse, isolation, and availability scenarios.
• Connect controls and proof. Link access policies, security requirements, controls, test cases, findings, software components, and report evidence to the risk they address.
• Maintain lifecycle traceability. Use versioning, change history, SBOM/vulnerability context, and incident links to identify when an earlier approval needs review.
• Generate an inspectable case. Produce a current, traceable security view for product security, compliance, auditors, and program management instead of assembling a new spreadsheet for each request or review.

Uraeus AI can propose relevant threats, controls, or tests and flag missing links. Human owners remain responsible for legal interpretation, risk acceptance, privacy, and approval.

ThreatZ is not the customer identity provider, consent ledger, privacy-management platform, API gateway, or runtime detection system. It makes those systems' cybersecurity decisions traceable to the vehicle, risk, evidence, and lifecycle context. That is the commercially relevant gap for OEM CSMS teams: proving that secure vehicle-data access is part of the living cybersecurity case, not a disconnected compliance endpoint.

Frequently asked questions

Does the Data Act require OEMs to expose every vehicle signal?

No. Scope depends on the regulation's definitions and the data generated through use of the connected product or related service. Organizations should classify data carefully and distinguish readily available data from newly derived insights.

Can cybersecurity be used to refuse a request?

Security concerns should be specific, evidence based, and handled under the applicable legal conditions. A blanket statement that all vehicle data is sensitive is not a credible operating model. A safer representation or controlled access method may be possible.

How does the Data Act interact with GDPR?

The Data Act does not replace personal-data law. When requested vehicle data contains personal data, the parties still need a lawful basis, transparency, minimization, security, and data-subject protections.

What is the most important ThreatZ use case for Data Act readiness?

Build one Data Access Cybersecurity Case that links the dataset and API to architecture, threats, controls, tests, suppliers, software components, and incidents. That creates a reusable pattern for later services and recipients.

What is a good first pilot?

Independent repair, fleet maintenance, charging optimization, or roadside assistance can work well because the user value is clear and the required data can be bounded. Avoid beginning with a broad "all vehicle data" program.

Related reading on VxLabs

• ThreatZ integrations
• vulnerability disclosure
• X.509 certificates in automotive

Authoritative references

• European Commission guidance on vehicle data accompanying the Data Act
• Regulation (EU) 2023/2854 - the Data Act
• European Commission: Data Act explained
• European Commission Data Act policy page