What is IEC 62443? Zones, Conduits and Security Levels Explained

The series is organized by role: asset owners, system integrators and product suppliers each have their own requirements.

Security here results from a division of labor and is not a property of a single product.

The series itself is split the same way. The general parts 1-x define terms and concepts. Parts 2-x address asset owners (for example 2-1) and service providers such as integrators (for example 2-4), parts 3-x address the system (3-2 risk assessment and zoning, 3-3 system requirements and security levels), and parts 4-x address components and their manufacturers (4-1 secure development process, 4-2 technical requirements for components). When a requirement shows up in a tender or a specification, the first thing to check is which role it is actually addressed to. An asset owner cannot hand owner obligations to a supplier.

The more recent parts of the series carry the title Security for industrial automation and control systems; the series abbreviates that subject as IACS. The abbreviation also appears in the part titles: 2-1 names IACS asset owners, 2-4 IACS service providers, 4-2 IACS components.

This is the practical core of the standard.

A zone is a group of devices and systems with the same protection needs. All the controllers on one production line can form a zone. Office IT is another. A remote maintenance access point is a third.

A conduit is the controlled connection between two zones: the deliberately designed one, with defined protocols, defined directions and a point where traffic can be monitored. An arbitrary link between two networks is not yet a conduit.

The value lies in the cut. Breaking a plant down into zones means finding and naming every connection along the way, including the ones no document mentions anymore: a machine builder’s laptop, a remote maintenance link set up six years earlier, a data export over a network share that someone once created for a report. Those finds are what the exercise yields, and they make zoning worthwhile even when no certificate is the goal. You end up with a list of everything that talks to the plant, as complete as the search was thorough.

The standard grades protection needs by the type of attacker to defend against. The question is whom a plant has to be secure against, rather than how secure it is in general.

Strictly speaking, a security level is a vector across seven groups of requirements, the foundational requirements; “SL 3” is shorthand.

The target security level (SL-T) and the achieved security level (SL-A) apply to a zone or a conduit, not to a single device. For systems and components, the standard describes a capability level (SL-C): the level they can reach when properly integrated and configured, measured against the requirements the standard sets for systems and for components. That is why “What SL does your product have?” only asks about capability. The project has to establish which level the zone or conduit needs and what a component contributes to it.

This three-way split looks bureaucratic but has a practical use: an intermediate state can be documented, instead of a project being labeled “not secure yet” for two years.

Both are EU law, and neither is a standard. NIS2 does not bind a plant outside the EU directly; for a plant in the United States, the case for IEC 62443 is the one the rest of this article makes. NIS2 becomes relevant when you supply products or services into the EU or operate plants in an EU member state.

NIS2 is an EU directive. It requires certain operators to practice risk management and report incidents. It does not say how, and IEC 62443 is one of the answers to the how. For readers in Ireland and the other EU member states, that is the practical link: for the minimum requirements of their country’s NIS2 implementation, IEC 62443 offers a framework for describing them for an automation system. The reverse does not hold. A certificate alone does not make anyone NIS2-compliant, because the directive also requires organization and reporting channels.

In Germany, the directive has been law since December 6, 2025, through the NIS2 Implementation Act, and the obligations are set out in the BSI Act (BSIG). As an example of what a national implementation requires, the German act obliges what it calls particularly important and important entities to register with the Federal Office for Information Security (BSI) no later than three months after they first or again qualify as such (Section 33 BSIG). They report a significant security incident in three stages: an early initial report within 24 hours of becoming aware of it, a notification within 72 hours, and a final report no later than one month after that notification, or a progress report first if the incident is still ongoing (Section 32 BSIG). Management is required to implement the risk management measures and to oversee their implementation (Section 38 BSIG). In Ireland and the other member states, their own national implementation applies.

The Cyber Resilience Act (Regulation (EU) 2024/2847) is aimed mainly at manufacturers, not at operators. It requires products with digital elements to be developed and documented securely, and it requires the manufacturer to handle vulnerabilities during a defined support period, as a rule at least five years. These obligations apply from December 11, 2027.

The reporting obligation applies earlier: since September 11, 2026, a manufacturer has to report actively exploited vulnerabilities and severe security incidents affecting its product, with an early warning within 24 hours, a notification within 72 hours and a final report. The reports go to the designated CSIRT and to ENISA, and the manufacturer has to inform the affected users. This also covers products placed on the market before that date.

For an asset owner, this means: from December 11, 2027, some things that until then are only promised have to accompany every product, such as the single point of contact for vulnerabilities and the end date of the support period. The technical documentation itself is intended for the market surveillance authorities.

