IEC 62443 explained for Indian manufacturers

IEC 62443 usually arrives through a requirement someone else set. A customer security questionnaire names it. An auditor asks how your control environment aligns to it. A regulator references it in guidance. Then someone has to work out what committing to it actually involves.

The honest answer is that full conformance is a multi-year programme, and almost nobody starts there. What the standard is genuinely useful for is providing a defensible structure for decisions you need to make anyway: which parts of the plant belong together, how much protection each grouping warrants, and who is accountable for what.

This assumes you have the context from our guide to IT and OT convergence, and that you understand why asset visibility comes before any of this.

Definition

What IEC 62443 actually is

IEC 62443 is a series of standards for the security of industrial automation and control systems, developed jointly by the International Electrotechnical Commission and the ISA99 committee. You will see it written as ISA/IEC 62443, and older material sometimes refers to ISA-99, which is the same lineage.

It is not a single document you can read in an afternoon, and it is not a certification you buy. It is a framework that defines how to assess risk in an industrial environment, how to divide that environment into protected groupings, how much protection each grouping needs, and how responsibility is shared between the organisation that owns the plant, the integrator that builds it, and the vendors that supply the equipment.

That last point is what distinguishes it from general security standards. IEC 62443 assumes an industrial environment is assembled from third-party products by a third-party integrator, and assigns obligations accordingly.

Structure

How the series is organised

The series divides into four groups. Knowing which group a document belongs to tells you whether it is addressed to you.

If you own and operate a plant, most of your attention goes to two places. 62443-2-1 describes the security programme an asset owner is expected to run, which is the governance and process layer. 62443-3-3 defines system security requirements and the security levels, which is the technical baseline you will most often be assessed against.

62443-3-2 is the third one worth knowing, because it describes how to conduct the risk assessment that produces your zone and conduit model. It is the bridge between knowing your estate and designing protection for it.

The 4-x documents matter when you are procuring. Asking whether a vendor develops to 62443-4-1 and whether a product meets 62443-4-2 is a reasonable question in a tender. It is not a question about your own conformance.

Core concept

Zones and conduits

The central organising idea is that an industrial environment is divided into zones, which are groupings of assets sharing common security requirements, connected by conduits, which are the controlled communication paths between them.

Zones are defined by risk and function rather than by network topology or physical location. A packaging line and a utilities system in the same building usually belong in different zones because they differ in criticality, downtime tolerance, and who operates them. Safety instrumented systems almost always warrant their own zone.

Conduits carry the traffic that must cross between zones, and each one is a control point. Defining zones without controlling conduits achieves very little, which is the most common way a zone model fails to deliver anything in practice. The practical implementation of this is covered in our guide to IT-OT network segmentation.

If you have seen the Purdue model, zones and conduits express similar thinking in standards language. The difference matters when you need to show an auditor or a customer a defensible basis for your architecture, because Purdue is a reference model that nobody certifies against and IEC 62443 is a standard that can be assessed.

Security levels

What SL 1 to 4 actually mean

Each zone is assigned a security level from 1 to 4, describing the capability of the attacker it is intended to resist. The levels ascend roughly from protection against casual or accidental exposure, through deliberate attack using simple means and modest resources, up to attack by well-resourced actors with sophisticated means and specific motivation.

The point most often missed is that a security level is a risk decision, not an aspiration. Higher is not automatically better. Each level upward carries cost, operational constraint, and sometimes a reduction in how easily operators can do their jobs. A zone whose worst-case failure is a few hours of lost packaging throughput does not warrant the same protection as one whose failure has safety consequences.

The standard distinguishes three uses of the level, and confusing them causes real problems in procurement:

• SL-T, the target level. What the zone needs, derived from your risk assessment. This is the number you decide.
• SL-C, the capability level. What a product or system is capable of delivering when configured correctly. This is the number a vendor quotes.
• SL-A, the achieved level. What the zone actually delivers as built and operated. This is the number that matters.

A component with a capability level of 3 installed with default credentials on a flat network achieves considerably less than 3. Vendor capability claims describe potential, not outcome.

Accountability

Three roles, and why a certified product does not certify your plant

IEC 62443 assigns responsibility across three parties, and misunderstanding this is the single most common and most expensive misreading of the standard.

The product supplier builds components and systems. The system integrator designs and commissions the installation. The asset owner operates the environment over its life and carries the residual risk.

Certification exists at the product and process level. A controller can be certified against 62443-4-2. A supplier development process can be certified against 62443-4-1. An integrator can demonstrate conformance to its own obligations.

