STRIDE Threat Modeling Under NIS2: Six Categories, and What Article 21(2)(a) Still Requires

STRIDE answers one of the ten things NIS2 Article 21(2)(a) asks for, and part of a second. It is not a risk analysis, and Microsoft has never claimed it was one — the Security Development Lifecycle describes threat modelling as “an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application” [5]. Nowhere does Microsoft call it a risk management framework.

The European regulator has reached the same conclusion, in a document most engineering teams never open. We extracted and searched the full text of ENISA’s 170-page Technical Implementation Guidance on cybersecurity risk-management measures: STRIDE appears exactly once. That single mention sits on page 82, inside the section on the secure development life cycle — which elaborates Article 21(2)(e) — and not in section 2.1, the section that elaborates Article 21(2)(a) [3].

That is a filing instruction, not a verdict. What follows sets STRIDE against the obligation’s actual wording, step by step, and names the artefacts a supervisory authority will ask for that a threat model does not produce.

Does this apply to you, and in which form?

In plain terms: Article 21(2)(a) binds every essential and important entity in the EU. The detailed ten-step version of it binds eleven types of digital-infrastructure entity outright, and describes the Commission’s own reading of the article for everyone else.

Your situation	What binds you	What STRIDE is being measured against here
Any essential or important entity under NIS2	Article 21(2)(a) as transposed into your national law [2]	“Policies on risk analysis and information system security” — nine words, elaborated by your national regulator
DNS providers, TLD registries, cloud, data centre and CDN providers, MSPs, MSSPs, online marketplaces, online search engines, social networking platforms, trust service providers	Commission Implementing Regulation (EU) 2024/2690, Annex point 2.1, directly [1]	The full ten-step cybersecurity risk management process, with named evidence
Every other sector (energy, health, transport, water, manufacturing, public administration)	Article 21(2)(a); Annex point 2.1 is not binding on you	The same ten steps, as the best available statement of what the Commission thinks the article means
You build or maintain software or systems	Article 21(2)(e), acquisition, development and maintenance [2]	This is where STRIDE genuinely earns compliance credit — see below

In the third row, treat Annex point 2.1 as a benchmark rather than a rule: it is the most detailed articulation of Article 21(2)(a) the Commission has published, and supervisors have nothing more specific to reach for. Our guide to Article 21(2)(a) risk management requirements works through that split.

What Article 21(2)(a) actually requires

In plain terms: the directive gives you nine words. The Implementing Regulation turns those nine words into a documented framework, a ten-step process, a risk treatment plan, and a signature from your management body.

Article 21(2)(a) requires “policies on risk analysis and information system security” [2]. That is the entire operative text. The detail lives in the Annex to Implementing Regulation (EU) 2024/2690, whose Section 2 is headed, in the regulation’s own words, “Risk management policy (Article 21(2), point (a) of Directive (EU) 2022/2555)” — the regulation itself tells you this is the elaboration of that article [1].

Point 2.1.1 sets the frame:

“The relevant entities shall establish and maintain an appropriate risk management framework to identify and address the risks posed to the security of network and information systems. The relevant entities shall perform and document risk assessments and, based on the results, establish, implement and monitor a risk treatment plan. Risk assessment results and residual risks shall be accepted by management bodies…” [1]

Point 2.1.2 then breaks the process into ten lettered steps: (a) follow a risk management methodology; (b) establish a risk tolerance level in line with risk appetite; (c) establish and maintain risk criteria; (d) identify and document risks on an all-hazards basis, including single points of failure; (e) analyse the risks “including threat, likelihood, impact, and risk level”; (f) evaluate risks against the criteria; (g) identify and prioritise treatment options; (h) continuously monitor implementation; (i) name who is responsible and by when; (j) document the treatment measures and “the reasons justifying the acceptance of residual risks in a comprehensible manner” [1].

ENISA’s guidance then states what evidence satisfies point 2.1.1. The list is short and complete: a documented risk management framework; documented results from previous risk assessments; a documented risk treatment plan; a record of management-body approval of the risk assessment results; and a record of management-body approval of the residual risks [3]. A threat model is not on that list. Neither is a data flow diagram. Our walkthrough of the risk register structure behind Article 21(2)(a) shows how those five artefacts fit together.

The six STRIDE categories and the properties they defend

In plain terms: STRIDE is a prompt list. Its job is to stop you forgetting a class of attack, not to tell you how bad any of them would be.

Microsoft’s own framing is modest: “You can group threats into categories to help you formulate these kinds of pointed questions. One model you may find useful is STRIDE” [4]. Each category maps to a security property an attacker breaks — and that mapping is where STRIDE and the Implementing Regulation touch.

