Rail and transit software supply chain security: a 90-day plan

Railroads and transit agencies secure their software supply chain by doing four things in order: list every piece of software inside their Critical Cyber Systems (train control, signalling, dispatch, traction power SCADA and the business systems that can stop trains), get a component inventory (an SBOM) and an advisory feed from each signalling, rolling stock and fare system vendor, rank patches with CISA's Known Exploited Vulnerabilities catalog as the TSA directive requires, and write down the extra mitigations for train control and wayside systems that cannot be patched on a normal schedule. In the United States the binding text is TSA Security Directive 1580/82-2022-01E (in force from 3 May 2026 to 2 May 2027) plus the 1580-21-01 and 1582-21-01 series for freight, passenger rail and rail transit, with a TSA rule proposed in 2024 that would make the requirements permanent and add explicit supplier notice terms.

This guide is for the people at a freight railroad, passenger railroad or rail transit agency who carry that work, from the CISO and the signals engineering lead to the TSA Cybersecurity Coordinator, procurement and the fare systems owner. The first two thirds work with whatever tools you already run. Safeguard enters at "How Safeguard does this". Nothing here is legal or regulatory advice; your TSA-approved plan and your counsel decide what applies to you.

Key takeaways

• The binding text for patching is TSA SD 1580/82-2022-01E. Section III.E requires a risk based patch strategy for Critical Cyber Systems, priority for everything on CISA's KEV catalog, and documented mitigations with a timeline where an OT system cannot be patched without severe degradation.
• Positive Train Control is named. Railroads that run PTC under 49 CFR part 236 must include PTC systems as a Critical Cyber System (Section III.A.2).
• Passenger rail and transit have their own reporting directive. SD 1582-21-01E (16 January 2026 to 15 January 2027) requires a 24/7 Cybersecurity Coordinator, incident reports to CISA within 72 hours, an incident response plan and a vulnerability assessment. SD 1580-21-01E does the same for freight.
• Software inventory is inspectable. TSA may ask to inspect a hardware and software asset inventory, including SCADA systems (Section IV.C.2.a). SBOMs keep the software half of it true.
• Contractors do not move the duty. A railroad that shares a measure with a managed security provider keeps sole responsibility (Section II.A.2).
• The rule is still proposed. TSA's Enhancing Surface Cyber Risk Management proposal (7 November 2024) is not final. Its proposed 1580.315 and 1582.215 supplier notice clauses are a model for contracts, not law.
• Safeguard capabilities used in this guide are all generally available (GA): the compliance and GRC suite, SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, TPRM, CSAF and VEX upload, policies and gates, the CLI and local runner, air-gapped deployment, Zero AI mode, and autonomous remediation (which ships switched off).

What software a railroad or transit agency runs

A railroad is a long, thin industrial plant that runs through public space. Its software spans safety related control, enterprise IT and a large public facing estate. Most of it is bought, and most of what is bought arrives as a closed box with open source inside.

• Train control and signalling. Positive Train Control on US freight and commuter lines combines onboard computers, wayside interface units at signals and switches, a back office server and a radio network. Rail transit runs communications based train control (CBTC) or fixed block systems with automatic train protection. Interlockings are increasingly computer based, running supplier software on industrial hardware with maintenance laptops and configuration tools.
• Dispatch and traffic management. Computer aided dispatch, rail operations control centers, movement authority servers, timetable and crew management, and the middleware between them. These are Linux or Windows server applications with databases, message buses, web front ends and many open source libraries.
• Traction power and facilities SCADA. Substation control, third rail and overhead line monitoring, tunnel ventilation, pumping, fire and life safety, with HMIs, historians and engineering workstations.
• Rolling stock. Train control and management systems (TCMS), door and brake controllers, event recorders, passenger information, CCTV and condition monitoring units on passenger trains; locomotive control computers, energy management, distributed power and end-of-train devices on freight. Updates happen at the depot, often years after the fleet was bought.
• Wayside and detection. Hot box and dragging equipment detectors, wheel impact load detectors, grade crossing controllers and the edge devices that report from them, many running embedded Linux with a web management interface.
• Fare collection. Ticket vending machines, faregates and validators, account based ticketing back offices, contactless payment processing and mobile ticketing apps.
• Passenger facing and business systems. Trip planners and real time feeds, websites and apps, station Wi-Fi, enterprise asset management, maintenance of way planning and ERP; on freight, car hire, interchange EDI, shipment tracking and customer portals.
• In-house code. Interface scripts between dispatch and crew systems, telemetry pipelines, customer apps, open data feeds and container images. This is the part of the supply chain you build yourself.

