TSA Security Directives and MFA: What Pipeline and Rail Operators Must Implement

Colonial Pipeline changed how the federal government regulates transportation-sector cybersecurity. Within months, TSA issued mandatory Security Directives for critical pipeline operators, then extended the model to freight and passenger rail. Several revisions later, the requirements are performance-based, actively inspected, and unusually direct about multi-factor authentication.

For operators, the practical question is not whether MFA is a good idea. It is where the directive-controlled access paths still depend on passwords, shared accounts, legacy portals, vendor access, or web applications around the OT boundary that cannot do MFA natively.

The current state: directives now, permanent rule later

The active TSA directive regime applies to designated critical pipeline and LNG operators and to designated freight, passenger rail, and rail transit owner/operators. TSA and CISA materials describe a common set of cybersecurity outcomes: network segmentation, access-control measures, continuous monitoring, incident reporting, risk-based patching, testing, and documentation.

MFA matters because the directives and related implementation-plan process treat remote access and critical cyber systems as inspected control points. Where the directives allow compensating controls, operators still need to justify those controls in the plan TSA reviews.

The permanent rule is still pending. TSA published the Enhancing Surface Cyber Risk Management NPRM in November 2024, comments closed in February 2025, and the official rule timetable still lists the final rule date as to be determined. Operators should plan against the directives in force today and expect the permanent rule to preserve the access-control substance.

How the requirement actually bites: your own implementation plan

The distinctive mechanism is the Cybersecurity Implementation Plan. Each covered operator documents the specific measures it will take, TSA reviews the plan, and the approved plan becomes the standard the operator is assessed against.

That structure changes the MFA conversation. Once a plan commits to MFA for remote access to critical cyber systems, a gap is no longer a general best-practice issue. It is a variance from a federally reviewed plan, surfaced through annual assessment work or a TSA inspection.

Where MFA gaps concentrate

The modern corporate IT estate is usually easier to cover because it already sits behind Microsoft Entra ID, Okta, Ping, Duo, or another identity stack. The harder findings often appear around web-facing or OT-adjacent applications that were never built for modern identity.

• Historian, SCADA, telemetry, or operations dashboards accessed remotely.
• EAM and maintenance systems where work orders, inspections, and asset data live.
• Pipeline, terminal, rail, dispatch, supplier, contractor, or vendor portals.
• Custom web applications that sit between IT and OT but cannot be changed quickly.

These systems are usually the ones with the least appetite for code changes. Vendor ownership, validation requirements, safety change control, and operational uptime all make a rewrite unrealistic before an assessment date.

Closing the gap without touching the systems

Datawiza Access Proxy enforces MFA at the access layer, in front of the web application, without changing application code or installing plugins inside the application.

• Remote access and web apps: Datawiza detects the login request before the application is reached, authenticates the user, and enforces MFA or 2FA before access is allowed.
• IdP or built-in MFA: Use your existing IdP, such as Microsoft Entra ID, Okta, Ping, or Cisco Duo, or use Datawiza built-in MFA for contractors, vendors, operations users, or other populations that do not sit cleanly inside the corporate IdP.
• Segmented network deployment: Deploy the proxy in customer-controlled network zones and validate the exact placement for segmented, hybrid, or disconnected environments during architecture review.
• Assessment evidence: Collect per-application configuration, screenshots or demos of the MFA challenge, user and group assignments, and logs showing allowed and denied access decisions.

That access-layer pattern is useful when the application is important enough to fall into the plan, but too fragile or vendor-controlled to modify quickly. For a broader cross-framework view, see the MFA compliance requirements hub.

Frequently asked questions

Do TSA Security Directives require MFA?

Yes. The pipeline and rail directive regime requires access-control measures for critical cyber systems and remote-access paths, including MFA or justified compensating measures where the directive and approved implementation plan allow them.

Who is covered by the TSA cybersecurity directives?

TSA-designated critical pipeline and LNG owners/operators are covered by the pipeline directives. Designated freight, passenger rail, and rail transit operators are covered by the rail and public-transportation directive series.

What happens if an operator does not comply?

TSA inspects against the operator's approved implementation plan and required assessment documentation. Gaps can lead to remediation pressure, inspection findings, and civil-penalty exposure under TSA's enforcement authority.

How do legacy OT-adjacent web applications meet the MFA requirement?

The fastest pattern is access-layer enforcement: put MFA in front of the application, prevent direct bypass, integrate with the corporate IdP where useful, use built-in MFA where an IdP does not cover the population, and keep per-application logs for assessment evidence.

Is the TSA requirement the same as NERC CIP?

No. TSA covers covered pipeline, LNG, rail, and surface transportation operators, while NERC CIP covers the bulk electric system. Some energy organizations may answer to both. The common access-control problem is similar: legacy or OT-adjacent web applications need MFA evidence even when the application itself cannot provide MFA.

Sources checked

• Office of Information and Regulatory Affairs rule timetable for RIN 1652-AA74.
• Federal Register proposed rule: Enhancing Surface Cyber Risk Management.
• Federal Register 2026 TSA cybersecurity information-collection notice.
• GAO testimony on surface transportation cybersecurity oversight.

The bottom line

TSA's directive model is direct: access controls are inspected, operator plans matter, annual assessment work surfaces gaps, and the permanent rule is expected to build on the same foundation. The systems most likely to slip are the web applications around the OT boundary. Enforcing MFA at the access layer is how teams close that gap without waiting for every application to support modern identity natively.

Book a demo and bring your implementation plan's access-control section plus the application list behind it. We will map the requirement to the fastest path for each app.