What Is Device Trust?

The first known security incident involving a compromised device occurred during the Bronze Age, in present-day Turkey. In that case, the Trojan guards were good men, not bad actors with malicious intent. But they made a fatal mistake when they failed to inspect the large, horse-shaped device they dragged inside the city gates.

You’d think that after 3000 years, we would’ve learned. And yet today, compromised devices are one of the greatest threats to cybersecurity. Employees routinely log into their work accounts with malware-infected devices. Even more commonly, bad actors use their own devices to access sensitive data, with the help of stolen employee credentials.

These debilitating hacks and data breaches are driving up cybersecurity insurance premiums and driving interest in potential solutions to secure end user devices. One such class of solutions is device trust.

What Does Device Trust Mean?

Device trust is the idea that a user’s device must be secure before accessing an organization’s sensitive resources (such as networks, cloud apps, and data). In this context, “users” generally means an organization’s employees, contractors, or vendors, and “devices” refers to the endpoints they use for work: laptops, desktops, and mobile devices.

We’ll go into the finer details of what makes a device trustworthy in a bit, but for now, let’s boil it down to two points.

1. A device must be known

You can’t let just any device access sensitive resources, even if its user has valid credentials. Stolen and phished employee credentials are responsible for huge numbers of hacks each year, so you need a more reliable way to associate a device with a specific user.

Making sure devices are known isn’t too difficult if you only allow access via managed devices–generally, those that are enrolled in the company’s mobile device management solution (MDM).

But many organizations also permit some degree of access on personal devices. Some companies have BYOD policies, others let third-party contractors use their own devices, some have Linux users outside the scope of MDM, and many have exceptions for workers using their personal mobile devices. In all these cases, management via MDM is either not technically possible or is considered too invasive.

Device trust solutions need to verify a device’s identity, even for unmanaged devices.

2. A device must be in a secure state

Once you’ve established that a device is known, the other half of the battle is ensuring that it meets an organization’s security requirements. These requirements ensure that a device is unlikely to be compromised and include things like:

• Operating system is up-to-date
• OS security controls (such as disk encryption, firewall, screenlock, and remote access) are configured correctly
• Additional security agents (such as antivirus) are installed and functional
• No malicious or prohibited software is installed

If a device is determined to be unsecure, it must be blocked from accessing sensitive resources. That’s why many device trust solutions are linked to user authentication; it’s the natural moment to allow or deny access.

Device trust solutions need to detect whether a device is in a secure state and restrict access to resources based on the device’s security posture.

Device trust vs Zero Trust

Many of the theorists who originally helped define the term “Zero Trust” thought that secure devices were an integral part of the paradigm. If their advice had been taken more seriously, we wouldn’t need to talk about device trust as a separate category or even sub-category of Zero Trust. But when ZTA gained popularity in recent years, most companies focused on verifying user identity and practicing role-based access control (RBAC), and devices were left out of the conversation.

Why did that happen? One reason is that device health is hard to define and even harder to enforce.

Challenges of Device Trust

Establishing device health is considerably more complex than verifying a user’s identity. In the latter case, the question is basically a binary: either someone is who they claim to be or they are not. (It gets trickier when we think about what resources they should be permitted to access based on their identity, but that’s the realm of authorization, not authentication.)

By contrast, to decide that a device is “healthy,” we have to look at a range of factors. And there’s no universally agreed-upon set of properties to determine device trust–some companies will consider you compliant if you’ve got the latest OS installed and firewall on, while others put every part of a device under the microscope.

On a political level, some companies struggle to implement device trust policies because it doesn’t neatly belong to either the IT or security team. It touches on device management (IT’s domain) but also reflects the security team’s access policies for the organization.

Another thing that differentiates device trust from traditional identity and access management (IAM) is that it requires constant updates to reflect threats that arise internally (ex: a laptop hasn’t been restarted in weeks) and externally (ex: a critical security patch needs to be installed). While a person’s identity is (more or less) stable, a device can go from compliant to noncompliant multiple times per week.

To quote Twingate’s blog:

“Device state changes constantly. To name just a few examples, a new OS security patch may be made available, a user may connect to an unsecured network, or a device may move to a new geography. Any of these events are triggers to re-evaluate device trust.”

What Are Device Trust Solutions?

Device trust solutions can operate as either standalone products or as part of existing security solutions. But to qualify as “device trust,” it’s not enough to simply detect problems: a solution must have some mechanism for restricting access to devices that don’t meet security standards.

