Entrust Identity Verification for Okta: Use Case Implementation Guide

Introduction

Okta governs the moments where workforce identity risk is highest: password reset, authenticator enrollment/unenrollment, and account unlock. These moments have historically relied on knowledge-based questions, one-time codes, or a help-desk agent's judgment. All of which are vulnerable to social engineering.

Entrust Identity Verification (IDV) plugs into Okta's account management policies. When a policy rule requires verification, Okta redirects the user to an Entrust-hosted flow, where the user captures a government-issued ID and completes a biometric liveness check (a check that confirms a live person is present rather than a photo, video, or mask). Entrust then returns a VERIFIED or NOT_VERIFIED result that Okta subsequently enforces. Configuration happens entirely in the Okta and Entrust admin consoles, so no custom code or professional services are required.

This guide is written for Okta administrators who manage account management policies. It assumes the product configuration is already covered by Entrust and Okta product documentation, and focuses instead on how to apply identity verification across supported workforce journeys.

The sections that follow cover the four workforce journeys Okta's identity verification framework supports today: new hire onboarding, self-service password reset, authenticator enrollment and re-enrollment, and account unlock. Each one explains why the control matters, when Okta triggers it, how to configure the policy, and what happens when verification succeeds or fails.

Shared Context for All Use Cases

Requirements

• Okta Identity Engine is required.
• The Okta tenant must support account management policies, and Entrust must already be registered as the identity verification vendor.
• Okta user profiles must include the legal name attributes used for matching, typically firstName and lastName. If those values are missing, unmapped, or materially different from the government-issued ID, verification may fail before the user can complete the gated action.
• End users need a device with a working camera, an internet connection, and a supported government-issued photo ID available during the flow.

This guide does not repeat the full Okta or Entrust setup procedure. Use the Entrust Okta identity verification product documentation for tenant registration, client credentials, endpoint values, redirect URI configuration, and claim mapping details.

For the use cases below, the important assumption is that Okta can call Entrust during the policy step, Entrust can complete the hosted verification flow, and Okta can enforce the returned verification result.

How Enforcement Works

Okta remains the enforcement authority in every journey. When a policy rule requires identity verification:

1. Okta initiates a server-to-server request to Entrust and receives a session reference.
2. Okta redirects the user's browser to the Entrust-hosted verification experience.
3. The user captures a government-issued ID and completes a biometric liveness check.
4. Entrust returns a signed result to Okta containing an assurance outcome: VERIFIED or NOT_VERIFIED.
5. Okta's policy engine then resolves on that returned result, the outcome together with the attribute-match results, and allows or denies the requested action.

Okta never receives identity documents, biometric data, or verification artifacts. Entrust hosts the verification experience and keeps custody of the full verification record for audit based on your retention preferences.

Success behavior common to all journeys: When Entrust returns VERIFIED, the requested action proceeds immediately and Okta logs the approval with the verification timestamp. The user is returned from the Entrust flow to Okta automatically and continues where they left off, with no separate sign-in, no service-desk ticket, and no manual identity check by an agent. The Success Behavior section in each use case notes only what that journey specifically permits and where the user lands.

How often users verify: Okta documents identity verification as a requirement evaluated by the account management policy for the specific account action being performed, such as authenticator enrollment, password recovery, or account unlock. Okta's public guidance does not document a configurable identity verification validity window or reusable verification cache for these account actions. Treat each gated action as its own policy evaluation: a successful verification authorizes the action that triggered it and does not automatically satisfy a later gated action. Where two gated actions occur in sequence, the user should expect to verify for each one. Account unlock and password reset are the pair most likely to occur together, so decide during rollout whether gating both is the experience you want, or whether one of the two is sufficient for your risk profile.

The remainder of this guide is organized as implementation scenarios. Each scenario describes a specific workforce journey, the risk the control is meant to reduce, the Okta trigger that starts the flow, the policy logic to configure, and the expected behavior when Entrust returns VERIFIED or NOT_VERIFIED.

Scenario 1: New Hire Onboarding

Business Objective

