Transportation Identity and OT Access Guide

Transport operators run safety-critical systems that are reached by far more people and machines than the operator employs, and most of that access is granted per mode, per site and per supplier with no common identity model. A rail signalling maintainer, an airport baggage system integrator, a crane manufacturer's remote engineer and a vehicle telematics back end all hold credentials into operational technology (OT), often shared, often permanent and rarely reviewed. Regulators in every mode now ask for the same core controls: unique accounts, multi-factor authentication (MFA) for remote access, least privilege, monitored third-party connections and prompt removal of leavers. This guide is the cross-mode identity and access view for rail, aviation, maritime and road. It is written for OT security leads, IAM and privileged access teams, and compliance owners at multimodal operators, infrastructure managers and their suppliers. The mode-specific architecture, standards and incidents sit in the linked sector guides and are not repeated here.

Key takeaways

The regulators converge on identity. TSA rail directives, the US Coast Guard maritime rule, EASA Part-IS, the IMO guidelines and UN Regulation No. 155 all ask for unique credentials, MFA or documented compensating controls, least privilege and control of supplier access.
Third parties are the main access population. Original equipment manufacturers (OEMs), integrators and maintainers hold most remote paths into signalling, cranes, airport systems and vehicle back ends, so supplier identity governance is the centre of the programme.
Compensating controls are allowed, undocumented gaps are not. Where an interlocking, a crane PLC or an onboard system cannot do MFA, the rules accept documented alternatives such as brokered access, physical controls or monitoring, and expect them to be written into the plan.
Machine identities outnumber people. Vehicle and rolling stock certificates, gateway service accounts, data exchange API keys and diagnostic keys need the same lifecycle discipline as staff accounts, and one credential must never open a whole fleet.
Shared accounts are the recurring finding. Control room, bridge, cab and maintenance laptops often run on shared logins; the TSA rail directive and the Coast Guard rule both restrict them and require removal of access on departure.

Why transport identity is different

CISA treats transportation as one critical infrastructure sector with seven subsectors: aviation, highway and motor carrier, maritime transportation system, mass transit and passenger rail, pipeline systems, freight rail, and postal and shipping. The Department of Homeland Security and the Department of Transportation are co-Sector Risk Management Agencies. What the modes share, from an identity point of view, is a set of conditions that break normal enterprise IAM:

Distributed, unstaffed assets: trackside cabinets, level crossings, remote berths, roadside units and aircraft at outstations are accessed locally by visiting staff, so physical and logical access are tied together.
Moving assets with intermittent links: trains, ships, aircraft and vehicles cannot always reach a central identity provider, so authentication must work offline and credentials must be cached safely.
Long asset lives: signalling, cranes and avionics stay in service for decades and may support only local accounts, fixed passwords or none at all.
Safety certification: changing software on a certified safety system can trigger reassessment, so adding an agent or an authentication module is not a routine change.
Multi-party sites: airports, ports and stations host many organisations on shared networks, and each party's risk crosses the interface. EASA Part-IS point IS.I.OR.205 requires organisations to identify interfaces with other organisations that create mutual exposure and to communicate shared risks.
Crew and shift working: drivers, pilots, seafarers and controllers change shifts at fixed times on shared consoles, which pushes operators towards shared logins unless fast user switching is designed in.

See the OT and ICS Identity and Access Guide for the general OT identity model this guide builds on.

The identity population by mode

Each mode has its own vocabulary, but the identity categories repeat. Mapping them early shows where accounts, keys and remote paths actually sit.

Mode	Human access to OT	Third-party access	Machine identities
Rail	Signallers, control centre operators, depot and trackside maintainers, train drivers on cab systems	Signalling and rolling stock OEMs, maintenance contractors, telecoms providers	Train control and positive train control (PTC) components, train radio, onboard gateways, condition monitoring sensors
Aviation	Airport operations and engineering staff, airline maintenance engineers, air traffic engineers	Baggage, check-in and airfield system integrators, avionics and software suppliers, ground handlers on shared systems	Loadable software parts and their signing keys, airport system service accounts, aircraft data link and electronic flight bag (EFB) devices
Maritime	Bridge and engine crew, terminal and crane operators, port control and vessel traffic staff	Crane and terminal OEMs, ship system makers with remote support, port community system users	Ship-to-shore data links, terminal operating system integrations, gate and container scanning devices
Road	Traffic control room operators, tolling and fleet operations staff, workshop technicians	Vehicle OEM service networks, telematics and tolling providers, traffic signal maintainers	Vehicle and roadside unit certificates, telematics back-end API keys, charge point credentials, diagnostic access keys