Where the software supply chain risk sits

Four things make rail different from an office network.

1. Very long lifecycles. Signalling systems and fleets are bought for decades. The operating system and open source libraries inside them age much faster, so a component current at handover can be end of life within a few years.
2. Safety approval slows patching. A change to a safety related system goes through the supplier's safety case and testing. That is the right control for safety, and it means a security patch can take months to reach a train or an interlocking. SD 1580/82-2022-01E allows for this with documented mitigations.
3. Few suppliers, deep dependence. One supplier for train control, one for interlockings, one for fares, each with its own maintenance contract and remote access path. A flaw in a shared component or protocol reaches many operators at once.
4. Business systems count. TSA's definition of a Critical Cyber System includes business services whose compromise could cause operational disruption, such as crew calling, dispatch support and fare systems that gate entry.

The regulations and frameworks that apply

TSA Security Directive 1580/82-2022-01E: mitigation actions and testing

This is the performance based directive. TSA's transmittal memo dated 1 May 2026 says SD 1580/82-2022-01E cancels and supersedes 01D, is effective 3 May 2026 through 2 May 2027, and makes no substantive revisions to the series. It applies to freight railroad carriers identified in 49 CFR 1580.101 and to other freight and passenger railroads that TSA designates.

What it requires, in the order a software supply chain program meets it:

• A TSA-approved Cybersecurity Implementation Plan (Section II.B). It describes the defense in depth plan for Sections III.A to III.E, and TSA inspects against it.
• Identify Critical Cyber Systems (III.A). Defined in Section VII.D as any IT or OT system or data that, if compromised or exploited, could result in operational disruption, including business services. Section III.A.2 says operators that run PTC under 49 CFR part 236 subpart H or I must include PTC systems as a Critical Cyber System, and must update their plan within 60 days if they had not.
• Segmentation (III.B). A list of IT and OT interdependencies, all external connections and zone boundaries. Supplier remote access paths belong in that list.
• Access control (III.C). Multi factor authentication or compensating controls for OT access, least privilege, shared account limits and trust relationship reviews.
• Monitoring (III.D). Including the capability to block and prevent unauthorized code from executing, and procedures to identify and respond to it.
• Patching (III.E). A patch management strategy that keeps all critical security patches and updates on Critical Cyber Systems current; a risk methodology for categorizing and determining criticality of patches with an implementation timeline; prioritization of all patches on CISA's KEV catalog; and, where patching specific OT systems would cause severe degradation of operational capability, a description and timeline of additional mitigations.
• Assessment (III.F). An annually updated Cybersecurity Assessment Plan, an architecture design review within 12 months of plan approval and every two years after, at least one third of measures assessed each year (all within three years), and an annual report to TSA.
• Records (IV.C). TSA may inspect or copy records including a hardware and software asset inventory (including SCADA systems), firewall rules, network diagrams, and plan and assessment documents.

Two definitions matter for vendors. An Authorized Representative includes agents, contractors and subcontractors acting for the operator, and both are liable for the representative's non compliance (II.A.3). A Managed Security Service Provider can share a measure, but the operator "retains sole responsibility" for compliance (II.A.2).