Ensure that the person activating a new account is the person your organization hired. This closes the fake-hire and synthetic-identity gap: candidates who pass hiring checks using stolen or fabricated identities are stopped before they receive credentials, devices, or system access. Verification replaces manual proofing by IT or HR staff during activation.

Trigger

A newly provisioned user activates their Okta account for the first time and reaches initial authenticator enrollment, whether from an activation email, an activation link, or first sign-in. Enforcement applies before the first authenticator is bound, so the account cannot become usable until verification succeeds.

Policy Logic

• Population: New hires, typically scoped by a group (for example, "Pre-Activation Users") populated by your HR-driven provisioning flow.
• Rule: For users in the onboarding group, authenticator enrollment requires identity verification with Entrust.
• Outcome mapping: VERIFIED allows enrollment to proceed and the account becomes usable. NOT_VERIFIED blocks activation.
• Recommended scoping: Apply to all new hires rather than a risk-based subset. Onboarding is a one-time event per user, and universal coverage is what closes the infiltration vector.

Configuration Steps

1. Confirm your provisioning flow (HR system, directory sync, or manual creation) populates firstName and lastName on the Okta profile before activation. These must match the name on the government-issued ID the new hire will present.
2. Create or identify the Okta group that holds pre-activation users.
3. In the account management policy, add a rule scoped to that group requiring identity verification with Entrust for authenticator enrollment.
4. Order the rule above any general enrollment rules so it evaluates first for new hires.
5. Test with a pilot user: activate the account, confirm redirection to the Entrust flow, complete verification, and confirm enrollment succeeds.
6. Update your new hire communications so employees expect the ID capture step and have their document available on day one.

Success Behavior

VERIFIED allows authenticator enrollment to proceed. The user is returned to the Okta enrollment screen and the account becomes active once enrollment completes.

Failure Behavior

• Verification returns NOT_VERIFIED: Account activation is blocked. The user cannot enroll an authenticator or access the account. Okta logs the denial with a failure reason code.
• Recommended remediation path: Route the new hire to a defined escalation contact (typically the IT service desk or HR) for supervised re-verification or manual review. Do not create a bypass rule that skips verification for the onboarding group; a standing bypass recreates the gap this control closes.
• User abandons mid-flow: An abandoned activation does not complete and creates no partial state in Okta, so the user can simply retry. Treat repeated failures against a new hire account as a security signal rather than a routine onboarding issue.

Scenario 2: Self-Service Password Reset

Business Objective

Eliminate service-desk employee impersonation as a password reset vector. Attack groups have repeatedly breached large enterprises by phoning the help desk, impersonating an employee, and requesting a reset. Knowledge-based questions, voice recognition, and one-time codes all leave the final call to an agent's judgment, and that judgment is what the attacker is exploiting. Requiring a government-issued ID and a biometric check takes the decision out of the agent's hands. It can also negate the help desk ticket entirely, because legitimate users recover access on their own.

Trigger

A user initiates password recovery from the Okta sign-in experience, such as selecting Forgot password. Enforcement applies before Okta permits the password reset screen, so the existing password remains in effect until identity verification succeeds. That timing matters because it prevents an impersonator from using the recovery path to take control of a known account while still allowing a legitimate user to complete the reset without a service-desk identity check.

Policy Logic

• Population: All workforce users, or a scoped high-risk population if you are phasing in.
• Rule: Password recovery requires identity verification with Entrust before the reset is permitted.
• Outcome mapping: VERIFIED allows the user to set a new password. NOT_VERIFIED denies the reset.
• Recommended scoping for phased rollout: Start with privileged users, executives, and service-desk staff (the populations attackers target for impersonation), then expand to the full workforce.

Configuration Steps

1. In the account management policy, add a rule requiring identity verification with Entrust for password recovery, scoped to your target group.
2. Test the end-to-end flow: trigger a reset, complete verification, set a new password, and sign in.
3. Brief your service desk that IDV is now in the mix. Their role shifts from performing identity checks to handling escalations from failed verifications.
4. Communicate the change to end users.
5. Consider review and disable of weaker recovery factors (security questions, SMS-only recovery) for the same population to ensure verification is not undercut by a lower-assurance parallel path.

