Back to Blog
June 2, 20263 min readsecurity

Device Trust: What Actually Works

What a successful device trust rollout actually looks like from the inside.

device-trustzero-trustmdmidentityokta

Device Trust: What Actually Works

I've talked to practitioners who think device trust is a flip of a switch and everything is secure. I'd like to think it's that easy too, but if you want your initial rollout to actually stick, you need to bring the data before any switches get flipped. Here's the order of operations that worked for me.

Visibility First

If you can't tell managed from unmanaged, laptop from mobile, that's your first problem. We silently pushed Okta's Device Trust Cert to endpoints via our MDM. That gave us what we needed to understand what is happening at the auth level. This level of visualization gave us A clear line between managed and unmanaged devices hitting our IDP.

Get the Data

Now that you have visibility, figure out who's accessing what and from where. I use a SIEM to create a dashboard to visualize the data. I tracked device type, which critical apps are being hit from unmanaged devices, and access patterns by device status. Don't rush this part. Let it collect. Everything that comes next depends on what you find here.

Rate Your Apps

This is where most people skip ahead and regret it. Not every app carries the same risk and not every user has the same access needs. Does calendar and mail access on a personal device stay open? What about third parties who may not be provided a managed device? You have to answer those questions before you build policy, not after.

  • Critical / High — Registered + Managed: AWS, databases, financial tooling
  • Medium — Registered Only: Apps that need mobile or third party access
  • Low — Unmanaged OK: Low-sensitivity tools, bookmarks, lunch ordering systems
  • Note: Medium tier devices are registered with the IdP through a local agent but do not require full MDM enrollment.

    Test, Test, Test

    Test your policies before anything goes live. Try every permutation you can think of. Be the end user. Managed laptop, unmanaged laptop, mobile, third party, etc . Find every way an end user might interact with the new policies. Did the cert install correctly? Does the local agent need updating? What is the process for a new hire who doesn't have a device yet? The more scenarios you work through before deployment, the less you're triaging after.

    Find Your Number

    Before we touched any authentication policies, roughly 80% of authentications were already coming from managed devices. That told us enforcement would affect a smaller slice of the user base than people feared. It also changed how we communicated the rollout. Instead of "we're locking things down" it became "most of you won't notice a thing." Let the data speak for itself when proposing the change.

    Expect the Pushback

    Someone will lose convenience and get loud about it. Its bound to happen. One person framed a security control as an attack on their ability to do their job. Those conversations are uncomfortable for a minute. Then the noise stops, people adapt, and it becomes the new normal. You're trading the convenience of a few for the security of the many. Security incidents happen every day. That's a reasonable trade.

    Flip the Switch

    You did the work. Visibility, data driven analysis, risk scoring, testing. Now you have something most people skip straight to on day one. A data driven rollout that you can defend, triage, and build on. That's how you move the needle on security posture.