How to Threat Model a System You Inherited With Zero Documentation
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The standard threat modeling advice assumes that you have a data flow diagram, an architecture overview, a list of assets, and at least one developer who can explain how the system actually works. The systems that most urgently need threat models are the ones where none of these things exist.
Inherited systems -- applications and infrastructure taken over from a previous team, acquired through M&A, or simply never formally documented -- represent a distinct challenge. You cannot begin with the standard STRIDE or PASTA methodology questions because you cannot answer basic questions like "what data does this system process?" or "where are the trust boundaries?" without first doing the documentation work that the threat model assumes as a starting point.
This guide covers the reverse-engineering approach to threat modeling an inherited system: how to build the minimum viable documentation from observable system behavior, how to identify trust boundaries without architecture diagrams, the tools that produce useful inputs for undocumented systems, and how to run a threat model session that produces prioritized threats even when the attack surface is not fully known.
Why Inherited Systems Are Harder to Threat Model Than New Ones
A threat model session for a newly designed system has a specific starting advantage: the people in the room designed the system. They know why architectural decisions were made, what data flows where, what the trust assumptions are, and what the intended security model was. Even if the design has been partially compromised in implementation, there is a cognitive map of how the system was meant to work.
An inherited system has the opposite problem. The system exists and works (or mostly works). But the cognitive map exists only in the memories of people who have likely left the organization, in code that has been modified over years without consistent documentation practices, and in infrastructure configurations that were laid down without security review.
This creates three specific threat modeling challenges:
Unknown data flows. You cannot identify threats to data if you do not know what data the system processes, where it enters and exits the system, and where it is stored in transit. Standard threat model methodology starts with data flow diagrams. For an inherited system, you may need to construct these from network traffic captures and log analysis before the threat model session begins.
Unknown trust boundaries. Trust boundaries are where data or control moves between security contexts (different authentication domains, network segments, or privilege levels). In an inherited system, trust boundaries may be implicit -- the original developers assumed certain components were trusted without documenting why, and those assumptions may no longer hold given changes to the surrounding environment.
Unknown integrations. Legacy systems frequently have integrations with other systems that were added over time without being formally documented. A threat model that does not account for these integrations has an incomplete attack surface.
The Four Artifacts You Need Before Running the Threat Model Session
A productive threat model session for an inherited system requires four minimum artifacts. These do not need to be comprehensive or perfect. They need to be accurate enough to support the threat identification discussion. Each can be reconstructed from observation.
1. A system component map. The list of distinct components in the system: services, databases, message queues, API endpoints, external integrations, and authentication systems. This does not need to be an architecture diagram. A bulleted list with brief descriptions of each component's role is sufficient. Build this from infrastructure inventory tools (AWS Config, Azure Resource Graph, or equivalent) and network traffic analysis.
2. A data flow sketch. For each major data category the system processes, trace the path from entry to storage to output. Focus on the highest-value data: credentials, PII, financial data, and API keys. A rough flow diagram with five to ten data paths is more useful for threat modeling than a comprehensive but incomplete formal data flow diagram. Build this from network traffic captures (Wireshark, tcpdump, or cloud VPC flow logs) combined with any available API documentation.
3. An authentication and authorization summary. What authentication mechanisms does the system use? What are the privilege levels? Which components can communicate with which other components, and on what basis? This information is typically recoverable from authentication log analysis and service configuration review, even without formal documentation.
4. An external dependency list. Which third-party services, external APIs, or external data sources does the system interact with? These are trust boundary candidates and often represent the highest-risk integrations in legacy systems. Build this from network egress analysis (DNS query logs, firewall allow logs, or cloud security group rules for specific external IPs and domains).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Reconnaissance Tools and Techniques for Mapping an Unknown System
The documentation-reconstruction phase before the threat model session uses security tools in a non-adversarial way: you are using the same techniques an attacker would use to map your system, but from an authorized insider position with access to logs and configurations that an attacker would not have.
Network traffic analysis is the most valuable starting point. In AWS, enable VPC Flow Logs for the relevant VPC and analyze traffic patterns to identify which components communicate with which others. On-premises equivalent: enable NetFlow on core switches or use a network tap with Wireshark. Traffic analysis reveals integrations that no documentation mentions: the legacy reporting service that still sends data to a third-party analytics platform, the background job that authenticates to an external API, the database that accepts connections from a range of hosts wider than expected.
Authentication log analysis identifies trust boundaries. Query your identity provider logs (Okta, Azure AD, or AWS CloudTrail for AWS service authentication) for authentication events related to the system's service accounts and users. The log entries reveal what resources each service account authenticates to, which reveals the implicit trust model.
API surface mapping using tools like Burp Suite, Postman, or custom scripts against the system's API endpoints builds the external attack surface map. For internal services, use service mesh configuration (Istio, Envoy, or equivalent) or internal network traffic analysis to map inter-service API calls.
Infrastructure configuration review using AWS Config, Terraform state, or cloud provider console exports identifies security group rules, IAM policies, network ACLs, and encryption settings. This reveals the security-relevant configuration even without application-level documentation.
Identifying Trust Boundaries Without Architecture Diagrams
Trust boundaries exist where data or control crosses between components with different security contexts. In a documented system, trust boundaries are identified from the architecture diagram. In an inherited system, they must be inferred from observable system behavior and configuration.
Five patterns that reliably indicate trust boundaries in inherited systems:
Authentication changes. Any point where a component presents credentials to access another component is a trust boundary. Authentication log analysis reveals these: service account A authenticates to database B with credential set X, and that credential use represents a trust boundary between the service and the database.
Network segment changes. Traffic crossing a firewall rule, security group boundary, or network ACL is crossing a trust boundary. Infrastructure configuration review of security group and firewall rules reveals these boundaries even without network diagrams.
Protocol changes. A system that accepts HTTPS from external users but communicates internally over HTTP has a trust boundary at the HTTPS termination point. Anything inside the HTTP boundary is implicitly trusted in a way that external HTTPS traffic is not.
Privilege changes. A component that runs as a low-privilege service account but elevates privilege to access certain resources (through IAM role assumption, sudo, or equivalent) has a trust boundary at the privilege elevation point.
Data format changes. Any point where data is parsed from one format to another (JSON to SQL, XML to a native data structure, user input to a query parameter) is a trust boundary where injection attacks may be possible. Code or log analysis of data entry and transformation points reveals these.
Document each identified trust boundary as a row in a simple table: source component, destination component, mechanism (authentication type, network segment, protocol), and trust assumption (what does the source component have to be to be trusted by the destination?).
Running the Threat Model Session When Nobody Knows the Full Picture
A threat model session for an inherited system should be run with the four artifacts completed and distributed to participants before the meeting. The participants should include: a security engineer who conducted the reconnaissance (who knows what was observed), a current developer or operator who maintains the system (who knows what behavior is intentional), and if available, anyone with operational history of the system (who knows what has broken or been attacked in the past).
The session structure that works for incomplete-documentation scenarios:
Start with the data, not the architecture. Ask "what is the worst thing that could happen to the data this system processes?" rather than "what are the threats to the architecture?" This produces threat scenarios even when the architecture is poorly understood. An insider-threat scenario for customer PII data, a data exfiltration scenario, and a data corruption scenario can all be identified without a complete architecture diagram.
Use the STRIDE categories as a checklist, not a methodology. Work through each STRIDE category (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and ask for each component in your system component map whether threats in that category are plausible. Mark unknowns explicitly rather than skipping them: "We do not know whether the reporting service validates user identity before displaying records; this requires verification."
Explicitly document unknowns as threat candidates. Every "we do not know" is a potential security finding. After the threat model session, these unknowns should drive a focused investigation: specific code review of the authentication flow that was unclear, a targeted network test of the trust boundary whose behavior was uncertain.
Prioritizing Threats When the Attack Surface Is Incomplete
Threat prioritization for an inherited system requires accounting for attack surface uncertainty: some threats are to components you understand well, and others are to components where your understanding may be wrong.
A simple prioritization matrix for inherited system threats uses two axes: severity (based on STRIDE impact if the threat is realized) and confidence (based on how well you understand the component and data flow involved). High-severity, high-confidence threats are your immediate priorities -- these are threats you understand well enough to act on. High-severity, low-confidence threats drive the "unknowns to investigate" list -- you need more information before you can assess them accurately. Low-severity, high-confidence threats can be scheduled for later. Low-severity, low-confidence threats can be deferred until you have better system understanding.
The most common high-severity, high-confidence threats in inherited systems from the reconnaissance phase are:
Overly broad database access grants from service accounts (revealed by IAM or database privilege review), unencrypted internal communication between components in different trust zones (revealed by network traffic analysis), externally accessible admin interfaces that were internal-only in the original deployment (revealed by security group and firewall review), and authentication bypass possibilities in integration endpoints that were added after the original security review and never separately assessed.
These four finding categories are directly actionable from the reconnaissance data without requiring a complete architecture understanding. Fixing them before the full threat model is complete is the correct decision -- these are known-high-risk findings and should not wait for documentation completeness.
The bottom line
Threat modeling an inherited system without documentation is more work than the standard methodology describes, but it is not impossible. The work has two phases: the documentation-reconstruction phase (building the four minimum artifacts from network traffic analysis, authentication logs, infrastructure configuration review, and API surface mapping) and the threat model session itself (using the reconstructed artifacts with STRIDE as a checklist and explicitly documenting unknowns as threat candidates requiring investigation). The output is different from a standard threat model: it includes a prioritized threat list, a list of high-severity unknowns requiring focused investigation, and a baseline documentation set that makes the next threat model session for this system substantially faster. That documentation investment pays forward -- the hardest threat model to run is the first one on an inherited system. Every subsequent one is easier.
Frequently asked questions
How do you threat model a system with no documentation?
In two phases. First, reconstruct the minimum viable documentation from observable system behavior: build a component map from infrastructure inventory tools, build a data flow sketch from network traffic captures and VPC flow logs, build an authentication summary from identity provider logs, and build an external dependency list from DNS query logs and firewall egress analysis. This produces four artifacts that enable a productive threat model session. Second, run the threat model session with these artifacts, using STRIDE as a category checklist rather than a formal methodology, and explicitly documenting unknowns as threat candidates requiring further investigation.
What is a trust boundary and how do I identify one without architecture diagrams?
A trust boundary is any point where data or control crosses between components with different security contexts. In inherited systems without architecture diagrams, trust boundaries are identified from five observable patterns: authentication changes (any point where one component presents credentials to access another), network segment changes (traffic crossing firewall rules or security group boundaries), protocol changes (HTTPS termination points where external traffic becomes internal traffic), privilege changes (service account role assumption or privilege elevation), and data format changes (any point where external data is parsed into a system data structure, which is a potential injection boundary).
What tools help map an inherited system for threat modeling?
Four tools produce the most valuable inputs for inherited system threat modeling. Network traffic analysis (AWS VPC Flow Logs, on-premises NetFlow, or Wireshark) reveals inter-component communication paths and external integrations not in any documentation. Authentication log analysis from your identity provider (Okta, Azure AD, or AWS CloudTrail) reveals service account trust relationships and authentication-based trust boundaries. API surface mapping tools (Burp Suite for passive proxying, or cloud service mesh configuration review) map external and internal API attack surface. Infrastructure configuration review via AWS Config, Azure Resource Graph, or Terraform state reveals security group rules, IAM policies, and encryption settings.
What are the four minimum artifacts needed to run a threat model session?
A system component map: the list of distinct components (services, databases, queues, external integrations) with brief descriptions of each one's role. A data flow sketch: for each major data category, a rough trace of the path from entry to storage to output, focusing on the highest-value data (credentials, PII, payment data). An authentication and authorization summary: what mechanisms the system uses, what privilege levels exist, and which components can communicate with which others. An external dependency list: which third-party services, external APIs, or external data sources the system interacts with. Each can be reconstructed from observation when original design documents do not exist.
How do I run a threat model session when participants have incomplete knowledge of the system?
Distribute the four reconstructed artifacts to participants before the meeting. Structure the session around the data rather than the architecture: start with 'what is the worst thing that could happen to the data this system processes?' rather than working through the architecture diagram. Use STRIDE as a checklist applied to each component in your component map rather than as a formal sequential methodology. Explicitly document every 'we do not know' as an unknown requiring investigation -- these unknowns are potential security findings that drive focused post-session code review or testing. Participants with operational history of the system are especially valuable for surfacing 'this has been attacked or broken before in this way' context that is not in any formal documentation.
How do I prioritize threats when I do not fully understand the attack surface?
Use a two-axis matrix: severity (impact if the threat is realized) and confidence (how well you understand the component and data flow involved). High-severity, high-confidence threats are immediate priorities. High-severity, low-confidence threats drive the 'unknowns to investigate' list requiring further reconnaissance before remediation can be prioritized. The four most common high-severity, high-confidence findings in inherited systems from reconnaissance data are: overly broad database access from service accounts, unencrypted internal communication between components in different trust zones, externally accessible admin interfaces that were originally internal-only, and authentication bypass possibilities in integration endpoints added after the original security review.
How long does threat modeling an undocumented inherited system take?
Expect 3 to 5 times the duration of threat modeling a newly designed system with existing documentation. For a medium-complexity system (10 to 20 distinct components), the documentation reconstruction phase takes 1 to 2 weeks of part-time security engineer effort, depending on log availability and infrastructure tooling. The threat model session itself takes a similar amount of time to a standard session (2 to 4 hours) once the four artifacts are prepared. Post-session investigation of documented unknowns adds additional time proportional to the number of unknowns identified. The investment pays forward: the reconstructed documentation makes every subsequent security review of the same system substantially faster.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.