STRIDE catches security threats well. It does not catch privacy threats. A system can satisfy every STRIDE category — nothing spoofed, nothing tampered with, nothing leaked to the wrong party — and still violate a person's privacy by linking their behaviors, identifying them across contexts, or failing to inform them their data is being collected.
LINDDUN was developed at KU Leuven (Wuyts, Joosen, Scandariato et al.) starting in 2010 as the privacy-focused counterpart to STRIDE. It has become the standard methodology for privacy-by-design analysis, and the natural pairing when GDPR, CCPA, HIPAA, or any privacy regulation is in scope.
The seven categories
Two or more items of interest (transactions, accounts, sessions) can be linked together as belonging to the same person, even if neither item identifies the person directly.
An item of interest can be tied to a specific real-world person. Pseudonymous data that, combined with other public data, identifies the individual.
The user cannot deny having performed an action, in contexts where deniability is the privacy property they wanted. Same letter as STRIDE's R, but flipped — in security we want non-repudiation; in privacy we sometimes don't.
An attacker can detect that an item of interest exists, even without reading its contents. Knowing someone has a record is itself revealing.
Personal data is exposed to a party that shouldn't see it. The privacy version of STRIDE's I (Information disclosure), but scoped to personal data and consent.
The user is unaware of what's being collected, how it's used, who it's shared with, or that they can change any of it. The transparency failure mode.
The processing violates applicable privacy law or policy. GDPR Article 6 lawful basis missing; CCPA opt-out request not honored; HIPAA minimum-necessary not enforced.
How LINDDUN is used
Like STRIDE, LINDDUN is applied to a DFD — but with explicit personal-data tags on the elements. For each element handling personal data, you walk the seven categories and ask: can this happen here? if so, what's the impact and what's the privacy control?
The official methodology now has three flavors (LINDDUN MAESTRO since 2024):
- LINDDUN GO — lightweight, card-deck-driven, suitable for a 90-minute team workshop.
- LINDDUN PRO — full methodology with detailed threat trees per category. Slow but thorough.
- LINDDUN MAESTRO — the 2024 unified version, scales between the two.
LINDDUN vs STRIDE
The same elements, two different lenses
| Aspect | STRIDE | LINDDUN |
|---|---|---|
| Concerns | Security (CIA + authentication, authorization, non-repudiation) | Privacy (data minimization, consent, transparency, regulation) |
| Trigger | An attacker tries to break the system | The system itself violates user expectations |
| Subject of harm | The system or its owner | The data subject (the person) |
| Mitigations look like | Auth, encryption, validation, audit logs | Data minimization, anonymization, opt-out, deletion, notices |
| Used together? | Yes. Many systems run both passes against the same DFD — one for security, one for privacy. | |
When LINDDUN fires
- The system handles personal data at meaningful scale — user accounts, location, biometrics, health, financial, behavioral.
- Privacy regulation applies — GDPR, CCPA/CPRA, HIPAA, FERPA, PIPEDA, LGPD, state and sector-specific laws.
- Privacy-by-design is a stated requirement — new product design, regulatory submission, contractual obligation.
- You're a data processor under contract — you don't own the data; your client does, and they need assurances.
LINDDUN exists because security and privacy are different problems. A perfectly secure system can be deeply privacy-violating; a privacy-respecting system can have security holes. Each lens catches what the other misses.
If your system handles personal data and you only run STRIDE, you'll ship features that satisfy your security review and surprise your data protection officer. Add a LINDDUN pass on the same DFD and that gap closes — with the additional benefit of producing the kind of analysis a regulator wants to see.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Deng, M., Wuyts, K., Scandariato, R., Preneel, B., & Joosen, W. (2011). A privacy threat analysis framework: Supporting the elicitation and fulfillment of privacy requirements. Requirements Engineering, 16(1), 3–32. https://doi.org/10.1007/s00766-010-0115-7
- European Parliament & Council. (2016). Regulation (EU) 2016/679: General Data Protection Regulation. https://eur-lex.europa.eu/eli/reg/2016/679/oj
- LINDDUN Project. (n.d.). LINDDUN privacy threat modeling. KU Leuven DistriNet. https://linddun.org/
- Wuyts, K., Sion, L., & Joosen, W. (2020). LINDDUN GO: A lightweight approach to privacy threat modeling. 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), 302–309. https://doi.org/10.1109/EuroSPW51379.2020.00047