With the NIS2 directive coming into effect, many industrial organizations are facing a fundamental challenge. The law tells them WHAT they must accomplish - manage risk, protect infrastructure, report incidents. However, it rarely specifies HOW exactly they are to do this in the complex and unique world of operational technology (OT). This gap between legal requirement and technical implementation is a source of great uncertainty and frustration.
Fortunately, we don’t have to reinvent the wheel. The answer to the “how?” question is the international, multi-part IEC 62443, which has become the de facto global standard and set of best practices for cyber security of Industrial Automation and Control Systems (IACS). It is the one referenced by other regulations, and it is the one that provides engineers, architects and managers with a comprehensive, battle-tested methodology.
Think of NIS2 as a law that mandates the construction of a safe home. IEC 62443, on the other hand, is a detailed manual of the art of construction that shows how to design foundations, how to erect walls and how to construct a roof to make a house realistically hurricane resistant. Understanding the key concepts of this standard is essential today to building any mature and legally compliant OT safety program.
Shortcuts
- If NIS2 tells you “what” to do, IEC 62443 shows you “how.” Why is it so important?
- What exactly is IEC 62443 and who does it apply to?
- What are “zones” (zones) and how do they help you logically organize your factory?
- What are “conduits” (ducts) and why is it as important to secure them as it is to protect the zones themselves?
- How do you practically define zones and channels for a typical production line?
- What are Security Levels and how do they help in risk assessment?
- Security Levels (Security Levels) according to IEC 62443
- From SL1 to SL4: What do the levels mean and what type of attacker do they protect against?
- Based on the risk analysis, how do you determine the target security level (SL-T) for each zone?
- How do you verify that your current safeguards reach the required level (SL-A)?
- What does it mean to certify a product to a given safety level (SL-C) and how to use this in the purchasing process?
- How do the concepts of zones, channels and security levels work together in practice?
- What is a Cyber Security Management System (CSMS) according to IEC 62443?
- Why is IEC 62443 not just a technical standard, but a complete OT safety management philosophy?
- How can nFlo help you practically implement the IEC 62443 family of standards in your organization?
If NIS2 tells you “what” to do, IEC 62443 shows you “how.” Why is it so important?
The importance of IEC 62443 stems from the fact that it was created from the ground up to address the unique challenges of industrial environments. It is not an adaptation of an IT standard, but a comprehensive framework that addresses OT priorities such as physical security (safety), reliability and business continuity. That’s why its recommendations are so practical and relevant.
The standard provides a common language and consistent methodology for all participants in the industrial ecosystem - from factory owners (Asset Owners) to system integrators to equipment manufacturers. As a result, all parties can clearly communicate their security requirements and expectations.
In the context of NIS2, IEC 62443 becomes an extremely valuable tool for demonstrating due diligence. By implementing safeguards based on an internationally recognized standard, an organization can, in the event of an audit or incident, prove that its actions were not haphazard, but were based on best, globally accepted practices. This is a powerful argument when talking to regulators.
📚 Read the complete guide: NIS2: Kompletny przewodnik po dyrektywie NIS2 - obowiązki, kary, terminy
What exactly is IEC 62443 and who does it apply to?
IEC 62443 is actually a whole family of standards, rather than a single document. It consists of more than a dozen parts, grouped into four categories that together cover all aspects of IACS security: from general concepts to policies and procedures to technical requirements for systems and components.
The standard is designed to engage three key stakeholder groups in the supply chain. The first group is component manufacturers (Vendors), for whom the standard defines requirements for a secure product development cycle. The second group is system integrators (System Integrators), who receive guidance on how to safely design and implement control systems at the end customer.
The third, and from the perspective of this article series, the most important group is the owners and operators of industrial installations (Asset Owners). For them, the standard provides a complete framework for building and maintaining an internal Cyber Security Management System (CSMS), assessing risks and verifying that implemented safeguards are adequate for identified threats.
What are “zones” (zones) and how do they help you logically organize your factory?
One of the fundamental concepts introduced by IEC 62443 is the division of the entire IACS infrastructure into zones (zones). A zone is a logical collection of resources (devices, applications, systems) that share common security requirements. In other words, we group together those elements that need to be protected in a similar way because they perform a similar function or are exposed to similar risks.
At its core, the concept of zones is a practical and formalized implementation of the segmentation philosophy we know from the Purdue Model. Instead of speaking in general terms about “Level 2,” IEC 62443 forces us to think more precisely. For example, we might define a “Production Line Zone A,” which would include all PLCs, HMIs and robots serving that particular line. Another example might be a “Safety Systems Zone,” grouping together all the controllers responsible for emergency stop procedures.
Grouping resources into zones helps bring order to a complex network architecture. This is the first step toward moving away from an unmanageable, “flat” network to a structured, logically partitioned environment. Inside a single zone, communication can be relatively free, but any attempt to cross a zone boundary will be subject to strict controls.
What are “conduits” (ducts) and why is it as important to secure them as it is to protect the zones themselves?
Now that we have defined zones, or our “safe islands,” we must somehow enable them to communicate. This role, in IEC 62443 terminology, is played by channels (conduits). A conduit is simply a communication path that connects two or more zones to each other. The important thing is that a conduit does not group end devices, but the network connections themselves.
All resources within a single channel must have the same security requirements. For example, all communication between “Production Line Zone A” and “SCADA Server Zone” can be defined as a single channel. It is at the channel level that we will define and implement control mechanisms to secure the flow of information between zones.
Securing the channels is absolutely key. They are the boundaries at which we will enforce our security policies. This is where firewalls, IDS/IPS systems or data diodes are installed. IEC 62443 teaches us that it is not enough to secure the devices themselves. It is equally important to secure the paths that lead to them.
How do you practically define zones and channels for a typical production line?
Let’s translate this theory into a practical example. Imagine a typical automated production line in a factory. The process of defining zones and channels could look as follows. First, we identify logical groups of resources. All PLCs, robots and HMIs directly on the line form the “Production Zone of Line A.”
SCADA servers and historical databases that supervise the operation of several lines form a separate “Production Supervision Zone.” Engineering stations, used for programming controllers, make up the “Service Zone.” In turn, the office network in which ERP systems run is ** the “IT Zone**. ”
Next, we define the channels. Communication between controllers and SCADA servers is ** the “Process Data Channel**. ” The connection between engineering stations and controllers is ** the “Service Channel.”** And the connection between the Supervision Zone and the IT Zone (e.g., to transfer data to ERP) is the “Business Channel,” which must obligatorily pass through the DMZ. This decomposition makes it possible to precisely define the security requirements for each element of the architecture.
What are Security Levels and how do they help in risk assessment?
Once we have our map of zones and channels, the question becomes, “How much should we protect each of them?” Here IEC 62443 introduces an extremely useful tool, Security Levels (SL). This is a scale from 0 to 4 that allows us to classify the security requirements for each zone and the ability of systems and components to meet those requirements.
Security Levels are not an abstract measure. They are directly linked to a risk assessment and define what type of attacker a system should be able to defend against. This is an extremely pragmatic approach that allows the level of security investment to be matched to the real threat.
Instead of trying to secure everything “to the maximum,” the standard encourages risk-based thinking. A zone controlling a non-critical auxiliary process may require a lower level of safety than a zone managing a major chemical reactor. Safety Levels give us a consistent and objective scale to express these varying requirements.
Security Levels (Security Levels) according to IEC 62443
LevelProtection from…Description of the attackerExampleSL 1Accidental or unintentional violation.Unintentional worker error, lack of awareness of safety rules.An employee accidentally plugs in an infected flash drive.SL 2Intentional violation by simple means.An amateur hacker (“script kiddie”) using freely available, simple tools.Brute-force attack on a service with a default password.SL 3Intentional violation by advanced means.An experienced hacker or group, able to exploit known vulnerabilities.Exploiting a known vulnerability in the SCADA system to take control.SL 4Deliberate violation by extraordinary means.State-sponsored groups with vast resources and knowledge.Attack using unknown vulnerabilities (0-day), like Stuxnet.
From SL1 to SL4: What do the levels mean and what type of attacker do they protect against?
Understanding the different Security Levels is key. Security Level 1 (SL1) is meant to protect against accidental breaches and basic threats. This is to protect against someone who has no bad intentions but makes mistakes, or an amateur hacker with low skills. Security Level 2 (SL2) raises the bar, requiring protection against targeted attacks carried out by more skilled individuals using publicly available hacking tools.
Security Level 3 (SL3) is already protection against professionals. It requires the system to be resistant to attacks carried out by experienced cybercriminals who can exploit known vulnerabilities and have specific knowledge of industrial systems. The highest, Security Level 4 (SL4), is reserved for the most critical infrastructures and is intended to provide protection against top-level attacks carried out by state-sponsored groups with almost unlimited resources, time and knowledge (like the creators of the Stuxnet virus).
It is worth noting that the standard also defines Security Level 0 (SL0), which means there are no security requirements or protections at all. Unfortunately, this is still the baseline for many industrial systems operating worldwide.
Based on the risk analysis, how do you determine the target security level (SL-T) for each zone?
IEC 62443 introduces the concept of Target Security Level (SL-T). This is the level we want to achieve for a given zone, and its selection is the result of a formal risk analysis. It is not an arbitrary decision, but a conscious choice based on an assessment of potential consequences.
The process begins with an assessment of what the worst consequences (financial, operational and, above all, health and life) could be if a zone were compromised. The more severe the consequences, the higher the required level of protection. Next, we assess the likelihood of an attack, taking into account the attractiveness of the target and the motivation of potential attackers.
Based on this analysis, for each defined zone, we determine its SL-T. For example, for a zone controlling safety systems in a nuclear power plant, the SL-T will be 4. For a zone managing a less critical production line in a furniture factory, an SL-T of 2 may be fully sufficient.
How do you verify that your current safeguards reach the required level (SL-A)?
Once we have a defined target (SL-T), we need to see what level of protection our current security measures realistically provide. IEC 62443 calls this level the Achieved Security Level (SL-A). This verification consists of a detailed audit or evaluation of the technical and organizational measures implemented.
For each Security Level, the standard defines a set of specific Foundational Requirements (FR) that must be met. These requirements address seven areas, such as access control, usage control, system integrity or availability.
The verification process involves checking which of these requirements are met by our current safeguards. If we have specified SL-T at level 3 for a zone, we must prove that we have implemented all the measures required for levels SL1, SL2 and SL3. If the audit reveals deficiencies, the difference between SL-T and SL-A represents our “security gap,” which must be closed by implementing additional safeguards.
What does it mean to certify a product to a given safety level (SL-C) and how to use this in the purchasing process?
IEC 62443 also introduces the concept of Capable Security Level (SL-C). This is a level assigned to a specific product or component (such as a PLC) that has been certified by an independent body. SL-C certification means that the product in question has built-in safety features that allow it to be used in systems requiring a given level of protection.
This information is extremely valuable at the stage of the purchasing process. If we are designing a zone for which we have specified SL-T level 3, we should choose components for it that are certified at least SL-C level 3. Using a component with a lower SL-C (e.g. SL-C 1) in a zone with higher requirements is possible, but it means that we will have to provide the missing safety functions with additional, external compensating controls.
Requiring suppliers to provide IEC 62443 certification for their products is one of the most effective ways to meet supply chain security obligations imposed by the NIS2 directive. It gives us objective proof of the level of security maturity of the equipment we buy.
How do the concepts of zones, channels and security levels work together in practice?
All these concepts together form a coherent and logical process for designing a secure architecture. We start by dividing the system into zones and channels. Then, for each zone, based on a risk analysis, we determine its Security Target Level (SL-T).
Then, we design safeguards for the zone. We select components with the appropriate Capable Security Level (SL-C) and implement additional protective measures. We do this until we can prove that the Achieved Security Level (SL-A) for this zone is equal to or higher than the required Target Level (SL-T).
We repeat the same process for all zones and, equally important, for all communication channels. In this way, step by step, we build a complete, risk-based, best-practice architecture in which the level of security is precisely matched to the criticality of the protected assets.
What is a Cyber Security Management System (CSMS) according to IEC 62443?
IEC 62443 is not just about technology. Much of it is devoted to processes and organization. It introduces the concept of a Cyber Security Management System (CSMS). This is a formal management system, very similar in philosophy to the Information Security Management System (ISMS) known from ISO 27001, but fully adapted to the specifics of IACS environments.
CSMS is a comprehensive framework that covers all aspects of an OT security program. It defines policies, procedures and roles. It includes processes such as risk management, vulnerability management, incident management, business continuity planning and employee training.
Implementing a CSMS according to IEC 62443 guidelines is the de facto best way to systematically implement most of the organizational and process requirements of the NIS2 directive. It gives a company a consistent and repeatable methodology to continuously manage and improve its security program.
Why is IEC 62443 not just a technical standard, but a complete OT safety management philosophy?
Reducing IEC 62443 to only technical issues such as firewalls and encryption is a huge oversimplification. In fact, it is a complete, holistic philosophy that teaches how to approach cyber security in a strategic and risk-based manner throughout the lifecycle of industrial systems.
The standard provides tools not only for engineers, but also for managers. It allows you to translate abstract risks into concrete, measurable levels of risk and make informed investment decisions. It creates a common language to build bridges between IT, OT, management and suppliers.
Implementing the principles contained in IEC 62443 is not a one-time project, but a fundamental cultural change. It’s a commitment to continuous improvement and treating cyber security not as a cost, but as an integral component of operational excellence and a prerequisite for survival in the era of Industry 4.0.
How can nFlo help you practically implement the IEC 62443 family of standards in your organization?
At nFlo, we firmly believe in the pragmatic and risk-based approach to safety that IEC 62443 teaches, but we understand that wading through the intricacies of the standard’s dozen or so parts on your own and translating them into a viable action plan can be overwhelming. That’s why we offer our support and experience as your guide on this journey.
Our certified experts will help you conduct a risk analysis and define adequate Security Levels (SL-T) for your key systems. Together with your teams, we will design a network architecture based on the concept of zones and channels, selecting the appropriate technologies to secure communications.
Most importantly, we help you build processes and procedures that form the foundation of your Cyber Security Management System (CSMS). We support you in creating policies, incident response plans and awareness programs that are not only compliant, but most importantly practical and effective in your unique environment. Our goal is to help you build a mature security program that realistically protects your business and allows you to demonstrate NIS2 compliance with confidence.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- NIS2 — NIS2 (Network and Information Security Directive 2) is an EU directive…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
- NIST Cybersecurity Framework — NIST Cybersecurity Framework (NIST CSF) is a set of standards and best…
- AI Act — AI Act is an EU regulation establishing requirements for artificial…
Learn More
Explore related articles in our knowledge base:
- How to conduct a KSC NIS2 readiness audit? A practical guide for CISOs
- How is KSC NIS2 revolutionizing procurement processes? A Guide for the Head of Procurement
- A security operations center (SOC) in every office? We demystify a key requirement of the KRI and NIS2
- Common Misconceptions About the NIS2 Directive
- Critical Infrastructure: Protection and Cybersecurity
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
Related topics
See also:
