The Second Curve in Counter-Drone: When Revenue Moves From Hardware to Software

On October 14, 2026, DroneShield published its fourth-quarter software update. The release adds flagging for unfamiliar or unclassified signals to its radio frequency detection systems and upgrades electro-optical and thermal recognition. The company reports a 44 percent improvement in thermal classification, an 18 percent improvement in fixed-wing recognition and an 8 percent improvement in recall. It also lets several DroneSentry-X Mk2 nodes coordinate an action and concentrate effect on a selected band, with the companion command platform release set for November 3.

Read that list again and notice what is absent. There is no new enclosure, no new mast, no new antenna. What shipped in October is a file, and it makes hardware customers already own work better than it did in September. That is the counter-drone software business arriving in public, and it changes what the industry is selling.

The pattern is not unique to one vendor. In every mature sensor market the same moment arrives, when the installed base is large enough that improving it becomes more valuable than extending it. A site that already owns hardware is cheaper to serve than a site that owns nothing, and a supplier that can improve that hardware remotely has a revenue line which does not depend on winning the next tender. What the October release shows is that counter-drone has reached that point, at least for the vendors that have a software layer worth updating.

Why Hardware Revenue Has a Ceiling

A sensor is bought once. The revenue is recognised once, and from that moment the site has less reason to buy another unit of the same type than it had the year before. Every successful sale removes a future sale from the same address. Growth then depends on reaching new addresses, and the number of airports, prisons, substations and stadiums in the world is large but finite.

The usual answer is that the threat changes, so the customer must buy again. That answer is true and it is also inconvenient. If a 2023 detector still detects what it detected in 2023, the customer’s honest conclusion is that the 2023 box was adequate and the 2026 box is a want rather than a need. If instead the 2023 box now finds airframes it could not find three years ago, the customer’s conclusion is that the relationship is producing value, and renewing it is the cheap option.

That difference, not the price list, is what separates a hardware company from a software company inside the same building.

What an Update Actually Sells

Strip the marketing from any counter-drone software release and three things remain.

The first is recognition refresh. A signature library is a perishable asset. New airframes appear, link protocols get new firmware, flight controllers change their frequency hopping, and every one of those events quietly ages the library in the field. A release that adds models is not a feature, it is maintenance of the only thing the sensor is actually good at.

The second is coordination. A single node reporting to a single operator is a detector. Several nodes that divide the search area, hand a track to whichever sensor has the best view, and avoid reporting the same aircraft three times under three different identities are a system. The DroneShield note about coordinating several nodes is the interesting part of that release because coordination is where software earns money that hardware cannot.

The third is record. Every detection, every operator decision, every dismissal is a data point. Kept for a year, those points answer questions no single alert can: what normally flies here, at what hours, on which bands, and what does an actual anomaly look like against that baseline. Organisations that can answer those questions buy differently from organisations that cannot, because they can justify the next purchase with their own evidence.

A Percentage Needs a Baseline

The published figures in the October release are 44, 18 and 8. Those are company numbers, and the useful question is not whether they are large but what they are measured against.

A classification improvement of 44 percent could mean the model now handles a thermal category that previously failed outright. It could also mean the same model scored better on a test set drawn from the same distribution as its training data. Both statements are arithmetically true and they imply very different field outcomes. A buyer who does not ask which one applies is buying a press release.

The honest way to present model gains is to publish three things beside the number: the size and source of the evaluation set, the conditions under which the imagery was captured, and the categories where the model still fails. The third item is the one that builds trust. Every real system has a category it handles badly, whether that is a distant quadcopter against a bright horizon, a fixed-wing aircraft at low contrast, or a bird that flaps at exactly the wrong frequency. A vendor who names its weak category is more credible on the numbers than one who does not.

This matters commercially because model quality is now the differentiator that hardware cannot copy. Two radars with the same panels and the same band can be separated entirely by what their classifiers do with the returns.

Service Has Three Tiers, and Most Customers Need the First

The industry has started to package support as an annual contract. That is the right direction and it is easy to get wrong.

