Somewhere in your last three PLC or remote access gateway RFPs, a vendor probably attached a PDF with a name like “Secure by Design Attestation” or “Product Security Roadmap.” It has a checklist. It has the CISA secure-by-design pledge logo, or language borrowed from it. It looks like due diligence. Whether it actually tells you anything useful about the risk you’re accepting is a separate question, and most plant IT and controls teams don’t have a good way to answer it.
That’s the gap this piece is trying to close. CISA’s secure-by-design initiative has moved from a voluntary pledge with broad principles into something more concrete: vendors publishing their own attestation documents and multi-year security roadmaps, often in response to pressure from the pledge itself and from customers who finally started asking. That’s genuine progress. But an attestation is a claim, not a control. If you’re evaluating PLCs, HMIs, or remote access gateways for a 2026 buy, you need to read these documents the way a controls engineer reads a vendor’s stated cycle time — as a number to verify, not a number to trust.
Why attestations are suddenly everywhere
The secure-by-design pledge asks vendors to make measurable progress on a defined set of goals: reducing default passwords, enabling multi-factor authentication by default, publishing memory-safe roadmaps, improving vulnerability disclosure, and reducing the prevalence of classes of vulnerability like SQL injection and path traversal in their products. It’s a framework, not a certification, and it deliberately leaves implementation detail to the vendor. That’s reasonable for a voluntary industry-wide pledge covering everything from cloud SaaS to industrial controllers. It’s also exactly why the resulting documents vary wildly in how much they actually commit to.
Automation vendors have responded in different ways. Some have published genuinely detailed technical roadmaps with version-specific commitments — this firmware release removes hardcoded credentials, this gateway model moves to certificate-based authentication by this milestone. Others have published something closer to a values statement: broad language about “prioritizing security” and “working closely with CISA,” with little that a procurement team could hold them to contractually. Both kinds of documents can carry the same pledge badge. The badge tells you the vendor participated in the conversation. It doesn’t tell you what they actually shipped.
A rubric for reading the attestation in front of you
When an attestation lands in your RFP response pile, run it against these questions before you let it count for anything in your scoring matrix.
Does it name a mechanism, or does it name a goal?
“We are committed to eliminating default credentials” is a goal. “Every unit ships with a unique per-device credential generated at manufacture, and there is no factory-set password that works across the product line” is a mechanism. Score mechanisms. Discount goals to zero — they’re marketing copy until they’re falsified into something specific.
Is remote access default-deny, or default-permit with an opt-out?
This is the single highest-leverage question for remote access gateways specifically. A gateway that ships with remote access disabled and requires deliberate configuration to enable an inbound path is a fundamentally different risk posture than one that ships listening on a management port with a documented (or worse, undocumented) way to turn it off. Ask the vendor directly: what listens on the network interface out of the box, on which ports, and what has to happen before any inbound session is possible. If the answer is vague, that’s your answer.
Is firmware signed, and is signature verification enforced or optional?
Signed firmware that the controller doesn’t actually check before executing an update is theater. You want the vendor to state, in writing, that the device rejects unsigned or improperly signed firmware images by default, not that signing capability “is available.” Ask what happens if someone pushes an unsigned image over the engineering port — does it fail closed, or does the device happily run it?
Does the roadmap have dates and versions, or does it have quarters and “soon”?
A credible roadmap names the firmware version or release train where a given control lands and gives you something to hold the vendor to at your next renewal or upgrade cycle. A roadmap that says a feature is “planned” with no version tied to it is a promise with no expiration date, which functionally means no promise at all.
Who verifies the claim, and what happens if it’s wrong?
Self-attestation means the vendor is grading their own homework. That’s not disqualifying — most of the industry runs this way for now — but it means the contractual weight has to come from you. If the attestation isn’t referenced anywhere in the actual purchase agreement, it’s not a commitment, it’s a cover letter.
RFP language that forces specifics instead of checkboxes
The fix isn’t to reject every attestation you get — it’s to stop accepting the document itself as evidence and start requiring answers that a document alone can’t satisfy. A few clauses worth adding to your next PLC or remote access gateway RFP:
- Require the vendor to state, per product SKU and firmware version, whether remote access is disabled by default and what specific action is required to enable it.
- Require a written statement on firmware signature enforcement: enforced by default, optional, or not supported — no other category accepted.
- Require disclosure of any hardcoded or shared factory credentials in the current shipping firmware, with a remediation date if any exist. Silence on this question should be scored as a “yes.”
- Tie the vendor’s published roadmap commitments to specific firmware or hardware revisions, and require notification obligations if a committed date slips.
- Require that the attestation document, or the specific technical claims in it, be incorporated by reference into the purchase agreement — not just attached as a PDF exhibit with no contractual status.
- Ask for the vendor’s process for handling a disclosed vulnerability in the product being purchased: patch cadence, advisory publication, and whether IEC 62443-4-1 or an equivalent secure development lifecycle process governs it.
None of this requires exotic legal drafting. It requires refusing to let “we support the CISA secure-by-design pledge” stand in for an answer to “does this gateway accept unsigned firmware.”
What this means for your 2026 buying cycle
The honest reality is that secure-by-design maturity varies enormously across the PLC and remote access gateway market right now, and it will keep varying for a while — this is a multi-year industry shift, not a switch that flipped. Treating every attestation as equally credible rewards the vendors who invested in a good PDF over the ones who invested in the engineering. Treating every attestation as worthless throws away real signal from the vendors who did the work and are willing to be specific about it.
Your job in the RFP is to make the vendors sort themselves. Ask for mechanisms, not commitments. Ask for versions, not quarters. Ask what happens by default, not what’s configurable if someone remembers to configure it. The vendors with substantive secure-by-design programs will answer these questions in detail because they can. The ones leaning on the pledge as a marketing asset will hedge, and that hedge is the most useful data point you’ll get out of the entire procurement.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
