Device Tags Are Not VPN Credentials: Three Claims to Separate

Hostnames, serial numbers and hidden marker files help label a laptop, and none of them proves that the laptop presenting one is the approved device. Admission rests on three separate claims: the asset is the one the organization recorded, the client possesses the credential issued for it, and that credential is protected as policy requires. Merging them into one check is how copied files and cloned keys slip through.

Three claims that get merged into one

The inventory record describes the asset and its owner. Enrollment ties an appropriate credential to that record. At connection time, the VPN verifies the proof its configured method requires. A serial number typed into an enrollment form should not automatically receive that device's authorization, because the form only proves someone knows the serial. Separate the three steps and each one can be tested on its own.

A marker file is worse than a serial number in one respect: copying it is trivial, and every copy looks equally convincing.

See what the device really presents

Look at the credential the client actually stores before assuming it is device-specific.

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, HasPrivateKey
certutil -store My <thumbprint>

The listing shows which machine certificates exist and whether a private key is present, which is the difference between a public file and a usable credential. The store dump adds the provider name, and a software provider versus a platform crypto provider is the first hint about where the key lives. A certificate without its private key authenticates nothing, while a private key exported to another machine makes the credential portable no matter what its subject says. Record the thumbprint and provider rather than the display name.

Hardware protection needs evidence

A certificate is public information, so the meaningful question is where the private key lives and whether that protection was attested. TPM key attestation describes a requester proving to a certificate authority that a key is protected by a trusted TPM, which is stronger than naming a hardware provider in a request. It is also an architecture with its own trust assumptions, not something a VPN client enables by default. Confirm what the issuer accepts and what the gateway enforces about the resulting credential, because storage, attestation and admission policy are three components.

A hardware-backed key still says nothing about patch level, current assignment or how the session is used. Those need their own controls.

Make replacement and removal concrete

Plan what happens when a device is lost, repaired, reassigned or replaced. A motherboard change or a wiped key store usually requires a supported re-enrollment rather than copying old secrets to imitate the original machine. Record the asset, credential identifier, owner, enrollment decision and access role together, so the next administrator can see what belongs to what. Remove the authorization the gateway actually accepts, because changing an inventory status proves nothing about an existing credential or session.

Then test the boundary: an approved device connects, a copied label alone does not, and a retired identity stops working. A file called approved remains a label until a trustworthy process gives it meaning.