TSA Security Directives 1580-21-01E and 1582-21-01E: coordinator, reporting, response and assessment

These two directives set the baseline. SD 1582-21-01E applies to passenger railroad carriers and rail transit systems identified in 49 CFR 1582.101 and other TSA-designated passenger railroads; it excludes bus-only operations. TSA's memo dated 9 January 2026 says it is effective 16 January 2026 through 15 January 2027. SD 1580-21-01E is the matching directive for freight railroad carriers identified in 49 CFR 1580.101, with the same memo date and the same effective dates.

Each requires four actions:

1. A Cybersecurity Coordinator and at least one alternate at the corporate level, reachable by TSA and CISA 24 hours a day, seven days a week, with at least one a US citizen eligible for a security clearance. The 01E revision adds that any non US citizen coordinator must be a current member of NEXUS, Global Entry or a comparable program.
2. Incident reporting to CISA as soon as practicable and no later than 72 hours after identifying a cybersecurity incident, through CISA's reporting system. Reportable incidents include unauthorized access to an IT or OT system and discovery of malicious software. TSA's footnote points to IC Surface-2025-01 for recommendations on notifying TSA of significant incidents earlier.
3. A Cybersecurity Incident Response Plan to reduce the risk of operational disruption.
4. A Cybersecurity Vulnerability Assessment on TSA's form, which identifies gaps and a remediation plan.

For a supply chain program, the reporting clock is the pressure point: when a widely used component is compromised, the coordinator needs to know quickly which systems and supplier products carry it.

TSA's proposed rule: Enhancing Surface Cyber Risk Management

On 7 November 2024 TSA proposed a rule that would turn the directives into permanent regulations for pipelines, freight railroads, and passenger railroads and rail transit. The supply chain risk management sections for rail are proposed 49 CFR 1580.315 (freight) and 1582.215 (passenger rail and transit). The preamble says they adopt three recommendations from CISA's Cross-Sector Cybersecurity Performance Goals:

• Paragraph (a), from CPG 1.G: procurement documents and contracts would require vendors and service providers to notify the operator of security incidents within a risk informed time frame.
• Paragraph (b), from CPG 1.H: the same for confirmed security vulnerabilities in the vendor's assets.
• Paragraph (c), from CPG 1.I: procurement documents would include cybersecurity requirements and questions that are evaluated in vendor selection, so that between two offerings of roughly similar cost and function, the more secure one is preferred.

The preamble says the requirements would apply to procurement and contract documents executed or updated after the final rule's effective date, and paragraph (d) would require the operator, on receiving such a notice, to consider mitigation measures sufficient to address the resulting risk to Critical Cyber Systems. The SD 1580/82-2022-01E memo says TSA still intends to codify the directive's requirements through rulemaking. We found no final rule as of 25 October 2026. Use the proposal as a model for contract language at your next renewal, not as an obligation.

Where the safety rules meet the security directive

The directive leans on the Federal Railroad Administration's safety rules. It defines PTC by reference to 49 CFR 236.1003, and for PTC components on locomotives it lets operators rely on the physical security measures they use under 49 CFR 232.105(h), 236.3 and 236.553 in place of Sections III.C.1 to III.C.5, if the implementation plan says which (III.C.6). Safety change control and security patching act on the same software, so fold the security patch methodology into the engineering change process rather than running two approval paths.

IEC 62443, CLC/TS 50701 and IEC 63452

The ISA/IEC 62443 series is the industrial automation security standard most control system suppliers build to. ISA's catalog lists ANSI/ISA-62443-2-1-2024 (security program requirements for asset owners), 62443-3-3 (system security requirements and security levels) and ANSI/ISA-62443-4-1-2018 (secure product development lifecycle requirements).

