STRIDE-LM: When Adding Another Letter Makes the Model Less Coherent

TL;DR

STRIDE-LM is aimed at a real deficiency: STRIDE cannot represent what happens after the first compromise.

But it misreads that deficiency. STRIDE is applied per element and puts its six questions to every internal component, so the vocabulary is not missing. What is missing is any way to join those findings into a sequence — and adding Lateral Movement as a seventh category supplies no sequence, and does not repair STRIDE as a taxonomy.

Lockheed Martin presented the LM addition as following STRIDE’s effect-oriented pattern. Yet lateral movement is not an effect in the same sense as information disclosure, tampering, or service loss. It is a property of a multi-step attack path: the attacker progresses from one controlled context to another.

That progression may be achieved through credential use, abuse of legitimate administrative functions, exploitation of internal services, malware execution, social engineering, or supply-chain trust. Those are different causes with different controls.

“Prevent lateral movement” is a strategic intention. It is not yet a control specification.

TLCTC handles this more precisely:

• the cause is a cluster;
• the order is sequence;
• the movement is topology;
• the destination is context.

The Gap Is Real. The Diagnosis Is Not.

STRIDE remains one of cybersecurity’s most familiar threat-modeling mnemonics:

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

Michael Muckin and Scott C. Fitch of Lockheed Martin later proposed STRIDE-LM, adding Lateral Movement to support a broader threat-driven approach to defensible architectures.

The motivation is understandable.

Modern intrusions rarely stop at the first compromised component. Attackers reuse credentials, access remote services, execute tools, exploit internal systems, and expand control across an environment.

But the deficiency has to be located precisely, because its location determines the cure.

STRIDE is applied per element. Every process, data store, data flow and trust boundary on the diagram receives the full six questions. The fiftieth internal server is not outside its scope. Elevation of Privilege on an internal host is a STRIDE question. Spoofing at an internal boundary is a STRIDE question.

So it is not true that STRIDE has no vocabulary for what happens after the first compromise.

What STRIDE lacks is any way to join those findings together.

It is stateless. It enumerates threats to each element independently and carries nothing from one element to the next — no attacker state, no ordering, no sequence. Every box is analysed as though the attacker had arrived at it fresh.

That is a compositional deficiency, not a missing category. And a compositional deficiency cannot be repaired by adding a category.

No seventh letter supplies a sequencing operator. No eighth letter would either.

The problem is therefore real. The diagnosis behind STRIDE-LM is not — and everything built on it inherits the error.

Lockheed Martin’s Own Rationale

A fair critique must begin with Lockheed Martin’s own position.

Muckin and Fitch did not present Lateral Movement as a new generic exploit mechanism. They described the LM addition as following STRIDE’s pattern of describing the effect of a threat.

That matters because it changes the strongest criticism.

The issue is not simply that LM introduces an effect into a cause-based model. STRIDE was not presented as a purely cause-based taxonomy in the first place.

The stronger internal critique is this:

Lateral Movement is not an effect of the same semantic type as the effects STRIDE already names.

Information Disclosure describes confidentiality loss.

Tampering describes an integrity effect.

Denial of Service describes loss of accessibility or availability.

Elevation of Privilege describes a change in authorization state.

Lateral Movement describes none of those things.

It describes the geometry and progression of an attack path.

So even by the extension’s own effect-oriented rationale, LM does not fit cleanly.

Lateral Movement Is a Path Property

“Lateral movement” tells us that an attacker progressed from one system, identity, security zone, or administrative context to another.

It does not tell us how.

The attacker may progress by:

• using stolen credentials;
• abusing RDP, SSH, WinRM, WMI, PowerShell, or another legitimate administrative function;
• exploiting a vulnerable internal service;
• executing malware on another target;
• manipulating an administrator;
• abusing a trusted management platform;
• or leveraging a compromised supplier relationship.

These mechanisms exploit different generic vulnerabilities.

They require different controls.

They create different evidence.

They are not one threat.

A useful top-level category should answer:

Which distinct generic vulnerability does the attacker exploit?

For #4 Identity Theft, the answer is:

Insufficient binding, at the point of authentication, between a presented credential and the authentic holder.

For #6 Flooding Attack, the answer is finite capacity.

For #9 Social Engineering, the answer is human psychology.

What is the one generic vulnerability for Lateral Movement?

There is no single answer.

That is because lateral movement is not an atomic threat step. It is a relationship among steps.

The TLCTC View

TLCTC classifies each atomic attacker action according to the generic vulnerability that initially makes that action possible.

Those atomic steps are then chained into an attack path.

This produces a simple separation:

• clusters classify causes;
• arrows express sequence;
• boundary annotations express responsibility-sphere transitions;
• intra-system annotations express defined boundaries inside one host;
• Data Risk Events record consequences to confidentiality, integrity, accessibility, or availability.