Category	What it covers [4]	Property broken	Named in CIR Annex 2.1.2(d) / 12.1.2(b)? [1]
Spoofing identity	Using another user’s authentication information	Authenticity	Yes
Tampering with data	Malicious modification of stored or in-transit data	Integrity	Yes
Repudiation	A user denies an action with no way to prove otherwise	Non-repudiation	No
Information disclosure	Exposure of information to people without access	Confidentiality	Yes
Denial of service	Denying service to valid users	Availability	Yes
Elevation of privilege	An unprivileged user gains privileged access	Authorisation	No

The regulation names four properties — availability, integrity, authenticity and confidentiality — both in the risk-identification step and again in the asset-classification requirement [1]. STRIDE covers all four and adds two the regulation’s lists do not name: non-repudiation and authorisation. So on coverage of threat types, STRIDE is not merely adequate; it is broader than the regulation’s own vocabulary.

The mechanism matters here. STRIDE works by walking a data flow diagram and asking six questions at every process, store, flow and trust boundary. That produces candidate threats with good coverage — and nothing else. There is no step in STRIDE that assigns a likelihood, an impact, or a risk level, which is precisely why teams historically bolted DREAD, CVSS or a 5×5 matrix onto it.

STRIDE against the ten steps of the risk-management process

In plain terms: STRIDE contributes to two of the ten lettered steps and is silent on the other eight. That is a scoping statement, not a criticism.

CIR Annex 2.1.2 step [1]	What STRIDE contributes	Verdict
(a) Follow a risk management methodology	Nothing. Microsoft classifies threat modelling as an engineering technique, not a risk framework [5]; ENISA’s worked example of a methodology is ISO/IEC 27005:2022 [3], and none of the 29 frameworks catalogued in ENISA’s compendium of risk-management methodologies is STRIDE [6]	Silent
(b) Establish risk tolerance in line with risk appetite	Nothing — STRIDE has no concept of how much risk the organisation will accept	Silent
(c) Establish and maintain risk criteria	Nothing	Silent
(d) Identify and document risks, all-hazards, incl. single points of failure	Strong on adversarial threats; the data flow diagram surfaces single points of failure well. Silent on the natural and accidental hazards ENISA explicitly requires — flood, fire, power loss, human error [3]	Partial
(e) Analyse threat, likelihood, impact and risk level	Supplies the threat. Supplies none of the other three	Partial
(f) Evaluate identified risks against the risk criteria	Nothing — there is no criterion to evaluate against	Silent
(g) Identify and prioritise treatment options	Lists candidate mitigations, but not prioritised against cost, asset classification and business impact analysis as point 2.1.3 requires [1]	Silent
(h) Continuously monitor implementation of treatment measures	Nothing	Silent
(i) Identify who is responsible and when measures are due	Nothing	Silent
(j) Document treatment in a plan and justify residual-risk acceptance	Nothing — and this is the step supervisors ask about first	Silent

Two partials out of ten is a fair result for a tool designed to answer one question — “what can go wrong at this trust boundary?” — during system design. The failure mode is not using STRIDE; it is presenting a STRIDE output as the risk analysis and discovering at audit that eight steps have no evidence behind them.

Row (d) deserves a note. ENISA instructs assessors to check that the risk-assessment approach “addresses a wide range of potential threats and risks, not just the cyber ones, but natural or man-made, accidental or intentional” [3]. STRIDE is adversarial by construction — all six categories presume an attacker — so a threat model that is complete on its own terms still has nothing to say about a flooded data centre.

Where the regulator actually files STRIDE: Article 21(2)(e)

In plain terms: ENISA does name STRIDE — as an example of evidence for secure development, under a different article entirely.

On page 82 of the Technical Implementation Guidance, in section 6.2 on the secure development life cycle, the guidance advises: “Consider threat modelling as part of the security requirements analysis.” The accompanying evidence list reads: “Evidence of the use of threat modelling (indicative, non-exhaustive list): documentation of the process used for example STRIDE or DREAD, data flow diagrams, and meeting minutes” [3].

Read the modal verbs carefully before you build a compliance argument on this. ENISA says “consider”, and labels the list “indicative, non-exhaustive”. This is guidance, not a binding requirement to run STRIDE; the binding provision is Article 21(2)(e), which requires security in “acquisition, development and maintenance, including vulnerability handling and disclosure” [2]. Nothing in NIS2 or the Implementing Regulation obliges any entity to use STRIDE specifically, and nothing in either text says STRIDE satisfies anything.

What the passage does establish is that your existing STRIDE artefacts have a defined home in an audit file. Data flow diagrams, the documented modelling process and the meeting minutes are named evidence for secure development obligations, and they sit naturally alongside your vulnerability handling process under CIR Annex 6, which covers the disclosure half of the same article. File them there. Reference them from the risk register — do not substitute them for it.

Closing the gap: what to build next to the threat model

