Counter-Drone Architecture for Critical Infrastructure: A Layered Design Guide

Detect. Something is in the airspace that should not be.

Identify. It is a drone, not a bird, a balloon, or the site's own maintenance UAV — and it is this class of drone, on this heading, at this speed.

Decide. Someone with the legal authority to act, who is awake, who has been trained, and who has a rule set that covers this case, decides what to do.

Defeat. The system does the thing that stops it.

Each stage feeds the next. A failure at any one of them makes the other three irrelevant. This is the part that vendors do not put on the slide, because a vendor sells you one stage — usually the fourth — and the other three are your problem.

I have walked sites with excellent jammers and no radar. I have reviewed programmes with genuinely good detection coverage where the person who would receive the alert at three in the morning had no authority to do anything about it, and no written rule that told them who to call. Both of those facilities were, functionally, undefended. They had spent money; they had not built an architecture.

Stage one: detection, and why one sensor is never enough

Detection is where the money should go first, and it is where single-modality thinking does the most damage.

There are four practical detection modalities, and each of them is defeated by a different thing.

RF detection listens for the control link and the telemetry downlink. It is cheap relative to the alternatives, it often gives you a bearing on the operator as well as the aircraft, and it is the fastest way to get useful coverage. It is also the modality with the most catastrophic single failure mode: a drone that is not transmitting is invisible to it. Pre-programmed autonomous flight defeats it. Fibre-optic control defeats it completely, which is a problem I have written about separately, because it is the countermeasure that changed the picture most in the last two years.

Radar detects the airframe itself, regardless of what it is transmitting. It does not care about the control link. What it does care about is size, material and altitude: small, largely non-metallic aircraft flying low against ground clutter are exactly the target set that legacy radar was never designed for. This is the single most consistent finding across every theatre I have studied. Legacy counter-battery radar and conventional air defence cannot effectively engage small, low-altitude loitering munitions. That is not a criticism of the equipment; it is a statement about what it was built to do.

Acoustic sensing detects the sound signature of the propulsion. It has short range and it degrades in noise, which rules it out as a primary layer at an industrial site. It has one property nothing else has: it works in an RF-denied environment, and it works against a drone that is transmitting nothing at all. In a saturated or jammed environment — which is exactly the environment a serious attack creates — acoustic is sometimes the only modality still reporting.

Optical and infrared provide the identification that the other three cannot. RF tells you something is transmitting. Radar tells you something is flying. A camera on a slew-to-cue mount, pointed by one of the other sensors, tells you what it is — and in most legal frameworks, that is the difference between an alert and an authorised response.

The design rule follows directly: no single modality, and no two modalities that share a failure condition. RF plus acoustic is a genuinely complementary pair, because the thing that defeats one does not defeat the other. RF plus RF-triggered cameras is not a pair at all; it is one sensor with an accessory.

Stage two: identification, and the classification problem nobody budgets for

Detection produces contacts. Identification turns contacts into decisions. Between them sits the least glamorous and most consequential part of the system: the classification library and the person reading it.

A facility with good detection and poor identification generates alerts it cannot act on. Within about three weeks, the operators stop treating alerts as meaningful, because most of them have been birds, weather, the neighbouring site's survey flight, or the facility's own inspection drone that nobody told the security desk about. This is not a hypothetical failure mode. It is the normal outcome, and it is a design failure, not an operator failure.

Three things prevent it, and none of them is a purchase.

A known-friendly register. Every drone that is authorised to fly over or near the site is registered, with its RF signature and its flight windows, and the system knows it. If the facility flies its own inspection UAV, that is the first entry.

A local baseline. What normally moves through this airspace? Which birds, at what times, on what routes? Which commercial flight paths clip the edge of the coverage? A system tuned in a laboratory and dropped onto a site produces noise until it is tuned against that site.

A confidence discipline. Every contact should carry an explicit confidence level, and the response rules should be written against confidence bands, not against raw contacts. "High confidence, hostile class, closing" and "low confidence, unclassified, transiting" are different events, and a system that presents them identically has thrown away the analysis it just performed.

That last point is the same discipline I apply to published intelligence, for the same reason: an assessment that does not state how sure it is forces the reader to guess, and people guess in the direction of whatever they already believed.

Stage three: decide — the stage that is almost always the weakest

This is the stage that is not a technology problem at all, and it is where most programmes actually fail.

Ask the following questions of any facility that believes it has a counter-drone capability:

• At 03:00 on a Friday, who receives the alert?
• What is that person authorised to do without waking anyone?
• What are they authorised to do after waking someone, and who is that person, and what is the number?
• Is any electronic countermeasure legal for this operator, at this site, in this jurisdiction?
• What happens when the drone is over the fence line but the operator is standing on public ground outside it?
• Who talks to the police, and at what point?

I have never reviewed a site where all six had written answers. I have reviewed several where the equipment was excellent.

The rules of engagement have to exist on paper, they have to be specific to the site's legal position, and they have to be rehearsed. In most jurisdictions the legal envelope is considerably narrower than the technical one — a great deal of what a counter-UAS system can do is not something a private operator may do. Designing a defeat layer without first establishing that envelope produces expensive equipment that nobody is permitted to switch on.

