IEC 62443-4-2 SL2 in practice: integrator checklist

Executive summary

IEC 62443 has moved in a few years from niche standard to explicit requirement in Brazilian public tenders, operator specifications and utility contracts. The integrator who builds SCADA panels, commissions PLCs and delivers Modbus networks for substations or telecom now receives direct Security Level 2 (SL2) requests that did not exist two years ago. This whitepaper unpacks what SL2 of Part 4-2 means in practical terms, without repeating the overview that every vendor presentation already covers. The seven Foundational Requirements are explained in integrator voice, followed by an objective twenty-five item checklist for component acceptance, concrete questions for vendor evaluation, and an honest item-by-item evaluation of the AEM-60DC8 against the same checklist, covering what it does, what is in progress (SL2 target, not yet certified) and what must be covered by the rest of the architecture. The text closes with the real ceiling of SL2 and the decision criterion to scale up to SL3.

For whom this whitepaper is — integrator, not auditor

This text is written for the industrial automation integrator, panel builder, SCADA designer and commissioning engineer. The scope is deliberate. The industrial cybersecurity auditor works with the whole IEC 62443, especially Parts 3-2 (system risk assessment) and 4-1 (manufacturer development process). The integrator works with what is inside the panel, and the reference document is Part 4-2 ("Technical security requirements for IACS components").

The integrator is rarely in a position to demand changes in a commercial PLC firmware. They are in a position to choose components, configure the system, segment networks, define passwords and procedures, and deliver acceptance evidence. SL2 at this level is more a buying and configuration decision than a development one. The goal of this whitepaper is to give the integrator a practical instrument to make that decision without becoming a standards specialist.

An important assumption: SL2 of Part 4-2 is a component level. IEC 62443-3-3 deals with system level, a different exercise. An SL2 system is not necessarily a system built only of SL2 components — it can be a system with stronger components in critical zones and weaker in isolated ones. The integrator must understand both dimensions but, day to day, chooses components individually.

What changes between SL1, SL2, SL3 and SL4

IEC 62443 defines four Security Levels that describe the adversary against which the component (or system) can defend. Levels are cumulative: SL3 includes SL2; SL2 includes SL1.

Level	Typical adversary	Means	Resources	Skills	Motivation
SL1	Accident, casual error	Low	Low	Generic	No malicious motivation
SL2	Opportunistic attacker	Low	Low	Generic	Low
SL3	Deliberate IACS attacker	Sophisticated	Moderate	IACS-specific	Moderate
SL4	State-level / advanced	Sophisticated	Extensive	IACS-specific	High

Practical reading: SL1 protects against the engineer who presses the wrong button. SL2 protects against the teenager with Metasploit and an off-the-shelf pentest script. SL3 protects against the attacker who has studied IEC 61850 and knows exactly what to do with a compromised IED. SL4 protects against the adversary who builds supply-chain attacks and coordinated backdoors.

The vast majority of Brazilian industrial projects — telecom battery bank, distribution substation supervision, discrete manufacturing, water utility — have a risk profile justifying SL2 for measurement and communication components. SL3 enters for assets whose compromise causes direct physical harm: protection relays in HV transmission, turbine control in generation, reactor controllers in nuclear processes. SL4 is rare outside of defense and explicitly designated national critical infrastructure.

The seven Foundational Requirements

IEC 62443-4-2 organizes its requirements into seven Foundational Requirements (FR), inherited from Part 1-1. Each FR groups a set of Component Requirements (CR) that apply differently to four component types: Software Application, Embedded Device, Host Device and Network Device. The paragraphs below describe each FR in integrator voice.

FR 1 — Identification and Authentication Control (IAC). The component must know who is accessing and how. In practice this translates to nominal users (no universal "admin/admin"), support for password policies, machine authentication where applicable, and at SL2 some form of unique identification for services and devices. A PLC with a shared "engineer" login is a failure; a PLC with named users and a log of who did what is the way.

FR 2 — Use Control (UC). Knowing who they are, the component decides what they can do. Granular permissions, distinct roles (operator, maintenance, administrator), separation between configuration and operation. For CR 2.1, the component must enforce use control based on the authenticated identity — which rules out the common practice of a single password granting full access.

FR 3 — System Integrity (SI). The component protects itself from unauthorized modification. Code integrity verification (firmware signing), protection against malicious software (where applicable), input validation on communication interfaces. For embedded devices, the central SL2 item is cryptographic firmware signing with boot verification — without it, the component is vulnerable to malicious update.

