Entrust Identity Verification for Okta: Reference Architecture

Introduction

This document describes the reference architecture for the Entrust Identity Verification (IDV) integration with Okta. It explains the components involved, the end-to-end verification flow, what the integration adds to an existing Okta environment, and where responsibility boundaries sit between Okta and Entrust.

This document is a companion to the Entrust IDV for Okta Technical Solution Overview and focuses on how the integration fits into the environment you already operate.

Audience and Scope

This document is for enterprise architects, identity architects, and security engineers who are evaluating or deploying Entrust Identity Verification within an existing Okta workforce environment.

The architecture described here covers Okta-supported account management flows only: password recovery, account unlock, authenticator enrollment, and authenticator unenrollment. Okta invokes identity verification by policy during these actions. Routine sign-in is not part of this integration.

Reference Architecture

At a high level, Okta determines when identity verification is required, redirects the user to Entrust to complete verification, and then uses the returned outcome to continue or stop the account management action. Entrust performs the proofing step, while Okta retains control of policy, enforcement, and the user's account state.

The architecture has four zones, shown left to right in the diagram:

1. User. An employee or contractor initiates a supported account management action in Okta from a desktop or mobile browser.
2. Okta Identity Platform. Okta Identity Engine orchestrates the account management journey and holds the policy and vendor configuration that govern verification.
3. Entrust IDV. Entrust hosts the verification experience, evaluates the submitted identity evidence, and returns the verification outcome to Okta.
4. Okta-managed outcome. Okta remains the sole enforcement authority: it completes or stops the action, and Entrust never modifies Okta objects or completes actions on Okta's behalf.

Component Responsibilities

The sections below separate platform orchestration, customer configuration, Entrust verification services, and final enforcement so that ownership is clear before the detailed protocol flow.

Deployment Topology

The integration is SaaS-to-SaaS. Both platforms operate as multi-tenant cloud services, and no integration component is hosted in the customer environment. The only customer-side participants are the user's browser and the Okta Admin Console configuration.

Each verification is an independent, stateless transaction initiated by an Okta policy decision. Verification load scales with the account management events your policies gate, not with signin volume. Adding users, groups, or actions to policy scope does not require an architectural change.

End-to-End Verification Flow

See How It Works in the Technical Solution Overview for the full OIDC/PAR/PKCE step-by-step flow.

What Changes in Your Okta Environment

Failure behavior is intentionally closed. If the user does not complete verification, Entrust cannot return a valid outcome, or Okta cannot validate the returned token, Okta does not complete the requested account management action.

The integration is additive and configuration-only. Deploying it introduces the following changes:

• A new identity verification vendor configuration in the Okta Admin Console, populated with Entrust-supplied values (client credentials, issuer, authorization, token, and JWKS endpoints).
• Account management policy rules that reference identity verification for the actions and user populations you select. Existing policy rules that do not reference verification are unaffected.
• System Log events related to verification requests and outcomes, available to your existing log streaming and security monitoring pipelines.

Customers should monitor Okta System Log events related to verification requests, outcomes, and interrupted flows. Exact event names should be confirmed against the Entrust IDV for Okta Technical Solution Overview and the customer's Okta tenant before production rollout. These events can be routed to existing SIEM, alerting, and case management tools through the customer's current Okta log streaming configuration.

The integration does not introduce:

• Agents, connectors, or software deployed in your network
• Changes to Okta Universal Directory schema or user attributes
• Required changes to your existing sign-in policies, session policies, or already-enrolled authenticators
• Inbound firewall rules; all communication is outbound over HTTPS

Multi-factor authentication. Identity verification complements your existing authenticators; it does not replace them. Verification proves who the person is at high-risk moments such as recovery and enrollment, while authenticators prove possession and continue to govern routine sign-in.

Onboarding and HR-driven provisioning. Provisioning from your human resources system into Okta is unchanged. Verification can attach to Okta-managed enrollment and activation steps in your onboarding flow, so a new hire proves their identity before establishing credentials.

Help desk and recovery processes. Verification inserts an identity-proofing step into the self-service recovery paths that Okta already provides. Help desk-assisted recovery is outside this architecture and continues to operate under the processes you use today.

Scoped rollout. Enforcement is driven by the account management policy, so verification scope is a policy decision. For initial deployment, customers can apply verification to a limited set of groups, actions, or pilot users, then expand coverage after security, identity, and help desk teams validate the user experience and support process.

Standards Alignment

See Where Entrust fits in the Technical Solution Overview for how this architecture aligns with NIST Special Publication 800-63 identity proofing and assurance levels.

Prerequisites and Network Requirements

• Okta Identity Engine. Okta Classic Engine environments are not supported.
• Okta administrator access sufficient to configure identity verification vendors and account management policies.
• An Entrust IDV tenant with a configured verification workflow and the integration values supplied by Entrust.
• End-user access from a desktop or mobile browser; no application installation is required.
• Outbound HTTPS (port 443) from user browsers to the Entrust-supplied verification and authorization domains. If your organization restricts egress or operates TLS inspection, allowlist the domains supplied by Entrust. The server-to-server calls in the flow occur between the Okta cloud and the Entrust cloud and require no customer network configuration.

Entrust IDV services are available in the AMER and EMEA regions. For details on regional processing, data residency, and availability assumptions, see the Entrust IDV for Okta Technical Solution Overview.

During operation, Okta remains the system of record for account management actions and policy enforcement, while Entrust remains responsible for the verification experience and proofing decision. Support teams should use Okta logs to determine whether verification was required and completed, and Entrust verification records to investigate proofing-specific outcomes.

Data Flow and Custody Boundaries

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

Out of Scope

The following are outside the scope of this architecture:

• Consumer identity and access management (CIAM) use cases
• Okta Privileged Access workflows
• Automated matching of verified identity attributes into Okta Universal Directory
• Continuous risk signaling between Entrust and Okta

Related guides

• Identity Verification for Okta: Product guide
• Identity Verification for Okta: Technical solution overview
• Identity Verification for Okta: Use case implementation guide