Can truly legacy PLCs ever be compliant with IEC 62443?

In practice, a truly legacy PLC is very unlikely to be individually compliant with IEC 62443, because the standard assumes security capabilities that these devices generally do not have. However, it can still be part of an IEC 62443-aligned system if it is appropriately segmented, monitored, and controlled, and if the residual risk is explicitly assessed and accepted.

What IEC 62443 actually applies to

IEC 62443 is a family of standards that covers:

• System-level requirements for industrial automation and control systems (IACS)
• Component-level requirements for products such as PLCs, RTUs, and network devices
• Security lifecycle and processes (for asset owners and integrators)

When people ask whether a PLC is “compliant,” they are usually mixing two ideas:

• Product conformance: The PLC itself implements the relevant technical security requirements for a target security level (e.g., 62443-4-2).
• System compliance/alignment: The overall IACS architecture, including compensating controls, meets the intent of 62443-3-3 for identified zones and conduits.

Legacy PLCs almost always fail the product conformance test if evaluated directly against 62443-4-2. But they can still exist inside a system that is engineered to meet 62443-3-3 objectives as far as reasonably practicable.

Why legacy PLCs usually cannot be directly compliant

Typical limitations of older PLCs include:

• No native user authentication or only a shared password
• No role-based access control or fine-grained authorization
• No encryption for engineering, HMI, or SCADA traffic
• No secure boot, firmware signing, or integrity protection
• No event logging suitable for modern security monitoring
• Vendor no longer providing security patches or firmware updates

Many IEC 62443 technical requirements assume these capabilities are available. If the PLC simply cannot implement them, you cannot truthfully claim that the device by itself meets the relevant component standard.

In regulated environments, there is also the added constraint that changing firmware or replacing hardware triggers validation, requalification, and documentation updates. This often locks in older devices for long periods, even when they are security-weak.

What “compliance” usually looks like in brownfield plants

For most aerospace, pharma, and other regulated plants with long-lived assets, IEC 62443 alignment is achieved at the system level, not by upgrading every PLC to a modern, certifiable platform. Common patterns include:

• Network segmentation and zoning: Placing legacy PLCs in tightly controlled security zones with minimal and well-defined conduits.
• Compensating controls: Using firewalls, data diodes, jump servers, VPNs, and application proxies to enforce authentication, access control, and logging around the PLC.
• Configuration hardening: Disabling unused ports/protocols, read-only configurations where possible, and removing or locking down programming access in production.
• Restricted engineering workflows: Strict procedures for who can connect to the PLC, from where, and under what change control, often with dual control or approvals.
• Monitoring and detection: Network-based intrusion detection, baseline traffic profiles, and alerting for unexpected changes or communications.
• Physical security: Locked panels, controlled access to cabinets, and managed use of removable media to compensate for weak logical security.

Under IEC 62443, this is acceptable only if:

• The risk is formally assessed (e.g., SL-T vs SL-A gap is documented).
• Compensating controls are designed, justified, and validated.
• Residual risk is explicitly accepted by the appropriate risk owner.
• Controls and assumptions are captured in configuration, design, and change records.

When the honest answer is simply “no”

There are situations where even with compensating controls, the correct answer is that the legacy PLC cannot be made acceptably aligned with the intended IEC 62443 security level for its zone:

• If the PLC is directly exposed to routable networks and cannot be adequately isolated without breaking required functionality.
• If there is no practical way to control or authenticate programming access.
• If the asset’s criticality (e.g., safety impact, product quality impact) demands a higher security level than compensating controls can realistically provide.

In these cases, you may need to:

• Lower the target security level for the zone and explicitly document the risk and rationale, or
• Plan a controlled migration to a more secure PLC, with appropriate validation and downtime planning.

In regulated environments, any migration usually involves:

• Change control and impact assessment
• Revalidation or requalification of equipment and processes
• Retesting of critical functions and failure modes
• Traceability updates to design, maintenance, and cybersecurity documentation

These burdens are why many sites choose to live with legacy PLCs under strong compensating controls rather than pursue immediate replacement.

How to approach legacy PLCs under IEC 62443

A pragmatic approach is usually:

1. Inventory and classify
   Identify all legacy PLCs, firmware levels, communication paths, and process criticality. Treat missing information as a risk item.
2. Perform a threat and risk assessment
   Use IEC 62443 risk methodologies to define target security levels for zones and identify where legacy PLCs fall short.
3. Design compensating controls
   Layer network, system, and procedural controls to address the most impactful gaps. Validate that they work and are maintainable with existing staff and tools.
4. Document residual risk and justification
   Capture assumptions, limitations, and risk acceptance decisions in your cybersecurity, quality, and engineering documentation.
5. Plan gradual modernization
   Where risk or obsolescence is unacceptable, plan staged replacements aligned with outages, validation cycles, and capital planning.

Trying to “rip and replace” all legacy PLCs at once rarely succeeds in regulated, long-lifecycle environments, due to downtime constraints, integration complexity, qualification burden, and the risk of introducing new, insufficiently understood failure modes.

Bottom line

Truly legacy PLCs are almost never directly compliant with IEC 62443 as standalone products. In most brownfield, regulated plants, the realistic goal is to:

• Use zoning, compensating controls, and strict procedures to bring the system into reasonable alignment with IEC 62443 expectations.
• Be transparent about gaps, residual risks, and risk acceptance decisions.
• Prioritize and plan replacements where the risk or obsolescence cannot be managed by architecture and process alone.

Any claim of full IEC 62443 compliance for legacy PLCs without this level of analysis, documentation, and control is likely misleading and will not stand up to a rigorous technical or regulatory review.