Okta: Integration Guide | Vanta Help Center

Overview

If your team uses Okta to manage employee access, this integration brings that identity data into Vanta automatically. Your team keeps working in Okta. Vanta handles the rest (evidence collection, access reviews, and compliance monitoring) using the user directory, group memberships, roles, MFA enrollment, application assignments, and password policies it reads directly from your org.

Want the fastest way to get started? Go to the Okta: Quickstart.

What you can do with this integration

Automatically verify that terminated employees have had their Okta accounts deactivated.
Track whether users have enrolled in MFA and which factor types they are using.
Confirm all Okta accounts are linked to Vanta personnel records.
Surface users, groups, roles, and applications in access review workflows.
Request and manage access to Okta entitlements through Vanta's Access Requests workflow.
Use Okta password policies as audit evidence for SOC 2, ISO 27001, and similar frameworks.

Three separate Okta integrations, one Okta tenant

We support three distinct Okta integrations, each configured independently:

Integration	What it does	Okta-side setup
Okta API (this guide)	Syncs users, groups, roles, apps, and policies into Vanta for monitoring and reviews	Okta API Services app
Okta SSO (this guide)	Lets users log in to Vanta via Okta	Vanta SAML app (from Okta's catalog)
Okta SCIM	Provisions and deprovisions users and groups from Okta into Vanta	SCIM 2.0 app (or the Vanta SAML app, with limitations)

Setting up one does not configure the others. If login works but groups are missing, or if users are provisioning but roles don't surface, the cause is almost always that only one of the three integrations has been configured.

Connection details

Detail	Value
Connection type	OAuth 2.0 with private key (default) — JWT client assertion signed with a private key, exchanged at /oauth2/v1/token. API Token (SSWS) is also supported as an alternate auth method. Use API Token authentication only if your environment restricts OAuth app creation or if you're connecting a legacy instance. For all new connections, use OAuth with private key.
Access level	Read-only. Vanta makes no writes to Okta. Curious what data Vanta reads from Okta? See the What Vanta collects and why section.
Who should connect	An Okta Super Administrator. This role is required to create the API app and to assign the Super Administrator role to the app.
Multiple Vanta Workspaces	A single Okta API app can connect to all of your Vanta Workspaces. You do not need to create a separate app per Workspace.

What Vanta collects and why

This section covers the data Vanta reads from Okta and why each field is collected. For how this data powers specific Vanta workflows, see Use cases and capabilities.

Scope — what Vanta monitors

By default, Vanta reads all users in your Okta org, their factor enrollments, their role assignments, all applications, and the users assigned to those applications. Password policies configured in Okta are also collected.

ℹ️ Scoping note: If IdP scoping is enabled, Vanta only monitors users assigned to the Vanta SAML app in Okta. See Controlling Scope Through Okta.

Users

Data point	What Vanta collects	Why it's collected
User ID	Unique Okta user identifier	Matches users across workflows and prevents duplicates
Email (login)	Primary account email	Links the user to Vanta personnel records
First name, last name, display name	Name fields from the profile	Populates personnel records
Title	Job title from profile	Populates personnel profiles
Employee number	From profile (if set)	Supports HRIS-to-IdP matching
Account status	Current status (active, suspended, deactivated)	Drives deactivation tests and personnel lifecycle
Activation time	Timestamp	Populates personnel records
Last login time	Timestamp of most recent login	Surfaces in access reviews
Creation time	When the account was created	Populates personnel records
MFA enrollment	Whether MFA is enabled on the account	Powers the MFA compliance test

MFA factors (per user)

Data point	What Vanta collects	Why it's collected
Factor ID	Unique identifier	Deduplicates factors
Factor type	e.g., Okta Verify, WebAuthn, SMS	Surfaces which factors users have enrolled
Status	Active or pending	Confirms the factor is actually enrolled, not just provisioned

Admin roles (per user)

Data point	What Vanta collects	Why it's collected
Role ID	Unique identifier	Deduplicates roles
Role label and type	e.g., SUPER_ADMIN, READ_ONLY_ADMIN	Surfaces privileged access
Status	Role status	Confirms the role is active
Assignment type	Direct or via group	Shows how the role was granted
Created, last updated	Timestamps	Supports access review timelines
Description	Role description	Human-readable context

Groups

Data point	What Vanta collects	Why it's collected
Group ID	Unique identifier	Deduplication and scoping
Group name	Display name	Identifies the group in Vanta workflows
Member list	User IDs of members	Powers group-based access reviews and IdP group imports

ℹ️ Note on Groups and the API integration: The Okta API integration pulls group metadata, but groups do not automatically populate into Vanta's People > Groups view. To surface Okta groups as Personnel Groups, import them via Dynamic IdP Groups for Okta. Alternatively, Okta SCIM with Push Groups creates Teams, which serve a different purpose.

Applications (vendors)

Data point	What Vanta collects	Why it's collected
App ID	Unique identifier	Deduplicates vendors
Label, name	Display name and internal name	Identifies the vendor
Sign-on mode	How users authenticate to the app	Context for vendor review
Creation time, last updated	Timestamps	Supports vendor lifecycle
Assigned users	User IDs with access	Maps vendors to users for review
Assigned groups	Groups with access	Maps vendors to groups

Password policies

Data point	What Vanta collects	Why it's collected
Policy ID, name	Identifier and display name	Identifies the policy in Vanta
Max password age	Expiration setting	Audit evidence
Minimum password length	Length requirement	Audit evidence
Character requirements (lowercase, uppercase, numbers, symbols)	Complexity rules	Audit evidence
Password reuse rules	Reuse restrictions	Audit evidence

See Tracking Password Settings for Okta for how to attach these policies to vendors for audit evidence.

Authentication policies (access policies)

✅ Feature availability: Authentication policy data is being rolled out progressively. If you do not see this data in your account, it may not yet be enabled for your workspace.

Data point	What Vanta collects	Why it's collected
Policy type	e.g., ACCESS_POLICY, MFA_ENROLL, OKTA_SIGN_ON	Identifies the kind of authentication policy
Policy name	Display name of the policy	Identifies the policy in Vanta workflows
Rules	Each rule's status (active or inactive), name, actions (e.g., allow or deny, verification method), and conditions (e.g., device registration, managed status)	Powers phishing-resistant MFA, biometric MFA, and device trust compliance tests

Org-level security configuration (FedRAMP Moderate)

ℹ️ Note: This data is collected only for workspaces enrolled in FedRAMP Moderate. It requires the two additional OAuth scopes listed in the Permissions section (okta.authenticators.read and okta.threatInsights.read).

Data point	What Vanta collects	Why it's collected
Active authenticators	For each enabled authenticator: ID, key (e.g., webauthn, okta_verify), name, status, and type	Powers phishing-resistant MFA and biometric MFA compliance tests
ThreatInsight action	Current ThreatInsight setting: none (disabled), audit (log only), or block (log and block)	Powers the ThreatInsight suspicious IP blocking compliance test

What Vanta does not collect or do

What	Detail
User passwords	Never read
Authentication session tokens	Not accessed
Write access to your Okta org	Vanta does not create, modify, or delete any data in Okta
Provisioning changes from Vanta back to Okta	The integration is read only To provision users into the Vanta app in Okta, set up Okta SCIM separately

Prerequisites and readiness checklist

Complete all items in this checklist before starting setup.

Confirm you are an Okta Super Administrator

This role is required for two reasons:

Only Super Administrators can create API Services apps with the scopes Vanta needs.
Vanta requires the Super Administrator role to be assigned to the API app itself in order to read role data. Without this, role information will not sync and validation will return a role-related warning.

ℹ️ Note: Whether Super Administrator is required depends on the integration type. For the Okta API integration covered in this guide, Super Administrator is required. SSO and SCIM may work with more limited roles.

Confirm your Okta Domain, not the admin URL

Vanta validates the connection URL and explicitly rejects Okta admin URLs (e.g., company-admin.okta.com). Use your standard Okta domain, which typically looks like company.okta.com or company.oktapreview.com.

Decide which Okta integrations you need

Before starting, decide which of the three you need:

Just directory monitoring? Okta API integration only (this guide).
Directory monitoring + login to Vanta via Okta? Okta API + Okta SSO (this guide).
Directory monitoring + automated user/group provisioning? Okta API + Okta SCIM.

All three? All three must be set up independently.

(Optional) Prepare your scoping assignment

If you want Vanta to track only a subset of Okta users, plan your scoping approach before connecting. See Configure IdP scoping for naming and assignment requirements.

Confirm the connecting admin will retain Super Administrator access

The account used to complete this setup should retain Super Administrator access in Okta on an ongoing basis. If that account later loses Super Administrator status, a current Super Administrator will need to step in for any future changes to the API Services app such as updating scopes, rotating credentials, or modifying role assignments.

Readiness checklist - quick reference

You are an Okta Super Administrator.
You have Vanta admin access.
You know your standard Okta Domain (not the admin URL).
You've decided which of the three Okta integrations you need.
(Optional) You've planned your scoping approach if you don't want to sync all users.
The admin account completing setup will retain Super Administrator privileges long-term.

Setup guide

Here are the steps to connect.

Step 1: Create the Okta API Services app

Log in to Okta as a Super Administrator.
Go to Applications > Applications > Create App Integration.

Select API Services and click Next.

Name the app (e.g., Vanta API) and click Save.

Step 2: Configure scopes, DPoP, and the Super Administrator role

On the Okta API Scopes tab, grant only these six read-only scopes:
- okta.appGrants.read
- okta.apps.read
- okta.groups.read
- okta.policies.read
- okta.roles.read
- okta.users.read

⚠️ Note: Do not add scopes outside this list. Vanta validates that the granted scopes exactly match the expected set and will report both missing and unexpected scopes as errors.

On the General tab, under Client Credentials, click Edit and uncheck Require Demonstrating Proof of Possession (DPoP) header in token requests.

⚠️ Note on a Known Okta bug: After saving, reload the page and confirm the box is still unchecked. The setting can silently revert on first save.

Assign the Super Administrator role to the app.
Still on the General tab, copy your Client ID. You will need it in the next step. Your Okta Domain is the URL you use to sign in to Okta (e.g., company.okta.com), not the admin URL (company-admin.okta.com). Vanta will reject the admin URL and return a validation error.

Step 3: Start the connection in Vanta

In Vanta, go to Integrations, find Okta in the Available tab, click View details, then click Connect.

Paste your Okta Domain and Okta Client ID, then click Next.

Copy the public key URL from the modal. Do not click Validate yet.

Step 4: Add Vanta's public key URL to Okta

Return to your Okta API app, go to General > Edit.
Under Client authentication, select Public Key / Private Key.
Under Public Keys, select Use a URL to fetch keys dynamically.
Paste the URL from Vanta and click Save.

Step 5: Validate in Vanta

Return to the Vanta modal and click Validate. Okta should now appear as Connected on the Integrations page.

Alternate: API Token (SSWS) authentication

Vanta also supports API Token authentication as an alternative to OAuth with private key. If you connect using an API Token, credentials are sent as Authorization: SSWS {token} rather than via JWT exchange. Token-based setup is supported for backward compatibility. New connections should use OAuth with private key, as described in the steps above.

Optional Configurations

Configure IdP scoping

By default, Vanta imports all users from Okta. To limit which users appear in Vanta (for example, to exclude contractors or service accounts), use IdP scoping.

⚠️ Note: IdP scoping uses the Vanta SAML app in Okta as its scope boundary, regardless of whether you are enabling SSO login. If you have not installed the Vanta SAML app yet, complete the Enable SSO steps below first, then return here. You do not need to enable SSO login to use scoping. The SAML app install is the only requirement.

How it works: When IdP scoping is enabled, Vanta treats the Vanta SAML app in Okta as the source of truth for scope. Only users assigned to that SAML app in Okta will sync into Vanta.

Setup:

In Okta, open the Vanta SAML app and go to the Assignments tab.
Assign the Vanta app to the users or groups you want in Vanta's scope.

In Vanta, go to Integrations > Okta > Configure scope and enable Control scope with Okta.

⚠️ Note: Scoping interacts with offboarding. If your offboarding process removes users from the Vanta group in Okta, those users will disappear from Vanta — including terminated employees you may still need for audit evidence. To preserve audit visibility, either keep terminated users assigned to the Vanta group in Okta (while deactivating them), or disable scoping and manage scope directly in Vanta.

For full details, see Controlling Scope Through Okta.

Enable SSO (log in to Vanta via Okta)

The API integration does not enable login to Vanta through Okta. To allow users to log in via Okta, install the Vanta SAML app separately:

In Okta, go to Applications > Browse App Catalog, find Vanta, and click Add Integration.

In Vanta, copy your Domain ID from the Okta integration page.

In Okta, open the Vanta app, go to Sign On > Edit, paste the Domain ID into Advanced Sign-on Settings, and click Save.

Go to Assignments and assign the Vanta app to the users or groups who should be able to log in.
Return to Vanta and click Connect app to finish linking.

Enable SCIM (provision users and groups from Okta)

The API integration does not provision users from Okta into Vanta. To automatically provision users, groups, and roles, set up the separate SCIM integration. SCIM requires a dedicated SCIM 2.0 app in Okta (the Vanta SSO app can be used, but does not support Push Groups).

For full SCIM setup including custom role attributes, group priority, and Push Groups, see Connecting Vanta & Okta (SCIM).

Import Okta groups into Vanta (without SCIM)

If you don't want to run SCIM but want Okta groups to power task assignments in Vanta, use the Dynamic IdP Groups feature to import groups on demand. See Dynamic IdP Groups for Okta.

ℹ️ Note on Group limits: Dynamic IdP Groups supports up to 10,000 groups per org (Okta rate limit). Groups with more than 8,000 members will not appear as selectable in the UI.

Multiple Vanta Workspaces

If your organization uses Vanta Workspaces, a single Okta API app can connect to all of them. Repeat only the Vanta-side steps (Step 3–5) in each Workspace — you do not need to create a separate Okta app per Workspace.

If you want to scope users differently per Workspace, you can create multiple Vanta apps in Okta (label must contain Vanta) and assign different users or groups to each. Vanta will prompt you to pick which app to connect during setup.

Verification and validation

After setup, confirm the following to verify the integration is connected and data is syncing.

Integration is active — Go to Integrations and confirm Okta shows Connected with a recent sync timestamp.
Users are syncing — Go to People. Okta users should appear and be linked to personnel records.
Compliance tests are populating — Go to Tests. The MFA, deprovisioning, and account linking tests should show data.
Roles are visible on users — Open a user's profile. Okta admin roles should appear. If they don't, check that the Super Administrator role is assigned to the API app in Okta.
Applications are appearing — Go to Vendors or Inventory. Okta-managed apps should appear.
Password policies are appearing — Go to Inventory > Password Policies. Okta password policies should appear.

Use cases and capabilities

The Okta integration powers five functional areas in Vanta: personnel management, automated compliance testing, access reviews, access requests, and password policy evidence.

Quick reference

Resource / Capability	Supported	How it's used in Vanta
Users	Yes	Personnel, access reviews, access requests, automated tests, evidence collection
Groups	Yes	Access reviews, access requests
Admin roles	Yes (requires Super Administrator role assigned to the Okta app)	Surfaces privileged access on the Access page; powers access reviews and access requests
Applications	Yes	Access reviews, access requests
MFA enrollment	Yes	Automated tests, evidence collection
Account status / deactivation	Yes	Automated Tests, offboarding and deprovisioning tracking
Password policies	Yes	Audit evidence via vendor configuration
User provisioning (Okta → Vanta)	Via SCIM only	Separate setup
SSO login to Vanta	Via Vanta SAML app only	Separate setup

Personnel management and lifecycle

Vanta uses Okta as a live source of identity data, syncing user profiles, account status, group memberships, admin role assignments, MFA enrollment, and application access on a regular basis.

What this powers in Vanta:

People section: Okta accounts are matched to Vanta user records by email address and appear on the People page with account status, role assignments, and MFA enrollment visible.
Access reviews: Synced users, groups, and roles surface in Vanta's access review workflows so reviewers can confirm whether access is still appropriate.
Automated tests: User data powers the core Okta compliance tests (detailed below).

What you get:

A continuously updated view of who has access, what level of access they have, and whether their account status is current, without any manual exports or spreadsheet maintenance.

⚠️ Note: Vanta's source of truth for employment status is your HRIS, not Okta. If a user is active in Okta but marked as terminated in your HRIS, Vanta will show them as terminated. This is by design. If a user appears terminated in Vanta when you expect them to be active, check their status in your HR system first.

⚠️ Note: Do not deactivate users directly in Vanta if Okta SCIM is connected. SCIM will re-sync them as active on the next cycle. Deactivate in Okta (and in your HRIS if connected); Vanta will pick up the change on the next sync.

Automated compliance tests

Okta data powers several automated compliance tests in Vanta (depending on your framework and configuration). Each test runs on a continuous basis and updates as Vanta syncs new data from your org. The following section captures a couple of the key tests:

Test 1 - MFA on Okta

Vanta checks whether every in-scope Okta user account has at least one active MFA factor.

What this powers in Vanta:

MFA on Okta test: Passes when all in-scope Okta users have at least one MFA factor in ACTIVE status. Fails when one or more non-suspended users who have logged in have no active MFA factor.

Note: Newly created Okta accounts are given a grace period (Account Setup SLA) before being evaluated. The grace period is configurable in Vanta.

Scope notes:

Users who have never logged in to Okta are not evaluated and will pass the test.
Suspended Okta accounts always pass this test (they appear in results but cannot fail).
Deactivated Okta accounts are not included in the test data.
Non-human/service accounts are excluded.
MFA enrollment alone is not sufficient — the factor must be in ACTIVE status in Okta. Factors in a pending state will not satisfy the test.

Test 2 - Okta accounts are associated with active users in Vanta

Vanta checks whether each active Okta account can be matched to a known, active user in Vanta.

What this powers in Vanta:

Okta accounts are associated with active users test -- Passes when every active Okta account is linked to an active Vanta user record. Fails when an active Okta account cannot be matched to any user, or is matched to a user who is marked as terminated.

What you get:

Evidence that all accounts in your Okta org are owned by known, active employees, a core requirement for demonstrating least-privilege access and proper access controls.

Scope notes:

Matching is done by email address. If an Okta account's email does not match any Vanta user record, it will appear as an unlinked account and may fail this test.
Service accounts and shared accounts that are not associated with a specific person can be marked as Not a Person in Vanta to exclude them from this test.
Contractor and vendor accounts should either be linked to a Vanta user record or marked appropriately. Leaving them unlinked will cause test failures.

Access reviews

Okta data surfaces in Vanta's access review workflows, giving reviewers the context they need to confirm whether access is still appropriate for each user.

What this powers in Vanta:

Users: All active Okta users appear in access reviews with their account status, role assignments, group memberships, and application access visible to reviewers.
Groups: Okta groups appear in access reviews when synced via Dynamic IdP Groups or SCIM push. Without one of these configured, group data will not be available for review. See Import Okta groups and Enable SCIM for setup details.
Roles / Entitlements: Admin role assignments from Okta are surfaced so reviewers can flag accounts with elevated privileges that may no longer be appropriate.
Applications: Application assignments from Okta are visible, allowing reviewers to confirm each user's app access is still needed.

What you get:

A structured, auditable record of who reviewed access, what they confirmed, and when, built directly from live Okta data rather than manually assembled spreadsheets.

Scope notes:

Vanta links Okta accounts to Vanta user records by email address for display in access reviews. Accounts that cannot be matched to a user record will appear as unlinked and may require manual resolution before the review can be completed.
Access reviews reflect data from the most recent sync. If a change was made in Okta within the last hour, it may not yet be reflected in the review.
Reviewers do not need Okta access to complete a review in Vanta.

Access requests

Okta entitlements (groups, roles, and applications) can be surfaced in Vanta's access request workflows, allowing employees to request access and approvers to review with full context.

What this powers in Vanta:

Entitlement catalog: Okta groups, roles, and applications synced to Vanta appear as requestable entitlements. Requesters choose from the available entitlements, and approvers see what level of access is being requested before deciding.
Provisioning tracking: Once a request is approved, Vanta tracks whether the access was provisioned in Okta. Without SCIM, provisioning must be completed manually by an Okta admin. With SCIM connected, provisioning can be automated.

What you get:

A documented, auditable trail of who requested access, who approved it, and when it was provisioned, without requiring any changes to how your team manages access in Okta.

Scope notes:

Entitlements only appear in the access request catalog if they have been synced to Vanta. Groups require Dynamic IdP Groups or SCIM push to sync. Roles and applications sync automatically with the API integration.
Without SCIM, access provisioning after approval must be completed manually in Okta. Vanta will track the request status but will not provision access on its own.
Access requests require the Vanta Access Requests feature to be enabled for your workspace.

Password policy evidence

Vanta reads your Okta password policies and surfaces them in the Vanta inventory, providing auditors with documented evidence that password requirements are defined and enforced.

What this powers in Vanta:

Inventory / Password Policies: Okta password policies appear under Inventory in Vanta, including policy name, minimum length, complexity requirements, and lockout settings.
Compliance evidence: The synced policies serve as evidence for controls that require documented password standards, including those in SOC 2, ISO 27001, and HIPAA.

What you get:

Automated password policy evidence pulled directly from Okta, without screenshots, manual uploads, or policy documents that go stale between audits.

Scope notes:

Vanta reads the password policies assigned to your default Okta groups. If you have multiple policies assigned to different user populations, all policies synced by the API will appear in Vanta.
For more details on how Vanta tracks and displays password settings, see Tracking Password Settings for Okta in Vanta.

Offboarding and deprovisioning

When an employee leaves your organization, Vanta uses Okta data to verify that their access was removed promptly and completely. This is one of the most commonly audited controls and one of the highest-value use cases for the Okta integration.

What this powers in Vanta:

Deprovisioning test: The Okta accounts are deprovisioned when personnel leave test continuously checks whether terminated users still have active Okta accounts.
Offboarding workflows: When a user is marked as terminated in Vanta (via HRIS sync or manual update), Vanta evaluates their Okta account status and flags any accounts that have not been deactivated.
Audit evidence: The timestamp of when a user was terminated and when their Okta account was deactivated is captured and available as evidence.

What you get:

A verifiable, timestamped record that access was removed when it should have been, with no manual evidence collection required.

Scope notes:

Without SCIM, deprovisioning in Okta must be completed manually by an Okta admin. Vanta tracks the status but does not trigger deactivation. See Enable SCIM for automated deprovisioning.
If a terminated user's Okta account needs to remain temporarily active (for example, to preserve an inbox or complete an offboarding task), document the exception in Vanta. See Offboarding a User in Vanta While Keeping an Inbox Active for guidance.
Vanta treats Okta account statuses of Deprovisioned (which Okta shows after deletion), Suspended, and Deactivated as successfully offboarded.
If your organization uses SCIM, deprovisioning can be triggered automatically from Vanta when a user is terminated, removing the manual step. See Enable SCIM for setup details.

Limitations and edge cases

Limitation	Detail	Workaround
Vanta cannot write to Okta	The integration is read-only. Vanta cannot deprovision users, assign roles, or push groups to Okta.	For provisioning, use Okta SCIM. For offboarding, deactivate users in Okta (and HRIS), not in Vanta.
HRIS overrides Okta for employment status	A user active in Okta but terminated in the HRIS will appear terminated in Vanta.	This is by design — use your HRIS as the source of truth.
Groups don't auto-sync from the API integration	Vanta reads group data from Okta, but groups must be explicitly added in Vanta before they’re used for access reviews.	Use Dynamic IdP Groups, or set up SCIM with Push Groups.
Dynamic IdP Groups caps at 10,000 groups	N/A	If you have more than 10,000 groups, only the first 10,000 are selectable.
Groups with more than 8,000 members will have their member list truncated to 8,000 users	This is a performance limit that may affect completeness of group-based access reviews.	Split large groups, or use SCIM.
MFA detection is based on Okta factor enrollment	If users authenticate to Okta via a federated IdP, Vanta cannot see MFA enforced at that layer.	Enforce MFA directly in Okta, or note the limitation in audit context.
Okta admin URLs are rejected	Vanta validates and rejects admin URLs like company-admin.okta.com.	Use your standard Okta domain (company.okta.com).
One Okta app per org for API integration	You can connect one API app to multiple Vanta Workspaces, but you cannot connect multiple API apps from one org to one Workspace.	One API app is sufficient — the architecture is designed this way.

Permissions

This section covers what access is required to connect Okta to Vanta.

Vanta access requirements

Permission	Required for
Vanta admin	Connecting, reconnecting, and managing the Okta integration

Okta: connecting user requirements

Requirement	Required or optional	What happens without it
Super Administrator role in Okta	Required	The API Services app cannot be created with the required scopes, or the Super Administrator role cannot be assigned to the app (which blocks role sync).

Okta: OAuth scopes

Scope	Required or optional	What happens without it
okta.users.read	Required	User data cannot be read. The integration will not sync.
okta.groups.read	Required	Group data cannot be read. Group-based workflows will not work.
okta.roles.read	Required	Admin role data cannot be read. Roles will not appear on user records.
okta.apps.read	Required	Application data cannot be read. Apps will not appear as vendors.
okta.appGrants.read	Required	Scope validation fails.
okta.policies.read	Required	Password policies will not sync.

Additional scopes for FedRAMP Moderate

These additional scopes are required for FedRAMP Moderate environments when enabled by Vanta. Your Vanta account team will confirm if these apply to your workspace.

Scope	Required or optional
okta.authenticators.read	Required for FedRAMP Moderate
okta.threatInsights.read	Required for FedRAMP Moderate

Admin role on the API app

Permission	Required or optional	What happens without it
Super Administrator role assigned to the API Services app	Required	Role data cannot be read; a warning is returned and role-based access reviews/requests will be incomplete.

Write access

Vanta does not write to Okta. All API calls are read-only. No user or configuration changes are made.

Troubleshooting and FAQs

Common questions and issues you may encounter when setting up or using Vanta’s Okta integration, along with recommended solutions.

ℹ️ Note: Before contacting Support, collect the connecting admin's Okta account email, your Okta domain, and a screenshot of any error shown in Vanta or during validation.

Connection and setup

Q: Validation fails with a scope mismatch error

Cause: The granted scopes in Okta do not exactly match what Vanta expects. Both missing scopes and unexpected extra scopes are reported.
Fix: In Okta, open the API Services app's Okta API Scopes tab. Confirm that exactly the six required scopes are granted (plus the two FedRAMP scopes if applicable) and no others. Remove any extras. Retry Validate in Vanta.

Q: Validation fails with a role-related error or warning

Cause: The Super Administrator role was not assigned to the API Services app. Without it, Vanta cannot read role data.
Fix: In Okta, open the API app and assign the Super Administrator role. Retry Validate.

Q: Validation fails with a DPoP or token error

Cause: DPoP is enabled on the API app. Vanta does not produce DPoP headers.
Fix: In Okta, open the API app > General > Client Credentials > Edit and uncheck Require Demonstrating Proof of Possession (DPoP) header in token requests. Reload the page after saving and confirm the box is still unchecked — a known Okta bug can silently re-enable it. Retry Validate.

Q: Validation fails and my domain is being rejected

Cause: You entered an Okta admin URL (e.g., company-admin.okta.com). Vanta rejects admin URLs.
Fix: In Vanta, replace the domain with your standard Okta domain (e.g., company.okta.com) and retry.

Q: Okta login returns "Vanta encountered a problem"

Cause: The Vanta Okta SSO app (the SAML app, not the API app) is not fully configured.
Fix: In Vanta, go to Integrations > Okta > Manage > Edit and re-add the SSO integration. Confirm the Domain ID is pasted into the Vanta SAML app's Advanced Sign-on Settings in Okta. If the error persists after reconfiguring, email [email protected].

Users and data

Q: Users are missing from Vanta after the initial sync

Step 1: Check whether Control scope with Okta is enabled at Integrations > Okta > Configure scope.
Step 2: If scoping is enabled, confirm the missing users are assigned to the Vanta SAML app in Okta (Assignments tab).
Step 3: Confirm the users are active and not deactivated in Okta.
Step 4: Wait for the next sync and re-check.

Q: A user appears terminated in Vanta but is active in Okta

Cause: Vanta uses your HRIS, not Okta, as the source of truth for employment status.
Fix: Check the user's status in your HR system. Update there first — the change will propagate to Vanta on the next sync.

Q: I lost admin access after enabling SCIM

Cause: SCIM reassigned your role based on Okta group mappings, and the group containing your admin role is at a lower priority than a lower-privilege group.
Fix: In your SCIM app in Okta, go to Assignments > Groups and drag the group with the highest-privilege role (Admin) to priority 1, followed by lower-privilege groups. Confirm admin roles are explicitly mapped via your SCIM custom attribute. See Connecting Vanta & Okta (SCIM) for the full group-priority workflow.

Q: I see the same person twice in Vanta with different emails

Cause: Duplicate personnel records from multiple IdPs or email aliases.
Fix: This requires Vanta Support to merge. Email [email protected] with the duplicate user emails.

ℹ️ Note on duplicate users across IdPs: If you have Okta plus another identity provider, or users with aliases across systems, Vanta may create duplicate personnel records. Merging duplicates requires Vanta Support — contact [email protected].

Q: Groups are not appearing in Vanta

Cause: Groups do not automatically populate from the API integration. Either Dynamic IdP Groups has not been used, or SCIM is not set up with Push Groups.
Fix: To import groups without SCIM: People > Groups > Add Group > Add from identity providers.
To push groups automatically: Set up Okta SCIM and enable Push Groups in a dedicated SCIM 2.0 app (not the Vanta SSO app — it doesn't support Push Groups).

Q: I added a user to Okta and they aren't showing up in Vanta yet

Cause: Sync is not real-time.
Fix: Wait up to 1 hour. If the user still isn't showing after a full hour, check scoping and the user's Okta status.

Q: I don't see roles when creating an access level in Vanta

Cause: Either the okta.roles.read scope is missing, or the Super Administrator role is not assigned to the API app.
Fix: In Okta, confirm both. Retry validation in Vanta.

Compliance tests

Q: The MFA test is failing for users who have MFA enabled

Step 1: Confirm the affected users have at least one active factor enrolled in Okta (not just a pending factor).
Step 2: If users authenticate to Okta through a federated IdP, Vanta cannot detect MFA enforced at that layer — only MFA factors in Okta are visible.
Step 3: Allow at least one full hourly sync after enrollment before re-checking.

Q: Enabling Okta SSO didn't enforce MFA for Vanta login

Cause: SSO handles authentication routing; MFA is a separate Okta authentication policy.
Fix: Configure MFA enforcement in Okta's Security > Authentication policies for the Vanta SAML app. SSO alone does not enforce MFA.

Offboarding and lifecycle

Q: I deactivated a user in Vanta but they came back as active

Cause: Okta SCIM re-synced them from Okta. Vanta is not the source of truth for user state when SCIM is connected.
Fix: Deactivate the user in Okta (and in your HRIS if connected). Vanta will reflect the change on the next sync. Do not deactivate SCIM-provisioned users directly in Vanta.

Q: How do I offboard a user while keeping their inbox active?

Okta and OneLogin both support suspending users without deactivating them, which lets Vanta mark them as ex-employees while preserving account data. See Offboarding a User in Vanta while Keeping an Inbox Active.