The Half You Don’t See: Command Centres, Cloud and Sovereignty

So far this series has focused on the vessel: how it resists deception, survives capture, and safely accepts new software. But a single vessel is only part of the picture. Behind every autonomous fleet is a command centre onshore — the systems and the people that plan missions, watch the live feeds, and issue instructions. It is the half of the system customers tend to ask fewest questions about, and it deserves at least as much scrutiny as the hardware floating in the water.
It is also the half where the failure modes are least dramatic and most consequential. Nobody writes headlines about a mis-scoped user account the way they write about a hijacked ship. The account is the more likely route in.

The command centre is where the authority lives

It is tempting to pour all your attention into hardening the vessel and treat the operations centre as a safe home base. That would be a mistake. The command centre holds the credentials that vessels obey, the mission plans, and the accumulated data. An attacker who gets into the command centre does not need to defeat any of the vessel’s defences — they can simply become the trusted operator and issue commands the vessels will faithfully carry out.
In security terms the command centre and the vessels are two halves of one system, and the whole is only as strong as its weaker half. Everything that follows is really a set of answers to one question: what stops someone becoming the trusted operator, and what happens if they do?

Who is allowed to do what

Not everyone who touches an autonomous fleet needs the same powers. Someone monitoring a survey needs to see position and video. Someone planning next week’s work needs to create and edit missions. Someone commanding a vessel under way needs to change its behaviour in real time. Collapsing those into a single permission — “logged in” — is the most common way a system that looks secure turns out not to be.
So access is layered by role, and the roles are deliberately narrow: view, plan, command, administer. A second factor beyond a password matters most at the higher levels, because a password on its own is one stolen credential away from handing a stranger the helm. And permissions should be reviewed when someone changes job, not only when they leave — accounts tend to accumulate access the way a coat accumulates receipts.
There is one distinction that is easy to lose and worth holding onto. Operational authority over the fleet and administrative authority over the infrastructure are different things. The person entitled to command a vessel is not necessarily the person entitled to reconfigure servers, alter logging or issue new credentials, and the reverse holds too. Keeping them separate means compromising one does not automatically deliver the other.

The operator is part of the system

It is tempting to think of a command centre as infrastructure. In practice its most important components are people, and a security design that leaves them out is incomplete.
Remote supervision has a specific difficulty: the operator has to build an accurate picture of a situation they are not physically in, fast enough to act on it. That is partly a human-factors question — how much information, presented how, and how many vessels one person can reasonably watch at once. But it is also a security question. An operator who cannot distinguish a genuine anomaly from an interface glitch cannot be the safety net the rest of the design assumes. A vessel reporting that its position is no longer trustworthy is only useful if that message reaches someone who understands what it means and what to do about it.
The operator’s own equipment belongs to the attack surface as well. If the fleet is commanded through a web browser, the laptop running that browser is a component of the system, whether or not anyone drew it on the architecture diagram. Phishing an operator is very often easier than attacking a platform directly, which is why session handling, device expectations and a healthy suspicion of unexpected login prompts belong in the security design rather than in an appendix to it.

Staying up is a security property

Availability is usually filed under reliability rather than security. For an autonomous fleet they are the same subject. A command centre that goes dark leaves vessels without their trusted anchor — unable to receive instructions, unable to escalate a problem, dependent entirely on whatever contingency behaviour they were given before they sailed. An attacker who cannot break into the centre may settle for making it unreachable and get much of the same effect for a fraction of the effort.
So the infrastructure is built to survive losing things: a machine, a data centre, an entire hosting region. That much is ordinary good engineering. What makes it harder in this domain is the constraint at the far end. Vessels at sea cannot be reconfigured on demand — some are out of contact, and all of them are running software that was fixed before departure. A failover plan that requires someone to change a setting on each vessel is not a failover plan. The switch has to happen ashore, and the vessels have to find their way to the new home unaided.
This is one of those requirements that sounds like a footnote and quietly determines the shape of the entire architecture.

Everything the centre depends on

Almost every modern command centre runs on infrastructure somebody else owns. That is usually the right engineering decision — it buys resilience, scale and physical security that a small operator could not build alone. But it means the security of your fleet now rests on a provider’s practices as well as your own, and “we use a major cloud provider” is a statement about someone else’s security rather than about yours.
The questions worth asking are unglamorous. Who can reach the machines? How is one customer’s data kept apart from another’s? What actually happens when a component fails, or a whole region does? Recognising this, the EU has been developing a dedicated cybersecurity certification scheme for cloud services, precisely so that these questions have standard answers rather than bespoke ones.
There is a second kind of dependency that attracts far less attention. A command centre does not plan missions from its own data alone; it pulls in charts, weather forecasts, traffic feeds and seabed information from outside services. Each of those is a convenience and a route in. Data arriving from a third party deserves the same suspicion as data arriving from the sea — validated, bounded, and never trusted merely because it came from a familiar name. A corrupted depth value that reaches mission planning unchecked is a navigational hazard that arrived by interface.

Where the data lives, and who can reach it

For a European maritime operator there is a further consideration: where the fleet’s data and control systems physically reside, and whose law reaches them. Hosting command infrastructure within the European Union, under European jurisdiction, is not merely a matter of preference. For sensitive or critical operations it can be a requirement, and it keeps control of the fleet inside a trusted legal framework.
Physical location and legal reach are not the same question, which is where this gets subtle. Data held in a European data centre may still be operated by a company subject to another country’s disclosure regime. The practical questions are therefore about control rather than geography alone: who holds the encryption keys, who could be compelled to produce what, and what the operator would actually be told if such a request were made.
There is also the question of what the data is worth. A fleet’s accumulated telemetry, imagery and survey results describe infrastructure, seabed and traffic patterns in considerable detail. For some customers that record is more sensitive than any individual mission, which makes retention periods, export rights and deletion something to agree deliberately rather than inherit from a default setting.
It is a useful reminder that cybersecurity is not only about code and cryptography. It is also about governance, jurisdiction, and who ultimately holds the keys. A technically flawless system operated under a legal regime the customer cannot live with is not a solution.

Being able to say what happened

Whatever else a command centre does, it has to be able to account for itself afterwards. Which operator issued which command, and when. What the vessel reported. What was changed, by whom. The obvious reason is that you cannot investigate an incident you have no record of — but there are two less obvious ones.
The first is accountability. In a system where authority is shared between software and several people, a clear and tamper-evident record is what allows a decision to be attributed rather than argued about. The second is that the record is also evidence. A great deal of what an assessor wants to see when certifying a system is exactly this: not an assurance that access is controlled, but a demonstrable trail showing that it was. A platform that keeps good records is substantially easier to certify than one that does not — which brings us to the final post.