For rail, CEN-CENELEC announced CLC/TS 50701 on 10 June 2021 as a technical specification on railway cybersecurity for rolling stock and fixed installations. The current edition is CLC/TS 50701:2023, listed by the Estonian standards body as valid from 1 September 2023. The specification is being taken to IEC as IEC 63452. DIN's project page describes the draft prEN IEC 63452:2025 as guidance for railway operators, system integrators and product suppliers on managing cybersecurity within the EN 50126-1 RAMS lifecycle, based on or derived from the IEC 62443 series, and lists a planned publication of July 2026. Check IEC for the current status before citing it in a specification. Asking a signalling supplier how its development process meets 62443-4-1, and how it maps to 50701, is a reasonable part of a vendor evaluation.

CISA guidance for OT buyers and SBOMs

CISA's Secure by Demand guide for OT owners and operators (13 January 2025, written with partners that include TSA) is meant to help owners and operators buy OT products, especially industrial automation and control products, with secure by design elements in mind. CISA's 2026 Minimum Elements for a Software Bill of Materials (29 July 2026) updates and replaces the NTIA's 2021 minimum elements and is the current reference for what an SBOM should contain.

Fare systems and PCI DSS

Fare collection that accepts payment cards also sits inside a PCI DSS assessment, and its software requirements reach the fare back office, payment pages and mobile ticketing apps. Agencies that use open loop contactless payment should confirm with their acquirer and fare system supplier who holds which requirement, and keep the component inventory from this plan available for the assessor.

Other rules to check

Transit agencies buying with federal funds follow federal procurement rules, so check new security terms with your grants and legal teams before they go into a solicitation. Operators with operations outside the US face their own national rules, and global suppliers design products and contracts around those too.

Real public incidents from the last three years

The incidents below come from official statements or government advisories. We describe what the sources say and draw no conclusions beyond them.

Transport for London, September 2024. TfL says that on Sunday 1 September 2024 it identified suspicious activity and acted to limit access, keeping all safety critical systems and processes running. Its investigation found that certain customer data, including names and contact details for some customers, was accessed, and TfL notified the UK Information Commissioner's Office and contacted those affected that month. TfL says the ICO confirmed on 13 February 2025 that it would take no regulatory action, and that in June 2026 two people charged in connection with the incident pleaded guilty and were each sentenced to five years and six months. The record shows corporate and customer systems can be the target while trains keep running.

End-of-train and head-of-train remote linking, 2025. CISA's industrial control systems advisory ICSA-25-191-10 (Update C, last revised 18 September 2025) covers the radio protocol used to link end-of-train and head-of-train devices, tracked as CVE-2025-1727 with a CVSS v4 base score of 7.2. CISA says the protocol relies on a BCH checksum, so packets can be created with a software defined radio to send brake commands, which could stop a train suddenly, disrupt operations or induce brake failure. The advisory lists all versions of the protocol as affected, names devices from several manufacturers confirmed as affected, and says the Association of American Railroads, whose Railroad Electronics Standards Committee maintains the protocol, is pursuing new equipment and protocols to replace the traditional devices. It is a shared industry protocol inside many suppliers' products, which no single railroad can fix alone; what a railroad can do locally is know which devices it runs and record its mitigations and replacement plan.

Volt Typhoon, February 2024. CISA, the FBI and partners said in advisory AA24-038A that they had confirmed the PRC state sponsored group Volt Typhoon had compromised the IT environments of multiple critical infrastructure organizations, primarily in the Communications, Energy, Transportation Systems, and Water and Wastewater Systems sectors. The advisory describes the group exploiting vulnerabilities in internet facing network devices, which is why vendor appliances at the edge of a railroad's network belong in the KEV based patch methodology and not only the servers behind them.

XZ Utils, March 2024. CISA said on 29 March 2024 that it was responding with the open source community to reports of malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1 (CVE-2024-3094), data compression software that may be present in Linux distributions. For rail, the question it raised was a simple one: which of our Linux based dispatch servers, wayside devices, onboard units and container images carry this library, and who can tell us? Operators holding supplier SBOMs could search them; others had to ask each supplier in turn.

