IEC 62443-2-4 focuses on what service providers must do to support secure industrial automation and control systems. You cannot “ensure” compliance in an absolute sense, but you can significantly increase conformance and reduce risk by making 62443-2-4 a structured part of supplier management, contracts, and technical controls.
1. Make IEC 62443-2-4 explicit in contracts and SOWs
Service providers rarely align with 62443-2-4 unless it is concretely required. Start by making expectations visible and binding:
- Reference IEC 62443-2-4 in master service agreements and statements of work, specifying which clauses or capability levels apply to your use case.
- Define scope: which sites, networks, systems, and environments (e.g., production, test, development) are in scope.
- State required deliverables: security plans, hardening guides, user management procedures, incident support, and documentation that map to 62443-2-4 requirements.
- Include right-to-audit or right-to-request-evidence clauses, within reasonable limits for confidentiality and export controls.
Avoid vague language like “provider follows industry best practices.” Tie expectations to specific, testable outputs and behaviors.
2. Integrate 62443-2-4 into supplier qualification
Before the first purchase order, assess the provider’s maturity against 62443-2-4, similar to any quality or safety qualification:
- Use a structured questionnaire mapped to 62443-2-4 requirements (e.g., account management, patching, remote access, backups, incident support).
- Ask for existing certifications or third-party assessments only as supporting evidence, not as a guarantee of suitability.
- Review their documented processes for secure configuration, remote access, and change control in operational technology (OT) environments.
- Classify providers by criticality (e.g., can they impact safety, product quality, or regulatory data) and scale your depth of assessment accordingly.
In highly regulated or safety-critical environments, you may need on-site or virtual technical reviews involving OT, IT security, and quality representatives.
3. Define clear responsibilities and boundaries
IEC 62443 assumes responsibility is shared between asset owners and service providers. Gaps often occur where boundaries are unclear. Clarify in writing:
- Who owns network zoning and segmentation, firewalls, and remote access gateways.
- Who creates, approves, and removes user accounts on OT systems and remote access tools.
- Who applies OS and application patches, and under what approval workflow.
- Who maintains backup and recovery procedures, and how often restore tests occur.
- Who leads incident response for cybersecurity events affecting their scope, and how this integrates with your incident and deviation processes.
Responsibility matrices (e.g., RACI charts) tied to 62443-2-4 control families are often the most practical way to avoid assumptions.
4. Align with existing brownfield and validated systems
In brownfield environments with legacy MES, DCS, PLCs, and validated systems, you cannot simply “upgrade to compliant” services without disruption. When applying 62443-2-4 expectations:
- Identify systems where changes trigger revalidation or requalification, and require service providers to follow your change control and validation processes.
- Prohibit unilateral provider changes to configurations, firmware, or network connections without documented change requests and impact assessments.
- Require versioned configuration baselines and traceability for any changes they implement.
- Favor additive protections (e.g., secure remote access gateways, jump hosts, monitoring) over wholesale replacement of legacy components, which often fails due to downtime, integration complexity, and regulatory burden.
Where providers propose major technology changes, insist on a structured risk and impact assessment that includes qualification effort, downtime windows, and rollback plans.
5. Control and monitor remote access
Remote access is one of the highest-risk areas governed by 62443-2-4 and often heavily used by vendors for troubleshooting and upgrades. At minimum:
- Use centrally managed, approved remote access solutions rather than ad hoc VPNs or vendor tools installed directly on OT assets.
- Require strong authentication (e.g., MFA) and unique identities for each individual, not shared vendor accounts.
- Limit access by time, system, and role; avoid persistent always-on vendor connections.
- Monitor and log remote sessions at the network and application layer where feasible, and retain those logs per your retention policy.
- Include remote access use in periodic reviews with the provider and in your internal cybersecurity governance.
Where legacy constraints limit technical controls, compensate with stricter procedural controls, escorted sessions, and additional logging at adjacent layers (e.g., jump hosts or firewalls).
6. Require and review evidence, not just policies
To move from trust to verification, tie 62443-2-4 requirements to concrete artifacts and periodic reviews:
- Define what evidence you expect: configuration hardening checklists, user lists, change records, incident reports, and test results for backups or failover.
- Ask for samples of tickets and change records (appropriately redacted) that show how they handle work in regulated plants.
- Check that their procedures are actually followed on your systems, not just documented generically.
- Include provider-related controls and evidence in your internal audits and pre-audit readiness activities, but avoid implying that this guarantees any particular audit outcome.
Be explicit that missing or weak evidence will affect continued use and future sourcing decisions.
7. Integrate providers into your change control and risk management
Service providers frequently act outside plant change processes unless you enforce alignment. To match 62443-2-4:
- Require that all provider changes go through your formal change control, including risk assessment, testing, and approvals where applicable.
- Mandate pre-deployment testing on non-production or representative testbeds for impactful changes (patches, firmware, major configuration shifts).
- Ensure cyber-related risks and mitigations are recorded in your risk registers, not just in vendor documents.
- Document rollback plans for any change that can disrupt production, quality, or safety-related controls.
In validated or qualified environments, align provider activities with your validation documentation and release processes to preserve traceability.
8. Use tiered oversight based on criticality
Not every service provider needs the same rigor. Define tiers such as:
- High criticality: Can affect safety functions, product quality, batch records, regulatory data, or core OT networks. These should have full 62443-2-4 alignment, detailed contracts, and regular reviews.
- Medium criticality: Indirect OT impact or limited-scope remote access. Require essential controls (remote access, user management, incident reporting) and periodic spot checks.
- Low criticality: No network access to OT, no impact on regulated data. Apply baseline corporate security and supplier expectations.
This avoids overburdening low-risk providers while still maintaining strong control where it matters most.
9. Plan for lifecycle, exit, and personnel changes
IEC 62443-2-4 expectations need to hold over long equipment lifecycles and changing vendor relationships:
- Include offboarding provisions: how accounts are removed, data returned or destroyed, and access revoked at contract end or scope change.
- Require timely notification when their key personnel with access to your environment change roles or leave.
- Plan for what happens if the provider discontinues a service or tool, to avoid unmanageable technical debt or stranded unsupported systems.
- Review alignment with 62443-2-4 at agreed intervals (e.g., annually) to account for technology and threat changes.
Lifecycle planning is especially important where providers manage components that would be costly to requalify or replace.
10. Be explicit about limits and shared responsibility
No combination of clauses or controls can fully guarantee that a provider will always follow IEC 62443-2-4 in practice. Factors like site-specific configurations, integration quality, and internal process maturity will strongly influence actual risk reduction. You remain responsible for:
- Defining acceptable risk in the context of your operations and regulatory environment.
- Maintaining network architecture, monitoring, and incident response that can detect and respond to provider missteps.
- Ensuring internal teams do not bypass agreed processes for the sake of short-term convenience.
Treat IEC 62443-2-4 as a shared framework: you set clear expectations, the provider demonstrates capability and evidence, and you validate and monitor that behavior over time.
