How to configure Okta Device Assurance without locking out users
Device Assurance is one of the most useful controls in Okta Identity Engine because it lets policy look at the device, not just the user. Used well, it keeps sensitive apps behind managed, healthy devices. Used too quickly, it creates lockouts and support tickets. The difference is rollout discipline.
What Device Assurance does
Device Assurance policies evaluate security-related device attributes as part of app sign-in policy. The exact checks depend on platform and the device signals available in your org, but the pattern is consistent: define the device posture you trust, then require that posture for access to selected apps.
This is not a replacement for MFA. It is another condition in the access decision. A user may know the password and satisfy MFA, but if the device is unmanaged, outdated, missing required protections, or not registered, the app policy can step up or deny access.
Create policies by platform and risk
In the Admin Console, go to Security, then Device Assurance Policies. Create policies that match real device populations: Windows, macOS, iOS, Android, or whatever platforms your workforce uses. Do not write one ideal policy and assume every device can satisfy it.
Start with a policy that matches your current managed baseline. If every managed laptop has disk encryption and a modern OS version, require those. If mobile management is still uneven, pilot mobile separately. The goal is to raise trust without accidentally blocking a department because one required signal was never deployed to their devices.
Attach the policy to app sign-in rules
A Device Assurance policy does not protect anything until an app sign-in policy references it. In the Admin Console, go to Security, then Authentication Policies, open App sign-in, choose the policy for the app, and add or edit a rule. The rule should require the device state and the matching Device Assurance policy for the apps that need device posture enforcement.
This is the same "available vs enforced" problem that shows up across Okta. Having a Device Assurance policy proves the org defined a standard. It does not prove any app uses that standard. The policy reference is what turns it into a control.
Pilot with one app and one group
Pick one sensitive app and one pilot group. Test with real devices from real users. Check managed and unmanaged devices, current and older OS versions, office and remote networks, browser and desktop flows, and device replacement scenarios. Document exactly what the user sees when access is denied.
Okta supports user help and remediation messaging for Device Assurance failures. Use it. A short message that tells users what to fix prevents a support queue from becoming the rollout plan.
Rollout order that usually works
First, inventory devices and confirm enrollment quality. Second, create Device Assurance policies that match the known-good baseline. Third, attach the policy to one high-risk app for a pilot group. Fourth, monitor failures and support tickets. Fifth, expand to more apps or groups after the failure reasons are understood.
For admins, set the bar higher. Admin console access should come from registered, healthy devices wherever possible. For broad workforce apps, take a slower path and avoid enforcing a device state your support team cannot help users fix.
Common mistakes
The first mistake is defining a policy but never attaching it to an app sign-in rule. The second is making the policy too strict before device management is ready. The third is applying it to every app at once, which turns one configuration mistake into an outage.
The fourth is forgetting about exceptions. Contractors, shared devices, mobile-only users, executives, and break-glass administrators need explicit handling. Exceptions should be narrow and reviewed, but pretending they do not exist usually leads to insecure emergency workarounds.
How Atomation checks it
Atomation reads Device Assurance configuration and policy usage read-only. It helps separate policies that are defined from policies that are actually used by app sign-in rules. That gives IAM and security teams a practical view: where device posture is enforced, where it is only configured, and where sensitive apps still do not check the device at all.
Device posture only helps when a policy uses it. Use Atomation to find Device Assurance gaps before a rollout or audit: demo.atomation.io.