Types of Azure Portal Authentication

Question

Types of Azure Portal Authentication

AzureTest04 180

I have a question regarding authentication when logging in to Azure Portal.

What authentication methods other than a password can be used as primary authentication when logging in to Azure Portal?

Please provide all applicable methods for both Microsoft Accounts and Microsoft Entra ID.

Additionally, if there are any official documents that describe these authentication methods, please share them.

Also, if authentication via external Identity Providers (IdP) is possible, please let me know which ones are supported.

0 comments

1 answer

Your answer

Answer 1

Marcin Policht 86,455 MVP Volunteer Moderator

For the Azure Portal, authentication is performed through Microsoft’s identity platform. The available primary authentication methods depend on whether the user signs in with a Microsoft Account (MSA) or with a Microsoft Entra ID (formerly Azure AD) account. In both cases, Microsoft has expanded passwordless sign-in so that several methods can function as the primary factor rather than a password.

For Microsoft Entra ID accounts, the following methods can be used as primary authentication without a password when the tenant is configured to allow them. FIDO2 security keys are supported for passwordless sign-in. These are hardware or platform authenticators compliant with the FIDO2/WebAuthn standard and can include USB, NFC, or Bluetooth security keys as well as platform authenticators such as Windows Hello backed by TPM. Windows Hello for Business can be used as a primary authentication method when signing in from a Windows device joined to Entra ID or hybrid joined to Active Directory; the private key stored in the TPM is used instead of a password. Microsoft Authenticator passwordless phone sign-in allows the user to enter their username and approve a number-matching prompt in the Microsoft Authenticator app, replacing the password. Passkeys (which are implemented through FIDO2/WebAuthn and may be stored on devices or synced through passkey providers) are also supported as passwordless authentication for Entra ID when enabled. Certificate-based authentication using client certificates can also function as a primary authentication method for Entra ID users when configured in the tenant; the user presents an X.509 certificate mapped to their account. Smart cards can be used when integrated with certificate-based authentication because they provide the certificate and private key. Temporary Access Pass can be configured as a time-limited primary credential used to bootstrap passwordless methods or sign in without a password. In some federated environments, Kerberos-based Integrated Windows Authentication can also serve as the primary authentication mechanism when the browser is domain-joined and accessing a federated identity provider.

For Microsoft Accounts (personal accounts such as Outlook.com, Hotmail.com, etc.), passwordless sign-in is also supported. Microsoft Authenticator passwordless phone sign-in can act as the primary authentication method. FIDO2 security keys and passkeys are supported as passwordless authentication methods for Microsoft Accounts and can be used directly instead of passwords when signing in. Windows Hello can be used as a passkey provider on supported devices and effectively acts as the primary authentication factor for the Microsoft Account on that device.

External identity providers can be used with Azure Portal only when authentication is federated to Microsoft Entra ID or when external identities are configured. In a federated Entra ID tenant, authentication can be redirected to an external IdP using standards such as SAML 2.0, WS-Federation, or OpenID Connect. The most common supported enterprise identity providers include Active Directory Federation Services (AD FS), PingFederate, Okta, Shibboleth, and other SAML 2.0 or OIDC-compatible providers. When a tenant is federated, the external IdP performs the primary authentication and returns a token to Microsoft Entra ID, which then grants access to Azure Portal. Entra ID B2B collaboration also allows external users to authenticate using their home identity provider (another Entra ID tenant, Microsoft Account, Google identity, or SAML/WS-Fed federation depending on configuration). However, Azure Portal access still ultimately depends on Entra ID issuing the final token for the portal.

Relevant official Microsoft documentation describing these authentication methods includes the following.

Microsoft Entra authentication methods overview https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods

Passwordless authentication options in Microsoft Entra ID https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless

FIDO2 security key authentication https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key

Windows Hello for Business authentication https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-overview

Certificate-based authentication in Microsoft Entra ID https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication

Temporary Access Pass https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass

Identity federation with Microsoft Entra ID https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed

External identities and federation in Microsoft Entra ID https://learn.microsoft.com/en-us/entra/external-id/external-identities-overview

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

AzureTest04 180 Reputation points

2026-03-05T13:26:03.41+00:00

Thank you.

To authenticate to the Azure Portal using Microsoft Entra ID, is it correct that any authentication method marked “Yes” under Primary authentication on the following site can be used?

Link: https://learn.microsoft.com/ja-jp/entra/identity/authentication/overview-authentication

Also, if there is a website that lists the available authentication methods for Microsoft accounts, please let me know.

For Microsoft Accounts (personal accounts such as Outlook.com, Hotmail.com, etc.), passwordless sign-in is also supported. Microsoft Authenticator passwordless phone sign-in can act as the primary authentication method. FIDO2 security keys and passkeys are supported as passwordless authentication methods for Microsoft Accounts and can be used directly instead of passwords when signing in. Windows Hello can be used as a passkey provider on supported devices and effectively acts as the primary authentication factor for the Microsoft Account on that device.
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-03-05T14:28:14.8733333+00:00

Yep - in general this is correct. The Microsoft Entra authentication overview page you referenced describes the authentication methods supported by Microsoft Entra ID and indicates which ones can function as primary authentication. Any method marked “Yes” under “Primary authentication” can technically serve as the initial sign-in credential for Microsoft Entra ID, provided the tenant configuration enables the method and the sign-in flow being used supports it. Because Azure Portal authentication ultimately relies on Microsoft Entra ID for organizational accounts, those primary authentication methods can be used to sign in to the Azure Portal as well. In practice this includes passwordless methods such as FIDO2 security keys, passkeys based on the WebAuthn/FIDO2 standard, Microsoft Authenticator phone sign-in, Windows Hello for Business, certificate-based authentication (including smart cards), and Temporary Access Pass. Note that whether a user can actually authenticate using one of these methods depends on tenant policy configuration, Conditional Access rules, authentication method policies, and whether the method is supported in the browser or device context used to access the portal.

