★★★★★ 4.5 CE

Beyond Identity Deployment Options & Rollout 2026

Beyond Identity fronts your existing login over OIDC. You embed an SDK, provision passkeys through API binding jobs, and private keys stay in device hardware.

Identity & Access ManagementVerified today

Full review Pricing Official site ↗

Beyond Identity Deployment verdict

Verified today·4 sources checked

Beyond Identity is a passwordless layer in front of your login, not a system you host.

Your app delegates authentication over OIDC. An embedded SDK on each device binds a Universal Passkey, generating its private key into the device's hardware trust module, such as an Apple T2, a TPM or a Nitro enclave.

How to roll it out

Treat Beyond Identity as a standards-based layer over your current authentication. Delegate auth to it over OIDC and embed the SDK. Provision passkeys through binding jobs: the RETURN method creates them inline so users never leave your app, or EMAIL when a link fits better, with automatic enrollment at first sign-in. Then handle the one real constraint. Map your fleet to hardware Trusted Execution Environments, an Apple T2, TPM, Titan or Nitro. Flag any endpoints that would fall back to OS storage, and decide whether that clears your bar. Configure the Authenticator Config for the post-binding redirect, and set the risk engine's conditions for device trust on every login. Because passkeys work across any OS and are managed by API, one model covers a mixed fleet, and the SDK handles the cryptographic key work for you. Effort scales with how many apps and which identity stack you front, not with the passkey mechanics.

Honest limits

Beyond Identity fronts your existing login over OIDC. There is no password store of your own to run.
Private keys are generated in device hardware and never leave. Only public keys reach the cloud.
Endpoints without a hardware TEE fall back to OS-level key storage, a device-coverage question for rollout.

Model: Passwordless layer over OIDC
Keys: Private key in device TEE
Provision: API binding jobs (RETURN/EMAIL)
Enroll: Inline on first sign-in
SDK: Open-source (bi-sdk-js)

View sources

This page covers how Beyond Identity deploys and is administered. Its compliance posture and pricing live on their own pages.

Deploy Beyond Identity: commands and config

Deployment runbook

Add the open-source Beyond Identity JavaScript SDK and initialize the Embedded namespace once before any call.

typescript

// npm install @beyondidentity/bi-sdk-js
import { Embedded } from '@beyondidentity/bi-sdk-js';

const embedded = await Embedded.initialize();

The SDK supports OIDC and OAuth 2.0; your app delegates auth and the SDK signs the challenge
Binding jobs are created server-side via the Beyond Identity APIs
Private keys are generated into a hardware TEE; only the public key reaches the cloud

Real Beyond Identity commands from the official docs. Pick a task to see what it does, then copy the command.

What you run at each Beyond Identity layer

Aspect	What you run	Notes
Cloud	Beyond Identity cloud	Holds public keys; runs OIDC and risk decisions
Device	Private key in hardware TEE	Never leaves the device
Apple	Apple T2 chip	TEE on Apple devices
Windows / Linux	TPM	Trusted Platform Module
ChromeOS / AWS	Titan chip / Nitro enclaves	AWS keys not persisted
Fallback	OS-specific secure storage	When no TEE; master key plus knowledge-factor salt
Protocol	OIDC + FIDO2 (WebAuthn/CTAP)	Delegated auth; standards-based

Beyond Identity connectors and integration surface

Integration	Type	Capabilities	Setup
Embedded SDK	Device SDK	bindPasskey() · Any OS device · Hardware key generation	Embed in app
Binding job (RETURN)	Provisioning	Generate link in-app · Deliver inline / SMS / email · Fastest binding link	API call
Binding job (EMAIL)	Provisioning	Email passkey link · Redirect via Invoke URL · Authenticator Config	Configure
OIDC delegation	Auth protocol	App delegates auth · Same protocol returns result	Standard config
FIDO2 (WebAuthn/CTAP)	Standard	Public-private-key auth · Interoperable · Certified	Built-in
Hardware targets	TEE binding	Apple T2, TPM · Titan, Nitro · OS fallback	Automatic
Risk engine	Access policy	Real-time user and device risk · Risk-based decision	Policy
Open-source SDK	Source	@beyondidentity/bi-sdk-js · OIDC + OAuth 2.0 · Inspectable on GitHub	Install

Beyond Identity rollout plan and risk points

A passkey creation link is created using the Beyond Identity APIs and delivered to the SDK running on the user's device.
The RETURN method is the suggested way to create a passkey without the user leaving your application and is the fastest way to get a binding link.
Enrollment happens automatically, inline with the first sign-in, reducing a separate setup burden, and sign-in afterward is a click or touch plus a biometric.
Where a device lacks a Trusted Execution Environment, the SDK falls back to OS storage, a rollout consideration for older hardware.

Beyond Identity Deployment FAQ

How is Beyond Identity deployed?

As a passwordless layer in front of your existing login. Your application delegates authentication to Beyond Identity over OIDC. An embedded SDK on the device binds a Universal Passkey. Its private key is generated into the device's hardware and never leaves, while only the public key registers with the Beyond Identity cloud. There is no password store to run on your side. You integrate the SDK and provision passkeys through API binding jobs.

How are passkeys provisioned to users?

Through binding jobs. A passkey creation link is created via the Beyond Identity APIs and delivered to the SDK on the user's device. The SDK's bindPasskey function then generates the private key into the hardware trust module and stores the public key in the cloud. You can deliver the link inline with the RETURN method, the fastest option since it keeps users in your app, or by EMAIL, and enrollment happens automatically on first sign-in.

Where are the private keys stored?

In the device's hardware, never in the cloud. Passkeys live in a Trusted Execution Environment wherever one exists. That means an Apple T2 on Apple devices, a TPM on Windows and Linux, the Titan chip on ChromeOS, or a Nitro enclave on AWS, where it is not persisted. If a device has no TEE, the SDK falls back to OS-specific secure storage protected by an OS-generated master key. That fallback is the device-coverage consideration for older hardware.

How do I integrate the Beyond Identity SDK?

With the open-source JavaScript SDK. You install @beyondidentity/bi-sdk-js and call Embedded.initialize once. Then you work through the Embedded namespace. Use bindPasskey to enroll a passkey from a binding link, authenticate to complete a login and return a redirect URL, and helpers like isBindPasskeyUrl to route incoming links. The SDK supports OIDC and OAuth 2.0 and handles the hardware key generation, so your app code stays at the level of links and redirects.

How does login work after deployment?

Every login is an on-device check plus a signed challenge. The user proves they hold a device with a valid passkey and can verify on it. The device signs a unique challenge with the hardware-held private key, and Beyond Identity verifies the signature. At the same time it evaluates user and device risk in real time and makes an access decision against your requirements. Device trust is a condition of access on every attempt, not just at enrollment.

Sources & verification

Verified by ComparEdgeMethod: Vendor docs, official pages, and selected independent sources

Source	What was checked	Last checked
Beyondidentity Official	Official product page	July 10, 2026
Beyondidentity Developer docs	Universal Passkeys	July 10, 2026
Beyondidentity Security And Compliance	Security And Compliance	July 10, 2026
GitHub Gobeyondidentity Bi Sdk Js	Gobeyondidentity Bi SDK Js	July 10, 2026

Every fact on this Beyond Identity page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.