SaaS Security: What Water Teaches You About Your System

There is a panel from your system open on the internet right now. You probably don't know which one. It could be the inventory admin, the CRM dashboard your old vendor set up, or that spreadsheet shared "with anyone with the link". SaaS security usually fails exactly there: not at genius hackers, but at doors someone forgot open.

In August 2026, the former head of the NSA, Paul Nakasone, said something simple after a series of suspected Iran-linked attacks on water systems in the United States: water station controllers should not be on the internet. Period. It wasn't a problem of advanced encryption. It was people putting the equipment that opens and closes valves on a public network, often with the default password.

If a water treatment plant makes that mistake, your scheduling SaaS can too. The difference is nobody will write a news story about you. The loss stays with you alone.

Why water systems ended up on the internet

The answer is boring: convenience. The operator wanted to check the reservoir level from their phone, at home, at 11pm. The controller vendor offered remote access. Someone opened a port on the router and that was it. It worked for years. Nobody went back to close it.

In the reported cases, the intruders didn't even need sophisticated technique. They searched the internet for known devices, tried the factory password and got in. In some towns, they changed settings and forced operations into manual mode. In others, they just left a message on the screen.

This is the part that matters for you: a real attack is almost never a movie. It's someone trying the handle on every door on the street and walking into the one that was unlocked.

Your business has the same vulnerability

Swap "valve controller" for any system that runs your company. I see this all the time at small and mid-sized clients:

• Website admin panel reachable at /admin with user admin and the password the developer set in 2019.
• Cloud database with the port open to any IP, because "the programmer needed access from home".
• Automation in n8n or Make with a public webhook that accepts any request, no token at all.
• WhatsApp integration using an API key pasted into a file that sits on GitHub, public.
• Cameras, turnstile, time clock system, all with remote access on and the factory password.

None of these is exotic. I've found every one of them auditing clients who thought they were "fine". One was a clinic with patient data. The scheduling system's API was open with no authentication. Anyone with the URL could list name, phone and appointment time.

Security isn't about locking well. It's about not leaving the door on the street.

What "should not be on the internet" means in practice

Nakasone's advice has a logic that works for any system. Before asking "how do I protect this?", ask "does this need to be reachable from outside?".

In most cases, the answer is no. The database only needs to talk to the application. The internal panel only needs to be accessed by the team. The webhook only needs to accept calls from one specific vendor.

Thinking this way, the list of things that actually need to stay exposed shrinks a lot. What's left is the company website, the customer area and, at most, one or two integration points. Everything else can sit behind a VPN, an allowed IP list, or simply be turned off.

This isn't expensive. Closing the database port so it only accepts the application server is a ten-minute setting on any cloud provider. Putting a token on the webhook is one line. The expensive part is the leak afterwards.

Four questions to ask your vendor today

You don't need to understand firewalls to demand this. You need to ask the right questions to whoever takes care of your system, whether it's a freelancer, an agency or the nephew who "knows computers".

1. Which company services are reachable from the internet without a login? Ask for the list. If the person can't answer, that's already the problem.
2. Is there still any default or shared password in use? Router, panel, database, WordPress admin. One password per person, with two-factor on critical systems.
3. If the previous developer left today, could they still get into anything? Ex-vendor access is one of the most common sources of leaks. I've written about it here on the blog.
4. How do I find out I've been breached? Without logs and alerts, you only find out when a customer complains or when the data shows up for sale.

If all four answers are clear and convincing, great. If they stay vague, you just found out where to invest the next hour of your month.

The SaaS you hire counts too

There's a second side. A good part of your business runs on third-party SaaS: CRM, ERP, messaging tool, scheduling system. You don't control their server, but you control how you use it.

Two things make a real difference. First: turn on two-factor authentication everywhere it's available. It's the cheapest protection there is and most breached accounts didn't have it. Second: review who has access to what, at least every quarter. Accounts of people who already left stay active for years, and each one is a water controller plugged into the internet with the password on the label.

If your SaaS vendor doesn't offer two-factor in 2026, that says something about their maturity. Worth weighing at renewal time.

You don't need to get paranoid, you need to close doors

None of this requires you to understand security. It requires someone to look at your system with the right question: what is exposed that didn't need to be? At most companies I work with, the first round of this analysis fits in an afternoon and fixes the most obvious risks without switching systems or paying for new tools.

The water station wasn't attacked for being important. It was attacked for being visible. Your system may be far less important and just as visible.

If you want someone to comb through your system, your automation or the SaaS you built, take a look at how I work. It's usually a shorter conversation than you'd think.

There is a panel from your system open on the internet right now. You just don't know which one.

In August, the former head of the NSA summed up a wave of attacks on water stations in the US in one sentence: a valve controller should not be on the internet. It wasn't a genius hacker. It was a factory password and a port someone forgot open.

Swap "valve" for a /admin panel from 2019, a cloud database open to any IP, or an n8n webhook with no token. I've found all of them at clients who called themselves "fine", including a clinic with patient data exposed.

Security isn't about locking well. It's about not leaving the door on the street.

Before asking "how do I protect this?", ask "does this need to be reachable from outside?". In most cases, the answer is no and the fix takes an afternoon.

Want to know what's exposed in your system for no reason? Reach out, it's usually a shorter conversation than you'd think.

#InformationSecurity #SaaS #Cybersecurity #SmallBusiness #Automation