Oil and gas operators run some of the most consequential operational technology in any sector, and a single compromised remote access account can stop a pipeline even when no control system is touched. Upstream production, midstream pipelines and terminals, and downstream refineries each have different architectures, regulators and failure modes, but they share long asset lifecycles, remote and unmanned sites, heavy reliance on contractors and a safety case that cyber risk can undermine. This guide covers the threat picture for each segment, the main regulatory regimes (TSA Pipeline Security Directives, the US Coast Guard maritime cyber rule, NIS2 in Europe), the industry standards (API Standard 1164, IEC 62443, DNV-RP-G108), and a phased programme with metrics. It is written for OT security leads, control system engineers and CISOs in energy companies, and it assumes the reader knows basic OT concepts covered in the OT Security Guide.
Key takeaways
- The business network can shut the pipeline. Colonial Pipeline halted operations in 2021 because of ransomware on IT systems; IT and OT dependency mapping (billing, scheduling, custody transfer) matters as much as control system hardening.
- Regulation is segment specific. TSA directives bind designated critical pipelines, the US Coast Guard rule covers MTSA facilities and Outer Continental Shelf facilities, and NIS2 covers oil and gas entities in the EU; map each asset to its regime before designing controls.
- API 1164 and IEC 62443 are the engineering backbone. API Standard 1164 (3rd edition) gives a pipeline specific programme, IEC 62443 gives zones, conduits, security levels and supplier requirements, and DNV-RP-G108 shows how to apply 62443 in oil and gas projects.
- Remote access and third parties are the front door. Vendor support links, SCADA telemetry over cellular and satellite, and contractor laptops at well sites are the most common paths into OT; every one needs an owner, MFA and a logged, brokered session.
- Safety systems need their own zone. Refinery and offshore safety instrumented systems must sit in a dedicated safety zone with controlled conduits, because an attack on safety turns a cyber incident into a process safety event.
Upstream, midstream and downstream: different OT, different risks
Treating "oil and gas" as one environment produces controls that fit nowhere. The table below shows how the three segments differ in practice.
| Segment | Typical OT | Characteristic exposure | Priority controls |
|---|---|---|---|
| Upstream (onshore wells, offshore platforms, drilling rigs) | RTUs, PLCs, wellhead and subsea control, drilling control systems, emergency shutdown (ESD) and fire and gas systems | Unmanned or remote sites, satellite and microwave links, rig contractors bringing their own control systems, long vendor support chains | Asset inventory per site, brokered remote access, removable media control, safety zone separation, contractor onboarding rules |
| Midstream (pipelines, compressor and pump stations, terminals, storage, LNG) | SCADA master stations, RTUs over wide area telemetry, leak detection, metering and custody transfer systems | Geographically dispersed assets, shared IT dependencies (scheduling, billing), regulatory designation as critical | IT/OT segmentation with dependency analysis, manual operation plans, telemetry encryption where feasible, TSA directive outcomes |
| Downstream (refineries, petrochemical plants, distribution terminals) | DCS, safety instrumented systems, advanced process control, historians, laboratory and blending systems | Large integrated plants, many vendor integrations, historian and APC links to business networks, turnaround periods with heavy contractor presence | Zone and conduit design to IEC 62443-3-2, SIS separation, change management during turnarounds, monitoring at Level 3/3.5 |
For the generic Purdue model and segmentation patterns, see the OT Security Guide. The rest of this guide focuses on what is specific to oil and gas.
Regulatory landscape (status checked October 2026)
The regimes below are the ones most oil and gas operators meet. Status is as stated on the official sources on the date checked; directives are reissued regularly, so confirm the current revision before relying on any detail.
| Regime | Who it covers | Core requirements | Status |
|---|---|---|---|
| TSA Security Directive Pipeline-2021-01 series (current listed revision 01E, "Enhancing Pipeline Cybersecurity") | Hazardous liquid and natural gas pipeline owners and operators notified by TSA | Designate a Cybersecurity Coordinator; report cybersecurity incidents to CISA (24 hours, revised from 12 hours in May 2022) | TSA lists 01E under 3 May 2025 |
| TSA Security Directive Pipeline-2021-02 series (current listed revision 02F, "Pipeline Cybersecurity Mitigation Actions, Contingency Planning, and Testing") | Owners and operators TSA has designated as critical (TSA estimates about 100) | TSA approved Cybersecurity Implementation Plan (CIP); Cybersecurity Incident Response Plan (CIRP) tested at least annually; annual Cybersecurity Assessment Plan (CAP) auditing at least one third of CIP measures each year, with an annual report; outcomes include IT/OT segmentation, access control, continuous monitoring and timely patching | TSA lists 02F under 3 May 2025; submissions are Sensitive Security Information |
| TSA proposed rule "Enhancing Surface Cyber Risk Management" (89 FR, 7 November 2024) | About 115 higher risk pipeline systems plus rail | Would codify the directives: Cybersecurity Coordinator, incident reporting to CISA, Cyber Risk Management programme with a Cybersecurity Operational Implementation Plan (COIP), CIRP and CAP with independent assessors | Proposed rule; we could not confirm a final rule from an official source as of October 2026 |
| US Coast Guard "Cybersecurity in the Marine Transportation System" (90 FR 6298) | MTSA regulated vessels, facilities (including many marine terminals) and Outer Continental Shelf facilities under 33 CFR parts 104, 105 and 106 | Cybersecurity Officer (CySO), Cybersecurity Plan, cyber incident response plan, MFA on remotely accessible OT, two drills every 12 months, incident reporting to the National Response Center | Effective 16 July 2025; Cybersecurity Plans due within 24 months of the effective date |
| EU NIS2 Directive (Directive (EU) 2022/2555) | Oil and gas entities in the energy sector (Annex I), such as pipeline, production, refining and storage operators | Article 21 risk management measures, Article 23 incident reporting, management accountability | Applies through national transposition; see the NIS2 Directive Guide |
The directive texts are not fully public: TSA treats operator submissions under the 02 series as Sensitive Security Information, so operators work from the copy TSA issues to them. The table summarises published descriptions, not the directive text.
Standards that do the engineering work
- API Standard 1164, Pipeline Control Systems Cybersecurity (3rd edition, August 2021): extended scope from SCADA only to all pipeline control systems, with requirements for an industrial automation and control security programme, risk assessment guidance and hardening against ransomware. It is based on the NIST Cybersecurity Framework and NERC CIP and is designed to be used with API Standard 780 for security risk assessment. It is a paid standard; operators often use it as the control catalogue behind their TSA CIP.
- ISA/IEC 62443 series: 62443-2-1 (security programme requirements for asset owners, 2024 edition), 62443-3-2 (security risk assessment for system design, which produces zones, conduits and target security levels), 62443-3-3 (system security requirements and security levels) and 62443-4-1 / 4-2 (supplier development lifecycle and component requirements). Use 3-2 and 3-3 in front end engineering design, and 4-1 / 4-2 in procurement. See the IEC 62443 Guide.
- DNVGL-RP-G108, Cyber security in the oil and gas industry based on IEC 62443 (2017): a recommended practice from a joint industry project with operators and automation vendors that explains how to apply 62443 in onshore and offshore projects and operations, and takes IEC 61511 functional safety into account. It is useful for writing cyber requirements into engineering, procurement and construction contracts.
- NIST SP 800-82 Rev. 3, Guide to OT Security (September 2023): the general OT reference with an SP 800-53 overlay. NIST has published an initial public draft of Rev. 4 with comments due 30 November 2026. See the NIST SP 800-82 OT Security Guide.
- UK HSE Operational Guidance OG86: how HSE inspectors assess IACS cyber security at COMAH sites, including refineries and terminals, built on zones and conduits and a dedicated safety zone.
Choosing a primary framework
- US pipeline operator designated by TSA: structure the programme around the 02 series outcomes, use API 1164 as the control catalogue and IEC 62443-3-2 for zone design. Keep a crosswalk so the CAP can show evidence per measure.
- Offshore or marine terminal operator in the US: the Coast Guard rule drives the plan; reuse 62443 zone work so the Cybersecurity Plan and any TSA CIP do not diverge.
- European or global integrated company: NIS2 sets governance and reporting; IEC 62443 gives a single engineering language across countries and vendors, which is why most global majors standardise on it.
- Small operator or independent producer: start with the CISA Cross-Sector Cybersecurity Performance Goals and a short list of 62443-3-3 SL1/SL2 requirements rather than a full 62443 certification effort. See the CISA CPG Guide.
Threats that matter in oil and gas
The table maps the main entry and impact paths to MITRE ATT&CK for ICS techniques (verified against ATT&CK v20) and to the control that breaks the chain.
| Scenario | ATT&CK for ICS | Where it shows up | Control that breaks it |
|---|---|---|---|
| Stolen or dormant VPN credentials used for remote access | T0822 External Remote Services, T0859 Valid Accounts | Corporate VPN, vendor support portals, remote SCADA access | MFA on every remote path, dormant account removal, brokered OT access with session recording |
| Internet exposed HMI, RTU or PLC | T0883 Internet Accessible Device | Remote well sites and pump stations with cellular modems | External attack surface scanning, private APN or VPN for telemetry, deny by default at the edge |
| Lateral movement from IT into OT through shared services | T0886 Remote Services, T0866 Exploitation of Remote Services | Historians, jump hosts, shared Active Directory, file shares | Separate OT identity domain, DMZ at Level 3.5, no direct IT to Level 2 flows |
| Ransomware on IT that forces a precautionary OT shutdown | T0828 Loss of Productivity and Revenue | Billing, scheduling, custody transfer and nominations systems | Dependency mapping, manual operation procedures, offline backups of OT critical IT |
| Contractor laptop or USB media at a site | T0864 Transient Cyber Asset, T0847 Replication Through Removable Media | Drilling rigs, turnarounds, commissioning | Transient device scanning kiosks, approved media, contractor device policy |
| Manipulation or trip of process and safety controllers | T0816 Device Restart/Shutdown, T0880 Loss of Safety | Refinery DCS and SIS, offshore ESD | Safety zone separation, key switch and engineering workstation control (see the Safety Instrumented Systems Security Guide) |
Architecture and controls by priority
- Know every asset and dependency: build a per site inventory (controller model, firmware, network, owner, vendor contract) and an IT dependency map that answers "which business systems must work for product to move?". Colonial showed that the billing system can be the dependency that stops the pipeline.
- Segment IT from OT with a real DMZ: historians, patch servers and remote access brokers live in a Level 3.5 DMZ; no protocol passes directly from IT to Level 2 or below. Apply deny by default rules and document every conduit. See the Network Segmentation Guide.
- Broker and record remote access: all vendor and engineer access passes through one broker in the DMZ with MFA, per session approval, time limits and recording. Remove standing VPN profiles for third parties. See the OT Remote Access Guide.
- Protect safety systems separately: SIS, ESD and fire and gas systems sit in a dedicated safety zone; read only data leaves through unidirectional or tightly filtered conduits.
- Monitor OT networks passively: deploy OT protocol aware monitoring at Level 3/3.5 and at key Level 2 segments, sending alerts to a SOC that has OT playbooks.
- Patch by risk, compensate where you cannot: follow vendor qualified patches, and use segmentation, allowlisting and monitoring for assets that cannot be patched until the next turnaround.
- Prepare to run manually: document and drill how each pipeline, terminal or unit operates if SCADA or business systems are unavailable, and keep offline backups of controller logic and configurations.
Where identity fits
Most oil and gas intrusions start with an identity, not an exploit. Shared operator accounts on HMIs, vendor accounts on remote access portals, service accounts used by historians and OPC connections, and default credentials on field devices are all non-human or shared identities that rarely get an owner or a review. Give each an owner and an expiry, remove shared logins where the platform supports named accounts, store vendor and service credentials in a vault with checkout, and keep OT directory services separate from corporate Active Directory. Colonial's entry point was a legacy VPN profile that was no longer used but had never been disabled, with a leaked password and no MFA; the Colonial Pipeline ransomware attack is the clearest case for a dormant account review. See the OT and ICS Identity and Access Guide.
Implementation: a phased programme
- Phase 0, scope (weeks 0 to 4): list every site and system, map each to its regime (TSA 01/02, Coast Guard, NIS2, HSE OG86) and identify the Critical Cyber Systems or equivalent. Appoint the Cybersecurity Coordinator or CySO where required.
- Phase 1, quick wins (months 1 to 3): MFA on all remote access, disable dormant and third party standing accounts, close internet exposed OT services found by external scanning, take offline backups of controller logic. Validate each change on one site first.
- Phase 2, architecture (months 3 to 12): run IEC 62443-3-2 risk assessments per facility, build the Level 3.5 DMZ and remote access broker, separate OT identity, put SIS into a safety zone. Deploy firewall rules in log only or monitor mode first, review a full operating cycle of traffic with operations, then enforce.
- Phase 3, detect and respond (months 6 to 18): deploy passive OT monitoring, integrate with the SOC, write OT incident playbooks that state who may order a precautionary shutdown, and test the CIRP with operations in a tabletop and a live manual operation drill. See the OT Incident Response Guide.
- Phase 4, sustain: build the annual assessment plan (the TSA CAP requires at least one third of measures audited each year), add 62443-4-1 / 4-2 requirements to procurement, and review architecture before every turnaround and major project.
Rollback: every firewall or access change in OT needs a written rollback (previous rule set or configuration saved and tested), an operations sign off and a change window agreed with the control room. If an enforced rule blocks a process flow, revert to the saved rule set first and investigate second.
Detection and measurement
- What to log: remote access broker sessions and approvals, VPN authentications (including failures and new source locations), firewall denies at the IT/OT boundary, engineering workstation logins, controller program downloads and mode changes, and new devices on OT networks.
- High value alerts: use of a dormant or vendor account outside an approved window, any IT to Level 2 flow, new remote access tools on OT hosts, controller program changes without a change ticket, unexpected safety trips.
| Metric | Target | Why it matters |
|---|---|---|
| Remote access paths into OT with MFA and brokering | 100% | The most common entry route |
| Accounts with OT access unused for 90 days still enabled | 0 | Dormant accounts were the Colonial entry point |
| Sites with a current asset inventory and network drawing | 100%, reviewed annually | Prerequisite for every other control |
| Conduits documented and enforced deny by default | Rising to 100% of Critical Cyber Systems | Shows segmentation is real, not on paper |
| Time to detect an unauthorised IT to OT connection (exercise) | Under 1 hour | Tests monitoring end to end |
| Facilities with a manual operation drill in the last 12 months | 100% | Resilience if SCADA or IT is lost |
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | IEC 62443 | API 1164 / TSA |
|---|---|---|---|---|
| Asset inventory | ID.AM-01 | CM-8 | 62443-2-1, 3-2 | CIP identification of Critical Cyber Systems |
| IT/OT segmentation | PR.IR-01 | SC-7, SC-7(5) | 62443-3-2 zones and conduits, 3-3 SR 5.1 | SD-02 segmentation outcome |
| Remote access and MFA | PR.AA-01, PR.AA-05 | AC-17, IA-2 | 62443-3-3 SR 1.1, SR 1.13 | SD-02 access control outcome |
| Monitoring | DE.CM-01 | SI-4 | 62443-3-3 SR 6.2 | SD-02 continuous monitoring outcome |
| Change and configuration control | PR.PS-01 | CM-3, CM-5 | 62443-2-1 | API 1164 programme requirements |
| Incident response and recovery | RS.MA-01, RC.RP-01 | IR-4, CP-10 | 62443-2-1 | CIRP tested annually |
| Supplier security | GV.SC-01 | SR-3 | 62443-4-1, 4-2, 2-4 | API 1164 supply chain protections |
For CIS Controls v8.1 the closest safeguards sit in Control 1 (asset inventory), Control 6 (access control management), Control 12 (network infrastructure management), Control 13 (network monitoring) and Control 17 (incident response). In ISO/IEC 27001:2022 Annex A the main controls are A.8.20 (networks security), A.8.22 (segregation of networks), A.8.32 (change management) and A.5.24 (incident management planning).
Common failure patterns
- Segmenting OT but ignoring business dependencies: controls protect SCADA, yet the operation still stops when billing or scheduling is encrypted, as at Colonial. Map and protect the IT systems that product movement depends on.
- Standing vendor access: always on VPN accounts for automation vendors, often shared across engineers, with no MFA or recording. Replace with brokered, approved, time limited sessions.
- Compliance plan without engineering: a TSA CIP or Coast Guard plan written by a compliance team without control engineers produces measures that cannot be implemented at remote sites. Build plans from facility risk assessments.
- Flat site networks at remote facilities: a cellular modem, an RTU and an HMI on one subnet with a public IP. Inventory and scan externally, then move telemetry to private networks.
- Turnaround drift: temporary contractor access, laptops and firewall exceptions added during a turnaround are never removed. Track every exception with an expiry date and review at turnaround close.
- SIS treated as part of the DCS: safety controllers on the same network and engineering workstation as the BPCS, so one compromise reaches both layers.
Practitioner checklist
- Map every facility to its regulatory regime and confirm the current TSA directive revision with your TSA contact.
- Maintain a per site asset inventory and an IT dependency map for product movement.
- Enforce MFA and brokered, recorded sessions on every remote access path into OT.
- Disable dormant, shared and standing third party accounts; review OT access quarterly.
- Run IEC 62443-3-2 risk assessments and document zones, conduits and target security levels.
- Place SIS, ESD and fire and gas systems in a dedicated safety zone.
- Deploy passive OT monitoring with SOC playbooks and a named authority for precautionary shutdowns.
- Test the incident response plan annually, including a manual operation drill.
- Write IEC 62443-4-1 / 4-2 and API 1164 requirements into supplier and EPC contracts.
- Close every turnaround and project with a review of temporary access and firewall exceptions.
Standards and references
- TSA: Security Directives and Emergency Amendments
- Federal Register: TSA Pipeline Corporate Security Reviews and Security Directive Pipeline-2021-02 series information collection
- Federal Register: Enhancing Surface Cyber Risk Management (proposed rule)
- Federal Register: Cybersecurity in the Marine Transportation System (US Coast Guard final rule)
- API: Standard 1164, Pipeline Control Systems Cybersecurity, 3rd Edition
- ISA: ISA/IEC 62443 Series of Standards
- DNV: Recommended practice on cyber security in the oil and gas industry based on IEC 62443
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · OT and ICS Identity and Access Guide · Top 10 OT Security Risks. This guide summarises the TSA Pipeline Security Directives, the US Coast Guard maritime cyber rule and NIS2 as they apply to oil and gas and is not legal advice.