The security of a plant is largely fixed on the day its controllers, HMIs and engineering software are bought, and most OT tenders still ask almost nothing about it. A PLC with hard-coded passwords, no logging and a ten-year life will be in service long after the project team has moved on, and asset owners then spend years building compensating controls around it. In January 2025 CISA and partner agencies from the United States, Australia, Canada, the European Commission, Germany, the Netherlands, New Zealand and the United Kingdom published Secure by Demand priority considerations that give OT buyers twelve concrete security elements to ask manufacturers about. This guide turns those elements into requirements, evidence requests, scoring and contract language for controllers, HMIs, SCADA and DCS platforms, IIoT devices and the integrators who deliver them. It is for OT engineers, procurement leads and security architects writing tenders, and complements the OT Security Platform Buyer's Guide, which covers buying security monitoring tools rather than control products.
Key takeaways
- Ask the twelve questions every time. The Secure by Demand OT priorities cover configuration management, logging, open standards, ownership, data protection, secure defaults, secure communications, secure controls, strong authentication, threat modelling, vulnerability management and patch tooling.
- Demand evidence, not assurances. Ask for SBOMs, sample CSAF advisories, published end-of-life dates, threat model summaries and certifications such as ISASecure CSA or SDLA against IEC 62443-4-2 and 4-1.
- Security features belong in the base product. The guidance expects logging, role-based access control and phishing-resistant MFA without paid add-ons; write that into the specification.
- Contract for the whole life. Support periods, free security patches, compatibility testing turnaround and vulnerability notification need to be contractual, not marketing.
- Test before you accept. Add security checks to factory and site acceptance tests so that defaults, open ports and accounts are verified before handover.
Why procurement is the strongest OT security lever
- Long service lives: controllers and DCS platforms often run for fifteen years or more, so each purchase sets the risk baseline for a generation of equipment.
- Retrofitting is expensive: adding authentication or logging after installation usually means new hardware or a full upgrade project, while asking at tender stage costs little.
- Collective demand moves markets: the purpose of Secure by Demand is that consistent questions from many buyers push manufacturers to build security in by default. See the Software Liability and Secure by Design Policy Guide.
- Regulation is arriving: the EU Cyber Resilience Act entered into force on 10 December 2024 and its main obligations apply from 11 December 2027, with vulnerability and incident reporting obligations applying earlier, from 11 September 2026. Products with digital elements sold in the EU will need to meet essential cybersecurity requirements. See the EU Cyber Resilience Act Guide.
The twelve Secure by Demand elements as requirements
The table restates each element from the January 2025 joint guide as a requirement you can place in a specification, with the evidence to request. Element names are as published; the requirement wording is NHI Mgmt Group's adaptation.
| Element | Requirement to specify | Evidence to request |
|---|---|---|
| Configuration Management | The product tracks and controls changes to configuration and engineering logic and supports secure backup and restore | Description of change tracking, sample change log, backup and restore procedure |
| Logging in the Baseline Product | Security, safety and change events are logged by default in open formats, without paid add-ons | Event catalogue, sample logs, supported export formats (for example syslog) |
| Open Standards | The product uses open, interoperable standards so the buyer can add or change suppliers | List of supported protocols and standards, including secure variants |
| Ownership | The operator can maintain and change the product without unnecessary supplier dependency, and may add security tools | Licensing terms, statement on third-party security tools, documentation access |
| Protection of Data | Operational data is protected at rest, integrity is verifiable, and data is not shared or sold without consent | Data handling statement, encryption details, contract clause on data use |
| Secure by Default | No default passwords; secure protocols enabled and insecure ones disabled out of the box; reset to original configuration possible | Default configuration listing, hardening guide, first-boot behaviour |
| Secure Communications | Authenticated, certificate-based communication that is easy to deploy and renew, and does not stop critical processes when a certificate fails | Certificate management design, behaviour on expiry, supported key lengths |
| Secure Controls | The product resists malicious commands, keeps essential functions available and stays stable during security scans | Robustness testing results, statement on scan tolerance |
| Strong Authentication | Role-based access control and phishing-resistant MFA in the baseline version, no shared role-based passwords | Role model, supported MFA methods, directory integration options |
| Threat Modeling | The manufacturer maintains a current threat model with documented mitigations, ideally referencing public sources such as MITRE EMB3D | Threat model summary or attestation, mapping to EMB3D threats |
| Vulnerability Management | CVE-based process, SBOM, machine-readable advisories (CSAF), coordinated disclosure policy and timely, free patches | SBOM sample, CSAF feed URL, disclosure policy, historic advisory list |
| Upgrade and Patch Tooling | Documented, verifiable, compatibility-tested and free patching and upgrades, published end-of-life dates, support for modern operating systems | Patch procedure, signing method, lifecycle policy with dates, supported OS list |
Certifications and evidence that carry weight
| Evidence | What it shows | How to use it |
|---|---|---|
| ISASecure CSA (IEC 62443-4-2) | A component has been assessed against component security requirements | Check the certified model, firmware version and security level match what you are buying |
| ISASecure SDLA (IEC 62443-4-1) | The supplier's secure development lifecycle has been assessed | Strong signal for long-lived platforms; ask for the certificate scope |
| ISASecure SSA (IEC 62443-3-3) | A system has been assessed against system security requirements | Useful for DCS and SCADA platforms delivered as a system |
| ISASecure ACSSA (62443-2-1, 2-4, 3-2, 3-3) | Assessment of an automation and control system as deployed | Relevant where an integrator delivers a complete solution |
| SBOM | Software components and versions | Feed into vulnerability matching. See the SBOM Guide |
| CSAF advisory feed | Machine-readable vulnerability information | Confirm a provider-metadata.json exists and advisories include product versions. See the CSAF Security Advisories Guide |
| Published lifecycle policy | Support and end-of-life dates | Compare with planned asset life; price extended support up front |
| Threat model mapped to MITRE EMB3D | Which embedded device threats the supplier considered and mitigated | Identify unmitigated threats you must cover with compensating controls |
For how the product security parts of the standard work, see the IEC 62443-4-1 and 4-2 Secure Product Development Guide and the ISASecure Certification Guide. A certificate covers a specific product version and scope; it is evidence, not a guarantee.
Contract language to include
- Support period: "[Supplier] shall provide security updates for [Product] at no additional charge until at least [date], and shall give [Organisation] at least [24] months' notice of end of support."
- Vulnerability notification: "[Supplier] shall notify [Organisation] of vulnerabilities affecting delivered versions within [5] business days of confirming them, and publish advisories in CSAF 2.0 format."
- Patch qualification: "[Supplier] shall state compatibility of third-party operating system and component updates with [Product] within [30] days of their release, and within [7] days for vulnerabilities listed in the CISA KEV catalogue." See the OT Patch Management Guide.
- Secure defaults: "Products shall be delivered with no default or hard-coded credentials, unused services disabled and logging enabled as documented in the hardening guide."
- SBOM: "[Supplier] shall provide a machine-readable SBOM for each delivered firmware and software version and update it with each release."
- Security tooling rights: "[Organisation] may deploy passive network monitoring and endpoint security tools on the system without voiding warranty or support, subject to documented compatibility guidance."
- Data use: "Operational data collected by the product or supplier services shall not be sold or shared with third parties without [Organisation]'s written consent."
Adapt periods to the product class and your sector, and have legal review the final wording. For wider clause sets, see the Third-Party Security Contract Clauses Template.
Integrators and service providers
Most OT products reach site through a system integrator who configures, programs and often maintains them. IEC 62443-2-4 sets security requirements for these service providers. In tenders, require the integrator to:
- Deliver hardened: apply the manufacturer's hardening guide and document every deviation.
- Hand over all credentials: transfer and then let you rotate every account created during commissioning; no integrator-only accounts left behind.
- Use your remote access: connect only through your brokered remote access with named accounts and MFA. See the OT Remote Access Guide.
- Protect project files: engineering projects, passwords and network diagrams held securely and returned or destroyed at contract end.
- Deliver documentation: asset inventory with versions, network drawings, conduit rules and backup copies at handover.
See the OT Third-Party and Integrator Access Guide.
Where identity fits
Three of the twelve elements are identity questions. Strong Authentication asks for role-based access and phishing-resistant MFA in the base product and an end to shared role passwords; Secure by Default rules out default credentials; Secure Communications depends on certificates, which are machine identities that need issuing, renewal and revocation. Ask how the product integrates with your directory, how service accounts between HMIs, historians and controllers are created and rotated, and what happens to the process when a device certificate expires. See the OT and ICS Identity and Access Guide and the Device and IoT Identity Guide.
Decision guidance: proportionate requirements
Not every purchase needs every element as a hard requirement. Set the bar by where the product will sit and what it controls, so that small purchases are not blocked and critical ones are not waved through.
| Purchase type | Mandatory (pass or fail) | Scored | Evidence depth |
|---|---|---|---|
| Safety or high-criticality controllers, DCS and SCADA platforms | Secure by Default, Strong Authentication, Vulnerability Management, Upgrade and Patch Tooling, Logging, published support period | Remaining elements, with Secure Controls and Threat Modeling weighted highly | Certificates (CSA, SDLA or SSA), SBOM, threat model summary, lab test of a sample |
| Supervisory and site systems (HMIs, historians, engineering software) | Secure by Default, Vulnerability Management, Upgrade and Patch Tooling, support period | Strong Authentication, Logging, Secure Communications, Ownership | Questionnaire with documents, SBOM, CSAF feed check |
| Field devices and IIoT sensors | No default credentials, signed firmware updates, support period | Secure Communications, Protection of Data, Open Standards | Questionnaire, hardening guide, update procedure |
| Small spares and like-for-like replacements | Supported firmware version, no known exploited flaws unmitigated | None | Check against supplier advisories and KEV |
Where no compliant product exists, which is common for specialised controllers, choose the best available, record the gaps and the compensating controls, and send the gap list to the supplier as a formal request for the roadmap. That feedback is the point of Secure by Demand.
Running a secure OT procurement
- Classify the purchase: zone, criticality, safety role and target security level, so that requirements are proportionate. See the IEC 62443-3-2 OT Risk Assessment Guide.
- Write requirements from the twelve elements: mark each as mandatory or scored, depending on the classification.
- Issue a security questionnaire with evidence requests: the table above, plus certificate copies and lifecycle dates.
- Score responses: weight mandatory items as pass or fail; for scored items, give more weight to authentication, secure defaults, vulnerability management and patch tooling for high-criticality zones.
- Verify in a test: where possible, assess a sample unit for open ports, default accounts, logging and behaviour under a standard scan in a lab. See the Safe Active Scanning and Testing in OT Guide.
- Contract: include support, notification, qualification, SBOM and tooling rights clauses.
- Accept with security tests: add checks to the factory acceptance test (FAT) and site acceptance test (SAT): defaults changed, unused services off, logs reaching the collector, backups restorable, credentials handed over.
- Record residual gaps: unmet requirements become dated compensating controls and feedback to the supplier for the next release.
Small and large buyers: a small utility or manufacturer can still ask the twelve questions in a short questionnaire and insist on the support period and notification clauses, which cost nothing. Large operators and buying groups should publish a standard OT security specification, share supplier responses across sites and track supplier performance over time.
Measuring the programme
- Percentage of OT purchases above a threshold value that included the security requirements and questionnaire.
- Percentage of new OT assets delivered with no default credentials and logging enabled, verified at SAT.
- Percentage of new assets with a documented support end date and SBOM on file.
- Number of suppliers in the OT inventory with a working CSAF feed or equivalent advisory subscription.
- Number of unmet mandatory requirements accepted by exception, and their age.
- Median supplier patch qualification time compared with the contracted value.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-04, GV.SC-05, GV.SC-06, GV.SC-07, ID.RA-09 | Supplier criticality, requirements in contracts, due diligence, supplier risk, integrity of acquired hardware and software |
| NIST SP 800-53 Rev. 5 | SA-4, SA-8, SA-11, SA-22, SR-3, SR-4, SR-5 | Acquisition process, engineering principles, developer testing, unsupported components, supply chain controls, provenance, acquisition strategies |
| IEC 62443 | 2-4, 3-3, 4-1, 4-2 | Service provider, system, development lifecycle and component requirements. See the IEC 62443 Guide |
| ISO/IEC 27001:2022 | A.5.19, A.5.20, A.5.21 | Supplier relationships, security in supplier agreements, ICT supply chain |
| EU Cyber Resilience Act | Essential requirements for products with digital elements | Manufacturer obligations from 11 December 2027 |
| MITRE EMB3D | Device properties, threats and mitigations | Common language for supplier threat models |
Common failure patterns
- Security as a checkbox: a generic "complies with IEC 62443" line with no version, security level or evidence.
- Security features as paid options: logging, MFA or encryption priced as add-ons and cut when the budget tightens, contrary to the baseline expectation in the guidance.
- No support date: products bought without a published end-of-life date, leaving the operator unpatched mid-life.
- Integrator accounts never handed over: shared commissioning passwords stay valid for years after go-live.
- Acceptance tests ignore security: FAT and SAT check function only, so defaults and open services reach production.
- Tooling rights missing: the warranty forbids monitoring or endpoint agents, blocking later security controls.
Practitioner checklist
- Use the twelve Secure by Demand elements as the backbone of every OT specification.
- Classify each purchase by zone, criticality and target security level.
- Request evidence: SBOM, CSAF feed, lifecycle dates, threat model summary and certificates.
- Require logging, role-based access and phishing-resistant MFA in the base product.
- Contract for support period, vulnerability notification, patch qualification timelines and free security updates.
- Secure the right to deploy monitoring and endpoint tools.
- Add security checks to FAT and SAT and verify credential handover.
- Record unmet requirements as dated compensating controls.
- Report procurement coverage and supplier performance to OT and security leadership.
Standards and references
- CISA and partners: Secure by Demand Priority Considerations for OT Owners and Operators when Selecting Digital Products
- ISA: ISA/IEC 62443 Series of Standards
- ISASecure: Certification programmes
- MITRE: EMB3D Threat Model for Embedded Devices
- OASIS: Common Security Advisory Framework Version 2.0
- European Commission: Cyber Resilience Act
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: OT Security Platform Buyer's Guide · OT Security Guide · Third-Party Risk Management Guide · IEC 62443-4-1 and 4-2 Secure Product Development Guide · EU Cyber Resilience Act Guide