Ships have been connected to networks for a long time. What has changed recently is not the volume of connectivity but its character. Satellite-based remote support, predictive maintenance, fleet-wide data integration, and the constant interconnection of navigation, engine, cargo, and safety systems have turned the vessel from an isolated machine into a moving system of operational technology (OT) — the industrial control systems that run machinery. In that environment, security cannot be an option bolted on later. It has to be a specification, one that covers network boundaries, remote access, logging, and incident response from the design stage onward.
The regulatory picture points the same way. The International Association of Classification Societies (IACS) issued Unified Requirements E26 (cyber resilience of ships) and E27 (cyber resilience of on-board systems and equipment), pushing the industry to build cyber requirements into design and construction rather than bolt them on afterward. After revising the requirements in light of industry experience, IACS set the effective date: the URs apply to newbuildings contracted for construction on or after July 1, 2024 — and because Unified Requirements bind IACS member societies, which write them into their own class rules, this is a condition of classification rather than guidance. The International Maritime Organization's guidelines on maritime cyber risk management reinforce the same trend, treating cyber as a material dimension of vessel operational risk.
Networked vessels requiring strengthened security
Shipbuilders are putting network security on the drawings: what a Samsung Heavy Industries patent shows
The patent record indicates that at least one major shipbuilder has begun treating security as a fundamental design element rather than as an afterthought added once the ship is in service.
Samsung Heavy Industries' ship network security patent (Korean Patent No. 10-2652835) claims an architecture that divides the vessel's interior into multiple communication zones and controls the paths between them. The specification describes the shipboard zones as remote communication (satellite and the like), business communication (corporate work and internet), navigation communication, control communication, and auxiliary communication, and places a demilitarized zone (DMZ) between them to perform security management — an intermediate network that terminates traffic arriving from one zone and re-originates it into the next, so that no zone ever has a direct path to another. The logic maps closely onto what industrial security frameworks describe as zones and conduits.
Two things matter here from a design standpoint.
First, network segmentation and boundary protection are placed at the starting point of security. Each zone is separated, traffic between zones is routed through the DMZ, and it is processed, monitored, and controlled there. This is exactly what OT security means by putting protection at the boundary: separate, relay, inspect, control.
Second, remote access is treated as a controllable session. The specification contemplates that the communication processing module inside the DMZ may include a remote access server — in current OT practice, a remote access gateway or jump host. On that basis, it describes logic for authenticating the user, monitoring the session, and constraining which systems a remote maintenance session may reach and during which time windows. This goes beyond simply allowing or blocking remote access: the session itself is defined as an object of management, and operating rules are built into the structure.
In other words, the shipbuilder has worked out at the design level how externally originating access should be structurally controlled, and the result takes the form of ship network segmentation with DMZ-based security management. A patent shows what a company thought worth protecting rather than what is necessarily installed on any hull afloat — but as a signal of design intent, it is a reliable one.
Components of an actual ship network classified by network system —
Fig. 3 of Korean Patent No. 10-2652835 (Source: KIPO gazette)
The gap that remains: accounting for who reached the control equipment
A hardened network boundary does not make incidents disappear. The risks repeatedly identified in the OT field often begin on the inside. Shared accounts, static passwords, temporary privileges handed out during vendor service visits, unauthorized configuration changes made from a maintenance laptop — these are the classic failure modes, and they persist even where the network has been well segmented.
Access to the shipboard control network — engines, power generation, valves, pumps, propulsion — is directly connected to physical safety. So it has to be clear who is connecting, whether the access is permitted at this particular moment, and what scope of actions was taken. A shipbuilder's network security design — zone segmentation, DMZ, remote session control — is an important foundation, but it does not automatically resolve the last mile: access to the control equipment itself. Three questions remain:
This gap is closed largely by strengthening user authentication at the control equipment itself.
One answer: an authentication layer directly in front of the control asset
In environments that require this kind of strengthened authentication, SSenStone's OTAC Trusted Access Gateway (OTAC TAG) can be placed immediately in front of the equipment to add an authentication layer.
SSenStone describes OTAC TAG as an OT user authentication solution installed in-line — physically in the traffic path — ahead of control assets such as PLCs, HMIs, RTUs, and DCS controllers. When a user attempts to connect from an engineering workstation, the gateway requires a One-Time Authentication Code (OTAC) — a one-way dynamic code — and permits the connection only when that code validates.
Entering that single code satisfies multi-factor authentication, which is the part worth pausing on. The OTAC can only be generated on the user's own enrolled device, a card or a smartphone, and only after the user releases generation with a PIN or a biometric. Possession of the enrolled device and the knowledge or biometric that unlocks it are therefore both bound into the one code presented. The user performs a single action at the point of access; the verifier receives evidence of two factors.
The other question an OT engineer asks of any in-line device is what happens when the device itself fails, since any device sitting in a control path is a potential single point of failure. OTAC TAG answers that with a hardware bypass: on failure it fails open, restoring the control path at the physical layer, so a fault in the authentication layer never becomes a fault in the plant. That is the deliberate trade-off OT demands — where availability is itself a safety property, an authentication device must never be the reason a ship stops.
Failing open is only acceptable, though, if the open state is visible and temporary. Here it is both: the administration server shows which gateways are in bypass, and enforcement resumes the moment a unit returns to normal. Bypass is therefore a monitored, self-closing condition rather than a silent gap in the control network — and that combination, an in-line device that cannot halt operations but also cannot quietly stop protecting them, is the first specification to check with any vendor in this category.
In a shipboard environment, adding an authentication layer this way has a further practical advantage. Where the cost of change is high and operational constraints during voyages are significant, authentication delivered through a gateway is likely to be far more practical to deploy than hardening that requires replacing the equipment or the system itself. Layered on top of the network security the shipbuilder designs — segmentation, DMZ, remote session control — authentication at the point of access materially raises assurance over who can touch control equipment.
SSenStone's OTAC Trusted Access Gateway, adding a user authentication layer in front of control equipment
Monitoring is not "later." It is continuous operation — ships need SIEM and SOC too
Security does not end with prevention. Ships in particular require detection and response, because of long voyages, the number of interconnected systems, and the complexity of the equipment and software supply chain. This is where security monitoring and analysis come in — SIEM (security information and event management) and the security operations center (SOC) that runs it.
IGLOO Corporation has publicly discussed a collaboration and validation project centered on its maritime SIEM, SPiDER OT for Maritime, in the context of vessel cyber resilience. In other words, the pieces — log collection, anomaly detection, response playbooks — are now reaching ships as actual products and delivered projects, not only as guidance.
Maritime security is complete only when design and the operation of authentication and monitoring move together
To draw it together:
1. Shipbuilders design the security architecture of the digital vessel. The DMZ-based segmentation, boundary protection, and remote session management in the Samsung Heavy Industries patent are one cross-section of that.
2. The factor that proves decisive in preventing incidents is usually an authentication question: who logged into the control equipment, and when. An authentication structure that controls the moment of access directly in front of the equipment, as OTAC TAG does, is one part of the answer.
3. For designed security to become working security, monitoring is required. IGLOO Corporation's disclosed maritime SIEM project is an early indication that this capability is being built for ships specifically.
Ships keep getting larger, carry more equipment, and are more densely connected to the outside world. As a result, security is no longer an added cost. It is becoming standard equipment. The shipbuilder lays the path through design — segmentation, boundary protection, remote session management. Authentication locks the last door on it. Monitoring keeps watch over both. Maritime security can no longer be achieved by any single company's technology. It becomes a competitive advantage for the digital vessel when design, authentication, and monitoring are treated as equal components of a single system.
By Karl Taekyun Chung, Partner Attorney
and Head of Strategy, BLT Patent & Law Firm
#MaritimeCybersecurity #ShipCybersecurity #OTSecurity #ICSSecurity #AutonomousShips #RemoteOperations #SmartShip #DigitalVessel #IACS #UR_E26 #UR_E27 #IMO #CyberResilience #NetworkSegmentation #ZonesAndConduits #DMZ #SecureRemoteAccess #UserAuthentication #MFA #OTAC #SSenStone #HardwareBypass #FailOpen #PLCSecurity #SCADASecurity #ControlSystemSecurity #SIEM #SOC #SecurityMonitoring #SamsungHeavyIndustries #Shipbuilding #PatentAnalysis #IPStrategy #KoreanIPFirm #BLT
Ships have been connected to networks for a long time. What has changed recently is not the volume of connectivity but its character. Satellite-based remote support, predictive maintenance, fleet-wide data integration, and the constant interconnection of navigation, engine, cargo, and safety systems have turned the vessel from an isolated machine into a moving system of operational technology (OT) — the industrial control systems that run machinery. In that environment, security cannot be an option bolted on later. It has to be a specification, one that covers network boundaries, remote access, logging, and incident response from the design stage onward.
The regulatory picture points the same way. The International Association of Classification Societies (IACS) issued Unified Requirements E26 (cyber resilience of ships) and E27 (cyber resilience of on-board systems and equipment), pushing the industry to build cyber requirements into design and construction rather than bolt them on afterward. After revising the requirements in light of industry experience, IACS set the effective date: the URs apply to newbuildings contracted for construction on or after July 1, 2024 — and because Unified Requirements bind IACS member societies, which write them into their own class rules, this is a condition of classification rather than guidance. The International Maritime Organization's guidelines on maritime cyber risk management reinforce the same trend, treating cyber as a material dimension of vessel operational risk.
Networked vessels requiring strengthened security
Shipbuilders are putting network security on the drawings: what a Samsung Heavy Industries patent shows
The patent record indicates that at least one major shipbuilder has begun treating security as a fundamental design element rather than as an afterthought added once the ship is in service.
Samsung Heavy Industries' ship network security patent (Korean Patent No. 10-2652835) claims an architecture that divides the vessel's interior into multiple communication zones and controls the paths between them. The specification describes the shipboard zones as remote communication (satellite and the like), business communication (corporate work and internet), navigation communication, control communication, and auxiliary communication, and places a demilitarized zone (DMZ) between them to perform security management — an intermediate network that terminates traffic arriving from one zone and re-originates it into the next, so that no zone ever has a direct path to another. The logic maps closely onto what industrial security frameworks describe as zones and conduits.
Two things matter here from a design standpoint.
First, network segmentation and boundary protection are placed at the starting point of security. Each zone is separated, traffic between zones is routed through the DMZ, and it is processed, monitored, and controlled there. This is exactly what OT security means by putting protection at the boundary: separate, relay, inspect, control.
Second, remote access is treated as a controllable session. The specification contemplates that the communication processing module inside the DMZ may include a remote access server — in current OT practice, a remote access gateway or jump host. On that basis, it describes logic for authenticating the user, monitoring the session, and constraining which systems a remote maintenance session may reach and during which time windows. This goes beyond simply allowing or blocking remote access: the session itself is defined as an object of management, and operating rules are built into the structure.
In other words, the shipbuilder has worked out at the design level how externally originating access should be structurally controlled, and the result takes the form of ship network segmentation with DMZ-based security management. A patent shows what a company thought worth protecting rather than what is necessarily installed on any hull afloat — but as a signal of design intent, it is a reliable one.
Components of an actual ship network classified by network system —
Fig. 3 of Korean Patent No. 10-2652835 (Source: KIPO gazette)
The gap that remains: accounting for who reached the control equipment
A hardened network boundary does not make incidents disappear. The risks repeatedly identified in the OT field often begin on the inside. Shared accounts, static passwords, temporary privileges handed out during vendor service visits, unauthorized configuration changes made from a maintenance laptop — these are the classic failure modes, and they persist even where the network has been well segmented.
Access to the shipboard control network — engines, power generation, valves, pumps, propulsion — is directly connected to physical safety. So it has to be clear who is connecting, whether the access is permitted at this particular moment, and what scope of actions was taken. A shipbuilder's network security design — zone segmentation, DMZ, remote session control — is an important foundation, but it does not automatically resolve the last mile: access to the control equipment itself. Three questions remain:
Is there a tamper-evident audit trail of who changed what and when, good enough for both day-to-day operations and post-incident investigation?
This gap is closed largely by strengthening user authentication at the control equipment itself.
One answer: an authentication layer directly in front of the control asset
In environments that require this kind of strengthened authentication, SSenStone's OTAC Trusted Access Gateway (OTAC TAG) can be placed immediately in front of the equipment to add an authentication layer.
SSenStone describes OTAC TAG as an OT user authentication solution installed in-line — physically in the traffic path — ahead of control assets such as PLCs, HMIs, RTUs, and DCS controllers. When a user attempts to connect from an engineering workstation, the gateway requires a One-Time Authentication Code (OTAC) — a one-way dynamic code — and permits the connection only when that code validates.
Entering that single code satisfies multi-factor authentication, which is the part worth pausing on. The OTAC can only be generated on the user's own enrolled device, a card or a smartphone, and only after the user releases generation with a PIN or a biometric. Possession of the enrolled device and the knowledge or biometric that unlocks it are therefore both bound into the one code presented. The user performs a single action at the point of access; the verifier receives evidence of two factors.
The other question an OT engineer asks of any in-line device is what happens when the device itself fails, since any device sitting in a control path is a potential single point of failure. OTAC TAG answers that with a hardware bypass: on failure it fails open, restoring the control path at the physical layer, so a fault in the authentication layer never becomes a fault in the plant. That is the deliberate trade-off OT demands — where availability is itself a safety property, an authentication device must never be the reason a ship stops.
Failing open is only acceptable, though, if the open state is visible and temporary. Here it is both: the administration server shows which gateways are in bypass, and enforcement resumes the moment a unit returns to normal. Bypass is therefore a monitored, self-closing condition rather than a silent gap in the control network — and that combination, an in-line device that cannot halt operations but also cannot quietly stop protecting them, is the first specification to check with any vendor in this category.
In a shipboard environment, adding an authentication layer this way has a further practical advantage. Where the cost of change is high and operational constraints during voyages are significant, authentication delivered through a gateway is likely to be far more practical to deploy than hardening that requires replacing the equipment or the system itself. Layered on top of the network security the shipbuilder designs — segmentation, DMZ, remote session control — authentication at the point of access materially raises assurance over who can touch control equipment.
SSenStone's OTAC Trusted Access Gateway, adding a user authentication layer in front of control equipment
Monitoring is not "later." It is continuous operation — ships need SIEM and SOC too
Security does not end with prevention. Ships in particular require detection and response, because of long voyages, the number of interconnected systems, and the complexity of the equipment and software supply chain. This is where security monitoring and analysis come in — SIEM (security information and event management) and the security operations center (SOC) that runs it.
IGLOO Corporation has publicly discussed a collaboration and validation project centered on its maritime SIEM, SPiDER OT for Maritime, in the context of vessel cyber resilience. In other words, the pieces — log collection, anomaly detection, response playbooks — are now reaching ships as actual products and delivered projects, not only as guidance.
Maritime security is complete only when design and the operation of authentication and monitoring move together
To draw it together:
1. Shipbuilders design the security architecture of the digital vessel. The DMZ-based segmentation, boundary protection, and remote session management in the Samsung Heavy Industries patent are one cross-section of that.
2. The factor that proves decisive in preventing incidents is usually an authentication question: who logged into the control equipment, and when. An authentication structure that controls the moment of access directly in front of the equipment, as OTAC TAG does, is one part of the answer.
3. For designed security to become working security, monitoring is required. IGLOO Corporation's disclosed maritime SIEM project is an early indication that this capability is being built for ships specifically.
Ships keep getting larger, carry more equipment, and are more densely connected to the outside world. As a result, security is no longer an added cost. It is becoming standard equipment. The shipbuilder lays the path through design — segmentation, boundary protection, remote session management. Authentication locks the last door on it. Monitoring keeps watch over both. Maritime security can no longer be achieved by any single company's technology. It becomes a competitive advantage for the digital vessel when design, authentication, and monitoring are treated as equal components of a single system.
By Karl Taekyun Chung, Partner Attorney
and Head of Strategy, BLT Patent & Law Firm
#MaritimeCybersecurity #ShipCybersecurity #OTSecurity #ICSSecurity #AutonomousShips #RemoteOperations #SmartShip #DigitalVessel #IACS #UR_E26 #UR_E27 #IMO #CyberResilience #NetworkSegmentation #ZonesAndConduits #DMZ #SecureRemoteAccess #UserAuthentication #MFA #OTAC #SSenStone #HardwareBypass #FailOpen #PLCSecurity #SCADASecurity #ControlSystemSecurity #SIEM #SOC #SecurityMonitoring #SamsungHeavyIndustries #Shipbuilding #PatentAnalysis #IPStrategy #KoreanIPFirm #BLT