Some IAM vendors check device properties in addition to handling user authentication. For example, Okta has Okta Device Trust, a suite of client-based and SAML-based solutions for managed devices, and they also offer “device assurance” as part of their Okta Verify product for unmanaged (or lightly managed) devices. (However, it should be noted that these features offer limited telemetry, such as OS version and disk encryption status.)

Other companies focus exclusively on device trust. Kolide recently became one of those companies, and our example can be useful in defining device trust. Kolide has always been an endpoint security solution that detected problems and guided end users to fix them. However, we weren’t in the “device trust” space until we added an enforcement mechanism: stopping users from authenticating via SSO unless the device is secure.

This change also ensures that only known devices can authenticate, because the presence of Kolide’s agent acts as an additional authentication factor. So a device without Kolide can’t log in, even if it has a user’s password, Yubikey, or fingerprint.

What Makes A Device Healthy?

As we’ve said, there’s no universal standard for device trust. Some device trust/device health solutions only look at a handful of properties, while others analyze device posture based on hundreds of factors.

Let’s start with the most widely agreed-upon issues, then work our way down to those that get less attention.

Updated OS

An up-to-date OS is considered table stakes for device trust since updates often contain critical security patches. This one is also not much of a technical challenge since any device trust product can compare the device’s state to a single, simple source of truth (Apple, Windows, etc).

OS updates are also a particularly potent use case for device trust solutions since organizations struggle to get them deployed via MDM. (We’ve written about this in much more detail elsewhere, but basically: updates require users to restart their devices, which users are reluctant to do unless there are consequences.)

Baseline device security settings

Most device posture checks look for at least some of the following:

• Firewall is on
• Screen lock is on
• Disk is encrypted
• Device has been restarted recently
• System Integrity Protection is configured correctly (for Macs)
• Remote access is turned off

These all relate to the device’s settings and first-party software.

Advanced device trust properties

This is where we start to see real differentiation between device trust products. Many device trust solutions don’t look at the following properties at all:

• Browser is up-to-date
• Antivirus and malware blockers are running
• Device is enrolled in MDM
• Malicious browser extensions are blocked
• No unencrypted credentials (like SSH keys or MFA backup codes) are present
• No sensitive files are present
• Ubuntu Unattended Upgrades are on (for Linux)

These are not standardized properties where we can rely on a single source of first-party data. Getting visibility into this data requires a high degree of customizability and the ability to query not just the device, but individual applications. Looking for sensitive files on a hard drive, for example, means you have to know what files or file types you’re looking for, and the answer will be different at every organization.

How Kolide Does Device Trust

Since you’re reading an article about device trust and Kolide is a device trust company, we’d be remiss if we didn’t conclude by talking about ourselves a little.

Specifically, let’s touch on three things that form the core of our identity.

Kolide’s agent monitors a huge range of device properties

At Kolide, we look at all the properties mentioned above, plus many more. (We have a library of 100 checks and counting (you can look at a sampler here.)

We also offer IT and security teams the ability to write their own custom checks. That’s a crucial feature since every organization has a unique tech stack and set of priorities.

Kolide can provide a more granular look at devices than many other “device health” features thanks to our osquery-based agent, which can draw on various data sources, instead of just the settings you’d find in System Preferences.

Kolide works on all major platforms

The vast majority of device trust solutions focus on a single platform, but–again, thanks to osquery’s versatility–Kolide works on macOS, Windows, and Linux. (We also have a non-osquery version of our product for iOS and Android devices.)

Kolide works with end users

As you might have guessed, any product that locks users out of their company’s resources has the potential to be unpopular and disruptive. But at Kolide, our founding principle is Honest Security, and we make it a point to give users maximal agency and transparency.

We’ve established that all device trust products need some blocking mechanism that keeps users from accessing resources if their device isn’t secure. Some products stop at the blocking stage; they tell the user they’re blocked (but not why) and send them off to IT. That’s not a great outcome for users (who can’t do their jobs) or IT (who will face an avalanche of support tickets).

Kolide, by contrast, gives users simple, non-technical instructions so they can unblock themselves.

Also, Kolide doesn’t wait until users are authenticating to inform them of blocking issues–we inform them ahead of time, so they can get ahead of the problem. (And if they forget to fix an issue but urgently need to log in, we have a snooze button that can give them temporary access.)

There’s an insidious idea that any improvement to security must come with a corresponding cost to user privacy or quality of life. Still, Kolide shows that it is possible to practice device trust without making users feel untrusted.

Watch our on-demand demo to see what Kolide’s device trust solution looks like in action!