ATT&CK for ICS T0822 External Remote Services in OT

External Remote Services (T0822) is the front door into many industrial networks: the VPN, remote desktop gateway or vendor support connection that lets engineers and suppliers reach control systems from outside, used by an adversary instead. ATT&CK for ICS places it under Initial Access and notes that access to valid accounts is often a requirement, which is why it usually travels with T0859 Valid Accounts. This guide covers what the ICS entry adds to the enterprise technique, the campaigns ATT&CK records, how to inventory and harden every remote path into OT, the detection analytics ATT&CK attaches to T0822, and how to respond without cutting off the people who keep the plant running. It is written for OT security engineers, control system owners, remote access administrators and SOC analysts. For the matrix see the MITRE ATT&CK for ICS Guide; for the enterprise technique see the T1133 External Remote Services Defensive Guide.

Key takeaways

Remote access is a designed path into OT, so attackers reuse it. ATT&CK notes that vendors and internal engineering groups often have external remote access to control networks, sometimes directly from the internet.
The credential matters more than the exploit. In the 2015 Ukraine Electric Power Attack, ATT&CK records that Sandworm Team used valid accounts taken from the Windows domain controller to access the grid operators' control system VPN.
Every path counts, including the forgotten ones. Point-to-point VPNs at third parties, split-tunnelled support laptops, cellular modems and radio links are all T0822 routes.
ATT&CK's analytics look at what the session does next. An unusual source for an ICS-role account matters most when the session goes on to reach the ICS zone or a field device management port.
Response must keep legitimate support working. Plan how to cut a suspect session or vendor path without stranding operations that depend on remote engineering.

What T0822 covers in ICS

ATT&CK for ICS v20 describes External Remote Services as using services that let users connect to internal network resources from external locations, such as VPNs and Citrix, as a point of initial access. Remote service gateways often manage the connections and the credential authentication. The technique applies to Embedded, Windows, Linux and Network Devices platforms.

The ICS text adds three points. External remote services allow administration of a control system from outside it. Vendors and internal engineering groups often have such access, frequently via the corporate network and in some cases directly from the internet. And adversaries searching for a way in may look for existing point-to-point VPNs at trusted third-party networks, or remote support connections where split tunnelling is enabled, citing E-ISAC and SANS analysis of the 2015 Ukraine attack.

Technique	What is abused	OT example	First control
T0822 External Remote Services	A legitimate remote access service, usually with valid credentials	Logging in to the plant VPN with a stolen engineer's password	Brokered access, phishing-resistant MFA, per-session approval
T0859 Valid Accounts	The credential itself, at any stage	Reusing a domain account to reach an HMI host	Separate OT accounts, no shared credentials
T0819 Exploit Public-Facing Application	A software flaw in an internet-facing application	Exploiting an exposed web HMI	Remove exposure, patch, DMZ
T0883 Internet Accessible Device	A field device directly reachable from the internet	A controller answering its native protocol on a public address	Remove the device from the internet
T0886 Remote Services	Remote services used for movement inside the network	Remote desktop from a jump host to an engineering workstation	Restrict internal remote services by zone

The remote access appliance itself is also a public-facing application, so a flaw in a VPN concentrator is T0819 while a login through it is T0822. See the MITRE ATT&CK for ICS T0819 Exploit Public-Facing Application guide.

Campaigns and software ATT&CK records

Procedure example	What ATT&CK records	Lesson for defenders
2015 Ukraine Electric Power Attack (C0028)	Sandworm Team used valid accounts taken from the Windows domain controller to access the control system VPN used by grid operators	If OT VPN accounts live in the corporate domain, a domain compromise is an OT compromise
Maroochy Water Breach (C0020)	The adversary gained remote computer access to the system over radio	Remote access includes radio and telemetry links, not only IP VPNs
Fuxnet (S1157)	Initial execution relied on accessing external remote services for victim environments	Destructive tooling against field devices still begins with a remote login
2025 Poland Wiper Attacks (C0063)	The adversaries gained initial access by compromising edge devices	The remote access edge is a high-value target in its own right

CERT Polska's report on the 29 December 2025 attacks describes coordinated, purely destructive attacks on more than 30 wind and photovoltaic farms, a combined heat and power plant and a manufacturing company. At the renewable sites, damage to RTUs stopped communication with the distribution system operator and prevented remote control, while ongoing electricity production was not affected. See the Sandworm Threat Actor Profile for the actor behind the Ukraine campaigns.

Outside ATT&CK's procedure list, the Colonial Pipeline ransomware attack shows the same pattern from the IT side: access through a legacy VPN profile that was no longer used but never disabled, with no MFA, followed by a precautionary pipeline shutdown when ransomware was found.

Inventory every remote path into OT

You cannot secure remote paths you do not know. Most OT estates have more than the official VPN. Build the list from firewall rules, flow records, asset inventories and vendor contracts, then confirm each path with its owner.

