What ISASecure CSA certification actually evaluates

If you have been asked to get a controller, a gateway, an HMI or a piece of control software "62443 certified," the scheme you are most likely looking at is ISASecure CSA, Component Security Assurance. It is the conformance scheme for individual industrial components, and the standard behind it is IEC 62443-4-2.

This article is the map: what a CSA certificate states, the three assessment streams that produce it, how many requirements are involved, and the two dials that decide how much applies to your product: component type and capability security level.

The certificate in one sentence

A CSA certificate says that a specific component, at a specific version and of one or more component types, meets the IEC 62443-4-2 requirements applicable to it at a stated capability security level, and was developed under an ISASecure-certified secure development lifecycle.

Every word in that sentence is load-bearing. The certificate names one component version, the component type or types the certifier finds applicable, and one capability security level, SL 1 through SL 4. And it depends on a second certificate, the supplier's SDLA, which covers the development process rather than the product. The evaluated network interfaces are recorded in the assessment report rather than on the certificate itself.

Three assessment streams, one decision

A CSA evaluation is not a single audit but three streams that run in parallel and converge on one independent decision.

SDA-C, security development artifacts. The supplier's SDLA certificate proves the development process is sound. SDA-C checks that the artifacts that process is supposed to produce exist for this component: the threat model, the security requirements, the design and implementation reviews, the verification records. It is evidence review against the IEC 62443-4-1 practices, scoped to the product under evaluation.

FSA-C, functional security assessment. This is the IEC 62443-4-2 stream. Each applicable requirement is evaluated for the component, and where the scheme flags a requirement for independent testing, the laboratory exercises it hands-on rather than relying on the supplier's test report. A subset of requirements is evaluated once per accessible network interface and rolled up.

VIT-C, vulnerability identification testing. The laboratory scans the component for known, published vulnerabilities on every accessible network interface, and in each operating mode where an essential function is active. The component is configured the way a customer would deploy it, hardened per the supplier's guidance, not locked down for the test. Findings are triaged by the lab before anything is disclosed.

The decision rule is simple: all three streams must complete, no functional or artifact requirement may be left not met, no vulnerability finding may be left open, and the SDLA prerequisite must be verified. The decision itself is made by a person who was not one of the stream leads, as ISO/IEC 17065 requires of a certification body.

After issuance the certificate covers the certified version and its updates for as long as the supplier holds its ISASecure SDLA certification and keeps the component in support; CSA has no surveillance audit. Upgrades need a new certification that can reuse prior evidence, with the vulnerability scan always rerun.

The 166 functional requirements

The functional stream draws on 166 requirements, organised the way IEC 62443 organises everything: by foundational requirement.

Seven foundational requirements carry the bulk of the set. Identification and authentication control, use control and system integrity together account for well over half of it. Data confidentiality, restricted data flow, timely response to events and resource availability are smaller families.

The eighth bar is the one people miss. The common component security constraints, CCSC, are four constraints that sit alongside the seven foundational requirements and apply to every component regardless of type or level. In the evaluation workbook they expand to 11 assessable rows. They get their own article in this series because they change how the certificate should be read.

Two structural facts worth knowing now. First, 117 of the 166 are base requirements and 49 are requirement enhancements, the "RE" items that add strength to a base requirement at higher security levels. Second, the identifiers tell you the scope: requirements prefixed CR are common to all component types, while the type-specific families are EDR (embedded device), HDR (host device), NDR (network device) and SAR (software application).

Four component types, four different scopes

IEC 62443-4-2 recognises four kinds of component, and the type or types the certifier finds applicable decide which requirements apply.

• A software application runs on a host it does not control, such as an engineering tool or a historian client.
• An embedded device is a purpose-built unit with its own firmware, such as a PLC, an RTU or a protective relay.
• A host device is a general-purpose computer running a dedicated control role, such as an HMI station or a server.
• A network device is infrastructure that moves or filters traffic, such as an industrial switch, a router or a firewall.

The counts differ because 63 of the 166 requirements belong to exactly one type. Network devices carry the largest type-specific family, which is why they have the largest total. Software applications carry the smallest. The applicable type is determined by the certifier against the IEC 62443-4-2 definitions; a product that genuinely spans two types is assessed against the requirements of both and the certificate lists both.

Security levels change how much is in scope

The second dial is the capability security level. CSA certifies to SL 1, 2, 3 or 4. The supplier names the highest level it is aiming for, based on the threat the component is designed to resist; the certifier then awards the highest level, up to that ceiling, that the component actually qualifies for. The requirement set is cumulative: each level includes everything from the level below.

Two patterns in that chart matter for planning. The jump from SL 1 to SL 2 is the largest single step. And the growth above SL 2 is almost entirely requirement enhancements rather than new base requirements: no enhancement applies at SL 1, and of the 23 requirements added between SL 2 and SL 3, 22 are enhancements. What SL 3 takes, and how that differs by component type, gets its own article.

What the lab tests, and what you bring

The laboratory tests the component itself in two places. In VIT-C it runs the vulnerability scan, and the pass threshold tightens with the security level: at SL 1 only critical findings must be addressed, and each level up adds one severity band. In FSA-C it independently exercises the 34 requirements the scheme flags for hands-on testing; the rest are evaluated through evidence review.

What the laboratory does not do is fuzz your protocols, flood your interfaces or penetration-test your product. Those are lifecycle activities that belong to the supplier under IEC 62443-4-1, and the lab reviews that they were done and what they covered. The scope of the supplier's fuzz and network-load testing is recorded per interface in the assessment report, with a rationale for anything left out. This division of labour has changed over the life of the scheme; the testing article in this series walks through where each test now lives.

As an ISASecure certification body, this is the split we work to on every CSA evaluation: the scan and the flagged functional tests are ours; the lifecycle testing evidence is yours.

What CSA is not

Three neighbours are easy to confuse with CSA.

• SDLA certifies your development process, not a product. It is the prerequisite for CSA, not an alternative to it.
• SSA certifies an integrated system built from components, against IEC 62443-3-3. If you deliver a solution rather than a product, that is the scheme to look at.
• ICSA certifies IIoT devices and gateways. It shares the IEC 62443-4-2 base with CSA but adds its own requirement set and is scoped by a Core or Advanced tier rather than a security level.

Where to go next

This article opens a series on CSA. The rest goes one level deeper on each topic above: the four component types, what SL 3 really costs, the CCSC constraints, the three streams individually, the testing that is yours versus the lab's, the independent-testing rule, and the evidence you will be asked for. Browse the whole set from the CSA filter on the Insights index.