IEC 62443 explained for teams building edge devices

An edge device sits between consumer and industrial security standards, with an arrow to IEC 62443 and a row of seven security-level numbers

Quick answer: IEC 62443 is the international series of standards for securing industrial automation and control systems and the devices in them. If you build a connected product for commercial or industrial sites, such as a site controller, gateway or EV charger, it’s usually the standard to design against. Part 4-2 covers the device and part 3-3 the site it runs in. Use ETSI EN 303 645 as a lighter checklist alongside it. A consumer version sold in Australia will likely fall under the Smart Devices Rules too.

You make a connected product. It might be a controller that runs a building’s doors, a gateway that links equipment on site to the cloud, or a network of EV chargers. A large customer wants to roll it out across their sites, and before they sign, their security team sends you a vendor questionnaire.

Most of it is familiar ground. Then one question stops your team. Which international security standard does your product align to?

It’s a fair question, and a harder one than it looks. Search for an answer and you’ll find at least five candidates, each with its own scope, vocabulary and cost. Choose one written for smart speakers and your customer’s operations team will send it back. Choose the heaviest one without understanding it and you can spend months building controls that stop your product doing its job.

We design and build edge-to-cloud platforms for organisations whose sites have to keep running when the cloud is out of reach, and IEC 62443 (also known as ISA/IEC 62443) is the standard we design their edge devices against. This guide shows where your product sits among the standards, why IEC 62443 is usually the right answer, what it asks of a product team, and where to start.

Consumer, industrial or in between? Where your product sits

Many security standards for connected devices fall into one of two broad families. Consumer IoT standards are written for things people buy for their homes, like cameras, speakers and baby monitors. Industrial standards are written for the equipment that runs plants, grids and water networks.

Plenty of products belong to neither family. A building access reader, an EV charger, a pump station controller, a gateway in a retail fit-out. Nobody buys one for the lounge room, and nobody would call one a factory.

Three questions place your product quickly.

Does it control something physical? A door lock, a valve, a relay, a charger. If its output moves something in the real world, you’re closer to industrial.
Does it have to keep working when the cloud is unreachable? If a site stops when the link drops, people are locked out or left waiting. Staying available through a failure is a defining concern of industrial security.
Who runs the site it lives on? If your customer has an operations or security team that manages the site network, they’ll assess your product the way they assess the rest of their control systems.

In most cases, two or three yeses put you on the industrial side, whatever your product looks like. The Australian market adds a fourth question. Could any version of your product be bought by a consumer? If so, that version must meet the Smart Devices Rules, whatever else you align to. The rules exclude only a few classes, such as laptops, smartphones and therapeutic goods.

These are the standards and rules you’re likely to be pointed at.

Standard	Written for	How to use it
IEC 62443 (ISA/IEC 62443, and AS IEC 62443 in Australia). International series for industrial automation and control systems	Control systems and their components, from a single device (part 4-2) to a whole site (part 3-3) and the supplier’s development process (part 4-1)	Typically the governing standard for a site controller, gateway or edge device
ETSI EN 303 645 (V3.1.3, 2024). European baseline for consumer IoT	Consumer devices. Its scope leaves out devices made mainly for industrial use	A baseline checklist, and the basis for Australia’s Smart Devices Rules
Smart Devices Rules 2025 (Australian law, in force since 4 March 2026)	Consumer-grade connectable products sold in Australia	Mandatory for any consumer version outside the excluded classes. Requires no universal default passwords, a way to report vulnerabilities and a published security support period
NIST IR 8259A. US baseline of device security capabilities	Any IoT device	A quick first check of what the device itself can do
OWASP ISVS. Community verification standard for IoT, still a release candidate	Devices and their surrounding services	A test checklist covering boot, firmware, communications and updates
NIST SP 800-82 (revision 3). US government guide to OT security	Operational technology	A free guide that maps its steps to IEC 62443 and adds an OT overlay of NIST SP 800-53 controls
EU Cyber Resilience Act. EU regulation	Products with digital elements sold in the EU	An obligation only if you sell into the EU. Reporting duties began on 11 September 2026, and the main requirements apply from 11 December 2027

Why IEC 62443 fits edge and site controllers

IEC 62443 is written for systems that control physical processes and have to keep running. Its stated priorities for a control system are availability, protection of the equipment it controls, operation in a degraded mode, and time-critical response. Those are the concerns of any site controller at its busiest hour.

It’s also a standard your customer’s assessor is likely to know. Standards Australia adopted the series as AS IEC 62443 in 2025. Parts 3-3 and 4-2 are published here as AS IEC 62443.3.3:2024 and AS IEC 62443.4.2:2025, identical to IEC 62443-3-3:2013 and IEC 62443-4-2:2019. An amendment to part 4-2 was in draft in 2026, so check which edition your customer expects.

Three more reasons it holds up when you have to defend the choice.