Path	Where it hides	Typical weakness	Target state
Corporate VPN with OT reach	Firewall rules allowing VPN pools into OT subnets	Domain accounts, broad network reach	VPN lands in a DMZ broker, never directly in OT
Vendor site-to-site or point-to-point VPN	Old commissioning projects and service contracts	Always on, shared accounts, little logging	Disabled by default, enabled per session with approval
Remote desktop and remote support tools	Software installed on HMIs or engineering hosts	Direct inbound or cloud-relayed access that bypasses the firewall design	Removed, or replaced by the approved broker
Cellular modems and routers at remote sites	Pumping stations, substations, renewable sites	Public addresses, default credentials, no central log	Private APN or brokered access, central logging
Radio and telemetry links	SCADA telemetry to outstations	Assumed private, rarely monitored	Treated as remote access in risk assessment

Unmanaged remote support tools and cellular modems are the paths most often missing from inventories. See the OT Asset Visibility Guide and the OT Remote Access Guide for the target architecture.

Hardening remote access: ATT&CK's mitigations in practice

ATT&CK lists eight mitigations for T0822. Taken together they describe a brokered, least-functionality, strongly authenticated design. The joint CISA, FBI, EPA and DOE primary mitigations for OT say the same: if remote access is needed, use a private IP network connection, or a VPN with a strong password and phishing-resistant MFA, apply least privilege to each user role and disable dormant accounts.

Route all access through a DMZ broker (M0930, M0935): ATT&CK says to deny direct remote access to internal systems through proxies, gateways and firewalls, consider a jump server in the DMZ, and use the DMZ or corporate resources for vendor access. It also says to limit remote services to centrally managed concentrators. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Require strong MFA (M0932): ATT&CK recommends strong MFA for remote service accounts, and warns that some MFA implementations can be intercepted. Prefer phishing-resistant methods, as the joint agencies specify.
Turn access off when not in use (M0942, M0918): ATT&CK suggests removing remote services that are not regularly used, or enabling them only when required, such as for vendor access, and using dynamic account management to remove accounts when not in use. Configure jump boxes and VPN concentrators with least functionality.
Apply account use and password policies (M0936, M0927): lockouts, permitted login times and password strength, applied with care where lockout could affect safety or availability. ATT&CK makes that safety caveat explicitly.
Record and approve sessions: time-bound approval per session, with recording for vendor and privileged sessions, gives operations control and gives investigators evidence. See the Vendor Privileged Access Management (VPAM) Guide.
Secure the access platform itself: patch the gateway promptly, keep its management interface off the internet and send its logs centrally. See Securing the OT remote access platform itself.

Choosing between options

Need	Preferred approach	Trade-off
Internal engineers, regular support	VPN to a DMZ jump host with phishing-resistant MFA and separate OT accounts	Two logins; needs a managed jump host
Vendor emergency support	Brokered session, enabled on request, approved by operations, recorded	Slower first response; agree response times in contract
Remote site telemetry	Private network or APN, no public addresses, central logging of modem access	Carrier cost and configuration effort
Small utility with one integrator	Single brokered path, access off by default, MFA, a named contact at the integrator	Relies on discipline; check monthly that access is off

For buying a broker, see the Security Service Edge for OT Remote Access Buyers Guide.

Detection: ATT&CK's analytics for T0822

ATT&CK v20 attaches a detection strategy, Detection of External Remote Services, with four analytics. Each carries the OT operational fidelity gate: alert only when the account, device or session breaks the approved identity, source host, jump path or zone policy and is corroborated by access to a protected OT asset, execution, a configuration change or another security-relevant follow-on event. Approved shift activity, vendor support, break-glass use, commissioning and documented remote-access windows are suppressed.

Platform	What it looks for	Data you need
Network devices	Authentication to an external remote access gateway with ICS-role credentials from a geolocation or autonomous system number inconsistent with the account's usage pattern, followed by that session reaching the ICS zone	Gateway authentication logs with source address, plus flow records between the VPN pool and OT zones
Embedded	Connections to field device management ports from addresses routed through external remote access infrastructure rather than from the expected ICS segments	Session and flow metadata (endpoints, ports, timing, bytes); ATT&CK notes no payload visibility is needed
Linux	SSH authentication or sessions to an ICS Linux asset from a VPN-assigned or remote access source outside the approved remote administration baseline	SSH authentication logs with source address
Windows	An ICS-role account session from a VPN or remote access connection that then accesses Windows ICS hosts in a pattern inconsistent with documented vendor support session profiles	Windows logon events with source address and logon type, mapped to the VPN address pool

Making the analytics work