For the mode-specific systems behind these rows, see the Rail Cybersecurity Guide (TS 50701), the Aviation Cybersecurity Guide, the Ports and Logistics Cybersecurity Guide and the Connected and Autonomous Vehicle Security Guide.

What the rules say about access

The access clauses are more alike across modes than the regimes themselves. Status and dates below are as the primary sources stated when checked in October 2026; check the issuing body for current revisions, as TSA renews its directives periodically.

Regime	Access and identity requirements	Third-party and remote access
TSA Security Directive 1580/82-2022-01C (freight and passenger rail; revision effective 1 July 2024)	Section III.C: password reset policy aligned with NIST SP 800-63; MFA or comparable controls, with compensating controls specified where MFA is not used for OT; least privilege and separation of duties; shared accounts limited to those critical for operations, and people who no longer need access must not know the shared password; scheduled review of domain trust relationships	Access controls apply to local and remote access to Critical Cyber Systems, which must include PTC systems; III.B requires documented external connections and zone boundaries
US Coast Guard, 33 CFR 101.650 (US-flagged vessels and facilities with security plans)	101.650(a): lockout after failed logins, default passwords changed before use, minimum password strength, least privilege for privileged accounts, separate credentials on critical IT and OT systems, credentials revoked on departure; (a)(4) MFA on password-protected IT and remotely accessible OT, or documented compensating controls	101.650(f)(3): monitor and document all third-party remote connections; (f)(2) vendors notify vulnerabilities and incidents without delay; (h)(2) log and monitor all IT to OT connections
IMO MSC-FAL.1/Circ.3/Rev.3 (ships and companies; non-mandatory)	Paragraphs 3.5.3.1 and 3.5.3.2: unique credentials for all users, separate user and privileged accounts, deactivation for leavers, default passwords changed, MFA or continuous authentication where appropriate	Paragraph 2.2.6 asks risk management to consider third-party vendors and maintenance devices; 3.5.3.4 covers ship and port interfaces
EASA Part-IS, Implementing Regulation (EU) 2023/203 (air operators, maintenance, ANSPs and others; applies from 22 February 2026)	IS.I.OR.240: the identity and trustworthiness of personnel with access to information systems and data must be appropriately established; competence and acknowledgement of responsibilities	IS.I.OR.235: contracted ISMS activities stay under the organisation's oversight; IS.I.OR.205: interface risks shared with other organisations
UN Regulation No. 155 (vehicle manufacturers, type approval)	Annex 5 mitigations M18 (roles and access privileges on least privilege) and M19 (security procedures including logging of actions on security functions); M1 controls on back-end systems against insider attack	7.2.2.5: the manufacturer must show how it manages dependencies on suppliers and service providers

The common thread is that a regulator will ask for evidence: an account inventory, an MFA coverage list with documented exceptions, a third-party connection log and leaver records. The TSA aviation emergency amendment of March 2023 added the same families (implementation plan, segmentation, access control, continuous monitoring, patching) for airport and aircraft operators. In the EU, NIS2 adds its own risk management duties for transport entities on top of Part-IS. See the NIS2 Directive Guide.

Controlling third-party and OEM access

Supplier access is where the modes most often fail and where a single programme can serve all of them. CISA, the FBI, EPA and DOE, in their primary mitigations for OT, ask operators to move necessary remote access onto a private network or a VPN with phishing-resistant MFA, to limit access to the minimum each role needs and to disable dormant accounts. Applied to transport, that becomes:

One broker per site class: route all OEM and integrator sessions through a privileged access or secure remote access gateway in an OT demilitarised zone, so that no supplier holds a direct VPN into signalling, terminal or airfield networks. See the OT Remote Access Guide.
Named accounts for supplier staff: issue accounts to individuals, not to companies. A "vendor" login shared by a maintenance contractor's whole team cannot meet 101.650(a)(6) or TSA III.C on shared accounts.
Time-bound approval: enable access per work order or maintenance window and disable it afterwards, with the operator's control room approving sessions that touch live operations.
Session recording and monitoring: record sessions into safety systems and log every third-party connection, which directly evidences 101.650(f)(3). See the Privileged Session Management Guide.
Contractual obligations: require suppliers to notify vulnerabilities and incidents, to inform you when staff leave, and to accept your access tooling. Part-IS IS.I.OR.235 and UN R155 7.2.2.5 both make supplier oversight the operator's responsibility.
Removable media and maintenance laptops: treat engineering laptops and USB media brought by suppliers as identities to control: approved devices only, scanned at a kiosk, logged on use. IMO 3.5.3.5 calls for controls on unauthorised removable media.