There are also some nuances to be aware of. The “Primary authentication” column indicates that the method can act as the initial factor used to obtain a token from Microsoft Entra ID, but it does not guarantee universal support across all protocols or device states. For example, Windows Hello for Business normally acts as the primary credential on a joined Windows device and results in a PRT (Primary Refresh Token) that is then used by the browser to access Azure resources such as the portal. Certificate-based authentication can be primary authentication in browser-based sign-in flows when configured. Temporary Access Pass is designed primarily as a bootstrap method for passwordless enrollment but can also be used as a primary credential during its validity period. FIDO2 security keys and passkeys are the most common direct passwordless browser authentication method for Azure Portal.

For Microsoft Accounts (MSA), the set of available authentication methods are separate from Microsoft Entra ID because the identity platform and configuration model differ. I'm not aware of a single table exactly like the Entra “authentication methods overview,” but the supported passwordless and strong authentication options for Microsoft Accounts include Microsoft Authenticator passwordless phone sign-in, FIDO2 security keys and passkeys, and Windows Hello acting as a device-bound passkey provider. These methods allow passwordless sign-in and function as the primary authentication factor for the Microsoft Account.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
AzureTest04 180 Reputation points

2026-03-06T01:41:01.3666667+00:00

Thank you.I understand that, unlike Entra ID, there is no document that consolidates authentication methods for Microsoft accounts.

I would like to ask about integration with external IdPs. You mentioned that Okta and Shibboleth are supported as external IdPs. If there is any documentation that states this as the basis for that information, could you please share the link?
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-03-06T04:17:52.92+00:00

Microsoft Entra ID supports federation with external identity providers that implement standard federation protocols such as SAML 2.0, WS-Federation, and OpenID Connect. Microsoft documentation generally describes support in terms of these standards rather than listing every compatible vendor. Because Okta and Shibboleth both support SAML 2.0 and OpenID Connect, they can be used as external identity providers when federating with Microsoft Entra ID.

Microsoft documentation confirming that Entra ID can federate with any IdP supporting these standards is here:

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed

This page explains that organizations can federate Microsoft Entra ID with external identity providers using SAML 2.0 or WS-Federation.

Documentation specifically describing SAML-based federation with external identity providers is here:

https://learn.microsoft.com/en-us/entra/external-id/direct-federation

This page explains that Microsoft Entra ID supports direct federation with identity providers that support the SAML 2.0 protocol.

Because Okta and Shibboleth both provide SAML 2.0 identity provider functionality, Microsoft documentation and vendor documentation show interoperability. Okta provides official configuration guidance for federating Okta with Microsoft Entra ID:

https://help.okta.com/en-us/Content/Topics/Provisioning/azure/azure-identify-identity-provider.htm

Regarding Shibboleth, Microsoft Entra ID supports federation with identity providers that supports the SAML 2.0 protocol. Microsoft documentation confirming SAML-based federation support is here:

https://learn.microsoft.com/en-us/entra/external-id/direct-federation

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
AzureTest04 180 Reputation points

2026-03-06T06:25:09.95+00:00

Thank you.

I understand that when using Microsoft Entra ID, it is possible to integrate with an IdP.

If such integration is configured, is it correct to assume that it applies not only when logging in to the Azure Portal, but also when performing interactive authentication using Azure CLI or Azure PowerShell?
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-03-06T12:04:58.7566667+00:00

Yep - federation in Microsoft Entra ID applies to the tenant’s authentication process itself rather than to a specific application or client. Therefore, if the tenant is configured to use an external identity provider, the same federation redirect occurs during interactive authentication regardless of the client being used. This includes the Azure Portal as well as interactive authentication through Azure CLI or Azure PowerShell.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
AzureTest04 180 Reputation points

2026-03-08T13:21:38.06+00:00

Thank you.

When MFA is applied to a Microsoft Entra ID account, my understanding is that after entering the account ID (email address) on the Azure sign-in screen, the user remains on the Azure login screen and completes the primary authentication followed by the secondary authentication (MFA) before signing in to the Azure Portal.

First, is my understanding correct?

Also, regarding the behavior when federating with an IdP, after entering the account ID (email address) on the Azure login screen, is the user redirected to the authentication screen of the federated IdP (such as Okta or AD FS) instead of continuing on the Azure login screen, and then signed in to the Azure Portal after completing authentication there?
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-03-08T15:27:54.7566667+00:00

Yes, your understanding is correct. When MFA is applied to a Microsoft Entra ID account, after entering the account ID on the Azure login screen, the user completes both primary authentication (password or passwordless) and secondary authentication (MFA) before accessing the Azure Portal.

When federating with an external IdP, after entering the account ID, the user is redirected to the federated IdP's authentication screen (e.g., Okta, AD FS) for primary authentication. Once authenticated there, the user is then redirected back to Azure for sign-in and can access the Azure Portal.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
AzureTest04 180 Reputation points

2026-03-09T00:06:14.3966667+00:00

Thank you.

I understand that MFA is currently being enforced when signing in to the Azure Portal. In this case, if it is integrated with dp and the user passes the primary authentication on the IdP side and is able to log in to the Azure Portal, I believe that would not count as MFA. How does Azure behave in that situation?
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-03-11T12:12:44.42+00:00

Logon to the Azure portal does require MFA

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

Types of Azure Portal Authentication

1 answer

Your answer