LINDDUN: A Worked Privacy Threat Model and Its Limits

LINDDUN is STRIDE for privacy. A worked pass on a vehicle telematics backend, where it contradicts STRIDE, and where it expands the threat taxonomy.

LINDDUN is STRIDE for privacy. Same shape: a taxonomy of threat types you walk against a data flow diagram, element by element, so you are less likely to forget a whole class of problem. The difference is the question it answers. STRIDE asks whether your system can be attacked. LINDDUN asks whether your system, working exactly as designed and fully secured against attackers, still harms the privacy of the people whose data it touches.

Those are different questions, and the gap between them is the whole reason LINDDUN exists. A system can be locked down (encryption in transit and at rest, tight authorization) and still collect far more data than it needs and quietly destroy a person’s ability to deny they were ever in the system. None of that shows up on a STRIDE pass. Confidentiality is about keeping data from people who should not have it. Privacy is about what you, the legitimate operator, are allowed to know and do with data about a person in the first place. LINDDUN is the one widely used framework that treats that as the main object of analysis rather than folding it into the “information disclosure” box and moving on.

This post covers LINDDUN from first principles, runs it against the same vehicle telematics backend I used in the STRIDE writeup, and is honest about where it overlaps STRIDE, where it needs expertise you might not have, and where the evidence for it is thinner than I would like.

The seven threat types

LINDDUN is a mnemonic for seven privacy threat types. As with STRIDE, each one is the inverse of a property you want to hold. STRIDE negates confidentiality, integrity, availability, authentication, and authorization. LINDDUN negates the privacy-specific goals that sit alongside those: unlinkability, anonymity, plausible deniability, undetectability, transparency, and lawful processing.

Letter	Threat type	Property it breaks	Concrete example
L	Linking	Unlinkability	Tying a pseudonymous user’s separate actions together, or joining records across two databases, to build a profile without ever learning the name
I	Identifying	Anonymity / pseudonymity	Re-identifying a specific person from supposedly anonymous data: a handful of timestamped locations, or one rare attribute
N	Non-repudiation	Plausible deniability	Stored evidence proves a person did or said something they cannot later deny: a whistleblower, document metadata, read receipts
D	Detecting	Undetectability	Learning that a record exists without reading it. Knowing someone holds a file at a rehab clinic implies an addiction, content unseen
D	Data Disclosure	Confidentiality	Collecting, storing, or exposing more personal data than the job needs. This is the type that overlaps STRIDE’s information disclosure
U	Unawareness	Transparency / intervenability	The person does not know what is collected, or cannot act on it: no real consent, no way to correct or delete
N	Non-compliance	Lawful processing	Handling personal data in a way that breaks GDPR, CCPA, HIPAA, or your own stated policy

A naming note for anyone cross-referencing older material. The framework relabeled its types in its 2023 revision, from noun forms to gerunds: Linkability became Linking, Identifiability became Identifying, Detectability became Detecting, and Disclosure of information became Data Disclosure. The original 2011 paper and most secondary write-ups still use the old names. They mean the same things. I am using the current naming from linddun.org throughout.

The one that trips people up: non-repudiation

This is the inversion worth slowing down for. In STRIDE, repudiation is the threat: someone performs an action and later denies it, and you want non-repudiation (audit logs, signed entries) so you can pin them. In LINDDUN, non-repudiation is the threat. Seen from the data subject’s side, the system’s ability to prove they did something is a privacy harm, because it strips away plausible deniability.

The canonical example is the whistleblower: if the system retains attributable evidence of who leaked what, that person can be prosecuted. The modern, sharper version comes straight from the LINDDUN catalog: data from a menstruation-tracking app, retained and attributable, can be used as evidence to prosecute someone under abortion law. Read receipts proving a message was opened, author metadata baked into a document, a signed transaction log: all of them are non-repudiation threats in the privacy frame.

There is an apparent conflict here with security, and it resolves cleanly. Non-repudiation is a legitimate security goal for some data and a privacy threat for other data. You just should not want both for the same data item. That distinction is the whole game, and it is the thing STRIDE and LINDDUN will openly disagree about on a real system. I will hit a concrete case of that disagreement below, because it is my favorite thing about running both: the audit log you added to satisfy STRIDE can be the exact finding LINDDUN flags.

How you run it

