This is the seventh 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 through sixth posts, we covered asset inventory, network segmentation, resilience, routine maintenance, and device security. This post picks up with account security, the second of the two technical control requirements the Coast Guard paired to form the rule’s technical core.
Account security failures can have real-world and organizational impacts that go well beyond a single stolen password. In May 2021, DarkSide ransomware operators shut down the largest fuel pipeline in the United States. Colonial Pipeline’s 5,500 miles of pipeline carry roughly 45% of the East Coast’s gasoline, diesel, and jet fuel. The company took its own pipeline offline as a precaution when the ransomware hit its IT and billing systems, not because its operational technology was directly compromised, but because it couldn’t yet confirm it wasn’t. Within days, fuel shortages and panic buying spread across the Southeast, and Colonial’s CEO later testified to Congress that paying the $4.4 million ransom in Bitcoin was one of the toughest decisions he’d ever made.
How could this happen? A single compromised password. An employee had reused a VPN password that had already leaked in an unrelated breach, and it turned up in a batch of credentials for sale on the dark web. The account itself belonged to someone who was no longer using it, but nobody had revoked it. And there was no MFA on that account, so a password alone was enough to get in.
One reused password. One account nobody deprovisioned. No MFA to catch either one. That’s not a sophisticated attack chain. That’s three ordinary account security gaps, compounding into the costliest pipeline shutdown in U.S. history.
Account security is a big lift, but a phased sequence gets every box checked well ahead of July 16, 2027, when the Cybersecurity Plan, which documents this requirement in Section 7, is due to the Coast Guard.
§ 101.650(a) requires, at minimum, the following seven account security measures:
• (1) Account lockout: Automatic account lockout after repeated failed login attempts, enabled on all password-protected IT systems.
• (2) Default credentials: Change default passwords before using any IT or OT system; where infeasible, document compensating controls.
• (3) Password strength: Maintain a minimum password strength on all IT and OT systems technically capable of password protection.
• (4) Multifactor authentication: Implement MFA on password-protected IT systems and remotely accessible OT systems; document compensating controls where infeasible.
• (5) Least privilege: Apply least-privilege principles to administrator/privileged accounts on both IT and OT systems.
• (6) Credential separation: Maintain separate user credentials on critical IT and OT systems (no shared/generic accounts).
• (7) Deprovisioning: Remove or revoke user credentials when a user leaves the organization.
Although the regulation doesn’t stagger the minimum requirements, looking at this with the crawl, walk, run framework will allow for smooth compliance.
Crawl: close the obvious gaps before automating anything
Inventory accounts and access. You cannot protect what you don’t know you have. Catalog and inventory all IT and OT accounts. This will include all administrative or privileged accounts, service, vendor, and shared accounts. Inventory accounts across all covered vessels, facilities, and OCS facilities. While you’re at it, confirm which systems your CySO has designated as critical IT or OT, since that determination puts credential separation and several other requirements below in scope; we covered how that designation gets made in the second post of this series. The list of administrator and privileged accounts on IT and OT can be a starting point for applying least-privilege principles to these accounts.
Enable account lockout. This one’s simple: turn on automated account lockout after repeated failed login attempts for all password-protected IT systems and document the failed-login threshold and lockout duration you set by system type. The regulation only requires this on IT; OT isn’t in scope for lockout specifically, but consider extending it for parity anywhere a lockout won’t interfere with safety-critical availability. Flag service, automation, and other non-human accounts now: a lockout policy that locks out a scheduled job instead of a person needs its own exception path, not a blanket rule.
Eliminate or document default credentials. Identify all systems, new and legacy, that run on default credentials, cross-referencing your asset inventory against vendor documentation and running a credential scan where you can safely do so on IT, and either change the credentials or document the compensating controls along with the reasoning of why the default cannot be changed.
Set a baseline password policy. Establish a minimum password strength requirement across IT and password-capable OT systems, and separately document how you’ll handle the systems that can’t technically enforce a password policy at all, compensating controls, network isolation, or physical access restriction are common starting points. The regulation does not specify complexity requirements, following current NIST password recommendations is a great place to start:
• Minimum length: 8 characters, 15+ characters for single-factor authentication
• No composition rules
• Accept all ASCII characters
• No forced rotation/password expiration
Deprovisioning processes. Begin defining how credentials get revoked, not just when someone leaves but when someone changes roles. Build a manual joiner-mover-leaver process: HR or the hiring manager submits the request, IT or OT confirms which systems the person had access to, and someone signs off that it’s been pulled. Set a target, five business days is reasonable for a full leaver, even before you automate it. An account left adrift for weeks is exactly the gap that shows up in the next incident report.
Assign Ownership. Confirm the CySO, or a named delegate, owns Section 7 of the Cybersecurity Plan and the account security documentation behind it. Put the name and the annual audit date in writing, not a verbal understanding, and define what that audit actually checks: current account inventory, outstanding default credentials, and any compensating controls still on the books. Every account security program needs someone at the helm, and Section 7 is no exception.
Walk: formalize account controls across their full lifecycle
Roll out MFA. Implement MFA on password-protected IT systems, all remotely accessible OT systems, and any vendor or third-party remote access into either environment, and document compensating controls for legacy OT where MFA is not feasible. A jump host that itself requires MFA, or network isolation that removes the remote path entirely, are two common starting points. MFA works by combining at least two of three factor types, something you know (a password), something you have (a token or authenticator app), or something you are (biometrics); confirm whatever you deploy actually combines two, not two flavors of the same factor.
Formalize least privilege. Take the inventory of privileged accounts from the Crawl phase and enhance it to a formal process: role-based access mapped to job function, a documented approval workflow for granting elevated access, and a quarterly review cadence for administrative and privileged accounts across both IT and OT. Anyone who no longer needs elevated access based on their current role gets brought back down to standard access at that same review, too many hands on the wheel is how ships run aground.
Separate IT and OT credentials. Remove all instances of shared and cross-domain credentials and ensure that critical IT and OT systems use distinct credentials. Decide, deliberately, whether IT and OT will run on separate identity stores or a federated model bridging the two; that architecture choice shapes how enforceable this separation actually is going forward.
Formalize a commissioning procedure. Build default-credential elimination into how new IT and OT systems get commissioned in the first place, so nothing goes live carrying a vendor default password to begin with.
Automate deprovisioning. Integrate credential revocation with HR/offboarding workflows, instead of manually putting things in motion. Extend the same process to contractor and third-party accounts, which tend to fall outside standard HR triggers, and settle on a timeliness standard, same-day revocation is a reasonable bar, rather than leaving it open-ended.
Formalize compensating controls. Where password/MFA controls aren’t technically feasible on OT, document a consistent, auditable compensating-control methodology: for each affected system, record why the control can’t be applied, what’s in place instead (network isolation, physical access restriction, a jump host with its own MFA), who approved the exception, and a review date to reconsider it as the system ages out. A one-line justification won’t hold water when an auditor, or the Coast Guard, comes calling.
Write it into the Plan. Convert working practices into the formal Section 7 account security narrative and evidence package for the Cybersecurity Plan. The Coast Guard’s own rulemaking ties some of this rule’s terminology, including how logging is worded elsewhere in § 101.650, to NIST and CISA’s Cybersecurity Performance Goals; keeping your account security documentation consistent with that same language doesn’t hurt.
Train personnel. Deliver account-security-specific content as part of the broader cybersecurity training program required under § 101.650(d): password hygiene, phishing recognition tied to credential theft, and role-specific training for anyone holding administrative or privileged access. Refresh it annually and any time the controls themselves change, so the whole crew, not just the officers, knows how to avoid steering into a phishing email.
Run: make privileged and anomalous account activity a same-day signal
Centralize IAM/PAM. Move toward a centralized identity and privileged access management capability spanning the IT/OT boundary, with just-in-time, time-bound privileged access as the maturity target rather than standing administrative rights.
Continuous monitoring. Alert on lockouts, failed-login spikes, and anomalous privileged-account activity, logins outside normal hours, access from a new location, or privilege escalation attempts, and feed all of it into the logging required under § 101.650(c)(1). Define actual thresholds up front, three failed logins in five minutes, for example, rather than leaving “anomalous” to interpretation after the fact.
Periodic access recertification. Recertify privileged and remote-access accounts on a recurring basis, quarterly is a reasonable starting cadence for anything privileged, and audit for orphaned or stale accounts, the ones nobody remembered to revoke, on the same schedule. Anything that hasn’t authenticated in 90 days should get flagged automatically rather than waiting for the next cycle.
Validate through testing. Use the § 101.650(e)(2) penetration test cycle to probe account controls (lockout bypass, credential stuffing, privilege escalation).
Continuous improvement. Feed findings from the annual Cybersecurity Assessment (e)(1) and any incidents back into Section 7 via Plan amendments.
Report metrics. Track and report KPIs to leadership/CySO, e.g., % of accounts with MFA, mean time to deprovision, count of shared/default/orphaned accounts remaining.
Account security answers who’s allowed to touch a system. It doesn’t answer what happens to the data once they’re in, whether it’s logged, protected, and encrypted the way it needs to be. That’s data security, the subject of the next post in this series.
Need help validating account security across your fleet?
