Pull up almost any threat model and look at where the attackers are. They're on the left of the diagram, outside the first trust boundary: an anonymous user, a bot, a criminal group probing the login page. Everything to the right of that line, including the support team, the on-call engineers, the contractor with a VPN account and the admin panel they all share, is drawn as trusted infrastructure, and nobody applies STRIDE to it.
That's a strange blind spot, because the people inside the line have something no outside attacker starts with: legitimate access, and the knowledge of where the valuable data lives.
The argument in one line: every serious external attack eventually becomes an insider problem, because the attacker ends up holding a real employee's access. A threat model that trusts everything inside the perimeter has no answer for the moment that happens.
Three kinds of insider, and only one is a villain
The phrase "insider threat" conjures a disgruntled employee walking out with a USB stick. That person exists, but they're one of three cases, and the least common of the three in most organisations:
- The malicious insider uses their access deliberately: for money, revenge, or because someone outside is paying or coercing them. In one well-documented case, a senior developer at Ubiquiti used his own access to copy confidential data, then posed as an anonymous hacker to demand a ransom for it. He was sentenced to six years in prison in 2023.
- The careless insider means no harm: the engineer who pastes production credentials into a public repository, the analyst who exports a customer list to a personal drive to work from home, the admin who runs a destructive command against the wrong environment. Intent is zero, but the access is real, so the impact can be just as large.
- The compromised insider isn't the insider at all. It's an outside attacker who has phished, bought or stolen a legitimate account and now acts with that person's permissions. In the July 2020 Twitter incident, attackers used phone spear-phishing against a small number of employees, then used the access they gained to reach internal account-support tools and take over high-profile accounts.
There's a fourth situation that blurs the categories: the former insider whose access outlived their employment. Block disclosed in 2022 that a former employee had downloaded Cash App Investing reports, containing information on about 8.2 million current and former customers, after their job ended; the reports were ones they had routinely accessed while employed. Nothing about the access path was exotic. It just hadn't been closed.
Our glossary entry on threat actors covers the malicious and negligent insider as actor types. The point here is narrower: whichever of these you're worried about, they all travel along the same paths through your system, and those paths are usually missing from the diagram.
Why threat models leave insiders out
It's rarely a decision. It falls out of how most teams draw their systems:
- One trust boundary, drawn at the edge. A typical data flow diagram has a single trust boundary between the internet and the company. Everything inside it inherits trust, so no flow inside it is ever analysed.
- The admin plane isn't on the diagram. The customer-facing API gets drawn carefully. The support console, the internal "impersonate user" feature, the read replica analysts query directly, the cloud console and the CI system that can deploy to production usually don't appear at all, even though they're the most powerful paths into the data.
- It feels personal. Sitting in a workshop and asking "what if Priya in support wanted to steal our customer list?" is uncomfortable, so the question doesn't get asked. Modeling external attackers carries no such social cost.
- It's filed under HR. Insider risk programmes often live with HR, legal or a dedicated security team, focused on people: background checks, monitoring, offboarding. That work matters, but it doesn't change how the system is designed, and the design is what decides how much damage one person can do.
Redraw the diagram with the admin plane in it
You don't need a separate methodology. You need the parts of the system that insiders use to be on the diagram, with boundaries around them:
- Draw internal roles as actors. "Support agent", "on-call engineer", "database administrator", "contractor", "CI pipeline". Each is an external entity on the diagram with its own flows, exactly like "anonymous user".
- Add trust boundaries inside the company. At minimum: corporate network versus production, admin tooling versus the product, and wherever regulated or customer data sits. Each boundary is a place where the question "should this specific person be able to do this?" has to be answered by a control rather than by assumption, which is the same shift zero trust architecture asks for at the network level.
- Draw the admin paths as first-class flows. Support console to customer records. Engineer laptop to production database. Analyst to the data warehouse export. CI system to production deploy. Identity provider admin to everyone's permissions. These are the flows an insider, or anyone who has stolen an insider's account, will actually use.
STRIDE, aimed inward
Once the internal flows are on the diagram, STRIDE works on them as it does anywhere else, but two categories that are often treated as afterthoughts on the external boundary become central:
| Category | The insider version of the question |
|---|---|
| Spoofing | Are there shared admin accounts, so an action can't be tied to one person? Can a support agent act as a customer, and is that recorded as the agent or as the customer? |
| Tampering | Can anyone change production data directly, bypassing the application's validation and history? Can one engineer change and deploy code with nobody else reviewing it? |
| Repudiation | Are admin actions logged at all? Could the person who performed an action also delete or edit the log of it? This is the category that matters most for insiders, because the people with the most access are often the same people who administer the logging. |
| Information disclosure | Who can read all customer records, rather than the one they're working on? Is there a bulk export, and would anyone notice if it ran at 2am? |
| Denial of service | Can a single person delete a production database, a backup set, or a cloud account? Are backups stored where the same credentials can destroy them? |
| Elevation of privilege | Can someone grant themselves more access? Who administers the identity provider, and who reviews what they do? |
An attack tree makes the same point from the other direction. Take a goal like "exfiltrate the customer database" and branch it: through the public API, through a compromised dependency, through the analytics export, through a support agent's session, through a database credential on an engineer's laptop. In most systems, the insider branches are the shortest ones, with the fewest controls along them.
The controls that come out of it
None of these is exotic, and most are things security teams already recommend. The difference is that a threat model ties each one to a specific internal flow, which is what gets them prioritised:
- Least privilege, scoped to the task. A support agent sees the customer whose ticket is open, not a searchable list of every customer.
- Just-in-time and break-glass access. Production access is requested, time-limited and logged, and emergency access triggers an alert rather than happening silently.
- Two-person rules for the irreversible. Code review before deploy, approval before deleting data or backups, separation between who can change permissions and who reviews those changes.
- Audit logs the admins can't edit. Ship admin-action logs somewhere the people being logged have no write access to.
- Limits and alerts on bulk access. Rate-limit exports, alert on unusual volume, and require a reason for access to sensitive records.
- Offboarding that actually removes access. Including API keys, personal access tokens, shared credentials the person knew, and any vendor or contractor accounts. Treat a contractor's or vendor's access as its own flow; third-party integrations deserve the same scrutiny.
Layered together, that's defence in depth applied inside the perimeter instead of only at it.
This isn't about distrusting your colleagues
The most common objection to insider threat modeling is that it signals distrust. It's worth framing the other way round. The goal isn't to find out who might betray the company; it's to make sure no single person, and no single stolen account, can cause a catastrophe alone. That protects employees as much as customers. The engineer whose laptop gets compromised is far better off if their credentials couldn't have deleted production on their own. The support agent accused of leaking data is far better off if a tamper-proof log shows exactly what they did and didn't access.
Framed that way, the workshop question changes from "what if Priya were malicious?" to "what could someone do with Priya's access?", which is a question about the system rather than the person, and it's the same question you'd ask after any phishing incident anyway.
If your current threat model has exactly one trust boundary and it's at the edge, that's the place to start. Add the admin plane, draw the people who use it, and run STRIDE across the line you've been treating as safe. It's usually where the shortest path to your most valuable data has been hiding.
For industries where privileged internal access is heavily scrutinised, see threat modeling for fintech and threat modeling for healthcare, or start from the free data flow diagram template.