Many security teams are in the same position right now. The perimeter stack is mature, MFA is in place for remote access, endpoint tooling is deployed, and yet one uncomfortable question remains: if an attacker lands on a single laptop, contractor workstation, or maintenance jump host, what stops them from moving deeper?
That question matters because most damaging incidents don't stay confined to the first compromised system. They spread through trust. In corporate IT, that often means a quiet path from the user endpoint to the file server to the identity infrastructure. In OT, it can mean a compromised vendor session, an engineering workstation, and then operational systems that were assumed to be insulated by network separation alone.
What is lateral movement? It's the set of actions an attacker takes after initial access to extend control across internal systems. For CISOs and security leaders, that makes lateral movement less of a malware topic and more of an architecture topic. The primary issue isn't just intrusion. It's whether your environment makes internal expansion easy.
A phishing click hits a user's laptop in corporate IT. A remote vendor session lands on an engineering workstation in OT. In both cases, the first system is only the starting point. The greater risk arises when that access is used to access identity systems, administrative paths, and operations that the attacker was never supposed to touch.
Lateral movement occurs after initial compromise, when an attacker expands from one system to others within the environment. They use discovery, stolen credentials, existing trust relationships, and legitimate remote access methods to move toward better targets. The objective is rarely the first host. It is the next credential, the next segment, or the next privileged path.
Rapid7's explanation of lateral movement describes it as an abuse of trust inside the network. That is the part many organizations still underestimate. The issue is not only that an attacker got in. The issue is that internal access is often easier to extend than leaders expect.
This matters differently in IT and OT. In IT, lateral movement often aims at identity infrastructure, file stores, databases, and cloud-connected admin systems. In OT, the path is usually narrower, but the consequences are harsher. An attacker may move through a jump server, historian, remote support channel, or engineering workstation to reach systems that affect plant availability, safety, or recovery time. Flat trust is dangerous in both places, but OT also carries uptime constraints that make blunt containment measures harder to apply.
Three conditions usually make lateral movement easier than it should be:
Practical rule: Treat identity and access paths as the primary lateral movement surface, not just the network.
Leadership teams should care because this is how a contained incident becomes a multi-system event. Attackers routinely blend into normal administration patterns once they have a foothold. They use valid accounts, approved tools, and expected protocols. That is why network-only defenses, by themselves, are no longer enough.
The stronger answer is identity-centric control. Role-based Privileged Remote Access controls, just-in-time access, session governance, and strong verification around administrative actions limit how far a compromised account can travel. In practice, that gives defenders something old perimeter models never did: a way to reduce trust after a compromise across both IT and OT without breaking every operational workflow.
A lateral movement attack rarely looks dramatic at the start. A user workstation is compromised, a remote support path is abused, or a service account is exposed. A significant risk emerges in the next hour when that initial access is redirected elsewhere.
What follows is usually disciplined rather than chaotic. Attackers work through a sequence: learn the environment, identify usable privileges, then use trusted channels to reach systems that matter. In IT, the path often runs toward domain services, cloud administration, data stores, and management platforms. In OT, the same pattern holds, but the objectives and constraints differ. Engineering workstations, historian servers, remote-access jump points, and interfaces between IT and OT become higher-value stepping stones, and noisy containment can have operational consequences.
After the first foothold, the attacker needs context. They identify nearby systems, administrative paths, and trust relationships. The goal is to answer practical questions fast: Which host is this? Who uses it? What can it reach? Which accounts have standing access from here?
Common discovery activities include:
Good operators do not move at random. They move where trust already exists.
The next phase is about getting an identity that travels. That may be a cached password, a token, a Kerberos ticket, a local administrator credential reused across systems, or access tied to a service account. In mature attacks, the attacker often prefers valid credentials to custom malware because approved tools and identities create less friction and noise.
As noted earlier, CrowdStrike describes the attack flow in three broad stages: reconnaissance, credential or privilege gathering, and access to other computers. That framing holds up in the field, but the defensive implication matters more than the sequence itself. If identity artifacts are easy to harvest and privileged access is always standing, the environment gives the attacker a built-in transit system.
This is also where IT and OT start to diverge. In enterprise IT, privilege gathering often leads toward centralized identity and broad administrative control. In OT, the attacker may need fewer hops because a shared admin account, a vendor remote access path, or a poorly governed jump server can expose systems that affect physical operations. The blast radius can be smaller in host count and higher in business impact.
Once the attacker has a usable account or higher privileges, movement usually occurs through normal administrative paths. Remote management services, scripts, support tools, and trusted host-to-host connections do the work. From a defender's perspective, that is the hard part. The traffic may look legitimate unless identity, session context, and asset criticality are evaluated together.
A practical model looks like this:
The strategic lesson is straightforward. Network segmentation still matters, but it does not solve the problem by itself. Attackers increasingly move through identity, not just through open ports. That is why identity-centric Privileged Remote Access governance is becoming more important than broad network trust alone. The stronger control point is privileged access itself: remove standing admin rights, require just-in-time approval, isolate high-risk sessions, and apply role-based privileged access management so a compromised account cannot cross from one trust zone to another. That matters in both IT and OT, where the same lateral movement pattern exists, but the operational cost of getting containment wrong differs significantly.
Most organizations still imagine lateral movement as malware hopping from machine to machine. That does happen, but it's no longer the most useful mental model. A lot of real movement happens through approved remote services, valid accounts, and built-in administration features.
The blind spot is operational familiarity. If your admins already use RDP, SSH, PowerShell remoting, Windows management tools, and service accounts, an attacker can hide inside those same patterns.
According to Picus on lateral movement attacks, attackers increasingly use legitimate identity paths and built-in tools to pivot. Picus also notes that MITRE ATT&CK documents multiple lateral movement techniques that rely on valid accounts, remote services, and Windows management tools rather than obviously malicious binaries.
In practice, defenders tend to encounter a handful of recurring techniques:
For management teams, MITRE ATT&CK matters because it gives operations, engineering, and leadership a common reference model. It helps answer a practical question: are we talking about remote services, credential abuse, or remote execution through internal tools?
| Technique | Description | MITRE ATT&CK ID |
|---|---|---|
| Remote services | Using internal remote access protocols such as RDP or SSH to move between hosts | T1021 |
| Valid accounts | Using legitimate user, admin, or service credentials to access internal systems | Valid Accounts |
| Use alternate authentication material | Authenticating with password hashes, tickets, or similar artifacts instead of the user's password | T1550 |
| Windows management tools | Leveraging built-in Windows administration capabilities to execute or manage remotely | Windows Management Tools |
| Remote service creation | Creating or modifying services on remote systems for code execution or persistence | Remote Service Session |
The table is intentionally practical, not exhaustive. MITRE ATT&CK is broader than any single environment, and security teams shouldn't confuse framework coverage with detection coverage.
What doesn't work is hunting only for malware signatures. That misses a large share of movement that rides on approved protocols and approved identities.
What does work is combining signals that are weak on their own but useful together:
If your program treats internal administration as inherently trustworthy, the attacker only needs to steal one credible identity.
The phrase "lateral movement" can sound abstract until you watch how it unfolds in real environments. The mechanics are similar across IT and OT, but the access paths, constraints, and business consequences are different.
A marketing user opens a phishing attachment. The attacker now has a workstation, a user context, and a starting point.
From there, the attacker surveys reachable shares and internal systems. They discover scripts, cached credentials, browser sessions, or evidence that an IT admin recently used the device for support. The first host isn't the target. It's the launch point.
Next comes the pivot. The attacker uses recovered credentials or a valid session path to reach an admin workstation. From that machine, the path to identity infrastructure becomes much shorter. File shares, privileged groups, and directory services become visible. If they can reach the domain controller or equivalent identity tier, the problem becomes enterprise-wide.
This is the classic IT pattern. A low-value endpoint becomes a stepping stone to high-value control.
OT changes the path, not the risk. In these environments, the attacker often doesn't start from internet exposure at all. They start from remote maintenance, third-party access, jump hosts, or shared credentials tied to operations.
Cloudflare notes in its lateral movement overview that in OT and air-gapped environments, the attack surface shifts from internet-facing compromise to privileged remote access, vendor connectivity, jump hosts, and shared maintenance credentials, where a single compromised admin session can still create enterprise-wide exposure.
A realistic OT sequence looks like this:
The impact is different from IT. In corporate networks, the endgame is often data access or identity dominance. In OT, it can include production interruptions, unsafe process changes, loss of auditability, or forced shutdowns while teams determine what was touched.
For a deeper look at that path, this analysis of how vendor access can lead into OT systems is worth reviewing.
IT teams often assume segmentation is the answer. OT teams often assume isolation is the answer. Both assumptions can fail if identity paths remain too broad.
In IT, the weak point is usually over-trusted internal administration. In OT, it's often the operational exception: shared vendor access, standing privileges, maintenance urgency, and systems that can't tolerate aggressive security changes.
Detection gets difficult once the attacker starts using legitimate tools. At that point, the task isn't just finding malicious code. It's finding admin-like behavior that doesn't make operational sense.
That means looking for combinations of anomalies, not single events.
The first clue is often identity behavior that doesn't fit the account's role.
Watch for:
A useful question for every alert is simple: Does this account usually work this way from this device?
Approved protocols create the most noise in real environments because they're both necessary and abusable.
Focus on these signals:
| Indicator | Why it matters |
|---|---|
| Unexpected RDP or SSH from non-admin endpoints | Suggests a compromised user device is being used to pivot |
| PowerShell remoting or similar admin tooling from ordinary workstations | Indicates use of built-in tools outside expected admin paths |
| Sudden host-to-host communication between segments that rarely interact | Points to reconnaissance or pivoting activity |
| Tool transfer between internal systems | Can indicate staging for further movement or execution |
Detection improves when you baseline who normally administers what, from where, and at what times.
OT environments require extra care because normal maintenance behavior can resemble that of attackers. That doesn't mean they're indistinguishable. It means context matters more.
Look for:
The mistake many teams make is monitoring endpoint malware while ignoring session context. In lateral movement cases, the session often tells the story earlier than the payload does.
The most effective controls don't try to guess every attacker's move. They reduce the number of moves that are possible in the first place.
That requires a shift away from network-only thinking. Firewalls and segmentation still matter, but they aren't enough on their own if stolen credentials can still grant broad access paths. Modern containment depends on combining identity verification, least privilege, session control, and microsegmentation.
Illumio's guidance on how lateral movement is mitigated is direct: practical mitigation focuses on shrinking pathways through network segmentation or microsegmentation and MFA for internal privileged access. The same guidance frames microsegmentation and identity-based access as the most effective means to prevent east-west propagation, because each segment becomes its own security boundary.
That's the architectural core. If every internal system can still talk to every other internal system, you're relying on detection to save you after the attacker has options.
Some controls sound good in policy but don't hold up operationally. The ones below usually do.
Permanent admin access creates ready-made movement paths. Replace it where possible with just-in-time elevation, scoped access approvals, and role separation between daily user work and administrative work.
A lot of organizations stop MFA at VPN or cloud login. That's not enough. Internal privileged access should also be re-verified, especially for admin sessions, jump servers, and remote maintenance workflows.
Flat segmentation projects fail because they ignore how people work. Segment around trust boundaries that make sense: admin tiers, identity infrastructure, production systems, vendor access zones, and engineering workstations.
Shared accounts, reused credentials, and broad jump-host entitlements are still common in OT and support environments. They make operations faster. They also make compromise harder to contain.
Field lesson: The access path you keep for convenience will be the path an attacker tests first.
Traditional network defense assumes you can define safe zones well enough to stop movement with routing and filtering. In hybrid IT and OT, that's often unrealistic. Users, vendors, MSPs, and support engineers need dynamic access across different systems and contexts.
That is why identity-centric Privileged Remote Access control is becoming more useful than broad network exposure as the primary design principle. Instead of placing a user "on the network" and trusting them to reach what they need, modern Privileged Remote Access platforms authorize a specific user to a specific application or system for a specific session, with auditing and recording attached.
That model is particularly important in OT, where uptime and legacy constraints often limit what can be changed at the endpoint or network layer.
Platforms in the Privileged Remote Access category, including Safous, are designed to connect identity directly to authorized applications and systems, record privileged sessions, and centralize vendor and remote maintenance access without requiring broad network exposure or a full network redesign.
That matters when the objective is to prevent a single compromised credential from leading to unrestricted internal movement.
A few approaches consistently underperform:
The core lesson is straightforward. Lateral movement succeeds when the environment gives internal users, systems, or vendors more trust than they should have.
That is why Zero Trust matters. Not as a slogan, but as a design discipline. Never trust internal access by default. Verify identity, constrain privilege, and scope every session. The point isn't to make movement impossible in theory. It's to make unauthorized movement difficult, visible, and containable in practice.
The IT-OT distinction is important here. IT programs usually need to clean up privilege sprawl and overexposed management paths. OT programs usually need to control third-party access, maintenance sessions, and jump-host trust without breaking uptime. Different operational problems. Same architectural answer: remove implicit trust and bind access to identity, purpose, and session context.
The National Cyber Security Center's position, as summarized by Zero Networks on preventing lateral movement, is that organizations shouldn't automatically trust internal network traffic and should enforce controls such as password hygiene, MFA, logging, device patching, and production honeypots to detect or prevent this behavior.
For leadership teams, the practical next step is to review internal access as critically as external exposure. Look at who can reach what, which privileged sessions are recorded, where shared credentials still exist, and whether vendors are getting network presence when they only need application-level access.
If you want a concise view of why this architecture shift matters, Safous also outlines the benefits of a Zero Trust architecture in the context of controlled remote access and privileged session governance.
What is Privileged Remote Access?
Privileged Remote Access is a security approach that authorizes, governs, monitors, and records remote privileged sessions to critical systems without exposing broad network access.
How does Privileged Remote Access help prevent lateral movement?
Privileged Remote Access reduces the risk of lateral movement by limiting users and vendors to approved systems and sessions rather than granting broad internal network trust.
If lateral movement is the problem you're trying to contain across hybrid IT and OT, Safous is built for Privileged Remote Access in those environments. It gives teams a way to authorize, monitor, and record privileged access at the identity and session level, rather than exposing broad network paths that attackers can reuse after a compromise.