Success Behavior

VERIFIED allows the reset to proceed. The user is returned to the Okta reset screen and sets a new password. See How Enforcement Works for the logging and return behavior common to all journeys.

Failure Behavior

• Verification returns NOT_VERIFIED: The password reset is denied. The account state is unchanged; the existing password remains in effect.
• Recommended remediation path: Escalate to a supervised process, such as a video call with the service desk plus manager confirmation. Define this path before enforcement goes live so a failed verification during a real lockout has a documented next step.
• Repeated failures: May indicate an active takeover attempt against a known account.

Scenario 3: Authenticator Enrollment and Re-Enrollment (MFA Reset)

Business Objective

Protect the authenticator lifecycle. An attacker who convinces a help desk to reset multi-factor authentication (MFA) can enroll their own device and hold durable access even after a password change. Requiring identity verification before any authenticator is enrolled or re-enrolled ensures the person binding a new device or passkey to the account is the account owner. This covers new device setup, lost or replaced phones, and factor changes.

Trigger

A user enrolls a new authenticator or re-enrolls after an administrator or self-service MFA reset. Enforcement applies at the enrollment action, before Okta binds the new authenticator to the account, regardless of what caused the enrollment. That timing matters because the reset action may remove or invalidate the old factor, but access should not become durable again until the person enrolling the replacement factor has passed identity verification.

Policy Logic

• Population: All workforce users for re-enrollment. (First-time enrollment for new hires is governed by the onboarding rule in Scenario 1. Keep the two rules distinct so onboarding and steady-state behavior can be tuned independently.)
• Rule: Authenticator enrollment requires identity verification with Entrust.
• Outcome mapping: VERIFIED permits the enrollment; the new factor is bound to the account. NOT_VERIFIED blocks the enrollment; existing factors are unchanged.
• Recommended scoping: Universal for re-enrollment. Device loss is unpredictable and attackers deliberately target the reset path, so risk-based exemptions here are weaker than they appear.

Distinguishing this rule from the onboarding rule: The onboarding rule and this rule both act on the same policy condition, authenticator enrollment requiring identity verification with Entrust. Okta evaluates account management policy rules in order and applies the first rule whose conditions match, so group scope and rule order are the only things that separate first-time enrollment from re-enrollment.

Scope the onboarding rule to your pre-activation group and place it above this rule, and scope this rule to your active workforce population. If both rules cover the same users, or if this rule sits above the onboarding rule, new hires will be evaluated against the re-enrollment rule and the onboarding scoping you configured will never take effect. Confirm as well that your provisioning flow removes users from the pre-activation group once activation completes; if that membership persists, activated employees keep matching the onboarding rule.

Configuration Steps

1. In the account management policy, add a rule requiring identity verification with Entrust for authenticator enrollment, scoped to active workforce users.
2. Confirm rule ordering relative to the onboarding rule so new hires hit the onboarding rule and existing users hit this one.
3. Decide whether administrator-initiated MFA resets should also require the user to verify at re-enrollment (recommended: yes; the administrator reset clears the old factor, and verification gates the new one).
4. Test the lost-device scenario end-to-end: reset a test user's factor, attempt re-enrollment, complete verification, and confirm the new factor works.
5. Update service desk runbooks: agents no longer need to verify identity by phone.

Success Behavior

VERIFIED permits the enrollment. The user is returned to the Okta enrollment screen and the new factor is bound to the account.

Failure Behavior

• Verification returns NOT_VERIFIED: The enrollment is blocked. No new factor is bound. If the user still holds a working factor, they retain access with it; if their factor was already reset, the account remains inaccessible until verification succeeds or an escalation path is used.
• Recommended remediation path: Same supervised escalation as password reset. Because a user in this state may have no working factor, define the escalation to be reachable without Okta sign-in (a phone number or walk-up desk, not a portal behind the login).
• User abandons mid-flow: No factor is bound and no partial state is created in Okta, so the user can retry. A user whose previous factor was already reset remains locked out until verification succeeds or the escalation path is used. Because re-enrollment is a primary target for account takeover, treat repeated failures here as a security signal.

