At the 18th International Conference on Cyber Conflict (CyCon 2026) in Tallinn, 26–29 May 2026, my co-authors Rishab Somu, Ankur Jayaraj, and I presented our work on hardware-enabled sovereignty for military systems. One argument from the paper stands on its own, and it applies far beyond the military context we framed it in.

The standard toolkit is the problem

In practice, critical systems today are protected by a stack of software services: endpoint detection and response, intrusion detection, cloud-based threat intelligence. None of these is a bad idea on its own. But they all do the same thing: they move part of the system's security outside the operator's own control.

• Cloud integration means the security of your system depends on infrastructure you do not control, in jurisdictions you cannot audit.
• Every additional agent expands the attack surface of the very system it is supposed to protect.
• On classified systems, such integrations are often not allowed at all — the connection itself would compromise the classification level.

In practice, every security decision on a critical system is also a sovereignty decision — whether anyone treats it as one or not.

Then there is the timescale. Military and industrial systems are not refreshed every three years; they are built for ten to twenty years of operation. You cannot protect a system that has to run for two decades with tools whose providers may not exist in five.

More security tooling means less sovereignty

For a system built for decades, the trade cannot be ignored. Piling on more tools makes it more resilient against known attacks — and less sovereign against the threats that matter most for long-lived systems: withdrawal, coercion, dependency. Every additional external dependency is a sovereignty leak: a path by which a vendor, a jurisdiction, or an attacker can reach into the system's operation.

More security or more sovereignty is a decision someone has to make. In practice it is usually made implicitly, one procurement at a time, one integration at a time — and a trade made that way is hard to reverse once a system is deployed. Where sovereignty is a requirement for the system, that decision has to be made deliberately and in the architecture: the security properties of the system are defined by the hardware it runs on, not by what is layered onto it.

Sovereignty, enabled by hardware

In the paper we demonstrate this with SOSA, the Sovereign Sensor and Actuator: a network sensor whose core is an application-specific processor SoC on FPGA. The core implements exactly the functionality the sensor requires, and nothing else. So the attack surface is not reduced by filtering or patching — it is reduced by absence. Only what the application requires is ever built, and what is not built cannot be exploited.

• The components integrate independently into existing systems, without cloud dependencies.
• The minimal core is resilient against a wide range of attacks.
• We validated the approach with a working implementation adapted to a naval combat management system.

The same principle runs through our broader ASP research: trustworthiness by structural elimination. You do not add verification on top of a system; you build only what the application requires. That is what sovereignty means at the hardware layer.

The takeaway

Sovereignty is often treated as a policy promise: a statement in a procurement document, a framework, a mandate. A promise does not make a system sovereign. Architecture does — sovereignty is a property the hardware gives the system, and no software layer can restore it once it is lost.

For any system that must stay operational for the next twenty years, the trade between security and sovereignty has to be made somewhere: deliberately, in the architecture — or by default, one dependency at a time. In the silicon, or in the mandate.

The full paper is available in the publications: Hardware-Enabled Sovereignty: Securing Military Systems Through a Novel and Resilient Defense Architecture, CyCon 2026.