How to configure Beyond Identity Secure Work as a Microsoft Entra External MFA (EAM) method

A step-by-step, no-surprises walkthrough: create the OIDC client in Beyond Identity, register the app and the external method in Microsoft Entra ID, register your pilot users, enforce it with Conditional Access, and test the sign-in.

At a glance

Microsoft Entra's External MFA (EAM, "external authentication methods") lets a third-party OpenID Connect provider satisfy Entra's multifactor requirement. Entra performs the first factor (the user's password), then hands the user to Beyond Identity, where the user approves with a passkey, and Entra accepts the result as MFA.

What you'll configure

• An OIDC client in Beyond Identity Secure Work
• An app registration in Microsoft Entra
• The external MFA method in Entra
• A pilot group and per-user registration
• A Conditional Access policy that requires MFA

Time

≈ 30 min

plus the time Beyond Identity needs to enable Entra request verification (see "Send three values to Beyond Identity")

Roles you need

• Entra: Global Administrator, or Authentication Policy Administrator + Conditional Access Administrator + Privileged Role Administrator (for consent)
• Beyond Identity: Secure Work administrator

Before you begin

Which Beyond Identity product? This guide is for Secure Work (admin console at admin.byndid.com). Secure Work has no "Entra ID (External Authentication Methods)" application in its catalogue; you create a standard OIDC client with Login Hint Validation instead (Step 1). Other public Beyond Identity articles about Entra EAM describe the Secure Access product and do not apply here.

Values worksheet

Worksheet keys are printed in square brackets throughout this article: [A] to [C] are fixed values, [1] to [6] are values you generate. Write the generated values in the boxes as each step produces them; later steps refer to them by key.

Fixed values (pre-filled)

Generated values (fill in as you go)

Not needed: the Beyond Identity client secret. Entra's external MFA flow uses the implicit flow with ID tokens, so the secret is never used. Do not copy it anywhere.

Step 1: Create the OIDC client in Beyond Identity

Where: Beyond Identity · Secure Work admin console

Go to: Beyond Identity admin console → Integrations → OIDC tab → Add OIDC Client

URL: https://admin.byndid.com (EU: https://admin-eu.byndid.com)

You need: [A]Entra redirect URI

You'll get: [1]BI Client ID

Actions

1. Sign in to the admin console. If the new console opens, use its link to the classic console; the Integrations page is in the classic console.
2. In the left menu choose Integrations, open the OIDC tab and click Add OIDC Client.
3. Fill in the form exactly as in the table below.
4. Click Save Changes.
5. In the OIDC Clients list, find your new client and copy the Client ID (use the copy icon next to it). Write it in the worksheet as [1].

Expected result

The client appears under OIDC Clients with a Client ID and a masked Client Secret. Only the Client ID is needed ([1]).

Why Login Hint Validation matters. Entra passes the signing-in user's identity to Beyond Identity as a login hint. With validation enabled, Beyond Identity only authenticates the user that Entra named, matched by the strategies you selected. Leave it enabled.

Step 1 · The Add OIDC Client form, filled in. The Redirect URIs field shows the end of the Entra redirect URI; Login Hint Validation is Enabled with EMAIL + USER_NAME selected.

Step 1 · After saving: the client in the OIDC Clients list. Copy the Client ID (worksheet [1] ); the secret is not needed.

Step 2: Register an application in Entra

Where: Microsoft Entra admin center

Go to: Microsoft Entra admin center → Entra ID → App registrations → New registration

URL: https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/CreateApplicationBlade/quickStartType~/null/isMSAApp~/false

You need: [B]BI authorization endpoint

You'll get: [2]Entra App ID; [3]App registration name

Actions – part 1: register

1. Open the Register an application form (URL above, or Entra ID → App registrations → New registration).
2. Fill it in as in the table below and click Register.
3. On the app's Overview page copy the Application (client) ID and write it in the worksheet as [2]. Write the name you chose as [3].

The redirect URI must be exactly Beyond Identity's authorization endpoint ([B]). Entra validates it against the provider's discovery document; any other value produces AADSTS50161: Failed to validate authorization url of external claims provider at sign-in time.

If the portal jumps to Home after Register and the new app is missing from "Owned applications", open App registrations and switch to the All applications tab. The app is there.

Step 2 · Register an application: name, single tenant, and the Web redirect URI set to the Beyond Identity authorization endpoint.

Actions – part 2: ID tokens and permissions

1. Open the app ([3]) → Authentication → Settings tab. (In the older experience the same checkbox is on the Authentication page under "Implicit grant and hybrid flows".)
2. Tick ID tokens (used for implicit and hybrid flows). Leave "Access tokens" unticked.
3. Click Save.
4. Go to API permissions → Add a permission → Microsoft Graph → Delegated permissions.
5. Tick openid and profile (type them in the search box to find them under OpenId permissions) and click Add permissions.

Expected result

API permissions lists Microsoft Graph with openid and profile (Delegated). The Status column is still empty: consent is granted in Step 3.

Step 2 · Authentication → Settings: "ID tokens (used for implicit and hybrid flows)" ticked, then Save.

Send three values to Beyond Identity

Where: e-mail or support ticket to Beyond Identity

Do this after Step 2. Beyond Identity uses these values to enable Entra request verification on your tenant, so that Beyond Identity accepts external MFA requests only from your Entra tenant. You can continue with Steps 3 to 6 while you wait. Run the test in Step 7 after Beyond Identity confirms.

Also include the name of your Beyond Identity tenant and its region (US or EU).

Do not send the client secret. None of the three values is a secret. The Beyond Identity client secret is not used by this integration and must not be shared.

Entra app registration → Overview: the Application (client) ID and the Directory (tenant) ID to send.

Beyond Identity admin console → Integrations → OIDC: the Client ID to send.

Step 3: Add the external MFA method in Entra

Where: Microsoft Entra admin center

Go to: Microsoft Entra admin center → Entra ID → Protection → Authentication methods → Policies → Add external multifactor authentication

URL: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods

You need: [1]BI Client ID; [2]Entra App ID; [3]App registration name; [C]BI discovery endpoint

You'll get: [4]External method name

Actions

1. On the Authentication methods → Policies page click Add external multifactor authentication (above the list of methods).
2. Fill in the four properties as in the table below. Then re-read the Name field: the form can drop the first value typed while the page is still loading.
3. Click Request permission. A Microsoft sign-in window opens: sign in as the administrator and click Accept on the consent prompt. Write the method name in the worksheet as [4].
4. Click Save. Leave Enable Off for now; Step 4 turns it on after the pilot group exists.
5. Verify consent, regardless of what the portal says: Entra ID → App registrations → All applications → [3] → API permissions. The Status of openid and profile must read Granted for <your tenant>.
6. If consent really is missing, grant it there: on the same API permissions page click Grant admin consent for <your tenant> → Yes.

Step 3 · The form filled in: Name, Client ID [1] , the discovery endpoint [C] and App ID [2] . "Request permission" becomes active once all fields are filled.

"Failed to request permission" is usually a false alarm. After you accept the consent prompt, the portal may show a red "Failed to request permission" under the button even though consent succeeded (the consent window ends on the provider's page, so the portal never receives its callback). Always verify on the app's API permissions page (action 5). Do not click Request permission repeatedly.

Expected result

The method is listed under Authentication methods → Policies → External with your name [4]. Reopen it: the "Your tenant administrator must grant consent" warning is gone and the Enable switch is active (still Off). On the app's API permissions page, openid and profile show a green check with "Granted for <your tenant>".

Step 3 · The misleading "Failed to request permission" message shown after a successful consent.

Step 3 · The proof that consent worked: App registrations → [3] → API permissions shows openid and profile "Granted for <your tenant>".

Step 4: Create the pilot group and target the method

Where: Microsoft Entra admin center

Go to: Microsoft Entra admin center → Entra ID → Groups → All groups → New group; then Authentication methods → Policies → your method

URL: https://entra.microsoft.com

You need: [4]External method name

You'll get: [5]Pilot group name; [6]Pilot user(s)

Actions – part 1: the pilot group

1. Entra ID → Groups → All groups → New group.
2. Fill in the group as in the table below and add your pilot users as Members. Click Create.
3. Write the group name in the worksheet as [5] and the pilot users' UPNs as [6].

Actions – part 2: enable the method for the group

1. Go to Authentication methods → Policies (URL: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods) and click your method [4].
2. On the Enable and target tab, in Include, click Add target → Select targets and pick the group [5]. It replaces the default target "All users".
3. Switch Enable to On.
4. Click Save.

Expected result

The toast "The policy was successfully saved" appears. In the Authentication methods list the method shows Enabled: Yes with your group as the target.

Why a pilot group? Targeting a group lets you turn the method and the Conditional Access policy (Step 6) on for a few users first. Widen the group when you are ready; the method and policy do not need to change.

Step 4 · The method's Enable and target tab: Enable On, Include = the pilot group [5] .

Step 5: Register External MFA for each pilot user

Where: Microsoft Entra admin center

Go to: Microsoft Entra admin center → Entra ID → Users → All users → the pilot user → Authentication methods → Add authentication method

URL: https://entra.microsoft.com

You need: [4]External method name; [6]Pilot user(s)

You'll get: Each pilot user has the method registered

Do not skip this step. Enabling the method and targeting the group is not enough: Entra only offers an external method to users who have it registered. Without registration, the "Verify your identity" page shows only the user's other methods (or, if there are none, something unrelated such as "Use a certificate or smart card"), and the user never reaches Beyond Identity. Most public guides leave this step out.

Actions (per pilot user, as an administrator)

1. Entra ID → Users → All users → open the pilot user ([6]).
2. In the user's left menu click Authentication methods.
3. Click Add authentication method.
4. In Choose method select External MFA.
5. Tick your method [4] (other external methods in your tenant, if any, are listed too) and click Add.
6. Repeat for every pilot user.

Expected result

Under Usable authentication methods the user now lists External MFA with the detail [4].

Alternatives

• Self-service: the user signs in at https://mysignins.microsoft.com/security-info → Add sign-in method → External Auth methods → your method.
• Registration wizard at sign-in: Entra prompts the user to register during sign-in, but only if the user has no other usable MFA method. If another method is usable (for example certificate-based authentication enabled for all users), the wizard does not appear.
• At scale: registrations can be created with Microsoft Graph through the user's externalAuthenticationMethod resource (under the user's authentication methods). Refer to Microsoft's Graph documentation for the current request format.

Step 5 · User → Authentication methods → Add authentication method → External MFA → your method ticked → Add. Before this, "Usable authentication methods" said "No usable methods".

Step 5 · Result: the user's usable methods list External MFA with your method name [4] .

Step 6: Create the Conditional Access policy

Where: Microsoft Entra admin center

Go to: Microsoft Entra admin center → Entra ID → Conditional Access → Policies → New policy

URL: https://entra.microsoft.com/#view/Microsoft_AAD_ConditionalAccess/ConditionalAccessBlade/~/Policies

You need: [5]Pilot group name

You'll get: A policy that requires MFA for the pilot group

Actions

1. Click New policy and give it a name, for example Pilot – require MFA (Beyond Identity).
2. Users → Include → Select users and groups → tick Users and groups → pick the group [5] → Select.
3. Target resources → Include → All resources (formerly 'All cloud apps'), or select the specific application you will test with.
4. Grant → Grant access → tick Require multifactor authentication → Select.
5. Under Enable policy choose On.
6. Click Create.

Use "Require multifactor authentication", not an authentication strength. An external method satisfies the MFA requirement, but it does not satisfy authentication-strength controls (such as "Phishing-resistant MFA"). A policy built on an authentication strength will never send users to Beyond Identity.

State must be On. "Report-only" evaluates the policy but never challenges the user, so the flow never reaches Beyond Identity.

"Don't lock yourself out" warning. With "All resources" selected, Entra warns that the policy could lock out administrators. It is safe to confirm as long as only the pilot group is included and your admin account is not in it.

Licensing. Conditional Access needs Entra ID P1 in the tenant. For licence compliance, assign a P1 seat to each user who is covered by the policy.

Expected result

The policy appears in the Conditional Access policies list with State On.

Step 6 · The Grant pane: Grant access with "Require multifactor authentication" ticked. Remember to switch Enable policy from Report-only to On before Create.

Step 7: Test the sign-in

Where: Microsoft sign-in page → Beyond Identity

Go to: A private / incognito browser window on a device where the pilot user's Beyond Identity passkey is available (or the Beyond Identity authenticator is installed)

URL: https://myaccount.microsoft.com/?login_hint=<UPN>

You need: [6]A pilot user and their password; [4]External method name

You'll get: A sign-in where Beyond Identity satisfies MFA

Actions

1. Open a private window and go to https://myaccount.microsoft.com/?login_hint= followed by the pilot user's UPN ([6]). The login_hint pre-fills the user. Any application covered by the policy works, for example https://myapps.microsoft.com.
2. If the user is not pre-filled, enter the UPN ([6]) and click Next.
3. Enter the password on the Microsoft page. If you are redirected to another identity provider for the password, the user is federated; see "Before you begin" and Troubleshooting.
4. On Verify your identity, choose your method [4]. If it is the user's only usable method, Entra may skip the picker and redirect at once.
5. The browser is redirected to Beyond Identity. Approve with the user's passkey (the Beyond Identity authenticator or platform passkey prompt appears).
6. Beyond Identity returns the user to Entra, which completes the sign-in and opens the application.

Expected result

The user lands in the application without further prompts; with My Account, on the "Welcome back" home page. In Entra ID → Sign-in logs, the sign-in shows Status Success, and the Conditional Access tab shows your pilot policy with Result Success.

The sign-in log does not name Beyond Identity. For a successful external MFA sign-in, Entra records Additional details "MFA requirement satisfied by claim in the token", and Authentication Details lists only Previously satisfied rows. Neither your method's name nor a password row appears. This is how Entra logs it; it is not a sign that the step was skipped.

Step 7 · Success: the pilot user lands on My Account after the password, the Beyond Identity redirect and the passkey approval.

Step 7 · The successful sign-in in Entra's sign-in log: Authentication Details shows "Previously satisfied" for the first factor and for MFA.

What happens after the redirect. Entra sends an OpenID Connect request to Beyond Identity's authorization endpoint with an identity hint for the user. Beyond Identity verifies the hint against the login-hint strategies from Step 1, authenticates the user with their passkey, and returns an ID token to Entra's redirect URI [A]. Entra validates the token and treats the sign-in as MFA-satisfied. This is the behaviour Microsoft documents for external authentication methods.

If the test fails

• Note exactly where it stops (Microsoft page, Beyond Identity page, or back at Microsoft with an AADSTS code) and consult the Troubleshooting table below.
• In Entra ID → Sign-in logs, open the attempt and read Authentication Details and the error code; for a failure they show the reason.
• Do not retry a wrong password many times: Entra smart lockout locks the account after repeated failures (default threshold 10).

Troubleshooting

Symptom: "Verify your identity" without your method. Here only "Use a certificate or smart card" is offered because the user had no External MFA registration (Step 5).

Symptom: the Beyond Identity error page "Invalid OIDC request: unknown client_id". Check the Client ID first; if it is correct, contact Beyond Identity support.

Appendix A: Disable or roll back

To pause the integration, do only item 1. To remove it completely, follow the order below: switch off what affects sign-ins first, then delete the objects.

Deleting the external method in Entra while users are still targeted by a Conditional Access policy that requires MFA leaves them with their other registered methods only. Always do item 1 first.

Appendix B: Glossary

Status. Validated end to end against Microsoft Entra ID and Beyond Identity Secure Work (US) in November 2026: password in Entra, redirect to Beyond Identity, passkey approval, and return to Entra with the sign-in completed. Portal labels and layouts change over time; if a menu item has moved, use the portal search box with the same name.