In IEC 62443, SL-T and SL-C represent different but related concepts in how you plan and implement cybersecurity for industrial control systems.
Core difference
- SL-T (Target Security Level): The security level you need for a specific zone or conduit based on risk assessment and overall system requirements.
- SL-C (Capability Security Level): The security level a specific component or product is technically able to support, as demonstrated by design, testing, and (where applicable) certification.
In practice: SL-T is defined top-down from risk and system context; SL-C is defined bottom-up from what equipment, software, and systems can actually do.
Where they come from in the IEC 62443 series
- SL-T is set during system and risk engineering activities (e.g., IEC 62443-3-2 and -3-3) when you define zones, conduits, and required protections.
- SL-C is established in the product and component context (e.g., IEC 62443-4-1 and -4-2), focusing on individual devices, applications, or systems and what they can demonstrably support.
How SL-T is determined
SL-T is driven by:
- Risk assessment for safety, quality, production continuity, IP protection, and regulatory exposure.
- Zone and conduit definition: which assets are grouped and how they communicate.
- Threat environment: expected adversary capability, motivation, and potential impact.
- Organizational policies and industry norms (for example, typical expectations for safety-critical or GxP-related systems).
SL-T is not a property of a device. It is a requirement placed on a zone or conduit that may consist of many devices, networks, and applications.
How SL-C is determined
SL-C is typically established by:
- Vendor design and documentation for a controller, PLC, gateway, MES, DCS, or network component.
- Testing and evaluation against IEC 62443-4-2 (for components) or related parts of the standard.
- Sometimes third-party evaluations or certificates that show capability up to a particular security level for specific requirement families.
SL-C is a technical capability. It does not guarantee that a deployed system actually achieves that level in your plant. That depends on configuration, integration, and operational discipline.
How SL-T and SL-C interact in real projects
In a realistic industrial deployment, you will see these patterns:
- SL-C >= SL-T: Components can meet or exceed the required target. You may still need correct configuration, hardening, and procedures to actually reach SL-T.
- SL-C < SL-T: The component is not capable of meeting the target on its own. This is common in legacy or vendor-locked systems.
When SL-C is lower than SL-T, you usually have to:
- Add compensating controls (for example, firewalls, one-way gateways, network segmentation, enhanced monitoring).
- Adjust zone boundaries so that lower capability components are isolated and protected by higher capability infrastructure.
- Apply procedural and administrative controls where technical controls are not feasible.
- Document residual risk acceptance when you cannot practically close the gap, especially in highly regulated environments.
Brownfield and regulated environment realities
In brownfield plants with long-lived assets, it is normal for existing controllers, HMIs, or legacy MES to have SL-C values that lag the SL-T you would choose on a clean sheet. Full replacement to close the gap is often not viable due to:
- Validation and qualification burden for safety, quality, and regulatory approval.
- Downtime constraints and production risk when replacing core control or execution systems.
- Integration complexity with MES, ERP, historians, QMS, and vendor-specific tools.
- Traceability and change control requirements that slow major platform changes.
As a result, many programs focus on:
- Using SL-T to prioritize zones and conduits where higher security is most critical.
- Mapping current assets to their SL-C and identifying gaps by requirement family (e.g., identification & authentication, use control, data integrity).
- Designing architectural and procedural compensating controls rather than trying to immediately replace non-compliant components.
- Maintaining traceable documentation of SL-T, SL-C, compensating controls, and residual risks for internal governance and external audits, without implying that this guarantees compliance outcomes.
How to use SL-T and SL-C in your program
For a typical industrial or manufacturing organization, a practical workflow is:
- Define zones and conduits and perform risk assessment to establish SL-T for each.
- Inventory components and determine SL-C per component or per group of similar components, using available vendor information and internal testing where needed.
- Compare SL-T vs SL-C for each zone/conduit and requirement family to identify gaps.
- Plan mitigations: architecture changes, network controls, system hardening, and procedures to help the overall zone reach its SL-T, even if individual components have limited SL-C.
- Implement under change control and document assumptions, dependencies, and known limitations as part of your cybersecurity management and quality systems.
IEC 62443 is structured so that SL-T drives what you need, and SL-C describes what you have. Effective programs manage the gap deliberately instead of assuming they will match by default.
