An insurance platform runs a threat modelling exercise that produces a long list nobody acts on. What went wrong, and what makes threat modelling useful?

What went wrong

Almost always one of three things:

• It was done too late, after the design was fixed, so the findings could only become a backlog rather than changing the architecture. A threat model is a design activity; performed after implementation it is a vulnerability list.
• It was unscoped, attempting to cover the whole system, producing breadth without depth and a list too long to prioritise.
• It produced findings without owners or severity, so nothing distinguishes the important from the theoretical and the whole list is deferred equally.

What makes it useful

• Scope to one flow or one boundary — the claims submission path, the payout path, the document upload path. A model of one flow that changes the design is worth more than a model of the system that changes nothing.
• Do it during design, when the answer can be "then we will not do it that way" rather than "we will add a mitigation later".
• Identify what the adversary wants, concretely. For an insurance platform: fraudulent claims, exfiltration of health or financial data, manipulation of premium calculation, denial of a legitimate claim. The attacker's goal, not a catalogue of techniques, is what focuses the exercise.
• Prioritise by consequence and likelihood, and be willing to write "accepted" against findings — an accepted risk with a named owner is a legitimate outcome and a long unprioritised list is not.
• Produce specific, testable mitigations rather than principles, each with an owner and a date.

The document-processing dimension specific to this domain

Insurance platforms accept files from claimants, which is one of the highest-risk surfaces available: parser vulnerabilities, embedded content, resource exhaustion via crafted files, and the fact that documents are processed by pipelines with broad access.

Processing untrusted files belongs in an isolated environment with no ambient credentials, no network egress, and hard resource limits — and that is a design conclusion a threat model reaches early and a vulnerability scan never reaches at all.

The measure of success

Did the design change? If no design decision was altered, the exercise documented the system rather than improving it. That is the question to ask at the end, and it is more useful than the finding count.