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

Imagine sitting in on a discussion where 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 vendor was well known. Near the end, the utility’s IT director, who had been quiet for most of the meeting, 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 actually 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” is not 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 their security homework, and a vendor that hasn’t done the work before you sign is not 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.

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.