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:
- Overlay network segmentation — Deploy Access Gate appliances that create encrypted overlay segments without changing the physical network topology or any device configurations
- Identity-based access control — Every connection to a BHS controller requires authentication, even from within the "trusted" network
- Micro-segmentation by function — Separate screening integration controllers from sortation PLCs from HMI workstations, each in their own zero-trust segment
- 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
| Factor | Traditional Approach (Agent-Based) | Network-Level Approach (Access Gate) |
|---|---|---|
| Requalification risk | High — installing agents on certified PLCs triggers recertification | None — no changes to certified equipment |
| Downtime required | Hours to days per device for agent deployment and testing | Zero — overlay deploys alongside running systems |
| Cost | $500K–$5M requalification + agent licensing | Appliance deployment only, no requalification |
| Coverage | Limited to devices that support agents (excludes legacy PLCs) | Full coverage including legacy and embedded systems |
| Compliance (NIS2) | Partial — gaps on unsupported devices | Full — network-level controls cover all connected assets |
| Vendor access control | Requires endpoint changes or separate PAM tools | Built-in just-in-time access brokering |
| Time to deploy | 6–18 months including requalification | Days 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:
- Deploy in monitor mode first — Observe traffic patterns and map communication flows before enforcing any policies
- Work with the system integrator — They know the communication requirements between BHS subsystems
- Start with vendor access — The highest-risk vector (always-on VPN tunnels) is also the easiest to address first
- Segment progressively — Move from coarse segmentation (BHS vs. non-BHS) to fine-grained micro-segmentation over weeks
- 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.

