Too few security engineers: automation, AI and reaching SOP clean

There are not enough people to do this work. That is the uncomfortable fact behind automotive cybersecurity, and it is getting worse, not better.

The maths does not work

ISC2’s workforce studies have put the global cybersecurity shortfall in the millions, around 4.8 million by their 2026 estimate, with the field needing to grow by roughly 87% to meet demand. Around 90% of security teams report a skills gap.

Now narrow that to automotive. Testing an ECU is not general IT security. It needs people who know CAN and CAN FD, UDS and DoIP, SecurityAccess, diagnostic sessions and the real-time constraints of an embedded target, and who can map all of it to ISO/SAE 21434. That is a tiny, overbooked subset of an already short field. Meanwhile the automotive cybersecurity market is growing fast, from roughly four billion dollars in 2026 toward twelve billion and beyond by the early 2030s. Demand is climbing a cliff while the pool of people who can actually test a control unit barely moves.

Then count the work. A modern vehicle programme has dozens of ECUs. Each one has many releases on its way to production, and more after it. If deep security testing depends on booking one of a handful of specialists for every release of every ECU, the queue is longer than the programme. Something gives, and usually it is the testing.

SOP is a wall you only hit once

Start of production does not move. When a vehicle reaches SOP, the cost of a security defect changes completely: what was a code review comment before the line starts becomes, afterwards, a field campaign or a recall. And under UN R155 and ISO/SAE 21434 you cannot simply ship and hope. You have to show the mitigations were tested and that known issues were dealt with.

So the real target is specific: reach SOP with no known low-hanging fruit. Not a perfect ECU, which nobody can promise, but one where the obvious, high-impact, first-hour findings are gone and documented. Diagnostic services reachable without authentication. Weak or default SecurityAccess. Exposed XCP or CCP. Writable identifiers that should be locked. These are common, they are devastating, and they are completely avoidable, if someone tests for them on every release.

That last clause is the whole problem. A single pre-SOP pentest is a snapshot of the software you had that week. The ECU keeps changing. A feature added two sprints later quietly re-opens a service, and nobody tests again until the next audit, by which point it is in the car.

You cannot hire your way out. You can multiply

The instinct is to hire more specialists. It is the right instinct and it is not enough, because the people are not there to hire, and even a doubled team cannot manually re-test every release of every ECU.

This is where AI and automation change the unit economics, and it is worth being precise about how. AI will not close the skills gap by itself, and anyone who tells you it replaces your security engineers is selling something. What it does do, well, is level up the team you already have: encode what a good tester does by hand into engines that run without them, so the scarce humans are spent on the work only humans can do.

Concretely, the knowledge of how to enumerate a UDS stack, probe SecurityAccess, fuzz an interface safely, or walk a DoIP gateway is stable and repeatable. It does not need a specialist present every time. It needs a specialist once, to build the test, and then a machine to run it on every release forever. The specialist is then free for the novel attack path, the TARA, the thing the automation cannot imagine.

What that looks like in a real programme

This is exactly what AutoST is built for. Its engines carry the testing knowledge: UDS enumeration, SecurityAccess analysis (0x27), UDS and CAN fuzzing, DoIP and SOME/IP, Android IVI. You wire the ECU to a bench once, and from then on AutoST runs from the API and in CI.

So the testing moves from “a specialist, if one is free, before the audit” to “automatically, on every major release”. Every build of every ECU gets the same baseline security pass. The low-hanging fruit is caught the moment it is introduced, not discovered in the car. By SOP you have a dated trail showing each release was tested and that the known issues were closed, which is also exactly what an ISO/SAE 21434 assessor wants to see.

And the handful of security engineers you do have stop spending their scarce hours re-finding the same weak SecurityAccess on the fortieth ECU. They spend them on the attacks that actually need a human.

The honest version

Automation does not make security engineers unnecessary. It makes the ones you have count. AutoST handles the breadth and the regression so a small team can cover a whole vehicle programme and reach SOP with no known low-hanging fruit. The depth, the creativity, the TARA and the audit still need people, and Zyberum brings those too, as a team that has taken Tier 1, Tier 2 and OEM programmes through exactly this. References are available on request.

If your programme has more ECUs than it has security engineers, which is almost all of them, that gap is the problem AutoST was made to close. Book a demo and we will show you what testing every release actually looks like.