Introduction

Welcome to the Beyond Identity - Okta Identity Engine (OIE) integration guide, where we walk you through every configuration step for delegating authentication to Beyond Identity; and, more importantly, explain why each action matters. You’ll learn not only how to set up routing rules, attribute mappings, and OIDC configurations, but also the security rationale that underpins each choice, such as preventing credential replay, enforcing device posture checks, and ensuring tamper-proof identity assertions. We’ll also share communication best practices; from crafting clear end-user notifications to briefing your executive sponsors; so your rollout is secure, transparent, and aligned with both IT and business stakeholders. Let’s dive in.

Intended Audience

IT Administrators: Responsible for configuring and managing both the Okta and Beyond Identity environments.
Executive Sponsors: Stakeholders who require a clear understanding of the integration process, benefits, and risk mitigation strategies.
Advanced End Users: Technical users or testers who want to understand how the system works and will experience changes in their login flow as a result of this integration.

Prerequisites and Overview

Before You Begin

Confirm you have administrative access to an Okta OIE tenant.
Confirm your Okta domain
(Example: abc123456789.okta.com)

Your Okta domain can be retrieved by logging into Okta, click your name in the upper-right hand corner and clicking Copy to clipboard.

Confirm you have administrative access to a Beyond Identity tenant.
Confirm there are one or more application(s) already available to your end users either via the Okta End User Dashboard or directly.

Integration Objectives

Create a custom attribute in Okta to determine which users should be routed to Beyond Identity for authentication. 4.1
Create an API key in Okta with admin privileges so Beyond Identity can update user attributes and control when users are routed through passwordless authentication. 4.2
Connect Beyond Identity to Okta as a delegate Identity Provider so Okta can route eligible users to authenticate through Beyond Identity. 4.3
Create a routing rule in Okta that sends users to Beyond Identity for authentication when they’ve been marked as enrolled. 4.4
Update existing authentication policy(ies) in Okta to enforce how users logging in through Beyond Identity should be authenticated. 4.5
Test the integration by enrolling a user and confirming they can log into an Okta-connected app using Beyond Identity. 4.6

3. Architecture

At a glance

The following diagram shows how Okta and Beyond Identity work together, and what the login flow looks like for users based on whether they’re enrolled.

Authentication Flow through Beyond Identity

