How to Get Buy-In for Threat Modeling From a Skeptical Team

Every other guide in this series assumes the meeting is already in the calendar. This one is about the harder problem, which is getting anyone to show up — and the first thing to get right is the diagnosis. Engineers who resist threat modeling are usually not uninformed about security. They have met security processes before, and the processes were bad: a checklist someone completed in a spreadsheet, a report that arrived two weeks after the code shipped, a gate that added a fortnight and produced nothing anyone acted on. Their skepticism is a reasonable inference from experience.

That reframing matters, because it changes the strategy entirely. You are not arguing against ignorance, which you might win with facts. You are arguing against evidence, and the only thing that beats evidence is better evidence. Every persuasive move in this post reduces to the same idea: stop explaining that threat modeling is useful and arrange for the team to watch it be useful, once, on something they care about.

Concede the objections that are true

The fastest way to lose a skeptical room is to treat a fair objection as an obstacle to be handled. Most of what you will hear contains something correct, and saying so buys more credibility than any argument that follows it.

Notice how many of those answers involve asking for less. That is deliberate. The instinct when facing resistance is to make the case bigger — more risk, more consequence, more urgency — and it reliably backfires, because a bigger case implies a bigger ask, and the size of the ask is what they were objecting to.

Choose the first system carefully

The first session is the whole campaign. Pick its subject deliberately rather than starting with whatever is most at risk, because the goal of session one is not coverage — it is a demonstration. Three criteria matter, roughly in this order:

• It is being designed right now. Something in flight, where a conclusion can still change the design this week. A model of a system that shipped two years ago produces findings that compete with the roadmap and lose; a model of something not yet built produces decisions, which cost nothing.
• It has consequences somebody feels. Money, personal data, access control, an integration with a customer's system. Not the internal admin tool nobody would notice — you need the room to care about the answer.
• Its owner is curious rather than hostile. Aim for the engineer who is unconvinced but interested. Converting your loudest critic first is a satisfying story and a bad plan; converting a respected peer is what actually moves a team, because skeptics are persuaded by colleagues, not by the security function.

One more constraint that people skip: keep the scope small enough to genuinely finish. A single service and its immediate neighbours beats "the platform" every time. The failure mode of an ambitious first session is not that it goes badly — it is that it runs out of time and ends with nothing concluded, which confirms exactly what the skeptics predicted.

Run it as a design conversation

Do not open by teaching a framework. A first session that begins with a slide explaining STRIDE has already told the room this is a security ceremony they are attending rather than a design problem they are solving. Use the framework as a private checklist to make sure you covered the ground; do not make the team learn it to participate.

Start where engineers naturally start: at a whiteboard, drawing how the thing works. The data flow diagram is the vehicle, and building it collaboratively does two useful things before any threat is discussed. It surfaces disagreement about the system's own behaviour — which happens in almost every first session and is worth the ninety minutes on its own — and it puts the team in the familiar posture of explaining their design rather than defending it.

Say plainly at the start what the session is not: not an audit, not a review of anyone's work, not something that produces a document with their name on it in a compliance folder. That reassurance sounds unnecessary until you notice how differently people talk once they have heard it. The mechanics of the session itself — agenda, who to invite, how to keep it moving — are covered in the first workshop guide; what follows here is only what changes when the room is skeptical.

Let them find it

This is the single highest-leverage technique in the post, and it is mostly a matter of restraint. When you see the flaw — and if you are experienced you will often see it early — do not say it. Ask the question that leads there.

"What happens if this call arrives twice?" "Who else can write to that queue?" "What proves this request came from the app rather than from curl?" "If someone had this token, what could they do with it?" Then wait. The pause is uncomfortable and it is doing the work.

The difference in outcome is not subtle. A finding you announce is a criticism, and it lands on someone who now has to decide whether to agree with you. The same finding reached by the engineer who owns the code is a discovery, and they will spend the next ten minutes arguing for fixing it, occasionally against you when you suggest it might not be urgent. You are not being coy for its own sake — you are choosing which of the two conversations the team remembers about threat modeling.

The corollary is to be genuinely willing to be wrong in the room. If someone explains why your concern does not apply, say so, write down the assumption their answer depends on, and move on visibly satisfied. A facilitator who can be talked out of a threat is one whose remaining threats carry weight.

Ship one fix before you ask for anything else

A session that ends with a list has produced nothing yet, and skeptics are correct to withhold judgement at that point. What converts a demonstration into evidence is a change that actually lands.