FR 4 — Data Confidentiality (DC). Sensitive data in transit and at rest is protected. In IACS, "sensitive data" includes credentials, keys, critical configuration parameters and, in some cases, operational telemetry. For a DC voltage monitor, the telemetry itself is rarely sensitive, but credentials and keys used to authenticate updates are.

FR 5 — Restricted Data Flow (RDF). The component respects network segmentation. Does not cross zones unnecessarily, makes no spontaneous outbound connections outside the zone, supports traffic separation. For the integrator, this translates to choosing equipment that accepts a firewall in front, supports explicit routing configuration, and has no embedded "phone home".

FR 6 — Timely Response to Events (TRE). The component generates auditable events and makes them available to the central event system. Security logs in consumable format (Syslog, dedicated Modbus registers, OPC UA Alarms), trustworthy timestamp, minimum retention. A component that does not log is invisible to the SOC.

FR 7 — Resource Availability (RA). The component keeps running under stress. Resistance to denial of service on communication interfaces, resource management, recovery after failure. At SL2 the requirement is reasonable — survive aggressive scanning without crashing, not exactly resist distributed saturation attack.

Components to verify in your project

Part 4-2 categorizes components into four types, and each type receives a specific subset of CRs derived from the seven FRs. The simplified mapping below guides reading:

Component type	Typical examples in industrial project	Applicable CRs
Software Application	SCADA, historian, MES	SAR (Software App Requirements) under each FR
Embedded Device	PLC, IED, quantity monitor, BMS, AEM-60DC8	EDR (Embedded Device Requirements) under each FR
Host Device	Engineering workstation, OPC server	HDR (Host Device Requirements) under each FR
Network Device	Industrial switch, firewall, IIoT gateway	NDR (Network Device Requirements) under each FR

The standard uses this matrix to avoid demanding TLS from a sensor with no TCP stack — the confidentiality requirement of FR4 turns into something appropriate to the embedded side (protection of configuration travelling via Modbus inside the zone, for example). The integrator should map every component in the project to a type and then check it against applicable CRs.

SL2 component acceptance checklist — 25 objective items

The twenty-five items below are a practical distillation of SL2 CRs from IEC 62443-4-2 translated into concrete checks the integrator can perform during FAT (Factory Acceptance Test) and SAT (Site Acceptance Test) of an individual component. The list does not replace reading the standard but covers the points whose absence is most frequently raised in audit.

#	Item	FR	How to verify
1	Unique identifiers for human users	FR1	Manufacturer documentation; user creation test
2	Unique identifiers for services/devices	FR1	Documentation; component configuration
3	Lock after N failed authentication attempts	FR1	Controlled brute-force test
4	Use notification or warning banner	FR1	Screen/banner at login
5	Configurable session timeout	FR1	Configuration and empirical test
6	Minimum password policy enforced by the component	FR1	Reject weak password attempt
7	Granular role-based permissions	FR2	Role × function matrix in documentation
8	Separation between configuration and operation	FR2	Test with operations-only user
9	Block unauthorized commands	FR2	Test with under-privileged user
10	Audit of failed use attempts	FR2 / FR6	Inspect log after test
11	Boot-time integrity verification	FR3	Modified-firmware attempt must fail
12	Cryptographic firmware signing	FR3	Scheme documentation; load unsigned firmware test
13	Firmware anti-rollback	FR3	Attempt to install older version must fail
14	Input validation on communication interfaces	FR3	Controlled fuzz over Modbus/SNMP/MQTT
15	Protection of confidential information at rest	FR4	Passwords and keys not in clear in firmware
16	Confidentiality in transit where applicable	FR4	TLS/HTTPS/SNMPv3 where architecture demands
17	Network segmentation support	FR5	Component IP/firewall configuration
18	No unnecessary ports and services	FR5	Nmap against component on test network
19	No undocumented "phone home"	FR5	Traffic capture in idle state
20	Security event log generation	FR6	Trigger event and verify log
21	Log timestamps and NTP support	FR6	Synchronization and correlation of logs
22	Log export in consumable format	FR6	Syslog, dedicated registers, OPC UA Alarms
23	Operation under high communication load	FR7	Polling stress test
24	Automatic recovery after communication failure	FR7	Cut and restore channel
25	Hardening documentation published by the manufacturer	Cross	Vendor hardening guide exists and is accessible

Each item enters as a line on FAT/SAT with documentary or test evidence attached. In projects with contractual SL2 enforcement, the absence of evidence on a specific item becomes a manageable non-conformity — but absence of the hardening guide of item 25, for example, typically indicates a vendor not tracking the standard and should be a bigger concern.

How to evaluate vendors — questions to ask for BMS, PLC and HMI