The personas who own the problem

The CISO

The CISO answers to the board and to TSA for the Cybersecurity Implementation Plan. They need a defensible view of Critical Cyber System risk that includes third party software, a patch methodology that holds up at inspection, and a fast answer on exposure when a component makes the news. Their moments are the TSA inspection, the annual assessment report, the board risk committee and the first hour of an incident.

Head of communications, signals and train control engineering

This person owns PTC, CBTC, interlockings and the wayside. They need supplier advisories that say clearly whether a product is affected, a way to separate real exposure from a scanner match, and a patch plan that respects the safety case. Their moments are a supplier maintenance release, a KEV addition that hits their systems, and planning for track possessions. A mitigation record with a revisit date is often the right outcome for them, not an emergency change.

TSA Cybersecurity Coordinator and compliance lead

The coordinator is reachable 24/7 and files the 72 hour report. The compliance lead keeps the implementation plan, assessment plan and evidence. They need records indexed in the directive's order (Section IV.A expects an index when prior materials are reused), an inventory TSA can inspect, and proof that KEV items were prioritized. Their moments are inspections, the annual report, plan amendments due within 50 days of a permanent change, and incidents.

Procurement and vendor risk

Procurement writes the contracts that decide whether an SBOM, an advisory feed and a patch commitment ever arrive. They need a short list of terms suppliers will accept, a tracker of what each supplier delivered, and supplier tiers by criticality. Their moments are new procurements of rolling stock, signalling and fare systems, renewals and supplier incidents, all inside public procurement rules for transit agencies.

Fare and revenue systems owner

The fare system is a payment environment, a customer service system and a gate that can stop people entering stations. This owner needs PCI evidence, a component view of the fare back office and apps, and a clear split of duties with the fare supplier and payment processor. Their moments are the annual PCI assessment, app releases and fare outages.

Fleet engineering, OT and field IT, and in-house developers

Fleet engineers need to know what is inside each fleet's TCMS and onboard units and which components are end of life, at overhauls and warranty ends. OT and field IT need scanning that works on segmented networks. Developers need fixes and pipeline gates for the code they own.

Step by step: a 30, 60 and 90 day plan

This plan works with any tooling and assumes a TSA-approved implementation plan and a named coordinator are already in place.

Days 1 to 30: know what you run

1. Pull your Critical Cyber Systems list from the implementation plan. Add PTC if you run it, and business services that can stop trains, such as crew calling, dispatch support and fare gates.
2. For each system, record the supplier, product, version, support status and maintenance contract. Include who has remote access and how.
3. Inventory the software you build. Generate SBOMs for in-house applications, scripts and container images in the CI pipeline.
4. Ask each critical supplier for an SBOM and an advisory channel. Ask for SPDX or CycloneDX in a machine readable file, not a PDF, and for CSAF or VEX advisories where the supplier can provide them.
5. Subscribe to the KEV catalog and supplier advisories. Route them to one queue the coordinator and the engineering leads both see.
6. Name an owner for each system's patch decisions. For safety related systems, that owner sits in engineering, with security as a reviewer.

A starter request to a signalling or rolling stock supplier can be short:

Days 31 to 60: decide and document

1. Write the patch risk methodology down. Categories (for example KEV, critical, high, other), the implementation timeline for each, and who approves. Put KEV first, as III.E.2.b requires.
2. Match SBOMs against vulnerability data. For in-house code, add reachability analysis so the team fixes what the code actually calls first. For supplier SBOMs, record the supplier's VEX position next to each match.
3. Write a mitigation record for every system you cannot patch on the methodology's timeline. State why patching would severely degrade operations, the additional mitigations (segmentation, access limits, monitoring, removal of unused services), the owner and a revisit date. This is the III.E.3 record.
4. Add gates to in-house pipelines. Block builds that introduce KEV listed components into software that reaches a Critical Cyber System; warn on lower severities.
5. Tier suppliers. Critical for train control, signalling and traction power suppliers; high for dispatch, fare and rolling stock software; lower for the rest. Set re-check frequencies by tier.
6. Draft contract language for renewals. Use the request table above and the proposed rule's supply chain clauses as a model. Have counsel review.

