You've run a threat model and found real issues, but engineering leadership says the roadmap has no room this quarter. How do you get the fixes prioritised?

Short answer

To get engineering buy-in for threat-modeling findings, translate each issue into a concrete failure scenario, business impact, exploitability, blast radius, and cost of delay. Push urgent fixes now, schedule lower-risk items with owners and dates, and make accepted residual risk explicit instead of letting it disappear from the roadmap.

The finding needs to be spoken in the roadmap's own language

A threat-modeling finding presented as "this violates a STRIDE category" competes for attention with feature work described in terms of revenue, customer commitments and deadlines, and it loses that competition by default because it is speaking a different language. The translation that actually moves a roadmap decision states three things concretely: what specific failure happens, what it costs when it happens rather than how severe it sounds in the abstract, and how that cost changes depending on when the fix lands.

"An attacker who compromises the recommendation service can use its payments credential to issue refunds to arbitrary accounts" is a sentence a product leader can weigh against a feature; "there is an elevation-of-privilege risk at this trust boundary" is not, even though both describe the same finding.

Blast radius and exploitability are the two dimensions that actually justify urgency, and it is worth ranking findings on them explicitly rather than presenting the whole list as equally pressing, because a list where everything is critical reads to a roadmap owner as a list where nothing has been prioritised. A finding that requires an attacker to already hold an internal credential is real but bounded; a finding reachable from an unauthenticated public endpoint with a clear path to customer data is a different category of urgent, and saying so — ranking rather than flattening — is what makes the rest of the ask credible.

Cost of delay is the argument that competes with feature work

The second half of the translation is making the cost of not fixing something now, rather than later, explicit. Some fixes get cheaper to defer — a hardening improvement with no active exploit path can reasonably wait a quarter. Others get dramatically more expensive the longer they wait, particularly anything that a growing number of features are being built on top of, because every subsequent feature inherits the same flaw and the eventual fix has to be threaded through more code. Naming that distinction turns "we don't have room this quarter" from a blanket rejection into a real trade-off leadership can reason about: room for this specific fix now, against a larger and harder fix plus everything built on top of the gap later.

Finding                           Exploitability      Blast radius    Cost of waiting
---------------------------------------------------------------------------------------
Overscoped payments credential    Needs internal      Arbitrary       Grows: every new
on order service                  compromise first    refunds         integration inherits it
Missing rate limit on password    Public, no auth     Account         Roughly flat
reset endpoint                    required             takeover
Verbose error message leaking     Public, no auth     Info disclosure Roughly flat
stack traces                      required             only

Not everything belongs on this quarter's roadmap, and saying so is credibility

The trap in this scenario is treating every rejected finding as a failure of persuasion, when for the lowest-severity items on the list, "not this quarter" may be the genuinely correct call — spending political capital insisting on a hardening improvement with a narrow blast radius, against a roadmap with real commercial pressure, burns trust you will need for the finding that actually matters.

The credible position separates findings into three buckets out loud: fix now regardless of roadmap pressure because the exploitability and blast radius leave no acceptable alternative; schedule explicitly with a date and an owner, tracked the same way a committed feature is tracked rather than left in a document nobody revisits; and accept as residual risk, which is a legitimate outcome provided a specific named decision-maker signs off on accepting it, rather than the risk defaulting into acceptance because nobody said no.

That last point is the part people skip under time pressure and the part that matters most. A finding that gets deprioritised with no explicit owner and no date has not been accepted, it has been forgotten, and the difference surfaces later as "why did nobody flag this" rather than "we made a documented trade-off." Making leadership say yes to a specific risk, in writing, rather than letting a roadmap conversation end in ambiguity, is what converts a threat model from a document into an actual decision.

The fixes most likely to get roadmap room are the ones you can describe as a specific failure with a cost, not the ones you describe as more severe.

---

© 2026 Preptima. Originally published at preptima.com.