The Factory Acceptance Test (FAT) and Site Acceptance Test (SAT) are the moment at which an asset owner formally accepts that a delivered system meets the requirements set. Security requirements are still too often treated as an afterthought here, whereas this is precisely the best moment to demonstrate that the intended Security Level has actually been achieved.
Why FAT/SAT is the right moment
After delivery a system is operational and changes are more expensive: every modification requires a new maintenance window and additional coordination. During FAT, at the integrator, and SAT, at the final location, it is still relatively easy to make adjustments before the system goes into production.
What to test in concrete terms
- Authentication and authorisation (FR1/FR2). Does logging in work as specified? Are default accounts disabled or changed? Do the correct role-based rights apply?
- Segmentation (FR5). Is the system actually only reachable via the intended conduits? Test this actively by trying to connect from an unauthorised segment.
- Logging and detection (FR6). Does the system generate usable logging for unexpected events, such as failed login attempts?
- Resilience (FR7). What happens when a connection is lost or a component restarts? Is critical functionality retained?
- Hardening baseline. Are unnecessary services, ports and protocols disabled in line with the previously agreed configuration baseline?
How to organise this
Include security tests as a fixed part of the FAT/SAT test plan, with the same status as functional and safety tests. Record test results as part of the handover documentation: this evidence is needed later to demonstrate that the achieved Security Level (SL-A) matches the intended level (SL-T).
Practical example
During the FAT of a new station controller, it is explicitly tested whether a connection attempt from a simulated office segment is refused, and whether the system generates a log entry after three consecutive failed login attempts. Both results are recorded in the test report that becomes part of the handover file.
Common mistake
Testing security requirements for the first time only after delivery, during a separate security assessment. Any shortcomings must then be remedied with extra cost and delay in an already operational environment.