Colonial Pipeline shut down its entire 5,500-mile fuel network on May 7, 2021, after a single compromised VPN password let ransomware operators into its billing systems. Within three weeks, the Transportation Security Administration — an agency better known for airport checkpoints than industrial control systems — became the primary cybersecurity regulator for the U.S. pipeline industry. The result is a stack of security directives that now dictate patch timelines, network segmentation, and software risk management for every critical pipeline owner and operator in the country. For teams trying to understand the TSA pipeline cybersecurity directive software requirements, the details matter: they determine what your vendors must prove, what your SBOMs need to contain, and how fast you have to respond when a CVE lands in a system that moves fuel, oil, or gas. This piece breaks down what the directives actually require and where software supply chain security fits in.
What Is the TSA Pipeline Cybersecurity Directive and Why Does It Exist?
It exists because a ransomware attack on a billing system, not the operational technology itself, was enough to stop fuel from reaching the East Coast. TSA issued Security Directive Pipeline-2021-01 on May 28, 2021, requiring critical pipeline owners to report cybersecurity incidents to CISA within 12 hours of discovery and designate a 24/7 cybersecurity coordinator. A second directive, SD Pipeline-2021-02, followed in July 2021 with prescriptive technical controls: network segmentation between IT and OT environments, access control measures, patching against known exploited vulnerabilities, and a TSA-approved Cybersecurity Implementation Plan. TSA revised the approach again in 2022 (SD-02C) and 2023 (SD-02D), shifting toward a performance-based model that still mandates specific outcomes — continuous monitoring, incident response testing, and annual architecture reviews — while giving operators more flexibility in how they achieve them. The directives apply to pipeline systems TSA has designated as "critical," a list built from throughput volume, service to major population centers, and connections to other critical infrastructure.
What Are the TSA Pipeline Cybersecurity Directive Software Requirements?
The software-specific requirements center on three things: knowing what you're running, patching what's known to be exploitable, and proving both to an auditor. Operators must maintain an architecture diagram covering all Critical Cyber Systems, apply security patches and updates for vulnerabilities on CISA's Known Exploited Vulnerabilities (KEV) catalog "in a timely manner" based on risk, and validate that patching through their Cybersecurity Implementation Plan. In practice, TSA inspectors expect documented evidence — patch logs, vulnerability scan results, and change records — not verbal assurances. Because most pipeline control software is assembled from commercial and open-source components rather than built entirely in-house, "knowing what you're running" increasingly means maintaining a software bill of materials (SBOM) for control system software, historian platforms, and the engineering workstations that touch them. Operators who can't produce an SBOM on request have no reliable way to answer TSA's core question during an inspection: is this specific system affected by the KEV entry that dropped last week, yes or no. That gap is exactly where a lot of pipeline security directive compliance programs currently fall short — they can show a patching policy on paper but can't map a live CVE to the software actually deployed across dozens of compressor stations and pump sites within the 12-to-72-hour windows examiners now expect for high-severity findings.
Who Counts as an Oil and Gas Software Vendor Under the Directive?
Any company that supplies software touching a designated critical pipeline's operational or IT environment counts, even if TSA never inspects the vendor directly. SCADA and DCS vendors, historian and analytics platforms, remote access and VPN providers, and even scheduling or billing software fall in scope because the directive's incident reporting and access-control requirements follow the data and the connections, not the org chart. This creates real oil and gas software vendor risk: pipeline operators, facing direct TSA liability, are pushing compliance obligations downstream through contracts. Vendors are increasingly asked to provide SBOMs at delivery, attest to secure development practices, disclose known vulnerabilities within fixed timeframes, and support the operator's 12-hour incident reporting clock by notifying customers the moment a security issue is confirmed. A vendor that can't produce this documentation quickly is becoming a disqualifying risk in RFPs for pipeline control and monitoring software, regardless of how good the product itself is. The Colonial Pipeline incident itself illustrates the stakes: the attack didn't touch OT, but it originated in an under-secured IT credential, which is exactly the kind of vendor-adjacent weak point the directives now target.
How Does Pipeline Security Directive Compliance Differ From Other Critical Infrastructure Rules?
It differs mainly in enforcement mechanism: TSA directives are mandatory conditions of operation backed by civil penalties, not voluntary frameworks like the NIST Cybersecurity Framework that many other sectors still rely on. Where a framework like NIST CSF or the TSA's own earlier pipeline security guidelines (pre-2021) offered recommended practices, the current directives function more like FAA airworthiness directives — non-negotiable, deadline-bound, and subject to direct inspection with fines for noncompliance. This puts pipeline operators in a similar posture to the electric sector under NERC CIP, but with less regulatory maturity and fewer established audit norms, since TSA only became a serious cybersecurity enforcer in 2021. It also means pipeline requirements are evolving faster than comparable rules for other critical infrastructure security directive regimes covering rail and aviation, which TSA has modeled closely on the pipeline approach but staggered a year or two behind. Operators managing multiple types of infrastructure — a common situation for large energy conglomerates — are now tracking several overlapping but not identical directive regimes, each with its own patching windows, reporting thresholds, and documentation formats, which is pushing many toward a single internal software risk system that can generate whatever evidence a given regulator asks for.
What Happens If a Pipeline Operator or Vendor Fails to Comply?
Noncompliance can trigger civil penalties from TSA, but the more immediate cost is usually operational: failing an inspection can mean a remediation order with a fixed deadline, increased inspection frequency, and reputational exposure if the finding becomes public through a subsequent incident. TSA has statutory authority to levy fines that historically ran up to roughly $13,000 per violation per day before recent increases, and multi-week remediation failures compound quickly across large pipeline networks with dozens of designated critical systems. For vendors, the consequence is contractual rather than regulatory — losing the account when an operator's compliance team flags an unpatched CVE or a missing SBOM during a routine security review. The 2021 directives were themselves issued under emergency authority specifically because TSA judged that voluntary compliance had failed to keep pace with the threat, which signals how little patience the agency has left for organizations treating this as optional guidance rather than an operating requirement.
How Safeguard Helps
Safeguard was built for exactly this gap between what TSA's software requirements demand and what most pipeline operators and their vendors can currently produce on short notice. Safeguard continuously generates and maintains SBOMs across control system software, IT platforms, and vendor-supplied components, so when a new KEV entry appears, you get an immediate, evidence-backed answer about exposure across every deployed system rather than a multi-day manual audit. That mapping feeds directly into the patch validation and vulnerability management documentation TSA inspectors expect under the Cybersecurity Implementation Plan, and it gives vendors a fast, defensible way to respond to operator due-diligence requests instead of scrambling to reconstruct a component inventory from scratch. For operators managing pipeline security directive compliance alongside other critical infrastructure security directive obligations, Safeguard consolidates that evidence into one system instead of a separate spreadsheet per regulator. And because oil and gas software vendor risk is now a contractual gate as much as a technical one, Safeguard helps vendors get ahead of it — producing the SBOMs, vulnerability disclosures, and secure-development attestations that pipeline customers are starting to require before they'll sign. Talk to Safeguard about mapping your current software supply chain visibility against TSA's directive requirements before your next inspection window.