Drone detection & counter-UAS for airports & critical infrastructure

Small unmanned aircraft are cheap, quiet and hard to see, yet a single sighting can close an airport runway or halt a prison, stadium or power plant. Multi-sensor detection systems fuse radar, radio-frequency (RF), camera and acoustic data with ML to detect and classify drones, estimate pilot position and give operators a ranked picture. This file covers the detection, classification and decision-support layer; kinetic or electronic defeat is a sovereign/police task and is only discussed at policy level.

Problem & value

• Today: airports and critical-infrastructure operators rely on staff sightings, police calls and CCTV. Sightings are late, unverified and often false (birds, balloons, aircraft lights). Each disruption causes diversions, closed runways and costly security responses.
• AI value: continuous automatic detection of small, slow, low-altitude targets; classification (drone vs. bird vs. clutter, model identification from RF fingerprint); track fusion across sensors; fewer false alarms; evidence for authorities; faster, more consistent operator decisions.
• Why now in the EU: the European Commission's counter-UAS communication (2023) and follow-up work (including guidance for protecting critical entities) put drone threats on the policy agenda, and repeated airport disruptions in Europe in 2025 raised demand for permanent detection at airports and other sites [1][2]. In Germany, DFS, Fraport and Munich Airport tested six drone-detection systems for four months at Frankfurt and Munich in 2020 and found no one-size-fits-all solution; the federal police has operated a drone-defence system at Frankfurt Airport since around the turn of 2024/25 [10][11].
• Benefit figures: public, independently audited detection-rate or false-alarm statistics are scarce; treat vendor claims as site-dependent and test on your own site (see Getting started).

Variants

• Airports: detection in approach/departure corridors and around the perimeter, integration with ATC, airport operations (A-CDM) and police; strict coordination with the national aviation authority because RF emitters can disturb aviation systems.
• Critical infrastructure (KRITIS / critical entities): power plants, substations, refineries, data centres, ports and water works; detection plus incident reporting duties under NIS2 / CER, and the Commission's counter-drone guidance for critical entities [3][4].
• Prisons and secure sites: contraband-delivery detection, low-altitude and short-range focus, often RF- and camera-heavy.
• Events and stadiums: temporary deployments with portable sensors, public-safety coordination, strong privacy constraints on camera use.
• Mobile/convoy and border use: vehicle-mounted systems; defence applications are out of scope here (see VIS-051 for ISR imagery).

How it works

1. sensors: radar + RF receiver + Remote ID receiver + EO/IR PTZ camera + acoustic array
2. per-sensor detection (radar micro-Doppler classifier, RF protocol/fingerprint, camera detector, acoustic classifier)
3. track association and multi-sensor fusion (Kalman/IMM filters, learned association)
4. classification & threat scoring (drone type, cooperative vs. non-cooperative, zone, behaviour)
5. deconfliction (ADS-B, registered Remote ID, authorised operations list)
6. operator console: map, camera slew-to-cue, alert, evidence recording
7. human decision and escalation (airport ops, police, ATC); any mitigation by authorised bodies only

• Radar: small 3D radars detect targets by Doppler signature; ML on micro-Doppler separates rotor blades from bird wing-beats.
• RF: wideband receivers detect control/video links and decode protocols (and Remote ID broadcasts); ML fingerprints known models. Fully autonomous or pre-programmed drones emit little or no RF and need radar/EO/acoustic.
• EO/IR cameras: small-object detectors (YOLO-class, transformer detectors) and trackers, cued by radar to point the PTZ camera; thermal channel for night.
• Acoustic: microphone arrays classify rotor sound at short range; limited by wind and airport noise.
• Human-in-the-loop: operators confirm classification and decide on escalation. Automated alerting is fine; automated defeat measures are not a task for the detection system or its operator, and legal authority differs by member state.

Data preparation

Data come from the sensors themselves (radar tracks, RF scans, EO/IR video, acoustic arrays) plus site information: maps, no-fly zones, flight data and approved drone registrations. They sit in the vendor system, a video management system, and in site plans on file shares or paper. Preparing data is therefore less about archives and more about site setup and calibration.

Typical gaps: no recorded baseline of normal airspace activity (birds, helicopters, authorised drones), uncalibrated sensor positions, no labelled recordings of real drone events, missing time synchronisation between sensors, and scattered incident logs. Access rights to video and logs are often unclear.

