Skip to content
Help Center
withpersona.comDashboard

Using Persona Workflows to manage Microsoft Entra users & profiles

Last updated on .

View Markdown Contact support Contact support 10 min read
On this page

Overview

Microsoft Entra ID is an identity management platform. It helps organizations manage secure access to applications and resources. When you integrate Microsoft Entra ID with Persona, you can use Persona identity verification in the Microsoft ecosystem. Use it to manage employee authentication and account recovery workflows, including password resets, MFA method revocation, and passkey (FIDO2) registration.

Prerequisites

To set up the Microsoft Entra ID integration with Persona, you need:

  • A Microsoft Entra tenant that is configured for service.
  • A completed onboarding process with Persona. To create an account, register through the Persona Dashboard.

Connect Microsoft Entra ID to your Persona account

Go to the Marketplace integrations in your Persona dashboard and select Microsoft Entra ID.

Microsoft Entra ID supports two authentication methods:

  1. Delegated permissions (default) — lets you manage all user authentication methods.
  2. Application permissions (app-only) — lets you do a limited set of authentication method operations.

For more information about the differences between these permission types, read the Microsoft documentation on delegated and application permissions.

Option 1: Delegated permissions

With delegated permissions, Persona acts for a signed-in user and accesses a range of Microsoft Graph authentication methods APIs. The permissions of the authorizing user control which Microsoft Entra ID operations Persona can do for the user.

Supported operations and associated permissions:

  • Get user - User.Read.All, CustomSecAttributeAssignment.Read.All
  • Get user by email - User.Read.All
  • Create a user - User.ReadWrite.All
  • Update a user - User.ReadWrite.All, User-PasswordProfile.ReadWrite.All
  • List authentication methods - UserAuthenticationMethod.ReadWrite.All
  • Delete authentication method - UserAuthenticationMethod.ReadWrite.All
  • Reset password - UserAuthenticationMethod.ReadWrite.All
  • Create temporary access pass - UserAuthenticationMethod.ReadWrite.All
  • List passkeys - UserAuthenticationMethod.Read.All
  • Get passkey creation options - UserAuthenticationMethod.ReadWrite.All
  • Register a passkey - UserAuthenticationMethod.ReadWrite.All

Setup steps:

  1. Select + Add credential. Select Microsoft Entra Authorization.
  2. Give this credential a name (for example, “Persona”).
  3. Sign in to your Microsoft account.

Note: Persona needs the offline_access permission to keep access to Graph APIs.

Option 2: Application permissions (app-only)

With application permissions, Persona authenticates with its own identity (client credentials), not for a user. This is useful for automated scenarios that run with no person present. The permissions of the app control which Microsoft Entra ID operations Persona can do.

Supported operations and associated permissions:

  • Get user - User.ReadWrite.All
  • Get user by email - User.ReadWrite.All
  • Create a user - User.ReadWrite.All
  • Update a user - User.ReadWrite.All, User-PasswordProfile.ReadWrite.All
  • List authentication methods - UserAuthenticationMethod.ReadWrite.All
  • Delete authentication method - UserAuthenticationMethod.ReadWrite.All
  • Create temporary access pass - UserAuthenticationMethod.ReadWrite.All
  • List passkeys - UserAuthMethod-Passkey.Read.All
  • Get passkey creation options - UserAuthMethod-Passkey.ReadWrite.All
  • Register a passkey - UserAuthMethod-Passkey.ReadWrite.All

Unsupported operations:

  • Reset password — Microsoft does not support this operation with application-only permissions

If your use case requires password resets, you can use the Update a user request to update the password profile of a user.

Setting up app-only permissions

  1. In the Azure/Entra portal, go to App registrations (not Enterprise Applications).
  2. Select your Persona application or create a new app registration.
  3. Under Certificates & secrets, create a new client secret. Keep it in a secure location.
  4. Under API permissions, add the applicable Application permissions (not Delegated).
  5. Click Grant admin consent for your tenant.
  6. In your Persona dashboard, go to Marketplace Integrations. Search for Microsoft Entra.
  7. Select + Add credential.
  8. Give this credential a name (for example, “Persona App-Only”).
  9. Enter your:
    • Tenant ID
    • Client ID (Application ID)
    • Client Secret