Lateral progression therefore appears through the sequence of actual causal steps.

It does not need to become another cluster.

For example:

#4 → #1

This may describe an attacker using a stolen identity artifact and then abusing legitimate remote-administration functionality.

Or:

#2 → #7

This may describe exploitation of an internal server-role service followed by execution of Foreign Executable Content.

Both can be described operationally as lateral movement.

But the causes are different.

Example 1: Credential Use and Administrative Function Abuse

Suppose an attacker manipulates an employee into disclosing credentials, later presents those credentials at authentication, and then uses legitimate remote-administration functionality.

A cause-oriented path is:

#9 ‖[human][@External→@Org]‖ + [DRE: C] → #4 → #1

Step 1 — Social Engineering

The attacker exploits human psychology:

#9

Because the victim successfully disclosed credentials, the step also produced a confidentiality event:

+ [DRE: C]

The DRE does not replace the cause. It records the data consequence of the successful manipulation.

Step 2 — Credential Use

The attacker presents the credential at authentication:

#4

Under R-CRED, acquisition maps to the enabling cluster. Use is always #4.

Step 3 — Abuse of Legitimate Functionality

The attacker uses a legitimate administrative capability without needing to exploit a code flaw:

#1

The phrase “lateral movement” describes the overall progression.

It does not identify the three distinct control points:

• resistance to human manipulation;
• authentication and identity-artifact binding;
• governance of administrative functionality.

Example 2: Internal Service Exploitation

Suppose an attacker already controls one system and then exploits a vulnerable service on another internal server.

The path is:

#2 → #7

Step 1 — Exploiting Server

The target service processes an attacker-controlled request and a server-side implementation flaw is triggered:

#2

Step 2 — Malware

The exploit enables Foreign Executable Content to execute:

#7

Under R-EXEC, the execution step must be recorded whenever FEC executes.

This may also be called lateral movement.

But the relevant preventive controls differ sharply from the credential-based path:

• patching;
• memory-safe implementation;
• input validation;
• service hardening;
• segmentation;
• exploit detection;
• execution prevention.

“Lateral Movement” alone does not tell the organization which mechanism it must prevent.

Example 3: Malware Propagation

Malware may spread across reachable systems in different ways.

One path may be:

#2 → #7 → #2 → #7

Each exploitation of a new server-role component is another #2 step.

Each new execution of Foreign Executable Content is another #7 step.

Another propagation path may be:

#4 → #1 → #7

Here the attacker:

1. applies an identity artifact;
2. abuses a legitimate remote-administration function;
3. executes foreign code on the destination.

Both paths may look like malware moving laterally.

They are not causally equivalent.

One depends on software defects.

The other depends on identity use, trusted functionality, and designed code-execution capability.

The cause determines the control.

The phrase “lateral movement” does not.

Position Does Not Change Classification

Axiom VI governs each atomic step:

A credential applied against the first target is #4.

The same type of credential application against the fiftieth target is also #4.

A server vulnerability exploited from the internet is #2.

The same kind of server vulnerability exploited from an already compromised internal system remains #2.

Its position in the attack path does not change the generic vulnerability being exploited.

Axiom VII separately governs how the attack vector is defined by the initial generic vulnerability.

This distinction matters:

• Axiom VI keeps step classification stable throughout the path.
• Axiom VII determines the initiating vector label.

“Initial Access,” “Lateral Movement,” “Persistence,” and “Privilege Escalation” describe where an action sits in an intrusion or what state transition followed.

They do not redefine the cause of the atomic action.

Topology Is Already a Separate Layer

TLCTC v2.3 provides:

• ‖[context][@Source→@Target]‖ for crossings where responsibility spheres or control regimes change;
• |[type][@from→@to]| for defined boundaries inside one system — sandbox, privilege, process, hypervisor;
• sequence through →;
• velocity through →[Δt=...];
• Data Risk Events through + [DRE: X].

Under R-INTRA-7, a boundary crossing is an observability annotation. It never changes cluster classification.

That is the structural fact that settles the question.

Topology in TLCTC is not part of the taxonomy. It is a separate layer of annotation laid over a classification that is already complete without it.

So a lateral-movement annotation would never answer “which cluster?” It could only answer “how much forensic detail does this record carry?”

The Vertical Axis Is Already Annotated

|[privilege][@user→@root]|, |[sandbox][@renderer→@os]| and |[hypervisor][@guest→@host]| are all vertical crossings: up a privilege gradient, or out of a containment layer.

Each is defined by an enforcement mechanism. A ring, a sandbox, a hypervisor.

Something is doing the containing, and the crossing consists of defeating it. That is what makes the annotation meaningful: it marks a mechanism that was overcome.

“Lateral” has no equivalent.

Movement between two peer systems is not defined by a mechanism. Very often it is defined by the absence of one.