Days 61 to 90: monitor and prove it

1. Monitor continuously. KEV additions, supplier advisories and in-house releases should all alert the same queue.
2. Run an exposure drill. Pick a widely used open source component and time how long it takes to list every system and supplier product that carries it.
3. Index the evidence in the directive's order. For each section of SD-2022-01E, list the record and where it lives, as Section IV.A expects when prior materials are reused.
4. Feed the Cybersecurity Assessment Plan. Choose which one third of measures to assess this year, and include the patch and inventory measures.
5. Report to the board. Number of Critical Cyber Systems with a current SBOM, KEV items open and their mitigations, suppliers that have not delivered, and the date of the last exposure drill.

How do you get an SBOM from a signalling or rolling stock supplier?

Ask when you have bargaining power: a new procurement, a renewal or a warranty claim. Ask for a machine readable SBOM for each delivered version, not a one-time document, and say what you will do with it (match it against KEV and advisories, under confidentiality). If a supplier will not share a full SBOM, ask for a list of third party and open source components with versions, or a commitment to answer exposure questions within a set time. Record every request and answer.

What should a railroad or transit agency put in vendor contracts now?

Five clauses cover most of the risk: an SBOM per release in SPDX or CycloneDX; vulnerability and incident notice within an agreed time; a patch and mitigation commitment that respects the safety case; disclosure and control of remote access; and a right to evidence of secure development. TSA's proposed 1580.315 and 1582.215 give a model for the notice clauses, and CISA's Secure by Demand OT guide gives priority considerations to ask suppliers about.

How Safeguard does this

The steps below use only what Safeguard's offering documentation and docs.safeguard.sh describe. Every capability named here is generally available (GA). Commands are shown as the docs show them; we did not run them for this post.

1. Switch on the relevant frameworks in the compliance suite

The compliance and GRC suite (GA) includes framework pages for IEC 62443 (component inventory, supplier verification and integrity) and NIST SP 800-82 (asset inventory, patch management and supply chain for control systems). Each is on in your workspace unless you switch it off in Compliance › Manage, with scan requirements checked on every product scan plus catalog controls. The docs list no TSA rail directive framework, so map SD 1580/82-2022-01E sections to these controls yourself; a mapping organizes evidence, it is not TSA's text.

2. Inventory the software you build

SBOM generation and analysis (GA) and SCA with deep transitive dependency scanning (GA) cover the in-house half of the supply chain. From the CLI (GA), the docs show safeguard scan taking exactly one target:

# A local directory (your own or proprietary code)
safeguard scan --dir .

# A container image
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

Results are written under ./output by default. To check supplier SBOMs before you rely on them, safeguard validate sbom.json checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications.

3. Collect supplier SBOMs through TPRM

TPRM, the Third-Party Risk Manager (GA), is where signalling, rolling stock and fare system suppliers live. The vendor management docs show each vendor with products, contacts, contract status, SBOM status and a risk tier of Critical, High, Medium or Low, with bulk import from a CSV template. To request an SBOM, the docs describe these steps:

1. Navigate to the vendor.
2. Click Request SBOM.
3. Select the product or products.
4. Choose a request template (the standard template covers SPDX or CycloneDX format and required fields).
5. Customize the message if needed.
6. Set a deadline and click Send.

Bulk requests cover many suppliers at once. Requests move through Sent, Viewed, In Progress, Submitted, Validated and Rejected, with automated reminders seven days before the deadline and at it, and an escalation seven days after.

4. Bring in supplier advisories as CSAF or VEX

CSAF and VEX upload (GA) lets you load a supplier's CSAF advisory or VEX statement so its position sits beside the raw match.

