Airport Cybersecurity Guide

An airport is a small city of interdependent systems run by dozens of organisations, and a failure in one shared platform can stop check-in, baggage and boarding across every airline at once. The airport operator owns the operational database, baggage handling, airfield systems and the shared networks, while airlines, ground handlers, retailers, border agencies and suppliers all plug in. This guide covers the airport operator's view: the systems that matter, how to zone them, how to manage the many third parties, how to keep passengers moving in degraded mode, and which obligations apply. It builds on the Aviation Cybersecurity Guide, which covers the wider aviation regulatory picture and aircraft, and is written for airport CISOs, IT and OT managers, and operations and resilience leads.

Key takeaways

Shared platforms are the biggest single risk. Common use passenger processing, the airport operational database and baggage control serve every airline, so their failure is an airport-wide event.
Most airport OT is buildings and logistics. Baggage handling, airfield ground lighting, building management, fuel, lifts and access control need the same zoning and remote access discipline as an industrial plant.
The airport is a landlord network. Tenants and suppliers need connectivity, so segmentation and supplier access control decide how far a compromise spreads.
Manual fallback is a security control. The September 2025 check-in disruption showed that rehearsed manual and degraded procedures keep flights departing when a supplier platform is down.
Several regimes overlap. EASA Part-IS for aerodrome operators, NIS2 for air transport entities, and national aviation security programmes may all apply to the same airport.

The airport system landscape

Airport systems split into passenger-facing IT, operational IT, and OT. The table lists the systems that most often drive operational impact, their owners and the typical consequence of loss.

System	Function	Typical owner	Impact if unavailable or manipulated
Airport operational database (AODB)	Master flight schedule, stand and gate allocation, feeds to every other system	Airport operator	Wrong or missing stand, gate, display and baggage data across the airport
Common use passenger processing (CUPPS, kiosks, bag drop)	Shared check-in desks, gates and self-service for many airlines	Airport operator or platform supplier	Check-in and boarding fall back to manual processing
Flight information display system (FIDS)	Departure, arrival and gate information	Airport operator	Passenger confusion; false information could direct crowds
Baggage handling system (BHS) and its controls	Conveyors, sortation, PLCs, SCADA, hold baggage screening interface	Airport operator with integrator	Bags not loaded or not screened; manual handling and delays
Hold baggage and passenger screening equipment	Security screening, networked image review	Airport or security provider	Screening stops; security programme obligations
Airfield ground lighting and its control system	Runway and taxiway lighting	Airport operator	Restricted operations in low visibility
Access control, CCTV, perimeter intrusion detection	Airside security boundary	Airport security	Weakened security boundary; regulatory breach
Building management, lifts, HVAC, fire systems	Terminal environment and life safety interfaces	Airport facilities	Terminal closure or evacuation
Fuel farm and hydrant controls	Aircraft fuel storage and distribution	Fuel consortium or operator	Fuelling stops; safety risk
Resource management, A-CDM and stand systems	Turnaround coordination, docking guidance	Airport operator	Turnaround delays, stand conflicts

Map each system's data flows, especially the AODB interfaces. Because so many systems take their schedule from the AODB, its integrity matters as much as its availability. See the Building Management System Security Guide for terminal building systems.

Threats airport operators plan for

Ransomware on operator or supplier IT: the most likely route to large-scale disruption, because passenger processing, AODB and resource systems run on ordinary Windows and Linux infrastructure, often hosted by a supplier.
Denial of service against public services: airport websites, flight information APIs and apps are visible targets; ACI World publishes airport guidance on reducing DDoS attacks. See the DDoS Protection Guide.
Remote access abuse: integrator and maintenance access to baggage, lighting and building systems, often installed for convenience and left running.
Data manipulation: false flight, gate or display data injected through an integration interface can move crowds or disrupt turnaround without any system being down.
Insiders and credential misuse: a large badge-holding workforce with access to airside systems and common use workstations.
Faulty updates and supplier outages: non-malicious failures of a shared platform produce the same operational effect as an attack and need the same fallback.

Zoning the airport network