Most vendor catalogs do not answer the integrator at the level of detail SL2 demands. The questions below, directed to the vendor's application engineer (not the sales rep), separate serious vendors from those who stamp "Cybersecurity Ready" on the datasheet without evidence.

1. What is the firmware signing scheme? RSA, ECDSA, Ed25519? What key size?
2. Does the bootloader verify the signature before every boot, or only during update?
3. Is there firmware anti-rollback? How is it implemented?
4. Has the component been evaluated by an accredited laboratory against IEC 62443-4-2? At what SL? What is the certificate number?
5. If not yet certified, what is the certification schedule and which laboratory?
6. Is there a factory default credential? How is it changed during commissioning?
7. Which interfaces remain active in production? Is there a "development mode" that needs to be disabled?
8. Is a published hardening document available? Can I see the current version?
9. What is the vendor's vulnerability disclosure cycle? Is there a PSIRT (Product Security Incident Response Team)?
10. Which CVEs have been published against this product and when were they fixed?
11. Does the manufacturer publish an SBOM (Software Bill of Materials)?
12. What is the product lifecycle and until when is there commitment to security patches?

An evasive answer to any of these twelve questions is relevant data for the integrator. A vendor that does not publish an SBOM in 2026 is three to four years behind best practice and almost certainly behind on other dimensions too.

Concrete example — evaluation of AEM-60DC8 against the checklist

Applying the checklist to a real component makes the exercise less abstract. The evaluation below is of the AEM-60DC8 with firmware v1.03 against the twenty-five checklist items. The intent is honesty: the AEM-60DC8 targets IEC 62443-4-2 SL2, but the formal accredited-laboratory certificate is in planning and has not yet been issued. The Secure by Design posture refers to product architecture, not to a certification.

#	Item	Status on AEM-60DC8 v1.03
1	Unique identifiers for human users	Not directly applicable — the component has no local human users; access is via Modbus RTU authenticated at the architecture level by the IIoT gateway. The integrator implements identities on the gateway.
2	Unique identifiers for services/devices	Unique Modbus address per bus; cross-check by serial number in a dedicated register.
3	Lock after N attempts	Not applicable to Modbus RTU; mitigation via physical bus isolation and the gateway.
4	Warning banner	Not applicable (no embedded human interface).
5	Session timeout	Modbus RTU is stateless; timeout is handled by the Modbus client.
6	Minimum password policy	Not directly applicable; sensitive configuration requires a documented authenticated command.
7	Granular permissions	Separation between read registers (telemetry) and configuration registers (write-protect).
8	Separation configuration/operation	Yes, via distinct register types.
9	Block unauthorized commands	Writes to critical registers require explicit configuration-mode precondition.
10	Audit of failed use attempts	Modbus registers dedicated to events (including command authentication failure).
11	Boot-time integrity verification	Yes — bootloader verifies Ed25519 signature before every boot.
12	Cryptographic firmware signing	Yes — Ed25519, public key embedded in the bootloader.
13	Anti-rollback	Yes — minimum version persisted in non-volatile memory; attempt to install v1.02 over v1.03 fails.
14	Input validation	Validation of function code, address range, payload size in the Modbus parser.
15	Protection of confidential info at rest	No hardcoded credentials in firmware; verification public key is public by design.
16	Confidentiality in transit	Modbus RTU is unencrypted; architecture assumes a secure zone or encryption at the gateway, aligned with the zone model of IEC 62443-3-3.
17	Segmentation support	Yes — RS-485 bus isolated by physical-layer design.
18	No unnecessary ports/services	Only Modbus RTU in production; no web server, SSH, Telnet or MQTT.
19	No phone home	Yes — the component never initiates spontaneous communication.
20	Security event log	Yes — dedicated Modbus registers, kept in non-volatile memory.
21	Timestamps in logs	Internal counter; external sync via Modbus set-time command.
22	Export in consumable format	Standard Modbus read of log registers; gateway translates to Syslog when configured.
23	Operation under high load	Validated in FAT with aggressive polling (10 Hz on a three-AEM bus with no packet loss).
24	Recovery after communication failure	Recovers state within 100 ms after bus restoration.
25	Published hardening guide	Yes — hardening guide published at aem.lri.com.br/docs/hardening (architectural reference).

The evaluation shows a component that covers most items directly applicable to an SL2 embedded device (FR3, FR5, FR6, FR7 are well covered) and delegates human-identity items (FR1, FR2) to the IIoT gateway, the architecturally correct place to implement them. The "say no to bloat" stance — no web server, no TCP/IP stack, no embedded MQTT, no experimental firmware — sharply reduces attack surface and makes long-term defense in depth more sustainable.

What SL2 does not give you