The process begins when a user attempts to log into an application, such as Salesforce (#1).

The application redirects the authentication request to Okta (#2), which then checks the authentication policy for that user (#3).

Okta evaluates whether the user is enrolled in Beyond Identity by checking the byndidRegistered attribute (#4).

If the user is not enrolled (Step 4a), Okta handles the authentication itself using its default method. If the user is enrolled (Step 4b), Okta delegates the authentication to Beyond Identity.

Upon successful authentication by Beyond Identity (#4c), the user is logged into the application (Step 5). This dynamic routing ensures a smooth transition for users moving to strong authentication while maintaining compatibility with existing login flows.

4. Step-by-Step Guide

This section breaks down each step in the configuration process explaining how it works, why it matters, and what impact it has on security and operations.

Throughout this guide, Okta will prompt you to re-authenticate for certain operations.

Throughout this document you still see bracketed text like the following: <SOME TEXT>
DO NOT copy/paste the bracketed text! These are dynamic values you MUST collect from your environment!

4.1 Create a custom attribute

To seamlessly login users with Beyond Identity, Okta needs a way to identify who should use the new authentication flow. Rather than reusing existing user attributes, which could interfere with other parts of your setup, we recommend creating a new, dedicated custom attribute just for this purpose.

The attribute will be included in the user profile with a default setting, meaning users won’t see any changes right away. We’ll only update this value after a user has successfully enrolled with Beyond Identity, ensuring a smooth and controlled rollout.

Task: Create a Custom Attribute within Okta OIE

Open your web browser and go to https://www.okta.com.
Log in as an administrator into your Okta account. Press Admin at the top right.
From the left-hand navigation panel, click Directory → Profile Editor
Under Profile click User (default).
Click +Add Attribute.
Fill out the form as follows:
1. Data Type: boolean
2. Display name: Beyond Identity
3. Variable name: byndidRegistered
4. Description: Beyond Identity registration status
5. User permission: Read Only
6. Click Save

4.2 Create an API key for Beyond Identity

Beyond Identity will use the API key you created to update the custom user attribute we set up earlier. This attribute tells Okta whether a user should be routed to Beyond Identity or stick with the standard Okta authentication flow.

This flexibility is important. You might be running a pilot, rolling out gradually, or excluding certain accounts like service users. You might also want to support a flow where users log in one last time with a password before switching to passwordless. By updating the attribute only after a user has successfully enrolled a secure passkey, Beyond Identity helps ensure their access to Okta remains smooth and uninterrupted throughout the transition.

In Okta, API tokens inherit the permissions of the user who creates them. To allow Beyond Identity to update the custom user attribute, the API token must have permission to Edit Profiles. According to Okta’s documentation, this permission is included in the Super Admin, Org Admin, and Group Admin roles.
For security and least privilege, we recommend using an Org Admin account when generating the token. This provides the necessary access without granting broader administrative rights.

This API key is used solely to update the Beyond Identity custom attribute in Okta. It's securely managed through AWS Key Management Service (KMS) and protected using the same security standards we apply to deployments for the U.S. Federal Government. For more details, visit our Availability, Security, and Compliance page.

Task: Create an Okta API Key w/ the correct privileges

To modify the Okta identity custom attribute byndidRegistered, we will need admin API privileges.

Log in as an administrator into Okta
Navigate to Security → API
Select Tokens and click Create Token
1. Name your token Beyond Identity
2. Select Any IP
  If you get a warning message above, re-click the Create token button and re-authenticate with Okta's two-factor.
Click Create token
Copy the Token value.
DO NOT PROCEED without saving this token securely before continuing. Okta won’t show it again, and if it’s lost or overwritten, you’ll need to generate a new one.
Click Ok, got it
In the Tokens tab, under the Role column, verify that the value is either Super Administrator or Organization Administrator

Task: Register the Okta API token with Beyond Identity

Open a new browser tab and go to https://www.beyondidentity.com
Log into the Beyond Identity Admin Console Secure Workforce
Navigate to Integrations → Okta
To the right of Okta Registration press the download button to install the service. If already enabled, press the pencil to edit.
Fill out the form as follows:
1. Okta Domain: https://<YOUR OKTA DOMAIN DO NOT COPY THIS PLACEHOLDER TEXT> (copy domain value from Okta after clicking your profile name)
  1. EXAMPLE ONLY DO NOT COPY: https://abc123456789.okta.com
2. Okta Token: <OKTA API TOKEN VALUE DO NOT COPY THIS PLACEHOLDER TEXT> (the API token value you created in the previous task)
3. Okta Registration Attribute: byndidRegistered
4. Okta Mapping Attribute: <LEAVE BLANK>

Click Save Changes

4.3 Configure Beyond Identity as an OIDC connection in Okta

Beyond Identity integrates with SSOs and Identity Providers as a delegate IdP, meaning it can receive authentication requests routed from another IdP like Okta. This is a common architecture for federating authentication, and in the case of Okta Identity Engine, the integration uses OIDC, which is the most secure option available, and less vulnerable than SAML to attacks like golden ticket-style exploits. Once the setup is complete, Beyond Identity will show up in Okta as a routable identity provider, allowing Okta to direct authentication requests based on the rules you define. This step requires configuration steps to be performed both in Beyond Identity and Okta, we'll start in Beyond Identity's admin console and finish up in Okta's.

Task: Create an OIDC connection in Beyond Identity

First, you'll create an OIDC connection in the Beyond Identity console.

Login to the Beyond Identity Admin Console
Navigate to Integrations → OIDC
Click Add OIDC Client
Fill in the form as follows:
1. Name: Okta SSO
2. Redirect URIs: https://<YOUR OKTA DOMAIN>/oauth2/v1/authorize/callback (copy domain value from Okta after clicking your profile name)
  1. EXAMPLE ONLY DO NOT COPY: https://abc123456789.okta.com/oauth2/v1/authorize/callback
3. Token Signing Algorithm: RS256
4. Auth Method: client secret post
5. Login Hint Validation Config: Enabled
6. Login Hint Match Strategies: Select all
Click Save Changes
Take note of the Client ID and Client Secret on the Integrations → OIDC page
You will need the Client ID and Client Secret from this OIDC connection in the next step.

Task: Create an OIDC Connection in Okta

Now, we'll create the OIDC connection in the Okta console

Log in as an administrator into Okta.
Navigate to Security → Identity Providers
Click + Add Identity Provider
Select OpenID Connect IdP
In rare cases, OIDC connections may be disabled in Okta tenants. If you don’t see it, reach out to Okta Support to have it enabled.
Click Next

Fill out the form as follows:

Field	Value
Name	Beyond Identity
IdP Usage	SSO Only
Claims	Leave blank
Scopes	openid (remove all other scopes)
Client ID	<CLIENT ID FROM PREVIOUS STEP> (copy this value from the OIDC integration you created in Beyond Identity)
Authentication type	client secret
Client Secret	<CLIENT SECRET FROM PREVIOUS STEP> (copy this value from the OIDC integration you created in Beyond Identity)
Authorize requests	leave blank
Proof Key for Code Exchange (PKCE)	leave blank
Issuer	https://auth.byndid.com/v2
Authorization endpoint	https://auth.byndid.com/v2/authorize
Token endpoint	https://auth.byndid.com/v2/token
JWKS endpoint	https://auth.byndid.com/v2/.well-known/jwks.json
Userinfo endpoint	https://auth.byndid.com/v2/userinfo
IdP Username	idpuser.externalId (this is an editable text field)
Filter	leave blank
Match against	Okta Username
Account link policy	Enable automatic linking
Auto-link filters	leave blank
If no match is found	Redirect to Okta sign-in page

Click Finish

4.4 Create the Beyond Identity User Portal in Okta

Now, you’ll create two OIDC applications in Okta—one for the user portal and another for the admin portal. These applications act as the connection points between Okta and your portals, allowing Okta to manage authentication for each independently. By assigning the correct client ID and secret to each app, you ensure that Beyond Identity can recognize and authenticate requests from both portals securely. This separation also provides flexibility in managing access policies, so that end users and administrators follow the appropriate login flows without overlap.

Be careful to create two separate apps in Okta—one for the User Portal and another for the Admin Portal. Don’t try to reuse one app for both, because Beyond Identity treats them independently. Mixing them up can cause authentication failures or policy misconfigurations. Both portals have their own unique Client ID and Client Secret ID.

Task: Create the Beyond Identity User Portal in Okta

Log in as an administrator into Okta.
Navigate to Applications → Applications
Select Browse App Catalog
In the search bar, type Beyond Identity User Portal
Select it and press Add Integration
Assign users to the User portal:
1. Select the Beyond Identity User Portal from the list of applications.
2. Click on the Assignments column
3. Press Assign → Assign to Groups
4. Select Beyond Identity and press assign
5. Click done

Task: Sign On Setup

Click on the Sign On column.
Click edit
For Org ID, type Oktatest
Take note of the Client ID and Client Secret. Label them as the User Portal ID's.You will need the Client ID and Client Secret from this OIDC connection in a later step.
You will need the Client ID and Client Secret from this OIDC connection in a later step.

Task: Provisioning Setup and API Configuration

Click on the Provisioning column.
Press Configure API Integration
Make sure Enable API Integration and Import Groups are checked off.
For the API Token, paste the token provided by Beyond Identity from step 4.2.
Then click on Test API Credentials
After seeing the message Beyond Identity User Portal was verified Successfully, save the configuration.
In the Provisioning column's To App section, click edit
Check the boxes to enable Create Users, Update User Attributes, and Deactivate Users
Hit save

Task: Pushing Groups Through User Portal

In the Beyond Identity User Portal, click on the Push Groups column.
Press Push Groups → Find groups by name

Type Beyond Identity and select the group.
Click save

Task: Setup User Portal Access in Beyond Identity

Login to the Beyond Identity Admin Console.
Navigate to Settings → Console Login

Under User Console SSO Integrations, click Edit SSO to the right of Custom OIDC SSO: Okta OIDC SSO. If the integration doesn't already exist, press Add OIDC SSO

Fill out the form as follows:


Name	Okta OIDC SSO
Client ID	<CLIENT ID FROM PREVIOUS STEP> (copy this value from the OIDC integration you created in Okta's Beyond Identity User Portal sign on)
Client Secret	<CLIENT SECRET FROM PREVIOUS STEP> (copy this value from the OIDC integration you created in Okta's Beyond Identity User Portal sign on)
Issuer	https://<YOUR OKTA DOMAIN DO NOT COPY THIS PLACEHOLDER TEXT> (copy domain value from Okta after clicking your profile name)
Token Field	sub
Token Field Lookup	external id
Scopes	Select all [address, email, phone, profile]

Press Save Changes
Ensure that Custom OIDC SSO: Okta OIDC SSO is active; if not, press Manage Active SSO → OIDC to make it the active SSO method.

4.5 Create the Beyond Identity Admin Portal in Okta

Once the User Portal application is fully configured, you’ll move on to creating an application for the Admin Portal. This app functions separately from the User Portal and is responsible for managing authentication specifically for administrative users. Assigning the correct client ID and secret ensures that Beyond Identity can securely recognize and authorize login requests from administrators, keeping their access flow distinct from regular users.

The Admin Portal must have its own dedicated app and credentials. Do not reuse the User Portal Client ID and Secret ID, as each portal requires independent authentication to prevent conflicts or access issues.

Task: Create the Beyond Identity Admin Portal in Okta

Log in as an administrator into Okta.
Navigate to Applications → Applications
Select Browse App Catalog
In the search bar, type Beyond Identity Admin Portal
Select it and press Add Integration
Assign users to the Admin portal:
1. Select the Beyond Identity Admin Portal from the list of applications.
2. Click on the Assignments column.
3. Press Assign → Assign to Groups
4. Select Admins and press assign
5. Click done

While this guide uses the default Admins group for simplicity, you can assign any Okta group to the Beyond Identity Admin Portal. For security and least privilege, we recommend creating a dedicated group containing only those users who already have Super Admin access in Okta. This ensures the right people retain administrative control without broadening access unnecessarily.

Task: Sign On Setup

Click on the Sign On column.
Click edit
For Org ID, type Oktatest
Take note of the Client ID and Client Secret. Label them as the Admin Portal ID's.
You will need the Client ID and Client Secret from this OIDC connection in the next step. This is separate from the User Portal credentials, do not replace the User Portal credentials or confuse them with the Admin Portal credentials.

Task: Setup Admin Portal Access in Beyond Identity

Login to the Beyond Identity Admin Console.
Navigate to Settings → Console Login
Under Admin Console SSO Integrations, click Edit SSO to the right of Custom OIDC SSO: Okta OIDC SSO Admin. If the integration doesn't already exist, press Add OIDC SSO.

Fill out the form as follows:

Field	Value
Name	Admin Console SSO - Okta
Client ID	<CLIENT ID FROM PREVIOUS STEP> (copy this value from the OIDC integration you created in Okta's Beyond Identity Admin Portal sign on)
Client Secret	<CLIENT SECRET FROM PREVIOUS STEP> (copy this value from the OIDC integration you created in Okta's Beyond Identity Admin Portal sign on)
Issuer	https://<YOUR OKTA DOMAIN DO NOT COPY THIS PLACEHOLDER TEXT> (copy domain value from Okta after clicking your profile name)
Token Field	sub
Token Field Lookup	external id
Scopes0	Select all [address, email, phone, profile]

Press Save Changes
Ensure that the Okta OIDC SSO Admin is active; if not press Manage Active SSO → OIDC to make it the active SSO method.

Task: Assigning Admin Roles

Login to the Beyond Identity Admin Console.
Navigate to Settings → Console Access Control
Select a predefined admin role such as Super Administrators
Check off the users you would like to assign and press Assign access role to users
Alternatively, you may assign user groups to Admin roles. Navigate to Settings → Console Access Control. Click on one of the predefined Admin roles. Click on the Groups tab. Press Assign access role to groups and type in the group that you would like to give Admin roles to. Once selected, press Assign groups to role to save.

4.6 Create a routing rule in Okta

Next, you'll create a routing rule that tells Okta when to send users to Beyond Identity for authentication instead of using its default login flow. This rule checks the custom attribute you set up earlier (byndidRegistered). If the value is set to true, the user is routed to Beyond Identity. If it’s false, Okta handles the login as usual. This ensures only users who’ve successfully enrolled and have an active passkey are directed to the Beyond Identity authentication experience.

Once this routing rule is enabled, the end-user login experience will change right away. Instead of seeing a single screen for both username and password, users will first be asked for their username. Based on that input, Okta will decide whether to route them to Beyond Identity or continue with the standard login flow and prompt them for a password.

Left: Okta Routing Rule Disabled; Right: Okta Routing Rule Enabled

Task: Create the Routing Rule within Okta OIE

Log in as an administrator into Okta.
Navigate to Security → Identity Providers.
Select the Routing Rules tab.
Click Add Routing Rule
Fill out the form as follows:
1. Name: Beyond Identity
2. IF User's IP is: Anywhere
3. AND User's device platform is: Any device
4. AND User is accessing ?: Any application
5. AND User Matches: User Attribute
  1. byndidRegistered
  2. equals
  3. true
6. THEN Use this identity provider: Use specific IdP(s)
  1. IdP(s): Beyond Identity (Remove Okta)
7. Click Create Rule
You will see a dialog titled Activate Rule? asking if you would like to activate this rule.
1. Confirm all the values are correct and click Activate
Ensure this rule is at the top of the rule list, as rules are evaluated in order.

Task: Add a Break-glass Rule for Admin Access (Recommended)

If you choose to complete this step, this rule should be placed BEFORE the "Beyond Identity" rule you created previously. On the left of the Break-glass Admin Access routing rule, click and drag the dotted bar over the Beyond Identity routing rule.

To avoid accidental lockouts, especially during testing or rollout, we recommend creating a break-glass rule that allows designated admin accounts to bypass the Beyond Identity flow and authenticate directly with Okta.

This avoids cases where admins unintentionally lock themselves out by applying routing rules too broadly.

Steps to Add a Break-glass Rule

Log in to the Okta Admin Console.
Navigate to Security → Identity Providers, then go to the Routing Rules tab.
Click Add Routing Rule
Fill out the rule as follows:
1. Name: Break-glass Admin Access
2. IF User's IP is: Anywhere
3. AND User's device platform is: Any device
4. AND User is accessing ?: Any application
5. AND User Matches: User Attribute (Select a specific user attribute that uniquely identifies your break-glass account(s), such as...)
  1. email
  2. Equals
  3. <enter admin email here>
6. THEN Use this identity provider: Use specific IdP(s)
  1. IdP(s): Okta
Click Create Rule.
Drag this rule to the top of the rule list to ensure it takes priority.

4.7 Update Existing Authentication Policies

The last setup step is to add a rule to your default authentication policy to define how Beyond Identity users should authenticate. Okta Identity Engine includes three built-in policies by default: Any two factors, Classic Migrated, and Okta Admin Console. To ensure a consistent experience for all users enrolled with Beyond Identity, each policy can be updated. For now, though, this guide focuses on updating the default policy: Any two factors.

You will potentially receive a warning from Okta claiming the following rule you will configure is weak because they cannot track the factors when integrating with other IdPs - You can safely ignore this warning and click Save Anyway

Misleading Okta warning

Task: Configure Authentication Policies in Okta

Log in as an admin into Okta
Navigate to Security → Authentication Policies
Select the Default authentication policy, usually Any two factors.
Click Add Rule
Fill out the form as follows (leave unmentioned fields as default values):
1. Rule name: Beyond Identity
2. IF
  1. AND The following custom expression is true: user.profile.byndidRegistered == true
3. THEN
  1. AND User must authenticate with: Password / IdP
4. When to prompt for authentication
  1. When it's been over a specified length of time since the user accessed any resource protected by the active Okta global session
    Time since last sign in: <STANDARD LOGIN INTERVAL FOR YOUR COMPANY> (default is 1 hour)
Click Save
1. If the misleading Okta warning mentioned previously Click Save Anyway
Make sure the Beyond Identity rule is at the top of the rule list

4.9 Verify login with Beyond Identity

To confirm that the integration between Okta OIE and Beyond Identity is working correctly, you’ll test it by logging in as a user who’s registered with Beyond Identity. Since you may not have many enrolled users yet, we’ll manually update the byndidRegistered attribute for an account you already control, ideally, the same one you used to set up the OIDC connection and enroll a Beyond Identity credential. Then, you’ll use that account to log into an app that uses Okta SSO.

Task: Manually set Beyond Identity User Attribute

Log in as an administrator into Okta
Navigate to Directory → People

Select the user you want to validate the Beyond Identity login with
Select the Profile tab and click Edit
Scroll down and set Beyond Identity, byndidRegistered to true
Click Save

Task: Log in to an application that uses Okta SSO

Navigate to the End User Dashboard or to the login page of your app directly
Depending on the authentication policy tied to your Okta End User Dashboard, users may still be prompted for Okta Verify MFA after completing the Beyond Identity login flow, especially when launching apps via IdP-initiated logins. The same applies to the Okta Admin Console, which uses a separate authentication policy.
If the routing rule is active, you’ll see a single field asking for your username. Enter it and click Next to continue.
If your authentication policy is set up correctly and the rule is in the right order, you’ll be routed through the Beyond Identity login flow. Once authenticated, you’ll be redirected to your application as expected.

5. User Impact and Communication

What Changes for End Users

Updated Okta Login Experience

When integrating a delegate identity provider, Okta modifies the login experience for all end users. Previously, Okta displayed a single screen prompting for both username and password simultaneously. With this integration, Okta separates the login experience into two sequential screens:

Username Prompt: On the first screen, users will enter their username. Okta uses this to check if they’re enrolled with Beyond Identity and decide how to route the login request.
Passwordless or Password Login: If the user is enrolled, they’ll be automatically redirected to the secure, passwordless Beyond Identity experience. If not, they’ll move to the usual second screen where they’ll enter their password.

Most organizations find this change subtle enough that broad end-user communication isn’t required. That said, it’s a good idea to update internal IT FAQs and help desk scripts to proactively address any questions or confusion that might come up.

Suggested Messaging for Helpdesk Teams or FAQs

We’ve updated the Okta login experience as part of our move to a more secure, passwordless authentication process.
You’ll now see a two-step login: first, you’ll enter your username. If you’re enrolled in passwordless authentication with Beyond Identity, you’ll be automatically routed through that secure login. If not, you’ll continue to the usual password prompt.

Upon Successful Passkey Enrollment

Once a user has enrolled a passkey on their device, their login experience becomes fully passwordless, they won’t see password prompts in Okta going forward.

For production deployments, Beyond Identity provides standard communication templates and messaging to assist with proactive communication, internal FAQ updates, and help desk training. This standard copy addresses:

What is changing in the user experience
Steps to enroll in passwordless authentication
- Windows, macOS, iOS, Android
Instructions for logging in without passwords
Guidance for re-enrollment procedures, if needed

For more product walkthroughs check out the rest of our arcade demos!

6. What are the Risks?

Beyond Identity delivers a reliable, enterprise-grade authentication service with 99.99% availability. Our platform is distributed across multiple AWS regions in North America and Europe to ensure high availability and minimize risk. We also offer 24/7 support for production customers.

If you ever need to roll back the integration, you can do so safely and instantly by disabling the Beyond Identity routing rule in Okta. This immediately returns users to their previous authentication experience, no additional configuration required.

7. Frequently Asked Questions

IT Admins / Identity Engineers / Security Engineers

What happens to our existing authentication flows when Beyond Identity is added?
Beyond Identity is added as a delegated IdP within Okta. This means you can selectively route users to Beyond Identity without disrupting existing auth flows. Your current MFA, password, or fallback policies remain intact until you’re ready to cut over.

How hard is this to roll back if something breaks?
Very easy. Okta routing rules can be toggled instantly. You can disable the routing rule and instantly revert all users to the previous IdP or policy.

How do we test this with a pilot group only?
You create a routing rule that targets a specific group of users (e.g., a test group with your email domain or user attribute). This lets you run a full pilot without affecting production users.

How do I verify my admin account has sufficient privileges?

Verify your account has either Super Admin or Global Admin privileges under Security → Administrators → Admins

Do I need to write custom code?
No. Beyond Identity integrates with Okta using standards-based protocols (OIDC/SAML). Most deployments require zero custom code.

What about break-glass accounts or service accounts?
Break-glass accounts should remain routed to Okta directly, bypassing Beyond Identity. This is controlled via routing rules.

How long does deployment take?
Most integrations take under an hour to configure for a pilot. Full rollout timelines depend on your internal testing and comms schedule.

Does this eliminate passwords from Okta completely?
Users that have been targeted to authenticate over the web using Beyond Identity as a primary factor can bypass this global routing rule via Okta's authentication API. There are three possible mitigations.

1. Users passwords can be randomized via a script.

2. Administrators can block these api authentication attempts using Okta's API RBAC sku.

3. Administrators would also configure Beyond Identity as an MFA factor which is enforced for all authentications.

Executives / CIO / CTO / CISO

What risk are we reducing by adding Beyond Identity to Okta?
You eliminate all phishable authentication factors, including passwords, push notifications, and OTPs. This directly addresses phishing, session hijacking, and help desk fraud.

Why not just use Okta FastPass, FIDO Keys or WebAuthn?
Okta FastPass still supports fallbacks to phishable factors. Beyond Identity guarantees no fallback, no shared secrets, and adds continuous authentication and device posture checks.

Will this affect our business continuity?
No. Beyond Identity is integrated without breaking existing workflows. Rollback is instant, and break-glass accounts remain available.

How does this help with Zero Trust and compliance mandates?
Beyond Identity supports EO 14028, FedRAMP, and CISA Zero Trust Maturity Model by enforcing phishing-resistant auth, verifying device trust, and continuously authorizing sessions.

Which user groups should we start with?
It’s best to begin with high-risk groups, like developers, IT staff, and executives, who are more likely to be targeted by phishing or credential-based attacks. Once those teams are onboarded, you can expand to contractors, BYOD users, and eventually the broader organization.

End Users / Employees / Contractors / Partners

Why does my login screen look different?
Your organization is upgrading to a more secure login experience that eliminates passwords and protects your identity from phishing.

What do I need to do?
You’ll install a lightweight Beyond Identity authenticator on your primary work device. From there, logging in is quick and seamless, just like unlocking your phone.

Will I have to remember anything?
No passwords, no codes, and no push prompts. Beyond Identity uses your device and a secure biometric or PIN to log you in instantly.

What happens if I lose my device?
Don’t worry, there are secure recovery steps in place. Your IT team can help you re-register a new device without needing a password reset, so you can get back up and running quickly and safely.

Will this work when I’m traveling?
Yes. As long as you have your registered device with you, your login will work normally.

Does Beyond Identity collect or share any of my personal / biometric data?

No. Beyond Identity does not collect, store, or share any of your personal or biometric data.
All authentication happens locally on your device. Biometric data, like your fingerprint or Face ID, stays securely within your device’s trusted hardware (such as the Secure Enclave on iOS or TPM on Windows) and is never transmitted or visible to Beyond Identity or your organization.

8. Troubleshooting

Use the following scenarios to identify and resolve common issues during or after the integration process. Each section includes what to check and how to fix it.

Users aren’t being routed from Okta to Beyond Identity

What to check	Fix
Is the Beyond Identity routing rule you created in Step 4.4 enabled and placed at the top of the list in Okta? Routing rules are evaluated in order.	Reorder the routing rule so it appears above others.
Does the rule correctly target users based on the byndidRegistered attribute?	Confirm the logic matches what you’ve configured in the user’s profile.
Is the user’s byndidRegistered attribute set to true?	Manually edit the user profile to set the attribute if needed (for test users).

The custom attribute isn’t being set to true after users enroll their credential

What to check	Fix
Is the API key you created in Okta still valid and properly registered in the Beyond Identity admin console?	Log into Okta and confirm the API key is listed under Security > API > Tokens, and hasn’t expired.
Was the attribute name (byndidRegistered) entered correctly? Case-sensitive and exact?	In Beyond Identity, go to Integrations > Okta and verify the registration settings, including the attribute name and token.
Does the API key have the required permissions (minimum: Org Admin) to edit user profiles?	If needed, re-enter or replace the API token using an account with Org Admin or Super Admin privileges.
Has the enrollment flow actually completed? (i.e., has the user registered a valid passkey?)	Check the Beyond Identity audit logs to confirm the passkey enrollment completed successfully for that user.

I don’t see “OIDC” as a valid Identity Provider type in Okta

What to check	Fix
Is your tenant missing Identity Providers > Add Identity Provider > OpenID Connect as an option?	If you don’t see OpenID Connect as an option, contact Okta Support and request that OIDC as an external IdP type be enabled. This option can be disabled by default in some tenants and must be activated manually.
Have you verified with Okta Support whether this feature is enabled on your tenant?	After it's enabled, return to Security > Identity Providers, click Add Identity Provider, and select OpenID Connect.

How to Submit a Ticket