Your employee’s experience

To help an employee reset their password, put their Entra ID in the inquiry URL before you send it. The Entra ID is usually their work email address. Your helpdesk can generate a Persona inquiry link that includes the Entra ID of the employee in the URL.

Persona uses this ID to get employee data from Microsoft Entra, for example name and date of birth. Persona can then verify that it is the correct person before it makes account updates.

After verification, Persona shows the employee a temporary password. The employee uses it to sign in at https://entra.microsoft.com. Entra then tells them to set a new password.

For more information about what the employee sees, read What to expect when verifying your identity with Persona to reset your Microsoft Entra ID password.

Resetting an employee’s MFA

The integration can also reset the multi-factor authentication (MFA) of an employee. To do this, it deletes a registered authentication method. This revokes that factor. The employee must then enroll it again at the next sign-in. Microsoft Graph does not have one “reset all factors” endpoint, as Okta does. Thus, MFA reset in Entra works one method at a time, with two operations in sequence:

  1. List authentication methods — gets the registered methods of the employee, so you can find the method to reset. The response includes the @odata.type (which maps to the method type) and the id of each method.
  2. Delete authentication method — deletes the specific method with its type and ID. This revokes that factor. At the next sign-in, Entra tells the employee to enroll it again, as your Entra policies specify.

The Method Type parameter selects the type of method to delete. It accepts one of these values:

  • softwareOathMethods
  • emailMethods
  • fido2Methods
  • microsoftAuthenticatorMethods
  • phoneMethods
  • platformCredentialMethods
  • temporaryAccessPassMethods
  • windowsHelloForBusinessMethods

Both operations require the UserAuthenticationMethod.ReadWrite.All permission. You can use both operations with delegated permissions or with application permissions. Unlike password reset, Microsoft Graph supports the deletion of all of the method types above with application-only permissions.

You cannot undo the deletion of an authentication method. The deletion revokes that factor immediately. Before you continue, make sure that you delete the correct method for the correct user. Before you revoke a factor, we recommend that you verify the identity of the employee with a Persona inquiry.

Managing an employee’s passkeys

The integration can list the passkeys (FIDO2) of an employee, register a new passkey for them, and remove a passkey. Use these operations, for example, to give a verified employee a new security key after they lose their old one.

Before you start

The passkey operations need more configuration in your Microsoft Entra tenant:

  1. In the Microsoft Entra admin center, go to Entra ID > Authentication methods > Policies and select Passkey (FIDO2).
  2. On Enable and Target, turn on the method. Include the employees who can get a passkey this way, or All users.
  3. On Configure, set Allow self-service set up to Yes. The provisioning operations fail without this setting, although only an administrator can use them. This is a known issue in Microsoft Graph.
  4. If Enforce attestation is on, make sure that your security keys are on the Microsoft list of attested vendors.
  5. Select Save.

For delegated permissions, the user who connects the integration must also have the Authentication Administrator or Privileged Authentication Administrator role in Entra. To only list passkeys, the Global Reader role is sufficient.

List passkeys

List passkeys gets the passkeys that are registered to an employee. For each passkey, the response includes:

  • The ID of the passkey
  • The display name and the date that it was created
  • The model of the authenticator
  • The attestation level (attested or notAttested)
  • The passkey type: device-bound (deviceBound) or synced (synced)

This operation works on the global, GCC High, and DoD clouds.

Register a passkey for an employee

