Before go-live, check that default accounts are gone, authentication works as bought, logs flow to your systems, only intended ports are open, known flaws have an answer, and you can roll back. Write pass and fail criteria in advance, and do not release until each item has an owner's sign off.
What acceptance testing is for
Vendor review asks whether the product could be safe. Acceptance testing asks whether your installation is. It happens in a staging copy that matches production as closely as possible, and it ends with a go or no go.
The tests
1. Default accounts and passwords. Try documented default credentials. CISA's Secure by Demand guide asks whether manufacturers have eliminated default passwords and recommends random, instance unique passwords. If your install still has a default, it fails.
2. Authentication. Confirm that single sign on works and that multi factor authentication is enforced for administrators. The same guide asks whether standards based single sign on and multi factor authentication are offered. Test with a regular user and an administrator.
3. Authorization. Log in as a low privilege user and try to reach admin pages and other users' data.
4. Exposure. Scan the host for open ports and services and compare with the vendor's documentation. Anything open that is not documented needs an explanation.
5. Transport security. Check that the product serves encrypted connections with current settings, and that internal service traffic is not plaintext.
6. Logging. Perform sample actions: login, failed login, configuration change, data access. Verify each appears in your log system with a user and a time. Secure by Demand asks that security logs be part of the baseline product and, for hosted services, kept for at least six months at no additional charge.
7. Known flaws. Scan the installed product and its SBOM. For each serious finding, get the vendor's written answer.
8. Outbound connections. Compare observed traffic with the allowlist from your egress inventory.
9. Backup and rollback. Take a backup, restore it, and verify the restored copy. Test the rollback of an update.
10. Support access. Confirm the vendor's access path follows your remote support rules.
Pass and fail
Write criteria before testing. Examples: zero default credentials; administrators require multi factor authentication; all four sample events logged; no undocumented open ports; no unreviewed critical findings. Anything that fails gets a fix, an owner and a date, or a documented exception approved by the risk owner.
Record the result
Attach the checklist, dates, tester and outcome to the purchase record, and keep screenshots or exports as evidence.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a scan reports exposed paths and weak settings on a running web app, the sort of result checks 3 to 5 look for. Run such tests only on systems you are allowed to test.
Quick check
Should we test in production?
Test in a staging copy where possible. Run only agreed, low impact checks in production.
What if the vendor says a failed item is by design?
Ask for it in writing, document an exception with an owner and expiry, and add compensating controls.
Safeguard offers dynamic scanning and SBOM and dependency scanning that can support this step.
Sources
Last reviewed: 19 October 2026.
