Help Center
Everything you need to model threats in ThreatTree — from your first forest to a signed-off risk register. Every section below walks through the real UI, with a worked example you can follow along with.
Getting Started
ThreatTree organizes your work into Forests. A forest is a container for one system, product, or engagement — inside it you build Data Flow Diagrams (DFDs) to map architecture, and Attack Trees to decompose specific threats against that architecture. Findings roll up automatically into a Risk Register, which you can export as a PDF report.
The core ThreatTree workflow: everything lives inside a forest and rolls up to a report.
1. Create your first forest
- From your Dashboard, click New Forest (top right).
- Give it a Name — e.g. "Acme Corp Threat Model" — and an optional Description (scope, system under analysis).
- Click Create Forest. You're dropped into the empty forest, ready to add your first diagram.
2. Add a diagram
Inside a forest, click New DFD or New Attack Tree (or use the generic Add Tree flow, which opens a modal where you name the tree and pick its type: Data Flow Diagram — "Map system components and trust boundaries" — or Attack Tree — "Decompose a threat with AND/OR logic"). If you choose Attack Tree, you can optionally link it to an existing DFD right there, or do it later — see Linking DFDs & Attack Trees.
3. Which one do I build first?
Most engagements start with a DFD to establish what the system actually looks like — its processes, data stores, trust boundaries, and external actors — and then build one or more Attack Trees against specific goals an attacker might pursue within that architecture (e.g. "Exfiltrate customer PII", "Achieve unauthorized admin access"). You don't have to link them, but doing so keeps your threat model traceable back to the architecture it's describing.
Plan limits
The Free plan is fully-featured but capped in size; Pro and Enterprise remove the caps and add collaboration, backup, and (Enterprise) SSO/audit/STIX. Encryption is available on every plan.
| Plan | Forests | DFDs / forest | Attack Trees / DFD | Price |
|---|---|---|---|---|
| Free | 3 | 3 | 5 | $0 |
| Pro | Unlimited | Unlimited | Unlimited | Quote on request |
| Enterprise | Unlimited | Unlimited | Unlimited | Quote on request |
ℹ️ Members of an Organization aren't capped
If you belong to a company Organization (see Collaboration & Organizations), the Free-plan quota doesn't apply to you even if your own personal plan shows as Free — organization membership already implies Pro/Enterprise-level access to the forests you work in.
Feature comparison
| Feature | Free | Pro | Enterprise |
|---|---|---|---|
| DFDs, Attack Trees, MITRE ATT&CK alignment, Risk register, Standards mapping | ✓ | ✓ | ✓ |
| Forest encryption (AES-256-GCM) | ✓ | ✓ | ✓ |
| Team collaboration (invite members to a forest) | — | ✓ | ✓ |
| Company Organizations (domain-wide access) | — | ✓ | ✓ |
| PDF report generation | — | ✓ | ✓ |
| Forest backup & recovery (snapshots) | — | ✓ | ✓ |
| SSO / SAML | — | — | ✓ |
| Audit logs | — | — | ✓ |
| STIX 2.1 export | — | — | ✓ |
See the full breakdown and current pricing on the Membership & Pricing page.
Data Flow Diagrams
A DFD maps what your system is made of and how data moves through it: processes, data stores, external actors, and the trust boundaries between them. It's the architecture layer your Attack Trees get built against.
The palette
The left-hand palette holds every element you can drag onto the canvas, split into two groups. Use the search box at the top of the palette to filter by name if you're hunting for one specific element.
Standard notation ("Elements" group)
| Element | Shape | Represents |
|---|---|---|
| Process | Circle | Something that transforms data — an application, a service, a function. |
| External Entity | Rectangle | An actor outside your system's control — a user, a third-party service, another company's system. |
| Data Store | Open-ended lines | Data at rest — a database, a file store, a cache. Has extra fields for Database System (20 options across SQL/NoSQL, each with its own icon and color) and Data Classification (Public / Internal / Confidential / Restricted). |
| Trust Boundary | Dashed rounded rectangle | A line across which trust level changes — a network segment, a process boundary, a cloud account edge. See below for its sub-type and cloud-branding options. |
Non-Standard group — infrastructure elements
These aren't part of classic DFD notation, but they let you be specific about the infrastructure sitting behind a Process without inventing a workaround. Each renders as a colored box with a two/three-letter badge.
| Element | Badge | Typical use |
|---|---|---|
| Firewall | — | Network or application-layer traffic filtering. |
| Router | — | Network routing between segments. |
| Load Balancer | — | Distributes traffic across multiple instances of a process. |
| Networking Device | ND | Switches, generic network appliances. |
| WAF | WAF | Web Application Firewall. |
| CDN | CDN | Content Delivery Network edge. |
| Storage Array | SA | Block/object storage infrastructure (as distinct from a logical Data Store). |
| Storage Server | SS | A dedicated file/storage server. |
| API Gateway | AG | Centralized API entry point — auth, rate limiting, routing. |
| Message Queue | MQ | Async messaging infrastructure (queues, brokers, event buses). |
| Identity Provider | ID | Auth/identity system — internal IdP or a federated one. |
| Cache | CH | In-memory or distributed caching layer. |
| DNS Server | DNS | Name resolution infrastructure. |
Trust boundaries in detail
A Trust Boundary has a Kind: Logical (default — a conceptual boundary with no further classification) or Physical. Physical boundaries unlock a Sub-type dropdown:
- Trusted Network, Untrusted Network, Internet, On-Premise — each renders with a distinct fill/stroke color so boundary types are visually distinguishable at a glance.
- Cloud Provider — unlocks a further Cloud Provider dropdown with 16 options (AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud, DigitalOcean, Linode/Akamai, Hetzner, Vultr, Scaleway, OVHcloud, Huawei Cloud, Tencent Cloud, Cloudflare Workers, Other). AWS, Azure, GCP, and OCI get their real brand colors on the boundary; the rest use a generic cloud style.
Drawing data flows (connections)
Select a node, then click Draw connection in the right-hand properties panel (it toggles to Cancel connection while active) — then click the node you want to connect to. You can also press C as a shortcut to start/cancel a connection on the selected node.
Canvas tools
- Minimap — bottom-right overview of the whole canvas once your diagram is larger than the visible area; click anywhere on it to jump there.
- Fit Labels — resizes every node so its shape fits its label text, useful after renaming several elements to something longer or shorter.
- Standard zoom/pan — see Keyboard Shortcuts for the full list (+/- to zoom, F to fit the view, Space+drag to pan).
Linking to Attack Trees
An Attack Trees badge in the toolbar shows how many attack trees are currently linked to this DFD, with a dropdown to jump to any of them. See Linking DFDs & Attack Trees for how the link is made.
Worked example: a simple 3-tier web app
Let's map a small SaaS backend: a customer's browser talks to a web application running inside an AWS account, which reads and writes to a PostgreSQL database.
- Drag an External Entity onto the canvas, label it Customer.
- Drag a Trust Boundary onto the canvas around where your app will sit. Open its properties, set Kind → Physical, Sub-type → Cloud Provider, Cloud Provider → AWS. Rename it AWS Account — prod.
- Inside that boundary, drag a Process, label it Web App (Node.js).
- Also inside the boundary, drag a Data Store, label it Customer DB. Set Database System → PostgreSQL and Data Classification → Confidential.
- Select Customer, click Draw connection, click Web App — label the flow HTTPS request.
- Repeat in the other direction for the response, and between Web App and Customer DB for the query/result.
- Click Fit Labels to tidy up node sizing, then save.
The finished diagram — an External Entity, a cloud-branded Trust Boundary, a Process, and a Data Store, connected by four labeled data flows.
Attack Trees
An Attack Tree decomposes one attacker goal into the specific ways it could be achieved, using AND/OR logic — then lets you score, categorize, and plan a response for each concrete threat at the leaves.
The four node types
| Node | Meaning | Has scoring/framework fields? |
|---|---|---|
| Goal | The attacker's top-level objective — e.g. "Exfiltrate customer PII". One per tree; the palette disables the Goal item once one exists on the canvas. | Yes |
| OR Gate | The goal (or parent node) is achieved if any one of its children succeeds. Use this for "there are several independent ways in". | No — purely structural |
| AND Gate | The parent is only achieved if all of its children succeed together. Use this when an attack needs multiple conditions to line up. | No — purely structural |
| Leaf Node | A concrete, atomic threat or technique — the bottom of the decomposition. This is where the real risk data lives. | Yes |
ℹ️ Gates are pure logic, not risk items
OR and AND gates only have a Label, a Label Color, and a Description — no likelihood/impact, framework tags, MITRE mapping, treatment plan, or standards controls. Those fields only appear on Goal and Leaf nodes, since a gate doesn't represent a single scoreable threat — it just describes how its children combine.
Likelihood, Impact, and risk score
On a Goal or Leaf node, set Likelihood and Impact on a 1–5 scale. The risk score is simply Likelihood × Impact (range 1–25), and the editor shows a colored severity badge automatically:
| Score range | Severity |
|---|---|
| 1 – 4 | Low |
| 5 – 9 | Medium |
| 10 – 15 | High |
| 16 – 25 | Critical |
For example, a leaf scored Likelihood 4 × Impact 4 = 16 → Critical; Likelihood 2 × Impact 3 = 6 → Medium.
"Include in risk register"
Every scoreable node has an Include in risk register checkbox. Its default depends on the node:
- A Leaf node with no children (a true terminal point in the tree) defaults to checked — it's assumed to be a concrete, reportable risk.
- Any other node (a Goal, or a Leaf that has further nodes hanging off it) defaults to unchecked.
You can always override the default in either direction — the checkbox reflects your explicit choice once you've touched it, not just the terminal-leaf heuristic.
Threat frameworks
Tag a Goal or Leaf with one or more categories from six threat-classification frameworks. Pick a framework from the dropdown, then a category within it — each tag shows as a colored chip on the node.
| Framework | Use it for | Example categories |
|---|---|---|
| STRIDE | General-purpose software threat classification | Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege |
| LINDDUN | Privacy-specific threats | Linkability, Identifiability, Detectability, Disclosure of Information… |
| OWASP Top 10 | Web application risk (2021 edition) | A01 Broken Access Control, A03 Injection, A10 SSRF… |
| OWASP Top 10 for LLM Applications | LLM-specific threats (2025 edition) | LLM01 Prompt Injection, LLM04 Data and Model Poisoning… |
| OWASP Top 10 for Agentic Applications | Agentic/multi-agent AI system threats | Memory Poisoning, Tool Misuse, Rogue Agents in Multi-Agent Systems… |
| CAPEC | Concrete, technique-level attack patterns | CAPEC-66 SQL Injection, CAPEC-62 CSRF, CAPEC-600 Credential Stuffing… |
ℹ️ MITRE ATLAS appears automatically for AI frameworks
As soon as a node is tagged with OWASP Top 10 for LLM Applications or OWASP Top 10 for Agentic Applications, a second MITRE ATLAS technique field appears alongside MITRE ATT&CK — ATLAS is MITRE's adversarial-ML/AI-specific technique catalog, the AI-world counterpart to ATT&CK.
MITRE ATT&CK / ATLAS technique mapping
Type one or more technique IDs into the MITRE ATT&CK field (comma-separated, e.g. T1078, T1110.003) or the MITRE ATLAS field (e.g. AML.T0051). Valid-format IDs render as clickable chips that link straight to the official MITRE technique page. This is free-text entry — you look up the technique ID yourself on attack.mitre.org / atlas.mitre.org and paste it in.
Treatment Plan
Record how you're responding to a leaf's risk. Each entry has a type and free-text description:
| Type | Meaning |
|---|---|
| Mitigate | Reduce the likelihood or impact with a control. |
| Avoid | Eliminate the risk by removing the feature/component that causes it. |
| Transfer | Shift the risk elsewhere — insurance, a third-party contract, a managed service. |
| Accept | Consciously decide to live with the risk as-is. |
Standards Controls
Map a node to specific controls from compliance/security standards — useful for showing an auditor exactly which control addresses which threat. Pick + Add standard, then search within it for the specific control to attach.
| Standard | Example control |
|---|---|
| ISO 27001:2022 | A.8.24 Use of cryptography |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege |
| NIST CSF 2.0 | PR.AA-03 Users, services, and hardware authenticated |
| CIS Controls v8 | CIS 6.3 Require MFA for Externally-Exposed Applications |
| OWASP ASVS 4.0 | V5.3 Output Encoding and Injection Prevention |
| PCI DSS v4.0 | Req 8.4 MFA implemented to secure access into the CDE |
| SOC 2 | CC6.1 Logical access security software, infrastructure, and architectures |
Canvas tools
- Auto Layout — automatically re-arranges the whole tree into a clean top-down layout. Handy after freehand-building a tree that's gotten tangled.
- Fit Labels — resizes nodes to fit their current label text.
- Draw connection — same mechanism as the DFD editor: select the parent, click Draw connection (or press C), then click the child.
Worked example: "Compromise customer accounts"
A goal with two independent paths in (OR logic), one of which itself needs two things to line up (AND logic):
- Drag a Goal node, label it Compromise customer accounts.
- Drag an OR Gate underneath it, connect Goal → OR Gate. Label it Account takeover vector (any one path below is sufficient).
- Drag a Leaf under the OR Gate: Credential stuffing using leaked passwords. Set Likelihood 4, Impact 4 (→ 16, Critical). Tag STRIDE → Spoofing. MITRE ATT&CK:
T1110.004. Treatment: Mitigate — "Rate-limit login attempts; enforce breached-password check on signup." - Drag a second Leaf under the OR Gate: Phishing email harvests login credentials. Likelihood 3, Impact 4 (→ 12, High). STRIDE → Spoofing. MITRE ATT&CK:
T1566.001. Treatment: Mitigate — "Enforce MFA so a stolen password alone isn't sufficient." - Drag an AND Gate as a third child of the OR Gate, label it Session hijacking via XSS (this path needs both children below to be true).
- Under the AND Gate, add Leaf Stored XSS in user-generated content (Likelihood 2, Impact 5 → 10, High; OWASP Top 10 → A03 Injection; CAPEC-86) and Leaf Session token readable by JavaScript (no httpOnly flag) (Likelihood 5, Impact 3 → 15, High; OWASP ASVS → V3.4 Cookie-based Session Management).
The finished tree — an OR gate covering three independent attack paths, one of which (session hijacking) itself requires two conditions via an AND gate.
Linking DFDs & Attack Trees
Linking ties an Attack Tree back to the architecture diagram it's threatening — so your threat model stays traceable to what it's actually describing, not a set of orphaned trees.
How to link
Linking is one-directional in setup but shows on both sides. There are two ways to create the link:
- From the Attack Tree editor — if the tree isn't linked yet, a Link to DFD ▾ button appears in the toolbar. Click it and pick a DFD tree from the same forest.
- At creation time — when you create a new tree via Add Tree and choose Attack Tree as the type, an optional Link to DFD dropdown appears right in that modal.
Where the link shows up
- In the DFD editor, an Attack Trees badge in the toolbar shows a count of every attack tree linked to that DFD, with a dropdown to jump straight to any of them.
- An attack tree can be linked to at most one DFD at a time; unlink it the same way you'd change the link, or leave it unlinked if it's exploratory and not tied to a specific architecture yet.
ℹ️ Linking is optional
You can build and score attack trees with no DFD at all — useful for a quick "what-if" exercise, or when you're modeling a threat conceptually before the architecture is finalized. Link it later once you have a DFD to attach it to.
Risk Register
The Risk Register is a forest-wide, auto-populated table of every scoreable finding across every attack tree in the forest — no separate data entry required.
How it's populated
Every Goal/Leaf node across every Attack Tree in the forest with Include in risk register checked (see Attack Trees for the default logic — terminal leaves default to included) shows up here automatically as soon as you save the node. There's nothing to separately "add" to the register.
Columns
| Column | Meaning |
|---|---|
| Risk | The calculated score and severity badge (Low/Medium/High/Critical). |
| Node | The node's label — the threat itself. |
| Type | Goal or Leaf. |
| L / I | Likelihood and Impact, 1–5 each. |
| Attack Tree | Which tree the node belongs to. |
| MITRE | Any MITRE ATT&CK / ATLAS technique chips attached to the node. |
| Mitigations | Count of Treatment Plan entries recorded on the node. |
| Owner / Collaborator | Free-text assignment fields, editable directly in the register (with autocomplete against forest members) — who's responsible for this risk and who else is working it. These are set here, not in the tree editor. |
Filtering
Three filters at the top of the register, combinable: Filter by tree (narrow to one Attack Tree), Min risk (hide anything below a score threshold), Owner (narrow to a specific assignee).
Example
Continuing the worked example from Attack Trees: as soon as those four leaves are saved, the register shows all four rows — Credential stuffing (16, Critical), Phishing email (12, High), Stored XSS in UGC (10, High), and No httpOnly flag (15, High) — each linked back to the "Compromise customer accounts" tree. Set Min risk to 13 and only the Critical entry remains; assign an Owner to each so it's clear who's tracking the fix.
Exporting & Reporting
Three different exports exist, each for a different purpose — a raw diagram export, a machine-readable threat-intel format, and a polished report for stakeholders.
From inside an editor (per-diagram)
Open the Export menu in either the DFD or Attack Tree editor:
| Option | What you get | Plan |
|---|---|---|
| Download JSON | The raw diagram data (nodes, edges, properties) as JSON — for backup, scripting, or moving data outside ThreatTree. | All plans |
| Download STIX 2.1 | The diagram re-expressed as a STIX 2.1 bundle (attack-pattern / relationship objects, with MITRE ATT&CK external_references and risk score as custom x_threattree_* properties) — for feeding into a SIEM, TIP, or other STIX-consuming tool. | Enterprise |
| Download PDF | A single-diagram PDF snapshot of just that tree. | Pro+ |
Forest-level PDF report
From a forest, open Generate Report (requires Pro or Enterprise) to build a full executive-ready PDF covering the whole forest, not just one diagram. Before generating, you set a Report title, a Classification (Confidential / Internal / Public), a Version string, and optional Version notes — all of which land in the report's Document Control section. The generated PDF includes:
- Cover page & document metadata
- Executive summary & risk posture
- Ranked risk register
- Threat analysis, per Attack Tree
- Architecture overview, per DFD
- Controls & standards mapping
- Contributors & activity log
- Appendix & forest metadata
If you've set an organization logo in Settings → Branding, it appears on the report cover — otherwise the report page shows a reminder link to add one.
All exports are server-side enforced
Every export option is gated on the server, not just hidden in the UI for lower plans — calling the export endpoint directly without the right plan returns an error rather than a file, so there's no way to bypass the STIX/PDF plan requirements from outside the app either.
Encryption All plans
Forest encryption is genuine client-side, zero-knowledge encryption — ThreatTree's server never sees your plaintext data, and never sees the key either.
What "lock a forest" actually does
From a forest's Forest Settings, click Lock & encrypt forest. Your browser then, entirely locally:
- Generates a fresh AES-256-GCM key using the Web Crypto API (
crypto.subtle) — never sent anywhere. - Encrypts every diagram name, node label, node property blob, and edge label, tree by tree.
- Uploads only the resulting ciphertext to the server — replacing the plaintext there.
- Downloads the key as a
.jsonfile to your device and emails it to your account's email address, so you have two independent copies. - Marks the forest
encrypted— every member now sees a lock screen instead of the forest's contents, until someone unlocks it.
Unlocking
Anyone who has the key can unlock — either upload the .json key file or paste the base64 key string directly. Unlocking is a one-time action that decrypts the data server-side and turns encryption off for the whole forest — it's not a personal, per-session unlock. Once unlocked, the forest behaves normally again until someone re-locks it (which generates a brand new key).
If the key is lost, the data is gone — permanently
There is no server-side recovery path, by design — that's what makes it real zero-knowledge encryption. An encrypted forest also cannot be deleted until it's decrypted first, so a lost key leaves the forest permanently locked and stuck. Keep both copies of the key (the downloaded file and the email) somewhere durable before you rely on this.
Forgot to save the key but still have the original download or email? Use Re-send key to my email on the lock screen to have it re-sent — this only works if you already have a valid copy of the key to re-send from, it can't regenerate a lost one.
Collaboration & Organizations
There are two independent ways to share access: inviting individuals to one specific forest, or creating a company Organization that gives everyone on your domain access to every forest owned by the org.
Inviting members to a forest Pro / Enterprise
- Inside a forest, open Invite Member.
- Enter their Email address and pick a Role.
- Click Send invite — they receive an email invitation and appear as "pending" until they accept.
| Role | Can do |
|---|---|
| Owner | Full control — implicitly held by whoever created the forest. Only an Owner can invite/remove members, change roles, delete the forest, or lock/unlock encryption. |
| Editor | Can view and edit diagrams — create/edit/delete trees, nodes, and edges — but can't manage membership or delete the forest. |
| Viewer | Read-only access to everything in the forest. |
Organizations Pro / Enterprise
An Organization is a bigger, domain-wide alternative to inviting people one forest at a time. Register your company's email domain once, and every forest owned by any member of the organization automatically grants Editor-level access to every other member — no per-forest invites needed.
- In Settings → Team, Create your organization using your own company email domain (personal email providers like Gmail/Outlook aren't eligible).
- Invite teammates by email — they must share the same verified domain.
- Organizations are seat-limited (set by your plan); the Team panel shows seats used vs. purchased and blocks new invites once you're at capacity.
ℹ️ Org membership overrides personal plan limits
If your organization is on Pro/Enterprise, every member gets that access level for forests within the org context — regardless of what plan shows on their own individual account.
SSO / SAML Enterprise
Enterprise organizations can configure SAML 2.0 single sign-on so members authenticate through your company's identity provider instead of a ThreatTree password. From Settings → Team, the organization owner configures the IdP's Entity ID, SSO URL, and x509 certificate, and is given the SP metadata/ACS URL to hand to the IdP admin. Once enabled, a Sign in with SSO option appears on the login page — signing in there looks up your email's domain, redirects to your company's IdP, and provisions/links your ThreatTree account automatically on first login.
Audit logs Enterprise
Enterprise forests keep an audit trail of member activity — invites, role changes, tree/node/edge creation and deletion, encryption lock/unlock, and more — viewable per forest, filterable by category.
Settings & Account
Everything about your own account and org-wide branding lives under the avatar menu → Settings, split into six tabs.
| Tab | What's there |
|---|---|
| Profile | Display name and (read-only) email address. |
| Security | Change password, set a session inactivity timeout (Never / 15m / 30m / 1h / 4h / 8h), view and revoke active sessions individually, and a Danger Zone to permanently delete your account. |
| Membership & Billing | Current plan badge, usage against Free-plan limits (forests used vs. cap), and a link to the plans page to upgrade. |
| Preferences | Theme (Light / Dark / System default), default diagram type for new trees, and email notification toggles (product updates, security alerts). |
| Branding Pro+ | Organization name, website URL, and report footer tagline (shown on PDF report cover/footer), plus logo upload (PNG/JPG/SVG/WebP, max 2MB) for the report cover page. |
| Team Pro+ | Create/view your Organization, manage members and seats, and (Enterprise, owner-only) configure SSO — see Collaboration & Organizations. |
ℹ️ Theme applies instantly across the whole app
Switching theme in Preferences previews immediately and applies everywhere — every page (including this Help Center) reads the same stored preference.
⌨️ Keyboard Shortcuts
Both the DFD and Attack Tree editors share the same shortcut set — also available any time from the ? button next to the zoom controls.
| Shortcut | Action |
|---|---|
| Del / Backspace | Delete the selected node(s)/edge |
| Ctrl+Z / Ctrl+Y | Undo / redo |
| Ctrl+S | Save |
| Ctrl+A | Select all |
| F | Fit view to canvas contents |
| + / - | Zoom in / out |
| C | Draw / cancel connection on the selected node |
| Space+drag | Pan the canvas |
| Escape | Deselect / cancel current action |