Autonomous ships, cyber security and the Workboat Code
Defending the brave new world of autonomous platforms from hackers is hard.
17/04/2025 Podcast
Back to Insights
If you thought uncrewed hydrogen-powered vessels were the stuff of science fiction, think again. In this episode of You Gotta Hack That, Felix sits down with Oli from AquaOcean to dissect how cutting-edge maritime technology collides with an industry steeped in tradition, and what that means for cybersecurity on the open seas. Picture a remote-controlled 25-tonne ship braving global waters, with zero crew and a full cyber stack vulnerable to everything from targeted hacks to satellite comms disruption. It’s maritime innovation pushed to its operational and regulatory limits.
AquaOcean is spearheading the development of the world’s first hydrogen-fuelled Small Waterplane Area Twin Hull (SWATH) uncrewed surface vessel (USV). This vessel, weighing 25 tonnes and measuring 14.5 metres in length, is engineered for extended blue-water operations without onboard crew. Its control and oversight are managed remotely from a shoreside operations centre. As a vessel under 24 metres, it qualifies for certification under the Maritime and Coastguard Agency’s (MCA) Workboat Code 3, which now includes detailed cybersecurity provisions aimed at autonomous systems.
Oli elaborates on the code’s annex for remotely operated and autonomous vessels, which sets out baseline cybersecurity expectations. These include system and data asset identification, threat mitigation strategies, attack detection capabilities, recovery protocols, and backup mechanisms. However, both Felix and Oli critique the abstract phrasing of these mandates, such as “timely detection of cyber incidents”, noting that their ambiguity poses implementation challenges in practice.
In response, AquaOcean is adopting a pragmatic, threat-informed approach to cybersecurity. Acknowledging the inherent limitations of achieving complete cyber resilience, the team is working to raise the bar relative to similar platforms, making themselves a less attractive target. Strategies include robust system logging during communication outages, comprehensive threat modelling, and the application of industry best practices to pass regulatory assessments. An integral part of this is maintaining a documented baseline configuration, including a Software Bill of Materials (SBOM), to ensure system state traceability.
The discussion highlights the gap between evolving technological capabilities and regulatory frameworks, with AquaOcean contributing to the establishment of norms for future autonomous vessel standards. Their efforts underscore the importance of industry input in guiding realistic, effective cybersecurity compliance for maritime autonomy.
Felix (00:09)
Hello, I’m Felix and welcome to You Gotta Hack That. This is the podcast all about the security behind the Internet of Things and operational technology. In this episode, I’m joined by Ollie and we’re going to talk to you about the workboat code. Ollie, how are you doing?
Oli (00:24)
Good thanks Felix and thanks for having me on. Appreciate it.
Felix (00:27)
You Gotta Hack That’s new training module is all about the nerdy bits of PCB and electronics reverse engineering. We explore topics such as identifying defensive PCB design, power distribution and chip to chip communications. The module is a week long deep dive and starts on the 23rd of June, 2025. As it’s brand new, our beta testers get 1000 pounds off the normal price.
There is more information available on our website and we recommend booking as soon as possible as spaces are limited. But for now, let’s get started on today’s topic.
Felix (00:57)
I guess, you know, we’ve been talking for a while now about ships and cybersecurity, because you’ve been investing your time in a particular project…
Oli (01:07)
Did you want me to give a bit of a context just for the listeners on what our vessel’s doing and what we’re trying to achieve as a wider project? Yeah. Let’s go. Always worth a plug for the company, So yeah, the company’s called AquaOcean, and we’re building the world’s first hydrogen-powered SWATH USV, small water plane area, twin hull,
Felix (01:14)
Absolutely. If you’re, if you’re up for that, let’s do it, haha
Oli (01:29)
USV uncrewed surface vessel. So our vessel by design has no people on it. To give you an idea of scale, it’s a 25 ton aluminium vessel, workboat class. It’s 14 and a half meters long and it’s nine meters wide. It’s able to carry a payload somewhere between six and seven tons, we expect, the size of a 20 foot ISO container.
What we’re not talking about here is a small little toy. It’s not a sort of go fast rib. This is a very sizable platform designed to sit at sea for extended periods of time, operate truly in the blue ocean in a category zero water, it can operate anywhere in the world globally and will be remotely operated from a remote operating center.
we are looking to build the vessel to follow the Workboat Code
So vessels under a certain length in the UK can be certified under Workboat Code 3. What that means is a subset of regulation that is slightly easier to get your arms around, slightly easier to follow and has a series of rules of thumb baked into it. There’s a subsection that was recently approved and released by the Department for Transport and the Maritime Coast Guard Agency, the MCA, which covered autonomous platforms. So they’re moving at pace, which is great. Now, to answer your question, as part of that,
Felix (02:51)
Hmm.
Oli (02:56)
move forward into the brave new world of autonomous platforms operating outreach with no people on them, clearly you’ve got a wide area connection, that’s the preferred option. For many companies we are the same. We operate both in a UHF and a wide area So that presents a cyber threat surface and that has therefore meant that the Department for Transport
Felix (03:01)
Hmm
Oli (03:18)
has released documentation. The MCA has folded that documentation into WorkBoat Code 3. So an exciting dive into the WorkPay Code 3. It’s a hoot.
Felix (03:26)
Ooh. So this, this annex, do you know when that was roughly added? The, autonomous, annex.
Oli (03:33)
So it was relatively early last year. We had a vessel designed under Workboat Code 2 and then Workboat Code 3 was released and the rules were if you had the keel laid, you could still build your vessel to you had to build it to 3. We hadn’t quite laid a keel by the time the regulations came in. So over one Christmas the goalposts move. But hey, such is life.
Felix (03:55)
Brilliant.
Oli (03:57)
But yeah, so going back, the workboat code is quite a well structured document. I can commend it to anybody who wants to go and build a workboat. However, chapter 31 on safety management then goes on to talk about cybersecurity. there’s a paragraph in here that reads, cybersecurity measures shall include at a minimum the following.
And it includes things like identification of the vessel systems assets data capabilities, which would impact the vessel if get disrupted. That’s perfectly reasonable. Measures to minimize and defend against cyber attacks seems entirely logical. Point four is more challenging. It’s a means to successfully detect a cyber attack in a timely manner, followed by point five, resilient means to restore key systems. And then
Felix (04:41)
Oof.
Oli (04:48)
Para 7 then goes on to talk about measures to successfully back up and restore critical systems following a cyber attack. So those on the face of it, yeah, sure, I wholeheartedly subscribe to the principles behind those. I’d be interested to know your thoughts, but I’ve got a sneaking suspicion that certain cyber attacks might… remove the ability to do some of those restorative or detect.
Felix (05:10)
particularly with an autonomous vehicle with nothing on it, right? mean, no one helping directly It’s going to be a bit of a challenge.
Oli (05:14)
Yeah. Yeah.
Felix (05:17)
it’s interesting because I mean, when we’ve talked about this before and these requirements, they’ve not got an awful lot of detail behind them, have they? It’s not a very prescriptive thing. It’s you must do this conceptual thing and make it better. And I see this a lot from different standards of varying sorts You must do cybersecurity. All right, but what is that? And then, and that one you pointed out a moment ago, the kind of the slightly more challenging one around…
that you must be able to detect and respond to a cyber incident in a timely manner. mean, it’s really, really quite vague, isn’t it? What is timely? know, is it in the milliseconds because it’s an operational thing and it might crash or is that in, you know, the next year? Because I don’t know, it’s probably a good idea to patch your stuff every now and then. Good,
Oli (05:50)
It is. Yeah.
I think to defend what they’ve written, it is entirely context specific and to some extent the speed at which you need to respond is necessitated by the situation in which you find yourself. If you are in a congested traffic separation scheme, for example, with many vessels in the vicinity, then yes, it becomes a problem. For us, it presents an issue because
We intend to be a hydrogen propelled zero emission vessel. So we have a hydrogen system embarked We need to take care with that. We’re also not an insignificant size. So 25 tons carries its own amount of inertia. We could do some damage to another vessel, or hopefully never, but there is a risk to life. So we have to be cognizant of that. So I think what they’re striving towards is laudable.
I’m not entirely sure we’re going to ever be able to fully meet that requirement because there are so many scenarios which could mean that we fall short. A well-designed attack might quite comfortably work around that and we would never detect it.
Felix (06:59)
Yeah.
And that’s really, really interesting, isn’t it? Because there is no such thing as absolute cybersecurity. It’s just not possible unless you don’t have the system. If you turn it off and bury it, then maybe you could claim that that is the case. to what extent are you going to be able to demonstrate that you have achieved these objectives And I presume there’s going to be some form of
know, official assessment by somebody saying, yes, you have or have not achieved these goals. So I think it’s kind of, I don’t know, I imagine a lot of people would be quite nervous about saying that they may or may not actually achieve these goals because they’re quite lofty, because ultimately you’ve got to get through that certification phase. But it’s quite forward thinking that, you know, recognizing that it’s maybe not so straightforward, you know, it’s not immediately achievable.
Oli (07:49)
I think you’ve got to be pragmatic. I’ve got some experience in the cyber domain in previous roles.
I’ve worked around computing infrastructures for a long time in my previous job in the Navy. There’s a degree of pragmatism that needs to come, I think, when approaching these sorts of challenges. As we’ve talked to to some extent, once you understand the threats that you are facing as a
opportunity then to be better than everybody else in that similar threat level actually could mark us out as a more difficult target, not worth the effort to somebody who’s looking for low hanging fruit and then move on to the next person or the next option or the next objective. That doesn’t mean that we won’t get caught in the crossfire of another attack or a less discriminant delivery of effect. Of course, that’s always the case,
Felix (08:26)
Hmm.
Oli (08:34)
But I think that, yeah, there deserves to be bit of pragmatism. We will be subject to survey. We are already subject to survey our certifying authority, and their surveyors will come and quiz us about all manner of things across the platform from does the red light have the right angles over the port side through to cybersecurity measures and how we intend to meet the requirements that are laid down. And I think insofar as we can
demonstrates them, we know what normal looks like. can hopefully start to spot the deviations from normal. We can illustrate the journey that we’ve taken with You Gotta Hack That and where we’ve come in terms of threat assessment. Certainly also talk to the Department for Transport Cybersecurity Code of Practice for ships. Another cracking read I can recommend anybody. But there’s a very neat wheel on there.
that starts with threat assessment and ends with reviewing your risks. so long as we have understood all the documentation that’s out there, we’re taking best practice and we’re employing it in a sensible way, in a professional way, we can then illustrate to the Maritime Coast Guard Agency that we are a professional outfit ready to be a UK flag vessel.
Felix (09:44)
I’m looking forward to hearing that you’ve passed that assessment with flying colors, to be honest, but have there been any challenges that you weren’t expecting when this whole process started?
Oli (09:56)
I think one of the biggest challenges we face, as is probably always the case, making enough time to give this the due regard it deserves. In the fast-paced world of startups where everything has to be simultaneously done, so we built the vessel at the same time as designing the vessel, at the same time as testing the systems.
Felix (10:09)
Hmm.
Oli (10:19)
and all of that was running simultaneously, to then stand back and go, okay, well, where are my risks and all of that? And as we progressed through the build, there were risks which were immediate risks to life with people working aloft, working confined spaces, all these sorts of All of demands the right amount of attention from a small team of people. I have in most cases one specialist in all the flavors I need and that is probably the single biggest pressure actually is finding the time. As I suspect you might have figured out as we’ve missed meetings and missed bits and pieces our own agenda that we’ve set.
Felix (10:52)
ha
Oli (10:57)
and our own timelines. So that I think is probably the biggest one is making the time to appropriately address this. But I think with your advice at an early stage, it has been able to influence the design decisions we’ve taken. Certainly some of the equipment decisions that we’ve started to make. And we will absolutely with capability demonstrator that we’re building.
look to refine this model for our future commercial offerings so that do come out the doors with a really resilient commercial solution from a cybersecurity perspective. We won’t stop learning.
Felix (11:24)
Hmm. That’s interesting. you know, this isn’t like necessarily an advert for you guys, but it’s one of the things that struck me quite early on is the whole discussion about what cyber security means in this context was one of the early things you guys seem to be thinking about. And as a result, I’ve definitely seen that some of the options that you’ve chosen have been influenced by that in a positive way. And yeah, I’m quite…
Oli (11:57)
Cool.
Felix (11:59)
quite looking forward to the kind of next steps and seeing sort of version two, if you will, whatever, however you’re designating it. But in terms of, recognizing that, you know, like it’s not necessarily going to be the final thing, and you know, where you’re going. I know that’s, that’s probably quite astounding to a lot of people in their sort of building big operational environments is, hang on a minute, you’ve got a plan for this. It might not be right first time around, but you know where you’re going.
So that’s pretty cool. And I think it does make a really big difference when you’re, making a new product, a new system, new whatever is actually having it in there early enough. So you can head off some of the major problems as you go along.
Oli (12:35)
Yeah, I remember you saying that in our early chats, it’s never too early to engage and start thinking about these things. There is definitely a point at which it’s too late, but too early, not a feature.
Felix (12:45)
Yeah, so in terms of the kind of cybersecurity requirements of the workboat code, I imagine when they wrote this, they were thinking about crewed vessels and having like a logging mechanism on board a ship and you’re able to kind of go and poke it and take action and disconnect yourself from the internet or whatever. It’s very different from the autonomous part that is involved in your project. Do you think that is going to cause some kind of major challenges that are…
Oli (13:08)
Yeah.
Felix (13:14)
what’s the right way of putting it? know, make those requirements quite difficult to achieve because of that remote nature, you know, because sever that connection to the internet from that vessel and suddenly you’re running blind and who knows what is happening, but are you still, you know, collecting the data necessary to deal with?
Oli (13:25)
Mm-hmm.
Felix (13:32)
requirement here or are you What degree of fidelity do you need on those sorts of logs? And all sorts of questions come to my mind.
Oli (13:38)
Yeah, yeah, it’s a really interesting challenge. that the MCA have dealt with what they call remotely operated unmanned vessels is that they’ve written a workboat code that is designed for vessels crewed or uncrewed, doesn’t matter. The workboat code deals with these are the requirements that every vessel has to meet.
That’s right and proper. The rules, the maritime, what are known as rules of the roads, but the collision regulations, they still apply to us. We still have to follow the rules that say you slow down and you turn right if there’s a chance of collision and all these other regulations around lights that you have to display, sound signals, et cetera. So all of that stuff still applies to us.
So it’s appropriate that the MCA has written one code for all. And what they’ve then done is they’ve written an annex two, which covers off RO UVs, is remotely operated unmanned vessels. And that then stipulates all the deviations that are specific to uncrewed vessels. And in that instance, it details what you have to do in the event of a loss of comms with your remote operating center, for example.
To answer your question, will continue to log data on board the platform in the event of a comms loss. We will continue to record imagery from our cameras. We will continue to record all of the things that we are required to record. What we can’t do, is physically go to the data recorder and check that it is doing such So there are limitations and I think you, with a remotely operated platform, you have to accept that
There are degrees which you cannot achieve, things that you would be able to achieve when you were in person. That said, our initial sortie length whilst we’re proving the platform will be relatively short and we can check the data. when to extend out towards our day endurance
Then part of our SOP, our standard operation procedure when the vessel comes back alongside, can be validating that the logging is as expected We can come back from this period being away at sea, bring in the logs go, OK. As far as we can see, there is the right volume of data here. The right fields have been recorded. And then we can spot check one or two of those.
Felix (15:39)
Fair enough. sounds like actually it’s not left open to as much interpretation as you might imagine. They must be recorded and then you do sensible things with them and that’s it. That sounds much more simple than I was
Oli (15:50)
This is the world according to Olli of course and we have yet to cross this bridge with with Lloyds and indeed the MCA. This is a case where industry and the automation industry in the maritime is pushing the boundaries of what can be done. there existed many uncrewed platforms at sea before WorkBoat 3 came along So as is often the case, technology is leading regulation and the regulatory frameworks are then being built based on what is seen to be best practice from the handful of players that are currently out there and that then shapes what will come for the many that follow.
Felix (16:21)
Is there anything else in the workboat code three that you want to touch on today?
Oli (16:25)
Not specifically around implementation of cybersecurity. But it remains something that is both at the forefront of our minds and guiding some of the decision making along the way.
I was taking on board your idea of an S-bomb and trying to document specifically what our platform looks like. Once we’ve baseline the platform and we understand the platform’s identity from the beginning, that puts us in a really, really quite good place. And certainly based on my experience of working in some other companies who specifically address this challenge, not all companies understand what their IT and OT infrastructure is and the software and firmwares that they’re running at any one time so even just to keep up to date is a challenge in its own right.
Felix (17:02)
Yeah, I think unfortunately the use of things like software bill of materials has a way to go yet. It’s quite an immature concept really in many ways, even though it’s been around for a while. Nobody tends to use it. And I genuinely think that that’s largely down to the fact that the awareness of what general assets you’ve got and what’s connected to what is usually pretty low. So I think it’s a really good way of demonstrating how building this stuff in at the beginning, when you’re, you’re, designing the system is the way forward because trying to retrospectively do this would be nightmarish, frankly.
Oli (17:35)
I wouldn’t say we’re perfect at it either. We are absolutely not. But we’re certainly trying hard and we acknowledge the process. We we intend to we will work hard to strive complete a of our vessel as we possibly can, but partly for safety reasons as well.
I will certify the vessel safe to operate at a certain baseline of software that we’ve written in-house, software that’s come from other OEMs. And the overall amalgamation of all of that, that will be a baseline at which point I will sign a certificate of design. I need to be happy and understand that when the vessel goes out each time, it is still in that same given configuration and hasn’t deviated.
Felix (18:18)
Thanks everyone for listening. I hope you’ve enjoyed the show. Your reviews are really important to us. So if you haven’t already, please give us a five-star rating and recommend us to all your friends. If you’ve got a question about cybersecurity, including for guests like Oli about the security of embedded systems, then why don’t you get in touch.
You can find us by email on helpme@yg.ht with @gotta_hack on X or by searching for You Gotta Hack That on LinkedIn. Cheers everyone.
Oli (18:45)
Awesome. Cheers, Felix. Thanks for having me.