Scenario 4: Account Unlock

Business Objective

Restore access after lockout without help-desk intervention and without creating an unlock path an impersonator can exploit. Lockouts are high-stress, high-volume events; attackers exploit that urgency in social engineering calls. Identity verification lets legitimate users unlock themselves in minutes while denying the same path to anyone who cannot pass a document and biometric check.

Trigger

A user initiates self-service account unlock from the Okta sign-in experience after their account is locked, such as after too many failed sign-in attempts. Enforcement applies before Okta changes the account from locked to unlocked, so the account remains locked until identity verification succeeds. That timing matters because lockouts often happen during password guessing, credential stuffing, or user confusion, and the unlock path should restore access only to the legitimate account owner.

Policy Logic

• Population: All workforce users, or the same phased population used for password reset.
• Rule: Account unlock requires identity verification with Entrust.
• Outcome mapping: VERIFIED unlocks the account; the user signs in with existing credentials. NOT_VERIFIED leaves the account locked.
• Design note: A lockout often precedes or accompanies an attack (credential stuffing produces lockouts). Verification here does double duty: it restores the legitimate user and confirms that the person requesting the unlock is not the party who caused the lockout.

Configuration Steps

1. In the account management policy, add a rule requiring identity verification with Entrust for account unlock, scoped to your target group.
2. Confirm self-service unlock is enabled in your Okta tenant; without it, users have no unlock entry point, and every lockout becomes a service desk ticket.
3. Align lockout thresholds with this flow. If verification-gated self-service unlock is available, you can hold or tighten lockout thresholds without increasing help-desk load.
4. Test: lock a test account through failed attempts, initiate self-service unlock, complete verification, and confirm sign-in succeeds.
5. Communicate to users that lockouts are now self-recoverable and what the verification step looks like.
6. Review and consider disabling weaker unlock paths (security questions, SMS-only unlock, or agent-performed unlock without a documented identity check) for the same population, so verification is not undercut by a lower-assurance parallel path. If agents retain the ability to unlock accounts directly, log every such unlock.

Success Behavior

VERIFIED unlocks the account. The user is returned to the Okta sign-in screen and signs in with existing credentials.

Failure Behavior

• Verification returns NOT_VERIFIED: The account remains locked. No state change occurs.
• Recommended remediation path: Supervised service desk unlock with a documented secondary identity check. As with MFA re-enrollment, the escalation path must be reachable by a user who cannot sign in.
• Repeated failures: A locked account plus failed identity verification is a strong indicator of an attempted takeover.

Cross-Cutting Concerns

Deny-by-Default

There is no partial or conditional outcome at the policy layer. Anything that prevents a VERIFIED result (a failed document check, a failed biometric match, a name mismatch against the Okta profile, or an abandoned session) results in the requested action being denied and the account remaining in its prior state. No journey fails into an allowed state.

Behavior during an Entrust outage: The same rule applies when the verification service is unreachable. If Okta cannot reach Entrust, or a response is returned that it cannot process, no VERIFIED result exists, so the gated action is denied and the account stays in its prior state. Okta records the attempt with PARSING_ERROR or RESPONSE_PROCESSING_ERROR. The system fails closed, and an outage never allows an unverified user through.

Plan for this in operational readiness. A sustained outage means affected users cannot activate accounts, reset passwords, re-enroll authenticators, or unlock accounts for its duration, so the supervised escalation paths described in each use case become the only route forward. Alert on a spike in these two codes in the System Log so an outage is recognized as an availability incident rather than a wave of individual user failures. Finally, confirm your service desk can distinguish the two before you enforce in production.

Deny-by-default means a small number of legitimate users will not get through: someone whose legal name has recently changed, someone without a supported document on hand, or someone who needs an accommodation to complete a document or biometric capture. Decide before enforcement how these cases are handled, who is authorized to approve a supervised exception, and how that approval is recorded. An exception process defined in advance and logged is what makes deny-by-default workable in production; an undocumented one becomes the bypass this control was meant to remove.