Same four questions as any threat-modeling exercise, the ones from the Threat Modeling Manifesto that STRIDE also uses: what are we building, what can go wrong, what are we going to do about it, did we do a good job. LINDDUN answers the second one, with a privacy-specific catalog behind it. You start from the same artifact you would build for STRIDE, a data flow diagram with processes, data stores, data flows, external entities, and trust boundaries. For LINDDUN, the elements you care most about are wherever personal data is collected, stored, flows, or gets retrieved.

The catalog is the part that does the heavy lifting. LINDDUN ships seven threat trees, one per type, each branching into more concrete characteristics, plus over 120 concrete examples. That is the knowledge it brings that you would otherwise have to carry in your head.

It comes in three flavors, and the only real decision is how much rigor you can afford:

GO is the lean version: a deck of 33 cards covering the most common privacy threats, organized into the seven types. You sit a team down with the cards and a system sketch and brainstorm. It lowers the expertise bar and gets you started fast.
PRO is the systematic version: the full DFD, the threat trees, the mapping tables, every interaction examined. Thorough and slow, and it supports tooling to automate parts of the analysis.
MAESTRO is the newest (also 2023), and it extends the DFD with extra architectural detail so that threats fall out of the model rather than out of the analyst’s memory. The goal is reproducibility. I have not used it in anger, so I will not vouch for whether it delivers.

Start with GO. Reach for PRO when the system holds personal data of real consequence and you need the full catalog. That, roughly, is the “best for” answer: LINDDUN earns its keep on systems handling health, financial, location, or behavioral data, especially anything under GDPR, CCPA, or HIPAA.

A worked pass: the telematics backend, again

I am reusing the system from the STRIDE post on purpose. That post ended by saying you should run LINDDUN alongside STRIDE on anything holding personal data, and a fleet telematics backend full of location history is about as personal as it gets. Here is what the privacy lens surfaces on the same diagram. This is just a general example telematics backend that does not represent any real telematics back end services or data collection practices.

flowchart LR TCU["Vehicle TCU"] OP["Fleet operator browser"] subgraph backend["Trusted backend"] GW(("Ingest Gateway")) SVC(("Telematics Service")) subgraph datatier["Data tier"] DB[("Location history + command log")] end end TCU -->|"telemetry incl. precise GPS, commands"| GW OP -->|"HTTPS"| SVC GW --> SVC SVC <-->|"reads + writes"| DB style backend stroke-dasharray: 5 5 style datatier stroke-dasharray: 5 5

The personal data is the point. Let’s assume that each vehicle streams timestamped, precise location continuously, and the store keeps months of it across the whole fleet. Now let’s walk the types.

Data Disclosure. A breach of that store exposes everyone’s location history. This is the same finding STRIDE produced as information disclosure, and the same mitigation applies: encrypt at rest, lock down access. I am logging it once and moving on, because the interesting privacy threats are the ones STRIDE never saw.

Linking. No breach required. Even pseudonymized, the trips link into a pattern of life. A pickup at the same residential address every weekday at 07:40, then the same office, ties a string of “anonymous” trips to one routine. Linking is what turns scattered points into a profile.

Identifying. Once linked, the pattern identifies. Home plus workplace plus overnight location singles out a person even with the name stripped from the record. A small number of timestamped locations is often enough to pick one individual out of a large population.

Detecting. The mere existence of a record leaks. If an outsider can tell that a given vehicle is enrolled and reporting, they learn it is in service and someone is using it, without reading a single GPS fix.

Non-repudiation. Here is the STRIDE disagreement I promised. In the STRIDE pass I added an append-only, signed command log to kill repudiation, so an operator cannot issue a remote unlock and later deny it. That is good, and it is non-repudiation working as a security goal, applied to operator actions. But the telemetry the same system retains, every GPS fix with a timestamp, is a non-repudiation threat against the driver. It is durable proof of where they were, and they cannot deny it. Same system, two logs, opposite verdicts. The resolution is exactly the principle from earlier: you want non-repudiation for the operator’s commands and deniability for the driver’s movements, and those are different data.

Unawareness. Does the driver know the unit streams precise location continuously to a backend that keeps it for months, and can they do anything about it? In a fleet, consent is genuinely murky: the operator owns the vehicle, but the driver is the person whose movements are recorded. Unawareness is the type that forces that question onto the table.

