Acceptance Checks for a Virtual VPN Gateway With MFA
Prove the gateway stage by stage: enrolment, sign-in, denial, revocation and restore, each with an artefact and a pass condition written before the test.
Vendors describe this appliance as virtual and two-factor capable, and neither word answers the questions that decide the purchase. Which hypervisor image is supported, which clients can enrol, what the second factor actually proves, and what happens when the identity provider goes down are still open. Turn those into acceptance stages you can run in a rehearsal, and the decision stops depending on how persuasive the datasheet is. The sheet below is a structure for that evidence, not a ranking of products.
What the supplier must confirm about this deployment
Start by pinning the deployment to one page: the hypervisor or cloud, the guest architecture, the supported image, and the interfaces the appliance expects. Add the users, with their operating systems, whether devices are managed, and how enrolment and sign-in are meant to work. Then the private access: applications and prefixes, DNS arrangement, return paths, and whether a public internet exit is part of the offer.
Operations belongs on the same page: who maintains the box, where updates come from, where logs go, how the configuration is protected, and what recovery objective the business actually agreed. Ask the supplier to confirm that exact combination rather than that the software runs in a virtual machine. Keep external dependencies such as an identity provider or a licensing service visible, because they are part of the deployment whether or not they ship with it. A deployment page with no named dependency is usually a deployment page with an unknown dependency.
Prove the second factor is a second factor
Name the authenticator and the verification flow, and say which identity each step establishes. Two password prompts in a row are not a second factor, and a password plus a one-time code is a different claim from a cryptographic authenticator bound to the service. Write down the flow you are buying rather than the label on the box.
Phishing resistance is a separate property, and the NIST authenticator guidance treats it as such: a code a user can be tricked into relaying still satisfies multi-factor authentication while failing that extra condition. Ask for the property explicitly if it matters to you. Then require a demonstration from the client type your users actually run, covering enrolment, a rejected or expired challenge, recovery after a lost authenticator, and revocation of one user while others stay connected. Keep gateway identity verification in scope, since a client that trusts any gateway has moved the problem rather than solved it.
Write the pass condition before you break anything
The table below is the part of the sheet that survives contact with a supplier, because every row asks for an artefact instead of an assurance. Fill the pass condition in before the rehearsal, and treat a row without evidence as a failed row. Five stages cover what a gateway has to do.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
Enrolment comes first because everything downstream depends on it: a device that cannot enrol cannot be tested. Sign-in is a separate stage from enrolment, and denial is the stage most sheets forget, since a gateway that admits everyone has not been shown to deny anyone. Revocation and restore hold most of the operational risk, and both are cheap to rehearse on a copy.
Rehearse on the copy, not the live gateway
Run the disruptive stages on a copy of the platform, following the supported deployment procedure, and keep each piece of evidence with its date and configuration version. A reboot row is not answered by a restart from the console, and a restore row is not answered by exporting the configuration. Note which state returns by itself and what has to reconnect, because that difference is what the operations team inherits. The rehearsal is also the only chance to time a restore without explaining an outage.
Record the identity provider state at the moment of each test, since an outage row tested against a healthy provider proves the opposite of what the sheet claims. Two reviewers on the same rehearsal catch different things, and the second one usually finds the row whose evidence is a screenshot of a dashboard. Keep that evidence attached to the row it belongs to, not in a folder named after the project.
Measure the workload your team will run
Settle on a workload that resembles a normal week, then measure it where you intend to deploy: concurrency, traffic mix, and the maintenance window the team actually has. An advertised throughput figure describes a lab condition and says nothing about your users. Measure the restore against the recovery objective rather than against the plan.
The sheet is finished when every stage has an artefact and every artefact has a date. An appliance somebody maintains, with evidence for each row, is a different purchase from the longest list of ticked boxes.