See the Third-Party Access Guide for the governance model and the Third-Party Access Policy Template for policy wording.

Machine identities in vehicles, rolling stock and data exchange

Transport increasingly authenticates machines to machines: a vehicle to an OEM back end, a train to a wayside system, a terminal operating system to a port community system, a charge point to its management system. These credentials are long lived, embedded and multiplied across fleets.

Per-asset credentials: the NHTSA 2022 cybersecurity best practices state at [T.5] that any credential obtained from one vehicle's computing platform should not provide access to other vehicles, and at [T.8] that global symmetric keys for diagnostic access should be minimised. The same principle applies to rolling stock, ships and roadside units: unique keys per asset, ideally in hardware-backed storage.
Developer and debug access: NHTSA [T.1] and [T.2] ask for developer-level access to be limited or eliminated on deployed units and protected to authorised privileged users where it must remain. Debug ports on onboard computers and crane controllers are a common unmanaged identity.
Back-end authentication: NHTSA [T.20] calls for encryption and authentication on operational communication between external servers and the vehicle, and [T.25] for designs that account for compromised servers and insiders. Fleet back ends are where one stolen service credential reaches thousands of assets.
Certificate-based protocols: charge point management under OCPP security profile 3 uses TLS with client certificates, and V2X uses a security credential management system with pseudonym certificates. Both need certificate inventories, renewal and revocation. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Data exchange API keys: port community systems, airport operational databases and logistics platforms connect many organisations through APIs and file transfers. Each integration key should have an owner, a scope and a rotation date. See the Device and IoT Identity Guide.

Decision guidance

Most choices in transport access are between a strong control the asset cannot support and a compensating control the regulator will accept if documented.

Situation	Preferred approach	Acceptable alternative	Trade-off
OT asset cannot do MFA (interlocking, crane PLC, legacy airfield controller)	MFA at a jump host or broker in front of the asset, with direct paths blocked	Physical access control plus monitoring, documented as compensating control (TSA III.C allows physical measures for listed PTC locomotive components)	Broker adds a dependency; plan a break-glass path for outages
Shared console at a control desk, bridge or cab	Individual logon with fast user switching or badge tap	Shared operator session for viewing, with individual credentials for any change and a shift log	Individual logons can slow handover; design with operators, not for them
Supplier needs urgent remote access during disruption	Pre-registered named account enabled by the control room for the incident	Escorted session where an operator shares the screen	Pre-registration takes effort but avoids creating accounts under pressure
Moving asset with intermittent connectivity	Locally cached credentials with short validity and central revocation on reconnect	Local accounts managed by a vault and rotated at depot or port call	Offline caching extends the window a revoked user remains valid
Small operator (regional airport, short line railroad, small terminal)	Managed secure remote access service and a single identity provider for IT and OT jump hosts	VPN with phishing-resistant MFA, a named account list and a monthly review	Less tooling, so the account list and review become the main control

Large multimodal groups gain most from one identity governance process across modes, with mode-specific connectors and approval workflows, rather than one tool per business unit. Small operators should spend first on removing direct internet exposure and default passwords, which the CISA OT mitigations list as primary causes of compromise.

How to implement

Inventory accounts and paths (months 0 to 3): list every human, supplier and machine account on critical systems, every remote access path and every shared login, per mode and site. Use the Critical Cyber System list (TSA) or critical system designation (101.650(b)(3)) as the scope.
Close the exposed doors first: remove internet-facing OT services, change default passwords (101.650(a)(2)), disable dormant and leaver accounts, and cut supplier VPNs that bypass the operator.
Stand up brokered access: deploy the remote access gateway in audit mode at one pilot site per mode, recording sessions while existing paths stay open, then move suppliers across one by one.
Enforce MFA and document exceptions: turn on MFA at the broker and for IT systems, and write each exception and its compensating control into the TSA implementation plan, Coast Guard Cybersecurity Plan or ISMS.
Replace shared accounts: start with accounts used for configuration changes, then operator consoles. Where a shared account must remain, vault the password and rotate it when anyone with knowledge of it leaves.
Govern machine credentials: inventory certificates, keys and service accounts in vehicles, rolling stock and integrations, assign owners and set rotation and revocation processes.
Test and roll back safely: trial every change in a maintenance window with the asset owner present, keep the previous access path disabled but restorable until the new one has run through a full operational cycle, and include access in disruption exercises.
Review and evidence: run quarterly access reviews for third-party and privileged accounts and keep records ready for TSA assessment plans, Coast Guard inspection or Part-IS oversight.

