Last of eight. Building something secure is one job. Proving it to a customer, an auditor or a regulator who has every reason to be sceptical is a different one — and it is the job the rules are now catching up with.

The vessel is only half the system. The other half sits onshore, holds the credentials the fleet obeys, and tends to get far fewer questions than it deserves.

Testing shows that a system worked in the cases you thought of. For a small number of really important properties, you can do considerably better than that — you can prove them.

Software always needs updating, and delivering it to ships that are often out of contact is harder than it sounds. Get the update channel wrong and you have handed over a master key

Almost all cybersecurity assumes your computers sit somewhere safe. A vessel alone at sea can be reached, disabled and taken away — so its design has to assume exactly that.

Listing threats to a system is the easy part. Being confident you have not missed any is the hard part — and there is a discipline for it that beats relying on memory.

Second of eight posts on securing autonomous vessels. Having established that an uncrewed ship is a target, this one gets specific: what an attacker would actually try, and why each attempt is dangerous.

MindChip builds the autonomy systems that let vessels operate with little or no crew aboard. This is the first of eight posts explaining, in plain language, what it takes to make such a vessel one you can actually trust — and how anyone would know