Rethinking OT security for project heavy shipyards
In this Help Net Security interview, Hans Quivooij, CISO at Damen Shipyards Group, discusses securing OT and ICS in the shipyard. He outlines how project-based operations, rotating contractors, and temporary systems expand the threat surface and complicate access control.
Quivooij also covers visibility in legacy environments and the risks introduced by IT and OT integration.
Shipyards blend long-lived industrial equipment with short-lived projects and contractors. How does that project-based operating model change the threat surface compared to more static OT environments?
Shipyards operate in a world of constant contradiction. On the one hand, you have heavy industrial infrastructure that is expected to run reliably for decades. On the other, every vessel under construction creates a temporary, project-driven environment with its own systems, people and access requirements.
That combination fundamentally alters the threat surface. Unlike static OT environments, there is rarely a true steady state. Networks change as projects progress. Temporary systems appear during commissioning and disappear again. Access that made sense last month may quietly remain enabled long after the original task has finished. Over time, this creates configuration drift that is hard to see until something goes wrong.
What often gets overlooked is the human dimension. Shipyards are contractor-heavy by design. Specialists rotate in and out, bringing their own tools, laptops and engineering environments. For the duration of a project, those external environments effectively become part of your operational reality. If you treat them as “outside the perimeter”, you are already making a dangerous assumption.
The uncomfortable truth is that traditional perimeter-centric security does not map well to this reality. The baseline itself is moving. In our case, this has led us to treat change itself as a security signal, not as an exception. Security in a shipyard is therefore less about defending a fixed boundary and more about continuously reassessing trust in an environment that is designed to change.
Many shipyards rely on legacy PLCs and proprietary control systems that cannot be patched or monitored traditionally. In practice, how do you establish meaningful visibility without disrupting operations?
In OT, availability always wins. If a security control interferes with operations, it will be bypassed or rejected, often for good reasons. That constraint forces a different mindset.
The first mental shift is letting go of the idea that visibility requires changing the devices themselves. In many legacy environments, that simply isn’t an option. So you have to look elsewhere.
In practice, meaningful visibility often starts at the network level, using passive observation rather than active interrogation. You learn what “normal” looks like by watching how systems communicate, not by poking them. That gives you a behavioural baseline without touching the control systems.
This is also where close cooperation with engineers becomes essential. In legacy OT environments, documentation is often incomplete or outdated. The people who built or maintain the systems usually know far more than any tool ever will. Ignoring that knowledge is a mistake security teams sometimes make.
Segmentation helps create order in this complexity. By clearly separating engineering environments, contractor access zones and core OT systems, you reduce unnecessary exposure. The goal is to build a stable envelope around systems that cannot realistically be patched or modernised.
Visibility in OT is rarely perfect. But it doesn’t need to be. It needs to be good enough to notice when reality starts to drift away from what you believe to be true.
Digital shipbuilding, predictive maintenance, and digital twins all require tighter IT and OT integration. Where have you seen security controls break down when business leaders push for connectivity too quickly?
This usually breaks down when connectivity is framed as a technical shortcut rather than a strategic decision. Digital shipbuilding brings real benefits, but every new connection changes the risk profile, whether that is explicitly acknowledged or not.
At Damen, we have seen that problems often start when systems are connected before the data they expose is properly classified. Once data starts flowing, especially into broader IT or analytics platforms, it becomes very difficult to re-establish boundaries later. At that point, security controls are forced to adapt to decisions that were already made under time pressure.
Another recurring pattern is what I would describe as project-driven shortcuts. Under tight deadlines, teams create direct integrations to get a job done, assuming they will be temporary. In practice, those connections often survive far longer than intended, because removing them later becomes operationally inconvenient. This is exactly why we deliberately embedded architectural and security review into the project lifecycle, rather than treating it as something that happens afterwards.
In our environment, sustainable IT/OT integration means avoiding ad-hoc connectivity altogether. When we connect vessels, yards and on-shore systems, we do so through deliberately designed integration paths. One practical example of this approach is how we use our Triton Guard platform: secure remote access, segmentation and monitoring are treated as integral parts of the digital solution itself, not as optional add-ons introduced later. That allows us to enable innovation while retaining control as IT and OT continue to converge.
Remote vendor access remains a common weak point. Diagnostics and support are essential, but without strong identity controls, clear time limits and visibility into what actually happens during a session, remote connectivity can quietly turn into a permanent access path.
On paper, all of this looks manageable. However, in a complex shipyard environment, it rarely is unless governance keeps pace with technology. At Damen, we therefore treat connectivity as a deliberate risk decision, not something that is implicitly approved simply because it enables speed.
Shipyards are contractor-heavy environments, often with multiple vendors accessing the same systems. What does least privilege realistically look like when dozens of external parties need OT access on tight timelines?
Least privilege sounds simple in theory. In a shipyard, it quickly becomes messy.
With many external parties working under time pressure, the real challenge is not granting access, but making sure it disappears again when it is no longer needed. Access that lingers quietly is often far riskier than access that is granted deliberately.
In practice, least privilege means being disciplined about time and purpose. Access should expire by default. It should be linked to a specific task, not to a project or a person’s role in general. We have found that making access removal automatic is often more effective than adding extra approval steps at the front end. If access cannot be explained in one sentence, it probably shouldn’t exist.
Segmentation again makes this workable. Vendors rarely need access to everything. They need access to something. Structuring OT environments accordingly limits the blast radius if something goes wrong.
From my perspective, the real risk is not that someone gets access. It’s that nobody notices when that access quietly becomes permanent. Least privilege in OT is therefore less about restriction and more about containment.
Given the geopolitical sensitivity of shipbuilding and naval supply chains, how should shipyards think about nation-state threats differently from financially motivated attackers?
The difference lies in patience and intent. Financially motivated attackers usually want fast results and visible outcomes. Nation-state actors are often content with quiet, persistent access that remains useful over time.
For shipyards, this changes how you interpret signals. The absence of disruption does not mean the absence of compromise. Long-lived credentials, subtle access patterns, or data flows that “almost make sense” are often more relevant indicators than obvious malware.
Supply chains deserve particular attention. Adversaries rarely start with the most protected target. Smaller partners, engineering environments or temporary project setups are often easier entry points.
This is where resilience becomes critical. You cannot assume you will keep every advanced adversary out forever. The goal is to detect early, limit impact, and prevent silent access from becoming strategic leverage. For us, this means treating cybersecurity as a standing management topic, not something that only surfaces when an incident occurs. In that sense, cybersecurity in shipbuilding is not just an IT issue, but part of broader risk and continuity management.