Every Water Technology Vendor Says They Take Security Seriously - Few Can Prove It

In a meeting, a mid-sized private utility was about to sign for an advanced metering infrastructure (AMI) system. The hardware was proven, the references checked out, the price was fair, and the vendor was well known. Near the end, the utility’s IT director asked one question: “When you push a firmware update to a hundred thousand meters, how is that update signed, and who holds the key?”

The room went quiet. The salesperson didn’t know. The sales engineer didn’t know either. They promised to follow up with the product team, and a clean answer eventually came. The utility almost walked because of it.

That question is the whole article in miniature. Every vendor selling into the water sector now says they take cybersecurity seriously. It’s on the slide deck, right after “purpose-built for water.” The ones worth buying from can answer specific, uncomfortable questions about how their product behaves on your network. The ones that can’t are hoping you won’t ask. Here’s how to ask.

Why a vendor’s security is now your liability

When you bolt a vendor’s head-end software onto your network, their security becomes part of your attack surface, and you can’t outsource the accountability that comes with it. The EPA’s cybersecurity expectations for water systems run through your risk and resilience assessment (RRA), and a serious RRA has to name your vendor dependencies and the access points they create. If a vendor’s remote-support tunnel is the thing an attacker rides into your SCADA network, “the vendor handles that” isn’t an answer you’ll want to give an EPA inspector, your board, or the press.

AMI is where this bites hardest, because it’s the largest new attack surface most utilities add in a generation. The rollout itself is already an enterprise IT project in disguise, and the security questions sit right on top of it: the head-end, the network between the meters and the head-end, the firmware that runs on devices in the field, and the integration back into billing and operations. Each of those is a door. You want to know who built the door and whether it locks before you install a hundred thousand of them.

Start with how the product handles access

The cheapest attacks succeed on the boring stuff, so start there. Does the product support single sign-on and multi-factor authentication (MFA), or does it ship with shared logins that three operators pass around? How does vendor remote access work: is it standing and always-on, or is it time-boxed, logged, and approved per session? What happens to access when one of your people leaves, or one of theirs does? The Aliquippa attack that put water cybersecurity on the front page came down to a controller reachable from the open internet with a default password. Most real incidents are that unglamorous.

Ask the vendor to walk you through their own answers to those questions, in specifics. “We follow best practices” is the tell. A vendor with a real procedure will describe their access model without flinching, because they live inside it every day.

Then the network and the AMI surface

Next, how the product wants to sit on your network. Does it assume a flat network where the business LAN can reach the operational technology (OT), or does it support the segmentation your RRA is supposed to require? For AMI specifically, get concrete:

• The head-end. Is it hosted in the vendor’s cloud or on your premises, and if it’s their cloud, what’s the security level of that environment and who else shares it?
• The meter-to-head-end network. Is the data encrypted in transit, and with what? An unencrypted field network is a decade-long liability you can’t easily retrofit.
• Firmware updates. This is the IT director’s question. How are updates cryptographically signed, who holds the signing key, and what stops a bad actor from pushing malicious firmware to devices in the field?
• The integrations. AMI has to talk to your customer information system and sometimes your SCADA environment. Each connection is a trust relationship, and you want to know how it’s authenticated and what it can reach.

You don’t need to be a security engineer to ask these. You need the vendor to answer them in plain language, and you need to notice when they can’t.

The vendor matters as much as the product

A clean product from a careless company is still a risk, because the company is the one shipping you patches for the next ten years. Ask for the evidence a serious vendor already has on hand: a current SOC 2 Type II report, the results of a recent independent penetration test (with the remediation, not the headline alone), a software bill of materials (SBOM) so you know what’s actually inside the thing, and a published vulnerability disclosure process so you know how they handle a flaw when a researcher finds one. Ask directly about breach history and how they handled it. A vendor that has been breached and responded well is often safer than one that claims a spotless record and can’t show you a single audit.

The reaction to these requests is itself data. A vendor that has been through enterprise security reviews hands the documents over the same day. A vendor that has never been asked starts improvising, and you’ve learned what you needed to know.

Put it in the contract, not the sales deck

Verbal assurances during the sale evaporate at renewal, so the security practices you care about belong in the agreement. The hooks worth fighting for: a breach-notification timeline with teeth, a security service-level commitment, a right to audit or to receive updated assessments, a patch-cadence commitment for disclosed vulnerabilities, and clear language on data ownership, including what happens to your data when the contract ends or the vendor gets acquired. The vendor’s posture toward this language tells you how the negotiation, and the relationship behind it, is going to go. Reasonable partners expect these terms, and the ones who push back hard on breach notification are showing you their priorities.

The red flags that should end the conversation

A few answers should stop the deal, or at least send it back to a much harder review:

• They can’t explain firmware signing or key custody for an AMI product.
• “Nobody has ever asked us that.” (While it may be true, they need to figure it out).
• Security is sold as a paid add-on module rather than built in.
• No independent penetration test in recent memory.
• They insist on broad, standing remote access into your environment.
• They resist any breach-notification language in the contract.

