IEC 62443-2-x: the management system behind a secure industrial plant
Two of the other pieces in this series cover the technical dimension of IEC 62443. The 4-1 and 4-2 article looks at how an OEM proves their product is built securely and what their product can actually do. The 3-2 and 3-3 article looks at how the asset owner sizes the security requirement of their system and how the system integrator delivers against it. Together those four standards cover the design, the components and the delivered system. What they do not cover — and what the entire standards family is incomplete without — is the day-to-day running of things. The people who operate the plant, the procedures they follow, the policies that govern them, the patches that keep the system current, and the service providers who come on site to maintain it. That is the dimension addressed by IEC 62443 Part 2.
A useful way to see why this matters is by extending the building analogy from the previous article. If 3-2 is the architect's brief, 3-3 is the building code, 4-2 is the kitemark on each component, and 4-1 is the brick-factory's quality system, then Part 2 is the hospital management system. You can have the best architects, the strictest building code, the highest-rated components and the most rigorously controlled manufacturers, but if the hospital is then operated with sloppy hygiene, untrained staff, no audit trail of who did what, and no system for recalling faulty medical equipment, none of it will save you. Part 2 is what makes the construction matter in operation. It is the discipline that turns a secure design into a sustainably secure plant.
There are five active members of the Part 2 family — 2-1 through 2-5 — and they distribute neatly between two audiences. The asset owner is the audience for 2-1, 2-2 and 2-5, with 2-3 affecting them as well. The service provider — by which the standard means system integrators, maintenance contractors, managed-service providers and similar third parties who work on or in your IACS — is the audience for 2-4. The product supplier appears in Part 2 only in a supporting role (mainly in 2-3, where they have to provide patch information for their products in a form their customers can actually use).
This becomes important in the EU regulatory context. Under NIS2 , the asset owner's Article 21 risk-management obligations and Article 21(2)(d) supply-chain duties land squarely on the territory 2-1 and 2-4 govern. Under the Cyber Resilience Act , Article 14 vulnerability reporting from the product supplier connects to the asset owner's patch programme that IEC TR 62443-2-3 codifies. The 2-x standards are the operational layer where EU regulatory demands meet OT reality.
This article works through each of the five sub-standards in turn, then ties them together and ends with a procurement and audit checklist.
The official standards are published by the IEC and co-branded by ISA. Primary sources for each: IEC 62443-2-1:2024 , ISA TR62443-2-2:2025 , IEC TR 62443-2-3:2015 , and IEC 62443-2-4:2015/AMD1:2018 . IEC 62443-2-5 is referenced in the family overview at ISA's 62443 series page .
The 2-x family at a glance
flowchart TB
classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
classDef ao fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
classDef sp fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
classDef tr fill:#f0e4ff,stroke:#6f42c1,color:#3a1a6b,stroke-width:1px;
P2[Part 2 — Policies & Procedures
The management-system half
of IEC 62443]:::entry
P2 --> S1[62443-2-1
Security Program Requirements
for IACS Asset Owners
2024 edition
Audience: Asset Owner]:::ao
P2 --> S2[62443-2-2
Security Program Ratings
Methodology for evaluating
protection effectiveness
Audience: Asset Owner]:::ao
P2 --> S3[62443-2-3
Patch Management in the
IACS Environment
Technical Report not a Standard
Audience: Asset Owner + Product Supplier]:::tr
P2 --> S4[62443-2-4
Security Program Requirements
for IACS Service Providers
2023 edition
Audience: Service Provider]:::sp
P2 --> S5[62443-2-5
Implementation Guidance
for IACS Asset Owners
Practical how-to handbook
Audience: Asset Owner]:::aoA quick orientation before we go into each in detail. Two of these — 2-1 and 2-4 — are full normative standards: they contain requirements that an organisation either meets or does not meet, and there are external certification schemes (more on these below) that can verify the claim. One of them — 2-3 — is a Technical Report, not a standard, which means it is guidance rather than auditable requirements; it is still important, but the bar for "compliance" is different. One — 2-5 — is implementation guidance: it tells you how to do what 2-1 says you must do. And one — 2-2 — is a relatively recent addition that provides a way to measure how good your security programme actually is once you have built it. Together they form a coherent management-system framework.
IEC 62443-2-1: the asset owner's security programme
IEC 62443-2-1, formally titled "Security program requirements for IACS asset owners", is the cornerstone of Part 2 and arguably the cornerstone of the asset owner's entire IEC 62443 obligation. The standard was first published in 2010 and was substantially rewritten in August 2024 as a second edition — an update that materially changed the structure of the requirements and aligns the standard more closely with how organisations actually run their security programmes today.
What it actually is
In plain English, 2-1 defines what an asset owner's Industrial Cybersecurity Programme must contain in order to be considered well-run. The standard does not specify how the IACS itself must be built — that is the job of 3-3 — but rather what policies, procedures, processes, training arrangements, governance structures and continuous-improvement mechanisms the asset owner must have wrapped around the IACS so that it stays secure in operation. The closest analogue from the IT world is ISO/IEC 27001's Information Security Management System (ISMS), and the 2024 edition of 2-1 makes this analogy explicit by deliberately deduplicating its requirements against ISO 27001 so that an organisation that already has an ISMS does not have to do everything twice.
To return to the hospital analogy, 2-1 is the clinical governance framework — the documented system that says how the hospital is led, how clinical decisions are made and reviewed, how staff are trained and credentialled, how incidents are reported and investigated, how patient safety is monitored, how risks are tracked, how policies are kept current, and how the whole apparatus continuously improves. A hospital with sound clinical governance can deliver safe care year after year; a hospital without it is one bad day away from a Care Quality Commission notice.
The Security Program Elements
The 2024 edition of 2-1 organises its requirements into Security Program Elements (SPEs) rather than the looser chapter structure of the 2010 edition. Each SPE is a coherent grouping of requirements addressing a particular dimension of the security programme. The specific element names and counts in the published standard cover the organisational and governance dimension, configuration management, network communications, data protection, user access control, event and incident management, business continuity, system maintenance and other operational disciplines familiar from broader management-system practice. The headline categories an asset owner must address can be visualised as follows.
flowchart LR
classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
classDef elem fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
SP[IACS Security
Programme
per IEC 62443-2-1:2024]:::entry
SP --> E1[Organisation
governance, roles,
training, awareness,
physical security]:::elem
SP --> E2[Configuration
management
asset inventory,
baselines, change control]:::elem
SP --> E3[Network
communications
segmentation, conduits,
remote access]:::elem
SP --> E4[Data security
protection of data
at rest and in transit,
key management]:::elem
SP --> E5[User access
control
identification,
authentication,
authorisation]:::elem
SP --> E6[Event and
incident management
detection, response,
recovery, lessons learned]:::elem
SP --> E7[System maintenance
patch management,
backup, integrity]:::elem
SP --> E8[Business continuity
availability, disaster
recovery, contingency]:::elem
SP --> E9[Supplier and
service provider
management
links to 2-4 and 4-1]:::elem
SP --> E10[Compliance and
audit
internal audit,
management review,
continual improvement]:::elemThe crucial conceptual move in the 2024 edition is the introduction of a maturity model for evaluating these elements. Echoing the structure used in IEC 62443-4-1 for OEM development processes, the 2-1 maturity model lets an asset owner be assessed not only on whether they have a policy in place but on how consistently and effectively they are applying it across the organisation. A policy that exists on paper but is unevenly followed is at a lower maturity level than the same policy demonstrably enforced across all sites with audit evidence. The maturity model makes the standard much more useful as an external assessment instrument than the 2010 edition was, because it gives assessors a defensible scale to score against rather than a binary "have or have not".
Another important change is what 2-1 deliberately does not try to do. The 2024 edition recognises that many asset owners already operate an ISO 27001 ISMS, and rather than duplicate the policy-and-procedure scaffolding of an ISMS it explicitly defers to ISO 27001 for the generic information security management apparatus and focuses 2-1's requirements on the IACS-specific additions that an ISMS does not naturally cover. In practice this means that an asset owner with a mature ISMS can use 2-1 as a focused gap-analysis tool rather than a replacement framework, which is a substantial saving of effort and a significant improvement in clarity.
What the asset owner must objectively demonstrate
A defensible claim of compliance with IEC 62443-2-1 looks like a coherent evidence pack covering each of the Security Programme Elements at a stated maturity level, with traceability to operational practice. Concretely this means a documented IACS security policy approved at the appropriate level of the organisation, a current asset inventory of the IACS systems in scope, a risk register that links to the CRS produced under 3-2 , training records for the people who design, operate and maintain the IACS, audit reports demonstrating that policies are being followed in practice, a documented incident management process with a real history of incidents handled (or a clear track record of monitoring with nothing significant to handle), a documented change management process governing how additions and modifications to the IACS are approved, and a management review record showing that senior leadership periodically reviews the programme's effectiveness and authorises improvements.
There is now an emerging third-party certification route for asset-owner programmes: ISASecure ACSSA (Automation and Control System Security Assurance), announced in 2023 and intended to cover an operational IACS at the asset owner's site against IEC 62443-2-1, 2-3 and the relevant parts of 3-3. ACSSA is newer and less widely used than its component-side cousins (SDLA and CSA), but for asset owners in regulated sectors it is likely to become an increasingly common way of evidencing a 2-1 claim. Where ACSSA is not in play, the evidence pack route — internal audit reports, external assessor reports by recognised consultancies, integration with ISO 27001 surveillance audits — is the default. In either case, the key principle is the same: a 2-1 claim is only as strong as the evidence behind it, and the evidence must be current, organisation-wide and consistent with what an outsider would actually find if they spent a day walking around the plant.
IEC 62443-2-2: rating how good the programme actually is
If 2-1 tells the asset owner what their security programme must contain, IEC 62443-2-2 addresses the related but distinct question: how do we evaluate how well the programme is actually working? It defines a methodology for producing a Security Programme Rating — a structured, defensible scoring of an operational IACS against the requirements of the standards family.
The motivation for this is practical. An asset owner can document a beautiful security programme on paper that fails in operation; another can have a less elegant programme that is rigorously followed and genuinely effective. Looking only at the documentation cannot distinguish them. 2-2 introduces a structured way to evaluate the operational reality — what is actually configured on the network, what is actually being logged and monitored, what is actually being patched, what is actually being tested — and to produce a rating that is comparable across sites, across business units and over time.
The hospital analogy here is the CQC (Care Quality Commission) inspection rating familiar to anyone who has dealt with UK healthcare. A hospital is rated Outstanding, Good, Requires Improvement or Inadequate based on a structured assessment against published criteria. The rating is comparable across hospitals, defensible to regulators and patients, and useful internally for prioritising improvement work. 2-2 plays a similar role for an industrial security programme: it produces a rating that has meaning beyond the immediate audit, with criteria that any informed assessor can re-apply.
The rating is intended to be used in several ways. Internally, it helps senior leadership benchmark sites against each other and against the company's own historical performance. Externally, it gives a way of substantiating cybersecurity claims to regulators, insurers and customers without having to publish sensitive internal documentation. In a procurement or M&A context, it provides a defensible measure of cybersecurity posture that is independent of any single vendor's product. And in the emerging ACSSA certification scheme, a 2-2-style rating is implicit in the assessment methodology.
What an asset owner must demonstrate to claim a 2-2-derived rating is the rating itself, the methodology by which it was produced, the evidence considered, and the assessor's competence. As with 2-1, a self-declared rating is much weaker than one produced by a recognised external assessor, and the value of the rating depends critically on the assessor following the methodology faithfully — which is the same point made about any certification: the credibility of the certificate is the credibility of the certifier.
IEC TR 62443-2-3: keeping the system current
IEC TR 62443-2-3 is the patch-management member of the family. The "TR" prefix matters: this is a Technical Report rather than an International Standard. The distinction is consequential. A Technical Report is informative — it contains guidance, recommendations and good practice rather than auditable requirements. You cannot strictly be "non-compliant with 2-3" in the way you can be non-compliant with 2-1, because 2-3 does not contain shall-clauses against which to be assessed. But the practical importance of 2-3 is enormous, because patch management in an industrial context is genuinely difficult, and the absence of a coherent patch programme is the most common single weakness in an otherwise well-run IACS.
The hospital analogy here is the medical equipment maintenance and recall handling procedure. Hospital equipment has manufacturer maintenance schedules, periodic recalls, software updates and safety notices. Some of these can be applied instantly; some require the equipment to be taken out of service, which has clinical consequences; some require staff retraining; and some — for very old equipment — may have to be applied through compensating measures because the manufacturer has stopped issuing updates. A hospital that ignores recalls is dangerous; a hospital that blindly applies every update without testing in its clinical context is also dangerous. The discipline of doing this properly is what 2-3 codifies for the industrial cybersecurity equivalent.
The headline contribution of 2-3 is a structured account of what a real-world IACS patch management programme has to address: the asymmetric responsibilities between the product supplier (who must produce patches, validate them on their products, and communicate them in a usable form to their customers) and the asset owner (who must consume that information, assess applicability in their specific operational context, test patches in a representative environment, schedule application during maintenance windows, and verify that the patched system continues to function correctly). 2-3 also introduces standardised data structures for delivering patch information — the VPatch concept being the most discussed example — so that asset owners do not have to translate between every product supplier's idiosyncratic patch notification format.
For the asset owner, demonstrating a credible patch management practice means showing a documented programme that covers every component in the IACS inventory (including, importantly, the long tail of small embedded devices that are easy to overlook), a process for receiving and triaging vendor advisories, a tested approach for risk-assessing each advisory in the operational context (because not every CVE is equally relevant to every deployment), evidence of patch application during scheduled windows with verification of post-patch system behaviour, and a coherent approach for components whose vendors no longer issue patches — typically through compensating controls at the network or operational level.
For the product supplier, the demonstration runs the other way. The supplier must show that they produce patches in a timely manner for vulnerabilities affecting their products, that they communicate those patches in a usable form, that the patches have been tested in representative configurations of the product, and that they support the asset owner's testing through clear release notes, regression-test guidance and roll-back procedures. The OEM-side of 2-3 connects naturally to the obligations in 4-1's Practice 7 (Security Update Management) and to the EU Cyber Resilience Act's vulnerability-handling requirements , so for product suppliers operating in regulated markets these obligations are increasingly being baked into product roadmap discipline rather than treated as an optional extra.
IEC 62443-2-4: the service provider's security programme
If 2-1 governs the asset owner's house, IEC 62443-2-4 governs the conduct of everyone who comes onto the asset owner's site to design, integrate, maintain or operate the IACS. The standard is titled "Security program requirements for IACS service providers", and its current edition is the 2023 second edition. The "service provider" in 2-4 covers a wide range of organisations: system integrators (who design and build the integrated system per the asset owner's CRS), automation contractors, maintenance contractors, managed-service providers, security service providers running monitoring or incident response on behalf of the asset owner, and any organisation whose people have hands on the asset owner's IACS.
The hospital analogy here is the medical staffing agency's accreditation and audit regime. A hospital that allows agency nurses to work on its wards has to know that the agency vets its staff, trains them, maintains their professional registrations, audits their performance, and is itself subject to inspection. A hospital that takes agency staff with no verification of any of those things is exposed to clinical risk that has nothing to do with how well the hospital itself is run. 2-4 plays the same role for service providers in the industrial security space: it tells the asset owner what to insist on from anyone who works on their IACS, and it tells the service provider what they must demonstrate to be acceptable.
The structure of 2-4
2-4 organises its requirements into Functional Areas — coherent groupings of capabilities that a service provider must demonstrate. The principal Functional Areas typically referenced in the literature on the standard include the following.
flowchart LR
classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
classDef fa fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
SP[IACS Service Provider
Security Programme
per IEC 62443-2-4:2023]:::entry
SP --> F1[Solution staffing
vetted, trained, competent
personnel]:::fa
SP --> F2[Assurance
processes and audit
of service quality]:::fa
SP --> F3[Architecture
secure design and
integration practice]:::fa
SP --> F4[Wireless
secure handling of
wireless technologies]:::fa
SP --> F5[Safety Instrumented
Systems SIS
specific disciplines
for safety systems]:::fa
SP --> F6[Configuration management
baselines, change control,
version handling]:::fa
SP --> F7[Remote access
secure tooling and
access controls]:::fa
SP --> F8[Event management
logging, monitoring,
incident response]:::fa
SP --> F9[Account management
identities, privileges,
credentials]:::fa
SP --> F10[Malware protection
prevention, detection,
response]:::fa
SP --> F11[Patch management
delivery, testing,
application]:::fa
SP --> F12[Backup and restore
data and configuration
preservation]:::faThe exact count and labelling of Functional Areas varies slightly between editions of the standard and between different organisations' summaries of it, but the substantive content is broadly stable: a service provider must have demonstrable capability across the people, the process and the technical dimensions of every activity they perform on the asset owner's IACS.
Like 4-1 for OEMs, 2-4 incorporates a Maturity Level dimension. A service provider can be assessed at Maturity Level 1 (the practice exists but is ad hoc), Level 2 (documented and repeatable), Level 3 (consistently practised across the organisation with evidence), or Level 4 (continuously measured and improved). An asset owner specifying 2-4 compliance in their contract should specify the Maturity Level they require, just as they would specify an SL-T in 3-2.
What the service provider must objectively demonstrate
Demonstration here is well-defined because there is an established third-party certification scheme. The IECEE CB Scheme for industrial cybersecurity issues certificates against IEC 62443-2-4 through accredited certification bodies, and these certificates are mutually recognised across IECEE member economies. ISASecure has also operated relevant schemes in this space at various points. A service provider claiming 2-4 compliance should be able to produce a current third-party certificate naming the version of the standard, the Maturity Level achieved per Functional Area (or a single global ML where claimed), the certifying body, the issue date and the expiry date — typically three years with surveillance audits in between.
Beyond the certificate itself, the asset owner should expect the service provider to be able to produce the substantive evidence underlying the certificate: training records and competence assessments for the staff who will actually be deployed to the asset owner's site, documented procedures covering remote access, change control, incident handling, patch deployment and configuration management, evidence of internal audit and management review of those procedures, and a security incident handling capability with a track record. As with 4-1, the scope of the certificate matters as much as the headline rating: a 2-4 certificate covering a specific business unit, a specific geography or a specific service line tells you about that scope, not about the whole organisation. Reading the scope statement carefully is the single most important verification step.
Where a service provider does not hold a third-party 2-4 certificate but claims alignment with the standard, the asset owner should ask for the gap analysis that supports the claim, the corrective actions taken, and any internal audit evidence. Self-asserted compliance is not nothing — it can be a stepping stone — but it does not carry the same weight as a certified position, and the asset owner should make a clear decision about whether they accept it for the kind of work being contracted.
IEC 62443-2-5: the practical handbook
The final member of the Part 2 family, IEC 62443-2-5, provides implementation guidance for the asset owner. Where 2-1 says what an asset owner must have in their security programme, 2-5 advises on how to actually do it. It is a practical handbook rather than a requirements document, and its value lies in the worked examples, templates, organisational patterns and pragmatic advice it offers to asset owners who are at the start of building or modernising their security programme.
Because 2-5 is guidance, it does not generate a "compliance" question in the same way as 2-1 and 2-4. There is no certification for being "compliant with 2-5"; there is only the question of whether an asset owner has used it (and similar guidance from ISA, ENISA, NIST and sectoral bodies) to inform their implementation choices. For asset owners building their programme from scratch, 2-5 is a sensible starting point. For asset owners already further along, it is a useful sense-check.
I will not spend long on 2-5 because the substantive obligations all live in the documents above it. But for completeness, anyone working seriously with 2-1 should be aware that 2-5 exists and use it.
How 2-x fits with the rest of the standards
Pulling back at this point, here is how Part 2 sits alongside the standards covered in the previous articles. The diagram below shows the four principal parties and the standards that govern each of them, with the artefacts and certifications that flow between.
flowchart TB
classDef ao fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
classDef si fill:#1e8e3e,stroke:#0b3d20,color:#ffffff,stroke-width:1px;
classDef ps fill:#e65100,stroke:#3d1e00,color:#ffffff,stroke-width:1px;
classDef art fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
classDef art2 fill:#f0e4ff,stroke:#6f42c1,color:#3a1a6b,stroke-width:1px;
AO[Asset Owner]:::ao
SI[System Integrator
Service Provider]:::si
PS[Product Supplier OEM]:::ps
AO --> AO1[IEC 62443-2-1
Security Programme]:::art2
AO --> AO2[IEC 62443-3-2
Risk Assessment, CRS, SL-T]:::art
AO --> AO3[IEC 62443-2-3
Patch Programme
consumer side]:::art2
SI --> SI1[IEC 62443-2-4
Service Provider Programme]:::art2
SI --> SI2[IEC 62443-3-3
Delivered system
achieving SL-A]:::art
PS --> PS1[IEC 62443-4-1
SDL]:::art
PS --> PS2[IEC 62443-4-2
Components SL-C]:::art
PS --> PS3[IEC 62443-2-3
Patch Information
supplier side]:::art2
AO -.Optionally certified.- ACSSA[ISASecure ACSSA
or equivalent]
SI -.Certified to.- IECEE[IECEE CB Scheme
against 2-4]
PS -.Certified to.- ISASec[ISASecure SDLA + CSA]The picture is now complete. Every party has technical-side standards (the 3-x and 4-x parts covered in the previous articles) and management-side standards (the 2-x parts covered here). Every party has at least one route to third-party certification of their respective scope. And every interface between parties is governed by a defined artefact: the CRS flows from asset owner to integrator, the SL-C vectors and patch information flow from product supplier to integrator and asset owner, the delivered system with traceability flows from integrator to asset owner, and operational practices on the asset owner's site are governed by the asset owner's 2-1 programme with service providers regulated by 2-4.
A useful diagnostic when looking at a real industrial site is to walk through each interface in this picture and ask whether the corresponding artefact exists, whether it is current, and whether it is being acted upon. Where any interface lacks its defined artefact, that interface is a chain link with no link.
Common pitfalls and red flags
The most frequent pitfall in 2-1 work is treating it as a documentation exercise. An organisation writes the policies, files them in a document management system, and considers itself "compliant" with 2-1. The 2024 edition's maturity model is specifically designed to counter this trap — a policy that is written but unevenly applied scores at a low maturity level, and an external assessor working to the standard will find that out. The most useful question to ask of any 2-1 claim is "show me the audit trail of the policy in operation across all sites in the last twelve months", because that is what separates a Maturity Level 1 organisation from a Maturity Level 3 one.
A second pitfall is conflating 2-1 with ISO 27001. The two standards overlap but are not substitutes. ISO 27001 governs information security generically; 2-1 specifically addresses the IACS context, including the long lifetimes, legacy components, safety interactions and operational realities that ISO 27001 does not naturally cover. The 2024 edition of 2-1 deliberately defers to ISO 27001 for the generic ISMS layer, so an organisation with an ISMS should not duplicate that scaffolding, but they must add the IACS-specific layer that 2-1 requires. A claim of "we are ISO 27001 certified so we comply with 2-1" is not, in itself, accurate.
A third pitfall affects service providers and their asset owner customers: 2-4 certificates with narrow scope. A large engineering company may have a 2-4 certificate that covers, for instance, its automation business unit in one country, while the company's marketing materials suggest the whole organisation is certified. The scope statement on the certificate is the truth. When commissioning a service provider, the asset owner should ask for a copy of the certificate and read the scope to verify that the actual team to be deployed sits within it. Where the deployed team is from a sister organisation or a recently acquired company, the scope may not cover them.
A fourth pitfall is confusion between 4-1 and 2-4. A product supplier may hold an SDLA certificate against 4-1 (covering their product development process) but not a 2-4 certificate (which would cover their service-delivery practices). The two address different scopes and different activities, and one is not a substitute for the other. An organisation that both manufactures products and provides services on the asset owner's site needs both certificates.
A fifth pitfall is IT patch management practices applied unmodified to OT. The IT world has well-established patterns for patch deployment — typically rapid, automated, frequently applied — that translate poorly to industrial environments where patches must be tested in representative configurations, scheduled around production windows, and verified for impact on real-time and safety behaviours. An asset owner whose IACS patch programme is run by an IT department using IT patterns is at high risk of either applying patches without proper validation or, more commonly, applying nothing because the IT pattern cannot be made to fit. The discipline in TR 62443-2-3 exists precisely because OT patch management is its own discipline.
A sixth pitfall, and a particularly insidious one, is legacy systems being quietly excluded from the security programme. The 2024 edition of 2-1 explicitly acknowledges that legacy systems with no manufacturer support cannot meet all of the requirements directly and that compensating measures are the right response. The pitfall is when legacy systems get excluded from the inventory altogether and quietly age out of any active management. The right answer is to keep them in the programme with their compensating measures documented and reviewed, not to drop them off the asset register and hope.
A checklist for procurement, audit and self-assessment
The following can be used as a contract annex, an internal audit instrument, or a self-assessment tool. It is organised by the party demonstrating compliance.
For the asset owner's own 2-1 evidence pack
- A current, board-approved IACS cybersecurity policy referencing IEC 62443-2-1 (2024 edition) and identifying the SP elements covered.
- A documented IACS asset inventory covering all systems in scope, including legacy systems with their compensating measures explicitly noted.
- A risk register linked to the CRS produced under 62443-3-2 , with regular review cadence evidenced.
- Training records for staff with IACS responsibilities, including refresher cycles and competence assessments.
- Documented procedures for change control, incident response, patch management (per 62443-2-3), backup and restore, and access management — with evidence of operation.
- A current self-assessment or external assessment of maturity level per SP Element, with prioritised improvement actions.
- Internal audit reports covering each SP Element with evidence of corrective actions closed out.
- Management review records demonstrating senior leadership engagement at a defined cadence (typically annually).
- Where applicable, a current ISASecure ACSSA certificate or equivalent third-party assessment, with the scope statement reviewed against the actual operational footprint.
For the asset owner's evaluation of a service provider's 2-4 claim
- A current IECEE CB Scheme certificate (or equivalent) against IEC 62443-2-4:2023, with the issuing body, issue date and expiry date clearly stated.
- A scope statement on the certificate that explicitly covers the business unit, geography and service type relevant to the contract.
- A statement of the Maturity Level achieved per Functional Area (or a single global ML where claimed).
- Training and competence records for the specific personnel proposed for deployment to the asset owner's site.
- Documented procedures for the activities the service provider will perform on the asset owner's IACS, with linkage to the certified Functional Areas.
- Evidence of past performance on similar engagements with reference customers.
- A defined process for handling incidents that may arise during the engagement, with escalation paths into the asset owner's own incident management process under 2-1.
For the asset owner's evaluation of a product supplier's 2-3 contribution
- A documented vulnerability disclosure and advisory programme with a track record of issued advisories.
- A defined patch delivery format (ideally aligned with the VPatch or similar machine-readable format) and an indication of the typical lead time from vulnerability disclosure to patch availability.
- Release notes and testing guidance accompanying each patch, sufficient to support the asset owner's own testing.
- A defined support lifetime per product with a clear end-of-support date, beyond which the asset owner must rely on compensating measures.
- Where applicable, demonstrable linkage to the supplier's 4-1 SDLA certification (the underlying secure development process) and 4-2 CSA certification (the components in scope).
For the asset owner's evaluation of their own 2-3 patch programme
- A current asset inventory covering every component in the IACS, with vendor advisory channels subscribed for each.
- A documented triage process for incoming advisories with risk-based prioritisation.
- A test environment representative enough to validate patches before production deployment.
- A scheduled patch deployment cycle aligned with production maintenance windows, with verification of post-patch system behaviour.
- A documented approach for unpatchable components, with compensating controls implemented and reviewed.
- Metrics demonstrating the programme's actual performance — typical time-to-patch by criticality, percentage of advisories applied versus deferred with justification, and trends over time.
Where the 3-x and 4-x standards address the what of an IACS — what the system must do, what the components must support, what the design must achieve — the 2-x standards address the how of running it day-to-day, year after year, through the long operational life of an industrial plant. IEC 62443-2-1 governs the asset owner's security programme and is the cornerstone of the family on the operational side. IEC 62443-2-2 gives a way of rating how well that programme is actually working. IEC TR 62443-2-3 codifies the discipline of patch management for both asset owners and product suppliers. IEC 62443-2-4 governs the service providers who do work on the asset owner's site. IEC 62443-2-5 offers practical implementation guidance to support 2-1.
The single most important mental model to carry away from this article is that every party has both a technical-side obligation and a management-side obligation under IEC 62443, and that defensible cybersecurity depends on both being in place. A product supplier with a brilliant SDL (4-1) but a chaotic patch advisory practice (2-3) is half a supplier; a system integrator with excellent technical capability against 3-3 but no certified service programme under 2-4 is half an integrator; an asset owner with a careful 3-2 risk assessment but no operational security programme under 2-1 has built a building with no caretaker.
The chain of evidence across all of IEC 62443 only holds up when every party can demonstrate their piece — with current certificates where they exist, with substantive evidence underlying them, and with a culture of operational discipline that keeps the certificates meaningful between audits. The standards family gives you the framework. What it cannot give you is the willingness to actually run things that way.