Why VPN Enrollment Asks You to Visit the Office

Being asked to appear in person for a VPN account feels like a technical limitation, and it is nothing of the kind. The tunnel protocol has no opinion about where you are standing. What the visit implements is a decision about identity: someone in the organisation has to be satisfied that the person receiving the credential is the person on the record. Understanding which decision needs that assurance is what turns an argument about the journey into a solvable problem.

Three Requests That Look Alike

A new starter needs their identity established, their eligibility confirmed and their access approved, and none of those follows from a certificate request or a display name in an email. An existing user changing a password needs an approved way to authenticate the change, which is a different question again. Someone who has lost every accepted authenticator needs recovery, and that is the most dangerous of the three, because the person asking may be an impostor trying to replace the evidence that would normally stop them.

Those cases should not share one informal procedure by default. Possession of an employee number or access to an unverified mailbox is not a substitute for the check the organisation chose.

What a Visit Does and Does Not Prove

Identity proofing is a process with stages rather than a place. Guidance such as NIST's identity-proofing guidance separates resolving an identity, validating the evidence behind it, and verifying that the applicant is the person that evidence describes. Each stage can be attended or unattended, remote or on site, and the assurance depends on how all of them are performed. Skipping a stage is a decision about risk, not a shortcut through paperwork.

Standing in an office performs none of those stages by itself. A video call performs none of them by itself either, which is why a remote process is not automatically weaker and an on-site one is not automatically complete.

Trained operators, evidence handling and technical controls carry the assurance, and the location only constrains how they can be applied. A desk in an office with an untrained operator is not a strong process.

Ask for the Approved Alternative

If travel is genuinely impractical, find out from the designated owner whether an approved remote or recovery method already exists. Do not negotiate an exception with an individual administrator, because that produces a credential nobody can audit and a precedent nobody agreed to. The approved path is usually documented, even when nobody has asked for it recently.

Where an on-site step is required, find out precisely which stage it satisfies. A visit that verifies evidence is a different requirement from one that witnesses a signature, and the two have different alternatives.

Get-Certificate -Template "VPN-User" -Url ldap:///CN=CA,DC=corp,DC=internal
certutil -store -user My

Keep the Later Stages Explicit

Verification is not the end of the process. Access approval, credential binding and delivery each need their own record, and the scope of the intended device and resource should be written down rather than assumed.

Preserve the authorised recovery route too, since a user who cannot recover will find an informal one. Handle any exposed credential through its actual removal process. A completed visit or a password change does not revoke other active sessions by itself, and that gap is where most incidents continue.

The question to take back to the owner is therefore narrow: which decision needs in-person assurance, and what is the approved way to reach the same assurance when travel is impossible. That question can be answered, and a complaint about the trip cannot.