IEC 62443 uses Security Levels (SL) to quantify how well an IACS can resist cyberattacks. But the standard actually defines three different flavors of Security Level — and confusing them leads to flawed assessments and miscommunication between asset owners, system integrators, and product suppliers.
The Three Security Levels
SL-C: Capability
SL-C describes what a product or system can do — its security capabilities, independent of how it's been deployed. An industrial firewall might have an SL-C of 3, meaning it's capable of enforcing controls that meet SL 3 requirements.
SL-C is a property of the component or system as built and configured. It answers the question: "What is this thing capable of?"
SL-T: Target
SL-T is the Security Level that an asset owner requires for a given zone or system, based on a risk assessment. It answers the question: "How secure does this zone need to be?"
SL-T is determined through a risk-based process (IEC 62443-3-2), considering:
- The consequences of a successful attack (safety, environmental, financial, reputational)
- The likelihood of attack given the threat landscape
- The required risk reduction
Typical SL-T values range from SL 1 (minimal protection, e.g., low-consequence production systems) to SL 3 (high protection for critical infrastructure).
SL-A: Achieved
SL-A is what you've actually achieved after designing and implementing the system. It's verified through testing and assessment. The goal is for SL-A ≥ SL-T.
SL-A answers the question: "How secure is this system in practice, right now?"
Why the Distinction Matters
| Type | Perspective | Determined by | Answers | |------|-------------|---------------|---------| | SL-C | Component/product | Supplier | What can this do? | | SL-T | Zone/system | Asset owner (risk assessment) | What do we need? | | SL-A | System as deployed | Asset owner + integrator | What have we achieved? |
The gap between SL-T and SL-A drives your remediation backlog. If SL-A < SL-T, you have a security deficit that needs to be addressed through additional controls, compensating measures, or product upgrades.
Practical Implications
When procuring industrial components, ask suppliers for their SL-C documentation. A component with SL-C 2 can potentially contribute to an SL 2 zone — but only if it's correctly configured and integrated with other controls.
When conducting risk assessments (per IEC 62443-3-2), you're setting SL-T for each zone. Be realistic: SL-T 3 everywhere is expensive and often unnecessary. Reserve higher SL-T for zones where a successful attack could cause safety incidents, major environmental harm, or critical infrastructure failure.
When validating your implementation, you're verifying SL-A. This is not a paper exercise — it requires testing against the Foundational Requirements at the target level.
The Seven Foundational Requirements
Both SL-T and SL-A are evaluated against IEC 62443's seven Foundational Requirements (FRs):
- FR 1 — Identification and Authentication Control
- FR 2 — Use Control
- FR 3 — System Integrity
- FR 4 — Data Confidentiality
- FR 5 — Restricted Data Flow
- FR 6 — Timely Response to Events
- FR 7 — Resource Availability
Each FR has requirements at each SL level. Moving from SL 1 to SL 2 to SL 3 generally means more stringent requirements, more redundancy, and more sophisticated controls.
Summary
Don't treat "Security Level" as a single thing. In any IEC 62443 conversation, clarify which type you're discussing:
- SL-C — what a product offers
- SL-T — what you need
- SL-A — what you've got
Getting this right is the foundation of a credible, defensible IACS security program.
Questions about applying IEC 62443 to your environment? Get in touch.
