A connected airport shouldn’t treat every system as part of one trusted network. Airport OT network segmentation separates operational assets into zones and limits communication to what each task requires. If an IT system is compromised, well-designed boundaries can help contain the incident and protect the continuity of airport operations.
That separation matters because baggage handling, access control, building systems and business IT have different roles, even when they need to exchange information. In an airport, controlling connections means accounting for devices, network paths and operational dependencies.
This article explains how asset groups and least-privilege policies shape segmentation, how Purdue levels can help organise zones, and why IT/OT convergence needs clear boundaries. It also applies these principles to airport control systems, where security decisions must support safe, reliable operation.
Key Takeaways
- Group airport assets by operational role, ownership and location so communication rules reflect how each system is used.
- Apply least-privilege policies to permit only necessary connections, while accounting for the operational impact of restricting access.
- Use Purdue zones to distinguish field devices, supervisory control, site operations and enterprise networks, with carefully controlled links between them.
- Plan IT and OT boundaries around real system dependencies; control systems design and SCADA integration can help align those boundaries with airport operations.
Asset grouping and least-privilege policies
Modern airports rely on many hardware assets for passenger processing, baggage handling, surveillance, communications and access control. Grouping devices by operational role, location and ownership gives segmentation a practical foundation. Inventories can quickly become outdated as airlines, vendors, contractors and tenants change, so asset visibility needs regular attention.
Communication mapping for asset groups
Communication mapping records which devices exchange data, which protocols they use and the purpose of each connection. At an airport, this can distinguish baggage handling equipment from CCTV and access-control systems while identifying approved links between them. The map helps define asset groups around real operational dependencies rather than broad labels.
Real-time asset discovery can reveal devices added or moved since the last inventory. Monitoring assets, protocols and network activity helps identify unexpected communications or abnormal behaviour. Because a MAC address can be spoofed, it is not proof of a device’s physical identity. Role, location and ownership provide important context when investigating a vulnerability.
Least-privilege policies for isolated zones
Least-privilege policies allow each device to communicate only with the systems and services required for its task. Separate baggage handling, surveillance, communications, access control and passenger-processing systems into OT zones according to their roles and necessary connections. To decide which airport systems to isolate, group operational assets by function, then restrict links between groups to approved needs.
For example, a baggage-control device should not have unrestricted access to business IT just because the networks exchange information. Define the permitted source, destination and protocol for each necessary connection, then monitor for traffic outside that pattern. Check devices against their expected role, location and ownership, and review zone assignments when airport tenants, vendors or equipment change. This makes segmentation more precise without overlooking communications essential to airport operations.
OT/IT convergence and expanded attack surfaces
Airport services increasingly connect operational technology with enterprise IT, remote access and wireless systems. This convergence supports data exchange, but can also create routes from compromised business systems to operational equipment.
IT-OT convergence
IT/OT convergence links information technology, which handles business data, with operational technology, which controls physical processes. At an airport, flight information displays may draw data from IT systems, while baggage handling depends on OT control networks. These connections support coordinated services, but a weakness in one environment can affect another if network boundaries are poorly defined.
Consider a supplier’s remote connection for maintaining an airport system. If access extends beyond its intended purpose, an incident affecting the supplier or an IT account could expose connected OT. Clear separation, controlled access paths and ongoing monitoring help teams understand which connections are active and whether they meet operational needs.
The expanded airport network attack surface
An airport network’s attack surface includes every connected system and pathway that could be used to reach airport services. This may include baggage control, CCTV, building automation, passenger processing, wireless connections and vendor access. Each connection makes visibility and access controls important, particularly when systems are managed by separate airport authorities, airlines, tenants or suppliers.
Convergence can turn an issue in one area into disruption elsewhere. For example, access to a corporate network should not automatically provide a route to building automation or baggage systems. Separating these environments limits unnecessary pathways, while monitoring traffic between them can help identify unusual activity before it affects airport operations.
Industrial environments also contain devices that cannot support conventional security agents, so visibility must account for the equipment and its network behaviour. A sound design identifies critical dependencies, restricts remote connections to their intended purpose and considers the operational consequences of a compromised system. This ties cybersecurity decisions to safe airport operation, rather than treating every connection as equally acceptable.
Purdue Enterprise Reference Architecture zones
The Purdue Enterprise Reference Architecture organises industrial networks into levels, from field equipment to enterprise IT. For airports, this model helps structure zones around operational roles and control traffic between connected systems.
OT network architecture planning
OT network architecture planning assigns airport infrastructure to levels according to each system’s function and operational dependencies. Level 0 includes sensors and actuators controlling physical processes; Levels 0-1 cover field devices, Level 2 supervisory control, and Level 3 site operations. Levels 4-5 represent business logistics, enterprise IT and cloud, with Level 5 also representing public networks such as the Internet.
This hierarchy gives design teams a framework for separating critical infrastructure without treating every airport system alike. For example, baggage-handling controls can remain within operational zones, whilst approved information flows reach business platforms through controlled boundaries. ANSI/ISA 62443-3-2 offers additional guidance for creating zones and conduits, helping architecture planning relate system function to permitted communications.
Firewall and DMZ architecture
A demilitarised zone, or DMZ, provides a controlled intermediary between corporate networks and ICS or OT networks. Industrial network architecture commonly places the DMZ between these environments, with connections terminating there rather than passing directly through. The DMZ is sometimes referred to as Level 3.5, between site operations and enterprise IT.
Firewalls at these boundaries can enforce access control by allowing only defined traffic between specific systems. For instance, data needed by an airport operations platform can terminate in the DMZ, rather than creating unrestricted access to control equipment. This limits direct pathways and makes traffic across the boundary easier to monitor.
A scalable airport deployment applies the same Purdue structure to each operational area, then defines the necessary conduits between zones. Baggage handling, access control and building systems can retain distinct boundaries while supporting approved data exchanges. When new connected systems are introduced, teams can assess their role and dependencies against the existing levels instead of extending broad network access by default.
As a planning model, Purdue levels help relate firewall placement to airport operations: field devices sit closer to the physical process, while enterprise services remain further removed. The architecture should preserve required control communications and make each cross-zone connection purposeful. This balance supports resilient airport infrastructure while keeping OT systems distinct from public and business networks.
Airport network segmentation
Segmentation divides airport networks into controlled areas, limiting routes between operational technology and other systems. Its value lies in containing cyber threats while preserving the communications airport operations require.
Assessment and implementation steps
Assessment and implementation define critical systems, map dependencies and introduce boundaries in a planned sequence. First, identify airport OT assets and classify them by operational function. Next, map required communications, including vendor connections, and design zones around those dependencies. Apply access rules to approved traffic, then validate system behaviour and recovery procedures before enabling changes across live environments.
Segmentation costs and price factors
The price depends on the case and is given after a quote request; it varies with the existing network, asset visibility, system dependencies and implementation scope. For example, an airport with documented zones and clear connection records has different design needs from one with unmanaged devices and undocumented links. Integration requirements, testing arrangements and the need to maintain operational continuity also shape the work involved.
Testing segmentation without disruption
Airports can test boundaries through passive monitoring, planned validation and rollback arrangements. Passive monitoring observes network traffic without interfering with active terminal operations, helping teams compare actual communications with intended rules. Schedule phased changes around established maintenance windows, then validate affected workflows with relevant vendors. Before fully enabling controls, test rollback procedures so teams can restore the prior configuration if baggage handling or access management is affected.
Monitoring airport OT segmentation
Monitoring checks whether devices, protocols and traffic continue to match approved operational patterns. Ongoing visibility can reveal an unexpected connection, a device appearing in the wrong zone or abnormal activity crossing a firewall. Teams can assess the affected system’s function and prioritise their response by operational impact, rather than treating every alert as equally urgent.
Review vendor and remote access alongside zone traffic, since changes to either can create new paths into OT environments. Test incident response and operational recovery procedures as part of ongoing oversight. For project-specific planning, discuss airport control-system architecture.
AAC LTD | All About Control
AAC LTD | All About Control helps airport teams turn segmentation principles into practical control-system architecture. Its automation engineering consultancy and control systems design support planning across the project lifecycle, aligning network boundaries with operational requirements and system dependencies.
For airports integrating or upgrading operational technology, SCADA integration and Mission Critical Control Systems can help address how control platforms connect, exchange data and support essential processes. Siemens S5 to S7 Migration is relevant where legacy control systems form part of the environment being modernised. The appropriate scope depends on the systems involved and the operational objectives.
If you are planning airport network changes or reviewing control-system architecture, contact AAC LTD | All About Control to discuss your requirements.
Make segmentation part of the next design decision
Network boundaries are most useful when they reflect how airport systems operate, not simply how they appear on a diagram. Treat airport OT network segmentation as an evolving design consideration: changes to equipment, connections and operating requirements can alter which pathways remain necessary. Regularly reviewing the design helps keep security controls aligned with operational priorities as airport systems develop.
For airport teams assessing a new control-system project or a legacy environment, the next step is to bring network requirements into the engineering discussion early. That creates space to consider system dependencies, intended data flows and operational constraints before design decisions become difficult to change. AAC LTD | All About Control can discuss how its engineering work relates to your airport’s control-system requirements. Contact AAC LTD | All About Control to discuss your project and take the next step with a clear engineering focus.
Frequently Asked Questions
Why is network segmentation important?
Network segmentation limits how far an incident can spread between connected systems. For example, if a business application is compromised, defined boundaries can prevent that access from automatically reaching baggage controls or building systems. This reduces the chance that one cyber incident affects unrelated airport functions and helps operations teams focus investigation and recovery on the systems involved.
What is the Purdue Model and how does it relate to segmentation?
The Purdue Model organises industrial network functions into levels, from physical process equipment to enterprise systems. In an airport, it can help teams distinguish field controls from supervisory systems and business platforms when designing boundaries. It is a planning framework, not a complete network design: actual zones and permitted connections must reflect the airport’s systems and dependencies.
What is the difference between IT and OT networks?
IT networks primarily process and exchange information, such as business records or operational data, while OT networks monitor or control physical processes. Airport business applications and administrative systems are examples of IT; baggage-control equipment and building automation are examples of OT. The distinction matters because OT changes can affect physical operations, so network controls must account for operational dependencies as well as information security.
What is OT network segmentation in an airport?
Airport OT network segmentation separates operational systems into controlled network areas, with specific rules governing communication between them. For instance, baggage handling, access control and building automation can be treated as distinct operational groups rather than sharing unrestricted network access. The design defines which connections support essential functions and puts boundaries around those flows, helping contain problems without blocking legitimate system-to-system communication.
Why do airports segment OT networks from IT and public networks?
Separating OT from IT and public networks reduces direct pathways from widely connected systems to operational equipment. A public-facing service or corporate account may face different threats from a baggage-control network. Boundaries help prevent that exposure from becoming direct access to operational systems, while carefully designed connections still let airport services exchange the information they need.
What cybersecurity standards and regulations apply to airport OT segmentation in the United States?
In the United States, TSA aviation cybersecurity directives and amendments address segmentation for regulated aviation operators. The measures include segmentation, access controls, continuous monitoring and detection, and timely security updates for critical cyber systems; affected operators must also develop an approved implementation plan. NIST guidance and ANSI/ISA 62443-3-2 offer useful architecture guidance, but standards and TSA requirements have different roles and scopes.
