NHTSA's Cybersecurity Best Practices for the Safety of Modern Vehicles are voluntary, but when the first edition came out in 2016, a product-liability law firm warned that plaintiffs would characterize them as the minimum "standard of care" for vehicle cybersecurity. NHTSA is now reopening the 2022 version. NHTSA Administrator Jonathan Morrison's remarks at this year's Auto-ISAC Cybersecurity Summit show where the next version is headed.
Why the NHTSA cybersecurity best practices update matters to your program
The 2022 document calls itself "non-binding and voluntary guidance," but it sets out the practices NHTSA expects industry to follow. In our view, that makes it the text legal teams reach for when judging due care. A program that met the old version can fall short of the next without changing anything.
Three passages in the remarks stand out:
- Attacks got cheaper. Generative and automated tools "drastically reduce the time and cost required" to find and exploit vulnerabilities in vehicle sensors and systems.
- The back end reaches the whole fleet. "Because cloud vulnerabilities could impact an entire fleet, securing backend infrastructure is just as important as securing in-vehicle networks."
- Software origin is now regulated. The industry should "continue to adhere to the Department of Commerce's connected vehicle supply chain final rule."
Where the 2022 text stops and the remarks point
The 2022 document asks for the right work but not how to show that work holds up against the three shifts above.
Cheaper attacks make periodic risk review too slow
AI lets an attacker find and exploit a flaw in hours. It can help us find and fix the flaw just as fast. But the fix can't reach the car until it passes safety validation and goes out as an over-the-air update, and that still takes weeks to months. Our COO, Andre Weimerskirch, made this point in his USENIX VehicleSec keynote: the faster attackers get, the more that wait matters. We think software is heading toward resilience and self-healing, which would shrink that gap.
Item G.21 of the 2022 text asks to reevaluate risks "periodically," which we think no longer fits: a calendar review leaves a new vulnerability waiting for the next scheduled assessment. Even weekly triage is too slow now that AI tools find more vulnerabilities, faster; it has to be continuous. Risk management belongs inside development teams' workflow, where tools check whether and where each new vulnerability or threat applies across the product portfolio and recommend mitigations automatically.
Fleet-wide cloud risk needs monitoring designed for it
Every VSOC we've built reached the same fork: monitoring designed into the vehicle and its back end, or security events pieced together from logs built for other purposes. For fleets already on the road, it is nearly always the second.
A traditional SIEM, built for a pre-AI world, sees only the data you chose to send it, so it misses a fleet-wide cloud problem whose evidence sits in systems that don't feed it. We think AI agents that query sources directly make that model out of date, though they still need the underlying data, and real-time attacks still need real-time detection.
So we pick use cases first, a lesson from an EV fleet's VSOC, where rules written from whatever data existed gave plenty of alerts and few that mattered. Spotting "a fleet-wide command that didn't come from our own back end" needs server and vehicle data side by side, which nobody has unless someone planned it.
Software origin makes inventory a two-way question
Most teams we work with can't quickly say where else a vulnerable library lives. The records exist but run the wrong way for that question: vehicle-down, spread across signing and key management, diagnostics, requirements tools and per-vehicle file systems.
The Commerce rule adds a question the 2022 text never asks: where did the software come from? The rule covers connectivity (VCS) and automated-driving (ADS) software only. When we helped a manufacturer assemble evidence for its Declaration of Conformity, the firmware-to-vehicle-program mapping sat across several systems and was resolved by hand, and supplier attestations alone didn't establish what was in the software.
Our CEO, Brandon Barry, moderated the summit's October 7 panel on the rule and spoke on the next day's follow-up. He noted that under type approval (UN R155), an approval authority gives the green or red light, while this rule puts liability on the OEM and the individual who signs the Declaration of Conformity. His answer is a three-legged stool: who owns the supplier, what the supplier claims, and what you can verify yourself, brought together in one record. For that third leg, binary scanning shows what is in the shipped software without knowing which source repositories built it.
Our read is that the next version may expect an inventory to answer origin as well as location, at least for VCS and ADS software. One set of records answering both, fed automatically from development instead of chased from suppliers, beats two kept by different owners.
Where the conversation happens next
The remarks give no date for the revised document, but they name two meetings to watch:
- December 1 and 2: NHTSA's Safety Research Portfolio Public Meeting at USDOT headquarters in Washington, where the agency will present "an evaluation of offensive cybersecurity models for the automotive domain."
- January 19: NHTSA's Cybersecurity Workshop with SAE International in Washington, held in coordination with SAE's Government/Industry Meeting.
We're glad to walk through the table's three checks on a short call. Get in touch.
Subject expert
Brandon Barry is the CEO and founder of Block Harbor. He leads the company's vision and partnerships, with a focus on securing connected vehicles and the next wave of physical AI, from robots to EV charging.
%201.svg){kind=logo}
