Two password prompts are not MFA: what a VPN login verifies

The login page asks for a password, then for a second secret, and the deployment gets described as multifactor. Sometimes it is. Often it is a single factor collected twice, because both values are knowledge the same person typed from the same memory or the same note. A strong tunnel cipher does not change that, and neither does the word "secure" anywhere in the product name.

Separating the claim from the mechanism takes one question: what does each step prove, and to whom?

A factor is a proof, not a field

Multifactor authentication means more than one distinct kind of evidence is verified for the same account: something the user knows, something they hold, something they are. Two fields that both collect a remembered string are one kind of evidence asked twice. That can be a useful control, since two independent secrets are harder to guess than one, but it is not what the term describes and it should not be counted as such in a risk assessment.

The verification side matters as much as the collection side. A code generated on a device proves control of that device only if the server checks it against a secret bound to this account and rejects replays. A shared code that works for everyone, a code with no rate limit, or a prompt approved on a device that never displays what is being approved are all weaker than the label suggests.

So when somebody asks whether the VPN has MFA, ask what the second step proves and how the server binds it. If the answer is "a second password from the same directory", you have one factor and a policy conversation, not a second factor.

The certificate case needs reading, not assuming

A client certificate plus a password looks like two factors, and it can be: the certificate is held in a store or on a token, and the password is remembered. It can also be one, if the certificate file sits unprotected in the same profile directory as the saved password, or if the certificate was issued to a device that several people share without individual accountability.

The question to settle is who or what the certificate identifies. A device certificate proves a managed machine is present. A user certificate proves an identity. If the deployment issues one certificate per laptop and then treats its presence as proof of the person, the second factor has quietly become a property of hardware that anyone holding the laptop inherits.

None of that makes certificates a bad idea. It makes the distinction between device assurance and user assurance worth writing down, because the two answer different questions and a compliance spreadsheet that counts them as one will overstate what is protected.

Gateway trust and user trust are separate problems

A second factor does not make it safe to type credentials into an endpoint you have not verified. The client has to recognise the intended gateway, which is what the server certificate and the client's trust configuration are for. Phishing works by moving the login to a server the attacker controls, and a correct OTP entered there is simply relayed to the real service in real time.

That is why method choice changes the outcome more than prompt wording does. Codes typed by a person can be relayed by anyone who can present a convincing page, while cryptographic methods that bind the authentication to the specific origin and session resist that relay by design. Which of those you have is a property of the method, not of the number of steps in the dialog.

Follow the vendor's supported enrolment and client flow rather than bolting an extra prompt onto a password field. A home-made second step usually lands somewhere between the two, adding friction without the binding that makes the factor meaningful.

Recovery is the second front door

Every strong login has a way back in when the authenticator is lost, and that path is where the design is usually weakest. If a support agent can reset the second factor after a phone call to a number on file, the attacker's cheapest route is the help desk, not the login page.

Ask how replacement works, who approves it, and what evidence they require. Then check that recovery material such as backup codes is stored separately from the primary credential, so one compromise does not hand over both. NIST's digital identity guidance treats verifier binding and authenticator lifecycle as part of the requirement rather than an operational afterthought.

What to write in the assessment

Describe the factors by kind, name what each one proves, and state how it is bound to the account. Note whether the method resists relay, and describe the recovery path with the same care as the login.

Then say plainly whether the deployment is multifactor by that definition. "Two passwords and a machine certificate" is an honest sentence, and it tells a reader far more than a checkbox that says yes.