Enforcing Device Authentication In The Era Of WFH

Device authentication is a core component of a zero trust architecture and should always be enforced in addition to strong user authentication. Learn more about implementing device authentication in this post.

When most people hear the word authentication, they think of user authentication. That is, authenticating a person via techniques like username/password, multi-factor authentication, and so on.

Of course, it is essential to authenticate the user, but it is important to remember that user authentication is just one specific type of authentication. To improve security posture, it is also necessary to authenticate the device the user is authenticating from. This is (uncreatively) known as device authentication, although it is also referred to as endpoint authentication.

With companies increasingly adopting work-from-home (WFH) and Bring Your Own Device (BYOD) policies, device authentication is more important now than ever before. Device authentication is also a core component of a zero-trust environment, so any company transitioning to ZT should prioritize the enforcement of device authentication wherever possible.

This blog post provides a brief history of device authentication, explains the attacks it prevents, and discusses some best practices to follow when incorporating device authentication into your enterprise’s cybersecurity practice.

Why Authenticate Devices?

Device authentication is central to the implementation of a zero-trust architecture— and for good reasons. When properly implemented, device authentication can provide strong protection against some common attack vectors:

  • Compromised credentials
  • Session Hijacking
  • Compromised devices


Without device authentication, an attacker could steal user credentials or a user’s session and use the stolen data on their own computer to launch attacks. Indeed, IBM’s 2020 Cost Of A Data Breach Report found that 19% of all data breaches resulted from compromised credentials. The 2020 Data Breach Investigations Report from Verizon had similar findings: “Credential theft, social attacks (i.e., phishing and business email compromise) and errors cause the majority of breaches (67% or more).”

On the other hand, when device authentication is implemented, attackers are forced to compromise a valid device, in addition to the credentials and/or session, and issue their attack from that particular device. This is more difficult (and therefore costly) to do, deterring cybercriminals from attempting the attack in the first place. An attack of this nature is also easier to detect, since the device is managed by the enterprise.

Moreover, corporate-managed devices are often more secure than personal devices, as the antivirus software is kept up to date, patches are rapidly applied, encryption is turned on, and the end user typically doesn’t have administrative rights on the device. By ensuring the end user is using a valid device (that they are permitted to use), the system is (or at least ought to be) held to a minimum set of security standards (more on this topic in a future blog post).

How Not to Authenticate a Device

Until just over a decade ago, most devices didn’t have a great way of authenticating themselves, so security engineers had to improvise. Without an easy solution available, early efforts to authenticate devices relied on the following techniques:

  • IP Address Whitelisting – IP addresses are easy to spoof, are not considered a secret, and are not always static.
  • Cookies – Mostly seen on the web, cookies can be used to store a device’s identifier. The problem is that cookies can be moved from one device to another.
  • Device X.509 Certificate – Arguably the best solution attempted, but device X.509 certificates also bring the challenge of protecting the device’s private key. With only software to protect the key, the key can be compromised with relative ease, allowing an attacker to spoof the device.


While these solutions attempted to authenticate devices within the technology constraints at the time, none of them should be considered acceptable solutions in today’s security landscape. Fortunately, a more advanced method for device authentication is now available.

Learn how a client-side hash signing architecture can accelerate digital signatures for a variety of use cases throughout your enterprise’s environment.


A Better Approach To Device Authentication

Like many cutting-edge security technologies, the best method for device authentication relies on public key cryptography. Every endpoint device generates a unique public-private key pair, then uses the private key to create digital signatures that strongly authenticate the device. Though advanced, this technique raises a new security concern: how are the private keys generated and stored?

Most modern devices come with a secure cryptoprocessor that can store secret keys. The most common form of these is a Trusted Platform Module (TPM), although other forms exist such as Apple’s T2 chip. Regardless of the type, the cryptoprocessor can be used to create a public-private key pair.

When a new device is provisioned, it uses its secure cryptoprocessor to generate a key pair where the private key is non-exportable. It then uses the corresponding public key (or a certificate issued against the public key) as its identifier. When the device needs to authenticate to a remote system, it uses its private key to respond to a challenge-response handshake (e.g., mutual TLS). Since the private key is protected by the device’s secure cryptoprocessor, an attacker cannot extract the private key and use it on a different device.

Next Steps

After a device has been authenticated, the next step should be to check the device’s health to ensure that it is still in a trusted state. Two solid approaches, that can be used independently or in tandem, are remote attestation and querying a device management system, such as Microsoft Endpoint Manager.

Once the user and device have both been strongly authenticated, the device identifier should be logged, along with every action the user takes and the corresponding timestamps. This way, should a device ever be found to be compromised, every action taken on that device can be audited to detect possible malicious activity.

If your enterprise is exploring solutions for enforcing device authentication, GaraSign may be the product you’re looking for. Compatible with all public-private key use cases, from code signing and document signing to SSH, TLS key management, and remote desktop protocol (RDP), GaraSign enables customers to seamlessly enforce device authentication with just a few clicks from a single pane of glass. Because GaraSign sits on customer-managed infrastructure between the signing clients and the centrally-managed keys, GaraSign can enforce a range of granular security controls, like MFA and device authentication, without requiring modifications to servers or adjustments to existing applications.

Get in touch with the Garantir team to request a free demo.

Share this post with your network.