IEC 62443 Explained: What It Requires and How to Prove It

IEC 62443 is the international standard series for securing industrial automation and control systems, and it's the framework your manufacturing, water, energy and building automation clients will name long before anyone brings up NIST. It isn't one document. It's a family of standards split into four numbered groups, held together by a zone and conduit model and a set of security levels describing how determined an attacker you're building against. MSP Pentesting runs OT-aware penetration tests under your brand, channel-only, so you can hand a client defensible evidence against 62443 requirements without standing up an OT practice of your own.

Most MSPs meet this standard the same way. A new plant manager asks whether you "do 62443." You say yes. Then you discover it's a multi-part series and nobody will say which part they meant.

Here's the short version.

What IEC 62443 actually is

It's a joint product of the ISA99 committee and IEC Technical Committee 65, which is why you'll see it written as ISA/IEC 62443. It covers industrial automation and control systems, shortened to IACS everywhere in the text, and it treats a control system as more than a pile of boxes. People, processes, suppliers and products all show up somewhere in the series.

Two things surprise anyone arriving from IT compliance work.

First, it's risk-driven, not a fixed checklist. You don't apply every requirement everywhere. You assess risk, partition the environment into zones, and assign each zone a target security level. What you owe follows from that.

Second, there's no blanket "62443 certified" badge for an organization the way people talk about ISO 27001. Certification schemes sit on top of the standard (ISASecure and the IECEE scheme are the two you'll meet) but they certify specific products, processes or sites against specific parts. Anyone selling organization-wide 62443 certification is being loose with the language.

The four groups, and who owns each one

The series numbers itself by group. The first digit tells you the category, the second tells you the document. Once that clicks, navigating it gets a lot easier.

When a client says "we're doing 62443," ask which part. The answer tells you whether they're writing policy, redesigning a network or buying hardware. Very different engagements.

The part MSPs keep missing: 62443-2-4

62443-2-4 sets security program requirements for IACS service providers. Read that again.

If you hold remote access into a plant, patch OT hosts, manage the firewall at the IT and OT boundary, or push engineering changes, you are a service provider under this standard. Your client's assessor can ask about your program, not just theirs.

You thought you were selling compliance.

You're in scope.

That's not a problem, it's a wedge. MSPs who can answer cleanly about their own access control, change management and subcontractor handling win industrial accounts that competitors stall out on.

Security levels 0 through 4

Security levels describe the adversary you're built to withstand. Not a maturity score, not a grade. Each level is defined by the means, resources, skills and motivation of the attacker it holds off.

• SL 0. No specific requirements.
• SL 1. Protection against casual or coincidental violation. The contractor who plugs into the wrong port.
• SL 2. Protection against intentional violation using simple means with low resources, generic skills and low motivation. Commodity malware and opportunists.
• SL 3. Protection against intentional violation using sophisticated means, moderate resources, IACS-specific skills and moderate motivation. Someone who knows what a PLC is and wants yours.
• SL 4. Same, but with extended resources and high motivation. State-sponsored territory.

Most sites land on SL 2 for general zones and SL 3 for anything touching safety or a high-consequence process. SL 4 is rare and expensive enough that nobody picks it casually.

Now the part that matters for testing. The standard uses three flavors of security level, and confusing them is the most common error in an OT assessment.

• SL-T, target. What a zone needs. Output of the risk assessment.
• SL-C, capability. What a product or system can deliver when configured correctly. This is the number on the vendor datasheet.
• SL-A, achieved. What the installation actually delivers as built, as configured, today.

Vendors sell SL-C. Assessors ask about SL-T. SL-A is the one nobody can hand you on a datasheet.

Careful how you sell the test here. A pentest doesn't certify an achieved SL for a zone, and anyone telling you it does is overselling. What it produces is dated, empirical evidence that specific controls held or failed under conditions you agreed in writing first. That feeds an SL-A assessment alongside architecture and configuration review, and it's the only input in that package that comes from somebody actually trying to get in.

The gap between capability and achieved is where nearly every real finding lives.

Zones and conduits, without the hand-waving

A zone is a grouping of assets that share security requirements. A conduit is the communication path between zones plus whatever controls you apply to it. That's the whole concept, and it works because it forces two decisions people otherwise dodge. What belongs together, and what's allowed to cross.

62443-3-2 walks through this as a process. Define the system under consideration, run an initial risk assessment, partition into zones and conduits, assess risk per zone, assign SL-T, document it. If you already run risk assessments for IT clients the logic will feel familiar. The scoping and the consequence model are what change.

A few rules that fall out of real assessments:

• Safety instrumented systems get their own zone. Always. They don't share a zone with basic process control.
• Wireless gets its own zone, because the trust boundary is physical and you can't see where it ends.
• Any path to the internet is a conduit. Vendor remote access counts even when it's outbound-initiated.
• Temporary connections count. The integrator's laptop isn't out of scope because it leaves on Friday.

Drawing zones is easy. Proving a boundary holds is the actual work, and that requires somebody attacking it.

The seven foundational requirements

