Defence innovation currently offers a long menu: counter-UAS, hypersonics, quantum sensing, directed energy. The item that will decide most fights is duller than any of them. It is integration.

Fusing sensors, effects and command into one decision-centric architecture is what shortens the gap between noticing something and doing something about it. The side that integrates faster wins, and that has very little to do with owning the most advanced individual system.

The complication is that an integrated force is also a larger attack surface. Exposed supply chains, models that can be poisoned, and data pipelines nobody governs turn an advantage into a liability. Security is not a tax on this kind of innovation; it is the thing that lets it be used.

Everyone is converging on the same five ideas

Read across NATO’s multi-domain command initiatives, UK digital backbone work and the US JADC2 programme and the same five commitments appear: treat data as the asset, use machine learning to exploit ISR at volume, keep communications working under attack, close the kill chain quickly, and keep a human answerable for the outcome. Where the money goes next is visible through vehicles such as NATO DIANA and AUKUS Pillar 2.

Integration is mostly an interface problem

Air, maritime, land, space and cyber converge only when there are published data models and APIs to converge on. Standards from the Open Geospatial Consortium and ordinary OpenAPI practice remove the bespoke glue code that quietly consumes most integration budgets, and federated mission networking gives coalitions a scaffold to work within.

AI buys speed and sells risk

Computer vision, multi-source fusion and reinforcement learning genuinely do compress tasking and targeting. Generative models add planning and red-teaming, and with them prompt injection, data poisoning and model theft. Both the NCSC AI security principles and the NIST AI work are worth treating as engineering requirements rather than reading material.

Four things decide whether any of it scales

First, the software supply chain. Defence systems are software-defined and cloud-connected, so a bill of materials (SBOM), signed artefacts and reproducible builds are the minimum, with provenance and attestation written into the contract rather than hoped for.

Second, identity. Machine-to-machine exchange needs mutual TLS, hardware-bound keys and short-lived tokens, with privileged access handled consistently across every partner on the network. Inconsistent identity is how coalitions leak.

Third, data governance. ISR and operational holdings routinely contain personal data, which brings impact assessments and privacy by design under UK GDPR into scope whether the programme planned for it or not.

Fourth, cryptographic agility. Anything fielded now will outlive its current algorithms, so key rotation policy and a post-quantum migration route belong in the design, not in a later phase that never gets funded.

Counter-UAS shows the whole argument in miniature

It needs fast classification, low-latency control and layered defeat options. Without signed control messages, authenticated telemetry and known model provenance, an opponent does not have to beat the system; they only have to spoof a few tracks and watch the operators stop trusting it. Confidence is the real target.

Getting out of pilot purgatory

Promising demonstrators stall because they were never meant to be procured. Modular open systems approaches and digital engineering allow competition at subsystem level, faster certification and a capability that can plausibly be exported. Crypto agility, published bills of materials and zero-trust interfaces should be contractual from day one, because nobody retrofits them afterwards.

What good looks like

• Identity rooted in hardware, short-lived scoped tokens, and every control message signed and verified.

• Open schemas, tracked lineage, and access that is logged rather than assumed.

• Models with known provenance, recorded evaluations and drift monitoring in production.

• Bills of materials end to end, patch velocity measured, and red-teaming in the calendar rather than in the risk register.

The conclusion is unfashionable. Integration beats novelty, and security is what makes integration usable at speed. The organisations that do well over the next decade will be the ones that stopped treating the two as separate programmes.