How software-defined vehicles are reshaping the automotive value chain
The end of the bundle: Software monetization challenges for automotive Tier‑1 suppliers
As OEMs unbundle hardware and software, Tier-1 suppliers face a new monetization reality
For decades, automotive Tier-1 suppliers sold hardware and software as a single, inseparable proposition. The electronic control unit (ECU) came with its embedded software. The sensor came with its perception stack. The telematics control unit (TCU) came with its application layer. Software-defined vehicle (SDV) architectures did not yet exist at scale, alternative suppliers capable of providing software independently were limited, and original equipment maufacturers (OEMs) lacked the purchasing sophistication to source these components separately. The bundle was the only practical option.
That era is over. The software revenue attributable to traditional hardware/software bundles is on a trajectory of 24% compound annual decline through 2030. Software as a Product/Software as a Service (SaaP/SaaS) models are growing at 11% annually, software engineering services at 9%, and OEM in-house development at 25% per year. The market is moving away from the bundled model toward channels that Tier-1 suppliers have not historically owned.
"We are seeing real pressure in actual RFQs from the largest OEMs to Tier-1 suppliers to sell software separately. These examples are no longer limited to ADAS and infotainment."
From delayed threat to live pressure
The unbundling thesis had long circulated through industry conferences and strategy decks without translating into meaningful commercial disruption. Roll-out of SDV architectures was slow and technically troubled. OEM software purchasing functions lacked organizational maturity to specify and source software components independently. Suppliers could, in practice, defend their bundles.
The conditions have changed as of 2025/2026. Procurement decisions already underway confirm this. A European OEM is sourcing perception software independently from camera hardware, reducing the sensor to a passive component. Another OEM has separated telematics applications from the TCU, adopting a simplified hardware unit and contracting the software layer separately. Seat control software is being procured independently from ECUs and integrated into dedicated body and comfort high-performance computers. A North American OEM has eliminated the standalone ECU for running boards and is sourcing the deployment logic separately, folding it into Body Control Modules. A European OEM is moving to source driver monitoring algorithms independently, replacing an integrated rearview mirror with a simplified mirror and a “dumb” camera unit.
These are not pilot programs. They are active sourcing decisions, occurring across multiple system domains and in both European and North American markets.
What the bundle was concealing
In the bundled model, the hardware/software package gave Tier-1 suppliers a claim on the full software-related content per vehicle (CPV). Disaggregated sourcing reduces that claim substantially. As hardware is commoditized, only part of the original CPV remains addressable by the supplier, with Tier-2s absorbing a larger share.
Cost transparency moves in the opposite direction. The bundled model limited OEM visibility into engineering, design and development (EDD), hardware, and software costs. OEMs could not build credible should-cost models for the software component, could not negotiate on software-specific terms, and had no basis for credibly threatening to source from an alternative vendor. In the new model, OEMs are actively learning cost structures and engaging directly in Tier-2 negotiations. The opacity that protected Tier-1 margins is eroding.
Scale requirements shift as well. In the bundled period, software scale was effectively inherited: hardware program volumes carried software along, and competing on system integration and domain know‑how was sufficient. In contrast, standalone SaaP and SaaS models require upfront investment that must be recovered across multiple programs and customers. Most Tier-1s have not yet built software businesses at the volume needed for that recovery to work.
The warranty position deteriorates in a specific way. The traditional model balanced front-line warranty responsibility with genuine control over Tier-2 components. In the new model, that responsibility remains while the control does not. Tier-1s are now required to integrate software and hardware components they did not select.
The business model moves from a single, integrated structure to a mix of SaaP, SaaS, licensing, and engineering services. Each carries different ownership terms, pricing logic, and margin profiles.
The profitability consequence is the sharpest contrast. In the bundled period, Tier-1 EBIT ran above 7%, above the supplier industry average. Under the disaggregated model, EBIT becomes highly variable and scale dependent. Where a supplier lands depends on whether it has built the commercial infrastructure to compete on software terms.
The alternatives OEMs already have
Where existing suppliers cannot separate software from hardware, OEMs will find vendors who never bundled them in the first place. Pure software players supply individual features and system integration support without any hardware attachment. Technology companies offer software architectures and middleware. Semiconductor companies provide software reference platforms alongside their silicon. OEM in-house development teams represent a different substitution risk: capability built internally is not typically rebought from the external supply base.
When OEMs no longer accept supplier‑defined integration terms, Tier 1’s integrated hardware/software bundle becomes harder to sell. Integration shifts from a source of differentiation to a commercial constraint.
Why selling software is fundamentally different from selling hardware
Software follows a different commercial logic than hardware, and the differences are material. Three dimensions matter: lifecycle, monetization structure, and commercial terms.
Hardware is governed by the start of production date. It is designed for a vehicle program, sourced for that program, and functionally obsolete when the program ends. Software does not work this way. A software release developed for Vehicle Program A continues to operate across Vehicle Programs B and C. It requires maintenance, updates, and commercial management throughout. The development investment carries forward across programs rather than resetting with each one. An engineering organization built around program milestones is poorly suited to managing software that remains in service long after any individual start of production (SOP).
Three monetization models, and what distinguishes them
Automotive software is sold under three distinct models, each suited to different circumstances.
The contract staffing model applies when the scope of work is unclear and the OEM retains intellectual property ownership. It is priced on a cost-plus basis, and OEMs have close to 99% cost transparency in this arrangement, leaving the supplier with minimal pricing leverage.
The engineering services model applies to work with clear requirements and defined deliverables. IP ownership remains with the OEM. Margins typically exceed 20%, but the OEM retains approximately 90% cost transparency, so leverage remains on the buyer's side.
Under SaaP and SaaS licensing models, OEM cost estimation deteriorates sharply. Unlike billable-time engagements, IP licensing gives OEMs no clear view of what the product actually costs to build. Parametric estimation models are their only proxy. Pricing structures run from fixed licenses to value-based arrangements, with margins that outpace contact staffing and engineering services models.
Most Tier-1 suppliers have built their commercial infrastructure to sell time and deliverables. The licensing model requires the ability to price on value rather than cost, to negotiate on vendor-defined terms rather than OEM-defined terms, and to structure agreements around lifecycle value rather than program delivery.
What Tier‑1s must do – A sequenced shift from engineering to product‑led software monetization
Responding to unbundling means changing the product portfolio, pricing logic, and organizational structure at the same time.
The starting point is decomposing existing hardware/software bundles into distinct, separately addressable software capabilities. An infotainment portfolio, for example, contains platform software, a media framework, sound packages, voice and navigation integration, OEM-specific applications, and integration services — each with a different competitive landscape and a different buyer within the OEM organization. Selling these as a single bundle obscures their individual commercial value. Suppliers must disaggregate internally before they can price them individually in the market.
The second requirement is a change in pricing logic. Unit-based pricing (e.g. a fee per vehicle, per ECU, or per feature) is the most direct transition from hardware commercial norms. It is not the only option. Subscription models, usage-based fees, developer seat licensing for middleware, and lifecycle monetization structures that combine initial license fees with ongoing maintenance revenues are all established models in software markets outside automotive. Applying them in automotive requires pricing from the value delivered to the OEM rather than from a cost base plus margin. That means understanding what the software enables for the OEM and what it costs them to go without it.
The third requirement is organizational. An engineering delivery model structured around program milestones and hardware integration is poorly suited to continuous software lifecycle ownership. Product management must exist as a function with authority over roadmap and release decisions. DevOps and continuous deployment infrastructure must replace program-linked delivery logic. Lifecycle governance must be a standing organizational function. The supplier's internal structure must also align with how OEM software organizations work, with the cadence, granularity, and commercial sophistication they have come to expect from software-native counterparts.
The cost of waiting: a compounding disadvantage
OEM software purchasing organizations continue to grow and, over time, develop deeper purchasing and integration expertise. Every independently sourced component gives the OEM purchasing team cost visibility it did not previously have. Direct Tier-2 negotiations build internal pricing intelligence. Each successfully disaggregated procurement produces a template that can be applied to the next domain. The OEM's sophistication is compounding year over year.
A Tier-1 that delays building a software product position does not hold its position during that period. It loses relative ground, because each successive negotiation finds the OEM counterpart better informed and more willing to accept the integration complexity of sourcing independently. Suppliers that move now will accumulate commercial track records, product reference bases, and internal capabilities. Late entrants will struggle to replicate these. Latecomers will negotiate from a weakened position. OEM buyers will already know how to price the bundle apart — and software specialists will already hold ground in the relevant domains.