SDA-C, FSA-C and VIT-C: what each ISASecure CSA assessment stream proves

The hub article in this series introduced the three CSA assessment streams in a paragraph each. This one goes a level deeper: for each stream, the question it answers, the evidence it consumes, who does the work and what fails it; then the five outcomes a functional requirement can receive, the rule that turns three streams into one decision, who takes it, and what does and does not end up on the certificate.

Four elements, three streams

The ISASecure scheme documents describe four evaluation elements for a component certification:

1. SDLPA-C, a check that the supplier holds a current ISASecure SDLA certificate covering the development process used for the component.
2. SDA-C, the security development artifacts for this specific component, evaluated against IEC 62443-4-1.
3. FSA-C, the functional security assessment against IEC 62443-4-2.
4. VIT-C, vulnerability identification testing.

The first is different in kind. It is not an evaluation of the product but a prerequisite check, and it gates the second: without a verified SDLA certificate the artifacts stream cannot close and the overall result cannot reach a pass. An evaluation therefore runs as three parallel streams, with the prerequisite check attached to the artifacts stream.

The three streams side by side

SDA-C: proving the process ran for this product

An SDLA certificate says an organisation's development process meets IEC 62443-4-1. It does not say that process was applied to the controller in front of the assessor. SDA-C closes that gap: it checks that the artifacts the certified process is supposed to generate actually exist for this component, at this version.

About two-thirds of the practice requirements behind SDLA, 77 of the 118, carry a component-level artifact check. Fifty of those sit in the practices that produce documents: security management, security requirements including the threat model, secure design, and the security guidelines that ship with the product. Security verification and validation testing contributes 18 of its 20 requirements, which makes testing evidence the second pillar of the review rather than a minor part of it. Defect management and security update management are almost entirely process obligations verified in the SDLA audit, with only three component-level checks between them. Penetration testing and tester independence never appear in SDA-C at all; the testing article in this series explains why.

What fails SDA-C is an artifact requirement left not met, or a prerequisite that does not check out: no SDLA certificate, one that does not cover the process used for this component, or one that has lapsed.

FSA-C: every applicable requirement, one at a time

FSA-C is the IEC 62443-4-2 stream. Component type and target security level fix the applicable requirement set, and each requirement in it is evaluated individually. Most of that is evidence review: your test results, your design documentation, a demonstration where one is needed. For the 34 requirements the scheme's evaluation workbook flags for independent testing, the lab exercises the requirement on the product itself rather than accepting your report. A subset, including some of the common component security constraints, is evaluated once per accessible network interface, and the worst result across interfaces is the one that counts.

The five outcomes

Every functional requirement ends up with one of five results:

• Met. The component provides the capability itself, where the standard expects the component to provide it directly.
• Met by component. The component provides the capability itself, where the standard would also have accepted the surrounding system providing it. No system-side conditions are attached.
• Met by integration into the system. The surrounding system delivers the capability, where the standard permits that. A pass, but a conditional one.
• Not met. The capability is not delivered in any way the standard allows for that requirement. The only result that fails the stream.
• Not relevant. The requirement has no bearing on this design, for instance because it concerns a kind of interface the component does not have.

Where the conditions live: CCSC 2

A met-by-integration result is only meaningful if someone writes down what the system has to supply. That is what CCSC 2, one of the four common component security constraints, is for: the supplier documents the compensating countermeasures the component relies on, the assessor evaluates that documentation as part of the stream, and the conditions are carried into the assessment report.

For an integrator this is the most useful part of a CSA report. A component with several met-by-integration results is not weaker than one without; it hands you a list of obligations. If your architecture cannot meet them, the certificate does not deliver the protection it describes.

VIT-C: the test the lab runs itself

VIT-C is the one place the certification lab tests the product with its own hands. It is a known-vulnerability scan, not an attack: each accessible network interface is scanned in turn, in each operating mode where an essential function is active, on the exact version submitted, with the component hardened to the supplier's own guidance and otherwise configured as a customer would deploy it. The lab runs the scan, filters false positives and only then discloses findings.

The pass threshold is a ratchet tied to the security level: at SL 1 only critical findings must be addressed, and each level up adds one severity band. Addressed means corrected, or documented as not applicable to this product with a rationale. A pass never requires zero findings; the scan is identical at every level. What fails the stream is a finding still open when it closes: neither fixed nor argued away.

The decision rule

The rule for combining three streams into one answer is deliberately blunt. A component passes when all of the following hold at once:

• all three streams are complete;
• the SDLA prerequisite has been verified;
• no artifact requirement in SDA-C is left not met;
• no functional requirement in FSA-C is left not met;
• no vulnerability finding in VIT-C is left open.

Any single not-met result or open finding means refusal; anything still pending means no decision yet. There is no scoring, no weighting between streams, and no notion of a component that mostly passed. Not relevant and met by integration do not count against the component. In practice a refusal comes from one of two places, not-met results in SDA-C or FSA-C that were never resolved, or vulnerability findings above the threshold for the target level that were left open, and both are visible to a supplier tracking its own results long before the decision.

Who decides

The person who takes the certification decision is not one of the people who evaluated the product. ISO/IEC 17065, the standard for certification bodies, requires the decision to be taken by someone not involved in the evaluation; in a CSA evaluation that means the decision-maker cannot have been the SDA-C lead, the FSA-C lead or the VIT-C engineer. The stream leads sign off the report; the decision-maker reads it and decides. As an ISASecure certification body, Perseus enforces that separation as a hard gate at issuance rather than as a policy statement.

What the certificate states, and what it does not

A CSA certificate names the component and its version, the component type, the capability security level, the standard it was certified against, IEC 62443-4-2, and the SDLA certificate that served as the prerequisite, together with the scope and any conditions attached.

It does not list the evaluated interfaces. Those sit in the accessible-interfaces section of the assessment report, alongside the per-requirement results, the CCSC 2 integration conditions and the scope of the supplier's fuzz and load testing. The certificate says a component met the bar at a stated level; the report says how, on which interfaces, and with what obligations on the surrounding system. Integrators making a design decision should ask for it.

Where to go next

The hub article puts these streams in the context of the whole scheme; the rest of the series is on the CSA filter of the Insights index.