MFA and Passwordless Authentication in Entra

Multi-Factor Authentication (MFA) requires two or more of the following: something you know (password), something you have (phone, hardware key), or something you are (biometric). It mitigates credential theft because an attacker must compromise multiple factors. In Entra ID, MFA is enforced via Conditional Access policies or security defaults. The exam focuses on how to enable and manage MFA for users, including per-user MFA (legacy) and Conditional Access-based MFA (recommended).

When a user signs in with a password, Entra ID checks if MFA is required. If yes, the authentication flow pauses, and the user must present a second factor. The available methods are:

The flow for Authenticator push: Entra ID sends a notification to the Authenticator app on the registered device. The app uses Azure Notification Hubs to deliver the push. The user approves the sign-in request, which includes a number matching challenge (the user sees a number on screen and enters it in the app) to prevent accidental approvals. The app signs the approval with a private key and sends it to Entra ID. Entra ID verifies the signature and completes authentication.

Passwordless authentication removes the password entirely. Methods include: - Windows Hello for Business: Uses biometrics or PIN tied to the device's TPM. The private key never leaves the device. - FIDO2 Security Keys: USB, NFC, or Bluetooth keys that generate a key pair. The private key is stored on the key. - Microsoft Authenticator app: The app itself becomes the primary factor. The user signs in by verifying a number and using biometrics on the phone. - Phone sign-in (SMS): Not truly passwordless but often grouped; sends a code via SMS.

For FIDO2: The user inserts the key and enters a PIN (local verification). The key signs a challenge from Entra ID using its private key. Entra ID validates the signature using the public key stored in the user's directory object. This is asymmetric cryptography: the private key never leaves the key, preventing phishing.

For Authenticator passwordless: The user enters their username, then opens the Authenticator app. The app shows a number matching challenge. The user enters that number in the app and uses biometrics to approve. The app signs the response with a key provisioned during registration.

To manage MFA via PowerShell:

# Get per-user MFA status
Get-MsolUser -All | Select-Object UserPrincipalName, StrongAuthenticationMethods, StrongAuthenticationRequirements

# Enable MFA for a user (per-user)
$auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$auth.RelyingParty = "*"
$auth.State = "Enabled"
Set-MsolUser -UserPrincipalName user@domain.com -StrongAuthenticationRequirements $auth

To manage via Graph API:

GET https://graph.microsoft.com/v1.0/users/{id}/authentication/methods

To create a Conditional Access policy requiring MFA:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
    displayName = "Require MFA for all users"
    state = "enabled"
    conditions = @{
        userRiskLevels = @()
        signInRiskLevels = @()
        clientAppTypes = @("all")
        platforms = @{
            includePlatforms = @("all")
            excludePlatforms = @()
        }
        locations = @{
            includeLocations = @("All")
            excludeLocations = @()
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @()
        }
        applications = @{
            includeApplications = @("All")
            excludeApplications = @()
        }
    }
    grantControls = @{
        builtInControls = @("mfa")
        operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

MFA integrates with Conditional Access (the primary enforcement mechanism), Identity Protection (risk-based MFA), and Entra ID P1/P2 licensing (P2 includes risk-based policies). Azure AD Join and Hybrid Azure AD Join determine device state, which can be used as a condition in policies. Passwordless methods require devices to be registered in Entra ID.

Enterprise Scenario 1: Global Organization with Remote Workers A multinational company with 10,000 employees deploys MFA via Conditional Access. They require MFA for all users accessing cloud apps outside the corporate network. They use Microsoft Authenticator with number matching. They exclude a few break-glass accounts (emergency admin accounts) from the policy. They also require compliant device (Intune managed) for access to sensitive apps. The policy is deployed in report-only for two weeks, then enabled. They see a 99% reduction in account compromise incidents. Common issues: users in regions with poor internet get delays in push notifications; they switch to OTP (time-based one-time password) in the Authenticator app, which works offline. The admin also configures a 60-day remember MFA setting to reduce prompts on trusted devices.

Scenario 2: Passwordless Deployment for Executives A financial services firm wants to eliminate passwords for C-level executives due to targeted phishing. They enable passwordless authentication using FIDO2 security keys. They purchase YubiKeys and distribute them. Admins enable the FIDO2 method in Entra ID and target the execs group. Each exec registers their key by inserting it into a USB port and following the setup wizard. They also register a PIN on the key (local verification). The execs now sign in by inserting the key and entering the PIN. The firm also sets a Conditional Access policy requiring passwordless authentication (authentication strength) for these users. Challenges: some execs lose keys, so the firm provisions a second key as backup. They also ensure all browsers support WebAuthn (Chrome, Edge, Firefox).

Scenario 3: Healthcare Organization with Legacy Apps A hospital uses an old EHR that only supports legacy authentication (POP/IMAP). They cannot use MFA directly. They deploy an app proxy solution (Azure AD Application Proxy) to modernize access. The proxy translates modern auth to legacy. They then enforce MFA via Conditional Access on the proxy app. Users access the EHR through a web portal, which requires MFA. This allows the hospital to secure the legacy app without upgrading it. The admin also blocks legacy authentication protocols via a Conditional Access policy (client apps condition) to prevent bypasses. They monitor sign-in logs for any legacy auth attempts and alert on them.