A recurring pattern in OT projects: security requirements are only explicitly tested at the Site Acceptance Test, when design choices are already fixed and changes have become expensive. The more effective point of leverage lies much earlier: in the procurement conditions.
Why procurement is the best moment
At the moment of procurement the asset owner still has full room to negotiate. Requirements laid down at this point — for example around authentication, logging, patch policy and support periods — are much easier for a vendor or integrator to accommodate than changes requested only after delivery.
Concrete requirements that are often missing
- Explicit Security Level requirements per component, instead of a general reference to "IEC 62443 compliant".
- A documented vendor patch policy, including the expected response time for critical vulnerabilities.
- A point of contact for responsible disclosure, so that vulnerabilities found can be reported and followed up in a structured way.
- Clarity about end-of-life policy, so that it is known in good time when a component will no longer be supported.
- Evidence during FAT/SAT as a contractual delivery condition, not as an optional extra.
What this means for system integrators
For system integrators this is also an opportunity: parties that can already demonstrate these requirements structurally stand out in tenders from parties that try to demonstrate security only afterwards, ad hoc. IEC 62443-2-4 offers a concrete frame of reference for this.
A small investment with a big effect
Tightening procurement conditions takes relatively little time compared with remedying shortcomings afterwards in an operational environment. For asset owners who are just starting a tender process, this is one of the most cost-effective security measures available.