Before you point AI at your TARA backlog

Everybody in this industry runs threat analysis and risk assessments, TARAs, because many regulations require some form of risk-based product development. If your program is large, you have a queue of them, and the queue is probably not moving as fast as your release schedule needs it to. That is the market a wave of AI tooling is aimed at, and the pitches are specific: asset identification in hours rather than weeks, a full-vehicle TARA in weeks rather than months, most of the work automated.

The speedup is real, and at Block Harbor we are building in the same direction ourselves. It applies to the second half of a TARA. The first half is where the real hours go and is likely where your own AI efforts (or those of your tools) are missing the biggest pain point.

A TARA has two parts. First you describe the thing you are analyzing: which control units are involved, what data moves between them, what protections already exist. ISO/SAE 21434 calls that the item definition, and puts it at the front of the concept phase in Clause 9, ahead of any of the analysis. Then you analyze it: what an attacker could do, how hard it would be, what the damage would be, and what you will do about it.

Every AI number quoted above starts counting after the first part is finished, because a machine that extracts a system model has to be handed a system model. Most programs, however, cannot easily hand one over.

One function, six sources, and they disagreed

We ran a TARA on a backup alarm for a global heavy equipment manufacturer. Put the machine in reverse, the machine beeps. It sounds like a trivial thing to analyze until you notice the alarm is also required after shutdown, while hatches are open and parts are still winding down, so that nobody reaches into something that is still moving. An alarm an attacker can silence is a safety problem. That is why it is in scope.

This program scopes its TARAs by function rather than by control unit, as many OEMs do, but one function is not one box. The reverse alarm reaches across the handle the operator moves, the module that handle connects to, two control modules that relay the signal, and the module that drives the speaker. Several owners, potentially several teams, and one analyst trying to assemble a single accurate picture.

The facts existed. Engineers had written them down and people answered when asked. They were spread across a requirements page, a large PDF of signal tables, a set of architecture drawings, a ticket, an email, and answers typed out by colleagues in other time zones. Where they overlapped, they disagreed.

The cybersecurity requirements page listed the control units involved, and two real participants were missing from it. Some engineers on the program believed that page was sufficient to build the TARA from. The drawings we were sent showed one control module where we had already established two, and we could not confirm we were holding the drawing for the right platform. Which protections were already deployed, and what operating system ran on one of the modules, were facts that lived with individual people and arrived over chat, not documentation!

Nobody was careless. The information had never been assembled in one place, because until somebody needed to analyze that function, nobody had to.

Assembling it took the large majority of the hours on that TARA. Everything after it ran fast.

The arithmetic on your backlog

With the item definition in hand, two experienced analysts finish two to three TARAs each per week. That number carries a condition, and the condition is what your schedule actually rests on: if we have all the information.

This customer named roughly 80 functions as highest priority, and the full list is longer. At four a week, 80 clears in five months. That is the plan anyone would write from the analysis rate, and it is the wrong plan, because the rate assumes the item definitions already exist. On the first one, they did not.

So the number to plan against is not how fast your analysts (or AI tools) work. It is how fast your organization can hand them an accurate description of each item being analyzed.

What AI does today, and what it does not

Today it analyzes what it's pointed at. Point a model at a pile of specification and it will digest more in an hour than a person gets through in a month, pull the components, interfaces and signals out of anything structured, and even hand back a credible first draft of both the item definition and the analysis. On the analysis side of this deliverable, the time savings is valid and real.

What it does not do, however, is get a fact that nobody wrote down.

No model reads the mind of the software owner who knows which operating system that module actually runs (yes, that's in a tool somewhere, but it's never the same tool as the 30 other teams on the project). It cannot reconcile two drawings without the person who knows which one matches the build. And when it hits a gap, it does not stop and tell you; it fills it with a confident sounding fabrication. Since all development efforts are after design, gaps and requirements based on fabrication costs true money down the line.

Every one of those is the same failure, and it is not an extraction failure. The information is in somebody's head, and the cost of getting it out is a meeting, a ticket, or a message that sits unanswered across time zones for weeks each round.

That is where we are pointing VSEC Design. Extraction of the known is the half that already works. The half that does not is the asking, so we are building the asking into the tool. And, better than that, it can even start with publicly known information!

Any asset in the model can request what it is missing from the person who owns that answer, at the push of a button, and their reply attaches to the asset. That engineer never has to open our tool, learn our tool, or sit in a workshop. They answer a question or throw in a document. The model fills in as replies land, and a readiness view shows what is still open instead of quietly guessing at it.

Two things that actually move the number

Both are management decisions rather than engineering ones.

The first is to capture the fact while the engineer who owns it is already writing it down, in a form a tool can read later, instead of reconstructing it from documents a year afterward. The domain expert who corrected a module list on one of our projects could have supplied it at design time. That is the argument behind involving engineers early in the TARA process, and as we enter the age of AI, that information should only need to be provided once to be accessible anytime throughout the engineering lifecycle.

Until that is true, stop letting analysts interview people in series. Our method on that program is to ask everyone at once to provide what they can, filling in the documentation as the answers land, and automatically finding gaps. The facts typically sit with people who are waiting to be asked, but every question costs a round trip across time zones.

The second is to fund reuse on the parts that repeat. Most of the analysis half is pattern work: the same attack trees and damage scenarios apply again and again, with the ratings already settled. Our engineers on that program built those templates, so an analyst picks the one that matches, deletes what does not apply, and moves on. Pattern work should cost pattern-work money and is where AI is generally useful out of the box.

What we are building

We have run more than 350 TARAs in house, full vehicle down to chip, across automotive, robotics, and agriculture. That body of work is what VSEC Design is built on, and its Auto-TARA capability is aimed at both the item definition AND the analysis rather than just analysis alone, because that is where your time goes.

It is currently (as of Sept. 2026) entering beta. You cannot buy it out of the box today, but you can apply to join the beta program by reaching out!

Tell us what your item definitions actually cost you!

‍