Guide

How to choose an offline TARA tool for ISO/SAE 21434 and UN R155

Most TARA tools assume your threat analysis can live in someone else's cloud. For a lot of automotive teams it can't. This guide explains what "offline" actually means in practice, what a TARA tool has to do regardless of where it runs, and the questions worth asking any vendor before you commit.

Published 16 July 2026 · Written by the engineering team at CYVEHX

1. Why teams need an offline TARA tool

"Offline" is often treated as a preference. For a large share of automotive engineering teams it is a hard constraint, and it usually comes from one of four places:

• The network genuinely has no route out. Engineering segments handling pre-production architecture are frequently air-gapped or heavily restricted. A tool that needs to reach a licence server or a cloud API simply won't start.
• The data is the crown jewels. A TARA describes your item definition, your architecture, your attack paths and precisely where you are weak. It is a map of how to attack the vehicle. Uploading that to a third-party platform is a decision the security team may reasonably veto.
• Contracts say no. OEM–supplier NDAs, customer security schedules and export-control rules regularly forbid putting design data on infrastructure you don't control, or outside a given jurisdiction.
• Approval takes longer than the project. Even when a cloud tool is permitted in principle, the vendor security assessment, DPIA and procurement cycle can outlast the deadline you're trying to hit.

If any of those apply, deployment model isn't a feature comparison — it's the first filter. A tool that fails it is out, no matter how good the rest is.

2. What "offline" actually means

This is where the word gets slippery. Vendors use "on-premise", "local", "private" and "offline" to mean very different things. It's worth separating them:

• Cloud / SaaS — your data lives on the vendor's infrastructure. Convenient, but it's the model most often ruled out.
• Self-hosted / "on-premise" — the vendor's server software runs in your data centre. Better for data residency, and it can survive an air gap, but only if it genuinely never phones home: many "on-prem" offerings still call out for licensing or updates, which is exactly what fails on a disconnected network. It is also a server to install, patch and own.
• Genuinely offline desktop — the tool runs on the engineer's machine, makes no network calls at all, and stores work in a local file. Nothing to host, nothing to phone home.

The first is out by definition. The second and third can both work air-gapped — but only if you verify the call-home question, because that is where most "on-premise" claims quietly break. And "offline" is only real if every one of these is true — it's worth checking each explicitly:

3. The method the tool must support

Deployment is the filter; method is the actual job. ISO/SAE 21434 doesn't mandate one specific TARA technique, but it does define the work products and the chain that connects them. A tool worth buying should carry that chain end to end, not just give you somewhere to type:

• Item definition — boundary, interfaces and assumptions, as the thing everything else hangs off.
• Asset identification and damage scenarios — with impact rated across the safety, financial, operational and privacy categories.
• Threat scenarios — systematically elicited (STRIDE and equivalent) rather than brainstormed and forgotten.
• Attack paths and feasibility — attack trees, and a feasibility rating you can defend with a documented rationale.
• Risk determination and treatment — impact × feasibility, then an explicit decision per risk: reduce, share, retain or avoid.
• Cybersecurity goals, claims and concept — the output an assessor will actually read.
• Traceability across all of it — this is the part spreadsheets lose, and the part an assessor probes hardest.
• UN R155 coverage — a live view of your position against the Annex 5 threat table, including the gaps.

Increasingly it's also worth asking about the EU Cyber Resilience Act (applicable from 11 December 2027; type-approved road vehicles remain under UN R155) and ISO/DIS 24882 for agricultural and off-road machinery — if a tool can reuse the same analysis across those, that's real work saved rather than a second project.

4. Why a spreadsheet stops working

Nearly every team starts in Excel, and for a first TARA that is a perfectly reasonable choice — it's free, everyone has it, and it's genuinely offline. It tends to break for the same reasons every time:

• Traceability is manual. Links between damage scenarios, threat scenarios, attack paths, goals and requirements exist only as text someone typed. Rename one row and the chain quietly breaks.
• Coverage is invisible. "Which R155 Annex 5 threats have we not addressed?" becomes an archaeology exercise instead of a view.
• Consistency drifts. Two engineers rate feasibility differently, and nothing enforces the method.
• The audit trail is thin. Who approved this risk decision, when, and on what basis — is usually not in the file.
• Every change re-opens everything. An architecture change means re-walking the whole workbook by hand.

The point isn't that spreadsheets are bad. It's that the cost shows up later — usually while preparing for an assessment, which is the worst possible moment to discover the chain doesn't hold.

5. Questions to ask any vendor

Useful regardless of which tool you end up with — including ours. Ask them in writing:

6. Where TARAexl fits

We build TARAexl, so treat this section as what it is — but it's also why the guide exists. TARAexl comes in two editions, and both keep the offline guarantee.

TARAexl Studio is the single-analyst desktop edition, built for exactly the constraint above: a portable Windows x64 application that unzips and runs, with no installer, no account, no auto-update and no telemetry. It makes no network calls, licensing is offline and per-seat, the on-device AI assistant keeps your threat model on your machine, and your work lives in a local project file you own.

On method it carries the full ISO/SAE 21434 chain from item definition to the cybersecurity concept, with UN R155 coverage, attack trees, STRIDE elicitation, an impact × attack-feasibility risk matrix, and end-to-end traceability. Exports are an Excel report, a Word cybersecurity concept, and a one-click Evidence Binder with a SHA-256 per artifact so each item stays independently verifiable. EU CRA mapping and an ISO/DIS 24882 profile are included.

TARAexl Hub (early access) answers the team question without giving up the air gap: it runs as a Docker stack on your server, behind your firewall, and the team reaches it from a browser. Six roles are enforced server-side, projects live in spaces with per-space permissions, and people sign in with local accounts, Active Directory / LDAP or OIDC SSO. This is the point most vendors force you into the cloud for — Hub keeps it on-premise.

The honest part: Hub is controlled collaboration, not simultaneous co-editing. One person edits a given project at a time under a four-hour lock that releases on its own, and every save is version-checked so nothing gets silently overwritten; the review discussion is the part that is shared live. If your team genuinely needs several people typing into the same analysis at the same moment, that is a real trade-off to weigh — it is also what keeps the whole thing running with no outside connection.

If your organisation also needs the organisational side — the CSMS itself, governance, evidence and the audit binder — that's Munimentx, built on the same offline principle.

This guide is general information, not consulting, legal or compliance advice. Standards and regulation names are used to describe scope and compatibility only and do not imply endorsement by, or affiliation with, any standards body or regulator. Tools support your work towards ISO/SAE 21434, UN R155 and the EU CRA; audit, certification and type-approval outcomes remain the responsibility of you, your assessors and the relevant authorities.