If you’re drafting a PLC, HMI, or historian RFP this year, you’ve probably already seen it: a section titled something like “Secure by Design Attestation” or “Vendor Security Questionnaire,” lifted more or less directly from CISA’s Secure by Demand guidance. It’s showing up because large utilities and a handful of major manufacturers have started writing it into procurement language, and once a few anchor buyers do that, the rest of the supply chain follows. That’s a good thing. It’s also, right now, mostly being implemented badly.
The problem isn’t the framework. Secure by Demand, as CISA has laid it out, asks reasonable questions: does the vendor publish a secure software development lifecycle, do they eliminate default credentials, do they support memory-safe languages where it matters, do they issue VEX documents alongside vulnerability disclosures. The problem is that most procurement teams are pasting these questions into an RFP as a compliance exercise — a box every vendor checks “yes” to — rather than as a scoring rubric that actually separates vendors who’ve done the engineering work from vendors who’ve hired someone to write good answers.
My argument here is simple: some Secure by Demand questions are load-bearing. They correlate with real engineering practice and you can verify the answers. Others are paperwork theater — they invite a “yes,” nobody checks, and the vendor’s actual posture never changes. If you’re building your first Secure by Demand-informed RFP for the back half of 2026, you need to know which is which before you send it out.
The questions that actually filter vendors
Default credentials: ask for the mechanism, not the promise
Every OT vendor will tell you they’ve “addressed” default credentials. The question that actually filters is more specific: does the device or software refuse to operate in a default-credential state, or does it merely allow you to change the password if you know to do it? A PLC or HMI that ships with admin/admin and simply lets you change it later is not the same as one that forces credential provisioning during commissioning and won’t come out of a locked-down state until that happens. Ask the vendor to walk you through the out-of-box state on a demo unit, live, during the technical evaluation. If they can’t demonstrate it in the room, the attestation in the RFP response is worth nothing.
VEX-backed disclosure, not just a CVE feed
Almost every vendor of any size now points to a security advisory page. That’s not the differentiator anymore. What separates a mature vendor is whether they publish Vulnerability Exploitability eXchange (VEX) statements alongside CVEs — meaning they tell you, component by component, whether a given vulnerability in an underlying library actually affects your specific product configuration, and why. A vendor bundling a component with a known CVE and just shipping a generic “we are aware and monitoring” notice is doing the minimum. A vendor issuing VEX documents is doing the engineering work of actually tracing exploitability through their own codebase. Ask for a sample VEX document from a past disclosure, not a description of the process. If they can’t produce one, they don’t have the practice yet — they have the intention.
Memory-safe engineering: ask about the roadmap for what’s already shipping
Nobody is rewriting a mature PLC firmware base in Rust overnight, and any vendor who claims otherwise is selling you something. The realistic, useful question is narrower: for new modules, new protocol stacks, and new network-facing services, is the vendor moving to memory-safe languages, and can they show you which recently released components were built that way? Ask specifically about the components most exposed to the network — web servers embedded in HMIs, OPC UA stacks, any parser handling untrusted input. That’s where memory corruption vulnerabilities actually get exploited in the field. A vendor who can name specific components and specific transitions is telling you something real. A vendor who answers with a general statement about “prioritizing secure coding practices” is giving you the industry’s most common non-answer.
SBOM as a living artifact, not a PDF at time of sale
Ask whether the software bill of materials updates with patches and point releases, or whether it’s a static document generated once for the RFP. A historian platform that ships quarterly patches needs an SBOM process that regenerates with each release — otherwise you’re maintaining a vulnerability picture that’s stale within a quarter. Ask to see two SBOMs from two different releases of the same product and compare them. If the vendor can’t produce that, their SBOM practice is a sales artifact, not an engineering one.
The questions that just generate paperwork
Not every Secure by Demand-style question earns its place in the rubric. Watch for these patterns, because they’re common and they waste evaluation time without telling you anything:
- “Does your organization have a secure development lifecycle policy?” Every vendor answers yes. A policy document proves nothing about whether engineers follow it. Ask instead for evidence tied to a specific recent product release — threat model artifacts, a fuzzing report, a third-party pen test summary.
- General attestations of “following NIST guidance” or “aligning with IEC 62423-4-1” without specifics. Alignment claims without a mapped control list are marketing language, not evidence.
- “Will you sign a memorandum of understanding on Secure by Design principles?” CISA’s own pledge is voluntary and non-binding by design — it’s a public commitment, not a contractual warranty. Getting a vendor to sign something equivalent for your RFP feels productive but changes no incentives and creates no liability. If you want teeth, put specific, testable requirements into the contract’s service level terms instead.
- Open-ended incident response questions like “describe your vulnerability disclosure process” without asking for time-to-patch history on past CVEs. Process descriptions are cheap. A track record of actual patch timelines for previously disclosed vulnerabilities in the exact product line you’re buying is the thing worth scoring.
Build the rubric before you build the RFP
The practical move for plant IT and controls engineering teams working through 2026 procurement cycles is to separate the RFP into two tiers explicitly. Tier one is attestation — the vendor states policies and intentions, weighted lightly, mostly there because your legal or compliance team wants it on record. Tier two is demonstrated evidence — live default-credential behavior, sample VEX output, comparative SBOMs across releases, named memory-safe components in recent releases, and patch-timeline history on past disclosures. Weight tier two heavily, and make clear in the RFP that non-response or vague response on tier two items scores as a fail, not a neutral.
This also changes how you run the technical evaluation. Instead of a written questionnaire alone, build in a short technical session — even thirty minutes — where the vendor’s engineering team, not just sales, demonstrates the default-credential behavior and produces a sample VEX and SBOM live. Vendors who’ve actually built the practice can do this without notice. Vendors who’ve only built the RFP response cannot, and that gap is exactly what you’re trying to surface before the PLC is on your floor for the next decade.
Secure by Demand is only as useful as the discipline you bring to scoring it. Treated as a checklist, it becomes another compliance artifact nobody reads after contract signature. Treated as a live rubric with demonstrated evidence requirements, it’s one of the better tools plant IT teams have right now for telling apart vendors who’ve actually done the engineering from vendors who’ve learned to answer the questionnaire well.
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.
