From Air-Gap to IP: How IEC 62443 Shapes Embedded Security Architecture When OT Meets IT
For most of their operating history, industrial control systems were secure by isolation. The programmable logic controller managing a compressor station, the remote terminal unit reading transformer telemetry, the DCS node controlling a reactor — none of these were connected to anything outside the plant network, and the plant network was not connected to anything outside the plant. Physical separation from the internet made the question of network authentication, encrypted communication, or firmware integrity verification largely academic.
That isolation has been dissolving for years and is now largely gone. The same 10BASE-T1L and EtherNet/IP connectivity that makes an IIoT field transmitter cloud-reachable also makes it reachable from outside the plant if the network architecture permits it. The 2024 update to ANSI/ISA-62443-2-1 acknowledges explicitly that IACS system lifespans routinely exceed twenty years, that many legacy devices contain hardware and software no longer supported by vendors, and that the security program for these environments must address a population of assets that were designed with no security requirements at all running on the same Ethernet infrastructure as newly connected IIoT devices.
For embedded engineers designing the field devices, PLCs, gateways, and edge controllers that populate this converged environment, IEC 62443 is the standard that defines what security they must implement. Understanding what it actually requires at the device level — not the policy level, not the organizational management level — is the prerequisite for making the correct hardware and software architecture decisions.
How IEC 62443 Is Structured and Which Parts Matter for Device Design
IEC 62443 is not a single document. It is a series organized into four groups, and only a subset is directly relevant to embedded firmware engineers. Understanding the structure prevents the confusion of trying to implement operational management requirements (Part 2) in device firmware.
The four groups are:
- General (1-x): Terminology, models, security metrics. IEC 62443-1-1 defines the foundational concepts including zones, conduits, and security levels. Firmware engineers need to understand these to design devices that fit coherently into the zone model.
- Policies and Procedures (2-x): Security program requirements for asset owners. IEC 62443-2-1 (updated 2024) defines what the plant operator must do to manage security across the installation lifecycle. IEC 62443-2-3 covers patch management in IACS environments. Firmware engineers are affected by these indirectly — the device must support the operations that 2-x requires (firmware updates, configuration management, audit logging).
- System (3-x): Security risk assessment and system-level security requirements. IEC 62443-3-2 defines the risk assessment and zone/conduit design process. IEC 62443-3-3 defines the system security requirements that a complete IACS must meet, organized by Security Level and Foundational Requirement. Firmware engineers need 3-3 to understand the system-level capabilities that their device must contribute to.
- Components and Requirements (4-x): This is the part that firmware engineers must own. IEC 62443-4-1 defines the secure product development lifecycle — what the development process must include to produce a certifiable device. IEC 62443-4-2 defines the technical security requirements that the device itself must implement, organized by component type (embedded device, network device, host device, software application) and Security Level.
The Embedded Device Requirements (EDR) section of IEC 62443-4-2 is the direct technical specification for industrial embedded devices. It contains over 140 requirements across seven Foundational Requirements, scaled by Security Level from SL1 through SL4. ISASecure recommends SL2 as the minimum for any device that could be subject to intentional attack — SL1 protects only against coincidental or casual access and is explicitly not designed to address adversarial threats.
Zones, Conduits, and What They Mean for Device Firmware
The zone and conduit model is IEC 62443's fundamental architectural concept. A zone is a grouping of assets with similar security requirements; a conduit is the controlled communication path between zones. The plant security engineer assigns a Target Security Level (SL-T) to each zone based on the risk assessment. Every asset within that zone must meet the assigned SL-T.
For embedded device firmware, the zone assignment determines which of the 62443-4-2 requirements apply at which stringency level. A pressure transmitter in a process zone assigned SL2 needs to implement SL2 Embedded Device Requirements. A gateway sitting in a conduit between the process zone and the enterprise network zone must implement requirements appropriate to managing cross-zone communication — including filtering, authentication enforcement, and audit logging for traffic in both directions.
The practical impact on embedded architecture is the boundary concept: every interface on the device that communicates with entities in other zones — Ethernet ports, serial interfaces, wireless radios, USB ports — is a trust boundary crossing that the device's security architecture must explicitly manage. Interfaces that in a pre-convergence world were opened during commissioning and never reconsidered (Modbus TCP on port 502, open JTAG, hardcoded credentials for the web management interface) become attack surface under IEC 62443's zone model. The embedded device's security architecture must define what each interface is, which zones it crosses, what authentication is required for access through it, and how unauthorized access attempts are detected and logged.
The Purdue reference model that IEC 62443 uses to describe industrial network hierarchy — Level 0 (field instruments), Level 1 (basic control), Level 2 (supervisory control), Level 3 (manufacturing operations), Level 4 (enterprise IT) — is the structural map that zone assignments follow. Each level transition is a conduit that security architecture must explicitly protect. OT/IT convergence is, architecturally, the reduction of conduit enforcement between Level 3/4 (formerly air-gapped from the IT network) and the internet or enterprise IT domain. Every embedded device that previously operated only on Level 0–2 networks and now has a path to Level 4 or beyond has crossed from one security perimeter to another, and its firmware must be designed for the threats that come with that exposure.
The Seven Foundational Requirements at Device Level
IEC 62443-3-3 defines seven Foundational Requirements (FRs) that apply at the system level. IEC 62443-4-2 translates these into device-level implementation requirements for embedded devices. For firmware architects, these translate directly to design decisions.
FR1 — Identification and Authentication Control: every human user and device identity that accesses the embedded device must be uniquely identified and authenticated. For embedded devices in OT environments this means per-device unique credentials (not shared credentials or factory defaults), certificate-based authentication for device-to-device communication, and enforcement of authentication for every management interface including web UI, CLI, SNMP, and API. IEC 62443-4-2 at SL2 requires multi-factor authentication for remote access to higher-privilege interfaces. For devices previously using hardcoded Modbus addresses and no authentication at all, this is a fundamental firmware architecture change: an authentication layer must be implemented before the device responds to any management command.
FR2 — Use Control: authenticated entities must be authorized for only the operations they legitimately need. Role-based access control (RBAC) at the device level means that the operator role can change setpoints, the maintenance role can update firmware, and neither role can access the manufacturing calibration data accessible only to the device vendor role. The device firmware must enforce these separations and refuse unauthorized operations regardless of the caller's identity.
FR3 — System Integrity: the device must protect the integrity of its firmware, software, and configuration data. IEC 62443-4-2 explicitly requires that embedded devices verify firmware integrity during boot and block execution if checks fail. wolfSSL's documentation on meeting secure boot requirements for IEC 62443 notes that the standard's mandate for integrity verification "essentially is a mandate for secure boot and secure firmware updates in the industrial context." The hardware root of trust that anchors this chain — OTP fuses carrying the public key hash used to verify the bootloader, TPM or secure element carrying device identity — is a silicon-level design choice that cannot be added after the fact.
FR4 — Data Confidentiality: communication carrying sensitive process data, configuration data, or credentials must be encrypted. TLS 1.2 or higher for TCP-based communication, DTLS for UDP-based protocols. This requirement affects not just the web management interface but every protocol the device speaks: PROFINET, EtherNet/IP, Modbus-TCP, OPC UA — all need transport security when traversing zone boundaries.
FR5 — Restricted Data Flow: the device must enforce which data flows it participates in and refuse participation in unauthorized flows. Stateful packet inspection, protocol whitelisting, and port filtering are system-level mechanisms; at the device level this translates to firmware that refuses to respond to protocol messages outside its defined communication profile and logs attempts that it refuses.
FR6 — Timely Response to Events: the device must detect security events and generate auditable logs with sufficient detail for forensic analysis. This requires timestamp accuracy (NTP or PTP synchronization), persistent log storage that survives power cycling, and the ability to forward logs to a centralized security monitoring system.
FR7 — Resource Availability: the device must remain operational under denial-of-service conditions. Rate limiting on management interfaces, watchdog mechanisms that recover from unexpected conditions, and graceful degradation to last known safe state when the network is unavailable.
The following table maps each FR to its primary firmware implementation mechanism at SL2:
| Foundational Requirement | Primary device-level mechanism at SL2 |
| FR1 — Identification and Authentication | Unique device credentials, certificate auth, MFA for remote access |
| FR2 — Use Control | RBAC, minimum privilege, per-role capability enforcement |
| FR3 — System Integrity | Secure boot, signed firmware updates, configuration integrity check |
| FR4 — Data Confidentiality | TLS/DTLS on all management and protocol interfaces crossing zone boundaries |
| FR5 — Restricted Data Flow | Protocol whitelisting, refused unauthorized messages, interface filtering |
| FR6 — Timely Response to Events | Persistent audit log, NTP-synchronized timestamps, syslog forwarding |
| FR7 — Resource Availability | Rate limiting, watchdog, safe-state fallback on communication loss |
IEC 62443-4-1 — What the Development Process Must Include
IEC 62443-4-2 specifies what the device must do. IEC 62443-4-1 specifies how the device must be developed. Both are required for device certification. 62443-4-1 defines eight secure development practices that the product vendor's development process must demonstrate:
Security management establishes governance for security decisions throughout the development lifecycle. Security requirements specification requires documenting security requirements based on threat modeling before architecture begins — not after. Secure design requires architecture choices that implement defense in depth, least privilege, and attack surface minimization. Secure implementation requires coding standards (MISRA C, CERT C), static analysis, code review, and compiler configuration that prevents common vulnerability classes. Security verification and validation requires security testing including penetration testing against threat models. Management of security-related issues requires a process for receiving vulnerability reports, assessing severity, and issuing patches. Patch management requires the vendor to maintain the ability to provide security updates throughout the product's supported lifetime. End-of-life requirements define what the vendor must communicate to customers when security support ends.
The practical consequence for embedded firmware teams is that 62443-4-1 certification cannot be obtained by documenting existing practices retroactively. It requires demonstrable process evidence: threat models for each product with documented mitigations, security test reports, vulnerability response records, and patch release documentation traceable to specific CVEs. Teams that do not have these practices in place when they begin certification will spend more time on process gaps than on technical ones.
The Legacy Device Problem and Compensating Controls
ANSI/ISA-62443-2-1-2024 explicitly acknowledges that many IACS assets have 20+ year operational lifespans and contain hardware and software no longer receiving vendor security support. This creates the central practical challenge of OT/IT convergence: the converged network connects new IIoT devices that can implement 62443-4-2 SL2 requirements to legacy PLCs and RTUs that were designed with no security requirements at all and cannot be patched or replaced on any near-term schedule.
IEC 62443 addresses this through compensating controls: when a component cannot meet a security requirement on its own, the system architecture must provide equivalent protection through other means. For legacy devices that cannot authenticate, the conduit protecting that device's zone must enforce authentication at the zone boundary — a firewall, a protocol proxy, or a security gateway that stands between the legacy device and any zone that requires authenticated access. The legacy device remains unmodified; the compensating control prevents unauthorized access to it.
This architecture pattern has direct implications for the embedded design of modern field devices that coexist with legacy populations: the new device should not assume that other devices on the same network segment have been authenticated or that messages arriving from the local network are trustworthy. Zero-trust behavior — authenticate every session, validate every message origin, refuse unexpected protocol behavior — is the appropriate posture for a new 62443-4-2 SL2 device operating in an environment where its neighbors may be decades-old equipment with no security capabilities.
The Cyber-Physical Risk That Makes OT Security Different
The engineering argument for taking IEC 62443 seriously as a firmware architecture constraint — rather than a compliance exercise conducted by the quality department — is the cyber-physical nature of OT security failure. An IT security breach affects data. An OT security breach can affect physical processes: a firmware attack that causes a pressure controller to misreport readings can result in equipment damage or personnel injury. The Purdue model's separation between Level 0–2 (physical process control) and Level 3–4 (information management) was not merely architectural preference — it was a physical safety boundary.
OT/IT convergence collapses that boundary in both directions: IT tools and management practices reach down to the process level, and process data flows up to enterprise IT and cloud systems. The resulting attack surface connects processes with physical safety consequences to networks where the threat actors, exploit techniques, and attack frequency are those of the broader internet rather than the isolated plant floor. Critical infrastructure saw cyberattacks approximately every 13 seconds in 2023.
The embedded security architecture decisions that IEC 62443-4-2 specifies — hardware root of trust for secure boot, TLS on all management interfaces, RBAC enforcing least privilege, signed firmware updates, persistent audit logging — are not compliance overhead. They are the technical response to the fact that an industrial embedded device now operates in a threat environment that its original designers assumed did not exist. The standard provides a structured, testable, certification-traceable way to demonstrate that the response is adequate.
Quick Overview
IEC 62443 provides the security architecture framework for industrial automation and control systems at the moment OT/IT convergence has removed the physical isolation that previously served as industrial cybersecurity. For embedded device firmware engineers, the directly relevant parts are IEC 62443-4-1 (secure development lifecycle requirements for the vendor's development process) and IEC 62443-4-2 (technical security requirements for the device itself, organized by Security Level and component type). At SL2 — the recommended minimum for any device subject to intentional attack — the Embedded Device Requirements mandate unique device credentials, certificate-based authentication, role-based access control, secure boot with firmware integrity verification, TLS on all cross-zone communication, persistent audit logging, and rate limiting. Legacy devices that cannot meet these requirements are addressed through compensating controls at zone boundaries rather than hardware replacement.
Key Applications
Field transmitters and smart sensors connecting via 10BASE-T1L or EtherNet/IP to plant networks that have IT network paths, PLCs and RTUs in manufacturing and process automation that receive remote management access, industrial edge gateways collecting OT telemetry for forwarding to enterprise IT or cloud analytics, remote terminal units in energy infrastructure under NIS2 or critical infrastructure legislation requiring IEC 62443 alignment, and any embedded device developed for sale into industrial markets where procurement specifications increasingly require IEC 62443-4-2 certification or declaration of compliance.
Benefits
IEC 62443-4-2 certification gives device vendors a verifiable, third-party-audited demonstration of security capability that industrial procurement teams can evaluate without performing their own security assessment. The Security Level framework allows customers to match device capabilities to their risk assessment outcomes — a plant segment at SL2 can specify SL2-certified components with confidence. The structured Foundational Requirements decompose the security engineering problem into testable requirements that can be tracked through design reviews and test campaigns, replacing the informal "we implemented security" claim with documented evidence.
Challenges
62443-4-1 process certification requires demonstrated development process evidence — threat models, security test reports, vulnerability response records — that teams without existing security engineering practices must build from scratch before product certification is achievable. The over-140 requirements in 62443-4-2 applied at SL2 represent significant firmware engineering scope for devices that previously had no security requirements; silicon-level choices (secure element, hardware root of trust, TPM) must be made at the design stage and cannot be retrofitted. The 20-year IACS lifecycle acknowledged in ANSI/ISA-62443-2-1-2024 means that newly certified devices will coexist with uncertifiable legacy equipment for years, requiring architectural compensating controls that add cost and complexity to system integration.
Outlook
The 2025 updates to IEC 62443 expand the zones-and-conduits model to address microsegmentation below Layer 3 — a response to the reality that OT networks now run mixed TCP/IP and legacy non-IP protocols on the same physical infrastructure, where traditional Layer 3 segmentation cannot enforce boundaries within a subnet. The EU Cyber Resilience Act (CRA) references IEC 62443 as a basis for demonstrating compliance, creating regulatory pull for certification in European industrial equipment markets. ISASecure's ACSSA (Automation and Control System Security Assurance) certification — targeted for completion in 2024/2025 — extends from product certification to system-level security assurance, addressing the gap between certifying individual components and certifying the assembled system operating in a plant.
Related Terms
IEC 62443, ISA99, IACS, industrial automation control system, OT, operational technology, IT/OT convergence, IIoT, Purdue reference model, zones and conduits, Security Level, SL1 SL2 SL3 SL4, Foundational Requirement, FR1 FR2 FR3 FR4 FR5 FR6 FR7, Embedded Device Requirements, EDR, 62443-4-1, 62443-4-2, 62443-3-3, 62443-2-1, secure boot, firmware integrity, hardware root of trust, RBAC, least privilege, TLS, DTLS, certificate-based authentication, unique device credentials, audit logging, compensating controls, zone boundary, conduit security, microsegmentation, zero trust OT, NIS2, EU Cyber Resilience Act, CRA, ISASecure, EDSA, ACSSA, secure development lifecycle, SDL, threat modeling, patch management, SBOM, defense in depth, attack surface, air gap, PLC, RTU, DCS, field transmitter, edge gateway, PROFINET, EtherNet/IP, Modbus-TCP, OPC UA, critical infrastructure
Our Case Studies
FAQ
What is the difference between IEC 62443-4-1 and IEC 62443-4-2?
IEC 62443-4-1 specifies the secure product development lifecycle — the process requirements for how industrial device vendors must develop their products, including threat modeling, security requirements specification, secure design principles, security testing, vulnerability management, and patch management. IEC 62443-4-2 specifies the technical security requirements — the capabilities the device itself must implement, organized by Security Level and component type (embedded device, network device, host device, software application). Device certification requires both: 4-1 demonstrates that the development process is sound, 4-2 demonstrates that the resulting device has the required security capabilities.
What Security Level should most industrial embedded devices target?
ISASecure's formal position is that SL2 is the minimum appropriate for devices that could be subject to intentional attack. SL1 protects only against coincidental or casual access and explicitly does not address adversarial threats. In a converged OT/IT environment where industrial devices have IP connectivity, intentional attack is a realistic threat scenario, making SL1 insufficient. SL3 and SL4 are appropriate for devices protecting critical safety functions or high-value targets where sophisticated nation-state-level adversaries are plausible threats. For most industrial field devices, PLCs, and edge gateways in manufacturing and process automation, SL2 is the correct target.
What does IEC 62443-4-2 specifically require for firmware integrity?
IEC 62443-4-2 requires that embedded devices verify the integrity of firmware, software, and configuration data needed for the boot and runtime processes prior to use. This is an explicit mandate for secure boot: the device must have a hardware root of trust anchoring a chain of cryptographic integrity verification from power-on through application launch, and must refuse to execute firmware images that fail integrity verification. It also requires preventing the execution of unauthorized software — effectively a whitelist of signed code. The requirement extends to firmware update mechanisms: updates must be authenticated and integrity-verified before being applied, and the device must have a rollback mechanism to recover to a known-good state if an update fails.
How do compensating controls address legacy devices that cannot meet IEC 62443-4-2 requirements?
When a legacy device cannot implement required security capabilities on its own hardware — because it has no cryptographic hardware, no authentication mechanisms, and no path for security patching — IEC 62443 allows the security requirement to be met at the zone boundary instead. A security gateway, protocol proxy, or firewall placed at the conduit between the legacy device's zone and adjacent zones enforces authentication and access control on the legacy device's behalf. The legacy device remains unmodified; the conduit security prevents unauthorized entities from reaching it. This compensating control must be documented in the system security assessment and its effectiveness verified against the threat model, but it does not require hardware replacement of the legacy device.