SL2 is a level of defense against an opportunistic adversary. It does not cover scenarios common in the rest of the architecture. The integrator must cover the points below regardless of component level.

IIoT gateway security is the integrator's responsibility. A gateway with an outdated Linux, SSH with weak password, or a WAN interface without a firewall nullifies the gain of any SL2 component behind it. Rule of thumb: the gateway is the most exposed piece and deserves the strictest treatment.

Engineering workstation security is invisible to the component. An integrator's laptop with a signing private key or with SCADA credentials without hardware protection (TPM, smart card) is a frequent compromise vector.

Complementary software supply-chain security (Python, libmodbus, MQTT broker, configuration tools) enters via SBOM and process. SL2 components do not remove the need to monitor dependency CVEs.

Physical security of the panel — panel key, site access control, video, opening alarm — is covered by other frameworks (NBR ISO/IEC 27002, sectorial standards) and not by 62443-4-2.

Organizational security — password policy, segregation of duties, change-review process — comes from the 62443-2-1 program (cybersecurity management system), not from the technical component requirements.

Path to SL3 — when scaling up makes sense

Moving individual components from SL2 to SL3 is a risk decision, not a marketing one. The practical criterion: if compromised, does the component cause immediate physical damage? If yes, SL3 starts to make sense. If not, the additional investment in SL3 frequently competes with investments yielding higher return in defense in depth.

Examples where SL3 is justified: protection relays in HV transmission, turbine control in thermal generation, SIS (Safety Instrumented System) in chemical plants, governor systems in hydroelectric plants. For these, Part 4-2 prescribes additional requirements — multifactor authentication for critical operation, in-transit encryption even inside the secure zone, audit logs with verifiable integrity, fast incident recovery.

Examples where SL2 suffices and SL3 brings no proportional gain: DC voltage monitor in a telecom site, tank instrumentation in a water utility, capacitor-bank supervision in low-voltage distribution, read-only telemetry in discrete manufacturing. In these applications the compromise risk is primarily operational and financial, not physical safety, and SL2 covers what needs to be covered.

The decision should formally enter the risk assessment exercise of IEC 62443-3-2, which maps assets to zones, zones to target SL and target SL to component requirements. An integrator who receives a technical specification with "SL3 mandatory" on every component without distinguishing critical from secondary zones should question the customer's cybersecurity engineer — there is probably oversimplification in the requirements document.

FAQ

1. Can I build an SL2 system out of SL1 components?

In principle no, but IEC 62443-3-3 allows an SL2 system to use SL1 components provided the gap is covered by documented compensating controls (external firewall, physical isolation, additional monitoring). The real-world practice is to avoid that path because audit evidence becomes complicated.

2. Who certifies an SL2 component?

Accredited laboratories, with programs such as ISCI ISASecure CSA (Component Security Assurance) or TÜV SÜD/SGS/Bureau Veritas in some countries. The certificate is for the component at a specific firmware version. Major firmware change usually requires reassessment. A vendor that claims "SL2 compliant" without a certificate is making a self-declaration of conformity, valid but weighted differently in audit.

3. How much does SL2 certification cost?

It varies. The public range published by laboratories for ISASecure CSA was between US$ 40k and US$ 150k in 2024 depending on component complexity. Process takes six to eighteen months. Very specific components may use documented self-assessment as an interim step.

4. Can Modbus RTU be SL2?

A component whose only interface is Modbus RTU can meet SL2 provided in-transit confidentiality is not a requirement (architecture assumes a secure zone or encryption at the gateway), and the other FRs are met by the component itself. In many cases this is cleaner than more complex protocols.

5. Is SL2 enough for NIS2 or Brazilian critical-infrastructure compliance?

NIS2 (EU) and its Brazilian counterpart under construction tend to require a managerial cybersecurity program (closer to 62443-2-1) than a specific component SL. SL2 contributes meaningfully as proof of technical good faith, but regulatory compliance includes process and governance that go beyond the component.

References

• IEC 62443-1-1:2009 — Industrial communication networks — Network and system security — Part 1-1: Terminology, concepts and models.
• IEC 62443-3-2:2020 — Security risk assessment for system design.
• IEC 62443-3-3:2013 — System security requirements and security levels.
• IEC 62443-4-1:2018 — Secure product development lifecycle requirements.
• IEC 62443-4-2:2019 — Technical security requirements for IACS components.
• IEC 62443-2-1:2024 — Security program requirements for IACS asset owners.
• ISASecure CSA — Component Security Assurance Certification.
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security.
• ANSI/ISA-62443 — US version harmonized with IEC 62443.
• LRI — AEM-60DC8 Datasheet v1.03, Hardening Guide and 147 holding registers map.

---