Either a Boundary Was Enforced, or Nothing Was Crossed

If a firewall, network segment, security group, or policy engine sits between the two systems, the control regime changes at that point — and by the definition of a domain boundary, ‖...‖ already applies. The operator is not reserved for @External→@Org.

If nothing sits between them, there is no boundary to annotate. The correct record is two steps in the same sphere, with no crossing marked.

The flatness is the finding.

An operator that marked a crossing where no boundary existed would record a fiction. Worse, it would make a segmented environment and a flat one produce identical registers — erasing the single most decision-relevant difference between them.

“Host” Is Not a Framework Primitive

Notice what the intra-system operator does not do: it never defines a host.

It defines boundary types — sandbox, privilege, process, hypervisor — and each one names a mechanism.

That is deliberate, and it is what makes the notation survive.

A host was a machine, then a virtual machine, then a container, then a pod, then a function invocation that outlives no request. Each generation redraws the box. None of them changes whether a privilege ring or a hypervisor is enforcing separation.

Anchor the notation to the packaging and it expires with the deployment model. Anchor it to the mechanism and it does not.

In @guest→@host the word names a role in a mechanism pair, not a unit of infrastructure. That is a different use, and it carries no commitment.

A framework that classifies by enforced mechanism everywhere else has no business adopting a convention-dependent unit here. That is the objection this article raises against STRIDE-LM, and it applies with equal force in the other direction.

What the Intuition Is Actually Asking For

Consider the cloud case. An attacker calls AssumeRole. No host changes. No packet crosses a segment. The attacker’s API calls are simply authenticated as a different principal from one moment to the next.

Every incident report would call that lateral movement.

It is #4, fully classified, and “movement” is a metaphor with no referent.

The forensic need underneath “it moved from A to B” is narrower than a topology operator. It is per-step asset attribution: which asset the step occurred on, so that blast radius can be counted.

That is a label on a step, not a direction between steps. It requires no new geometry, no new operator, and no eleventh cluster.

The causal sequence was already correct:

#4 → #1

or:

#2 → #7

Why STRIDE-LM Still Fails as a Taxonomy

A coherent taxonomy needs a rule for what may enter the top level.

Ask five questions:

1. Does the category identify one distinct generic vulnerability?
2. Can one atomic attacker action map to it?
3. Is it semantically the same type of thing as the other categories?
4. Does adding it preserve mutual exclusivity?
5. Is there a principled reason to include it while excluding similar concepts?

Lateral Movement fails these tests.

It has no single generic vulnerability.

It decomposes into several different attacker actions.

It is a path property rather than an atomic step.

It overlaps with credential use, exploitation, malware, function abuse, social engineering, and other causes.

And its inclusion provides no stopping rule.

Why add Lateral Movement but not:

• Initial Access?
• Persistence?
• Discovery?
• Command and Control?
• Credential Access?
• Exfiltration?
• Defense Evasion?

All are operationally important.

Importance alone does not establish taxonomic identity.

But there is a reason that list reads so naturally.

Every item on it is a MITRE ATT&CK tactic. So is Lateral Movement.

LM’s peers are not the six STRIDE letters. They are the other thirteen tactics it was standing next to.

STRIDE’s six are negated security properties. ATT&CK’s tactics are adversary objectives. Different column headers, built to answer different questions, and neither is a subset of the other.

STRIDE-LM is therefore not an extension of STRIDE. It is one item lifted out of one model and spliced into another with an incompatible organising principle.

And once a single tactic is admitted, there is no principled ground left on which to refuse the remaining thirteen.

A six-letter mnemonic that has absorbed fourteen tactics is simply ATT&CK — arrived at by accident, and without its structure.

“Prevent Lateral Movement” Is Not Yet a Control Specification

Security teams often state that they must “prevent lateral movement.”

That is a valid strategic objective.

It is not yet a control specification.

The specification begins only after the next causal step is identified.

Are we trying to prevent:

• #4 — application of stolen identity artifacts?
• #1 — abuse of legitimate administrative functions?
• #2 — exploitation of internal server-role software?
• #3 — exploitation of internal client-role software?
• #7 — execution of Foreign Executable Content?
• #9 — manipulation of additional employees or administrators?
• #10 — abuse of trusted third-party access or artifacts?

Each requires a different control strategy.

#6 Flooding Attack is notably absent from the normal lateral-movement set.

Exhausting finite capacity may disrupt a target, but it does not establish control of a new identity, host, or execution context. If a crafted input compromises the next host by triggering a defect, the step is #2 or #3 under R-FLOOD and R-ROLE—not #6.

This is why cause-first classification matters.

A broad objective such as “contain lateral movement” can guide architecture.

It cannot replace the identification of the mechanism the attacker will use next.

STRIDE-LM Can Still Be a Checklist

None of this means STRIDE-LM is useless.

A team can ask:

