Most OT security advice is written for organizations with a CISO, a security operations center, and a budget line for threat intelligence. You have three people, a truck, and forty remote sites. This guide is for you. It covers what actually threatens small operators (opportunistic attacks, not nation-states), the five controls that stop most of them, what you can honestly defer, and how to make a managed platform carry the security workload your team doesn't have hours for - so a small operation ends up with a posture many larger ones would envy.
Explore the full security & certification article series - 60+ practitioner guides.
Let's describe the actual situation instead of the one security vendors imagine. Your "IT department" is whoever is best with computers, plus maybe a contractor who visits monthly. The SCADA system was set up by an integrator years ago, and changing it feels risky. Remote sites talk over cellular modems someone else provisioned. Passwords are shared because the HMI only has one login. Nobody has time to read a 300-page framework, and the capital budget competes with pumps that actually move product.
Here's the encouraging part: security outcomes at this scale are decided by a handful of fundamentals, not by tooling. The incidents that hit small operators - ransomware through an exposed remote desktop, a hijacked email account, an ex-employee's login that still worked - are precisely the ones basic controls prevent. A small team that nails five things is better defended than a large enterprise with a SOC and a flat network. Frameworks like NIST SP 800-82 and ISA/IEC 62443 matter as you grow (our secure SCADA buyer's guide maps that territory), but none of them work without the fundamentals below.
Small operators mostly aren't targeted; they're found. Automated campaigns scan the entire internet for exposed VNC, RDP, and web panels; credential-stuffing bots try leaked passwords against everything; phishing kits go to every address they can harvest. The attacker frequently doesn't know the victim runs a water system until they're inside. Three threat categories cover most of the real risk:
What largely isn't your threat model: Stuxnet-class engineering. Designing for nation-state adversaries while your VNC port is open is buying a vault door for a tent. The defensive consequence is liberating - the attacks that will actually reach you are the cheapest ones to stop.
This is the same philosophy behind CISA's Cross-Sector Cybersecurity Performance Goals - a deliberately short, prioritized baseline written for organizations without dedicated security staff. Our version for small SCADA operators:
Right-sizing means saying no to good ideas whose prerequisites you don't have. Deferring these isn't negligence - it's sequencing:
The deepest small-team insight is that most security controls are operational, not architectural - they fail not at design time but at 2 AM, in the patch nobody applied and the log nobody read. A managed cloud platform moves those always-on obligations to a team whose full-time job they are. That is the essence of the shared responsibility model: the vendor operates the infrastructure, application security, patching, monitoring, and backup machinery; you operate your users, your field devices, and your procedures.
| Security Task | Self-Hosted SCADA (You) | Managed Cloud SCADA |
|---|---|---|
| Server OS & platform patching | Your team, in change windows you must schedule | Vendor, continuously |
| TLS certificates & encryption | Your team (and expiry outages when forgotten) | Vendor-managed |
| Intrusion & anomaly monitoring | Requires tooling and attention you don't have | Vendor runtime threat monitoring with alerts to you |
| Backup execution & validation | Your team, tested rarely in practice | Vendor-operated with validated archives; you verify export access |
| MFA, roles, session controls | Depends on what your platform supports and how it was configured | Built in; you assign roles and enforce use |
| User lifecycle & offboarding | Yours either way | Yours either way - no vendor can fire your ex-employee's account for you |
| Field device & PLC security | Yours either way | Yours either way, with gateway isolation reducing exposure |
The honest caveat: this only works if the vendor actually operates those controls well, which is why evaluation matters even more for small operators - you're outsourcing what you can't independently verify day to day. As a concrete example of what "built in" should mean: Merobix ships TOTP and passkey MFA, named roles from viewer to admin, site-level authorization, brute-force lockout, and immutable audit records as standard platform behavior - not configuration projects. Its gateway is outbound-only (no inbound ports at your sites, no static IPs to buy), telemetry is signed at the device with replay detection, and security events can be delivered straight to email or SMS, so a three-person team gets told about repeated failed logins without owning a SIEM. The full control list is public on our security page - and that public documentation is itself the pattern to demand from any vendor: readiness programs and control mappings you can read, not just logos. Cost-wise, the same shift usually favors small teams too; the arithmetic is in our .
Key takeaway: A small operator's winning strategy is concentration, not coverage: eliminate internet exposure, require MFA, use named least-privilege accounts, keep tested backups, and contain what you can't patch - then let a well-run managed platform carry the 24/7 operational load of everything else. Security you must remember to do will eventually not get done; security that ships as default behavior keeps working when your team is busy pulling a pump.
Block four hours. No tools beyond a browser, a phone hotspot, and your router logins:
Every finding becomes a budgetable task - most cost attention, not dollars. Water utilities should note that AWIA Section 2013 risk and resilience assessments and several states' rules increasingly expect exactly this kind of documented baseline; our water utility SCADA guide covers the sector's specifics.
Right-sizing is a stage, not a ceiling. Signals that it's time to graduate to the fuller program: a regulator or insurer asks for monitoring evidence you can't produce; user count crosses a few dozen and quarterly access reviews stop being a glance; a customer contract flows down security requirements; or you're operating infrastructure whose failure makes the news. At that point, add SIEM export from your platform, formalize access reviews, and start walking a framework deliberately - with the fundamentals already in place, that climb is far shorter. And if you're evaluating platforms now, take the vendor-question checklist from our buyer's guide into every call, or pressure-test the answers in a live demo.
Yes - but mostly not the way headlines suggest. Small operators are rarely singled out by sophisticated adversaries; they are swept up by opportunistic campaigns that scan the whole internet for exposed services, spray stolen credentials at everything, and deploy ransomware wherever a foothold lands. The attacker often does not know or care that the victim runs a water system or a gas gathering network until after they are in. That is actually good news for defenders: opportunistic attacks are stopped by a small set of fundamental controls, not by enterprise tooling.
Five controls deliver most of the risk reduction: remove every internet-exposed service from your sites (port forwards, VNC, RDP, public-IP cellular modems); require MFA on every remote login; give every person a named account with least-privilege roles and disable accounts the day someone leaves; keep tested offline backups of SCADA configurations and historian data; and keep the systems you can patch patched, with compensating controls around the ones you cannot. A three-person team can realistically operate all five - especially if the SCADA platform ships with MFA, roles, and audit logging built in rather than as configuration projects.
For most small operations, yes - initially. A SIEM you do not have time to watch, tune, and respond to produces alert fatigue, not security. Right-sizing means using the built-in detection and alerting of a managed platform (failed-login alerts, security notifications delivered to email or SMS) and revisiting the decision as you grow. Signals that you have outgrown this stage include regulatory obligations that require monitoring evidence, cyber-insurance requirements, dozens of users, or contractual customer demands - at that point, SIEM export from your SCADA platform becomes the practical on-ramp.
For a small team, a well-run managed cloud platform usually delivers a stronger achieved posture than self-hosted SCADA, because the controls that are hardest for small teams - patching servers, maintaining TLS, monitoring for intrusions, testing backups, running identity infrastructure - become the vendor's full-time job rather than your spare-time job. The honest caveat: this is only true if the vendor actually operates those controls well, so evaluation matters. Ask about MFA, tenant isolation, signed telemetry, audit trails, backup validation, and how the vendor proves each - a serious vendor documents all of this.
Run a one-afternoon self-audit: list your public IP addresses and check them from outside for open ports; inventory every router for port-forwarding rules; list every person with SCADA access and confirm each has their own account and that departed staff are disabled; turn on MFA everywhere it exists; verify you can actually restore a backup of your SCADA configuration; and write down, on one page, who you would call in an incident. Every finding from that afternoon is a concrete, budgetable task - and most cost far more in attention than in dollars.
MFA, named roles, audit trails, outbound-only gateways, and security alerts to your phone - running from day one, without a security hire.