Repeated failures are a security signal: A single failed verification is usually benign, caused by a poor capture, insufficient lighting, or an expired document. Repeated failed attempts against the same account are not. In every journey, route repeated failures to your security operations team rather than handling them as routine support tickets, since an account that cannot be verified by the person requesting access is the exact condition these controls exist to surface. Set a threshold during rollout, alert on it using the System Log events to make sure your service desk knows to escalate rather than let a user retry indefinitely.

Common Failure Reason Codes

When a verification-gated action is denied, Okta records a failure reason on the user.identity_verification event in the System Log, described in Support and Escalation Path. The codes below are the ones you are most likely to encounter, with their typical cause and the recommended response. See Okta's IDV vendor framework documentation for the complete list of failure reason codes.

Code	Meaning	Typical cause and response
CLAIMS_NOT_VERIFIED	Verification completed with a failed outcome	Document or biometric check did not pass. Route the user to your escalation path.
CLAIM_*_NOT_VERIFIED	A specific attribute failed to match	The name (or another required attribute) on the ID did not match the Okta profile. Check the profile for legal-name discrepancies (nicknames, recent name changes).
MISSING_*	A required attribute was absent from the request	The user's Okta profile is missing firstName or lastName, or a mapped attribute has no value. Fix the profile data; this is a configuration issue, not a user failure.
No failure code recorded	Session abandoned before the user completed verification	Okta documentation does not identify a dedicated abandoned-session or timeout failure reason code for identity verification. If the user closes the flow, loses connectivity, or never completes capture, no verification result is returned and the gated action remains denied. Identify abandoned attempts by finding user.identity_verification.start events without a corresponding user.identity_verification completion event. The user can retry; a high abandonment rate usually points to device, camera, connectivity, or instruction problems rather than fraud.
PARSING_ERROR / RESPONSE_PROCESSING_ERROR	Communication or response formatting failure between Okta and the verification service	Transient or configuration-related. Retry once; if persistent, follow the support path in Support and Escalation Path. The requested action remains denied while unresolved.

Support and Escalation Path

For user-level verification failures, route the user through your organization's documented supervised escalation path, such as the service desk, HR, or another approved identity-review process. For Okta policy configuration, System Log behavior, callback URL, or account management policy issues, open a case with Okta Support.

For Workflow Studio configuration, credentials, endpoint values, verification flow behavior, document support, biometric capture, retention, or vendor-side logs, contact Entrust Support or your Entrust representative. If the failure crosses the Okta and Entrust boundary, collect the Okta System Log events, timestamps, user ID, flow reference, and the relevant Entrust verification result or dashboard/API reference before opening cases with both vendors.

Auditing and Observability

Each verification attempt produces two events in the Okta System Log:

• user.identity_verification.start fires when the policy step triggers, with the flow and reference identifiers.
• user.identity_verification fires after policy resolution, with the allow or deny result and the failure reason code if applicable.

Both events carry IdvReferenceId and IdvFlowId properties that support teams can use to correlate a specific user's verification across Okta and Entrust. Use these events for compliance reporting, correlating verification denials with other sign-in telemetry, and feeding the repeated-failure escalation process.

Data Handling Summary

See Data Exchanged Between Okta and Entrust in the Technical Solution Overview for what is exchanged, what stays with Entrust, and how fuzzy attribute matching works.

Rollout Recommendations

1. Deploy in a sandbox or preview tenant first and validate all four journeys with test users.
2. Phase production enforcement by population: privileged and high-target users first, then general workforce.
3. Stand up escalation paths before enforcement, not after. Every journey needs a documented supervised fallback reachable by a user who cannot sign in.
4. Instrument System Log events from day one so you have a failure-rate baseline before broad rollout.

Related guides

• Identity Verification for Okta: Product guide
• Identity Verification for Okta: Technical solution overview
• Identity Verification for Okta: Reference architecture