Everything technical in the series rolls up to seven foundational requirements. 62443-3-3 turns them into system requirements graded across the security levels. 62443-4-2 does the equivalent at component level.

• FR 1, identification and authentication control. Who and what gets to connect.
• FR 2, use control. What they're permitted to do once connected.
• FR 3, system integrity. Code, firmware and data aren't altered without authorization.
• FR 4, data confidentiality. Information isn't readable by parties who shouldn't read it.
• FR 5, restricted data flow. Segmentation. Traffic goes only where policy says it can.
• FR 6, timely response to events. You notice, and you act on it.
• FR 7, resource availability. The control system keeps running under stress.

Learn those seven and you can hold a real conversation with a controls engineer without bluffing.

How a pentest produces evidence against 62443

Assessors don't want your opinion on whether a zone boundary works. They want artifacts. Here's what a properly scoped test yields, requirement by requirement.

• FR 1 and FR 2. Shared HMI logins, permanent local admin on engineering workstations, service accounts still holding domain rights from a migration that ended years ago, vendor accounts nobody disabled. Testing produces a named list with proof of access rather than a policy assertion.
• FR 3. Unauthenticated write paths to controllers, unsigned firmware update mechanisms, protocol handlers that accept commands from any source. Demonstrated on a spare unit or in a lab, not on a running process.
• FR 4. Cleartext industrial protocols, historian credentials in plaintext config files, unencrypted backups of the whole control estate.
• FR 5. The headline finding on most engagements. Can a compromised business workstation reach a supervisory host? Does the DMZ terminate sessions or quietly forward them? Does the guest wireless VLAN have a route nobody intended?
• FR 6. Every test doubles as a detection exercise. If nothing alerted while a tester moved from the business network into site operations, that's a documented gap with timestamps.
• FR 7. Assessed rather than proven. You don't run availability attacks against a live plant, so config review and redundancy validation carry this one.

What the assessor wants is a per-zone statement. Here's the target level, here's what the installation achieved against it, here's the proof, here's the fix and the owner. A finding list sorted by CVSS score doesn't answer that. Structure the report by zone and requirement instead, which is why we publish a pentest report template partners can share with a client before the engagement starts.

Testing live industrial systems without breaking anything

This is where OT work stops resembling IT work. A scan that's routine on a corporate subnet can knock a legacy PLC offline, and an offline PLC in the wrong process is a safety event, not a ticket.

The working model on a serious engagement looks like this. Full active testing at the business and DMZ layers. Passive collection and pre-agreed interaction at the supervisory layer. Config review and lab replication for controllers. Go and no-go criteria signed before anyone touches a keyboard, plus an engineer on the call with authority to stop the test.

Nobody credible fires an exploit at a running turbine to see what happens.

Where 62443 sits next to what you already run

NIST SP 800-82 is guidance for securing operational technology and it references 62443 throughout. Use 800-82 to learn the terrain. Use 62443 when someone wants requirements to test against.

What none of your existing IT work covers is the plant floor. SOC 2 scoping and PCI DSS boundaries stop at the business network in practice. A client can hold a clean SOC 2 report and still run an unauthenticated PLC on a flat VLAN reachable from reception. Both true at once, which is why OT testing is a separate line item.

Common questions about IEC 62443

Is IEC 62443 mandatory?

Not on its own. It's a voluntary consensus standard. It becomes effectively mandatory through contracts, insurance requirements, sector regulators and large customers who write it into supplier agreements. If your client sells into automotive, pharma, energy or critical infrastructure, somebody upstream will eventually require it in writing.

Do we need to be certified before we can work on 62443 projects?

No. Certification against 62443-2-4 is a differentiator for service providers, not an entry requirement. Plenty of MSPs deliver 62443-aligned work without it. What you do need is honest scoping, testers who understand industrial protocols, and the discipline to refuse activities that put a process at risk.

Does a normal network pentest count as 62443 evidence?

Partly, and only if it's mapped. An internal test that stops at the corporate network proves nothing about the zone boundaries below it. Testing that crosses the IT and OT boundary and reports findings against foundational requirements per zone does produce usable evidence. The difference is scope and reporting structure, not tooling.

Who decides the target security levels?

The asset owner, informed by the risk assessment in 62443-3-2 and usually with an integrator and a process safety engineer in the room. It's a decision about consequence, not a technical one. Your job is to make sure it gets documented, because an undocumented target level means nobody can be held to anything.

Where to take this next

IEC 62443 isn't as intimidating as its part numbering makes it look. Four groups. Seven foundational requirements. Five security levels in three flavors. Zones and conduits. That's the whole mental model, and it's enough to run a competent client conversation this week.

The hard part isn't understanding it. It's producing evidence without hiring OT testers and building a lab you'll use four times a year.

That's the part we handle. MSP Pentesting delivers white-labeled penetration testing under your brand, including OT-aware engagements scoped by zone and reported against foundational requirements. Your client sees your logo. Bring us the zone diagram and the site constraints, and we'll tell you straight what can be tested live, what belongs in a lab, and what the evidence package looks like when it's done.