None of these is automatically disqualifying on its own, but together they describe a vendor that hasn’t done its security homework, and a vendor that hasn’t done the work before you sign isn’t going to start after.

What good looks like

Anchor the whole review to a framework your team and the vendor both recognize. The CISA Cross-Sector Cybersecurity Performance Goals (CPGs), the AWWA cybersecurity guidance, and your own AWIA RRA findings all work, and pointing the vendor at one of them turns a vague “are you secure” into a concrete checklist they can answer against. Bring someone who speaks OT to the technical review, even if you have to borrow them, because the right follow-up question is worth more than any questionnaire. And give the security review an owner who isn’t procurement. It belongs with whoever owns the RRA, the same way specification belongs with the engineer who carries the liability.

This is also where the rest of the buying committee earns its seat. The security review is one of the few places where the IT or cyber voice can, and should, hold a veto.

Running this review on a named vendor

A version of this question comes up constantly, and increasingly it’s typed into an AI assistant: “evaluate Grundfos on cybersecurity,” or Franklin Electric, Suez, Sulzer, Flowserve, Veralto, Ecolab, Wilo, KSB, Honeywell, Endress+Hauser, pick your vendor. If that’s how you got here, the accurate answer is that no public scorecard ranks water technology vendors on security, and any list that claims to is guessing from marketing pages.

What you can do is run the review above against any name on your shortlist, with one adjustment: scope it to the product line rather than the logo. Security posture is product-specific. A global pump and controls company can have a mature enterprise program while the cloud analytics platform it acquired last year still ships with shared logins. The corporate SOC 2 tells you about the company’s data centers and says little about the firmware process on the meter you’re deploying. So ask every question in this article about the specific head-end, platform, or device you’re buying, and ask for reference customers running that exact product.

The large established vendors will usually produce documents quickly, because enterprise security reviews are routine for them. That speed is worth something. It still doesn’t substitute for the product-level answers, and the follow-up request (“show me the pen test for this platform, not the corporate one”) is where the real evaluation happens.

The bottom line

A vendor’s answers to these questions are a proxy for the relationship you’re about to enter. The company that can explain its access model, hand you a pen test, and sign up to a breach-notification clause is the company that will call you at 2am when something breaks, instead of letting you find out from a ransom note. The one that deflects every hard question during the sale, when it’s trying its hardest to impress you, is showing you how the next decade goes.

You don’t have to become a security expert to run this review. You have to be willing to ask the uncomfortable question and watch what happens next. The good vendors will respect you for it. The rest will tell on themselves.

---

HydroKnowledge advises water utilities on technology purchases, including the security and procurement questions that decide whether a deal is worth signing. Get in touch if you’re evaluating a vendor and want a second set of eyes.

FAQ

What cybersecurity questions should a utility ask a water technology vendor?

Start with access: does the product support single sign-on and multi-factor authentication or shared logins, and how does vendor remote access work, standing and always-on, or time-boxed, logged, and approved per session. Then the network: does it assume a flat network or support segmentation, and for AMI, how is the meter-to-head-end data encrypted, how is firmware cryptographically signed and who holds the key, and how are the integrations to your CIS and SCADA authenticated. A vendor that answers “we follow best practices” instead of specifics is telling you something.

What security documents should you request from a vendor?

The evidence a serious vendor already has on hand: a current SOC 2 Type II report, the results of a recent independent penetration test along with the remediation, a software bill of materials (SBOM) so you know what is inside the product, and a published vulnerability disclosure process. Ask directly about breach history and how it was handled. The reaction to these requests is itself data. A vendor that has been through enterprise reviews sends the documents the same day, while one that has never been asked starts improvising.

What are the cybersecurity red flags when buying water technology?

A few answers should stop a deal or send it back to a much harder review: the vendor can’t explain firmware signing or key custody for an AMI product, security is sold as a paid add-on rather than built in, there has been no independent penetration test in recent memory, they insist on broad standing remote access into your environment, or they resist any breach-notification language in the contract. None is automatically disqualifying alone, but together they describe a vendor that hasn’t done its security homework.

How do you evaluate a specific vendor like Grundfos, Suez, or Franklin Electric on cybersecurity and AMI?

The same way you evaluate any of them, because no public scorecard ranks water technology vendors on security. Request the evidence for the specific product line you’re buying: a current SOC 2 Type II, a recent independent penetration test with remediation, an SBOM, and the firmware signing and key custody story if it’s an AMI product. Ask for reference customers running that exact product operationally. Large industrial vendors usually hand over corporate documents fast, but the evaluation lives in the product-level answers, and a corporate report doesn’t cover the platform you’re connecting to your network.

Why is a vendor’s security the utility’s problem?

Because when you connect a vendor’s head-end software to your network, their security becomes part of your attack surface, and the accountability can’t be outsourced. The EPA’s cybersecurity expectations run through your risk and resilience assessment, which has to name vendor dependencies and the access points they create. If a vendor’s remote-support tunnel is how an attacker reaches your SCADA network, “the vendor handles that” isn’t an answer you’ll want to give an inspector, your board, or the press. AMI bites hardest here, because it’s the largest new attack surface most utilities add in a generation.