Factory Acceptance Test is a formal test of equipment, software or a system at the supplier’s site before delivery. It checks that the build meets specified requirements and can include functional checks, configuration verification and interface testing before site installation.
What the test establishes
A Factory Acceptance Test, or FAT, is a pre-delivery checkpoint. It proves that the supplier has built the equipment, software, or integrated system to the agreed specification before it ever reaches the site.
For security and resilience purposes, FAT is valuable because it can surface defects while the system is still in a controlled environment. That is often the cheapest moment to catch functional gaps, configuration drift, interface failures, missing dependencies, or ambiguous requirements.
How a FAT is typically structured
A useful FAT usually starts from a traceable test script or acceptance checklist that maps back to the purchase specification, design documents, and contractual requirements. The point is not to “test everything,” but to verify the items that matter most to operational readiness and acceptance.
The test plan commonly covers startup and shutdown behaviour, alarm handling, interface exchanges, configuration values, data handling, and evidence that the delivered build matches what was ordered. For complex industrial or cyber-physical environments, the test often also validates that supplier hardening and documented settings are actually present on the build being shipped.
What FAT proves and what it does not
FAT demonstrates conformance at the supplier’s site, not real-world resilience in the target environment. A system can pass FAT and still fail after installation because of site-specific dependencies, network segmentation, identity integration, field wiring, or operational conditions that were not present in the factory.
That is why FAT should be treated as one stage in an acceptance chain, not the final assurance point. It reduces delivery risk, but it does not replace commissioning, site acceptance testing, production validation, or post-deployment monitoring.
Why FAT matters to delivery and assurance
In procurement-heavy environments, FAT is where acceptance evidence becomes concrete. It gives buyers a documented basis to confirm that the supplier delivered the promised build, while giving the supplier a chance to correct defects before cost, schedule, and change control become much harder.
For security-conscious organisations, FAT can also expose weak default settings, undocumented interfaces, or missing safeguards before the system is handed over. That is especially useful when the delivered item will later connect to sensitive networks, industrial control environments, or systems with strict availability requirements.
Risk and Threat Considerations
Factory Acceptance Test is a control point, but it can create false confidence if teams treat a passing result as proof that the delivered system is safe in production. The main risk is acceptance of a build that is functionally correct in the factory yet still vulnerable once exposed to real users, real networks, or operational dependencies.
Failure mechanism: Gaps appear when the factory setup does not mirror the deployed environment, when test scope is too narrow, or when supplier-built configurations are later altered during shipping, staging, or installation.
Impact: Defects, insecure defaults, or interface failures can survive into production, increasing operational disruption, rework, and the chance that security issues are discovered only after deployment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | FAT verifies delivered build-state and configuration before deployment. |
| Recommendation — Use FAT evidence to confirm secure baseline settings before accepting the asset. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | FAT checks whether the supplier build matches the specified configuration baseline. |
| CM-6 — Configuration Settings | FAT often validates required configuration values and hardening settings. | |
| SA-11 — Developer Testing and Evaluation | FAT is a formal pre-delivery testing and evaluation activity at the supplier site. | |
| Recommendation — Verify the delivered system against the approved baseline before deployment. Inspect configuration settings during FAT and record deviations for remediation. Require documented test evidence that the delivered system satisfies acceptance criteria. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | FAT is used to confirm that supplied systems are configured as agreed before release. |
| Recommendation — Validate that the delivered configuration matches the approved specification before acceptance. | ||
Practitioner Guidance
Why practitioners should care: FAT is most useful when it is tied to explicit acceptance criteria, evidence retention, and the actual operational outcomes the buyer expects. A vague pass/fail exercise often misses the settings, interfaces, and build-state details that matter most later.
Practitioner note: Treat FAT as a procurement and assurance control, not as a substitute for site validation. If the delivered system depends on configuration, external integrations, or security hardening, make sure those elements are part of the acceptance evidence rather than assumptions carried forward from the supplier’s lab.