I have a VPN and PKI in place with MFA. My question is: What's the best method/solution for protecting the integrity and identity of end-user certs? I want to make sure that users only able to use VPN with company provided devices.


  • 1
    You're trying to solve a people problem with tech. It will not work. The easiest way would be to tell your employees "You are only allowed to access the VPN with your company-provided devices." and most of them will do just that. Those users who don't care about company policies will also be the ones who would likely have evaded your technical solution anyways. – MechMK1 Aug 5 at 14:56
  • I agree to @MechMK1, because if your security policies are not translated correctly to your employees, they will always find a way to mess with you. A technical solution could be, If you have AD you could just check if the device is connected. – Raimonds Liepiņš Aug 5 at 15:04

What's the best method/solution for protecting the integrity and identity of end-user certs?

Install an HSM on their devices and use keys stored within it for VPN. Expensive and difficult to set up.

I want to make sure that users only able to use VPN with company provided devices.

Then instead of trying to control the keys, which is difficult, use VPN Posture Checking and disallow devices that don't match your required profile. Depending on your VPN vendor, this may include things as explicit as Domain membership - for example, here's how to do it with Check Point.


@gowenfawr's answer is correct, but I'd also like to chime in with a couple interesting ideas. Cloud providers are coming out with instances that do just what you need.



These platforms leverage HSMs to safeguard data in-memory in hardware that encrypts its data. There are several other cloud platforms that do similar but those are two I'm most aware of.


You can’t. As long as your VPN needs to be usable there is no feasible way to constrain it like that. As long as the profile or data exists on a disk that can be read and decrypted externally or in between boot stages no method will protect you.

The closest you might get is a firmware-to-OS level of MDM on company hardware, but that is basically exclusive to Google and Apple products. This is because you can get crypto outside of the storage medium and MDM in firmware; this means that reading the disk externally won’t work and booting the system using an alternate OS won’t be possible either. This then leaves bugs and exploits as the next best attack avenue.

I would go with posture checking (i.e. using osquery or some proprietary system) and MFA, preferrably hardware based (u2f or smarcard or yubikey or something like that) and limit sessions to 1. This still won’t prevent someone from sharing their laptop, token and creds, so keep that in mind.


@MechMK1 is absolutely correct. You are looking for a technical solution to a problem of policy, which is rarely something you want even if you can make it happen. I'd also think long and hard about why you feel that policy is necessary; there are a lot of bad reasons I can think of, and only a few good ones. After all, a VPN is a layer-3 solution, best suited for solving layer-3 problems.

If you are worried, for example, that your users' personal machines might have viruses that could harm other machines on your network, you're trying to solve a layer-7 problem at layer 3. The real problem is likely that you are, for some reason, more vulnerable to viruses coming from inside rather than outside your network. Presence on a network segment should not be conflated with authorization to use resources. Google gets this right; a lot of others don't.

You might also be worried that users might use compromised personal machines for work and thereby compromise confidentiality, but again that's not a layer 3 problem. Restricting VPN access to corporate-managed machines might accomplish this policy goal, but only as an accidental side-effect of the fact that you can't talk to corporate resources without it. Look no further than the many companies touting "hybrid cloud" solutions for evidence that that accident of networking is considered a problem to be solved, not a security feature.

I could go on all day, but the general point is that policy problems never map to technical solutions. It sure looks tempting, but you'll end up shooting yourself in the foot every time.

In the interests of education, however, binding a keypair to a device isn't as hard as it sounds. Your corporate devices probably have an HSM in them already in the form of a TPM, and Microsoft helpfully provides the Platform Crypto Provider and Virtual Smart Cards to make it easy to use. You can specify the PCP as the crypto provider with a command-line argument to certutil when requesting or importing certificates, which will result in a certificate that Windows handles exactly like it would a software-backed certificate except that it's TPM-backed. Or you could use the tpmvscmgr command to create a virtual smart card, with a PIN and the whole nine yards, which you can import certificates into or request certs with, and works with any software capable of using a smart card (even ones that talk directly to the card with their own crypto middleware instead of using CryptoAPI).

PCP-backed keys can be created bound to the TPM only (the default) or also to a specific set of PCRs -- you'd probably want 0, 2, 4, and 11 on machines without secure boot, and 7 and 11 on machines with secure boot, same as the bitlocker defaults. (That said, you will have to compile a utility distributed in source-code form only as part of Microsoft's TPM Platform Cypto-Provider Toolkit to bind to a specific set of PCRs. Personally, I never bother.) You can also set a password for the key when using High security with the Strong Key Protection option, which will be protected by the TPM anti-hammering logic.

Virtual Smart Cards, on the other hand, cannot be bound to a set of PCR values, but have a PIN of their own which protects all their keys and can be changed easily. (You can also create multiple VSC instances if you want different PINs for different keys.)

All that said, just marking the key as non-exportable would probably do the trick. It's not impossible to extract like the TPM keys are, but it would likely be "good enough" and it's definitely the easiest to implement.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.