> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify contacts with a Microsoft Authenticator push

> Connect a client's Microsoft tenant to Thread Verify and send a Microsoft Authenticator number-match push to confirm an end user's identity in Inbox.

<Note>
  Microsoft Authenticator verification is a limited-availability feature in
  partner beta. Contact your Thread representative if you'd like to enable it
  for your workspace, and see [Verify: End-User Identity
  Verification](/inbox/verify) for the SMS and email methods that are already
  live for every workspace.
</Note>

Microsoft Authenticator push adds a second way to run an end-user identity challenge from Thread Inbox. Instead of sending an OTP magic link over SMS or email, Thread Verify triggers a **number-match push** through the contact's Microsoft Authenticator app. The two-digit code appears in the ticket as an external note, the end user matches it in Authenticator, and the outcome is written back to the ticket the moment Microsoft confirms it.

Use this page to connect a client's Microsoft 365 tenant to Thread Verify, then send a push challenge from a ticket.

## How it works

The push method works per client company. Each client whose contacts you want to verify with Authenticator needs to authorize Thread Verify against their own Microsoft 365 tenant once. After consent:

* Thread reads the contact's Authenticator registration status from Microsoft Graph, so technicians only see the Authenticator option for contacts who actually have it registered.
* When a technician chooses **Microsoft Authenticator** on a verification challenge, Thread issues a number-match push to that user's Authenticator app.
* The two-digit match code posts to the ticket as an **external** note, so the end user can see it on whichever channel the thread is running on.
* Every other lifecycle event — requested, approved, denied, undelivered, timed out — posts as an **internal** note, matching how the existing SMS flow already behaves.
* A push challenge lives for a much shorter window than a magic link (about five minutes by default) because Authenticator pushes themselves are short-lived.

SMS and email magic-link challenges continue to work exactly as they do on [Verify: End-User Identity Verification](/inbox/verify). Microsoft Authenticator is an additional method, not a replacement.

## Prerequisites

Before you connect a client tenant, confirm:

* **End-user verification is enabled** on your workspace. If Verify isn't in Admin yet, contact your Thread representative to turn it on.
* **The Microsoft Authenticator method is enabled** on your workspace. This is the beta toggle that surfaces the Microsoft Authenticator option in Admin and in the technician's verification modal.
* **The client company already has contacts in Thread with email addresses on their Microsoft tenant's verified domains.** Thread checks the consenting tenant's verified domains against the contact emails it has on file for that client before it accepts the connection, so a client with no contacts on file yet cannot be connected.
* **A Global Administrator of the client's Microsoft 365 tenant** is available to grant admin consent. The consent link Thread generates can only be completed by a tenant admin.

## Connect a client tenant

<Steps>
  <Step title="Open the client in End User Verification">
    In Admin, go to **End User Verification**, open the **Integrations** tab, and find the client company you want to connect.
  </Step>

  <Step title="Generate a consent link">
    Select **Connect Microsoft tenant** on the client's row. Thread generates a one-time, signed consent URL scoped to that specific client company.

    Copy the link, or send it directly to the tenant admin from your email client. The link is a bearer for that client — anyone who completes it consents on that client's behalf — so treat it like any other admin invitation.
  </Step>

  <Step title="Have the tenant admin grant consent">
    The tenant admin opens the link, signs into Microsoft with a Global Administrator account, and approves the Thread Verify app registration.

    Thread reads the tenant id from the signed Microsoft id token returned to it, then checks the tenant's verified domains against the client's contact emails. The consent is only accepted when at least one contact email domain matches a verified domain on the consenting tenant.
  </Step>

  <Step title="Confirm the connection">
    Back in the **Integrations** tab, the client's row now shows as connected. The **Connected tenants** list shows every client whose tenant has already approved Thread Verify, so you can see coverage at a glance.
  </Step>
</Steps>

<Tip>
  If a tenant admin's consent is refused, the link stays valid so the admin can retry once the underlying issue is fixed. Only a consent that actually landed spends the link.
</Tip>

### Refusal reasons

Thread refuses a consent for one of these reasons. The refusal is logged, the link is not spent, and the tenant admin can retry.

* **`tenant_domain_mismatch`** — none of the consenting tenant's verified domains match a contact email on the client company. Confirm the tenant admin is signing in against the correct tenant, and that the client has at least one contact whose email is on a domain that tenant has verified.
* **`tenant_domain_unverifiable`** — Thread couldn't read the tenant's verified domains from Microsoft Graph. The most common cause is that the Thread Verify app registration is missing the `Domain.Read.All` (Application) permission. Contact your Thread representative.
* **`tenant_already_linked`** — the consenting tenant is already connected to a different client company in your workspace. A tenant can only be bound to one client at a time; disconnect the existing binding first if this is intentional.
* **`invalid_state`** — the consent link is expired or already spent. Generate a fresh one from the Integrations tab.

## Send a Microsoft Authenticator push from a ticket

<Steps>
  <Step title="Open the ticket in Inbox">
    Open the thread you want to verify the contact on, then open the actions list on the ticket.
  </Step>

  <Step title="Start a verification">
    Choose the **Verify** action to open the verification modal. Thread shows the methods available for this specific contact.

    **Microsoft Authenticator** appears in the method list only when both are true: the contact's client company has a connected Microsoft tenant, and the contact's Microsoft user has Microsoft Authenticator registered as an authentication method. If either is missing, the option is hidden and SMS or email remain available.
  </Step>

  <Step title="Send the push">
    Pick **Microsoft Authenticator** and send. Thread issues the challenge and posts an internal note that a push has been requested.

    Within a few seconds, Thread posts an **external** note on the thread that carries the two-digit number the end user needs to match in Authenticator. Because this note is external, it travels out on whichever channel the thread is on — Messenger, Microsoft Teams, email — so the end user sees the number the same way they see any other reply.
  </Step>

  <Step title="Wait for the outcome">
    When the end user approves the push in Authenticator, Thread posts an internal note that the verification succeeded, and the ticket is now treated as verified for downstream consumers like Voice Shield.

    A denied push, an undelivered push, or a timeout each post their own internal note explaining what happened, so the technician always sees why a challenge didn't complete.
  </Step>
</Steps>

## Disconnect a client tenant

Open the client's row in the **Integrations** tab and choose **Disconnect**. Thread removes the tenant binding for that client company. Any in-flight push challenges finish out on their existing tenant; new challenges for that client fall back to SMS or email until a fresh consent is granted.

## Activity log

Microsoft Authenticator challenges appear in the same verification activity table described on [Verify: End-User Identity Verification](/inbox/verify), alongside SMS and email challenges. Each entry captures the method used, the outcome, and, for a denied or undelivered push, the specific failure reason Microsoft returned.


## Related topics

- [MFA Methods Audit](/skill-library/m365-administration/mfa-methods-audit.md)
- [Duo MFA Anomalies](/skill-library/vendor-runbooks/duo-mfa-anomalies.md)
- [MFA Fatigue Attack Response](/skill-library/security/mfa-fatigue-attack-response.md)