The TSA pipeline security directives legally require roughly 100 designated critical pipeline operators to name a 24/7 cybersecurity coordinator, report incidents to CISA within 12 hours, and run a TSA-approved Cybersecurity Implementation Plan covering network segmentation, access control, continuous monitoring, and risk-based patching. They were born in May 2021, when a ransomware incident shut down the country's largest refined-products pipeline for days and fuel lines formed on the East Coast. Five years and several revisions later, the directives have matured into a performance-based regime built around operator-written implementation plans, incident reporting to CISA, and continuous assessment. This guide explains who is covered, exactly what each directive requires, how the requirements evolved, and the practical steps - including what they mean for your SCADA platform choice.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
TSA has held statutory authority over pipeline security since 2001 - a historical quirk of post-9/11 legislation that put pipelines under the transportation security umbrella rather than the energy regulators. For two decades it exercised that authority gently, publishing voluntary pipeline security guidelines and running collaborative reviews. The Colonial Pipeline ransomware incident of May 2021 - the DarkSide ransomware attack documented in CISA advisory AA21-131A - ended that era. The attack hit the operator's IT systems, but the company shut down pipeline operations as a precaution, and the resulting fuel disruption made pipeline cyber risk a national headline. TSA issued Security Directive Pipeline-2021-01 within weeks, followed by the more demanding Pipeline-2021-02 series that July.
The lesson buried in that history matters for SCADA buyers: the event that triggered mandatory regulation was not an exotic OT exploit - it was an IT compromise that the operator could not confidently contain away from operations. The directives are, at their core, an attempt to make sure every critical pipeline can answer the question Colonial faced: can your OT keep running safely when your IT is on fire? We look at the incident itself, alongside four others, in our industrial cyberattack case studies.
The directives apply to owners and operators of hazardous liquid and natural gas pipeline systems and facilities that TSA has designated as critical. Public reporting has put the covered population at roughly 100 companies - the operators of the pipeline infrastructure the country most depends on. TSA notifies designated operators directly; there is no self-assessment test to run. If you have not received notification, you are not currently bound.
Three caveats before anyone relaxes:
The first directive, renewed annually since 2021, establishes three baseline duties for covered operators:
These sound administrative, but the 12-hour reporting clock has real operational teeth. It presumes you can detect incidents, escalate them internally, and characterize them well enough to report - within half a day, around the clock. Operators whose SCADA platforms provide runtime threat detection and deliver security alerts to the people on call are simply in a different position than operators who would learn about an intrusion from a system outage.
The second directive is where the substance lives, and its history is a case study in regulating OT. The original July 2021 version prescribed specific technical measures on fixed timelines - patching windows, password rules, and IT-style controls that, applied literally to control systems, could have forced operators to choose between compliance and safe operations. Industry pushback was loud and, in fairness, largely correct.
TSA listened. The July 2022 revision (SD Pipeline-2021-02C) rebuilt the directive around performance-based outcomes: operators define how they will achieve required security results in a plan TSA approves, rather than following a fixed checklist. The subsequent revision (02D, 2023) kept that architecture and strengthened the assessment obligations. The contrast is worth seeing side by side:
| Aspect | Original SD-02 (2021) | Revised SD-02C/02D (2022–) |
|---|---|---|
| Approach | Prescriptive - specific measures and deadlines for all | Performance-based - operator-written, TSA-approved plan |
| OT fit | IT-centric assumptions; patching timelines hard to meet safely in OT | Risk-based patching; compensating controls acceptable where justified |
| Accountability document | The directive text itself | The operator's Cybersecurity Implementation Plan |
| Verification | Attestation of compliance | Cybersecurity Assessment Program: annual plan, rolling testing of measures, results to TSA |
| Incident response | Required contingency planning | Maintained Cybersecurity Incident Response Plan with annually exercised objectives |
The approved plan must show how the operator achieves outcomes in four areas. Each maps directly onto capabilities you should be evaluating in any SCADA platform:
1. Network segmentation. OT systems must be able to operate safely even if IT systems are compromised - the Colonial question, made policy. In practice this means defined IT/OT boundaries, controlled conduits between zones, and honest answers about every path into the control network. Architectures where the SCADA platform's field connectivity is outbound-only - no inbound firewall rules, no VPN concentrator bridging IT into OT - make this section of the plan dramatically easier to write and defend. Our guide to securing SCADA on OT networks covers the architecture in depth.
2. Access control. The plan must cover how access to critical systems is granted, authenticated, and revoked - including multi-factor authentication, shared-account elimination, and privilege management. For SCADA specifically, look for MFA on every account, granular roles that govern control actions rather than just screen visibility, session expiry and revocation, and step-up authentication for the highest-risk operations.
3. Continuous monitoring and detection. Operators must have defined policies and capabilities to detect cybersecurity threats affecting their critical systems. That implies audit logging you can actually query, detection of anomalies like repeated authentication failures or unexpected control activity, and delivery of security events to the people and systems that watch for them - including SIEM export if you run one.
4. Risk-based patching and updates. The plan must describe how operating systems, applications, drivers, and firmware are kept current - with a risk-based methodology that acknowledges OT reality and documents compensating controls where immediate patching is not safe. A cloud SCADA platform shifts a meaningful slice of this burden to the vendor, who patches the platform continuously; your plan then covers the gateway and field devices, a much smaller surface.
Approval of the plan is the beginning, not the end. Covered operators must run a Cybersecurity Assessment Program: an assessment plan submitted to TSA annually, proactive testing of the measures in the implementation plan on a rolling schedule that covers everything over a multi-year cycle, and annual reporting of results. The incident response plan cannot sit on a shelf either - operators must exercise its objectives annually with the personnel who would actually respond. Add the standing 12-hour CISA reporting duty from SD-01, and the regime adds up to something closer to continuous compliance than annual audit.
The operational consequence: evidence generation has to be a byproduct of normal operations. If gathering access records, audit trails, and detection logs for your annual assessment takes a month of manual effort, the program will decay. This is where platform choice shows up again - a SCADA system that maintains immutable audit records and security event history produces your assessment evidence as a side effect of running.
The directives never name a technology, but they quietly reshape SCADA buying criteria. A platform helps you comply when segmentation, access control, monitoring, and patching are properties of its architecture rather than projects for your team. Merobix was designed on that basis: the gateway makes outbound-only TLS connections so no inbound rules or VPN paths cross your OT boundary; TOTP and passkey MFA, granular roles, session revocation, and step-up authentication for high-risk actions cover the access pillar; runtime threat detection, tamper-evident audit records, and security event delivery to email, SMS, webhooks, or your SIEM cover monitoring; and the cloud platform is patched continuously by the vendor, shrinking your patch scope to the edge. Merobix also maps its controls to IEC 62443 and runs a SOC 2 readiness program, with independent penetration testing part of its ongoing validation program - the details are on the security page, and you can pressure-test the architecture against your draft implementation plan in a guided demo.
Key takeaway: the TSA directives ask one question four ways - can you keep operating safely, and prove it, when something goes wrong? Segmentation answers it architecturally, access control answers it for people, monitoring answers it for detection, and the assessment program answers it on paper. Build your plan around honest answers, choose vendors whose architecture makes those answers short, and the annual obligations become routine instead of a scramble.
The directives apply to owners and operators of hazardous liquid and natural gas pipeline systems and facilities that TSA has designated as critical - reported at roughly 100 companies covering the most important US pipeline infrastructure. TSA notifies covered operators directly, so if you have not been notified, the directives do not bind you today. That said, TSA has signaled through rulemaking that it intends to codify similar requirements more broadly, and non-covered operators are well advised to treat the directive requirements as the de facto standard of care.
The Cybersecurity Implementation Plan is an operator-written, TSA-approved document describing how the operator meets the directive's performance-based outcomes in four areas: network segmentation policies that let OT operate safely even if IT is compromised, access control measures including multi-factor authentication, continuous monitoring and detection of cybersecurity threats, and risk-based patching of operating systems, applications, drivers, and firmware. Once TSA approves the plan, the operator is accountable for doing what the plan says - and for assessing that it does, on a defined schedule.
Under the SD Pipeline-2021-01 series, covered operators must report cybersecurity incidents to CISA within 12 hours of identification. This applies to incidents on both IT and OT systems, which is why event visibility across your SCADA environment matters: you cannot report what you cannot see. Operators should maintain a tested internal escalation path so that the people who detect an event can reach the cybersecurity coordinator, and the coordinator can reach CISA, comfortably inside the window.
Yes. The directives are performance-based and do not prohibit cloud-hosted SCADA or monitoring platforms. What they require is that the outcomes hold regardless of hosting model: OT must be able to operate safely if IT systems are compromised, access must be controlled with MFA, systems must be monitored, and vulnerabilities must be managed. A cloud platform with an outbound-only gateway can actually simplify the segmentation story, because it removes inbound firewall rules and VPN paths into the OT network - but you must still document the architecture in your implementation plan.
The directives are legally enforceable under TSA's statutory security authority. TSA can inspect covered operators, require corrective action, and pursue civil penalties for non-compliance, and the reputational and commercial consequences - with insurers, customers, and partners - tend to arrive faster than the formal ones. In practice TSA has emphasized working with operators on approvable plans, but treating the directives as optional is a mistake: they are regulatory obligations, not guidance.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Outbound-only segmentation, MFA and roles on every account, continuous monitoring, and audit evidence generated as a byproduct of operations.