The automotive aftermarket is bigger than most people outside it realise, and almost all of it depends on a single technical fact: for thirty years, anyone could plug a device into a standardised port under the dashboard and read what the car was thinking.
That fact is expiring. Not through any single decision, but as a side effect of the software-defined vehicle. And because the aftermarket is where most cars spend most of their lives, this is a bigger deal than the architecture conversation usually admits.
What the port actually gave away
OBD-II was mandated for emissions compliance, and its scope reflects that: standardised diagnostic trouble codes and a defined set of emissions-related parameters. Everything genuinely useful beyond that — bidirectional control, module programming, manufacturer-specific parameters — lives behind UDS services and manufacturer-specific addressing.
Which means the aftermarket's real capability was never the standard. It was reverse engineering plus subscription access to OEM diagnostic information, delivered through the port. Independent workshops, tool vendors and telematics providers all built on top of that.
The port also enabled an entire telematics category. A dongle drawing power and data from OBD-II, phoning home over cellular, became the basis for usage-based insurance, fleet management and driver scoring — largely without OEM involvement.
Why it is closing
Three forces, none of them primarily about competition.
Cybersecurity regulation. An unauthenticated, physically accessible port with bidirectional access to vehicle networks is exactly the attack surface that vehicle cybersecurity rules require OEMs to control. Gateway modules that authenticate and authorise diagnostic sessions are the natural answer, and the natural consequence is that access becomes something granted rather than taken.
Architecture. As functions consolidate into central compute and communication becomes service-oriented, there is often no bus carrying the signal a tool wants to read. The data exists as a service call inside the vehicle, not as a broadcast frame.
Business model. Vehicle data has become an OEM revenue line, and the cheapest way to monetise it is to be the only supplier.
Whether the third force is driving the first two is the argument the industry is actually having.
The two models, and why the difference matters
This is the crux, and it is worth being precise because the terminology is used loosely.
In-vehicle interface. Third parties get authenticated access to vehicle data and functions in the vehicle, in something close to real time. Access is mediated by security controls but the data path does not route through the OEM's cloud.
Extended vehicle. The vehicle sends data to the OEM's backend. Third parties consume it from an OEM-operated API — with the OEM deciding which signals are exposed, at what frequency, at what price, and with visibility into who is asking for what.
The standards work around extended-vehicle access has made the second model concrete and interoperable. It works. Its consequence is structural rather than technical:
| In-vehicle interface | Extended vehicle | |
|---|---|---|
| Latency | Real-time, local | Cloud round trip |
| Signal coverage | Broad, negotiated | Whatever is published |
| Offline capability | Works | Does not |
| Competitive visibility | OEM sees nothing | OEM sees every request |
| Cost to third party | Hardware | Per-call, ongoing |
An independent service chain reading live data locally is a competitor with a cost base it controls. The same chain calling an OEM API is a customer whose margin and product roadmap are set by the company it competes with. That is why this is fought over in regulatory consultations rather than standards committees.
The unglamorous data problem underneath
Set the access fight aside, because there is a second data problem the aftermarket has always had and mostly solved with brute force: cataloguing.
Matching a part to a vehicle is genuinely hard. A vehicle is a build, not a model — the same nameplate in the same year may take different components depending on trim, plant, engine variant and mid-cycle supplier change. The industry's answer is standardised catalogue data: application data mapping parts to vehicle configurations, and product attribute data describing the parts themselves.
If you work in this space, catalogue data quality is the whole game. A wrong fitment record costs a return, a labour hour and a customer. The businesses that win the online parts channel are not the ones with the best search UI; they are the ones whose fitment data is right, which is a supply-chain and data-governance achievement rather than a software one.
VIN decoding sits in the middle of this and is messier than it looks. The standardised portion of a VIN tells you manufacturer, some attributes and the model year. Everything else lives in manufacturer-specific positions or in build records the OEM holds. Which is, again, the same story: the useful data is on the other side of a boundary.
What electrification does to the service business
Worth stating plainly because it changes what software the aftermarket needs.
An EV has far fewer wearing mechanical parts. No oil changes, no exhaust, no timing belts, dramatically reduced brake wear thanks to regeneration. The traditional maintenance revenue stream contracts.
What grows instead:
- Battery diagnostics and state-of-health estimation — the highest-value assessment on a used EV, and the one buyers most want independently verified
- High-voltage-qualified labour, which is a training and certification problem before it is a tooling problem
- Software and calibration work — ADAS recalibration after a windscreen replacement is now a routine, billable, tooling-intensive job
- Thermal management systems, which are more complex and more failure-prone than in combustion vehicles
Battery state-of-health is the interesting one for anyone building software here. Estimating it properly requires charge and discharge history, cell-level data and thermal history — which lives inside the battery management system, exposed at the OEM's discretion. An independent estimate from a short diagnostic session is possible but materially less accurate. The information asymmetry has direct residual-value consequences, which is why regulators have started paying attention to it specifically.
If I were building here
Do not build your product on a data path you do not control without pricing that risk. Plenty of telematics businesses were built on the OBD dongle and discovered their access was a temporary artefact of regulation.
Treat catalogue and fitment data as the core asset. It is defensible, it compounds, and nobody can take it away from you.
Instrument what you learn in the bay. Independent workshops collectively see more real-world failure than any single OEM's warranty channel. That aggregated diagnostic history is a genuine and underused asset — and the one piece of data the OEM does not have.
Follow the right-to-repair legislation, not the press releases. Whether independent operators get in-vehicle access or a metered cloud API is being decided in regulation, and it determines the shape of every business in this sector for the next decade.