So from the first session, deliberately pick one item that is small, clearly worth doing, and owned by someone in the room, and get it done inside the sprint. Not the most severe finding — the most shippable one. Severity is the right basis for prioritising a backlog; it is the wrong basis for choosing your proof of concept, because the biggest finding is usually the one that needs a design change, a quarter, and someone else's roadmap.

Then, when it ships, say so in one sentence to the same people who were in the room. Not a report — a sentence. That single closed loop does more for the second session's attendance than any amount of advocacy, because it demonstrates the one thing every previous security process failed to demonstrate: that participating produced a result rather than an obligation.

Speak in their units

How you describe the outcome determines who repeats it. "We identified fourteen threats" is a security metric, and it sounds to an engineering manager like fourteen new tickets. Nobody forwards that sentence.

Describe the same session in the units the audience already uses. To engineers: we changed the auth design before writing it, which saved rewriting the session handling later. To a product lead: we found that the export feature would have shipped able to read other tenants' data, and we caught it in design. To an executive: two of our top three risks now have owners and dates, and the one we could not resolve internally is on your desk with a recommendation. Same session, three sentences, none of them counting threats.

The most persuasive number available is usually avoided rework rather than found vulnerabilities, because it is the one that lands with people who have to justify the time. If a design change in session one prevented a migration later, say that — it is both true and the argument that survives contact with a planning meeting.

Tell a skeptic from someone who is blocked

Not all resistance is the same thing, and mistaking one for the other wastes months. A skeptic is unconvinced and movable by evidence — everything above is written for them. Someone who is blocked has already agreed with you and cannot act, and no amount of persuasion changes their situation.

You can tell them apart by what happens after agreement. If a person says the idea is sensible and then nothing occurs, repeatedly, the obstacle is not belief. It is usually incentives: they are measured on delivery dates and nothing else, and an hour spent modelling is an hour that shows up as slippage while the flaw it prevented shows up as nothing at all. That is a rational response to how they are being measured, and it is not fixable by making a better case to them. It is fixable one level up, by whoever sets what gets measured — which is a different conversation, with a different audience, and pretending otherwise is how well-intentioned adoption efforts stall for a year.

The rarer case is genuine hostility, usually from someone who feels a security review implies their previous work was deficient. The remedy there is scope: model something new, where there is no prior work to be judged, and let their contribution be expertise rather than exposure.

What buy-in actually looks like

It is not applause, and it is not a policy. The signals worth watching for are quieter and much more reliable:

• Someone schedules the second session without being asked.
• An engineer raises a threat in a design review you are not in.
• A pull request description references a decision from the model.
• Someone asks whether a change is big enough to warrant revisiting the model — the question means they now think of it as a living thing.
• You get invited earlier. This is the strongest signal there is, because it means the team has concluded the input is more useful before the code than after it.

Those take a few months, not a few weeks, and the mistake at this stage is to formalise too early. The instinct once two teams are doing it voluntarily is to write the policy and make it mandatory. Resist that for longer than feels comfortable: a mandated model gets produced to satisfy the mandate, which is precisely how threat modeling earned its reputation with the people you just persuaded.

Where buy-in campaigns go wrong

• Leading with the mandate. A requirement produces compliance, and compliance produces documents. You want the practice, which only comes voluntarily.
• Leading with the tool. Tool selection before anyone has run a session is a way of feeling productive while avoiding the actual obstacle, which is the ninety minutes.
• The security team writing the model. Handing a completed threat model to a team creates a document they did not write and will not maintain, and reinforces that this is somebody else's job.
• Starting with the scariest system. The legacy monolith is where value is, and it is a terrible first session — too big to finish, too old to change, too likely to end in a list nobody can act on.
• Selling with fear. Breach anecdotes work once, on people who already agreed. To an engineer who has heard three of them this year, it reads as pressure rather than evidence, and it makes every subsequent claim sound like marketing.
• Producing the forty-page output. Nothing confirms the "document that rots" objection faster than proving it in week one.
• Measuring adoption by sessions held. Count design decisions changed instead. Sessions held is the metric that produces sessions held.

The underlying point is that threat modeling adopts the way engineering practices adopt generally — code review, testing, on-call — which is by demonstrating value to peers, not by being required. Every one of those was once resisted by reasonable people for reasonable reasons, and none of them won its argument by making the case more forcefully. They won by being the thing that was obviously working on the team next door.

In regulated environments there is a second argument available, and it is worth holding in reserve rather than leading with: the same session output doubles as audit evidence your team is producing anyway. See the industry threat modeling guides, or bring a pre-labelled DFD to the first session from the free templates.