TroutTrout
Back to Blog
TransportationAirportOT Security

Securing Airport Baggage Handling Systems Without Requalification

Trout Team6 min read

The Problem with Securing Baggage Handling Systems

Airport Baggage Handling Systems (BHS) are some of the most complex OT installations in transportation infrastructure. A large international hub processes 50,000+ bags per day through a network of conveyor belts, sortation units, screening integration points, and destination-coded vehicles — all orchestrated by PLCs and SCADA controllers that were certified under strict aviation safety standards years ago.

These controllers work. They passed certification. And that certification is the reason they are almost impossible to secure with conventional cybersecurity tools.

What Requalification Actually Means

Requalification is the process of re-certifying that a safety-critical system still meets its original certification requirements after a modification. For BHS, this certification typically falls under:

  • ECAC Doc 30 requirements for screening integration
  • TSA/CATSA mandates for checked baggage inspection systems
  • Airport authority acceptance testing protocols
  • Equipment manufacturer warranty conditions

Any modification to a certified system — including installing a software agent, changing a network configuration on the controller, or updating firmware — can trigger requalification. The cost is not abstract:

  • Timeline: 3–12 months of testing and documentation
  • Direct cost: $500K–$5M depending on system scope
  • Operational risk: Potential BHS downtime during retesting
  • Regulatory risk: Operating with a lapsed certification during the gap

Most airport operators and their system integrators will not touch certified BHS equipment for security purposes. The risk/reward calculation does not work.

Why BHS Networks Are Vulnerable

The certification constraint creates a security paradox. The systems that matter most are the ones you cannot protect with endpoint tools. BHS networks typically exhibit:

  • Flat network architecture — PLCs, HMIs, and SCADA servers share a single broadcast domain
  • No authentication — Modbus TCP and proprietary protocols have no built-in authentication
  • Long lifecycle equipment — Controllers running Windows XP Embedded or VxWorks with no patch path
  • Vendor remote access — System integrators maintain always-on VPN tunnels for maintenance
  • 24/7 operations — No maintenance windows for security changes

An attacker who gains access to the BHS network — through a compromised HMI, a vendor VPN, or lateral movement from airport IT — can reach every controller on the unsegmented network.

The Network-Level Approach

The answer is to stop trying to secure the equipment and instead secure the network around it. This means:

  1. Overlay network segmentation — Deploy Access Gate appliances that create encrypted overlay segments without changing the physical network topology or any device configurations
  2. Identity-based access control — Every connection to a BHS controller requires authentication, even from within the "trusted" network
  3. Micro-segmentation by function — Separate screening integration controllers from sortation PLCs from HMI workstations, each in their own zero-trust segment
  4. Vendor access brokering — Replace always-on VPN tunnels with just-in-time, audited access sessions

None of these actions modify the BHS controllers. The PLCs continue to operate exactly as certified. The security enforcement happens at the network layer, on dedicated appliances that sit alongside the existing infrastructure.

Traditional vs. Network-Level Security for BHS

FactorTraditional Approach (Agent-Based)Network-Level Approach (Access Gate)
Requalification riskHigh — installing agents on certified PLCs triggers recertificationNone — no changes to certified equipment
Downtime requiredHours to days per device for agent deployment and testingZero — overlay deploys alongside running systems
Cost$500K–$5M requalification + agent licensingAppliance deployment only, no requalification
CoverageLimited to devices that support agents (excludes legacy PLCs)Full coverage including legacy and embedded systems
Compliance (NIS2)Partial — gaps on unsupported devicesFull — network-level controls cover all connected assets
Vendor access controlRequires endpoint changes or separate PAM toolsBuilt-in just-in-time access brokering
Time to deploy6–18 months including requalificationDays to weeks

Beyond BHS: Other Airport OT at Risk

BHS is the most requalification-sensitive system, but airports operate other OT networks that benefit from the same approach:

  • Flight Information Display Systems (FIDS) — Often running outdated Windows with direct network access to airline data feeds
  • Physical access control systems — Badge readers, mantraps, and vehicle gates on legacy protocols
  • Airfield lighting — Runway and taxiway lighting controlled by PLCs with no security controls
  • Building management systems — HVAC and fire suppression in terminals, often on networks with no internal boundaries, shared with other systems

Each of these can be segmented and secured at the network level without touching the endpoint equipment. Rail operators face a similar constraint with safety-certified signaling systems — our analysis of rail signaling cybersecurity covers that parallel challenge.

NIS2 Requirements for Airports

Under the NIS2 Directive — which is now actively enforced across the EU — airports and air carriers are classified as essential entities in the transport sector. This means mandatory requirements for:

  • Risk management measures (Article 21) — including network segmentation and access control
  • Incident reporting (Article 23) — 24-hour early warning, 72-hour incident notification
  • Supply chain security (Article 21(2)(d)) — covering vendor access to OT systems
  • Business continuity (Article 21(2)(c)) — ensuring BHS and other critical systems remain operational

Network-level security directly addresses the risk management and supply chain requirements without creating the operational risk that endpoint modification would introduce.

Making It Work in Practice

Deploying network-level security in a live BHS environment requires respecting operational constraints:

  1. Deploy in monitor mode first — Observe traffic patterns and map communication flows before enforcing any policies
  2. Work with the system integrator — They know the communication requirements between BHS subsystems
  3. Start with vendor access — The highest-risk vector (always-on VPN tunnels) is also the easiest to address first
  4. Segment progressively — Move from coarse segmentation (BHS vs. non-BHS) to fine-grained micro-segmentation over weeks
  5. Document everything — NIS2 auditors want evidence of controls, not just their existence

Airport BHS security is not a technology problem. It is a constraint satisfaction problem. The constraint is requalification. The solution is to enforce security where you have freedom to act — the network — and leave certified equipment untouched.