Counter-UAS capability is no longer an optional layer for principal port operators. The 2026 incident landscape, taken across the public reporting from at least three regional theatres, has established small-system aerial threat as a baseline planning case rather than a contingency. The question for port operators is not whether to deploy counter-UAS. It is which architecture to deploy, against which threat profile, and how to integrate the system with the existing perimeter defence stack without producing the layered systems pathology of false-positive saturation. This note draws on three anonymized engagements from the past 18 months.

Detection-track-defeat layered architecture in a port environment.

Source: UG UAE / illustrative.

01.I. THE OPERATIONAL PICTURE

Port environments present a counter-UAS problem distinct from other critical-infrastructure environments in three respects. The first is altitude congestion. Ports operate at altitudes shared with cranes, gantries, and harbour-craft mast systems, none of which are friendly to radar primaries calibrated for clean-airspace returns. The second is electromagnetic congestion. Ports run dense communications, navigation, and cargo-tracking emissions; counter-UAS RF detection layers must operate against a noise floor that an airfield perimeter does not encounter. The third is throughput sensitivity. A port that pauses operations for a counter-UAS response loses revenue at a rate that an industrial perimeter does not. Response doctrine must therefore be tuned to a higher false-positive cost than is typical for other CI environments.

These three constraints, taken together, mean that the counter-UAS architecture appropriate to a port is not the architecture appropriate to a refinery, a base, or a stadium. The vendor evaluations we have performed for port-operator clients have to be re-baselined against the port-specific constraint set, even when the vendors have credible track records in adjacent CI verticals.

02.II. ENGAGEMENT 1 / THE DETECTION-ONLY DEPLOYMENT

The first engagement, with an Indo-Pacific port operator, deployed a detection-only architecture: passive RF detection paired with a multi-static radar primary, integrated into the operator's existing security operations centre. No defeat layer. The decision was deliberate. The operator's threat profile, characterised against 24 months of incident reporting from the surrounding region, indicated that the dominant scenario was reconnaissance-grade overflight rather than kinetic incursion, and the regulatory environment did not support deployment of any defeat capability against airborne systems.

The architecture performed against the threat profile it was designed for. Detection volume aligned with the projected baseline within 12 percent. False-positive load, after the initial six-week tuning period, settled to a rate that did not generate operational drag on the SOC. The system gave the operator advance notice of incursion events sufficient to stage deconfliction with cargo-handling operations.

What the architecture did not do, and was not designed to do, was provide the operator with a kinetic option against the incursion. When a higher-grade incursion occurred 9 months into deployment, the operator's recourse was the local civil aviation authority and the local police, with the timelines those routes implied. The lesson is not that detection-only is wrong. It is that detection-only is correct only when the operator has accepted the response-time profile that detection-only implies, and has built operating doctrine around that acceptance.

03.III. ENGAGEMENT 2 / THE DETECT-TRACK-DEFEAT LAYERED SYSTEM

The second engagement, with a MENA port operator, deployed a layered detect-track-defeat architecture. Passive RF and EO/IR fused at the detection layer; multi-static radar with primary and secondary tracking at the track layer; directed RF and selective non-kinetic defeat at the defeat layer. Integration with the existing perimeter defence stack required 7 months of doctrinal alignment work in addition to the technical integration.

The doctrinal alignment was the harder problem. The defeat-authorisation chain had to be re-mapped against the operator's safety-of-life constraints, harbour-traffic rules, and adjacent civil-aviation corridors. The technical layer can detect, track, and defeat in seconds. The authorisation chain, on the day the engagement began, took minutes. The work of the engagement was reducing the authorisation latency to a band consistent with the kinetic threat profile, without removing the safeguards that justify the chain in the first place.

The deployment is now operational. The defeat layer has been employed against 23 confirmed incursions in the 14 months since acceptance. The operator's incident-handling time has dropped by a factor consistent with the integration work done. The principal observation is that the defeat layer is not the deliverable. The reduced authorisation latency, against an adversary moving in seconds, is the deliverable. The technology is the precondition for the doctrinal work, not the substitute for it.

04.IV. ENGAGEMENT 3 / THE TRAINING-AND-HANDOFF MODEL

The third engagement, with an EMEA port operator, was scoped differently. The operator had already procured a counter-UAS architecture from a tier-one vendor, and the vendor relationship had become difficult on operational support and personnel readiness. Our scope was to train the operator's existing security personnel against the deployed architecture, certify them against a written competence model, and hand off operational responsibility on a defined timeline.

The work surfaced two findings worth recording. The first is that vendor-issued training, on its own, is insufficient for sustained operational competence. The training had been delivered. The personnel had attended. The certification, when measured against scenario-based competence, was not held. The gap was not the vendor's deficiency; it was a structural consequence of the difference between platform familiarity and operational doctrine. Closing that gap required scenario-based exercises, structured debrief, and a written competence model that the operator could maintain after the handoff.

The second finding is that the handoff itself is a discipline. Most counter-UAS deployments in the public record degrade in operational quality within 12 months of vendor disengagement. The cause is not capability decay; it is doctrinal decay, as the operator's personnel rotate through the platform without the discipline structures that the original deployment carried. The handoff model addresses this by leaving in place a written doctrinal manual, a competence-review cadence, and a contingent recall provision that lets the operator request remedial work against measured drift.

The technology is the precondition for the doctrinal work, not the substitute for it.

05.V. FIVE LESSONS

  1. Architecture follows threat profile, not vendor capability. The wrong architecture for a port is the architecture optimised for a different CI vertical, even when the vendor delivers it competently.
  2. Authorisation latency is the binding constraint. Detection in seconds against authorisation in minutes is not a defended port. The doctrinal work to compress the chain is the substantive work of the engagement.
  3. False-positive cost in port environments is asymmetric. Operating doctrine must be tuned against a higher false-positive cost than the vendor specification typically anticipates.
  4. Detection-only is a posture decision, not a budget decision. Choosing detection-only is correct when the operator has accepted the response-time profile it implies and built doctrine accordingly.
  5. Handoff is a discipline. A counter-UAS deployment without a written doctrinal manual, a competence-review cadence, and a recall provision will degrade within 12 months, regardless of the platform.