Non-compliance. Holding granular location history indefinitely, with no lawful basis and no retention limit, is a data-protection problem under GDPR and its analogs. LINDDUN scopes this type narrowly, to the compliance gaps that fall out of the six threats above, which I think is the right call.

The contrast is the payoff. STRIDE looked at this system, flagged the database breach, and told me to encrypt at rest. LINDDUN flags the same breach and then says the deeper problem is that I am holding precise, linkable, identifying location history at all. The mitigation STRIDE never suggests is to collect less: coarsen the GPS, shorten retention, drop fields nobody uses. Data minimisation is the highest-impact privacy control, and no security framework will ever recommend it, because from a security standpoint the data is not the problem.

From threats to fixes

LINDDUN points you at mitigations the way STRIDE points you at signatures and access control. The usual reference is Hoepman’s eight privacy design strategies, split into two groups. The data-oriented ones are minimise, hide, separate, and aggregate. The process-oriented ones are inform, control, enforce, and demonstrate. Underneath those sit the privacy-enhancing technologies: pseudonymisation, differential privacy, anonymous credentials, and so on. The two strategies with no STRIDE analog at all are minimise and aggregate, which is the same lesson the telematics pass taught: the most effective privacy move is often to not have the data. (Hoepman later swapped “aggregate” for “abstract” in a revision, so you will see both; the idea is the same.)

Where LINDDUN breaks down

I reach for LINDDUN on anything privacy-sensitive, and it has real limits. Knowing them is the difference between a threat model that helps and one that gives false confidence.

It needs privacy expertise you might not have. STRIDE leans on intuitions most engineers already hold; spoofing and tampering are familiar shapes. LINDDUN’s types assume you can reason about linkability, re-identification, and data-protection principles. The framework is regulation-agnostic in principle, but its vocabulary and threat catalog map most directly onto GDPR-style concepts: data subject, lawful basis, minimisation. Hand it to a team without that background and the output is shallow, because the categories are only as good as the privacy knowledge you bring to them.

It overlaps STRIDE and creates duplicate work. Data Disclosure is STRIDE’s information disclosure wearing a privacy hat, the same root concept, and on a shared DFD you will write the same finding down twice. The honest read: that is one type out of seven, and the non-repudiation collision is a second, productive one. The other five are pure additive value. The redundancy is an annoyance, not a reason to skip the framework. Run both passes and dedupe at the end.

It explodes, same as STRIDE. Seven types across every element or interaction, threat trees that branch into several characteristics each, a catalog of 120-plus examples. PRO and MAESTRO are exhaustive and slow. GO exists precisely to cut the scope to the common hotspots so a team actually finishes instead of drowning in candidates.

It is analyst-dependent. Hand the same system to two people and you get two threat lists, because the result rides on the quality of your DFD and the privacy knowledge of whoever is running it. This is a known, acknowledged limitation, and MAESTRO was built specifically to push the analysis toward reproducibility by enriching the system model. Whether it closes the gap in practice, I cannot say from experience yet.

Non-compliance is a legal moving target, not a technical property. Whether processing is lawful depends on jurisdiction, purpose, consent, and a regulator’s interpretation, none of which a data flow diagram encodes. LINDDUN scopes its Non-compliance type narrowly, which is sensible, but you cannot threat-model your way to a legal opinion, and you should not pretend a clean Non-compliance column means counsel signed off.

The evidence base is thinner than STRIDE’s. STRIDE has independent precision-and-recall studies behind it. LINDDUN’s main empirical evaluation (Wuyts et al., 2014) measured correctness, completeness, productivity, ease of use, and reliability across three studies, and the results were broadly positive, but it is largely the framework’s own authors evaluating their own method. I would treat any confident “X valid threats per hour” claim about LINDDUN as needing a source check against the actual paper.

The takeaway

“Is it secure?” and “does it respect privacy?” are different questions, and a security review only ever answers the first. A system can pass STRIDE clean and still quietly build a pattern-of-life database on everyone who comes near it. LINDDUN is the structured way to ask the second question. The reason to run it alongside STRIDE rather than instead of it is that the two overlap in one place and contradict each other in another, and both of those turned out to be useful on a real system.

The framework will not tell you how much privacy risk you are willing to carry, and it will not collect less data for you. It just makes the risk hard to not see.