It separates your job from your customer’s. You state what your product is capable of. The site owner sets the level each site needs. That’s the conversation you want to be having.
It builds on NIST. Part 3-3 lists NIST SP 800-53 among its sources, and its bibliography includes NIST SP 800-82 and NERC CIP (the North American power-sector rules). A customer who works in NIST terms can map across.
It can be certified. Accredited certification bodies assess products against it, under schemes such as ISASecure and the IEC’s own IECEE programme.

ETSI EN 303 645 and the NIST and OWASP baselines still earn their place as checklists. When an operations team asks which standard governs the design of a device like this, the answer is most often IEC 62443.

What IEC 62443 asks of a product team

Three parts of the series carry most of the weight.

Part 4-2 sets the technical security requirements for a single component, meaning your device and its software.
Part 3-3 sets the requirements for a whole system, meaning the site your device runs in, with its network and the equipment around it.
Part 4-1 sets the secure development lifecycle a component must be built under. Part 4-2 depends on it. This guide stays with the technical requirements in 4-2 and 3-3.

The series is written around four roles. The asset owner runs the site. The product supplier makes the components. The system integrator puts them together on site, and the service provider supports them in operation. A product company is often supplier and integrator at once. In our experience, confusion starts when each party assumes another holds a responsibility.

Every requirement sits under one of seven foundational requirements.

Identification and authentication control. Every person, process and device proves who it is before it gets access.
Use control. Once someone is in, what they can do is enforced and recorded.
System integrity. Software, settings and messages can’t be changed without authority.
Data confidentiality. Information is protected where it’s stored and as it travels.
Restricted data flow. The network is divided into zones, and data only crosses the boundaries it needs to.
Timely response to events. Security events are noticed, reported and acted on in time.
Resource availability. Essential functions keep running through denial-of-service attacks and other security incidents.

Part 4-2 also sorts components into four types, namely software applications, embedded devices, host devices and network devices. The standard’s examples are industrial, such as a PLC, a substation protection device, a switch, a VPN terminator and a data historian. A Raspberry Pi controller running your software isn’t on that list, so you classify it from the definitions. A general-purpose operating system makes it a host device, and your code on it is a software application, so both sets of requirements apply.

Most importantly, IEC 62443 states outcomes. Part 3-3 says of itself that it doesn’t hold enough detail to design a security architecture. It tells you what has to be true, and the design is yours.

Where IT security instincts conflict with IEC 62443

Many product teams learn security on web and cloud platforms, where the safe response to doubt is to refuse. Lock the account. Reject the request. Stop and raise an alert.

IEC 62443 starts from a different place. Its first concern is that the site keeps doing its job, and several of those reflexes are exactly what it warns against. These are the conflicts we see most often when a team brings web security habits to an edge device.

The IT reflex	The IEC 62443 approach
Lock the account after five failed sign-ins	Never lock an account that an essential function depends on, even briefly. In practice that means limiting the source of the attempts
Refuse to connect when a certificate can’t be checked	On a high-availability system, losing the certificate authority must not stop essential functions. In practice certificates have to be checkable without a live link to the centre
Stop if the audit log can’t be written or the clock looks wrong	When audit processing fails, staff are alerted and essential functions keep running. Recording who did what must not noticeably delay the process, and a bad timestamp must not stop it
Keep the logic in the cloud and the edge thin	When the site boundary closes, in what the standard calls “island mode” or “fail close”, essential functions keep running. Everything they need has to live on the site
A higher security level is always better	Not always. A system that must be very highly available may sensibly sit lower on authentication, with physical and personnel measures making up the difference
Read the requirement title and tick it off	Titles mislead. Resource management (CR 7.2) sounds like memory and disk limits. It’s about making sure security functions, such as patching, scans and integrity checks, can’t starve the device’s main job

Most of these conflicts flow from one idea. Before you choose a single control, declare your product’s essential functions. For a building access system, that means letting authorised people in, keeping everyone else out, and showing staff what’s happening on site. The standard’s rule is that on a high-availability system, no security measure may stop an essential function unless a risk assessment supports it, and never in front of a safety function. That one rule shapes an edge design more than any individual requirement.

IEC 62443 security levels are seven numbers, not one

If your team has worked with functional safety, you’ll know the safety integrity level (SIL) from IEC 61508. A safety function gets a single SIL, because the rate of random hardware failure behind it can be calculated.

Security doesn’t reduce to one number. Attackers, motives and consequences vary too much, so IEC 62443 rates each of the seven foundational requirements separately, on a scale of 1 to 4.

Level 1 protects against casual or accidental misuse. A contractor reads a password taped inside the comms cabinet door.
Level 2 protects against deliberate attacks using simple, widely available means. An automated scan finds a remote-support port left open with its default password.
Level 3 protects against a sophisticated attacker with skills specific to systems like yours. Someone who understands your controller crafts an attack on its local interfaces.
Level 4 protects against the same kind of attacker with extended resources and motivation. A well-funded group spends weeks on a campaign against one operator.

