CCSC explained: the four IEC 62443-4-2 constraints that apply to every component

Ask anyone who has worked with IEC 62443-4-2 to describe its structure and you will almost always hear the seven foundational requirements, from identification and authentication control through to resource availability. That is the axis everyone learns. The standard has a second one, and it decides how a certificate should be read.

The common component security constraints, CCSC, are four constraints that apply to every component regardless of its type or target security level. In an ISASecure CSA evaluation they are assessed alongside the functional requirements, and they carry the conditions, dependencies and process links that turn a column of "met" results into a certificate an integrator can act on. This article covers what each constraint is about, how the workbook turns four into eleven rows, and what to look for on a certificate as a result.

The second axis

Here is how the 166 functional requirements of a CSA evaluation split by family. Seven bars are the foundational requirements; the eighth is the CCSC.

Eleven of the 166 are CCSC rows: a small share of the count and a disproportionate share of the meaning, for three structural reasons. They apply at every security level, in scope at SL 1 and still in scope at SL 4. None carry requirement enhancements, which is why the 23 requirements added at SL 3 include no CCSC at all. And they apply regardless of component type, with one carve-out for embedded devices described below.

Put differently: the foundational requirements say what a component must be able to do at a given level. The constraints set the terms under which any of that counts.

From four constraints to eleven rows

IEC 62443-4-2 defines four CCSC clauses. The ISASecure evaluation workbook, the assessor's working document, splits the first into eight lettered rows, 1A through 1H, and keeps the other three as one row each. That gives eleven assessable rows, all included in the 166.

Three things deserve a second look.

The evaluation column. Rows 1A to 1E are answered once for every accessible network interface, and the worst result across interfaces is the one that carries. A component with a management port and a control-network port is evaluated twice on each of those five rows, which is why the accessible-interface list you declare at application matters as much for the CCSC as for the vulnerability scan. The remaining rows are evaluated once, for the overall product.

Row 1G. It carries no component-level requirement and applies to no component type. It exists to keep the workbook's numbering aligned with the system-level standard, and the assessor records it as needing no validation.

The embedded-device rows. Three of the eight CCSC 1 rows, 1D, 1E and 1H, apply to embedded devices only. An embedded device is therefore assessed against ten CCSC rows; a software application, host device or network device against seven.

CCSC 1: security must not break the essential function

The first constraint is about the relationship between a component's security capabilities and its essential function, the control, monitoring or protection job it exists to do. The theme is plain: adding security must not put that job at risk. A misbehaving security mechanism, an interface under a flood of traffic, or a supporting security service that disappears should not take the essential function down with it.

That is why it is a constraint rather than a functional requirement. It does not ask the component to do something new; it limits how everything else may be done. It is also why five of its rows are evaluated per interface: whether the essential function survives adverse conditions on an interface depends on what that interface is connected to and how it is exposed, so the answer belongs to the interface, not to the product in the abstract. The embedded-device rows push the same logic one step further: a device with its own firmware that physically executes a control or protection action has failure modes that a software application or a network switch does not.

CCSC 2: where "met by integration" lives

The second constraint, compensating countermeasures, is the row with the most consequence for how a certificate reads.

A component does not have to implement every applicable requirement in its own code to be certified. Where it cannot, or where the system around it is the better place, the supplier can document a compensating countermeasure: a control outside the component that achieves the intent of the requirement. With that dependency written down for the integrator, the requirement can be recorded as met through integration into the system rather than by the component alone.

CCSC 2 is what makes this legitimate. It is not an escape hatch; it is a documentation obligation. The assessor looks at whether the countermeasure genuinely covers the requirement and whether the dependency is spelled out for whoever installs the component.

The practical consequence is that every met-by-integration outcome is a condition. The component is certified on the assumption that something outside it is present, and the certificate's scope and conditions, together with the supplier's integration guidance, are where those assumptions surface.

CCSC 3: least privilege as a design property

The third constraint is least privilege: a user, a process or an interface should hold only the access it needs. In a functional requirement it shows up as a feature you can point at, an authorisation model or a role definition. As a constraint it is a property of the whole design: are default privileges as narrow as they could be, and is there a way to run the component more open than it needs to be. It is evaluated once for the overall product, at every level; what grows with the level is the use-control family built on top of it.

CCSC 4: the link to IEC 62443-4-1

The fourth constraint ties the component to its development process. IEC 62443-4-2 does not define a secure development lifecycle of its own; it points at IEC 62443-4-1 and expects the component to be developed under a conforming process.

In ISASecure terms, this is why the SDLA certificate matters to CSA. A valid SDLA certificate covering the development process used for the component is a prerequisite, and the SDA-C stream then checks that the artifacts that process should produce exist for the specific component. CCSC 4 is the requirement-level hook for both; without a verified SDLA prerequisite the CSA decision cannot reach a pass. For a supplier this reorders the timeline: process certification is upstream of the component evaluation, not parallel to it. Which lifecycle testing that process covers, and why the lab does not repeat it, is covered in where fuzzing, load testing and penetration testing actually live.

How CCSC changes the way you read a certificate

Most people read a CSA certificate for three things: the component and version, the component type, and the security level. The CCSC add a fourth reading.

• Conditions. Any functional requirement met by integration or by a compensating countermeasure, via CCSC 2, becomes a condition on the certificate. Read the scope and conditions before the level; SL 2 with several integration conditions is a different proposition from SL 2 with none.
• Interfaces. The evaluated accessible interfaces are recorded in the assessment report rather than on the certificate. Because five CCSC rows are answered per interface, the report is where you see which interfaces were in scope and how the essential-function constraint held up on each.
• Process. The SDLA prerequisite reference on the certificate is the visible end of CCSC 4. The scheme's rule that a certificate follows the component's maintenance-update stream depends on that SDLA certificate staying valid and the updates staying under the certified process.

For integrators, the conditions are your deployment requirements. For suppliers, every requirement you plan to meet through the surrounding system will become one, so write the integration guidance accordingly.

As an ISASecure certification body, we evaluate the CCSC rows in the same functional assessment stream as the foundational requirements, and the conditions that come out of CCSC 2 are carried onto the certificate.

Where to go next

If the three streams and the 166 are new to you, start with what ISASecure CSA certification actually evaluates, the map for this series. The rest of the series is on the CSA filter of the Insights index.