Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.

Wie das Beispiel-Artefakt im anderen Tab entsteht: Auslöser, Eingaben, Schritte und was "fertig" bedeutet. Orientierung auf Basis des CRA-Texts — ein Ausgangspunkt für Ihren eigenen Prozess, keine Rechtsberatung.

How it is created — SEC-TM Threat Model (STRIDE, pre-development)

Produces	SEC-TM-<product> — the threat model and its attack-surface inventory
Type	Product record, revised on every interface or trust-boundary change; all revisions retained
Owner	Product Security Lead (moderator)
Participants	Firmware lead, hardware engineer, QA — a workshop, typically 3 hours
Trigger	After the risk assessment baseline, still before architecture freeze; then per major release and on any interface change
CRA reference	Annex I I(1) and I(2)(b); IEC 62443-4-1 practice SD-1 (secure design principles) if you use it for structure

1. What separates a threat model from a brainstorm

Three things, and an auditor will look for all of them: a documented methodology, a model of the system with trust boundaries, and traceability from each threat to a requirement or an accepted risk. A list of scary scenarios with no method and no outcome is not evidence.

2. Inputs

The pre-development risk assessment and its assumptions.
The planned system decomposition — components, data flows, storage.
The interface list from hardware and firmware, including the ones nobody plans to use: debug ports, vendor test modes, radios present in the silicon.

3. Steps

Write down the method you are using, in the document. Data-flow diagram, trust boundaries, attacker profiles, STRIDE per element, hand risks back to the risk assessment. Stating the method is part of the obligation, not documentation overhead.
Draw the data-flow diagram and mark the trust boundaries. Keep it in a source-controlled file in the project repository; the document is the reviewed export, so the model can evolve without the record losing its date.
Build the attack-surface inventory as a table — every interface, service and data store that crosses a boundary, with its exposure and its planned default state. This table is what the secure-defaults checklist verifies later, so write it in terms that can be tested on a shipped unit.
Define threat actors with capabilities and motivation. An opportunistic person on site, a skilled attacker with a stolen unit and lab equipment, a remote attacker on the plant network, a malicious insider with legitimate rights. Capability determines which threats are credible.
Apply STRIDE element by element and record only what is relevant to the intended use or foreseeable misuse. Padding the table with theoretical entries makes the real findings harder to see.
Give every finding an outcome: a security requirement ID, a link to the corresponding risk, or an explicit out-of-scope decision with a compensating measure elsewhere (jamming handled by stale-data detection at the gateway, for instance).
Hand over the derived requirements as mandatory before architecture freeze, and note which of them confirm hardware constraints.
Write the maintenance rule into the document: re-run as a delta workshop whenever an interface, protocol or trust boundary changes, and at least once per major release.

4. Done when

The methodology section describes what was actually done, including who was in the room and when.
Every attack-surface entry has a planned default state.
Every retained threat maps to a requirement, a risk ID, or a documented decision.
The model is stored somewhere it can be revised, and the revision rule is stated.

5. Common mistakes

Modelling the system you wish you had rather than the one in the schematic — the BLE stack present in the chosen silicon is part of the attack surface whether or not the roadmap mentions it. Running the workshop once and never again. Producing findings that no requirement ever picks up.

6. In TRA Studio

Zones and conduits carry the trust boundaries, components carry the elements, and threats link to mitigations and security controls — so the traceability from threat to requirement is maintained by the tool instead of by a table you keep in sync by hand.