IEC 62443-4-1 and 4-2.
Process is not the same as product.

A secure development process starts before writing code. Which risks are relevant? Which security requirements follow from them? How are design and implementation tested? And how are vulnerabilities and updates handled after delivery?

The public IEC explanation mentions, among other things, security requirements, secure design and implementation, verification and validation, defect and patch management, and the end of the product lifecycle. The scope focuses on the developer and maintainer, not the user or integrator. Read the explanation of IEC 62443-4-1.

IEC 62443-4-2 groups requirements around seven foundations: identification and authentication, usage rights, system integrity, confidentiality, restricted data flow, timely response to events, and resource availability. It concerns component capabilities; a required or actually achieved security level for the entire installation does not automatically follow. Read the explanation of IEC 62443-4-2.

For a remote access project, you can translate this into your own assessment list:

• How are users and devices recognized, and how is access revoked?
• Which rights and network connections can you actually limit?
• How are configurations, software, and communication protected?
• Which events are visible and useful during investigation?
• How does the component behave during failure, overload, or an update?

These questions help the technical dialogue. They are not a full representation of the standard and not a conformity test.

IEC 62443 also looks at the system and the surrounding organization. Part 3-2 covers risk assessment and the division into zones and communication links between zones, the so-called conduits. Part 3-3 covers technical requirements at the system level. A router is therefore one part of a broader setup. View the overview of the IEC 62443 series.

For example, suppose a supplier only needs to maintain a controller on one production line. Then account rights, the remote connection, firewall rules, and the local application must fit that scope. A correctly authenticated user with an overly broad network route remains a risk.

Ask for the exact part of the standard, the assessed scope, the product, and the software version. Check whether the claim concerns a development process, component, or system, and which boundary conditions apply. A certificate for 4-1 does not automatically prove that every product is certified under 4-2.

A component assessment also does not simply provide a declaration for your entire installation. This page does not claim specific IEC certification or security levels for Remote products. Product claims must be supported by current, product-specific documentation.