In the automation pyramid, security is not a level of its own. It is decided at the crossings: wherever data leaves a layer, that is where the conduits are. A controller sits inside its zone. A connection between OT and IT links zones, and it does so permanently. In security terms, it therefore deserves more attention than any single controller.

Middleware between OT and IT sits on such a conduit. It is the point where you decide which data flows in which direction, and which does not. Compared with many direct connections, there is one point to review instead of twenty, and that one point can log what it lets through. Twenty individual connections are hard to control even when each one is encrypted. Only a bundled crossing can be described completely.

A published user article describes such a bundling. It first appeared in German in the trade magazine Maschinenmarkt in April 2019 and is available on opc-router.com. At STIHL at the time, each assembly line communicated via an OPC Router with its own local SQL Server database, with central databases above them that combined the lines. “This architecture increases security and speeds up communication,” said Dominik Feil, who at the time was in charge of production on the IT side. “That’s why we made it as a standard a few years ago.” The article’s figures belong to its date: 16 installations in Germany, plus plants in the USA and China, as of the report. What it describes is a layering that grew out of operational needs, not a zone model according to the standard. It still answers the same question: which systems talk to each other, and through which point.

More on the plug-in whose security settings come up further down: OPC UA Client plug-in. How ISA-95 and the automation pyramid order the levels: What is ISA-95? · What is IT/OT integration?

A plant can pass an audit and still not be as protected as its paperwork says. Several causes lie in how the systems themselves are built: when identity is checked, where encryption ends and how a configuration travels.

The right-hand column of the table and the paragraphs on the OPC Router below it describe capabilities and settings documented in the OPC Router manual as of this article’s date and are not a conformity claim. Whether a zone or a conduit reaches its target security level depends on all the measures in it, not on a single component.

A revocation does not reach the running connection

A certificate is revoked centrally, or a user loses a role. The block is set, everything looks right in the management tool, and the existing connection keeps working as before. On a machine connection, that can last until the next restart.

The cause is a design decision: identity is checked when a session is established, not with every message. Checking every telegram would be unworkable for a connection that carries values every second, and a revocation list lookup for every value would make the cell dependent on the network. A revocation list therefore takes effect at the next handshake, and on a stable connection it may take a restart to trigger one. The test is simple: revoke a permission without restarting the service, then check whether the connection still delivers data. The result is your actual time to effect.

The delay can be shortened and put in numbers, but not eliminated. It is up to the asset owner to set it instead of leaving it open. A cyclic synchronization with a central certificate management system has an interval, and that interval tells you how long a revocation takes to reach the system. If the synchronization does not end the running connection, only a restart makes it effective for that connection; without a restart, the delay stays open. On the user side, set session timeouts where they exist; if they are off by default, they apply only once someone sets them. Where login runs through a Windows group, remove the permission at its source. The asset owner runs the test from the previous paragraph.

The OPC Router can retrieve certificates, trust lists and revocation lists cyclically from a Global Discovery Server (GDS) and synchronize them during operation. By default, the retrieval interval adapts to the GDS: it starts at 5 minutes and then follows the update interval the GDS reports for its trust lists; if the GDS reports none, it stays at 5 minutes. With “Automatically adjust interval to the GDS” switched off, a fixed “Update Interval” between 1 minute and 24 hours applies. Both settings sit in the “Automatic Retrieval” section of a GDS application, which you set up under the GDS entry of the certificates menu; the manual describes them on its page “Certificate Management via OPC UA GDS”. The feature requires an Enterprise license per installation as well as a GDS in the company. That turns the time until the new state reaches the OPC Router into a figure you can state. The manual names the limit in the same context: the synchronization does not affect plug-ins that are already running. Existing connections keep using the old state until the plug-in next starts, and when that happens depends on how the plug-in is operated.

The manual also puts a number on the user side. A role change takes effect only when the saved login token is renewed, and after a user is deleted, it can take up to 30 minutes until that user is logged out on all devices. For a shorter delay there is an inactivity timeout and a maximum session duration; both are off by default, are set globally through environment variables and can be fine-tuned per user. The right to revoke anything at all is governed by a permission matrix with three roles and 22 permissions, in which managing certificates, users and the license is reserved for the Admin role. The asset owner assigns the roles, and when migrating from an older version, existing users initially receive the Admin role.

The zone crossing can undercut a check the design was meant to provide

A crossing can be built through a reverse proxy in a demilitarized zone, rather than routing the connection straight through the zone boundary. Depending on the protocol and the proxy, the connection then only comes up if a check is left out that was meant to secure the identity of the other side.