5. Monitor suppliers and KEV continuously

TPRM monitoring (GA) watches vendor SBOMs for new vulnerabilities, severity changes, exploit availability updates and CISA KEV additions. The docs list an Exploited alert (a CVE added to CISA KEV), an SBOM Expiry alert, and re-scans from daily for critical vendors to quarterly. Vulnerability management (GA) enriches findings with EPSS and KEV, and reachability analysis (GA) helps rank which vulnerable code paths your own applications call, which supports the risk methodology Section III.E.2.a asks for.

6. Turn the patch methodology into policies and gates

Policies, gates and guardrails (GA) put the methodology into practice. The docs describe policies created under Settings › Policies with conditions such as severity, CVSS, EPSS, license and component age. Each policy's action decides what a failure does to the gate: Block fails the gate, Warn passes it with a warning, and Notify passes it and sends a notification. Plain English policy creation (GA) is also available.

For in-house code, the docs show a CI step that fails the job when a gate fails, with policy outcomes on for your workspace:

safeguard ci scan --wait --fail-on-gate <gate>

For a finding you cannot fix on the methodology's timeline, the exception workflow fits III.E.3: the docs describe a request naming the policy and finding, a business justification and an expiration date, reviewed by an approver, with an audit trail. The justification holds your mitigations; the expiry is your revisit date.

7. Run it where the OT network allows

• Local runner (GA). The runner ships with the CLI. The docs say all its traffic is outbound HTTPS that the runner opens, nothing connects to it, and it runs each scan job locally and uploads only the resulting SBOM and findings, never source code.
• Air-gapped deployment (GA). The docs describe running the full web app, including TPRM, inside your perimeter, with signed snapshot bundles delivered by one-way diode, signed removable media, a scheduled DMZ sync or a pull replica, at a cadence from hourly to quarterly.
• Zero AI mode (GA). The platform can run with no LLM in the loop.

8. Fix what you own, with a person in charge

Autonomous remediation (GA) opens fix pull requests for vulnerable dependencies in code you build. It ships switched off, with every category set to Manual. For supplier software, the fix still comes from the supplier; Safeguard tells you which systems are affected and keeps the record.

9. Answer the "who is your vendor?" question about Safeguard

Your own supplier evaluation will ask about Safeguard. Use the precise wording: Safeguard's platform is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not talk to TSA or CISA for you. Plans, assessment reports and incident reports remain the coordinator's job.
• It does not see inside firmware a supplier will not disclose. The flows above work on source, container images, repositories and SBOM files. For onboard units, interlockings and wayside firmware you depend on the supplier's SBOM and advisories.
• It does not segment networks, harden controllers or monitor OT traffic. Those outcomes (III.B, III.C and III.D) need your network design, access controls and OT monitoring tools.
• It does not change the safety case. It can show a KEV item affects a dispatch server; engineering and safety decide when a safety related system changes.
• It does not make a supplier send an SBOM. TPRM tracks requests and reminders; contract terms and purchasing decisions get the document.
• It has no TSA rail directive framework page. The docs list IEC 62443 and NIST SP 800-82; the mapping from SD 1580/82-2022-01E sections to evidence is yours.
• It does not interpret the regulations for you. This post is not legal advice.

Common mistakes

• Leaving PTC out. SD-2022-01E names it.
• Leaving business services out. Crew calling, fare gates and passenger information can all be Critical Cyber Systems.
• One-time SBOM requests. An SBOM is only current for the release it describes.
• Accepting PDFs as SBOMs. You cannot match a scanned PDF against KEV.
• Mitigations without dates. Every III.E.3 record needs a revisit date.
• Two approval paths for one change. Merge the security patch methodology into engineering change control.
• Assuming a managed provider holds the duty. The directive says the operator keeps sole responsibility.
• Waiting for the final TSA rule to fix contracts. Renewals happen now.

FAQ