• Could an identity be impersonated?
• Could information be modified?
• Could actions become difficult to attribute?
• Could confidential data be exposed?
• Could services become inaccessible or unavailable?
• Could privileges increase?
• Could an attacker progress beyond the first compromised component?

The first six prompts do real work. Each names a property whose negation a team can test against a specific element.

The seventh does not behave like the others.

“Could an attacker progress beyond the first compromised component?” is answerable with the phrase already contained in the question. A team says “yes — lateral movement,” records it, and moves on, having named the phenomenon instead of the mechanism.

This is the characteristic behaviour of a residual category. Because it is defined by what it is not — not entry, not escalation — it carries no test of its own, and it collects whatever the other six failed to catch.

A well-run workshop pushes past it. Most workshops are not well run, and the item is most attractive exactly where the analysis is weakest.

So LM does not merely sit awkwardly among the six. It offers teams somewhere to file the hard question instead of answering it.

A checklist and a taxonomy are not the same thing.

A checklist can tolerate a mixed semantic type, because its purpose is to stimulate discussion rather than to classify. What it cannot tolerate is an item that terminates the discussion.

A taxonomy must support:

• reproducible classification;
• attack-path construction;
• control mapping;
• incident comparison;
• threat-intelligence aggregation;
• governance;
• and machine-readable analysis.

STRIDE-LM is a broader checklist.

It is not a coherent cause-based threat taxonomy.

A 1999 Model Doing 2026 Work

STRIDE was developed inside Microsoft in 1999. Its shape reflects the assumptions of that moment: an application whose elements could be enumerated, a diagram that held still long enough to analyse, and a threat model expressible as the negation of six security properties.

Each of those assumptions has weakened.

Elements are no longer stably enumerable. Autoscaled compute, ephemeral containers, function invocations and third-party APIs mean the diagram is a snapshot of an arrangement that has already changed.

The property list was never closed over causes. There is no STRIDE letter whose negation is “a trusted supplier shipped compromised code.” There is none for human manipulation, and none for physical access. Some of the largest incidents of the last decade have no home in the mnemonic — which is the same pressure that produced LM, applied at a different point on the same model.

And the output joins to nothing. A STRIDE finding cannot be compared with an incident record, a threat-intelligence report, or a control failure, because nothing downstream speaks in negated properties.

None of this makes STRIDE worthless. As a design-time prompt for developers — its original purpose — it still earns its place, and it can be taught in an afternoon, which is not a small virtue.

The difficulty is that the industry uses it far outside that remit: in risk registers, in regulatory evidence, in threat-intelligence mapping, in tooling that treats six letters as a classification scheme.

A mnemonic asked to carry that weight will keep acquiring letters, because every question it cannot answer looks like a missing category.

STRIDE-LM is one visible result of that pressure. It will not be the last.

Conclusion: LM Is the Evidence, Not the Fix

STRIDE-LM begins from a real deficiency:

STRIDE does not represent attacker progression across interconnected environments.

But it misreads that deficiency as a missing category when it is a missing sequencing primitive—and so its solution, adding Lateral Movement as another letter, confuses attack-path structure with atomic classification.

Lateral movement is not one cause.

It is not one security effect.

It is what a path looks like when an attacker expands control from one context to another.

That progression may involve:

• #1 Abuse of Functions;
• #2 Exploiting Server;
• #3 Exploiting Client;
• #4 Identity Theft;
• #5 Man in the Middle;
• #7 Malware;
• #8 Physical Attack;
• #9 Social Engineering;
• #10 Supply Chain Attack;
• or combinations of them.

#6 Flooding Attack normally disrupts rather than establishes the new control required for lateral progression.

The specific cause determines the preventive control.

The movement describes where the path goes next.

Those are different analytical dimensions.

STRIDE-LM does not solve STRIDE’s structural weakness.

It demonstrates it.

The missing capability was never another letter.

It was a grammar capable of separating cause, sequence, topology, event, and consequence.

TLCTC provides that grammar today: causes classified by cluster, topology annotated separately, and every boundary anchored to a mechanism that enforces something—not to whatever the current generation happens to call a host.

When every blind spot is repaired by adding another letter, the framework is building a glossary—not a taxonomy.

References

• Muckin, Michael, and Scott C. Fitch. A Threat-Driven Approach to Cyber Security. Lockheed Martin.
• Kreinz, Bernhard. A Cause-Oriented Cyber Threat Taxonomy: The Top Level Cyber Threat Clusters Framework, v2.3.1, 1 July 2026. DOI: 10.5281/zenodo.21361169.
• Kreinz, Bernhard. Applying the Top Level Cyber Threat Clusters: Classification, Governance, and Cross-Domain Application, v2.3, 19 June 2026.
• Kreinz, Bernhard. TLCTC Framework Glossary, Version 2.0/2.1.