Where fuzzing, load testing and penetration testing actually live in ISASecure CSA

Ask ten suppliers preparing for ISASecure CSA what the lab will do to their product and most will say some version of "hack it." Fuzz the protocols, flood the ports, try to break in. It is a reasonable expectation. It is also wrong, and getting it wrong costs time in two directions: suppliers who under-prepare their own testing evidence because they assume the lab will do it, and suppliers who over-prepare for a lab attack that never comes.

This article lays out who performs each kind of security test in a CSA evaluation, what the lab does instead of the tests it does not run, and what you should have ready.

A short history explains the confusion

The expectation is not baseless. Earlier generations of the ISASecure component scheme did include certifier-run communication robustness testing: the lab itself sent malformed and excessive traffic at the device and graded how it held up. That element was withdrawn. The robustness-testing specifications it relied on were superseded, and the scheme's own report template dropped the corresponding results section.

What replaced it is a division of labour. Robustness testing moved to the supplier, as part of the secure development lifecycle that IEC 62443-4-1 defines and that the SDLA scheme certifies. The lab's own hands-on work narrowed to two things it is uniquely positioned to do independently: scan the product for known vulnerabilities, and verify a defined subset of the functional requirements directly. And a new reporting obligation was added so that the scope of the supplier's robustness testing is visible in the assessment report rather than assumed.

If you last looked at the scheme several years ago, that is the change you missed.

Who does what

Two rows in that table surprise people. Fuzz and load testing are yours, and the lab's job is to check that you did them and how far they reached. Penetration testing is also yours, and it is not even evaluated at the product level: it is a requirement on your development process, examined when your SDLA certification is audited.

What the lab does test

The vulnerability identification scan. The lab scans the component for known, published vulnerabilities. Every accessible network interface is scanned, one at a time, and an embedded device is scanned in each operating mode where an essential function is active. The component is set up the way a customer would deploy it, hardened according to your own published hardening guidance, with services running and ports open unless that guidance says otherwise. This matters: you cannot pass the scan by shipping a locked-down test unit.

The pass threshold is a ratchet tied to the target security level. At SL 1 only critical findings must be addressed; each level up adds one severity band.

"Addressed" means corrected, or documented with a rationale for why the finding is not relevant to the product. A pass does not require zero findings. The scan itself is identical at every level; only the acceptance filter moves. The lab triages the raw results and filters false positives before anything is disclosed to you.

What the scan is not: it is not an attack. It does not send malformed packets, it does not flood, it does not attempt exploitation. It answers one question, whether the product ships with known weaknesses that an outsider could find at the target level, and that question is deliberately separate from whether the product survives abuse.

Hands-on verification of flagged requirements. Of the 166 functional requirements in the CSA evaluation, 34 are flagged in the scheme's evaluation workbook as requiring validation by independent test. For those, the lab exercises the requirement on the product itself rather than relying on your test report. For the remaining requirements, the assessment is evidence review: your test results, design documentation and demonstrations, evaluated by the assessor. Which requirements carry the flag, and what "independent" means in practice, is the subject of its own article in this series.

What the lab reviews instead of running

For fuzz and network-load testing, the assessment report contains a dedicated section that records, interface by interface, whether fuzz testing was performed, whether load testing was performed, and the rationale for any interface or protocol that was not covered. The assessor fills it from your evidence. A gap is acceptable; an unexplained gap is not.

That section is the practical replacement for the withdrawn certifier-run robustness testing. The scheme no longer asks the lab to prove your device survives malformed traffic. It asks you to prove it, and it asks the lab to make the boundaries of that proof explicit in the report so that a reader knows exactly what was and was not exercised.

The same logic applies across the verification practice. Your requirements testing, your abuse-case testing, your attack-surface analysis and your own known-vulnerability testing are evaluated as development artifacts for this specific component. The lab is checking that the process your SDLA certificate vouches for actually ran, and produced results, for the product in front of it.

Penetration testing sits one step further out. It is a requirement on the development process, and the CSA product evaluation does not carry a component-level check for it. It is verified when your development process is audited under SDLA. If your pen-test records are thin, that will surface in the SDLA audit, not in CSA.

Why the scheme is built this way

The design is not an accident and it is not the lab being lazy. Three reasons hold it together.

First, the process certificate does the heavy lifting. SDLA certifies that your lifecycle performs these tests as a matter of routine, with the independence the standard requires of the testers. Re-running them in the lab would duplicate an assurance you have already earned, on one product, once.

Second, the lab's own testing is reserved for what has to be independent and current. A vulnerability scan is only meaningful if it is run by someone other than the supplier, against a current vulnerability feed, on the exact version being certified. That is the one place where supplier evidence cannot substitute for the lab doing the work.

Third, scope visibility is worth more than a single lab result. A fuzz campaign is only as good as its coverage. Recording per interface and protocol what was tested tells a reader far more than a pass mark from one lab session would.

What to prepare

• A coverage matrix. For every accessible interface and every protocol on it: fuzz tested or not, load tested or not, and a one-line rationale for each "not." This maps directly onto the report section and is the single most useful document you can bring.
• The fuzz and load test reports themselves, as artifacts of your verification practice, tied to the component version under evaluation.
• Your accessible-interface and protocol list. It defines the scan set for the lab and the rows of your coverage matrix. Keep the two consistent.
• Your hardening guidance, because the lab configures the scan target from it.
• Penetration-test records, filed with your SDLA evidence, not your CSA evidence.

Prepared that way, the two tests the lab runs are the only surprises left, and the vulnerability scan is one you can rehearse yourself with the same tooling before the evaluation begins.