Capability

Device assurance

What it does: Only managed, healthy devices get a session - regardless of the credentials presented.

WIC

In short

Device assurance checks the state of a device before it gets a session. A device that is out of date, unencrypted or not on your list can be refused. The check applies whatever credentials the user presents.¹³

Book a call How Okta does it ↓

attack types it helps against

What it is, and the attacks it stops

A correct password and a correct MFA response prove who is signing in. They say nothing about the device - it may be unmanaged, out of date or already compromised.

Device assurance adds that second question. Admins define the device conditions they require in Okta, such as OS version, disk encryption or screen lock, and an app sign-in policy can require those conditions before access is granted.¹³

That check helps against situations such as:

Stolen credentials used from an unknown device

An attacker signs in from their own machine with a password they stole. The device is one your organization has never seen.

Outdated or unpatched devices

A laptop that missed several OS updates carries known vulnerabilities that malware can use to reach the session.

Lost or stolen devices without encryption or a screen lock

Whoever holds the device gets access to everything that is signed in on it.

Jailbroken or rooted phones

A modified phone can weaken the protections that apps depend on.

Personal devices that nobody has checked

Staff and contractors sign in from personal laptops and phones, and nobody knows what is installed on them.

Before and after rollout

Without

With

WithoutAny device with the right credentials gets a session.

WithA session depends on the device meeting the conditions you set, as well as on the credentials.¹³

WithoutOld operating systems and missing encryption go unnoticed until an incident.

WithA device assurance policy can check conditions such as OS version and disk encryption at sign-in.¹

WithoutPersonal and managed devices look the same to the sign-in.

WithPolicy rules can treat devices differently, depending on whether they pass the checks.¹³

WithoutAdmins learn about a risky device from a user report or an incident.

WithAdmins define the device conditions once in Okta, and the policy applies them at every sign-in to the covered apps.³

How Okta does it

Okta evaluates device conditions as part of the sign-in policy of an app, using information from devices that run Okta Verify.²³

The user opens a sign-in

The user signs in to an app protected by Okta.

Okta gets the device information

Okta Verify on the device reports attributes such as OS version and screen lock status.¹²

The policy compares the device with your conditions

The app's sign-in policy rule checks the device against the device assurance policy that the admin selected.¹³

The rule decides what is allowed

Depending on how the admin configured the rule, the sign-in is allowed, asks for more, or is denied.³

WIC

Who it protectsStaff, contractors, admins

Device assurance policiesAdmins define the device requirements for each platform, such as OS version, disk encryption or screen lock.¹

App sign-in policy rulesA sign-in policy rule for an app can require that a device assurance policy is met.³

Okta Verify and FastPassOn devices with Okta Verify, the app reports device health to Okta and is also the Okta FastPass authenticator.²

How Zelto implements it

Okta provides the policy engine - Zelto agrees with you which devices count as acceptable and how to bring the rest up to that level. We plan the policy in stages to minimize risk/impact. We start with the apps that matter most, and every user whose device fails a check gets a clear path to fix it.

Typical rollout

Map the devices that sign in
We list your platforms, device owners and the management tool you use today, including personal and contractor devices.
Define the baseline per platform
With your IT team we agree on the minimum for each platform, for example OS version, disk encryption and screen lock, and on who owns each requirement.
Pilot with admins and IT
We start with admins and IT. We check which of their devices fail and why, before any rule becomes mandatory.
Roll out one app and one group at a time
Each app and group gets its own sign-in policy rule in Okta. Your help desk gets a script for users whose device fails the check.
Raise the baseline and review exceptions
We raise the baseline as OS versions move on, and we review exceptions on a schedule.

Pitfalls we plan for

A user's laptop fails the device check on the day of a deadline.

−Add a permanent exception for that user, so the rule no longer applies to them.

+Show the user what to fix, set an expiry date on every exception, and review it with its owner.

Contractors and personal devices have no management tool.

−Apply the staff baseline unchanged, or leave these devices out of the policy.

+Write a separate rule with a baseline these devices can meet, and limit access to the apps the contractor needs.

The OS baseline is set to the newest version overnight.

−Require the latest version at once, so every user who has not updated is locked out.

+Set the baseline one version back, announce a date, and raise it in steps.

A device is lost, replaced or reset.

−Treat the new device like the old one and register it after a few questions on the phone.

+Register it through a recovery process that verifies the user, and make the new device pass the checks first.

Want to know which devices can reach your apps today?

We review which devices your staff sign in from. Then we tell you which conditions to require first.

Book a call30 minutes, no slides. We look at your devices and sign-in policies today.

Sources

Official Okta and Auth0 documentation and primary legal sources.

1Device assuranceOkta Help Center
2Okta Verify and Okta FastPassOkta Help Center
3About app sign-in policiesOkta Help Center