The laptop a contractor plugs into a control network for an afternoon can carry more risk into the plant than any permanent connection, because it has lived on other networks first. MITRE ATT&CK for ICS tracks this as T0864 Transient Cyber Asset, an Initial Access technique for Windows and Linux assets. ATT&CK describes transient assets as devices brought into an environment by authorised personnel that do not stay there permanently, and notes they are common where remote management is not feasible, there is no external remote access, or contractor and vendor access is required. This guide is for OT security leads, control engineers and compliance owners, including NERC CIP entities. It covers how adversaries use transient assets, the NERC CIP-010 and CIP-003 requirements, a practical control set, MITRE's detection analytics and response. Defensive framing only.
Key takeaways
- Trust is the attack surface. ATT&CK notes an adversary can compromise a transient asset while it sits on an external network and then use its trusted access inside the control environment.
- Engineering software travels with the laptop. The installed vendor tools and libraries that let engineers talk to controllers are exactly what an adversary needs; the Maroochy case shows a computer with proprietary engineering software used against a wastewater system.
- NERC CIP already sets the baseline. CIP-010-4 R4 (high and medium impact) and CIP-003-9 Attachment 1 Section 5 (low impact) require documented plans for transient cyber assets and removable media, including third-party devices.
- Site-owned beats visitor-owned. A hardened laptop that stays inside OT removes most of the uncertainty a contractor's own machine brings.
- Detect the first appearance. MITRE's analytic flags a device never seen before that immediately connects to ICS application servers outside an approved maintenance window.
What T0864 covers
ATT&CK for ICS describes three ways transient assets are abused:
- Compromise outside, attack inside: the asset is targeted while connected to an external network (home, hotel, corporate, another customer's site) and its trusted access is then used in the control environment.
- Abuse of installed tools: applications and libraries legitimately used to interact with control system devices are used by the adversary.
- Insecure configuration: an asset that was never deployed with a secure configuration carries malware which propagates when it connects to the ICS network.
Typical transient assets are engineering and maintenance laptops, vendor diagnostic laptops, test equipment that runs a general purpose operating system, and tablets used for commissioning. Removable media is related but tracked separately as T0847; see the MITRE ATT&CK for ICS T0847 Replication Through Removable Media guide and the Removable Media and USB Control Guide. For the ICS matrix as a whole see the MITRE ATT&CK for ICS Guide.
The public case
| Case | What ATT&CK records | Control lesson |
|---|---|---|
| Maroochy Water Breach (C0020), 2000 | The adversary used a computer, possibly stolen, with proprietary engineering software to communicate with the local government's wastewater system; the campaign led to the release of 800,000 litres of raw sewage. | Engineering laptops and their software are control-capable assets: inventory them, encrypt them, and make loss or theft a security incident. |
ATT&CK lists no other procedure examples for T0864 as of v20.
What NERC CIP requires
For North American bulk electric system entities, transient cyber assets (TCAs) and removable media have explicit requirements. Other sectors can use the same structure as a good-practice template.
| Requirement | Scope | What the plan must cover |
|---|---|---|
| CIP-010-4 R4, Attachment 1 Section 1 | High and medium impact BES Cyber Systems and associated Protected Cyber Assets; TCAs managed by the Responsible Entity | 1.1 manage TCAs ongoing or on demand; 1.2 authorise users, locations and uses; 1.3 mitigate unpatched software (patching, a live operating system from read-only media, hardening or other methods); 1.4 mitigate malicious code (antivirus with managed signatures, application whitelisting or other methods); 1.5 mitigate unauthorised use (restricted physical access, full-disk encryption with authentication, multi-factor authentication or other methods) |
| CIP-010-4 R4, Attachment 1 Section 2 | TCAs managed by a party other than the Responsible Entity | 2.1 review the party's patching or other vulnerability mitigation; 2.2 review its antivirus, application whitelisting, live operating system use or hardening; 2.3 decide whether more mitigation is needed and apply it before connection |
| CIP-010-4 R4, Attachment 1 Section 3 | Removable media | 3.1 authorise users and locations; 3.2 detect malicious code using a Cyber Asset that is not a BES Cyber System or Protected Cyber Asset, and mitigate it before connection |
| CIP-003-9 R2, Attachment 1 Section 5 | Low impact BES Cyber Systems | 5.1 malicious code mitigation for entity-managed TCAs; 5.2 review of third-party TCAs before connection, with additional mitigation where needed; 5.3 scan removable media on a non-BES Cyber Asset and mitigate before connection |
FERC approved CIP-010-4 in March 2021 and CIP-003-9 in March 2023; effective dates follow each standard's implementation plan, so confirm the version currently in force for your region with NERC. See the NERC CIP Guide.
Mitigations MITRE maps to T0864
| Mitigation | MITRE's guidance for this technique | OT implementation |
|---|---|---|
| M0930 Network Segmentation | Control software movement between business and OT through one-directional DMZs; engineering workstations, including TCAs, should have minimal connectivity to external networks and limited dual-homing | Connect TCAs only to a defined maintenance port or VLAN in the target zone, never bridging zones; block internet and email from that segment |
| M0949 Antivirus/Antimalware | Install anti-malware on all workstations and transient assets that may have external access | Signatures updated through an OT-side update server before each connection, with a scan record kept |
| M0951 Update Software | Update software on control network assets where possible, using modern operating systems | Patch site-owned TCAs on a schedule matched to the engineering software vendor's supported versions |
| M0947 Audit | Integrity checks of transient assets, including Secure Boot and Trusted Boot validation and checks of programs, configuration files, processes, accounts and open ports | A pre-connection check against a known-good baseline: installed software list, local accounts, listening ports |
| M0941 Encrypt Sensitive Information | Full-disk encryption, especially where engineering workstations are transient and more likely to be lost, stolen or tampered with | Encrypt every TCA disk with pre-boot authentication; project files on the laptop are a map of the plant |
Choosing a transient asset model
| Model | When it fits | Trade-offs |
|---|---|---|
| Site-owned TCA kept in OT | Routine maintenance by own staff; any site that can afford a small pool of laptops | Best control of patching and software; needs licence management for vendor tools and someone to own the pool |
| Site-owned TCA issued to contractors | Contractors who only need standard engineering tools | Contractor uses a known machine; vendor-specific diagnostic tools may still require their own laptop |
| Third-party TCA with pre-connection review | Specialist vendor equipment that cannot be replaced | The review (patch level, anti-malware state, hardening) is a point-in-time check; NERC CIP-010 Section 2 expects extra mitigation where the review falls short |
| Remote access instead of a visit | Support that does not need physical presence | Removes the transient device but adds a persistent path; see the OT Remote Access Guide |
Small sites with few visits can run a single site-owned laptop and a paper log. Large fleets benefit from a central TCA pool, managed images per engineering tool set and logs fed into the OT SOC.
Where identity fits
A transient asset is an identity problem twice over. The device needs its own identity in the asset inventory and, where the network supports it, at the switch port through 802.1X or another network access control method (see the Network Access Control (NAC) Guide). The person using it needs a named account rather than a shared engineering login, and engineering software credentials and controller passwords stored on the laptop are non-human secrets that leave the site whenever the laptop does. Keep controller and project passwords out of local files, rotate them after a contractor engagement ends, and tie each TCA connection to a work order. See the OT Third-Party and Integrator Access Guide and the Non-Human Identities in OT Guide.
Rolling out a TCA programme
- Inventory: list every device that connects temporarily today, who owns it, which zones it reaches and which engineering tools it runs. Interview maintenance and contractor managers, not only IT.
- Define connection points: agree the ports or VLANs where TCAs may connect in each zone and disable or lock the rest.
- Build the baseline: a hardened image for site-owned TCAs with full-disk encryption, anti-malware, application allowlisting and only the vendor tools needed. See the Engineering Workstation Security Guide.
- Write the third-party check: a short pre-connection checklist (patch level, anti-malware signature date, hardening evidence, owner, work order) that the site lead signs before connection.
- Pilot with monitoring only: run new-device alerting for a few weeks to learn real maintenance patterns before enforcing port control.
- Enforce in stages: port control on the least critical zone first, then wider, each change agreed with operations and planned for an outage window where required.
- Rollback: keep a documented way to open a specific port for an emergency repair, authorised by the site lead and logged, so an urgent fix does not wait on a policy change.
Detection and measurement
ATT&CK for ICS v20 sets out detection analytics for T0864 (DET0744), each gated so that alerts fire only when the device and session break the approved policy and are followed by access to a protected OT asset, outside approved vendor support, commissioning and maintenance windows.
| Platform | Signal (from MITRE's analytics) | Log source |
|---|---|---|
| Windows | A device with an IP or MAC address never seen before makes its first connection to ICS application servers immediately after a new device association on the network | NetFlow or IPFIX flow records; Windows Security event 4624 from a hardware ID not in the approved device inventory |
| Linux | An SSH connection to an ICS Linux asset from an IP address that appeared on the network shortly before and is not in the approved inventory | syslog auth records |
MITRE notes the approved device inventory is ideally enforced through NAC or 802.1X. Passive OT monitoring can supply the first-seen device signal; see the OT Network Security Monitoring Guide and the OT Asset Visibility Guide.
Metrics:
- Percentage of TCA connections with a matching work order and pre-connection check record.
- Unknown devices seen on OT networks per month, and median time to identify each.
- Percentage of site-owned TCAs with current anti-malware signatures and patches at time of connection.
- Percentage of third-party connections where the review led to extra mitigation or refusal.
- Percentage of TCAs with full-disk encryption enabled.
Responding to a suspect transient asset
Follow the OT Incident Response Guide. Technique-specific points:
- Disconnect with operations: agree with the control room before pulling a laptop mid-task, as it may be holding an online session with a controller.
- Preserve the device: keep the laptop powered and isolated for imaging where possible; it holds the evidence of where it has been.
- Scope the reach: use switch logs, flow records and the work order to list every asset it touched, then check those assets for new files and changed logic.
- Treat loss as compromise: a lost or stolen engineering laptop means rotating every controller and application credential it stored and reviewing project files it held.
- Verify control logic: compare running logic on reached controllers with the approved version before declaring the event closed.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0864; M0930, M0949, M0951, M0947, M0941; DET0744 | Technique, mapped mitigations and detection strategy |
| NERC CIP | CIP-010-4 R4 Attachment 1; CIP-003-9 Attachment 1 Section 5 | Mandatory TCA and removable media plans for BES entities |
| NIST SP 800-53 Rev. 5 | MA-3 Maintenance Tools; IA-3 Device Identification and Authentication; CM-8 System Component Inventory; SI-3 Malicious Code Protection; SC-41 Port and I/O Device Access | Maintenance devices, device authentication, inventory, anti-malware and port control |
| NIST CSF 2.0 | ID.AM-01; PR.AA-03; DE.CM-01 | Hardware inventory, device authentication and network monitoring |
For zone and conduit design see the IEC 62443 Guide and the NIST SP 800-82 OT Security Guide.
Common failure patterns
- Contractor laptops treated as the contractor's problem. NERC CIP-010 Section 2 exists because third-party devices still connect to your assets.
- One-time checks. A laptop reviewed at the start of a two-week outage may have been on hotel Wi-Fi every night since.
- Dual-homed maintenance laptops. Wi-Fi left on while cabled into the control network bridges two zones; MITRE's segmentation guidance warns against dual-homing.
- Unencrypted engineering laptops. A lost laptop with project files and stored controller passwords is both a data leak and an access path.
- Open switch ports everywhere. Without defined connection points, any device can join any zone.
- Shared logins on TCAs. Without named accounts, there is no answer to who connected what, when.
Practitioner checklist
- Keep an inventory of every transient cyber asset, its owner and the zones it may reach.
- Provide site-owned, hardened, encrypted laptops for routine OT maintenance.
- Require a signed pre-connection check for every third-party device.
- Define and label permitted connection points; disable or lock other ports.
- Turn off wireless interfaces on TCAs while connected to OT.
- Tie every connection to a named user and a work order.
- Alert on first-seen devices that reach ICS application servers outside approved windows.
- Rotate stored controller and application credentials after contractor engagements and lost devices.
- Map the programme to CIP-010-4 R4 or CIP-003-9 Section 5 where NERC CIP applies.
Standards and references
- MITRE ATT&CK: Transient Cyber Asset (ICS)
- MITRE ATT&CK: Maroochy Water Breach
- NERC: CIP-010-4 Configuration Change Management and Vulnerability Assessments
- NERC: CIP-003-9 Security Management Controls
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: OT Security Guide · OT Remote Access Guide · Removable Media and USB Control Guide · NERC CIP Guide