Stage four: defeat — deliberately last

Defeat is the stage everyone wants to discuss first and the one that should be specified last, because its correct shape is entirely determined by the three stages above it.

RF jamming severs the control link. Against a link-dependent drone it is effective and it is fast. Its two limitations are decisive: it does nothing against an aircraft that is not using the link it is jamming, and its effects do not respect the fence line. Jamming near an airport, a hospital, a port control tower, or a residential district creates a second-order safety problem that can be worse than the first-order one.

GPS spoofing and navigation interference attack the aircraft's understanding of where it is rather than its connection to its operator. Against certain platforms this is more elegant than jamming, and it can produce a controlled outcome rather than an uncontrolled fall. It carries the same collateral question, in a different form.

Cyber takeover — asserting control of the aircraft through its own protocol — is the cleanest outcome when it works, and it is platform-specific, which means it works against a known list and not against anything else.

Kinetic countermeasures are the last resort, and at a critical infrastructure site the debris problem is frequently worse than the drone. A neutralised aircraft falling into a tank farm has not been neutralised.

Physical barriers are the layer almost every architecture omits, and the one I have spent five years arguing for. A physical net perimeter does not care how the aircraft navigates, whether it is transmitting, whether the jammers are saturated, or whether the operator is standing outside the fence. It fails only physically. That property — indifference to the electronic environment — is the entire argument, and it is the foundation of the Shield Curtain doctrine, which exists because the electronic layers alone stop working precisely when they are most needed.

The economics, which decide the architecture

Every design decision above is constrained by an arithmetic that does not favour the defender.

In Ukraine, a Lancet costs roughly $30,000–35,000 per unit against $700,000–$1,000,000+ per M777 howitzer destroyed — a ~30-to-1 cost ratio in the attacker's favour, and Lancet has confirmed kills on 200+ Ukrainian armoured vehicles and artillery systems. In Yemen, Houthi drones costing $5,000–20,000 forced Saudi Patriot interceptors costing $3,000,000+ per launch.

Read those figures as a design constraint rather than as a statistic. Any architecture whose primary defeat mechanism costs more per engagement than the threat costs to build is an architecture the attacker can bankrupt at will. That is not a hypothetical: it is what the Yemen numbers describe. An interceptor-first design is a design with a losing exchange rate baked into it, and the attacker chooses the number of engagements.

The conclusion is not that interceptors are useless. It is that they cannot be the load-bearing element. Detection has to be cheap and layered. Identification has to be good enough to prevent expensive responses to non-threats. And the defeat layer has to include at least one mechanism whose cost per engagement does not scale with the number of engagements — which, in practice, means something physical.

Saturation: the case the architecture must survive

There is one more design case, and it is the one that most programmes are not built for.

In March 2026, more than 3,000 drones and missiles were launched against all six GCC states in 36 hours — the largest drone warfare event in history.

A defence sized for the single-intruder case behaves very differently in that environment. Detection saturates, because every sensor is reporting simultaneously and the classification queue grows faster than it drains. Decision saturates, because the authority chain was designed around one event at a time. And the defeat layer runs out of magazine, because magazine depth is finite and the attacker's supply is a production-line question — by 2025 Ukraine and Russia were each producing 100,000+ FPV drones annually.

Design for saturation and the single-intruder case is covered automatically. Design for the single intruder and saturation is a different system you do not own.

Practically, that means three things. Detection must degrade gracefully — the system must keep producing a usable picture when it is overwhelmed, rather than producing an unusable one. Decision authority must be pre-delegated, in writing, for the saturation case; a chain that requires a phone call per engagement is not a chain. And at least one defeat mechanism must be non-consumable.

The order of purchase

If you take nothing else from this: build the architecture in this order.

1. Write the rules of engagement first, against your actual legal position. This costs almost nothing and determines everything downstream.
2. Establish the local baseline — what normally flies here, and what is friendly.
3. Buy detection, in complementary pairs. RF plus acoustic, with optical for identification. Coverage before sophistication.
4. Build the identification layer — the friendly register, the classification library, the confidence bands.
5. Rehearse the decision, at 03:00, with the person who will actually be there.
6. Then, and only then, specify the defeat layer — sized to the legal envelope, the collateral environment, and the saturation case.

Most programmes run that list backwards, starting at six and stopping there. Which is why so many facilities own counter-drone equipment and have no counter-drone capability.

What I have not written here

The Shield Curtain's technical specifications — materials, deployment mechanics, sensor integration, team composition — are not public and will not be. The distinction I hold to is that doctrine benefits from scrutiny and engineering detail benefits attackers. Everything above is the former.

What I bring that a vendor datasheet cannot: I have designed these architectures for real sites in a country where the threat is not a scenario, and I do not sell any of the hardware I have just discussed.

Carlos Kfoury is GM/CEO of CIS Security and the author of the Shield Curtain doctrine. He delivers counter-drone architecture design and threat assessment personally. Conflict and geopolitical intelligence is published through RAGE Intel.

Related: The Shield Curtain Doctrine · The 30-to-1 Problem · Fibre-Optic FPV Drones