Detection and measurement

Logging must cover the boundaries where identity is used. TSA III.D asks for continuous collection and analysis on Critical Cyber Systems and directly connected IT and OT, and 101.650(c)(1) requires logs to be securely captured, stored and accessible only to privileged users.

Monitor: all authentications at OT jump hosts and remote access gateways; third-party session starts, durations and source addresses; use of shared and break-glass accounts; new accounts on OT systems; IT to OT connections (101.650(h)(2)); certificate and key issuance for fleet back ends.
Alert on: remote logons outside an approved work order, a supplier account active after its contract end, logons to OT from a path other than the broker, and a single machine credential seen from many assets.

Metric	What it shows	Target direction
Share of remote OT access paths that pass through the broker	Whether bypass routes are closing	100 percent
MFA coverage on remotely accessible OT, with documented exceptions counted separately	Regulatory readiness	Rising, with every exception documented
Number of shared accounts on critical systems	Accountability	Falling
Median time from supplier staff departure to account disablement	Leaver control for third parties	Under one working day
Third-party sessions without a linked work order	Approval discipline	Zero
Machine credentials with no named owner	Non-human identity governance	Falling to zero

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	MITRE ATT&CK for ICS
Account and credential lifecycle, including suppliers and machines	PR.AA-01	AC-2, IA-5, PS-7	T0859 Valid Accounts
Remote and supplier access via broker with MFA	PR.AA-05	AC-17, IA-2, MA-4	T0822 External Remote Services, T0886 Remote Services
Least privilege and separation of duties	PR.AA-05	AC-6	T0859 Valid Accounts
Device and asset authentication	PR.AA-01	IA-3	T0883 Internet Accessible Device
Supplier risk	GV.SC-07	PS-7	T0847 Replication Through Removable Media
Monitoring of personnel and third-party activity	DE.CM-03	AU-6, SC-7	T0822 External Remote Services

In ISO/IEC 27001:2022 Annex A, the same areas sit under 5.15 access control, 5.16 identity management, 5.18 access rights, 5.19 to 5.22 supplier relationships and 8.2 privileged access rights.

Common failure patterns

Dormant remote accounts: a VPN or remote access account left active after its user stopped needing it. The Colonial Pipeline ransomware attack, in the pipeline subsector of transportation, began with an unused VPN account, and the operator shut down pipeline operations as a precaution.
Supplier-owned connections: OEMs installing their own modems, cellular routers or remote support tools on cranes, signalling cabinets or airport systems, outside the operator's inventory.
Unauthenticated operational radio and protocols: commands that any transmitter can send. In the 2023 Polish railway radio-stop incident, reported by The Record, around 20 trains were halted because the analogue radio stop signal lacked encryption and authentication. Identity controls cannot be added to such channels, so the fix is migration and monitoring.
Fleet-wide secrets: one diagnostic key, service password or API key shared across every vehicle, train or terminal, so a single extraction compromises all of them, against NHTSA [T.5].
Exceptions that are never written down: MFA "not possible" on OT with no compensating control recorded, which fails TSA III.C and 101.650(a)(4) at the first review.
Shared multi-party platforms without ownership: airport and port community systems where no party owns the account lifecycle for ground handlers, agents or hauliers. The September 2025 ransomware incident affecting Collins Aerospace's MUSE passenger processing system disrupted check-in at several European airports and showed how one shared third-party platform can affect many operators at once.

Practitioner checklist

Build one inventory of human, supplier and machine accounts and remote access paths across all modes, scoped to critical systems.
Remove internet exposure and default passwords on OT before any other identity project.
Route every supplier session through a broker with MFA, named accounts and session recording.
Document every MFA exception with its compensating control in the TSA plan, Coast Guard Cybersecurity Plan or ISMS.
Replace shared accounts used for configuration changes, and vault and rotate any that must remain.
Require suppliers by contract to notify incidents, vulnerabilities and staff departures.
Issue unique credentials per vehicle, train, ship and roadside unit, and plan revocation.
Log and alert on third-party sessions without a work order and on any OT logon that bypasses the broker.
Review third-party and privileged access quarterly and keep the evidence for regulators.

Transportation Identity and OT Access Guide: Rail, Aviation, Maritime and Road