This is the fifth post in our MTSA cybersecurity series. In the first post, we introduced the crawl, walk, run approach we’re using to work through the regulation. In the second, third, and fourth posts, we covered asset inventory, network segmentation, and resilience. This post picks up with routine system maintenance.
Nobody gets a shiny award for patching on schedule. Nobody sends a press release when their vulnerability scan returns ship-shape. However, when maintenance lapses and something breaks, everyone wants to know why it wasn’t caught sooner. The work that isn’t so glamorous must be done.
Everything covered so far (inventory, segmentation, resilience) erodes the moment you stop maintaining it. Vulnerabilities accumulate. Configurations drift. Systems that were hardened last year become entry points this year. Routine maintenance is what keeps the program from becoming a snapshot of a moment that no longer exists.
The regulation breaks routine maintenance into six areas: identifying vulnerabilities, sharing risk, fixing and mitigating issues, configuration management, reducing exposure, and the human layer of access reviews and logging. In the first post, we introduced crawl, walk, run as the way we work through every MTSA requirement in this series. Here’s what that progression looks like applied to maintenance.
At this stage, you don’t have a maintenance program yet; you have the minimum that keeps something from breaking silently.
Identifying vulnerabilities: Maintain an asset inventory, even if it’s spreadsheet-based. Apply manual patching on a periodic basis, as feasible for OT systems, and run basic antivirus and signature updates where applicable.
Configuration management: Document maintenance responsibilities, who owns what. Establish a vendor contact and process for updates and support, and perform ad hoc system health checks: logs, uptime, errors.
Fixing and mitigating issues: Identify systems with no current patch process and document compensating controls. Note known end-of-life systems and flag them for review, and track open vendor advisories relevant to installed systems.
At this stage, the deliverables are basic: an asset inventory with patch status, a vendor contact list, a maintenance ownership register, and a list of unpatched or end-of-life systems with documented rationale.
This is where the regulation’s actual requirements live.
Identifying vulnerabilities: Maritime owners and operators must have a process for receiving and acting on publicly submitted vulnerabilities. The process can be straightforward: an email inbox monitored for relevant vulnerabilities, a triage step to assess your exposure, and a defined path to implement mitigations or compensating controls. The goal is a clear, repeatable way to receive vulnerability information and act on it before someone else does.
If that sounds simple, it is, in theory. In practice, organizations can get lost in the fog with the volume of CVEs published daily. The email notifications go into a folder and are lost at sea, turning a blind eye to the warnings. Start with the Known Exploited Vulnerabilities list. Those are not theoretical; someone is actively using them against systems like yours.
The Cybersecurity Plan must define your vulnerability scanning processes and procedures. This will include regular scanning on all IT systems and planned scans on OT systems. OT systems scanning must be carefully planned because active and intensive scanning can crash legacy devices, which could cause critical process downtime and safety risks. It is important to define frequency, scope, and tools to be used in your Cybersecurity Plan. Scanning for vulnerabilities in the environment will strengthen resilience by providing visibility into weaknesses you may not know exist. At this stage, vulnerability scanning is credentialed where possible and passive for sensitive OT, remediation is tracked and prioritized using risk-based scoring, and change management processes are integrated for all system updates.
Sharing risk: in addition to having a way to receive vulnerability information, you must also have a way to share threat and vulnerability information with others, such as industry groups, government entities, stakeholders, and partners. This practice supports resilience efforts across maritime operations by preventing vulnerabilities from becoming widespread operational disruptions across many vessels or facilities within the larger environment.
Fixing and mitigating issues: The regulation is clear: apply patches to your systems or implement and document compensating controls for all Known Exploited Vulnerabilities (KEVs) in all critical IT and OT systems, immediately. This cannot be a plan to do later or put off; it demands focus and attention from maritime organizations. We want to be direct with this one: “We are working on a plan to patch” is not a compensating control. It is an empty statement that may make you feel better, but pair it with something that reduces risk while you work through your change management process.
A defined process to track KEVs, prioritize them, and to patch or apply/document compensating controls must be implemented. Unlike IT systems, OT systems commonly are unable to, or it is not feasible to immediately apply patches; therefore, compensating controls must be implemented to harden systems and keep the environment protected. KEVs are actively being exploited. Leaving vulnerable control systems unprotected is not a calculated risk - it’s an open gangway, especially when uptime is critical to safety. At this stage, a formal patch management process with defined timelines is in place, maintenance windows are scheduled and aligned with operations, compensating controls are documented for systems that cannot be patched immediately, and the KEV catalog is reviewed regularly against the installed asset inventory.
Configuration management: Patching is half of the maintenance equation; the other half is configuration. MTSA expects that systems will operate with secure baseline configurations. Unnecessary services must be battened down, default credentials must be changed, and open ports must be closed unless they are explicitly required and documented. Like everything else, this is not a set-it-and-forget-it scenario; this must be ongoing to avoid configuration drift. Hardened devices can accumulate exposure over months of small, undocumented changes. A formal configuration management process is what keeps hardening from becoming a one-time event. This means everyone must have accurate baseline documentation, change tracking, and periodic validation against the baseline to be effective. At this stage, configuration baselines are established and monitored for drift, and maintenance logs and audit trails are kept for all changes.
Reducing exposure: Eliminate direct internet exposure and restrict OT connectivity to the internet. Measures must be taken to remove exploitable channels in the OT environment. This entails locking down the environment by closing open ports, managing remote access tools, and securing internet-facing services through network segmentation, firewalls, and comprehensive access controls. Removing direct internet exposure from the environment reduces the attack surface and lessens the likelihood of intrusion by opportunistic bad actors.
OT systems should not talk to the internet; instead, they should be isolated from external communication. The exception to this would be if a vendor needs remote access, in which case the vendor access must be controlled, limited, and documented thoroughly. OT environments are not created with a security backbone and are not designed to be exposed to the internet. Even the most limited connectivity can introduce exploitability risk and compromise safety and operations if not controlled.
We have found internet-facing OT systems at facilities where the operators were genuinely unaware they were exposed. Not negligent, unaware. That is exactly why asset inventory comes first. You cannot batten a hatch you don’t know exists.
Access reviews and logging: Routine maintenance also includes the human layer. Regular access reviews need to be conducted to audit who has credentials, whether they are the right credentials, whether personnel who are no longer with the company have had their credentials removed, review privileged accounts, and rotate any shared credentials. MTSA will also expect systems to generate and retain logs that are robust enough to support incident investigations. Retention periods must be defined, adequate storage must be obtained, and confirmation that logs from critical systems are being collected and accessible is a must.
At this stage, the deliverables mature: a formal patch management policy, vulnerability scan reports, configuration baselines, maintenance logs, and a risk-scored remediation backlog.
Run: Optimized and risk-driven maintenance, proactive, intelligence-driven, and tied to mission risk
This is where maintenance stops being a checklist and starts running on its own signal.
Identifying vulnerabilities: Use threat intel to prioritize patching, focusing on exploits active in the wild. Continuously monitor systems with predictive maintenance analytics, and integrate maintenance workflows with the SOC and OT monitoring functions.
Fixing and mitigating issues: Implement automated patch deployment where safe, across IT and select OT systems, and apply digital twin or isolated test environments to validate updates before deployment. Track KPIs, including MTTR, patch SLAs, and vulnerability aging, tied to operational risk, report maintenance posture to leadership in mission-impact terms, and continuously reduce the attack surface through the scheduled decommissioning of legacy systems.
Configuration management: Align the maintenance program with the NIST, CSF, or IEC 62443 framework controls.
At this stage, the deliverables reflect a program that runs itself: automated patch reports, threat-intel-driven prioritization records, a KPI dashboard, framework alignment mapping, and test environment validation logs.
Maintenance is what keeps the first three layers from decaying. An asset inventory, a segmented architecture, and a resilience program are only as accurate as their last verification, and patching, vulnerability management, and configuration hardening are what keep them from drifting out of compliance between audits. But maintenance assumes the devices underneath were secured correctly in the first place. That’s device security: the requirement that first introduced asset inventory, and the subject of the next post in this series, covering what MTSA expects for the rest of the devices running your OT environment.
- Routine System Maintenance Maturity Framework has a crawl, walk, and run breakdown across vulnerability intake, patch and configuration management, and risk and exposure for maritime OT environments.
Talk to a Dragos expert about closing the gaps.
