Get 15% off for Cybersecurity Awareness Month. Use code CYBERREADY15. Explore ideas

Why Elevation of Privilege works for threat modeling

Developers understand the systems they build: how the code behaves, how components interact and what changing a design would involve. That knowledge makes them essential contributors to threat modelling. But knowing a system well does not automatically mean knowing how to identify threats against it.

How do we help developers apply their existing knowledge to security questions, without expecting them to become security experts first?

The Elevation of Privilege game by Adam Shostack was designed around that challenge. Its effectiveness comes from how its cards and rules address the difficulties of getting started, while creating space for the exploration that makes threat modelling valuable.

Balancing skill and challenge

One influence on the game’s design was the psychological concept of flow: the sense of focused engagement that can emerge when a task’s challenge is well matched to a person’s skill.

If the challenge increases without the skills to meet it, people can feel anxious or overwhelmed. If their skills grow but the challenge stays the same, they can become bored. The aim is to help people develop their abilities while keeping the task engaging and achievable.

This matters in threat modelling. Asking a newcomer to identify everything that could go wrong with a system sets a substantial challenge without necessarily giving them a way to tackle it. Experts can draw on patterns they have encountered before; beginners need support to begin recognising those possibilities.

Elevation of Privilege starts with something familiar: a diagram of the system, such as a data flow diagram (DFD). Developers can use their understanding of its components, connections and data flows as the foundation for the discussion.

The content on the cards builds on that familiarity. Threats are described in concrete terms that developers can connect to software behaviour, rather than leaving them to interpret abstract security concepts. 

The activity connects to four core threat modelling questions:

  • What are we working on?
  • What can go wrong?
  • What are we going to do about it?
  • Did we do a good job?

A simple diagram helps answer the first. The cards give players a practical starting point for the second, generating findings the team can then address and review. This is how EoP makes a demanding activity more approachable: it gives developers a manageable next step.

Providing structure without closing down creativity

Simply training developers in threat modelling can seem like an obvious starting point. Those who are new to the practice, or use it only occasionally, need a method they can follow. But there can be tension: a procedure provides direction, while threat modelling also requires the freedom to explore unexpected possibilities.

If the activity becomes a checklist, developers may learn to look for familiar problems without questioning what else could go wrong in their particular system.

Elevation of Privilege provides structure through its cards and turns, giving players a clear starting point and an opportunity to contribute. The cards prompt discussion rather than prescribe an answer. Players still need to interpret each threat, connect it to their design and explore the implications together.

That combination helps developers practise a way of thinking, building their confidence while preserving the curiosity and creativity that make threat modelling effective.

Giving everyone a way into the conversation

A physical deck of cards plays its role by creating curiosity before the discussion even begins. It gives developers something tangible to explore and an entry point into an activity that might otherwise feel unfamiliar.

The rules then turn that interest into participation. Everyone has a hand of cards and a turn to contribute, so the discussion is less dependent on the most confident or experienced people speaking first. 

That matters when someone is sitting alongside senior developers or security specialists. A player can say, “I think this might apply here, but I’m not sure how,” and invite others to help. They can contribute without having a polished answer, while the discussion provides immediate feedback and an opportunity to learn.

Producing real outcomes

Many games train and educate. Elevation of Privilege goes further: players examine their own system design and uncover real security issues. Learning happens alongside work that directly benefits the software they are building.

Players earn points for identifying threats, missing test cases and questions that need investigation. These contributions produce actionable findings that the team can record, track and address through its development workflow.

The game starts with something developers know - a whiteboard diagram, and ends with something they can act on: bugs, tests and investigation tasks. That gives the session a clear purpose and players a tangible sense of accomplishment.

 

This article draws on Adam Shostack’s white paper, Elevation of Privilege: Drawing Developers into Threat Modeling, written during his time at Microsoft.