Building your first TRA

A Threat & Risk Analysis is the document that shows why your product is secure the way it is: what could go wrong, how bad it would be, and what you did about it. Under the CRA it is what makes "security by design" checkable rather than asserted.

This page is a short orientation to the shape of the work. It is not a method course — if you want the facilitated version, that is what our workshops are for.

The five moves

1. Say what the product is, and where it lives. Intended purpose, foreseeable misuse, the network it sits on, who can physically reach it, and what data it holds. Almost every disagreement later in a TRA turns out to be a disagreement about one of these, held silently.

2. Draw the boundaries. Which parts of the system do you trust, and where does that trust stop? Interfaces, data stores and links that cross a boundary are where your threats will be — everything else is detail.

3. Name what could go wrong, as a path to a consequence. "Key extracted from a stolen device, leading to compromise of the whole installation" is a threat. "No encryption at rest" is a missing control — it cannot be scored, ranked or closed, and starting from a list of missing controls is the most common way a first TRA stalls.

4. Score, using a scale you wrote down first. Likelihood times impact, on a small scale with each point anchored by a sentence. What matters is not precision but that the same scenario scores the same way next quarter, and that the threshold for "this needs a design measure" was fixed before anyone saw the scores.

5. Decide, and write the decision down. Mitigate, accept, or transfer — each with a reason, an owner and a date. The accepted risks are as much a part of the TRA as the mitigated ones; a TRA with no accepted risks usually means the scoring was steered.

Two things worth getting right the first time

Do it early enough to change something. A TRA written after the architecture is frozen can only ratify decisions already taken. Its value is highest when it can still rule out a component or force a hardware capability — which means running it during design, not before release.

Keep every version. The first, pre-design version is the evidence that the assessment preceded the design. Overwrite it and you still have a risk assessment, but you no longer have proof of security by design.

Where TRA Studio fits

The tool holds the system model, the threat and mitigation register, the scoring, and the sign-off — so the TRA stays a living document rather than a spreadsheet that ages. Requirements from the standards you import are mapped onto your own development activities, and anything unmapped shows up as a gap.

Ready to start? Check whether the CRA applies to your product first — scope determines how much of this you actually owe. Then look at the example process documents to see what the surrounding paperwork looks like when it is done properly.

Want to see the five moves done in the tool? The walkthrough is this page with the clicks in it: one product, one TRA, one system model, one rated threat, one treatment, one report — about 45 minutes, screenshot by screenshot.

Guidance based on the CRA text. A starting point for your own work, not legal advice.