Airports often grew a single flat network that carries airline, tenant, operator and OT traffic. Zoning reduces how far an incident spreads and makes supplier access manageable. ACI World lists NIST CSF 2.0, ISO/IEC 27001 and MITRE ATT&CK among the frameworks it points airports to; for the OT zones, IEC 62443 zones and conduits are the usual model. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Zone	Contents	Allowed conduits	Key controls
Corporate IT	Email, finance, HR, office devices	Internet, controlled links to operational IT	Standard enterprise controls, phishing-resistant MFA
Operational IT	AODB, FIDS, resource management, integration bus	Defined interfaces to passenger processing, OT DMZ, airlines	Change control, integrity monitoring, high availability
Passenger processing	Common use workstations, kiosks, bag drop, gate readers	Airline host connections via supplier networks	Locked-down endpoints, application allowlisting, separate admin paths
Security systems	Access control, CCTV, screening networks	Monitoring centre; minimal links to operational IT	Strict separation, separate identities, physical protection
Airport OT	BHS controls, airfield lighting, BMS, fuel, lifts	OT DMZ only; no direct internet	IEC 62443 zones, brokered remote access, passive monitoring
Tenant and public	Retail, lounges, public Wi-Fi, tenant offices	Internet only; no route to airport zones	Isolated VLANs or separate infrastructure, client isolation

Integration bus as a conduit: treat the message broker or integration platform between AODB, BHS, FIDS and airline systems as a security boundary, with authenticated, allowlisted interfaces.
Public Wi-Fi and tenants: never let public or tenant traffic share routing with operational zones; validate this with periodic testing.
Direct internet exposure: CISA's first primary OT mitigation is removing OT connections to the public internet; check BHS, lighting and BMS controllers explicitly, as these are often installed by contractors.

Third parties and shared platforms

An airport depends on suppliers that also serve its competitors and its airlines. On 19 September 2025, a ransomware incident affecting Collins Aerospace's MUSE passenger processing software, which lets airlines share check-in desks and boarding gates, disrupted check-in at several European airports including Berlin, Brussels and London Heathrow; ENISA described it as a third-party ransomware incident. One supplier compromise became a multi-airport event. The July 2024 CrowdStrike outage showed a similar concentration effect from a faulty update rather than an attack. See the Third-Party Concentration Risk Guide.

Classify suppliers by blast radius: passenger processing, AODB, BHS integrator, security systems, network provider and cloud hosting are tier one. NIST CSF 2.0 GV.SC-07 expects these risks to be understood, recorded and prioritised.
Contract for security and recovery: require incident notification times, recovery time objectives, offline fallback modes, evidence of testing, and the right to audit (GV.SC-05).
Know where the platform runs: on-premises, supplier hosted or cloud, and which parts keep working if the supplier's central services are down.
Broker all supplier remote access: named accounts, MFA, time-limited approval and session recording, never shared or always-on VPN accounts. See the OT Third-Party and Integrator Access Guide.
Coordinate with airlines and handlers: agree who declares an incident on a shared platform, who communicates with passengers, and how airline systems reconnect after recovery.

Where identity fits

Airports issue identities to a very large and changing population: airline and handler staff on common use workstations, contractors, tenant staff, and the service accounts and API keys that connect the AODB to airlines, BHS and display systems. The highest-risk identities are often non-human: integration accounts with write access to flight data, supplier support accounts on passenger processing platforms, and shared credentials on BHS and BMS controllers. Inventory them, give each an owner, restrict them to the interfaces they serve, and rotate their secrets. Link airside ID pass status to logical access so leavers lose both at once. See the Transportation Identity and OT Access Guide and the Service Account Security Guide.

Operating in degraded mode

Airports can keep flying through most IT failures if staff can fall back to manual processes. CISA lists the ability to operate OT systems manually among its five primary mitigations, and the same principle applies to passenger processing.

Function	Degraded mode	What must be prepared
Check-in and boarding	Manual check-in, handwritten or pre-printed boarding passes, paper passenger lists	Printed stock, offline passenger manifests from airlines, trained staff, extra desk staffing rota
Baggage	Manual sortation, manual tagging, reduced flows	Labour plan, screening procedures agreed with the security regulator, labelling stock
Flight information	Static or manually updated displays, public address	Independent display path, announcement scripts
Stand and gate allocation	Whiteboard or spreadsheet in the operations centre	Offline copy of the day's schedule exported at fixed intervals
Access control	Guarded manual checks at key portals	Security staffing plan, offline list of valid passes

Exercise these procedures with airlines and handlers at least annually, and measure how many departures per hour the airport can sustain in each mode. That number informs both the recovery time objective and the conversation with suppliers.

Obligations that apply to airports

Requirements depend on jurisdiction and are covered in depth in the Aviation Cybersecurity Guide. In summary, as checked in October 2026:

