← Home
Cybersecurity Acceptance Testing
The cybersecurity of an Automation Solution should be tested and accepted by the operating
organisation before delivery and startup. Cybersecurity acceptance testing confirms that
implemented controls match the agreed cybersecurity requirements and that the system is
sufficiently robust against known weaknesses — typically through
Cybersecurity Factory Acceptance Testing (CFAT) and
Cybersecurity Site Acceptance Testing (CSAT).
Teaching note: Paraphrased for learning from IACS cybersecurity course material
and ISA/IEC 62443 practice. Not a substitute for project procedures, contractual
acceptance criteria, or the normative text of ISA/IEC 62443.
Related:
IEC 62443-2-2 Automation Solution Security Lifecycle
|
CRS (ZCR 6)
|
IEC 62443-2-4 Service Providers
|
IEC 62443-4-1 SVV
|
System Hardening
|
Network Discovery and Scanning
|
IACS Cybersecurity Roles
Standards map
| Source |
Role for CFAT / CSAT |
| ISA/IEC 62443-2-2 Phase 4 – Verification & Validation |
Primary home — Automation Solution V&V; FAT/SAT (including cybersecurity acceptance) against the CRS |
| ISA/IEC 62443-3-2 CRS (ZCR 6) |
Input — specifications and constraints being verified |
| ISA/IEC 62443-2-4 |
Supporting — service-provider security programme capabilities that enable sound integration and V&V delivery. Programme evaluation/certification (TR/TS 62443-6-1) is not a substitute for project CFAT/CSAT |
| ISA/IEC 62443-4-1 SVV |
Related, different scope — product-supplier development testing; techniques overlap, object does not |
CFAT vs CSAT
Cybersecurity Factory Acceptance Testing (CFAT)
Performed at the factory (or integrator facility), typically by the vendor or system
integrator. Best run after functional factory testing of the system is complete, so the
security baseline is checked on a working build.
Cybersecurity Site Acceptance Testing (CSAT)
Performed onsite where the system will operate. Run after operational/site testing is
complete and before release to operations, with the system in a locked-down state ready
for production use.
Test order: Run cybersecurity acceptance testing
after the relevant functional testing (factory then site). CFAT follows
functional FAT; CSAT follows operational/site testing and precedes release to operations.
Do not schedule cyber tests before the functional build is stable — you would be validating
security on a moving target.
Validated / high-change-control sectors (for example nuclear or pharmaceutical)
often treat cybersecurity acceptance as integral to functional FAT and SAT rather than as a
fully separate campaign. Align timing with the project’s change-management and quality
system — do not invent a conflicting sequence.
Two objectives
1. Verification of cybersecurity specifications
Confirm that policies, configurations and security components work as intended. Typical
scope includes:
- Operating systems, applications and databases
- Network devices (including firewall security functions)
- IACS devices
- Antivirus / malware protection
- Detection systems (operational and able to identify and report events)
- Local and remote access controls
- Capacity concerns that affect security monitoring (for example bandwidth for expected traffic)
Use the
Cybersecurity Requirements Specification (CRS)
and hardening baselines (see
System Hardening) as the expected state.
2. Cybersecurity robustness testing
Test the design to discover weaknesses: resilience to attack, intrusion testing against
firewall configuration, and scans for known vulnerabilities. The goal is to find issues
before an external party does — under controlled, authorised conditions.
Use careful OT-safe methods; aggressive scanning can disrupt control systems. See
Network Discovery and Scanning and
prefer lab/FAT windows or scheduled outages for higher-risk techniques.
Best practices
- Use testers independent from those who designed the system (where practical).
- Define the System-Under-Test (SuT) clearly; document a repeatable process.
- Develop a verification and test plan before execution.
- Verify cybersecurity configuration settings against the CRS and approved baselines.
- Perform robustness testing (asset discovery, known-vulnerability scanning, communications/firewall checks) within authorised scope.
- Document results and feed defects into corrective action before acceptance sign-off.
Tooling (categories)
Projects commonly use:
- Configuration / baseline auditors — compare hosts and network devices to security benchmarks (for example CIS-style assessment tools)
- Vulnerability scanners — known-CVE and compliance checks (IT tools must be OT-tuned; misuse can crash control systems)
- ICS-oriented audit packs — vendor- or community-supported checks for industrial servers/workstations
- Authorised assessment platforms — only on owned systems or with explicit asset-owner approval; legal and safety constraints apply
Prefer categories and approved project toolsets over chasing product names. Check vendors
and national guidance for acceptance-testing recommendations applicable to your sector.
Key takeaways
- CFAT and CSAT accept the Automation Solution against the CRS before handover — factory then site.
- Run cyber acceptance after functional testing at each stage (not before).
- Cover both spec/config verification and robustness testing.
- Anchor in ISA/IEC 62443-2-2 Phase 4; use the CRS as the test oracle.
- Part 2-4 (and 6-1 programme evaluation) certifies provider capability — not the plant acceptance test.
- Part 4-1 SVV is product-supplier testing; do not conflate it with CFAT/CSAT.