Does Passwordless Sign-In Count as MFA for Microsoft Apps?

Passwordless sign-in with Proximia is a Microsoft 365 sign-in method that, according to Proximia’s release notes, satisfies Microsoft’s MFA requirement for Microsoft applications such as Azure. Users who sign in to Microsoft 365 with Proximia do not need a second, separate authenticator. How this applies in a given environment depends on the organization’s Entra tenant configuration, so confirm it with the Proximia team before rollout.

• Proximia Connect 2026.3.5, dated September 22, 2026, describes MFA for Microsoft applications: users who sign in to Microsoft 365 with Proximia reach MFA-protected applications such as Azure without a second authenticator.
• Microsoft Entra ID decides whether MFA was performed by reading the sign-in token, and for SAML 2.0 federation Microsoft documents that the MFA assertion must be in the AuthnContext element of the AuthnStatement (Microsoft Learn, “Expected inbound assertions for MFA”).
• Whether Entra ID honors the MFA claim from a federated identity provider depends on the tenant’s federated MFA setting, so administrators should confirm how it applies to their tenant with the Proximia team.
• The capability covers sign-in through the Entra ID SAML flow only, not the Microsoft web session that follows.

What does it mean for Proximia to count as MFA for Microsoft?

It means Microsoft accepts one Proximia sign-in as the full MFA requirement, so the user does not carry or approve anything extra. Proximia’s Connect 2026.3.5 release notes, dated September 22, 2026, describe this capability.

Before this release, a user could sign in to Microsoft 365 with Proximia and still need a separate authenticator to open an MFA-protected application. Per the release notes, the user now signs in once, and Proximia tells Microsoft that MFA was performed. Proximia then serves as the user’s complete authenticator for the Microsoft applications that ask for it.

How does Microsoft decide that MFA was performed?

Microsoft Entra ID decides by reading the sign-in token, not by watching what the user did. Microsoft’s Conditional Access documentation describes the logic. If a valid MFA claim is not in the token, the user is interrupted and asked to complete MFA. If a valid claim is present, the requirement is met.

For sign-ins that arrive from an external SAML 2.0 identity provider, Microsoft documents where that signal must sit. Microsoft Learn, “Expected inbound assertions for MFA” (https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-expected-inbound-assertions), says the inbound MFA assertion must be present in the AuthnContext element of the AuthnStatement, and only one method can be presented that way.

Microsoft also documents a tenant-level setting for federated sign-ins. In Microsoft Graph, the federatedIdpMfaBehavior property “determines whether Microsoft Entra ID accepts the MFA performed by the federated IdP when a federated user accesses an application that is governed by a conditional access policy that requires MFA” (https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation). Microsoft lists three values:

• acceptIfMfaDoneByFederatedIdp: Entra ID accepts the provider’s MFA, and performs its own if the provider did not.
• enforceMfaByFederatedIdp: Entra ID accepts the provider’s MFA, and redirects the request to the provider if MFA was not done.
• rejectMfaByFederatedIdp: Entra ID always performs its own MFA and rejects the provider’s.

Microsoft’s page adds that if the property is never set, Entra ID honors the older SupportsMfa setting, and if neither is set, the default is acceptIfMfaDoneByFederatedIdp. That is Microsoft’s description of how Entra ID treats a federated provider’s MFA claim in general. How it applies to a given organization depends on that organization’s Entra tenant configuration, and it should be confirmed with the Proximia team before you plan the rollout.

Why can one sign-in replace a second authenticator?

One Proximia sign-in already combines two things, so a separate authenticator adds a step without adding a different kind of proof. Every Proximia sign-in requires a live biometric and a proximity device, which is either a XiFi Card or the user’s phone. The biometric is something the user is. The card or phone is something the user has.

Biometric matching is local, and raw biometric images are never stored or transmitted. In the Microsoft flow, Office forwards the user to Proximia’s sign-in page, where Proximia acts as the SAML identity provider. The user signs in with the phone app, or with face sign-in if they use a XiFi Card without the phone app. Sign-in takes about two seconds.

For IT admins, the gain is practical:

• No second authenticator app to enroll, issue, or support for Microsoft access.
• No separate approval prompt for the user to answer.
• One less enrollment step in onboarding, and one less thing to lose or replace.

The second point matters because a prompt that never appears cannot be approved by mistake. That is a narrow benefit, and it is real.

What does the integration depend on?

It depends on the Entra ID SAML flow, so it depends on how your directories are set up. What an organization gets follows from which directory services are in play:

• Active Directory and Entra ID together: the full result, with passwordless Windows sign-in plus Microsoft 365 and Entra ID app authentication through the SAML flow.
• Active Directory only, or Entra ID only: Windows sign-in works, but Microsoft 365 app access needs separate credentials, because the SAML flow needs Entra ID to be present.
• Local users only: Windows sign-in works, and Microsoft 365 integration is not possible.

A short planning list helps before you turn this on:

1. Confirm which of the three directory setups above describes your organization.
2. Review which Conditional Access policies require MFA, and for which applications.
3. Check how the federated MFA setting is configured for your tenant, and confirm with the Proximia team how it applies.
4. Run a pilot group through an MFA-protected application such as Azure and read the sign-in logs.
5. Decide what happens to existing authenticator registrations once the pilot passes.

For more on how passwordless approaches fit alongside existing identity investments, see Proximia’s article on passwordless authentication at proximia.com/passwordless-hybrid-authentication/.

What does it not change?

It does not change who owns the Microsoft session after sign-in. Microsoft controls token lifetime once authentication is done, so Proximia’s authentication for Microsoft web sign-in is a point-in-time event, not a continuous one. This is how SAML and OIDC federation work for any provider.

That has a few plain consequences:

• The local session and the Microsoft session are separate. Proximia’s persistent, presence-aware protection covers the local Windows, RDP, and VDI session. If a user walks away and the workstation locks, an already-open Microsoft 365 browser tab is not signed out. Locking is the same as the user locking the machine.
• The scope is Microsoft applications. The release describes MFA for Microsoft applications through Entra ID. It does not make Proximia an MFA source for every other application.
• Your policies still decide. Conditional Access still determines which applications require MFA. Proximia answers the requirement; it does not replace the policy.

Session theft after sign-in is a separate topic, covered in Proximia’s article on MFA and session hijacking at proximia.com/mfa-session-hijacking-authentication-bypass/. Naming the boundary clearly is what lets admins plan around it.

To see the Microsoft sign-in flow in your own environment, schedule a demo at proximia.com/contact-us.

Sources

• “Expected inbound assertions for MFA,” Microsoft Learn, Microsoft. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-expected-inbound-assertions
• “internalDomainFederation resource type,” Microsoft Graph documentation, Microsoft Learn (read 2026-10-15). https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation
• “Conditional Access: Grant,” Microsoft Learn, Microsoft. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant