TSA Security Directives for pipeline and surface transportation operators mandate network segmentation, multi-factor authentication, access controls, and continuous monitoring of OT systems. BlastShield addresses all four — without requiring hardware changes or production downtime.
Oil, Gas & Hazmat Pipelines
Freight & Passenger Rail
Transit & Bus Operations
TSA Security Directives are mandatory cybersecurity requirements issued by the Transportation Security Administration under its authority over transportation infrastructure. Unlike voluntary NIST frameworks, these carry real enforcement weight — operators who fail to implement required measures can face significant financial penalties and operational restrictions.
Before May 2021, TSA's approach to pipeline cybersecurity was advisory. The Colonial Pipeline ransomware attack changed that permanently. Within weeks, TSA issued Security Directive Pipeline-2021-01, followed by the more comprehensive -2021-02 series. Surface transportation directives followed as the administration extended mandatory requirements to freight rail, passenger rail, and transit operators.
The directives share a common set of mandatory cybersecurity measures focused on the same vulnerabilities that enabled Colonial Pipeline: weak access controls, flat OT networks with no segmentation, and absence of multi-factor authentication for OT system access. Each of these is precisely what BlastShield addresses.
A single compromised password granted DarkSide ransomware access to Colonial Pipeline's IT network. The company shut down 5,500 miles of pipeline preemptively, causing fuel shortages across the Eastern Seaboard and a $4.4 million ransom payment. The attack succeeded not because of a novel exploit, but because of absent MFA and no meaningful IT/OT segmentation. TSA's directives exist to ensure this cannot happen again.
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.
DarkSide ransomware attack causes 6-day pipeline shutdown. TSA issues SD-2021-01 within weeks, requiring designation of a Cybersecurity Coordinator and 24-hour incident reporting to CISA.
TSA issues the second, more substantive directive. Mandates specific technical cybersecurity measures for OT systems: network segmentation, access control, MFA, and monitoring. Sets deadline for Cybersecurity Implementation Plan submission.
TSA revises pipeline directives (02B, 02C, 02D) incorporating industry feedback while strengthening core OT requirements. TSA extends mandatory directives to freight rail, passenger rail, and transit operators through the 1580/82 series.
A single compromised password granted DarkSide ransomware access to Colonial Pipeline's IT network. The company shut down 5,500 miles of pipeline preemptively, causing fuel shortages across the Eastern Seaboard and a $4.4 million ransom payment. The attack succeeded not because of a novel exploit, but because of absent MFA and no meaningful IT/OT segmentation. TSA's directives exist to ensure this cannot happen again.
The table below maps the core technical cybersecurity measures required across TSA pipeline and surface transportation directives to specific BlastShield capabilities.
Requirement Area
What TSA Requires
How BlastShield Delivers
Applicable Directive(s)
Coverage
Network Segmentation
Segment OT Networks from IT and Business Networks
Implement network segmentation policies and controls to prevent unauthorized access to OT/ICS systems
BlastShield's software-defined segmentation creates cryptographically enforced boundaries between IT and OT networks — and between individual OT zones — without requiring physical network changes or production downtime. Policies are centrally managed via the Orchestrator. A compromised IT environment cannot traverse to pipeline control systems.
SD Pipeline-2021-02
SD 1580/82-2022-01
Full Coverage
Access Control
Implement Access Control Measures for OT Systems
Apply least-privilege access controls; limit who can access OT systems and from where
The BlastShield Orchestrator enforces least-privilege access at the device and application level. Each operator, engineer, or contractor accesses only the specific OT systems they are authorized for. Access is identity-bound — not network-location-bound — so contractors working remotely receive the same tight controls as on-site staff. All access events are logged with user identity and timestamp.
SD Pipeline-2021-02
SD 1580/82-2022-01
Full Coverage
Multi-Factor Authentication
Require MFA for OT/ICS System Access
Implement multi-factor authentication for all accounts accessing OT networks and critical systems
The BlastShield Authenticator provides phishing-resistant passwordless MFA for all OT access — combining biometric verification, a QR challenge-response protocol, and device keystore cryptography. There are no passwords to steal, no OTP codes to intercept. This goes beyond the MFA minimum the directives require and eliminates the credential theft vector that made Colonial Pipeline possible.
SD Pipeline-2021-02
SD 1580/82-2022-01
Full Coverage
Annex I §1(4)
Minimal Attack Surface
Products must minimize their attack surface, including external interfaces
BlastShield's core capability is attack surface reduction. Protected OT assets are invisible to unauthorized endpoints — they do not respond to pings, scans, or connection attempts from non-authenticated sources. There are no exposed management ports, no open services visible to the network. The attack surface is functionally zero for anyone outside the authenticated overlay.
Compensating Control
Compensating Control
Annex I §1(5)
Protection Against Unauthorized Access
Products must be designed to limit access to authorized users, processes, and services only
BlastShield enforces identity-based least-privilege access at every connection attempt. Users and devices must authenticate with phishing-resistant MFA before establishing any connection to an OT asset. Unauthorized parties cannot access what they cannot reach — and they cannot reach what is invisible.
Compensating Control
Compensating Control
Annex I §1(8)
Security Logging
Products must record security-relevant events; logs must be available for investigation
The BlastShield Orchestrator logs all access events — authentication attempts, successful connections, denied probes, session duration and termination — with full user identity and timestamp. For legacy OT assets with no native logging capability, BlastShield provides the security event record that CRA and NIS2 both require. Logs export via Syslog to enterprise SIEM platforms.
Full Coverage
Full Coverage
Annex I §1(9)
No Unauthorized Access Channels
Products must not contain undocumented access capabilities, functions, or backdoors
BlastShield's Software-Defined Perimeter ensures that all network access paths are explicitly defined, authenticated, and auditable. The Orchestrator maintains a complete, version-controlled record of all access policies. Any connection that has not been explicitly authorized through the policy system is structurally impossible — not just blocked by a rule that could be misconfigured.
Full Coverage
Full Coverage
Annex I §2
Vulnerability Handling
Manufacturers must identify vulnerabilities, distribute security updates, and coordinate disclosure
For OT operators, this requirement on product manufacturers creates supply chain risk management obligations under NIS2. BlastShield addresses this by controlling and auditing all manufacturer/vendor remote access — ensuring vendor maintenance sessions cannot be used to introduce new vulnerabilities or exfiltrate operational data. BlastAccess session recording provides evidence of authorized vendor activity.
Supply Chain Control
Supply Chain Control
Inventory Your OT Assets Against CRA Product Categories
Identify which OT components in your environment fall under CRA product categories — particularly Class II Important Products (industrial automation and control systems) and critical products. Document their current vulnerability status and whether any update path exists.
Deadline: Complete before Dec 2027 compliance date
Establish Compensating Controls for Legacy Assets
For assets that will never be CRA-compliant, implement and document compensating controls that achieve the security outcome the CRA requires. Network isolation, authenticated access boundaries, and encrypted communications satisfy regulatory due diligence — and BlastShield delivers all three without touching the legacy device.
Action: Deploy BlastShield before CRA reporting obligations begin Sep 2026
Tighten Vendor Remote Access Controls
CRA places vulnerability disclosure obligations on your OT equipment suppliers. But until their products achieve compliance, you must manage the risk of their remote maintenance access. Replace uncontrolled VPN access with BlastAccess: scope-limited, session-recorded, phishing-resistant maintenance channels.
Action: Audit all third-party OT access paths; migrate to BlastAccess
Update Procurement Requirements
As the CRA enforcement date approaches, update your OT equipment procurement specifications to require CRA conformity declarations from manufacturers. Prefer CE-marked products where available. Document exceptions with compensating controls for any non-compliant products that must still be purchased.
Deadline: Build into 2026 procurement cycles
Create a Security Event Log for OT Infrastructure
Both the CRA and NIS2 require access logging and incident reporting capabilities. Most legacy OT assets have no native logging. BlastShield provides the security event record for every OT asset it protects — authentication events, access grants, denied probes, and session data — exportable to SIEM for retention and analysis.
Action: Connect BlastShield logs to your SIEM before Sep 2026 reporting obligations
Coordinate with National Cybersecurity Authority
CRA enforcement runs through national market surveillance authorities. NIS2 incident reporting runs through national CSIRTs. Establishing early dialogue with your national authority, demonstrating a documented compensating control architecture, positions you favorably before mandatory reporting obligations begin.
Action: Prepare CRA gap assessment and compensating control documentation
The CRA and NIS2 are complementary, not redundant. The CRA focuses on the security of products with digital elements — the hardware and software that makes up OT infrastructure. NIS2 focuses on the security practices of the organizations that operate that infrastructure. Together they create a supply-side and demand-side security mandate for OT environments.
Under NIS2 Article 21(d), essential and important entities must address cybersecurity risks in their supply chain — which explicitly includes the security of products they procure. A NIS2-compliant operator must therefore have a view on which of their OT products are CRA-compliant (or on what timeline they will become so) and what compensating controls exist for those that are not.
BlastShield in the CRA/NIS2 Stack
→ For NIS2 Article 21(d): BlastShield controls and audits all third-party vendor access, demonstrating active supply chain risk management.
→ For NIS2 Article 21(f): BlastShield provides documented compensating controls for unpatchable OT assets with known CVEs.
→ For CRA Annex I: BlastShield compensates for legacy assets that cannot meet essential product security requirements by providing network-layer enforcement of those outcomes.
→ For both regimes: BlastShield's audit logs satisfy the security event recording requirements that both regulations require.
Our European compliance specialists help OT operators develop a defensible compensating control architecture that addresses both CRA and NIS2 — before enforcement deadlines arrive.
.svg)
Privacy Policy | Cookie Policy | © 2025 BlastWave, Inc. All Rights Reserved
This website uses cookies to ensure you get the best experience. More Info