Map VPN address pools to people: the analytics depend on knowing which internal address belongs to which remote session. Keep gateway logs long enough to join them to OT logs.
Write down vendor session profiles: the Windows analytic compares behaviour to documented vendor support profiles. Record which hosts each vendor normally touches and when.
Feed the maintenance and access calendar to the SOC: approved sessions and commissioning windows are what the gate suppresses.
Alert on dormant accounts: any remote login by an account unused for 90 days or more (NHI Mgmt Group suggested threshold, matching the metric below) deserves a call to its owner before the session continues.

See the OT Network Security Monitoring Guide and the OT Security Operations Centre Guide.

Where identity fits

T0822 is an identity problem dressed as a network one. Vendor accounts are often shared by several engineers, stay enabled for years and sit outside joiner and leaver processes; site-to-site tunnels authenticate with pre-shared keys or certificates that nobody owns. Give every remote user a named account, give every tunnel and service credential an owner and a rotation date, and keep OT remote access accounts out of the corporate domain so the 2015 Ukraine pattern cannot repeat. See the OT and ICS Identity and Access Guide and NHIs in OT.

Safety-aware response

Identify what the session can reach: which zones, hosts and devices are reachable from the suspect session or tunnel, and whether it can write to controllers.
Terminate the session and disable the account or tunnel: agree first with operations whether anyone legitimate depends on that path right now, and how they will be supported meanwhile.
Check for process changes: compare controller logic, setpoints and configurations touched during the session against known-good values. This is the T0836 Modify Parameter question.
Reset and re-issue: reset credentials for the account and any that share its password, rotate tunnel keys and certificates, and re-enrol MFA if a factor may be compromised.
Preserve evidence: gateway and broker logs, session recordings, jump host logs and flow records. See the If your OT remote access and historian is compromised playbook and the OT Incident Response Guide.

Metrics that show it is working

Remote paths into OT not through the broker: count of tunnels, tools and modems bypassing the approved route. Target zero.
Remote access accounts with phishing-resistant MFA: share of human remote accounts. Target 100%.
Vendor access off by default: share of vendor paths disabled outside approved sessions. Target 100%.
Dormant remote accounts: accounts unused for 90 days that are still enabled. Target zero.
Session approval and recording coverage: share of vendor and privileged sessions approved and recorded.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK for ICS mitigation
Brokered, managed remote access	AC-17 Remote Access; SC-7 Boundary Protection	PR.IR-01	M0930 Network Segmentation; M0935 Limit Access to Resource Over Network
Strong authentication	IA-2 Identification and Authentication (Organizational Users)	PR.AA-03	M0932 Multi-factor Authentication
Account lifecycle and dormant accounts	AC-2 Account Management	PR.AA-01	M0918 User Account Management
Least functionality on gateways	CM-7 Least Functionality	PR.PS-01	M0942 Disable or Remove Feature or Program
Lockout and password rules	AC-7 Unsuccessful Logon Attempts; IA-5 Authenticator Management	PR.AA-01	M0936 Account Use Policies; M0927 Password Policies
Detection	SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-01; DE.CM-03	ATT&CK detection strategy for T0822
Containment	IR-4 Incident Handling	RS.MI-01	Not applicable

NIST SP 800-82 Rev. 3 (final, 28 September 2023) is the OT tailoring reference; NIST notes an initial public draft of Revision 4 is open for comment until 30 November 2026. See the NIST SP 800-82 OT Security Guide and the IEC 62443 Guide.

Common failure patterns

OT VPN accounts in the corporate domain: the 2015 Ukraine campaign took credentials from the domain controller and used them on the control system VPN.
Legacy profiles that never die: the Colonial Pipeline intrusion used an unused VPN profile with no MFA.
Always-on vendor tunnels: a permanent connection to a supplier makes the supplier's network part of yours, which is the staging-target pattern ATT&CK describes.
Remote support software installed by integrators: tools added during commissioning create paths that the firewall design never anticipated.
Treating radio and cellular links as private: the Maroochy case shows remote access over radio is still remote access.
Lockout policies that hurt operations: aggressive lockout on shared operator accounts can deny operators access during an incident. Use named accounts and MFA instead of relying on lockout.

Practitioner checklist

Inventory every remote path into OT, including vendor tunnels, remote support tools, cellular modems and radio links.
Route all remote access through a DMZ broker or jump host; deny direct access from VPN pools to OT subnets.
Require phishing-resistant MFA and named accounts for every human remote user, including vendors.
Keep OT remote access accounts separate from the corporate domain.
Disable vendor access by default and enable it per session with operations approval and recording.
Disable dormant remote accounts and give every tunnel credential an owner and rotation date.
Deploy the ATT&CK T0822 analytics with VPN pool mapping and documented vendor session profiles.
Write and test a runbook for cutting a remote path while keeping legitimate support available.

MITRE ATT&CK for ICS T0822 External Remote Services: Securing and Monitoring OT Remote Access