A product’s capability is written as a vector of seven numbers, in the order of the foundational requirements above. An edge controller might read {2, 2, 2, 1, 2, 1, 3}. Resource availability sits highest because keeping the site running is the job. Data confidentiality sits lowest because the device holds little of value and runs on its own network. That vector is an illustration, and the right one for your product comes from your own risk assessment.

Three kinds of level keep the conversation straight.

Capability is what your product can do on its own. You state it.
Target is what a particular site needs. The owner sets it from their risk assessment.
Achieved is what a site has once your product is installed, checked at commissioning and again over time.

So when a customer asks whether your product is “SL2”, the useful answer is your capability vector and how it meets their target.

Where to start aligning your product to IEC 62443

You don’t need to settle all seven numbers on day one. These five steps are how we start an alignment, and they get a product team moving without deciding everything at once.

Name the roles. Write down who owns each site, who supplies the product, who integrates it and who maintains it.
Declare the essential functions. List them, name the degraded mode for each, and ask outright whether any output is a safety function.
Classify every component. Use the four device types and record why each one fits.
Draw the zones and conduits. Show which equipment sits together, what crosses each boundary, and what keeps running when each boundary closes. Then decide what every output does when something fails. A door that loses its controller should fail open or fail secure by design.
Choose a first capability vector and map the requirements to it. Start with a milestone you can evidence, the same way you’d scope a minimum viable product. Record where something outside your product, such as a locked cabinet or the site firewall, covers a requirement for you.

Unless a contract requires it now, certification can wait. It’s an assessment by an accredited body of your product and, in some schemes, of how you build it under part 4-1. Plan for it once the design holds up.

Buy the parts you need. The standard is copyright and sold per part under licence, by the IEC, by ISA as ANSI/ISA-62443 and by Standards Australia as AS IEC 62443, among others. For the how, the free publications in the table above fill the gaps, and NIST SP 800-82 is a good place to begin.

Since 2008 we’ve designed and built software for organisations where downtime has a cost, from customer platforms to edge-to-cloud IoT platforms. If you’ve been handed a questionnaire that names IEC 62443, our secure by design software development team can run the gap assessment, build the fixes and roll them out. If you’re designing an edge product and want the security right from the first build, our IoT and edge platform team can help you scope it. For the zones, conduits and connectivity requirements your customer’s IT team will ask for, see our systems design and architecture service.

IEC 62443 doesn’t ask you to lock everything down. It asks you to keep the site running while you protect it.

Frequently asked questions

What is IEC 62443?

IEC 62443 is an international series of standards for the security of industrial automation and control systems, developed jointly by the International Society of Automation (ISA) and the IEC. Its parts range from the asset owner’s security programme to requirements for service providers, whole systems, single components and the supplier’s development process. It’s also known as ISA/IEC 62443, and adopted in Australia as AS IEC 62443.

Is IEC 62443 mandatory in Australia?

Not on its own. IEC 62443 is a voluntary standard, adopted by Standards Australia as AS IEC 62443. It becomes a requirement when a customer, tender or contract names it. Consumer-grade connectable products are a separate case. Those made from 4 March 2026 must meet the Cyber Security (Security Standards for Smart Devices) Rules 2025, which draw on ETSI EN 303 645, unless they fall in an excluded class such as smartphones.

What is the difference between IEC 62443-3-3 and IEC 62443-4-2?

Part 3-3 sets security requirements for a whole system, such as a site with its network and equipment. Part 4-2 sets requirements for a single component, and derives each one from the system requirement with the same number. Part 4-2 adds requirements by device type for software applications, embedded devices, host devices and network devices. A product supplier usually states capability against 4-2, and the site is assessed against 3-3.

IEC 62443 or ETSI EN 303 645?

ETSI EN 303 645 is a baseline for consumer IoT devices, and its scope leaves out devices made mainly for industrial use. IEC 62443 is written for industrial and commercial control systems, including the IoT and edge devices in them. If your product controls physical equipment on managed sites and has to keep working when the cloud is unreachable, align to IEC 62443 and use ETSI EN 303 645 as a checklist.

What are IEC 62443 security levels?

Security levels run from 1 to 4, from protection against accidental misuse up to well-resourced, targeted attacks. They’re set separately for each of the seven foundational requirements, so a product’s level is a vector of seven numbers. The supplier states the product’s capability, the asset owner sets a target for each site, and the achieved level is checked once the product is installed.

Can a product be certified to IEC 62443?

Yes, through accredited certification bodies, under schemes such as ISASecure and the IEC’s IECEE programme. ISASecure’s component certification assesses the technical requirements of part 4-2 together with the development process in part 4-1. IECEE can certify each part on its own. Align the design first, then plan certification once the capability vector and its evidence are stable.

What is the difference between ISO 27001 and IEC 62443?

ISO/IEC 27001 is the standard an organisation’s information security management system is certified against, meaning the policies, risk process and controls a business runs. Parts 3-3 and 4-2 of IEC 62443 set technical security requirements for control systems and their components, with security levels a product can be designed and assessed against. The two work together. A supplier can hold ISO 27001 for the business and align its product to IEC 62443.