Preparation steps: (1) record a baseline for several weeks and label false-alarm sources, see PREP-020 and PREP-018; (2) synchronise sensor clocks and coordinates and document the site layout; (3) digitise site plans, whitelists and procedures, see PREP-006 and PREP-010; (4) define access rights and retention for video and logs, see PREP-024; (5) pseudonymise or mask data used for training, see PREP-022; (6) capture operator feedback on alarms, see PREP-021. Roughly a third of the effort goes into data and calibration. Check with GUIDE-003.

Implementation paths

Which path for whom

• Enterprise: Path A, because airports and KRITIS operators need certified, tested sensor suites with regulator acceptance and vendor support, where integration matters more than algorithms.
• Public: Path A, because authorities must use certified, approved systems with clear responsibility, and the operational security context excludes ad-hoc builds.
• Developer: Path C, because integrators and researchers can build fusion and classification on open-source tracking and detection models running on edge hardware (HW2) with full control of the sensor data.

Path A — Buy (recommended)

• Integrated detection suites: Dedrone (now part of Axon; US with a large European base), Hensoldt (DE), Rohde & Schwarz ARDRONIS (DE), Robin Radar Systems (NL), Weibel (DK) radars, DroneShield (AU), Blighter (UK), Thales and Leonardo (large defence primes) and further EU start-ups entering the market. Mark EU vendors in procurement shortlists for sovereignty and export-control reasons.
• Selection criteria: independent test results (e.g. national test centres), RF-emission licensing, certification for airside use, open interfaces (ASTERIX, SAPIENT, ONVIF, REST), on-prem operation and data location, support SLAs.
• Choose A when: you are an airport, KRITIS operator or authority; integration, certification and regulator acceptance dominate over algorithms.

Path B — Build on cloud APIs

• Rarely suitable for real-time detection (latency, availability, security classification). Cloud fits offline analytics: incident review, VLM-based video summarisation (VIS-031), reporting, and fleet management of sensors. Use EU regions only; no sensor control loop in the cloud.

Path C — Self-host (open source)

• Camera layer: Ultralytics YOLO or RT-DETR variants fine-tuned for small aerial targets, trackers such as ByteTrack/BoT-SORT, deployment via TensorRT/OpenVINO on edge devices; the Anti-UAV benchmark provides open data [5].
• RF/radar layer: software-defined radios (USRP, HackRF-class) with open DSP toolchains for research and test; fusion via ROS 2 or custom streaming services. Open stacks reach lab/pilot level; production-grade radar hardware is purchased.
• Hardware: HW1 at the sensor edge (Jetson-class), HW2 for fusion/operator server.

Path D — Custom training

Worth it for site-specific clutter (birds, wind turbines, cranes) and for new drone types: collect and label your own radar, RF and video recordings over months across seasons and weather. Data is mostly self-recorded; synthetic data and flights of friendly drones augment rare cases. Retraining must be validated against a fixed test set before updates go live.

State of the art (2026)

• Multi-sensor fusion is the accepted approach; no single sensor is sufficient. Radar-cued cameras and RF fingerprinting have become standard options in commercial suites.
• Remote ID and U-space in the EU make cooperative drones identifiable, shifting the problem to non-cooperative or spoofed targets [6].
• Interoperability standards (e.g. NATO SAPIENT for sensor integration) are spreading to civil procurement.
• Open benchmarks such as Anti-UAV (infrared tracking) exist, but real-world performance depends on site clutter [5].
• Limits and failure modes: birds and insects (radar and camera false alarms), urban RF clutter, wind and aircraft noise (acoustic), autonomous radio-silent drones, fibre-optic-controlled drones (no RF), low radar cross-section at close range, and weak pilot localisation when RF is absent. Detection range claims depend heavily on drone size, terrain and weather. Detection does not equal attribution or authority to act.

Shared resources & combinations

• Same stack (object-detection + tracking + streaming): VIS-010 perimeter and intrusion video, VIS-012 traffic analytics, VIS-031 natural-language search and summaries over camera feeds, VIS-060 camera-based bird collision avoidance (same bird/drone discrimination problem).
• Acoustic layer: SPEECH-009 audio event detection.
• Neighbours: ROBO-006 (the flying drone itself), VIS-045 X-ray security screening and VIS-051 ISR imagery for the wider security picture.
• Hardware: edge GPU boxes (HW1) per sensor cluster and one HW2 fusion server can be shared with other site-security analytics.

Effort, cost & KPIs

• Path A: 3–12 months from site survey and spectrum licensing to operation; costs driven by radar count, camera heads, integration and operator staffing (not by software licences alone).
• Path C/D: 12+ months and a specialised team; mostly suitable for research, test ranges or add-on camera analytics.
• KPIs: probability of detection by drone size and range, false alarms per day, time from first detection to operator confirmation, classification accuracy, track continuity, pilot-localisation success rate, operator workload, number of confirmed incidents with usable evidence.