EASA Part-IS for aerodrome operators: Delegated Regulation (EU) 2022/1645 sets information security management requirements for aerodrome operators and other organisations, with an entry-into-force date on EUR-Lex of 16 October 2025. It expects an ISMS focused on risks to aviation safety, incident detection and reporting. See the EASA Part-IS Guide.
NIS2: air transport is a sector of high criticality under Directive (EU) 2022/2555. Its recitals describe an early warning within 24 hours, an incident notification within 72 hours and a final report within one month for significant incidents. Check national transposition. See the NIS2 Directive Guide.
National aviation security programmes: the UK CAA cyber oversight process and US TSA requirements for regulated airport operators also apply where relevant; confirm the current versions with the regulator.

How to implement

Inventory and dependency map (months 0 to 3): list every system in the landscape table with owner, supplier, hosting, interfaces and degraded mode.
Quick wins (months 0 to 3): remove internet exposure of OT controllers, revoke shared supplier accounts, enforce MFA on all remote access.
Zoning (months 3 to 12): separate tenant and public networks first, then OT, then security systems, using firewall rules in monitor mode before enforcement and with a rollback plan per change window.
Supplier programme (months 3 to 12): tier suppliers, update contracts at renewal, and run joint incident exercises with tier one suppliers.
Monitoring (months 6 to 18): passive OT monitoring for BHS and airfield systems; SOC coverage for operational IT and passenger processing. See the OT Network Security Monitoring Guide.
Resilience (ongoing): degraded mode exercises, offline schedule exports, backup and restore tests for AODB and BHS controls. See the OT Backup, Recovery and Golden Image Guide.

Small regional airports: rely heavily on supplier-hosted platforms; focus on contracts, remote access control, network separation of tenants and rehearsed manual procedures.
Large hubs: run their own SOC with OT coverage, maintain an airport-wide cyber incident plan with airlines, and test integration bus failure scenarios.

Detection and measurement

Monitor: AODB interface errors and unusual data changes, supplier remote sessions, new devices on OT and security networks, controller logic changes in BHS, authentication anomalies on common use workstations, and DDoS against public websites and apps.
Metrics: percentage of tier one suppliers with tested fallback and notification terms; number of OT devices reachable from the internet (target zero); percentage of supplier remote sessions brokered and recorded; departures per hour achieved in the last degraded mode exercise; time to restore AODB from backup in tests; and number of shared or unowned service accounts.

Framework mapping

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK for ICS
Inventory and dependencies	ID.AM-01, ID.AM-02, GV.OC-04	CM-8	n/a
Supplier risk	GV.SC-05, GV.SC-07	SR-6	n/a
Zoning and remote access	PR.IR-01	SC-7, AC-17	T0822 External Remote Services, T0883 Internet Accessible Device, T0886 Remote Services
Resilience and degraded mode	PR.IR-03, RC.CO-03	CP-2	T0814 Denial of Service
Incident coordination	RS.CO-02	IR-4	n/a

Common failure patterns

Single shared platform with no fallback: passenger processing fails across all airlines and staff have not practised manual check-in.
Contractor-installed OT on the internet: baggage or lighting controllers reachable for remote support with default credentials.
Flat landlord network: tenant or public Wi-Fi segments can route to operational systems.
Always-on supplier VPNs: shared integrator accounts that nobody reviews, a pattern also seen in the Colonial Pipeline Ransomware Attack, where an unused VPN account was the way in.
Unclear incident ownership: the airport, the platform supplier and airlines each wait for another to declare and communicate.

Lessons from incidents

The September 2025 MUSE disruption is the clearest recent example for airport operators: the compromised system belonged to a supplier, the impact landed on several airports at once, and recovery depended on the supplier while operations depended on manual procedures. The lessons are to know which shared platforms you depend on, to contract for notification and fallback, and to rehearse degraded mode with airlines and handlers before it is needed. A further lesson is about communication: passengers judge the airport, not the supplier, so the airport's incident plan needs prepared public messages and a single spokesperson even when the root cause sits elsewhere.

Practitioner checklist

Map every airport system, owner, supplier and interface, starting with the AODB.
Remove internet exposure and default credentials from BHS, lighting, BMS and fuel controllers.
Separate tenant and public networks from all airport operational zones.
Broker, time-limit and record all supplier remote access with MFA.
Tier suppliers by blast radius and contract for notification, recovery and fallback.
Inventory and own every integration account and API key touching flight data.
Rehearse manual check-in, baggage and display procedures with airlines annually.
Agree airport-wide incident roles with airlines, handlers and platform suppliers.
Map obligations under Part-IS, NIS2 and national aviation security programmes.

Airport Cybersecurity Guide: Shared Systems, Suppliers and Regulation