Every RFP for a new MES or PLC platform now has a line somewhere that says the vendor must “comply with IEC 62443.” Procurement teams write it because legal told them to, legal wrote it because a customer or regulator asked, and everyone signs off feeling like they did their job. Then the equipment shows up, the vendor hands over a glossy security whitepaper, and nobody on the buying side can point to a single clause that lets them reject it. That’s not a compliance gap. That’s a contract drafting failure, and it’s happening at nearly every plant still treating 62443 as a badge instead of a specification.
IEC 62443 was written as an engineering framework — a way to reason about zones, conduits, and layered defense in an industrial control system. It was never designed to be dropped whole into a purchase order as a single checkbox. But that’s exactly what’s happening now, driven partly by CISA’s push for secure-by-design attestations and partly by customers further up the supply chain demanding SBOMs and security documentation before they’ll accept a subcontractor’s equipment. Procurement is being asked to enforce OT security posture, and most purchasing departments have no idea how to translate a standard built for controls engineers into language that survives a legal review and holds up at acceptance testing.
The mistake: citing the standard, skipping the target
IEC 62443-3-3 defines seven foundational requirements — identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability — and it defines four security levels (SL 1 through SL 4) describing the threat sophistication a system is designed to resist, from casual misuse up to a well-resourced, motivated attacker. IEC 62443-4-2 takes those same requirements and applies them at the component level: PLCs, HMIs, network devices, embedded controllers.
Neither document tells you which level you need. That’s a target security level, or SL-T, and it’s supposed to come from a risk assessment specific to your zones and conduits — not from the standard itself. If your RFP says “vendor shall conform to IEC 62443-4-2” and stops there, you’ve cited a menu without ordering anything. A vendor can claim conformance at SL-1 and technically not be lying, even if your process safety zone genuinely needs SL-3.
This is the single most common defect in 62443 contract language, and it’s why so many buyers end up unable to reject a bid that “meets the standard” but doesn’t meet the plant’s actual risk profile.
Setting SL-T by zone, not by plant
A security level target isn’t a plant-wide number. It’s assigned per zone, based on consequence of compromise and the realistic threat actor you’re defending against in that zone. A reasonable working approach, consistent with how 62443-3-2 frames zone risk assessment:
- SL-1 — enterprise-facing zones, reporting layers, historian read replicas. Defends against incidental or accidental exposure, not deliberate attack.
- SL-2 — general MES functions, supervisory HMI networks, most manufacturing zones. Defends against an intentional attacker with basic tools and moderate motivation — the level most plants should treat as the floor for anything touching production.
- SL-3 — safety instrumented systems, zones with environmental, safety, or high-value product risk, any conduit where a compromise could cause physical consequence. Defends against a sophisticated attacker with moderate resources.
- SL-4 — reserved in practice for national-critical infrastructure and defense-adjacent facilities defending against well-funded, targeted campaigns. Most discrete and process manufacturers will never need to specify this, and vendors quoting SL-4 compliance for a line-side PLC should raise an eyebrow, not confidence.
The RFP work is doing a zone-and-conduit diagram before you write a single procurement clause — not after. If you can’t draw the boundary between your SL-2 supervisory network and your SL-3 safety zone, you can’t write a defensible SL-T requirement, and the vendor knows it.
What to actually demand: evidence, not assertions
This is where most contract language falls apart a second time. Even when a buyer does specify SL-T by zone, the acceptance criteria section often just says “vendor shall provide documentation of conformance.” That’s an invitation for marketing collateral.
What you want instead is specific, checkable evidence:
- Third-party certification, not self-attestation. ISASecure and similar accredited certification schemes issue actual conformance certificates against 62443-4-1 (secure development lifecycle) and 62443-4-2 (component requirements). Ask for the certificate number and the accredited lab that issued it, and verify it independently rather than accepting a PDF the vendor generated in-house.
- Component-level test reports mapped to specific requirements. A conformance claim should trace back to which of the seven foundational requirements were tested, at what SL, with what test methodology. If the vendor can’t produce a requirements traceability matrix, they’re likely asserting conformance they haven’t actually validated.
- SBOM as a contractual deliverable, not a nice-to-have. A software bill of materials in a standard format (SPDX or CycloneDX) lets you check component-level vulnerabilities against known CVEs on an ongoing basis, not just at time of purchase. Make delivery of a current SBOM at each firmware or software release a condition of the maintenance contract, not just the initial PO.
- Patch and vulnerability disclosure commitments in writing. A conformance certificate at time of sale tells you nothing about the product five years into its service life. Contract for a defined vulnerability disclosure and patch cadence, and make continued conformance — not just point-in-time conformance — a term of the agreement.
The acceptance test clause everyone forgets
None of this matters if it isn’t tied to a rejection right. The clause that actually protects you reads something like: conformance evidence for the specified SL-T, mapped to the applicable foundational requirements, is a condition of acceptance, and failure to produce it — or discovery during factory acceptance testing (FAT) or site acceptance testing (SAT) that the delivered configuration doesn’t meet the specified level — constitutes grounds for rejection or remediation at vendor cost. Without that linkage, your evidence requirements are just paperwork you collect and file.
FAT and SAT are also where you actually verify the claims instead of trusting them. If your SAT plan doesn’t include validating authentication controls, network segmentation, and logging behavior against the SL-T you specified, you’re accepting equipment on faith at the exact moment you had leverage to refuse it.
Why this is procurement’s problem now, not just engineering’s
Controls engineers have understood zone-based security thinking for years. What’s changed is that purchase orders, not project specs, are now the enforcement point, because that’s where CISA attestation pressure and customer SBOM demands are actually landing. A plant IT or controls team that writes a great security architecture but hands procurement a generic “comply with IEC 62443” clause has done the engineering and skipped the enforcement. The standard doesn’t protect you. The contract does — and only if the contract says what level, for which zone, proven by what evidence, checked at what gate.
Get that translation right once, as a template your organization reuses across RFPs, and every future PLC or MES purchase gets measurably harder for an underqualified vendor to win — which is exactly the point of writing it into procurement in the first place.
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.