A reverse proxy that terminates transport encryption also terminates the client’s transport identity. The server behind it sees either the proxy’s certificate or none at all. A check that matches the transport certificate against the application certificate can then no longer pair the two reliably. For the OPC UA server of the OPC Router this is documented: if it is reachable over HTTPS through a reverse proxy, the “Enable Mutual TLS” option has to be disabled, because the mapping there “is not always unambiguous”; otherwise the connection may fail despite a correct configuration. The audit then shows a check that must not be active behind the proxy and therefore has to be justified. Login with username and password remains mandatory; anonymous connections are not permitted over HTTPS.

The zoning, the location of the conduit and the classification of the segment behind the proxy remain the asset owner’s decisions. The asset owner also creates the firewall rules; the Windows setup does not configure any firewall exceptions and only points out the issue during installation. The common recommendation to terminate transport encryption in the reverse proxy rather than in the application appears in the manual as well, for network performance, and it adds: “This is especially true if the network traffic between the reverse proxy and OPC Router can be considered secure.” Whether the segment behind the proxy qualifies is for the asset owner to verify. If it cannot be verified, it has to be decided whether transport encryption may end in front of the OPC Router.

For the data path to the plant, the crossing needs no proxy as long as the OPC Router establishes the connection itself as a client, outbound to the port of the target system. A reverse proxy only comes into play in the data path where an external client needs to reach the OPC Router itself, for example the REST server, the built-in OPC UA server, the IDoc trigger for SAP and Web Management. Which ports have to be opened inbound therefore depends on the configured plug-ins. The full list is in a documented port catalog with default value, purpose and context, along with a list of the fixed outbound internet destinations that can go to the network team unchanged, and a list of ports the OPC Router does not use. For the HTTPS destinations among them, such as licensing, pronubes and the Solution Gallery, the OPC Router can use an outgoing proxy, set per service through HTTPS_PROXY. The manual names the limits in the same section. A proxy that requires authentication is not supported. On Windows, HTTPS_PROXY does not cover the revocation list lookups on port 80, which Windows makes itself through the system-wide WinHTTP setting. And HTTPS_PROXY applies to the whole process: internal destinations such as the redundancy partner or the endpoints of HTTP and REST plug-ins must be listed in NO_PROXY, otherwise those connections go through the proxy as well. Under TLS inspection, the manual names two options, and neither of them switches off certificate validation in the OPC Router: either an exception from inspection for the internet destinations, or the certificate of the inspection certificate authority in the local computer’s certificate store, “not just in the logged-in user’s certificate store”. The manual says nothing about TLS inspection on the data path itself.

The certificate carries a name, the plant speaks IP

An encrypted connection is set up and rejected, because the certificate carries only the host name while the server is addressed by its IP address.

A certificate is valid only for the names and addresses entered in it. A fixed IP address can be one of them, and OPC UA explicitly provides for this in server certificates. If the certificate carries only the host name, though, it no longer matches as soon as the server is addressed by its IP address. Automation addresses devices by fixed IP for good reasons: a cell network may have no name resolution, the address is in the wiring diagram, and a plant should not depend on a service run by IT. Both practices are right on their own terms. They fit together only if the certificate carries the address the server is reached by.

Once the check is switched off entirely, the plant runs in a state where even an expired or swapped certificate goes unnoticed until someone resets the switch, because there is no longer any alert. The configuration shows it, in connections that were set up once and never touched again.

The cause lies in the certificate, and no middleware issues certificates. There are three ways out, and all three belong to the asset owner: obtain a certificate that carries exactly the identity the server is actually addressed by, meaning the host name or the fixed IP address, entered as a Subject Alternative Name; provide name resolution in the cell network; or decide deliberately, and on record, which check to relax. The third way is defensible as long as it is documented. Add the side effect the manual names explicitly: with certificate validation disabled, “even incorrect server names or expired certificates will be accepted”.

The OPC Router’s OPC UA client splits validation across several switches. Documented are “Certificate Validation”, which checks the validity of the server certificate (on by default), “Validate Server Application URI”, which checks the server’s application URI against the configured one (on by default), and the choice of “Trusted Certificates”. The option “All (untrusted)” widens the circle of trust and leaves the validity check in place; in the manual’s words: “The server certificate must still be valid.” For the address, the manual states: when using certificates, the endpoint must be addressed exactly as specified in the certificate. What to set up, then, is a server certificate issued for the name or the fixed IP address the OPC Router connects to, and exactly that endpoint in the plug-in. The switches are in the OPC UA Client plug-in on the “Security” tab, the endpoint on the “Connection” tab.

