Threat models: the key concepts

A threat model is a structured way to think about security risks for a specific situation. Instead of asking “Is this secure?”, you describe the scenario: who the potential attacker is, what they are trying to achieve, what assets you care about, and what protections are in place. This helps you connect security goals to realistic risks.

In practice, threat model concepts usually include:

  • Assets: what you want to protect (for example, your browsing activity, accounts, or device data).
  • Adversary: who might try to interfere (for example, someone on the same network, a service you connect to, or a party with legal or technical leverage). Keep this at the level of plausible capabilities, not “everyone everywhere.”
  • Attack goals: what success looks like (for example, observing traffic patterns, modifying data, redirecting you, or identifying a user).
  • Attack surface: the entry points and paths relevant to the scenario (your device, apps, network connections, DNS use, and the connection path).
  • Defenses and assumptions: what you believe will limit risk, and where those beliefs may be wrong.

A useful threat model is operational: it produces decisions, like what to configure, what to test, and what claims to treat as uncertain.

Operating conditions: what makes the model “work”

Threat modeling isn’t one-size-fits-all. The same person or organization can face different risks depending on conditions. For example, risk changes when:

  • you switch networks (home Wi‑Fi vs. mobile data vs. public hotspots),
  • you use different devices or browser profiles,
  • you change locations,
  • you alter how you authenticate (single sign-on, account recovery flows, session persistence),
  • time changes (for example, when infrastructure, policies, or network behavior changes).

For VPN-related setups in particular, “operating conditions” often include:

  • The connection path you actually use (whether traffic goes through the VPN tunnel consistently).
  • DNS behavior (how name resolution is handled while connected).
  • Application scope (which apps route traffic through the tunnel and which might bypass it).
  • Client configuration (whether security-relevant settings match your expectations).

Because these conditions vary, a threat model should be written to match your environment. If you later change anything important, re-check whether the original threat assumptions still hold.

Limitations you should treat as non-negotiable

Threat models clarify risks, but they also highlight limits. Common limitations include:

  1. No tool guarantees anonymity, safety, or access. A VPN can reduce some risks, but it does not provide absolute, guaranteed privacy or protection in all situations.
  2. Performance and availability vary. Connection speed and uptime can change based on network, device, location, provider choices, and time.
  3. Claims may be incomplete or time-dependent. Some “security” or “capability” statements depend on implementation details, which may change. For current product behavior and legal or empirical assertions, you should verify with reliable, up-to-date information.

A practical way to handle uncertainty is to separate:

  • what you can reasonably verify today in your setup, and
  • what relies on assumptions or marketing-style claims that may not apply to your exact conditions.

How to verify your assumptions in a consumer setup

Verification is how a threat model becomes operational. Since there are no stable answers that fit every device and network, focus on checks you can repeat and interpret.

  1. Validate routing scope Confirm which apps and interfaces actually use the secured connection. If some traffic bypasses the intended path, that can undermine the threat model’s assumptions about exposure.

  2. Check DNS and name resolution behavior DNS handling matters for identifying traffic patterns and preventing certain classes of leaks. Make sure the behavior matches your security goal (for example, avoiding unexpected resolution paths while connected).

  3. Compare before/after observations (carefully) Use non-invasive tests to see whether the observable effects changed in the way your model expects. If the difference is inconsistent, treat that as evidence to update assumptions.

  4. Review configuration against your threat goals Threat models often map to concrete configuration choices: whether blocking or fallback behavior is enabled, whether you are using the right client settings, and whether your device network permissions allow the expected routing.

  5. Re-test when conditions change If you switch Wi‑Fi networks, travel, change devices, or update the app, re-run your checks. Threat models depend on operating conditions; changing them can invalidate earlier conclusions.

Direct next step: turn concepts into a checklist

To make threat models actionable while diagnosing or configuring a VPN connection, do three things: (1) write down your assets, adversary capabilities, and attack goals; (2) list the operating conditions that could change the risk; and (3) run repeatable verification checks in your own environment. If any verification fails, adjust the model or the configuration—don’t rely on absolute guarantees.

If you want, you can also consult a threat models checklist for concepts and operation to guide setup, diagnostics, and troubleshooting: /guides/threat-models-concepts-checklist/.