TSA Security Directives require pipeline and surface transportation operators to segment OT from IT, control and authenticate access, monitor for threats, reduce the risk of unpatched systems, and prove annually that the whole programme works. BlastShield addresses parts of that directly, supports other parts, and produces the evidence for several more. This page says which is which, clause by clause, including what BlastShield does not cover.
Current as of: SD Pipeline-2021-02G, effective 3 May 2026 to 2 May 2027. SD 1580/82-2022-01D. Reviewed 18 August 2026.
Oil, Gas & Hazmat Pipelines
Freight & Passenger Rail
Transit & Bus Operations
BlastWave publishes compliance mappings. BlastWave is not certified or accredited to any regulatory framework, and no vendor product confers compliance on an operator. This page describes how BlastShield controls support specific required outcomes under the TSA Security Directives. It supports, but does not replace, an operator's own implementation plan, assessment plan, and formal determination by TSA.
TSA Security Directives are mandatory cybersecurity requirements issued under 49 U.S.C. § 114(l). Unlike voluntary NIST frameworks, they carry the force of federal law. Non-compliance can result in civil penalties, operational restrictions and public disclosure.
Before May 2021, TSA's approach to pipeline cybersecurity was advisory. The Colonial Pipeline ransomware attack ended that. TSA issued Security Directive Pipeline-2021-01 within weeks, followed by the more substantive 2021-02 series, and later extended mandatory requirements to freight rail, passenger rail and transit operators.
The important change came later, and most vendor material still misses it. The 2021-02 series began as a prescriptive mandate: a defined list of measures to implement. TSA has since revised it into a performance-based framework. Operators now document how they achieve required security outcomes, and TSA approves that plan. There is no longer a short list of boxes to tick.
That shifts what compliance costs. Standing controls up once is the easy half. Section III.G requires a Cybersecurity Assessment Plan, submitted annually to TSA, that assesses whether your implementation plan is effective. Section III.G.2.d sets the pace: at least one third of the policies, procedures, measures and capabilities in your approved plan must be assessed every year, and 100 percent over any three-year period. Section III.G.2.b adds a cybersecurity architecture design review at least once every two years, including verification and validation of network traffic and system log review.
So the useful question is no longer "are we segmented." It is "can we prove it, on the day it matters, to someone who does not work here."
A compromised password on a legacy VPN account with no multi-factor authentication gave DarkSide ransomware access to Colonial Pipeline's IT network. Colonial halted 5,500 miles of pipeline from 7 to 12 May 2021 and paid a ransom reported at $4.4 million.
Colonial's OT network was never compromised. The shutdown was precautionary, for two reasons: the business systems needed to bill for deliveries were down, and Colonial could not be certain the attack had not reached the control systems.
The second reason is the one TSA has been legislating against ever since. Operational disruption followed from an inability to prove the control network was clean, not from a breached PLC. That is why the current directive cares less about which products you bought than about whether you can show what your controls did.
Enforcement context: TSA Security Directives are issued under 49 U.S.C. § 114(l) and carry the force of federal law. Non-compliance can result in civil penalties, operational restrictions, and public disclosure. The directives are periodically updated — operators must track revisions and maintain ongoing compliance.
TSA issues its first mandatory pipeline cybersecurity directive within weeks of the attack, requiring designation of a Cybersecurity Coordinator and incident reporting to CISA.
The second and more substantive directive mandates specific technical measures for OT systems and sets a deadline for Cybersecurity Implementation Plan submission.
TSA revises the pipeline directives incorporating industry feedback, and extends mandatory requirements to freight rail, passenger rail and transit operators through the 1580 and 1582 series.
TSA restructures the series away from prescriptive measures toward required security outcomes, giving operators flexibility in how they meet them and adding the annual assessment and reporting cycle.
The current directive runs 3 May 2026 to 2 May 2027. A separate rulemaking that would convert the directives into permanent regulation was proposed in November 2024 and has not been finalised.
Clause references below are to SD Pipeline-2021-02G. The rail directives in the 1580 and 1582 series are structurally parallel but numbered differently, so confirm the equivalent clause before relying on this table for a rail environment.
Clause
What TSA Requires
How BlastShield Delivers
Coverage
III.B.2.a
Controls preventing unauthorized communications between zones
Software-defined segmentation creates cryptographically enforced boundaries between IT and OT and between individual OT zones, without physical network changes or production downtime. A compromised IT environment cannot traverse to control systems
Directly addresses
III.B.2.b
OT services may not traverse the IT system unless content is encrypted in transit
OT traffic crossing the BlastShield boundary is carried in encrypted peer-to-peer tunnels. Encryption is a property of the transport, not an option that can be left off
Directly addresses
III.B.1
Document IT and OT interdependencies, all external connections, and zone boundaries organized by criticality
The policy configuration defines zones and permitted paths, and is exportable. BlastShield does not produce network or architecture diagrams, so your existing documentation still carries that part
Supports
III.C.2
Multi-factor authentication, or controls providing commensurate risk mitigation
The BlastShield Authenticator provides phishing-resistant passwordless MFA: biometric verification, QR challenge-response, and device keystore cryptography. No password to steal, no one-time code to intercept
Directly addresses
III.C.1.b
Documented mitigations for components that will not have passwords reset on schedule, plus a timeframe
This is the clause for legacy assets that cannot take a password policy. Passwordless access is the mitigation, because it removes the credential rather than managing it
Directly addresses
III.C.3
Manage access rights on least privilege and separation of duties. Where not technically feasible, describe compensating controls
Least privilege is enforced at device and application level, identity-bound rather than network-location-bound, so a remote contractor gets the same tight controls as on-site staff. Separation of duties on policy change is not enforced in product, see the assessor questions below. This clause expressly allows compensating controls to be described
Supports
III.C.4
Limit shared accounts. Individuals who no longer need access must not retain knowledge of the shared password
Where there is no password, there is no residual password knowledge to manage. Shared account policy remains yours
Supports
III.C.5
Schedule for review of domain trust relationships
Not addressed
Out of scope
Vendor access
III.C.3, III.F
Third-party remote access to OT must be authenticated, controlled and auditable
BlastAccess provides a dedicated vendor channel with session recording, identity-bound authentication, time-limited grants and scope-limited access. Vendors reach only the specific system they are authorized for. Access is revocable immediately from the Orchestrator, and session recordings are forensic evidence for audits
Directly addresses
III.D.1
Capabilities against malicious email, malicious IP addresses, malicious web domains, unauthorized code execution, and command and control traffic
BlastShield does not do this. It requires email security, web filtering, and endpoint and network detection tooling
Out of scope
III.D.2.b
Document and audit communications between OT and an external system that deviate from the identified baseline
Permitted paths are the baseline, expressed as policy. Denied-attempt logs are the deviation record
Provides evidence for
III.D.3.b
Log data maintained for sufficient periods to allow effective investigation
Retention is configurable, so it can be set to match your investigation and assessment window
Supports
III.D.4
Mitigation measures or manual controls so ICS can be isolated when an IT incident creates risk to OT safety and reliability
Isolation by policy change, without physical re-cabling or VLAN work. The change is logged and takes effect immediately
Directly addresses
III.E.3
Where patches cannot be applied without severe degradation of operational capability, describe additional mitigations and a timeline
This is the clause that contemplates compensating controls for unpatchable assets. Network cloaking means the asset does not answer an unauthorized scan. A side-by-side port scan produces the dated artifact an assessor can verify. You still need your own asset inventory and firmware tracking under III.E.1
Directly addresses
III.F.1.d
Established capability and governance for isolating IT and OT systems during an incident that could cause operational disruption
The capability is the product: sessions terminate instantly, policies change in real time, affected segments isolate without touching unaffected operations. The governance is yours. Change logs evidence that isolation was exercised
Directly addresses
III.G.2.b
Architecture design review at least every two years, including verification and validation of network traffic and system log review
Access and enforcement logs are the reviewable material. The review itself is yours, and the architecture diagrams it expects come from elsewhere
Provides evidence for
III.G.2.d
At least one third of the approved plan assessed annually, 100 percent over three years
Exportable policy configuration and retained logs are the assessable material for the segmentation and access-control portion of your plan
Provides evidence for
IV.C.2.e
On request, produce log files and snapshots of East-West OT traffic and North-South IT to OT traffic
The Orchestrator logs both permitted and denied access attempts, with identity and timestamp. Export runs over API, syslog, local storage or FTP in CSV format. This clause names the artifact class directly
Provides evidence for
IV.C.2.c
On request, produce network diagrams, switch and router configurations, architecture diagrams and VLANs
BlastShield does not produce topology or architecture diagrams. Your existing network documentation carries this
Out of scope
BlastShield directly addresses seven clauses, supports four, and produces evidence for four. Three are entirely yours. Any vendor claiming to cover Section III end to end is describing a product that does not exist, and Section III.D.1 alone will catch them.
The technical requirements in TSA directives are straightforward on paper. In practice, three obstacles make them difficult for critical infrastructure operators to implement.
Compressor stations, SCADA systems, and rail control systems often run on hardware and software from the 1990s and 2000s. These systems cannot support modern authentication protocols, cannot be patched, and cannot be taken offline for upgrades. Any compliance solution must protect them as-is.
BlastShield: Gateway-based protection requires no changes to the protected asset
A pipeline system may have hundreds of unmanned compressor stations, pump stations, and measurement sites spread across thousands of miles. A rail network may have thousands of control assets across an entire continent. Physical site visits for security changes are operationally impossible.
BlastShield: Software-only deployment; remote configuration through the Orchestrator
TSA directives require segmenting IT and OT networks — but in many pipeline and rail environments, these networks have been integrated for years and share infrastructure. Implementing a hard boundary without disrupting operations requires a solution that works within the existing architecture.
BlastShield: Software overlay on existing infrastructure; no IP changes or network redesign
TSA directives set specific deadlines for CIP submission and implementation. Traditional OT security projects involving firewall redesign, network segmentation hardware, and physical site work often run into years. That timeline doesn't fit a regulatory mandate.
BlastShield: Deployable in hours at each site; no hardware shipping or physical installation
Pipeline OT environments present a unique set of security challenges. Compressor and pump stations are typically unmanned. Control systems run proprietary industrial protocols. SCADA systems monitor conditions across thousands of miles from a central control room. Maintenance access is frequently provided by OEM vendors who need to connect remotely to troubleshoot proprietary equipment.
BlastShield's architecture maps directly to this reality. The BlastShield Security Gateway can be deployed at each compressor station site — either as a VM on existing infrastructure or as a certified hardware appliance — without requiring any changes to the SCADA or PLC systems it protects. From that point, every access to the site's OT systems must pass through BlastShield authentication and policy enforcement.
Remote operator access is handled through BlastShield's secure remote access solution. SCADA engineers connect from their laptops, authenticate with the BlastShield Authenticator, and gain access only to the specific site systems their role permits — with session recording capturing every interaction for compliance documentation.
Third-party vendor access: The leading concern for pipeline operators implementing TSA directives is controlling vendor remote access. OEM engineers from Emerson, Honeywell, Siemens, and other ICS vendors need remote access to proprietary systems — but conventional remote access tools (VPNs, RDP, jump boxes) grant far too much access. BlastAccess gives vendors a dedicated, audited, scope-limited session to the specific device they're maintaining, and nothing else.
Compensating controls for unpatchable systems: Many pipeline SCADA components cannot be patched on any reasonable timeline. TSA directives recognize the need for compensating controls (2026, Section III.E.3). BlastShield's Network Cloaking and microsegmentation serve as documented, defensible compensating controls: the vulnerable system exists, but it is not reachable by any unauthorized party.
Clause references below are to SD Pipeline-2021-02G. The rail directives in the 1580 and 1582 series are structurally parallel but numbered differently, so confirm the equivalent clause before relying on this table for a rail environment.
Clause
What TSA Requires
Where is the boundary, and what enforces it?
Per identity and per asset rather than per network segment. Enforcement happens at the BlastShield Gateway and Agent, with policy distributed from the Orchestrator. No ACL or VLAN dependency, so the boundary does not move when the network is re-addressed
Is OT traffic protected when it crosses the IT network?
Yes. OT traffic crossing the BlastShield boundary is carried in encrypted peer-to-peer tunnels, which is what satisfies Section III.B.2.b
Who administers policy, and how are changes reviewed?
The Orchestrator, on-premises or cloud. Change rights are governed by the permission model. There is no staged approval workflow. If a user's permissions allow a policy change, it takes effect immediately. Review is after the fact through the configuration change log. Section III.C.3 requires separation of duties and expressly allows compensating controls to be described where the principle is not technically feasible, which is where your permission model and change management procedure belong. We would rather tell you this now than have your assessor find it
What evidence exists that the control was operating, not just installed?
Access attempts are logged whether permitted or denied, so the record shows the control acting rather than merely present. Configuration changes are logged separately. BlastAccess sessions are recorded in full. Retention is configurable and export runs over API, syslog, local storage or CSV
What happens when the control fails?
With cloaking active, BlastShield fails closed. Protected assets stop answering, which is deliberate, because a security control that fails open has stopped being a control. Availability is addressed by deploying redundant Gateways, and already-established sessions are retained through failover, so an operator working in a live session is not dropped. Orchestrator failure is a different case and is not a traffic event: if the Orchestrator becomes unreachable, the Gateway keeps enforcing the policy already configured. The Orchestrator can itself be redundant, on-site, in the cloud, or both
How is the control tested?
A twenty-minute side-by-side port scan, unprotected against protected. It produces a dated artifact for Section III.G.2.c, and it is the fastest way to establish whether the control does what this page says it does
Our OT security engineers work with pipeline and transportation operators on the segmentation, access control and evidence portions of their Cybersecurity Implementation Plans. Book a 30-minute session to walk your environment against the clauses on this page, or ask for the twenty-minute side-by-side scan and see the artifact for yourself.
Our Privacy Policy applies.
.svg)
Privacy Policy | Cookie Policy | © 2026 BlastWave, Inc. All Rights Reserved
This website uses cookies to ensure you get the best experience. More Info