The state can also be read back. Certificate management shows the subject, DNS names, issue and expiry date, serial number, fingerprint and source for each certificate. Because the configuration is stored as YAML in an internally managed Git repository that records who changed what and when, a disabled checkbox shows up when two versions are compared. For an audit, this documents the time of the change along with the current state.

The highest security level is the highest the other side offers

The project sets the option that asks for the strongest available security. The connection comes up, the documentation says “encrypted”, and the matter is considered closed. What was actually negotiated is recorded nowhere.

A client can only choose from what the server offers. If an older controller offers only an unsecured endpoint, the best of what is offered is that one. The same idea sits behind the security level of a zone: the level is set at the weaker end. The result can therefore only be read from the negotiated endpoint; the client’s configuration shows the intent.

It is up to the asset owner to check which endpoints the other side actually offers before the setting goes into the documentation as evidence. That includes the documented condition for the connection test: it succeeds only if the same security level is set on both sides and the client and server certificates to be exchanged are mutually classified as trusted. Classifying them on the server side is not something middleware can take over.

The OPC Router’s OPC UA client has the switch “Use Highest Security Level”. According to the manual, it enforces the most secure security configuration the server offers when establishing a connection and rejects weaker endpoints if a more secure alternative is available. While it is active, the field for the security mode is locked. What comes out of it still depends on the other side. The manual does not state the default of this switch: for “Certificate Validation” and “Validate Server Application URI”, the default is noted explicitly; for this switch, it is not. Only your own installation shows which setting applies.

The plant is clean, the export file is not

The credentials are stored properly, the zones are cut, the crossing is described. Then the configuration is exported: for a backup, for support, for a second plant. The file this creates appears in no network diagram and in no zone assessment.

A configuration has to be portable, or it can be neither backed up nor duplicated. Portable means that everything needed is in one file. A secret that has to travel along leaves the protection the installation gave it. That is the flip side of portability, and it applies to every system whose export takes secrets along. It becomes visible only when something happens: the find comes later, from a file share or a ticket attachment.

It is up to the asset owner to assign a passphrase during export whenever the file leaves the computer, is shared or is stored. According to the permission matrix, the Editor role may also export projects, and the passphrase is set by whoever is exporting. After that, check where the exports of the past years ended up. Take care when cleaning up: the OPC Router does not check whether a secret is still in use, and a deleted secret that is still referenced leads to runtime errors.

In the OPC Router, the password fields in the configuration dialogs do not accept plain text but reference a secret; the configuration holds only the key, not the value. There are two stores. One keeps the values encrypted and separate from the rest of the configuration; the other reads them from the environment variables of the system or container and is always read-only, so the value never enters the configuration in the first place. Two side effects matter for security: secret values are never part of a project version, only the key is versioned, so a rollback does not change a password. And the file with the internal secrets is removed from the diagnostic package compiled for a support request. The manual names the exception itself: without a passphrase, the secret values appear in plain text in the export file. All of this is managed under Secrets in the menu.

These questions fit into any tender or supplier review and cost only the time it takes to ask them:

1. How are credentials stored? Are passwords kept in plain text in a configuration file, or does the configuration reference a protected store?
2. Which roles exist, and what may they do? Software with exactly one administrator account is hard to justify in a zone with protection needs.
3. Which ports are opened, what for, and can they be restricted? A supplier should be able to hand over a complete port list without looking it up.
4. How are certificates rolled out and renewed? Manually on each machine, or managed centrally. Across many plants, that decides whether encryption is kept up in operation.
5. How quickly does a revoked permission take effect? Immediately, or only when a session expires. Either can be defensible, but it has to be known.
6. How are vulnerabilities reported, and within what time frame? For products sold in the EU, this has been more than a courtesy since September 11, 2026: the Cyber Resilience Act sets manufacturers reporting deadlines toward the authorities and requires them to inform affected users.

Besides the content, it is telling whether the supplier has the answers at hand. That makes the questions a good pre-screening tool, before a plant is even put out to tender.

For the OPC Router, the answers to questions 1 to 5 are further up, under the problems: credentials and export, roles and permission matrix, the port catalog, certificates via a Global Discovery Server, and how quickly a revoked permission takes effect. Each one appears there with its limit and refers to the manual as of this article’s date, not to earlier releases of the OPC Router. The sixth, the reporting time frame for vulnerabilities, is not a product property. For actively exploited vulnerabilities in products sold in the EU, the deadlines toward the authorities have been set by the Cyber Resilience Act since September 11, 2026. Anything a supplier commits to beyond that belongs in its answer to the question, not in an article on the basics.

Last updated: September 22, 2026. Statements about the OPC Router refer to its documentation as of this date.