What does TSA SD 1580/82-2022-01E require for patching?

A patch management strategy that keeps critical security patches on Critical Cyber Systems current, a risk methodology with implementation timelines, priority for every patch on CISA's KEV catalog, and a description and timeline of additional mitigations where patching an OT system would severely degrade operational capability (Section III.E).

When do the TSA rail directives expire?

SD 1580/82-2022-01E runs from 3 May 2026 to 2 May 2027. SD 1582-21-01E runs from 16 January 2026 to 15 January 2027. TSA has renewed the series each year, so expect renewals around those dates.

Does the TSA rail directive cover Positive Train Control?

Yes. Section III.A.2 of SD 1580/82-2022-01E says operators that run PTC under 49 CFR part 236 subpart H or I must include PTC systems as a Critical Cyber System.

How fast must a transit agency report a cyber incident?

Under SD 1582-21-01E, as soon as practicable and no later than 72 hours after identifying a cybersecurity incident, to CISA.

Does the TSA directive require an SBOM?

Not by that name. It lets TSA inspect a hardware and software asset inventory. An SBOM is the practical way to keep the software part accurate.

Is the TSA surface cyber rule final?

No. TSA proposed it on 7 November 2024. TSA's May 2026 directive memo still describes codification as intended rulemaking, and we found no final rule as of 25 October 2026.

What is CLC/TS 50701?

A CENELEC technical specification on railway cybersecurity, based on the IEC 62443 series. The current edition is CLC/TS 50701:2023, and it is being developed into IEC 63452.

Can supply chain scanning run on a segmented rail network?

Yes, if the tool supports outbound only scanning from a jump host or a fully air-gapped deployment.

The open source dependencies inside your in-house dispatch integrations, customer apps, data pipelines and container images are the part of the rail software supply chain you can fix yourself, without waiting on a signalling or rolling stock supplier's release. The section below explains how Safeguard handles that half, from upgrade pull requests to cases where upstream has no fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. On a rail network, this is the pattern for a jump host in an OT DMZ next to the operations control center: the runner opens only outbound connections and uploads the SBOM and findings, so the scan happens where the code lives.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to an in-house customer app or dispatch integration whose dependencies are behind.

Click through it at your own pace, or open it full screen.

Related reading

• In this series: 90-day plan for oil and gas pipelines, electric utilities and logistics and freight.
• Manufacturing OT software supply chain
• IEC 62443-2-2 (2025): security protection schemes for IACS
• Air-gapped vulnerability management
• Third-party risk management for software vendors

Quick check

To try these flows on your own code and supplier SBOMs, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

Sources

• TSA: Security Directives and Emergency Amendments
• TSA SD 1580/82-2022-01E and transmittal memo (PDF)
• TSA SD 1580-21-01E and transmittal memo (PDF)
• TSA SD 1582-21-01E and transmittal memo (PDF)
• Federal Register: Enhancing Surface Cyber Risk Management, proposed rule, 7 Nov 2024
• ISA: ISA/IEC 62443 series of standards
• CEN-CENELEC: A major step for railways cybersecurity, the new CLC/TS 50701
• EVS: CLC/TS 50701:2023 Railway applications, Cybersecurity
• DIN: Railway applications, Cybersecurity, prEN IEC 63452:2025 project
• CISA: Secure by Demand, Priority Considerations for OT Owners and Operators
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA advisory ICSA-25-191-10: End-of-Train and Head-of-Train Remote Linking Protocol
• CISA advisory AA24-038A: PRC state-sponsored actors (Volt Typhoon)
• CISA alert: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• Transport for London: Cyber security incident in September 2024
• Safeguard docs: IEC 62443 framework
• Safeguard docs: NIST SP 800-82 framework
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Policies and Gates
• Safeguard docs: Generate SBOM
• Safeguard docs: CLI usage
• Safeguard docs: Local Runner
• Safeguard docs: Air-Gapped Deployment

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.