20% of the exam — the third-largest domain.
7 sub-topics · this deck covers sub-topic 4 of 7
↑ Module 1 OverviewSome policies from the last sub-topic checked "device state" as a condition. This sub-topic is about what that phrase actually means underneath — how a device gets an identity Okta can check at all.
Device registration binds an Okta Verify app instance to a device, creating a unique object in the Okta Universal Directory. Users set this up themselves in Okta Verify — admins cannot add devices directly from the Admin Console.
A unique cryptographic key is generated during registration and stored in a hardware-backed keystore (like a TPM or Secure Enclave) or a software-backed one, depending on the device.
Registered — Okta Verify is installed and an account exists on the device. That's it.
Managed — additionally enrolled through a device management solution, and configured in Security > Device Integrations. Managed is a strictly higher bar than Registered.
When a user hits a protected app, Okta checks several device attributes: whether Okta Verify is installed, the registration state, management enrollment, and whether secure hardware is present (TPM, Secure Enclave) along with hardware protection of the proof-of-possession key.
Watch for scenario questions built around this trap:
→ "A device has Okta Verify installed but isn't satisfying a 'managed device' policy rule." = expected — Registered ≠ Managed; managed requires device-management enrollment too.
Sources: help.okta.com — device-registration.htm
Next: Sub 5 →