In plain terms: keep STRIDE, add a rating layer, and route every finding into the register as a risk statement with an owner.

CISO or security architect: your gap is step (e). A STRIDE finding is usable to the compliance side only once it carries a likelihood, an impact and a risk level. Attach whatever scoring scheme your organisation already uses — a qualitative 5×5 matrix is enough, and easier to defend than a borrowed formula nobody can explain. Then tie each finding to a classified asset, because point 2.1.3 requires treatment prioritisation to account for asset classification and the business impact analysis [1].

Compliance officer: your gap is documentary. An auditor asks for five artefacts by name — framework, assessment results, treatment plan, record of management approval, record of residual-risk acceptance [3] — and a threat model is none of them. The task is not getting STRIDE accepted as a substitute; it is making sure it feeds the register that produces those five.

You already have	What is missing	Effort	Required by
STRIDE model per system, with data flow diagrams	Likelihood, impact and risk-level rating per finding	Low	2.1.2(e)
A list of candidate mitigations	Risk criteria and a tolerance level to judge them against	Medium	2.1.2(b), (c), (f)
Engineering ownership of fixes	Named owners and due dates in a documented treatment plan	Medium	2.1.2(g), (i), (j)
Adversarial threat coverage	Natural, accidental and man-made non-cyber hazards	Medium	2.1.2(d), all-hazards
Engineering sign-off on the model	Management-body acceptance of residual risk, on record	High	2.1.1
A model built at design time	Review at planned intervals, at least annually and after significant incidents	Low	2.1.4

Concretely, one STRIDE finding becomes one register row. “Tampering — an unauthenticated internal service can write to the billing queue” fills the threat field and, with the diagram, the affected-asset field. It leaves blank the likelihood, impact, risk level, treatment option, owner, due date and residual-risk decision. Seven blank fields per row is the real size of the gap, and a methodology fills them, not more threat modelling. ENISA’s worked example is ISO/IEC 27005:2022 [3]; our comparison of NIS2 against ISO 27005 covers what adopting it involves.

Frequently asked questions

Can we name STRIDE as our risk management methodology under step (a)? It is a weak position. Microsoft frames threat modelling as an engineering technique rather than a risk framework [5], and the compendium ENISA’s guidance points to catalogues 29 risk-management frameworks and methodologies — ISO/IEC 27005, the NIST SP 800 series, OCTAVE, EBIOS, MEHARI, MONARC and others — none of which is STRIDE [6]. Name a methodology that covers criteria, evaluation and treatment, and cite STRIDE within it as your threat-identification technique. The same question applied to the seven-stage alternative is covered in our guide to PASTA threat modelling and Article 21(2)(a).

Does NIS2 require threat modelling at all? No provision of the Directive or the Implementing Regulation requires it by name. ENISA suggests you “consider” it under secure development and lists it as example evidence [3]. Treat it as a strongly recommended practice, not an obligation.

Is DREAD acceptable as the scoring layer? ENISA names DREAD alongside STRIDE in the same evidence list [3], so citing it is defensible. The regulation does not prescribe a scoring scheme — point 2.1.2(e) requires that likelihood, impact and risk level be analysed, not how. Use whatever your organisation can apply consistently and explain to an auditor.

Does STRIDE handle the all-hazards requirement? No. All six categories assume a deliberate attacker, and ENISA’s assessment guidance expressly looks for natural and accidental hazards too [3]. That gap has to be closed elsewhere in the assessment.

What to do next

STRIDE is a genuine asset filed in the wrong cabinet. It gives you better threat-type coverage than the regulation’s own vocabulary, and it gives you almost nothing on the governance half of Article 21(2)(a) — the half that produces the documents a supervisor reads first.

Three moves close the distance. Re-file your existing STRIDE artefacts as Article 21(2)(e) secure-development evidence, where ENISA has already said they belong. Add a likelihood-and-impact rating to every finding so step (e) has something behind it. Then route each rated finding into the risk register as a row with an owner, a due date and a residual-risk decision that your management body has signed.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, Annex points 2.1.1–2.1.4, 6.2 and 12.1.2 — EUR-Lex, official English text (linked above).
2. Directive (EU) 2022/2555 (NIS2), Article 21, cybersecurity risk-management measures — points (a) and (e) of paragraph 2 (linked above).
3. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 — section 2.1 (pp. 21–26) and section 6.2 (p. 82). The count of STRIDE mentions reported in this article was obtained by extracting and searching the full 170-page text (linked above).
4. Microsoft, The STRIDE Threat Model — Microsoft Learn archive; definitions of the six categories (linked above).
5. Microsoft, Threat Modeling — Security Development Lifecycle (linked above).
6. ENISA, Compendium of Risk Management Frameworks with Potential Interoperability, January 2022 — 29 frameworks catalogued in section 3; STRIDE is not among them (linked above).