The first tier is baseline: software updates, warranty extension, a hotline that answers, and a documented release schedule. It is unglamorous and it is what the majority of sites actually need. A prison that runs six fixed sensors and one operator on shift does not require a managed service. It requires that the system still works in year four and that someone picks up the phone.

The second tier adds work on the customer’s own signals. That means importing local recordings, retraining or tuning against the aircraft that actually appear on that site, and reviewing the results quarterly. This tier is worth real money to an operator with an unusual local pattern, an industrial site with heavy radio traffic, or a border area where the airframes are not the ones in the catalogue.

The third tier is managed operation: remote monitoring, diagnostics, a spare parts pool, and a response commitment when something fails. It fits very large estates and events with no standing security staff. It is also the tier most often oversold, and overselling it has a predictable result. The customer pays for a level of service they cannot absorb, sees no measurable difference, and declines to renew anything at all.

The pricing basis of a tier deserves as much attention as its contents. A per device fee is easy to administer and punishes the customer for expanding coverage, which is the opposite of what the vendor wants them to do. A per site fee rewards density and makes a wide deployment cheaper per sensor, but it breaks down when one site has four sensors and another has forty. A flat platform fee plus a support band tied to the number of active devices is the arrangement that survives a growing estate without a renegotiation every year. None of this is exotic. It is the ordinary commercial plumbing of a software business, and it is new to a sector that has priced boxes for two decades.

What Belongs in the Contract

Public buyers have become sharper about this, and the contract language is where the difference shows.

Update cadence should be written as a commitment rather than a phrase. Software updates included is not a term; four releases a year, with a named process for urgent signature additions, is a term. Model version matters too, because a classifier that changes without a version number cannot be audited and cannot be rolled back after a bad release.

Data ownership deserves its own clause. Local recordings are the customer’s operational history. Whether the vendor may use them to improve a shared model, and whether the customer can refuse, is a commercial and legal question that should not be settled by a default setting. Organisations with strict internal rules will ask, and the answer they receive will decide the deal.

Exit terms are the clause nobody reads until it matters. If the platform stops receiving updates, does the customer keep a working system, or does a licence server quietly turn a functioning installation into furniture? A support contract that ends should degrade into a system that still detects, still records and still displays, even if it no longer learns.

Finally, a yearly benchmark on the customer’s own site is worth more than any brochure figure. It converts a service contract into measurable evidence, and it gives both sides a shared fact base when renewal comes around.

Where the Platform Layer Sits

Software is also the only part of a counter-drone installation that is touched every week. Sensors sit on masts and are visited when something breaks. The command layer is opened every shift, which makes it the natural carrier for a service relationship.

For LZ TECH, that layer is CCS, which handles device access and status, the map picture, alarms, allow and deny lists, protected zones, event records, statistics and unattended operation, with CRPCS adding web and mobile access and zone-based workflows. The point is not the feature list. The point is that a platform which receives updates, imports customer recordings and reports its own health is a platform that can carry a contract, while a box that leaves the factory finished cannot.

Integration effort belongs in the same calculation. A service contract assumes the vendor can reach the customer’s system, and the cost of that reach is decided at installation. A platform with a documented interface, an export format and a health endpoint can be supported remotely. A platform that requires a site visit to read a log makes every service tier expensive to deliver, and the price of that inefficiency lands on the customer at renewal. The cheapest support contract is written into the product architecture long before anyone signs it.

The Bottom Line

Hardware revenue is a series of transactions. Software revenue is a relationship, and relationships survive only if they keep producing something the customer can name.

That is the test to apply to any subscription offer in this market, including our own. Can the vendor list three things the system does in 2026 that it could not do in 2024, with the site, the aircraft type and the conditions attached? If the answer is specific, the annual fee is a maintenance cost that buys capability. If the answer is vague, the fee is a tax on a product that has not changed, and customers work that out within two renewal cycles.

The second curve is real. It is also narrower than it looks, because software only earns a recurring payment when it delivers a recurring improvement.