How do you defend writing 'a nation-state adversary is out of assumed capability' into a threat model?

## Bounding downward is a legitimate move A threat model that assumes an adversary with unlimited capability, resources and access produces a list where nothing can be triaged out, every control is insufficient, and no decision follows. Bounding the actor downward is therefore not a cop-out — it is what makes the model usable. A solo-founder scheduling tool writing *a nation-state adversary is out of assumed capability* into its model is doing the right kind of work, provided it does it in the open. The defence has four parts: state it, justify it against the assets, say what it leaves untreated, and name what would force a revisit. ## State it where the model lives An exclusion that exists only in someone's head is a blind spot; the same exclusion written into the model is a decision. Minimum record: which actor is excluded, which dial the exclusion is about (capability, resources, access), the rationale, who agreed, the date, and the trigger for reopening it. That record is what lets a future reviewer challenge the bound instead of re-arguing the findings that depended on it. ## Justify against the assets, not against effort "We could not stop them anyway" is not a justification — it is a shrug, and it is often false. The usable justification runs from the assets: what an actor of that class would be spending its resources *for*, and whether this system holds anything of that kind. A scheduling tool for one founder's customers holds calendars and contact details; the argument is that this asset does not attract an actor able to develop bespoke exploitation or coerce a supplier, not that the team is small. ## An exclusion removes threats, not categories The most common error is treating an actor exclusion as a licence to delete whole threat classes. The exclusion removes only the threats that **require capability above the assumed level**. Most of what a high-capability actor would do to a small system — credential stuffing, a stolen session, a misconfigured object store, an unpatched dependency with a public exploit — is equally available to a cheap actor and stays firmly in scope. Concretely: excluding a nation-state does not let you stop enumerating tampering with your build, because a bored contributor and a criminal group can also reach that. It lets you stop treating threats that need bespoke exploitation of an unpublished flaw, physical interception of hardware in transit, or coercion of a named employee. ## Sign-off belongs to whoever owns the consequence An actor exclusion decides what goes untreated, which makes it a business decision expressed in engineering vocabulary. The engineer proposes it; the person accountable for the asset accepts it. The security contribution is to state the consequence in plain terms — "if we are wrong about this, the outcomes we would not detect are X and Y" — rather than to hand over a severity number and let it read as approval. ## Design for the exclusion being wrong The exclusion should shape *reversible* choices more than irreversible ones. Skipping a detection capability is cheap to add later. A key-custody scheme, a data-retention design, or a single-tenant versus shared-tenant split is expensive to unwind, so a high-capability exclusion is a weak reason to choose the cheaper side of those. A good rule: the more permanent the decision the exclusion is justifying, the less weight the exclusion should carry. ## Name the revisit triggers up front The bound is true of the system as it is today, so the record should say what would make it false. Useful triggers, phrased so a non-security person can spot them: - The customer base changes shape — the first government, defence, healthcare or large-enterprise customer brings their adversaries with them. - The system starts holding a new class of data: identity documents, health records, location history, private source code. - You become a supplier inside someone else's build or deployment path, making the product a route to a bigger target. - The company becomes newsworthy, enters a regulated market, or acquires a business that was itself a target. Attaching triggers to the exclusion converts it from a permanent claim into a dated one, and gives the team a cheap review event instead of a full re-model. ## Dishonest exclusions, and how to spot one An exclusion is dishonest when it is chosen *after* the design, to make a shortcut already taken look acceptable; when it is broad enough to erase threats that cheap actors can also reach; or when nobody can say who approved it. The interview signal is whether the candidate can distinguish "we bounded the model and wrote down what that leaves untreated" from "we decided not to look".