ArabnaBook
Connect. Trade. Thrive
Why Your Next Car Is No Longer Just a Product — and What That Means for Ownership, Cost, and Control
For more than a century, a car was fundamentally a mechanical object. Even as electronics and computers were added, they remained subordinate to the hardware. Software existed to operate the machine, not to define what the machine was.
That relationship has now reversed.
During the early 2020s, without any single announcement or obvious breaking point, the automobile crossed a conceptual threshold. It stopped being primarily a machine that contains software and became a software platform that controls a machine.
Most buyers have not yet internalized this change. They still compare engines, cylinders, gearboxes, and trim levels. They still think of “features” as physical things that are either present or absent. They still assume that when they buy a car, they are buying a finished, stable product.
Increasingly, that assumption is wrong.
By 2026–2027, buying a new car will no longer mean buying a static object. It will mean entering into a long-term technical and commercial relationship with a manufacturer: their software platform, their update policies, their server infrastructure, and their product strategy.
Some of the most important characteristics of the car you buy will no longer be determined once at the factory. They will be shaped over time by:
Software updates
Licensing and feature entitlements
Subscription policies
Region-specific rules enforced through software
Corporate and regulatory decisions made years after purchase
This is not a hypothetical future. It is already happening.
The industry has a name for this transformation: the software-defined vehicle. Every major manufacturer now uses this language to describe the future of its products, including Volkswagen, Mercedes-Benz, BMW, Tesla, and others.
Volkswagen: https://www.volkswagen-group.com/en/news/software-is-the-key-to-the-mobility-of-tomorrow-16076
Mercedes-Benz: https://group.mercedes-benz.com/innovation/digitalisation/software-defined-vehicle.html
BMW: https://www.bmwgroup.com/en/news/general/2023/software-defined-vehicle.html
The term sounds abstract, but the underlying change is simple and far-reaching:
The identity, capabilities, and long-term value of a car are increasingly defined by software rather than hardware.
If you do not understand this shift, you will misjudge prices, misunderstand depreciation, and misunderstand what you are actually buying. And you will be surprised when your car changes in meaningful ways after you have already paid for it.
The term “software-defined” did not originate in the automotive world. It comes from data centers and telecommunications, where fixed-function hardware was replaced by general-purpose computing platforms controlled by software. Instead of building a separate physical device for every function, companies began building flexible hardware whose behavior could be reshaped by code.
The automotive industry is now undergoing the same transition.
Traditionally, a car was a collection of specialized electronic control units: one for the engine, one for the transmission, one for the brakes, one for airbags, several for infotainment, and so on. These units were often supplied by different vendors, ran separate software, and were only loosely coordinated.
That architecture had two important consequences:
Most of the vehicle’s behavior was fixed at production time.
Changing that behavior later was difficult, expensive, and risky.
A software-defined car is built on a different premise.
Instead of dozens of semi-independent computers, the vehicle uses a small number of high-performance centralized computing platforms — effectively automotive servers — that run many functions as software services. Features are no longer tightly bound to specific control units. They are abstracted, virtualized, and orchestrated in software.
A technical overview of this shift:
https://www.synopsys.com/automotive/what-is/software-defined-vehicle.html
In a software-defined car:
The same hardware can support different feature sets in different markets
Capabilities can be enabled or disabled by software configuration
Performance characteristics can be modified through updates
New features can be added years after production
Some features can be restricted or removed without changing hardware
Tesla demonstrated this model earlier than most legacy manufacturers, but nearly all major groups are now rebuilding their platforms around the same idea. Volkswagen’s entire software strategy is explicitly based on this transition:
https://www.volkswagen-group.com/en/news/cariad-the-software-company-of-volkswagen-group-15994
Cars have contained software for decades. What is new is not the presence of software, but the scope of what software is allowed to control.
In older vehicles, software configured hardware. In software-defined vehicles, software increasingly defines the vehicle.
In practical terms, this means:
The same physical car can be sold as multiple “models” differentiated primarily by software
Features can exist in the vehicle but remain locked behind code
Hardware capacity may be intentionally underused to support future paid upgrades
The boundary between “option,” “feature,” and “service” becomes blurred
A well-known consumer example:
https://www.theverge.com/2022/7/12/23205258/bmw-heated-seats-subscription
From the manufacturer’s perspective, this model is extremely attractive. It allows post-sale monetization, price segmentation, and regional differentiation. It also turns a one-time sale into an ongoing commercial relationship.
From the buyer’s perspective, it changes what ownership means.
To make this possible, manufacturers are abandoning the old “one ECU per function” model and moving toward centralized or zonal computing architectures.
Instead of:
70 to 150 small computers distributed throughout the vehicle
They are moving toward:
A few very powerful central computers
Connected to simpler input/output modules in different physical zones of the car
NVIDIA’s overview:
https://www.nvidia.com/en-us/self-driving-cars/vehicle-architecture/
This matters because it makes the car:
More like a general-purpose computing platform
Easier to update and reconfigure
More dependent on software quality and cybersecurity
More susceptible to post-sale changes in behavior and capability
It also makes it much easier for manufacturers to change what the product is after it has been sold.
This shift is not happening because automakers suddenly discovered a love for software. It is happening because the old architecture is collapsing under its own complexity.
Modern vehicles must simultaneously manage:
Emissions and efficiency
Electrification and battery management
Advanced driver assistance systems
Connectivity and infotainment
Cybersecurity
Regional regulatory compliance
Continuous updates
Trying to do this with dozens of loosely integrated control units and supplier-specific software stacks has become increasingly unmanageable.
The software-defined vehicle is, in part, an attempt to regain architectural control.
McKinsey’s analysis:
https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/the-software-defined-vehicle
For most of automotive history, buying a car meant making a set of decisions at the moment of purchase: engine, transmission, trim level, and a list of options. Once the vehicle left the showroom, those choices were largely permanent. The car you bought was the car you owned.
A software-defined vehicle breaks this logic.
In a software-centric architecture, the physical differences between trim levels are increasingly small. Manufacturers are moving toward building vehicles with largely uniform hardware configurations and using software to determine what is enabled, restricted, or available for later activation.
This is no longer a theoretical direction. It is already visible across multiple brands.
From an engineering and manufacturing perspective, reducing hardware variation is economically attractive. If most vehicles leave the factory with the same sensors, actuators, heating elements, motors, or battery packs, logistics, supply chains, and quality control become simpler and more predictable.
Software becomes the differentiation layer.
A feature can exist physically in the vehicle but remain inactive until it is enabled by software. This allows manufacturers to:
Sell essentially the same car at multiple price points
Offer post-purchase upgrades without physical modifications
Experiment with pricing models and regional restrictions
Create ongoing revenue streams from features that used to be one-time options
BMW’s attempt to sell heated seats as a subscription is the most widely cited example:
https://www.theverge.com/2022/7/12/23205258/bmw-heated-seats-subscription
But it is not unique.
Mercedes-Benz offers performance upgrades on some electric models as paid software unlocks:
https://www.motortrend.com/news/mercedes-eqs-acceleration-increase-ota-update/
Tesla has built a substantial part of its business model around selling software-locked capacity, performance upgrades, and driver assistance features:
https://www.tesla.com/support/software-updates
From a buyer’s perspective, this model changes how prices are perceived. The vehicle often appears cheaper at purchase because many capabilities are presented as optional activations rather than as part of the base configuration.
In practice, this is less about flexibility and more about unbundling.
Instead of buying a fully equipped car once, the buyer is pushed into a pattern of:
Repeatedly re-evaluating whether features are “worth it”
Paying separately for hardware that is already present in the vehicle
Accepting that the vehicle’s full capability set is provisional rather than fixed
This mirrors the evolution of consumer electronics and software markets, where products are increasingly sold as platforms with expandable and contractible feature sets rather than as finished objects.
In a software-defined product structure, the traditional notion of trim levels loses much of its meaning.
Instead of:
Base
Mid
Premium
The buyer increasingly gets:
A common hardware platform
A list of software-controlled entitlements
A mixture of permanent and time-limited licenses
From a manufacturing perspective, this is efficient. From a buyer’s perspective, it makes comparison and long-term value assessment more difficult.
Simple questions become harder to answer:
What does this car actually include?
Why is this configuration cheaper than that one?
What happens if subscriptions lapse?
Which functions will still work in ten years?
Public controversy has mostly focused on comfort features such as seat heating. But the same commercial logic is increasingly applied to more consequential systems, including:
Advanced driver assistance features
Certain performance or battery-related functions
Navigation and connected services
Remote access and app-based features
For example, General Motors’ Super Cruise and Ford’s BlueCruise are sold as subscription services after an initial trial period:
https://www.gm.com/stories/super-cruise
https://www.ford.com/technology/bluecruise/
When such subscriptions expire, the vehicle does not become unsafe, but it does revert to a less capable feature set. This is still a significant shift: functionality that many buyers intuitively think of as “part of the car” is now conditional on ongoing payment.
That represents a real change in the meaning of ownership.
This model also introduces a complication that used-car markets have only begun to confront.
Questions that barely existed before now matter:
Which features are permanently tied to the vehicle, and which are tied to the owner’s account?
Which subscriptions transfer to the next owner, and which do not?
Which features can be reactivated, and at what cost?
What happens if the manufacturer changes its policies or shuts down services?
In other technology markets, loss of functionality over time is normal. There is no technical reason vehicles are immune to the same dynamics.
From the manufacturer’s point of view, the attraction of this model is obvious.
Instead of:
A one-time sale every several years
They gain:
An ongoing revenue relationship
Recurring income streams
Post-sale price control
The ability to segment customers and feature access over time
McKinsey describes this as a central pillar of the industry’s future profit model:
https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/monetizing-car-software
To understand why software-defined cars change the buying decision so fundamentally, it is necessary to start with how they are built. They are not merely sold differently. They are engineered around a different organizing principle.
For decades, automotive electronics evolved in an additive way. Each new function received its own control unit: one for anti-lock braking, one for airbags, one for the engine, one for the transmission, several for infotainment, and many more besides. A modern premium vehicle could easily contain more than a hundred electronic control units supplied by dozens of vendors, each running its own software, communicating over several different in-vehicle networks (CAN, LIN, FlexRay, Ethernet).
This architecture made sense when cars were primarily mechanical systems with electronic assistance. It begins to fail when software becomes the core of the product.
By the late 2010s, manufacturers were hitting a wall. Adding a new feature increasingly meant coordinating changes across dozens of suppliers, ECUs, and incompatible software stacks. Update cycles were slow, integration was fragile, and failures were difficult to diagnose. Over-the-air updates were nearly impossible to implement consistently across the whole vehicle.
The software-defined vehicle is the industry’s response to this architectural limit.
In a software-defined vehicle, instead of many small, specialized controllers, the car uses a small number of high-performance central computing units. These are closer in nature to server-class or gaming-console-class systems-on-chip, often based on NVIDIA, Qualcomm, or custom silicon platforms.
Functions that previously lived in separate control units are now:
Virtualized
Isolated using hypervisors
Containerized or sandboxed
Scheduled and monitored like software services
Updated and maintained as part of a coordinated software stack
This is not just consolidation. It is a shift to a service-oriented architecture inside the vehicle, similar to how modern cloud systems are built.
Technical overviews:
NVIDIA: https://www.nvidia.com/en-us/self-driving-cars/vehicle-architecture/
Synopsys: https://www.synopsys.com/automotive/what-is/software-defined-vehicle.html
In practice, this means:
The same compute hardware can host infotainment, driver assistance, body control, and in some cases even powertrain functions
Safety-critical and non-safety-critical workloads are separated using virtualization and hardware isolation
Middleware layers abstract the hardware and standardize communication between software components
Adding or changing functionality increasingly means deploying new software rather than installing new hardware
This is why modern vehicles now require data-center-style software stacks, including update orchestration systems, rollback mechanisms, health monitoring, and cryptographic trust chains.
Centralization alone does not solve the wiring problem. Traditional vehicles run individual wire bundles from sensors and actuators to specific control units scattered throughout the car. This creates massive wiring harnesses that are heavy, expensive, and difficult to assemble.
Software-defined vehicles increasingly use zonal architectures.
Each physical zone of the car (for example, front left, front right, rear, cabin) has a relatively simple input/output controller. These zonal controllers aggregate local sensors and actuators and connect them to the central compute cluster over high-speed automotive Ethernet.
This approach reduces:
Wiring weight
Harness complexity
Assembly time
Manufacturing cost
And increases:
Architectural flexibility
Compute resource sharing
Fault isolation
Long-term scalability
Technical overview:
https://www.eetimes.com/zonal-architecture-is-the-future-of-automotive-electronics/
This is one of the reasons new EV platforms often advertise dramatic wiring reductions compared to older designs.
The most public demonstration of why this architectural shift is unavoidable came from Volkswagen.
Around 2020–2023, VW attempted to build a unified software platform (via its Cariad division) on top of largely legacy vehicle architectures. The result was massive delays to critical vehicle programs, including the Porsche Macan EV and Audi and VW next-generation platforms.
Reuters documented how software integration problems became a bottleneck for entire vehicle launches:
https://www.reuters.com/business/autos-transportation/vw-software-unit-cariad-faces-more-delays-2023-12-05/
Internally, VW discovered something uncomfortable: you cannot build a modern, continuously updateable software product on top of a fragmented, ECU-centric hardware architecture. The organizational failure was rooted in a technical one.
At the same time, Tesla demonstrated the opposite approach: a tightly integrated central compute architecture, a unified software stack, and full-vehicle OTA capability. This did not make Tesla perfect, but it made fast iteration possible in a way legacy architectures simply could not support.
Ford’s CEO Jim Farley has publicly stated that the company had to rethink its entire electrical architecture because its older designs made modern software development unmanageable:
https://www.theverge.com/2023/6/15/23761861/ford-software-defined-vehicle-architecture
This is the background reality behind the industry-wide pivot to centralized and zonal designs.
This architectural change has direct consequences for the product you are buying.
First, hardware becomes more generic. The same compute platforms are often used across multiple models and sometimes across multiple brands within a corporate group. Differentiation moves primarily into software configuration.
Second, capabilities are no longer frozen at the moment of production. Because the vehicle is designed as a software platform, manufacturers can add, modify, or restrict functions years after the car is built.
Third, long-term value increasingly depends on software support rather than only on mechanical durability.
In a 2010 car, a 15-year-old engine that still runs is a valuable asset.
In a 2027 software-defined car, a 15-year-old compute platform that no longer meets security or performance requirements may be a serious liability.
Once you centralize computing, you inevitably end up building something that is, in effect, a vehicle operating system.
Instead of dozens of loosely related software stacks, the car increasingly runs a unified platform responsible for:
Hardware abstraction
Process scheduling and isolation
Security and cryptographic identity
Software update management
Application deployment and rollback
Inter-process communication
Examples:
Volkswagen (VW.OS / Cariad): https://www.volkswagen-group.com/en/news/cariad-the-software-company-of-volkswagen-group-15994
Mercedes-Benz (MB.OS): https://group.mercedes-benz.com/innovation/digitalisation/mbos.html
BMW software platform: https://www.bmwgroup.com/en/news/general/2023/software-defined-vehicle.html
This is not marketing language. It is a direct consequence of running most of the vehicle’s behavior on general-purpose computing hardware.
Once a car has an operating system, it also inherits all the properties of computing platforms: update cycles, deprecation, compatibility layers, performance ceilings, and security lifecycles.
Just as early smartphones eventually became too slow for modern apps, vehicles with insufficient compute headroom will eventually hit a ceiling.
Tesla has already had to retrofit older vehicles with new infotainment computers to keep them compatible with newer software:
https://www.tesla.com/support/infotainment-upgrade
This is a preview of a future where mid-life compute upgrades become a normal part of vehicle ownership.
In a software-defined vehicle, you are no longer primarily buying:
An engine
A gearbox
A fixed set of physical options
You are increasingly buying:
A compute platform
A sensor and actuator set
A software stack
A development and support roadmap controlled by the manufacturer
Two cars with identical hardware can diverge significantly over time depending on:
Update policies
Regulatory constraints
Business decisions
Platform evolution strategies
From the buyer’s perspective, this means the vehicle’s future trajectory matters almost as much as its current specification.
When you walk into a dealership in 2026 or 2027 and buy a modern car, the transaction will still look familiar. You will sign papers. You will pay money. You will receive a vehicle.
But legally, technically, and practically, you will not be buying what buyers used to buy.
In a software-defined vehicle, the product you receive is no longer a single, unified object. It is a stack of systems, each governed by different rules and enforced by different technical mechanisms. Some parts behave like traditional property. Others behave like licensed software. Others behave like cloud services. These layers are tightly integrated, but they are not owned in the same way.
From an engineering perspective, the car is now closer to a distributed computing system than to a standalone machine. Part of it runs in the vehicle. Part of it runs in data centers. Part of it lives in identity, entitlement, and provisioning systems. The buyer experiences one product, but the architecture is fragmented by design.
Understanding this stack is now essential to making a rational purchasing decision, because failures, limitations, and loss of functionality almost always originate in one specific layer, not in the mechanical vehicle as a whole.
At the base, you still own the physical vehicle:
The body and structure
The chassis
The motors or engine
The battery or fuel system
The sensors and actuators
The wiring harnesses
The computing hardware
This layer still behaves like traditional property. You can sell it, store it, modify it, or scrap it.
But architecturally, this hardware is no longer a self-contained product. It is a general-purpose execution platform for software.
Modern vehicles are designed with significant hardware headroom: more compute capacity, more sensors, more power electronics capability, and sometimes even more battery capacity than is required for the base configuration. This is done intentionally to reduce manufacturing variation and to allow future software activation.
As a result, your car may physically contain:
More battery capacity than is enabled in software
More performance capability than the control software allows
More sensors than are currently used by your feature set
More compute resources than your current software profile can access
The hardware is present. The feature gates are in software.
Technically, these limitations are enforced through calibration tables, configuration flags, cryptographic feature masks, and secure boot chains. In many systems, even if you modify the software, the vehicle will refuse to load it unless it is signed and authorized.
This is why unlocking features is no longer a mechanical act. It is a cryptographic and server-mediated act.
Almost all vehicle behavior is controlled by software running across multiple compute domains: infotainment, ADAS, body control, chassis control, battery management, and increasingly even powertrain management.
Legally, this software is not sold to you. It is licensed.
This is not just a legal detail. It is an architectural one.
Modern vehicles use:
Secure boot chains
Hardware security modules (HSMs)
Code signing and signature verification
Encrypted storage and communications
Partitioned and sandboxed execution environments
These systems ensure that only manufacturer-authorized software can run on the vehicle.
From a technical standpoint, this means the manufacturer retains root authority over the computing platform. Even if you physically own the computer, you do not control the trust anchors that decide what code is allowed to execute.
This is the same model used in smartphones, game consoles, and enterprise servers.
The agricultural industry encountered this earlier. John Deere tractors will not accept unauthorized software or parts without digital authentication. Cars are now built using the same security architecture.
This is not primarily about monetization. It is about system integrity, liability control, and cybersecurity. But the side effect is the same: the manufacturer never fully relinquishes control of the software platform.
On top of the base software stack sits a feature provisioning and entitlement system.
This layer determines:
Which ADAS functions are active
Which comfort features are enabled
Which performance limits are applied
Which UI features are accessible
Which compute resources are allocated to which functions
Technically, these are controlled through:
Cryptographically signed configuration bundles
Vehicle identity certificates
Account-linked entitlements stored in backend systems
Regional and regulatory policy profiles
Secure provisioning workflows during manufacturing and after sale
In many modern vehicles, the car periodically synchronizes its entitlement state with manufacturer servers. The backend systems, not the car itself, are the source of truth for what the vehicle is allowed to enable.
This is why two physically identical cars can behave differently, and why features can appear or disappear after an update.
Tesla, Mercedes, BMW, and others already operate this way.
At a systems level, the car is no longer a static product. It is a managed node in a fleet-wide software and policy infrastructure.
Above the feature-entitlement layer sits a layer of service dependencies.
In a software-defined vehicle, a growing number of functions are no longer implemented entirely inside the car. Instead, they are split across on-board software components and off-board cloud systems operated by the manufacturer or its partners. Architecturally, the car is no longer a closed system. It is a client in a distributed system.
Many modern vehicle features are not self-contained. They depend on:
Cloud-based map services
Traffic and routing backends
Voice recognition servers
Remote access APIs
Telemetry ingestion systems
Driver assistance data pipelines
In practice, this means that the vehicle is continuously authenticating itself, negotiating access, and exchanging data with remote services. The software running in the car often acts as an orchestrator that coordinates between local sensors, local compute, and remote inference or data services.
Access to these services is controlled through time-limited tokens, certificates, and account subscriptions.
From a technical perspective, this is implemented using mechanisms that are already standard in large distributed systems: OAuth-style token issuance, mutual TLS authentication, rotating certificates, and backend-side policy enforcement. The car is not “checking a setting”. It is requesting permission from an external authority to continue using parts of its own feature set.
When a subscription expires, several things can happen technically:
Authentication tokens are no longer issued
API access is refused
Backend-dependent features fail gracefully or are disabled
UI elements are removed or greyed out
Local fallback modes (if any) are activated
In many cases, the software is designed to degrade in stages. First, warnings appear. Then certain features stop updating. Finally, entire functions are disabled because they can no longer complete their backend calls.
From the user’s point of view, the feature simply disappears.
The car has not changed. The service graph around it has.
This also means that availability, latency, and reliability of remote systems become part of the vehicle’s functional quality. A navigation system that depends on a cloud backend is not just a piece of software in your car. It is a contract between your vehicle and a live infrastructure that must be operated, secured, and funded for many years.
In a software-defined vehicle, there is now a structural separation between:
Physical capability
Software implementation
Policy permission
This three-layer split is one of the most important conceptual changes in the modern automobile.
The hardware may be capable. The software may contain the code. But the policy layer decides whether the function is allowed to run, under what conditions, in which region, and for which user account.
This is not a simple “on/off switch”. In most modern platforms, policy decisions are enforced at multiple layers: during boot, during feature initialization, and sometimes continuously during runtime.
This is enforced through:
Secure boot and runtime attestation
Feature gating in middleware layers
Certificate and entitlement checks
Backend authorization systems
In practice, this means that even if a function is present in the software and even if the hardware supports it, the system can still refuse to activate it because the policy authority says no.
This is why two identical cars can have different functionality for their entire lifetime, even if they never diverge mechanically.
After purchase, the manufacturer can modify the vehicle by changing:
Software binaries
Configuration bundles
Calibration data
Feature entitlement profiles
Backend service behavior
Policy enforcement rules
All without touching the hardware.
From a systems engineering point of view, the car is treated as a managed endpoint in a large fleet. It receives configuration, code, and policy updates just like a server, a phone, or an industrial machine.
Technically, this happens through OTA update pipelines that can:
Update individual partitions or containers
Roll back failed updates
Migrate data schemas
Change inter-service contracts
Deprecate or replace components
Modern vehicle software stacks are explicitly designed to support continuous evolution. They contain multiple redundant partitions, versioned APIs between internal services, and update orchestration systems that can coordinate complex multi-stage upgrades.
From the vehicle’s point of view, this is normal platform maintenance.
From the owner’s point of view, it is product mutation after purchase.
In a software-defined car, failure no longer only means “something broke”.
It can also mean:
Certificate expiration
Backend service shutdown
API contract changes
Security policy tightening
Platform deprecation
Compute resource exhaustion
These are not theoretical failure modes. They are routine events in large-scale software systems.
What makes them new in the automotive context is that any one of them can partially or completely remove functionality from a mechanically perfect vehicle.
A car can be fully drivable, fully charged, and physically intact, and still lose major features because a digital dependency somewhere in its ecosystem has failed or been withdrawn.
By 2026–2027, a rational buyer must start asking questions like:
How long is this compute platform supported?
How long are certificates and trust roots valid?
Which features require backend services?
Which features are purely local?
Which entitlements are stored in the car, and which only in the cloud?
What happens when backend APIs are retired?
Is there a documented decommissioning policy?
These are not abstract questions. They are questions about system architecture, dependency management, and long-term operability.
If these questions cannot be answered, it means the true product lifecycle is undefined — and that is a very different risk profile from anything car buyers have historically dealt with.
You still own the machine.
But the machine is now a managed, authenticated, policy-governed computing platform.
And control of that platform is shared — and in many cases dominated — by whoever controls the software update, identity, and entitlement infrastructure.
That is the real technical meaning of a software-defined car.
In a mechanical car, aging is primarily physical. Parts wear out. Corrosion spreads. Rubber hardens. If you maintain the machine, it can often remain functionally complete for decades. A thirty-year-old car may be less comfortable or less efficient, but it is still recognizably the same product it was when new.
A software-defined car ages in a completely different way.
Its most critical components are not pistons, bearings, or gears. They are compute platforms, operating systems, and software stacks. And software does not age gracefully. It is either maintained, or it becomes obsolete very quickly.
This creates a new and deeply underappreciated ownership risk: functional decay without mechanical failure.
Every complex software platform has a lifecycle:
Initial development
Rapid improvement
Stabilization
Maintenance-only mode
End-of-support
Once a platform reaches end-of-support, several things begin to happen:
Security vulnerabilities are no longer patched
Compatibility with new services degrades
Online features start failing
Integrations with phones, apps, and infrastructure break
Some systems may be deliberately disabled for liability reasons
This is not unique to cars. It is standard in phones, computers, routers, and industrial equipment.
The difference is that cars are expected to last 10–20 years.
Manufacturers like to compare cars to smartphones. This is misleading in a critical way.
A smartphone is designed to be replaced every 3–6 years. A car is not.
Yet many automotive software platforms are being built with similar assumptions about support cycles.
Volkswagen’s own internal software struggles and delays are well documented:
https://www.reuters.com/business/autos-transportation/vw-software-unit-cariad-faces-more-delays-2023-12-05/
Mercedes-Benz and BMW are building entirely new operating systems (MB.OS, BMW OS) precisely because older platforms cannot evolve fast enough.
Mercedes MB.OS:
https://group.mercedes-benz.com/innovation/digitalisation/mbos.html
BMW software platform:
https://www.bmwgroup.com/en/news/general/2023/software-defined-vehicle.html
This should immediately raise a buyer’s question:
What happens to the previous generation of cars when the platform strategy changes?
In a software-defined car, updates generally fall into several categories:
Security updates (fix vulnerabilities)
Stability updates (fix bugs)
Feature updates (add or change functionality)
Regulatory updates (change behavior to comply with new laws)
Commercial updates (change what is paid, free, or restricted)
Tesla’s update history shows how dramatic these changes can be:
https://www.tesla.com/support/software-updates
In some cases, updates have:
Increased range or performance
Reduced charging speed to protect battery health
Changed user interface layouts
Modified driver assistance behavior
Removed features entirely
The important point is that updates are not inherently improvements. They are policy changes implemented through software.
Unlike mechanical parts, computing hardware becomes obsolete not because it wears out, but because it becomes insufficient for new software.
This has already happened in the automotive world.
Early Tesla Model S vehicles, for example, had to have their infotainment computers replaced to support newer software features:
https://www.tesla.com/support/infotainment-upgrade
This creates a new class of mid-life “digital engine replacement”: the computer upgrade.
As AI, graphics, and user interface demands grow, many 2026–2027 cars will hit the same wall.
Many software-defined car features are not fully contained in the car. They depend on:
Manufacturer servers
Map providers
Voice recognition services
Media streaming platforms
Remote control APIs
If any of these services are shut down or changed, features can partially or completely stop working.
This is not theoretical. It has already happened in other connected devices and early connected cars.
A general overview of connected vehicle cloud dependence:
https://www.synopsys.com/automotive/what-is/connected-car.html
In a software-defined car, end of support will likely not mean that the car stops working overnight.
It will look more like this:
New phones stop pairing properly
Navigation data becomes outdated
Voice assistants stop responding
Remote app features stop working
Some safety or assistance features are limited or disabled
Security risks accumulate
The car still drives. But it is no longer the product you bought.
Traditionally, a car’s value depended on:
Mileage
Condition
Brand reputation
Mechanical reliability
In the software-defined era, a new variable appears:
Platform relevance.
A car that is mechanically perfect but digitally obsolete will depreciate much faster than buyers expect.
Used-car markets have not yet fully priced this in.
In 2026–2027, you should start explicitly asking:
How long is this software platform supported?
How long are security updates guaranteed?
Are compute upgrades possible? At what cost?
Which features depend on cloud services?
Which features will degrade if support ends?
Does the manufacturer have a credible long-term software track record?
Manufacturers rarely advertise this clearly, for obvious reasons.
In a traditional car, the boundary between the manufacturer and the owner was relatively clear. Once the vehicle left the factory, the manufacturer’s control over it was mostly indirect. They supplied parts, published service manuals, and issued recalls, but they did not mediate every significant interaction between the car and the workshop. Independent garages could diagnose problems, replace components, and return the vehicle to service without asking permission from a central server.
A software-defined car breaks this model at a fundamental level.
The reason is not political or ideological. It is architectural. In a software-defined vehicle, the behavior of the car emerges from the interaction between tightly integrated software systems, calibrated sensors, cryptographically paired control units, and centralized computing platforms. You cannot simply replace a part and expect the system to accept it as if nothing happened.
Consider something as simple as a modern windshield. In many current vehicles, the windshield is not just glass. It is an optical component of the perception system. Cameras for lane keeping, emergency braking, and traffic sign recognition are mounted to it and calibrated against it. Replacing the windshield is no longer a mechanical operation. It is a mechatronic and software procedure that requires precise recalibration using manufacturer-specific tools and software.
The same is increasingly true for bumpers, headlights, steering components, suspension modules, battery packs, and even seats, if they contain sensors related to airbags or driver monitoring.
But calibration is only the visible part of the transformation.
Underneath it lies a deeper change: the growing use of cryptographic pairing and component authentication. Many modern control units will not function fully, or at all, unless they are digitally authorized by the vehicle’s central system or by the manufacturer’s backend servers. This is done partly for security reasons and partly for configuration control, but the effect is the same: a component is no longer just a component. It is a licensed participant in a software ecosystem.
This means that in many 2026–2027 vehicles, replacing a control unit, a battery module, a steering rack, or even a headlight may require online access to the manufacturer’s systems to:
Register the part
Unlock its functions
Load the correct software
Apply cryptographic certificates
Integrate it into the vehicle configuration
From the point of view of the manufacturer, this is logical. From the point of view of long-term ownership, it is a structural dependency.
This is not speculative. It is already common practice in many brands today.
An overview of secure vehicle architectures and component authentication:
https://www.synopsys.com/automotive/what-is/automotive-cybersecurity.html
The practical consequence is that diagnostics and repair are increasingly moving away from universal tools and toward brand-specific, cloud-connected service platforms. The “OBD scanner” model of troubleshooting is slowly becoming inadequate for anything beyond superficial fault reading.
Even when a physical problem exists, the car may refuse to operate normally until its software state is restored to a condition that the manufacturer considers valid.
This creates a new form of failure mode: a car that is mechanically repairable but digitally locked.
The Right to Repair movement has emerged precisely because of this trend, not only in cars but in tractors, phones, and industrial equipment:
https://www.repair.org/stand-up
https://www.ifixit.com/Right-to-Repair
In the automotive context, the stakes are higher, because vehicles are high-value, long-lived assets. A dependency that might be tolerable in a smartphone becomes economically dangerous in a car that is expected to last fifteen years.
What makes software-defined cars particularly challenging is that this dependency is not accidental. It is a direct and intentional consequence of their architecture. Once a vehicle is designed as a coordinated software system rather than a collection of semi-independent parts, some central authority must manage coherence. Today, that authority is almost always the manufacturer.
This leads to a quiet but profound shift in the balance of power. The manufacturer is no longer just the original producer of the car. They become the ongoing operator of the platform on which the car runs.
For the buyer, this means that the question “Can this car be repaired?” is being replaced by a more subtle and more important question:
Will this car still be supported?
A mechanically simple failure in a software-defined vehicle can be economically total if the platform that authorizes its components is no longer maintained or accessible.
The moment a car becomes software-defined, it also becomes something else by necessity: a networked computer system. It communicates continuously with manufacturer servers, mapping providers, app ecosystems, diagnostic platforms, update infrastructure, and sometimes even other vehicles. This connectivity is not an accessory. It is a structural requirement of how modern vehicles are now designed, maintained, and monetized.
Once this happens, the problem of vehicle safety expands beyond mechanics and electronics into the domain of cybersecurity.
In a traditional car, the attack surface was almost entirely physical. To interfere with the vehicle, one had to be physically present. In a software-defined car, the attack surface includes:
Cellular modems
Wi-Fi and Bluetooth stacks
Update mechanisms
App interfaces
Cloud APIs
Diagnostic gateways
Each of these is a potential entry point.
This is not a theoretical concern. Researchers have demonstrated remote compromises of vehicle systems for more than a decade. The famous Jeep Cherokee hack in 2015 showed that it was possible to remotely control steering and braking through the infotainment system:
https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
Since then, the industry has invested heavily in automotive cybersecurity, but the underlying reality has not changed: a connected car is an attackable system.
An overview of modern automotive cybersecurity architecture:
https://www.synopsys.com/automotive/what-is/automotive-cybersecurity.html
To manage this risk, software-defined vehicles are built around layered security models. They use secure boot chains, hardware security modules, encrypted communications, code signing, and continuous integrity checks. Every update must be cryptographically verified. Every critical control unit must prove that it is running authorized software.
This is one of the reasons why component replacement and repair have become so tightly controlled. From a security perspective, an unauthorized or modified control unit is not just a part. It is a potential attack vector.
But security is only one side of the issue.
A software-defined car necessarily produces vast amounts of data. To function as designed, it must record, process, and sometimes transmit:
Sensor data
Diagnostic logs
Usage statistics
Location history
Driver behavior metrics
System performance data
Some of this data is processed locally. Some is uploaded to manufacturer servers. Some is stored temporarily. Some is stored for years.
Manufacturers justify this collection for several reasons: improving reliability, detecting failures, training future systems, and providing customer services. All of these are real. But they do not change the core fact that the modern car is one of the most comprehensive behavioral data collection devices most people will ever own.
Mozilla’s analysis of car privacy practices is blunt and deeply concerning:
https://foundation.mozilla.org/en/privacynotincluded/categories/cars/
In many cases, car data privacy protections are weaker than those applied to smartphones or computers, even though the data collected is often more intimate and more revealing.
Once a car is permanently connected and software-defined, the manufacturer gains a new kind of power: remote authority.
They can:
Push updates
Change behavior
Disable features
Restrict usage
Enforce compliance
In extreme cases, immobilize the vehicle
Some of this is done for safety or legal reasons. Stolen vehicles can be tracked or disabled. Dangerous software faults can be mitigated quickly. Regulatory changes can be enforced.
But from a legal and philosophical point of view, this represents a profound shift. The car is no longer an object that is fully under the physical control of its owner. It is a node in a managed network.
Tesla’s ability to remotely disable or restrict features is well documented:
https://www.teslarati.com/tesla-remotely-disable-used-car-supercharging/
As vehicles become software-defined, regulation increasingly takes the form of software constraints rather than mechanical rules.
Speed limits, emissions behavior, geofencing, driver monitoring requirements, and usage restrictions can all be enforced algorithmically. This is more precise and more scalable than traditional enforcement, but it also means that compliance is built into the machine itself.
The European Union’s mandatory driver monitoring and speed assistance systems are an early example:
https://transport.ec.europa.eu/transport-themes/road-safety/vehicle-safety/driver-assistance-systems_en
A software-defined car must be continuously updated to remain secure. An unpatched vehicle is not just outdated. It is a liability.
This creates a new kind of dependency: even if your car works perfectly, you may be forced to accept updates to keep it legal, insurable, or functional. Those updates may also change behavior, remove features, or introduce new restrictions.
By 2026–2027, buying a software-defined car means accepting that:
You are not just buying a machine.
You are joining a governed digital ecosystem.
The rules of that ecosystem can change.
In the mechanical era of automobiles, evaluating a car was largely a matter of assessing tangible things. You looked at the engine, the transmission, the build quality, the reputation of the brand, and the cost of maintenance. Even when electronics became widespread, they were still secondary to the physical machine. A good engine in a well-built car could remain a good engine for decades, largely independent of the manufacturer’s future decisions.
A software-defined car cannot be evaluated this way.
When software becomes the core of the vehicle’s identity, the long-term value of the product depends less on what is installed in the car today and more on the trajectory of the platform that controls it. You are no longer simply buying a machine. You are buying into a technical and organizational ecosystem whose future you do not control.
The first and most important thing to understand is that two cars that look identical on the showroom floor may not be the same product over the course of their lives. In a software-defined architecture, the present state of the vehicle is only a snapshot. Its future behavior will be shaped by update policies, business strategies, regulatory changes, and the evolution of the manufacturer’s software stack. This means that a rational buyer must begin thinking in terms of platform risk rather than just mechanical risk.
One of the most revealing questions is not about horsepower or screen size, but about the manufacturer’s software competence and history. Building and maintaining large, long-lived software platforms is not a skill that traditional car companies historically needed. Some have adapted quickly. Others have struggled visibly and publicly. The delays and internal crises around large in-house software programs, such as Volkswagen’s Cariad division, are not just corporate drama. They are signals about how stable and coherent a given platform strategy really is. A car built on a platform that is already being restructured or replaced inside the company is a car whose long-term support is uncertain. An overview of these struggles is well documented in reporting such as Reuters’ coverage of Cariad’s delays: https://www.reuters.com/business/autos-transportation/vw-software-unit-cariad-faces-more-delays-2023-12-05/
Another critical dimension is the update philosophy of the manufacturer. Some companies treat updates primarily as a way to fix bugs and close security holes. Others treat them as a way to continuously reshape the product, experiment with business models, and adjust functionality over time. Tesla is the most visible example of the latter approach, where vehicles have seen substantial changes in behavior, interface design, and feature availability years after purchase through over-the-air updates: https://www.tesla.com/support/software-updates The question a buyer must implicitly answer is whether they are comfortable owning a product whose behavior is not stable and whose evolution is not fully under their control.
Closely related to this is the issue of support lifetime. Every software platform eventually reaches a point where it stops receiving meaningful updates. In consumer electronics, this is accepted because devices are replaced frequently. Cars are not. Yet many automotive software stacks are being developed with technology and organizational structures that resemble consumer electronics more than long-lived industrial systems. Manufacturers such as Mercedes-Benz and BMW are now building entirely new operating systems, MB.OS and BMW OS, precisely because older architectures cannot be extended indefinitely. This should immediately raise a buyer’s concern about what happens to vehicles built on the previous generation of platforms. Mercedes’ own description of MB.OS makes it clear how central and long-term this transition is supposed to be: https://group.mercedes-benz.com/innovation/digitalisation/mbos.html
A software-defined car must also be evaluated in terms of what is local and what is remote. Some features run entirely inside the vehicle. Others depend on cloud services that the manufacturer or its partners operate. Navigation, voice assistants, remote apps, traffic services, and sometimes even parts of driver assistance systems rely on external servers. If those services are changed, degraded, or discontinued, the car changes with them. This is not a hypothetical scenario. It is a normal lifecycle event in the software industry. A general overview of how connected cars depend on cloud infrastructure can be found here: https://www.synopsys.com/automotive/what-is/connected-car.html The practical implication is that a buyer must start thinking not just about the car, but about the durability of the service ecosystem around the car.
Another dimension that did not exist in the mechanical era is feature stability. In a software-defined vehicle, features are not only added. They can also be modified, restricted, or removed. Sometimes this is done for safety or regulatory reasons. Sometimes it is done for commercial reasons. The legal structure that governs most in-vehicle software is not a sale but a license. That means the manufacturer retains far more control over the behavior of the product after purchase than most buyers intuitively expect. This is not unique to cars, but it is far more consequential when applied to a high-value, long-lived asset.
The buyer must also consider the compute margin built into the vehicle. Just as early smartphones eventually became too slow for modern software, cars with insufficient computing headroom will hit a ceiling where new features, better interfaces, or improved driver assistance systems are simply not feasible. Tesla’s need to retrofit older vehicles with new infotainment computers is an early example of this phenomenon: https://www.tesla.com/support/infotainment-upgrade When evaluating a car in 2026 or 2027, the question is not only whether the hardware is good enough today, but whether it is likely to remain adequate for the next ten years of software evolution.
Finally, and perhaps most importantly, a buyer must confront the question of control. A software-defined car is, by design, a governed system. It is subject to remote updates, policy enforcement, and technical constraints imposed by its maker. This can bring real benefits in safety and functionality. It also means that ownership is no longer absolute in the way it once was. The car is not just an object. It is a participant in a managed digital environment.
Evaluating a software-defined car in 2026–2027 therefore requires a shift in mindset that is deeper than most buyers currently realize. You are not choosing between engines and options. You are choosing between platforms, software strategies, and long-term technical governance models. The mechanical qualities still matter, but they are no longer the dominant factor in determining what your car will become over its lifetime.
Part 9: The New Reality of Ownership — What It Means to Buy a Car in the Software Age
For more than a century, the automobile was defined by its material nature. It was steel, rubber, fuel, and motion. Its value degraded in visible, physical ways. You could hear problems, smell them, feel them through the steering wheel. Even when electronics became common, they were still subordinate to the machine. The essence of the car remained mechanical.
The software-defined car breaks that continuity.
What you buy in 2026 or 2027 will still look like a car, and in many ways it will still behave like one, but its identity will be fundamentally different. Its most important characteristics will not be frozen at the factory. They will live in code. They will evolve, sometimes improve, sometimes degrade, sometimes change for reasons that have nothing to do with engineering and everything to do with business, regulation, or liability.
This is not a minor shift. It is a change in the nature of the product itself.
A software-defined car is not a finished object. It is a managed system. It exists in a continuous relationship with the organization that built it, with the servers that support it, and with the policies that govern its behavior. Ownership, in the old sense, becomes a weaker concept. You possess the hardware, but you participate in the software.
This has consequences that reach far beyond features and screens.
The value of a car is no longer determined primarily by the durability of its mechanical parts. It is increasingly determined by the longevity and coherence of its software platform. A mechanically healthy car can become functionally diminished if its digital environment decays. A car that is physically identical to another can be a different product in practice because its software entitlements, update history, or platform generation are different.
In this world, obsolescence is no longer something that happens only when metal wears out. It can happen when support ends, when cloud services are withdrawn, when security standards move on, or when the internal architecture of the manufacturer’s ecosystem leaves a generation behind.
The most unsettling aspect of this transition is not technical. It is psychological.
Buyers are still trained, culturally and emotionally, to think of cars as objects. But software-defined cars are closer to infrastructures. They are closer to operating environments. They are closer to platforms. You do not simply own them. You inhabit them.
This does not make them worse. In many ways, it makes them more capable, more adaptable, and potentially safer. But it does make them less final.
There is no longer a clear moment when a car is “done.”
From the manufacturer’s point of view, this is a triumph of flexibility and control. From the buyer’s point of view, it is a new kind of dependency. The long-term quality of the product you own is now tied to the long-term quality of an organization’s software culture, security discipline, update policy, and strategic consistency.
Some companies will be good at this. Some will not. And the difference will matter far more than most buyers currently realize.
The uncomfortable truth is that in the second half of the 2020s, choosing a car increasingly means choosing a technology governance model. It means choosing how much power you are willing to cede to the maker of the system. It means choosing how much instability you are willing to accept in exchange for continuous improvement. It means choosing whether you prefer a product that is fixed and finite, or one that is fluid and negotiated.
None of this is visible in a test drive.
It is visible only in history, in corporate behavior, in platform strategies, and in how companies treat products after they have been sold.
In the mechanical era, a good car was one that was well built. In the software-defined era, a good car is one that belongs to a healthy ecosystem.
This is the real shift. And this is why buying a car in 2026 or 2027 is no longer the same act it was even ten years earlier.
You are not just choosing transportation.
You are choosing a future relationship with a system that will, in subtle and not-so-subtle ways, continue to shape what your car is long after you have paid for it.
Software-defined vehicles (Synopsys):
https://www.synopsys.com/automotive/what-is/software-defined-vehicle.html
Volkswagen software strategy (Cariad):
https://www.volkswagen-group.com/en/news/cariad-the-software-company-of-volkswagen-group-15994
Reuters on VW software delays:
https://www.reuters.com/business/autos-transportation/vw-software-unit-cariad-faces-more-delays-2023-12-05/
Mercedes-Benz MB.OS:
https://group.mercedes-benz.com/innovation/digitalisation/mbos.html
BMW software-defined vehicle strategy:
https://www.bmwgroup.com/en/news/general/2023/software-defined-vehicle.html
NVIDIA vehicle architecture:
https://www.nvidia.com/en-us/self-driving-cars/vehicle-architecture/
Connected cars and cloud dependency:
https://www.synopsys.com/automotive/what-is/connected-car.html
Tesla software updates:
https://www.tesla.com/support/software-updates
Tesla infotainment computer upgrade:
https://www.tesla.com/support/infotainment-upgrade
Automotive cybersecurity overview:
https://www.synopsys.com/automotive/what-is/automotive-cybersecurity.html
Car data privacy (Mozilla):
https://foundation.mozilla.org/en/privacynotincluded/categories/cars/
