What are common pitfalls when retrofitting legacy products to meet IEC 62443 expectations?

Retrofitting legacy industrial products to align with IEC 62443 expectations is usually constrained more by architecture, lifecycle, and vendor lock-in than by individual technical controls. Many initiatives stall or deliver little real risk reduction because of a few recurring pitfalls.

Pitfall 1: Treating IEC 62443 as a checklist, not a system risk exercise

A common mistake is to approach IEC 62443 as a control checklist instead of a risk- and zone-based architecture framework.

• Focusing only on adding firewalls, hardening guides, or passwords without revisiting zones, conduits, and trust boundaries.
• Ignoring the distinction between system-level requirements (e.g., 62443-3-3) and component/product-level capabilities (e.g., 62443-4-2).
• Assuming that if each device looks secure in isolation, the overall system risk is acceptable.

This leads to fragmented controls that are hard to sustain and that may not meaningfully reduce cyber-physical risk.

Pitfall 2: Skipping rigorous asset and dependency discovery

Legacy products are rarely isolated. In brownfield plants, they rely on undocumented dependencies, fragile integrations, and vendor-specific tooling.

• Incomplete inventories of fielded versions, firmware levels, protocols, and communication paths.
• Unknown dependencies on legacy services (e.g., SMBv1, insecure vendor remote access, hardcoded IPs).
• Hidden single points of failure, such as an obsolete engineering workstation or dongle-based licenses.

Without accurate asset and dependency data, retrofit changes can break operations, invalidate previous validation, or create new safety and availability risks.

Pitfall 3: Assuming full IEC 62443 compliance is achievable for all legacy products

Many legacy controllers, drives, and embedded products simply cannot meet the expectations of modern IEC 62443 levels without redesign.

• No hardware root of trust, secure boot, or modern cryptography support.
• Inability to segment functions or enforce least privilege.
• Limited CPU/memory to run secure protocols or logging without impacting cycle time.
• No vendor support for security patches or signed firmware.

Trying to force full alignment with higher security levels can result in extended downtime, unstable systems, or unsupported configurations. In many regulated environments the realistic strategy is to strengthen compensating controls around the product (network zoning, monitoring, procedures) rather than inside it.

Pitfall 4: Underestimating vendor and OEM constraints

In regulated, long-lifecycle industries, OEM support and validated configurations matter at least as much as technical capability.

• Adding third-party security agents, wrappers, or firmware that void OEM support.
• Deploying patches, protocol changes, or encryption methods not validated or qualified by the vendor.
• Relying on contracts or SLAs that were never updated to cover security maintenance and vulnerability handling.

Even if a control is technically feasible, losing OEM support or deviating from qualified configurations can create bigger operational and regulatory risks than the original vulnerability.

Pitfall 5: Ignoring validation, documentation, and change control

Retrofitting security into validated systems is not just a technical task. It affects qualification status, procedures, and evidence trails.

• Making security changes (e.g., hardening, patching, segmentation) without impact assessments on process validation and product quality.
• Weak traceability from requirements to implementation to testing, making it hard to defend configurations in audits.
• Inadequate regression testing of critical functions, including failure modes and recovery procedures.

IEC 62443 alignment efforts that do not integrate with existing change control, configuration management, and qualification practices often stall or must be undone when audits or deviations appear.

Pitfall 6: Over-reliance on network perimeter controls

Adding a firewall or VPN around an insecure product helps, but it is not a full solution.

• Assuming a perimeter firewall compensates for weak authentication, missing logging, or insecure local access.
• Failing to define zones and conduits with clear policies, monitoring, and ownership.
• Not accounting for internal threat vectors such as maintenance laptops, engineering workstations, or removable media.

Commonly, a strong network wrapper hides ongoing exposure from flat internal networks, shared accounts, or unmonitored engineering tools that remain directly connected to legacy devices.

Pitfall 7: Neglecting operational usability and support implications

Security changes that hinder maintenance or troubleshooting tend to get bypassed informally.

• Complex authentication flows that encourage password sharing or static “maintenance” accounts.
• Access restrictions that make vendor support difficult, driving people to create undocumented backdoors.
• Controls that extend outage durations because recovery and failover procedures are untested or unclear.

IEC 62443 expectations include secure operation over time, not just an initial hardened configuration. If operators and technicians cannot practically support the retrofitted product, controls will degrade or be removed.

Pitfall 8: Not addressing credentials and identity properly

Legacy products often rely on shared accounts, hardcoded passwords, or local user stores.

• Leaving default or vendor accounts in place because they are tied to support tools.
• Not integrating with centralized identity where feasible, or lacking a defined alternative (e.g., procedural controls) where it is not.
• No process for credential rotation, revoking access for departed staff, or auditing privileged actions.

IEC 62443 expectations around identification, authentication, and accountability are hard to satisfy on legacy hardware and software without a clear access control and logging strategy.

Pitfall 9: Forgetting monitoring, logging, and incident response

Security retrofits often prioritize preventive controls and neglect detection and response.

• No practical plan for collecting, storing, and reviewing logs from legacy devices and surrounding infrastructure.
• Using network monitoring tools that are too intrusive, causing performance or stability issues.
• Incident response playbooks that are generic IT documents and do not reflect the constraints of 24/7 production or validated processes.

In many cases, realistic improvements are limited to network-level monitoring, engineering workstation logging, and strong procedural responses due to device constraints. Treating this as a design choice rather than a defect helps align expectations with what is achievable.

Pitfall 10: Assuming wholesale replacement is the only path

When retrofitting looks difficult, there is often a push to replace legacy products entirely with “IEC 62443-compliant” alternatives. In regulated, long-lifecycle environments this frequently fails or stalls.

• High qualification and validation burden for new equipment and software.
• Downtime and migration risks that are unacceptable for critical lines or assets.
• Integration complexity with existing MES/ERP/QMS and vendor-specific tooling.
• Long coexistence periods where legacy and new systems must both operate, increasing overall risk and support load.

For many plants, a phased approach that combines targeted retrofit controls, network zoning, and selective replacement during planned lifecycle events is more realistic than a full, fast cutover.

Practical ways to avoid these pitfalls

To improve the odds of a useful and sustainable retrofit:

• Start with a zone and conduit model, aligned to IEC 62443, that reflects your actual brownfield topology.
• Perform structured asset and dependency discovery before selecting controls.
• Classify legacy products by what is realistically modifiable and where compensating controls are required.
• Align changes with existing change control, validation, and documentation practices from the outset.
• Engage OEMs early and document supported, qualified configurations.
• Design for ongoing operation: clear procedures for access, maintenance, incident handling, and recovery.

Retrofitting legacy products towards IEC 62443 expectations is typically an exercise in compromise and layering. A candid view of technical limits, validation impacts, and vendor constraints helps avoid overpromising on “compliance” and instead focus on tangible risk reduction.