People & change

Involve management and the security department lead first, as drone defence touches liability and aviation or police responsibilities. Bring in the security operators who will work with the alerts, IT and IT security (network separation, sensor hardening, see GUIDE-013), legal and compliance (radio licensing, responsibilities toward the authorities) and the DPO. Camera and RF data may capture people and staff, so a DPIA is likely and an AVV is required with vendors (GUIDE-005).

Works council: depends, but often yes. Cameras and logging in the control room are suited to monitor employees, so §87(1) no. 6 BetrVG applies under the BAG's objective suitability test; inform it under §90(1) no. 3 and agree on exclusions from performance evaluation (GUIDE-004). In public bodies the staff council applies. Active countermeasures are largely a task of the authorities in Germany, so keep the response chain human-led.

AI literacy: operators need exercises on alarm types, classification errors and escalation rules (Art. 4 AI Act, measures to support literacy, GUIDE-006). Run a pilot in monitor-only mode at one site (GUIDE-009). Typical concern: alarm fatigue and unclear responsibility. Address it with tuned thresholds, clear escalation plans and the principle that people decide on any response. See GUIDE-014 for AI Act obligations.

Risks, regulation & compliance

• EU AI Act: classification depends on use. Safety components in management and operation of critical infrastructure (Annex III point 2) can make AI systems high-risk; law-enforcement use is subject to Annex III point 6 duties. Detecting objects (drones) is not itself a prohibited practice, but Art. 5 prohibitions must be checked if cameras are used for real-time remote biometric identification of persons (e.g. identifying pilots by face) in public spaces for law enforcement, which is prohibited except under narrow exceptions [7]. Do not add face recognition to drone-detection cameras. Military/national-security-only systems fall outside the Act.
• GDPR: drone pilots and bystanders can be identified through video, Remote ID (which broadcasts operator ID) and RF logs. Data protection impact assessment, purpose limitation, short retention of non-incident video, masking of areas not needed, signage and works-council involvement where employees are filmed.
• Aviation and spectrum law: radar and RF equipment need frequency licences; interference with aviation systems must be excluded; the EU drone framework (Reg. 2019/947) defines legal drone operations [6]. Jamming or taking over drones is lawful only for authorised bodies; in Germany the police and Bundeswehr roles are defined by federal law, and operators of airports or plants must not defeat drones themselves.
• NIS2 / CER: significant incidents must be reported; physical-security and resilience measures of critical entities should address drone threats [3][4].
• Security risks: sensor feeds are themselves targets (spoofing of Remote ID, GNSS spoofing, adversarial patterns). Segment networks, log all alerts and keep human control of escalation.
• Mitigations: documented operating concept with police and aviation authority, regular recorded test flights, threshold tuning per site, audit logs, and fall-back to manual procedures.

Getting started

1. Run a threat and legal assessment with the aviation authority, police and (for KRITIS) the competent regulator; define who may act on alerts.
2. Survey the site: airspace geometry, RF environment, bird activity, power and network at sensor positions.
3. Shortlist 2–3 suites (including EU vendors); require open interfaces and a live trial with controlled test flights.
4. Measure detection, false alarms and time-to-confirm over several weeks before go-live; write the DPIA and operating procedure.
5. Integrate with the security operations centre, airport operations and incident reporting; schedule regular drills.

Sources

1. European Commission — Communication "Countering threats posed by drones" (COM(2023) 659) — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023DC0659
2. European Commission DG HOME — Counter-drone policy and resources — https://home-affairs.ec.europa.eu/index_en
3. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
4. Directive (EU) 2022/2557 (Critical Entities Resilience) — https://eur-lex.europa.eu/eli/dir/2022/2557/oj
5. Anti-UAV benchmark — https://github.com/ZhaoJ9014/Anti-UAV
6. Implementing Regulation (EU) 2019/947 on rules for the operation of unmanned aircraft — https://eur-lex.europa.eu/eli/reg_impl/2019/947/oj
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Ultralytics YOLO — https://github.com/ultralytics/ultralytics
9. Dedrone — https://www.dedrone.com
10. aerotelegraph — In Frankfurt und München starten Drohnen-Abwehr-Tests (DFS, 2020) — https://www.aerotelegraph.com/in-frankfurt-und-muenchen-starten-drohnen-abwehr-tests
11. LOGISTIK HEUTE — Frankfurt Airport: Bundespolizei setzt Drohnen-Detektionssystem ein — https://logistik-heute.de/news/frankfurt-airport-bundespolizei-setzt-drohnen-detektionssystem-ein-277737.html