None of that certifies your plant. A plant is an assembly of components, configurations, network design, operating procedures, and people, and conformance is a property of that whole. Buying certified equipment improves your starting position. It does not transfer your obligations, and a customer questionnaire asking about your alignment is asking about the asset owner role, not your vendors.

Regulatory context

Where this intersects with Indian regulation

To be precise about the status: IEC 62443 is not, in itself, a legal requirement in India. It becomes binding through other routes, and those routes are increasingly common.

NCIIPC guidance. Organisations operating critical information infrastructure work under the National Critical Information Infrastructure Protection Centre, whose guidance for control-system environments references the IEC 62443 series. Alignment to the standard therefore supports regulatory readiness rather than sitting alongside it as separate work.

CERT-In. Incident reporting obligations and directions apply regardless of sector, and a documented security programme makes those obligations considerably easier to meet.

Sector regulators. Power sector organisations work to Central Electricity Authority cyber security requirements. Other sectors carry their own supervisory expectations. Scope against the obligations that actually apply to your operations rather than to the sector in general.

Customer contracts. For many Indian manufacturers, particularly those supplying multinational OEMs, the binding requirement arrives commercially rather than from a regulator. A customer security questionnaire referencing IEC 62443 creates an obligation as real as any regulation.

ISO/IEC 27001. An information security management system does not secure a plant by itself, but it provides the governance scaffolding that keeps an OT programme running after the initial project ends. The two complement each other rather than competing, and organisations that already hold 27001 have a meaningful head start on the 62443-2-1 requirements. Caveo Infosystems is certified to ISO/IEC 27001:2022.

Getting started

A realistic first year

Nobody conforms to IEC 62443 in twelve months from a standing start. What is achievable is establishing the structure that makes progress measurable and defensible.

1. Define the system under consideration. Decide what is in scope. A single plant, or one production line, is a better first scope than an entire enterprise.
2. Build the asset inventory. Everything downstream depends on it, and it has to be built safely rather than by scanning a live control network.
3. Conduct the risk assessment. Following the 62443-3-2 approach, identify threats and consequences, and use them to draw an initial zone and conduit model.
4. Assign target security levels. Per zone, justified by consequence rather than by preference. Record the reasoning, because that record is what an auditor will ask for.
5. Assess the gap against 62443-3-3. Compare current controls with the requirements for each zone target level. The output is a prioritised list, not a pass or fail.
6. Remediate by priority. Segmentation and vendor access control usually deliver most in the first year, because they reduce exposure without depending on vendors supporting old equipment.
7. Stand up the governance. Ownership, review cycles, and a change process that keeps the zone model accurate as the plant evolves.

At the end of that, you are not certified. You have a documented risk basis, a zone model, justified target levels, a measured gap, and evidence of progress against it. For most customer questionnaires and most audits, that is what is actually being asked for.

Pitfalls

Common misreadings

1. Treating it as a certification to purchase. Asset owner conformance is a programme, not a product.
2. Assuming vendor certification transfers. A certified controller in a poorly designed network achieves a lower level than its capability suggests.
3. Skipping the risk assessment. Selecting controls before defining zones and target levels produces spending that cannot be justified when questioned.
4. Setting every zone to SL 3. Expensive, operationally restrictive, and a clear signal to an assessor that no real risk analysis happened.
5. Scoping the whole enterprise at once. Programmes scoped too broadly stall before delivering anything.
6. Letting the zone model go stale. Without a change process, the documented architecture and the actual plant diverge within a year.
7. Treating it as separate from IT security. Findings should feed the same risk register and the same monitoring, not a parallel process nobody reviews.

Caveo approach

How Caveo supports IEC 62443 alignment

Our OT security services cover assessment of control environments against the IEC 62443 requirements, zone and conduit modelling, target security level definition based on consequence, and prioritised remediation planning. We assess and design against the standard; we do not issue certification, and no consultancy can certify your plant on a regulator behalf.

Because we also deliver GRC consulting, the governance layer that 62443-2-1 describes can be built into your existing risk and compliance process rather than maintained separately. Caveo is certified to ISO/IEC 27001:2022 and ISO 9001:2015, and our Malaysian entity holds NACSA licences for managed SOC monitoring and penetration testing.

Sector context shapes priorities considerably, so see cybersecurity for manufacturing and energy and critical infrastructure security for how this applies in each.

Frequently asked questions