Azure Authentication Methods: SSO, MFA, and Passwordless Sign-In

Single sign-on (SSO) lets someone authenticate once and reach every connected app without signing in again. Multifactor authentication (MFA) makes that one sign-in harder to fake by demanding a second, independent proof of identity. Passwordless authentication removes the password from the equation altogether, replacing it with a device or biometric credential. They aren’t competing options — a well-run Microsoft Entra ID tenant typically runs all three at once, each solving a different part of the sign-in problem.

Single sign-on: fewer prompts, not less security

SSO addresses a specific pain point: password fatigue. Without it, an employee juggling a dozen SaaS tools ends up remembering a dozen credentials, resetting the ones they forget, and generating a steady stream of help-desk tickets in the process. SSO fixes this by establishing a trusted session or token the first time a user authenticates, and every participating application then recognizes that token instead of demanding its own separate login.

That’s the whole feature — SSO governs how many times you’re asked to prove who you are, not how strong that proof needs to be. It doesn’t grant permissions, doesn’t touch what a signed-in user can do to a resource, and doesn’t replace the need to authenticate in the first place. A common exam trap frames SSO as bypassing authentication or as a way to share one account among a team; both misread what SSO actually does. It’s a convenience layer sitting on top of a single, still-required authentication event.

Multifactor authentication: layering independent proof

MFA solves a different problem: what happens after a password leaks. Passwords get phished, reused across sites, and occasionally guessed outright, so relying on a password alone means a single leaked credential is enough for a full account takeover. MFA closes that gap by requiring a second, independent form of verification before granting access.

Those verification methods fall into three recognized categories, and Microsoft’s documentation leans on this framework consistently:

• Something you know — a password or PIN.
• Something you have — a registered phone, a hardware token, or a Microsoft Authenticator app installed on a device.
• Something you are — a fingerprint or facial scan.

A valid MFA challenge combines factors from at least two different categories. Two passwords stacked together isn’t MFA — it’s still a single “something you know” factor typed twice. In Microsoft Entra ID, the practical options for that second factor include a Microsoft Authenticator push notification (tap to approve, no code to type), a phone call with a key press, an authenticator app generating a rotating code, or a registered phone number. Push notification approval is generally the fastest and most frictionless of these, since the user only confirms rather than reads and re-types anything.

Two license-related details matter here for AZ-900 purposes. Security defaults offer a free, fixed baseline that requires MFA for administrators without configuration, useful for a small organization on the free tier of Microsoft Entra ID. Anything more granular — MFA triggered only for certain apps, users, or risk levels — belongs to Conditional Access, which needs a Microsoft Entra ID P1 license. That distinction, along with how Conditional Access uses risk signals and device compliance to make access decisions, is covered in full in the Azure RBAC vs. Conditional Access article.

Passwordless authentication: removing the password entirely

MFA still usually keeps a password as one of its factors. Passwordless authentication goes a step further and removes it completely, replacing it with a credential built from something you have plus something you are or know. Two methods show up repeatedly on the AZ-900 exam:

Windows Hello for Business ties sign-in to a specific device: the user unlocks it with a PIN or a biometric gesture — fingerprint or face — and that credential never leaves the device or travels over the network the way a typed password does. It’s a natural fit for employees who each use their own registered laptop or desktop.

FIDO2 security keys are physical hardware devices, tapped or plugged in to authenticate, built on an open standard from the FIDO Alliance rather than anything Microsoft-specific. Because the credential lives on the key itself rather than tied to a personal device, FIDO2 is the better answer whenever a scenario describes shared kiosks or shop-floor workers who don’t carry personal smartphones — the key travels with the worker, not with any one workstation.

Passwordless doesn’t mean unverified. It still requires genuine proof of identity; it just sources that proof from possession and biometrics instead of a memorized string.

SSO, MFA, and passwordless compared

	Single sign-on	Multifactor authentication	Passwordless authentication
Problem it solves	Repeated sign-in prompts across apps	A compromised password alone granting access	The password itself as an attack surface
How it works	One trusted session/token reused by connected apps	A second, independent verification factor after the password	A device-bound or biometric credential replaces the password
Typical examples	Trusted session recognized by connected apps	Authenticator push, phone call, rotating code	Windows Hello for Business, FIDO2 security key
What it does NOT do	Grant permissions or skip authentication	Guarantee a passwordless experience by itself	Automatically imply MFA is also configured

How the AZ-900 exam tests this

• The help-desk-tickets scenario. A prompt describes employees resetting forgotten passwords across many separate internal tools and asks which capability most directly reduces the volume. The answer is SSO, not MFA or RBAC — the root cause is credential sprawl, not weak verification.
• The category-naming question. Expect a direct ask for the three MFA verification categories. Memorize “something you know, something you have, something you are” word for word; distractors substitute plausible-sounding but wrong triads like ownership/rental/borrowing concepts.
• The shared-device or no-smartphone scenario. When a stem describes factory or warehouse workers on shared kiosks without personal phones, Authenticator push notifications and SMS codes are both wrong because they assume a personal device — FIDO2 security keys are the answer.
• The “combine two capabilities” scenario. Some stems want streamlined daily sign-in plus automatic blocking based on sign-in location. That’s SSO paired with Conditional Access, not SSO alone and not RBAC, since RBAC governs permissions rather than sign-in conditions.

Quick reference

• SSO reduces how often a user re-authenticates; it does not grant permissions or weaken security.
• MFA requires two or more factors from independent categories — something you know, have, and are.
• A password used twice, or a longer password, is never MFA — it’s still one factor.
• Windows Hello for Business ties passwordless sign-in to a specific registered device.
• FIDO2 security keys are portable hardware credentials, ideal for shared workstations without personal phones.
• Security defaults give free, fixed MFA enforcement; Conditional Access gives configurable, risk-aware enforcement and requires Microsoft Entra ID P1.
• These three features are complementary, not substitutes — a mature tenant typically uses all three together.

Understanding what each of these identity features actually governs — session, verification strength, or credential type — is exactly the discrimination AZ-900 practice questions are built to test, and pairing this article with Microsoft Entra ID fundamentals covers the identity domain end to end. These sign-in controls are also the practical expression of the “verify explicitly” principle behind Zero Trust and defense in depth, and the AZ-900 study guide walks through how identity security fits into all three exam domains.