To register a passkey for an employee, you do three steps. Persona does the first step and the last step. A provisioning client that your organization controls does the middle step on the security key.

  1. Get passkey creation options. Persona gets the WebAuthn options for the employee from Entra. The options include a challenge. The challenge expires after 5 minutes, so you must complete step 3 before then.

  2. Create the credential on the security key. Give the creation options to a CTAP or WebAuthn provisioning client that your organization controls. The client creates the credential on the security key of the employee. Persona cannot do this step, because the credential must be created on the security key itself.

    Each excludeCredentials ID in the creation options ends with one extra digit. The digit is the number of padding characters that Entra removed. Your client must remove this digit before it decodes the ID.

  3. Register a passkey. Persona sends the credential from the client to Entra. The request body contains a displayName and the publicKeyCredential. Encode each binary value as Base64URL without padding.

    {
  "displayName": "Security key",
  "publicKeyCredential": {
    "id": "CREDENTIAL_ID",
    "response": {
      "clientDataJSON": "CLIENT_DATA_JSON",
      "attestationObject": "ATTESTATION_OBJECT"
    }
  }
}

    If the registration is successful, the response includes the ID, model, and attestation level of the new passkey.

Entra trusts the public key that Register a passkey sends. Whoever holds the authenticator that created the credential can sign in as the employee without their password, and Entra counts that sign-in as phishing-resistant MFA. To prevent account takeover:

  • Send only a credential from a provisioning client that your organization controls.
  • Register a passkey only after Persona verifies that the person is the account owner.
  • Take the user ID from the Entra data that is stored on the Persona account. Do not take it from data that the end user enters.

Remove a passkey

To remove a passkey, use Delete authentication method. Set Method Type to FIDO2 Methods (fido2Methods), and set the method ID to the passkey ID from List passkeys.

This operation works with delegated permissions and with application permissions. With application permissions, UserAuthMethod-Passkey.ReadWrite.All is sufficient to remove a passkey, so you do not need UserAuthenticationMethod.ReadWrite.All for this method type.

Passkey limits

  • Get passkey creation options and Register a passkey work only on the global cloud. Microsoft does not supply passkey creation options in GCC High or DoD.
  • Entra accepts only the packed and none attestation formats.
  • Pre-registered passkeys (security keys that have credentials on them before delivery) are not supported.
  • Guest users and B2B users are not supported.

Frequently Asked Questions

What minimum permissions and scopes are required?

You must create a Microsoft Entra API credential with the applicable scopes. These include User.Read.All and UserAuthenticationMethod.ReadWrite.All. If you do not give these permissions, the integration setup fails with the message “Need admin approval: Persona needs permission to access resources in your organization that only an admin can grant.”

For delegated permissions: The signed-in user must have these delegated permissions and the applicable admin privileges.

For app-only permissions: Grant these application permissions to the application in the App registration. Also grant admin consent.

Can I reset all of an employee’s MFA factors at once?

No. Microsoft Graph does not have one endpoint that resets all factors at the same time. Thus, the integration resets MFA one method at a time. First, list the authentication methods of the employee. Then delete each method that you want to revoke. For each deleted method, the employee must enroll again at the next sign-in. Unlike password reset, this works with delegated permissions and with application permissions.

In many cases, employees may contact a helpdesk through ServiceNow or similar tools. The helpdesk can put the Entra ID of the employee in the inquiry URL before it sends the URL. Persona then gets data from Entra to verify the identity. After that, Persona does the configured authentication method operation. If you use password reset, Microsoft Entra makes the employee change their password at the next sign-in.

Plans Explained

Microsoft Entra Integration by plan

Startup ProgramEssential PlanGrowth PlanEnterprise Plan
Microsoft Entra IntegrationNot AvailableNot AvailableLimitedAvailable

Learn more about pricing and plans.

Was this page helpful?If something is missing, let us know and we will take a look.
Thanks for the feedback. It helps us improve these docs.

Related articles

FAQ: Workforce IDV
Marketplace and 3rd-Party Integrations · Workforce
What to expect when verifying your identity with Persona to reset your Microsoft Entra ID password
For users · Platform-specific verification guides