Multi-Factor Authentication in Microsoft Entra ID
Seventh in this series on Microsoft Entra ID, covering multi-factor authentication (MFA): the core mechanics, how to configure it, and a set of corrections to older training material — a fair amount of the legacy MFA surface described in the original course notes has actually been retired since.
Core concepts
MFA requires two or more independent verification factors to authenticate, which makes unauthorised access substantially harder even if a password has already been stolen. A few supporting mechanics: account lockout temporarily disables an account after a set number of failed attempts to blunt brute-force attacks, and the failed-attempt counter doesn't reset immediately after a successful login — it resets only after a configured time period, which is worth understanding before you're surprised by an unexpected lockout. OATH software tokens are a time-based one-time-password (TOTP) method — the Microsoft Authenticator app is the common example, generating a new code every 30 seconds. Named locations are geographic definitions used for conditional access and security reporting; they aren't the same mechanism as trusted IPs, which can bypass MFA entirely for requests from defined ranges, typically an internal network with secure connectivity.
One correction on hardware tokens: the original note said Azure AD doesn't support hardware-based tokens, which is out of date. Microsoft Entra ID does support OATH hardware tokens — SHA-1 and SHA-256, refreshing every 30 or 60 seconds — currently as a public preview feature requiring a P1 or P2 licence, uploaded in bulk via CSV. A user can have up to five hardware tokens or authenticator apps registered at once.
Remembered devices let Entra ID skip MFA on devices that have already authenticated successfully, trading a little security for convenience, and app passwords exist for older applications that can't do MFA directly — these can be reset or deleted if compromise is suspected.
Configuring MFA
Configuring the account lockout and related settings follows a predictable path: navigate to the MFA settings, adjust the number of denials allowed before lockout and the counter-reset duration (remembering, again, that the counter doesn't reset immediately on a correct entry), and decide how aggressively to block and unblock users manually — useful for something like a lost phone, where you want to disable access immediately. Enabling fraud alerts lets users flag a suspicious authentication request themselves, which is a useful early-warning signal, though it's worth thinking through the trade-off of automatically blocking an account the moment a fraud alert comes in, since that disrupts the user's own productivity while the issue gets investigated. OATH software tokens can be configured for apps like Microsoft Authenticator — Entra ID historically didn't support hardware-based tokens for this flow, though as noted above that's since changed with hardware OATH tokens in preview. Named locations (for example, "US Office" tied to a country or IP range) matter for security reporting, but — worth repeating because it's a common misunderstanding — configuring one does not by itself affect MFA. Trusted IP ranges are the separate mechanism that actually bypasses MFA for requests from those addresses, and it's worth knowing this only works for genuinely private IP ranges where there's site-to-site connectivity back to Azure — Azure only ever sees a public IP for a direct, non-VPN connection.
Enabling MFA for an individual user is a similarly short flow: navigate to MFA settings, enable it for the user, and from there manage their specific settings — forcing re-registration of contact methods, deleting existing app passwords (forcing new ones to be generated for apps that need them), or resetting the "remembered device" status entirely so MFA is required again on every previously trusted device (useful if one is lost or compromised). Authentication methods, once configured, are visible in detail from the user's profile.
Troubleshooting
A few recurring gotchas: assuming a named location automatically bypasses MFA is a common but incorrect assumption — it's purely for reporting unless it's separately wired into a Conditional Access policy. The lockout counter resetting only after its configured period, not immediately on a correct entry, catches people out. Automatically blocking on a fraud alert is a real security-vs-productivity trade-off worth thinking through deliberately rather than defaulting into. Trusted private IP ranges only work with an actual site-to-site VPN or equivalent secure connection — a home network's private range alone does nothing, since Azure only sees the public IP on a direct connection. And app password issues after enabling MFA are usually solved by generating a fresh app-specific password for whatever legacy application needs one.
On the legacy MFA Server: it's not just "existing servers continue to be supported" as the original note had it — Microsoft Entra multifactor authentication server deployments stopped servicing MFA requests entirely as of 30 September 2024, so this is now well past the point of being a future planning item and is a hard requirement to have migrated. Relatedly, the older Block/unblock users, fraud alert, and notification features (including the 90-day default block duration referenced in the original note) were retired on 1 March 2025, replaced by Report suspicious activity, which is integrated with Identity Protection for risk-driven remediation rather than a flat block/unblock toggle. And separately, legacy per-user MFA and SSPR policy management itself stopped being usable after 30 September 2025 — organisations still relying on the legacy policy surface (rather than the Authentication methods policy) needed to have migrated by then.
Given how much of this shifted within about a year (MFA Server's retirement, the Block/unblock users retirement, and the legacy MFA/SSPR policy retirement all landed close together), it's worth double-checking any older MFA training material or documentation against current Microsoft Learn rather than assuming it still describes the live product.