MFA Enforcement Policy: How to Write and Roll One Out

An MFA enforcement policy is a written rule, backed by technical controls, that makes a second proof of identity mandatory for access to your systems. It names who must use MFA, which methods count, what exceptions exist and what happens when someone doesn't comply. Turning MFA on as an option is not enforcement. Enforcement means a user without a registered second factor cannot get in.

This guide covers both halves: the policy document your auditors and staff read, and the Conditional Access settings that make it real. It also covers what Microsoft now requires of every Azure and Microsoft 365 tenant, because that shift has changed what "optional" means for admins.

TL;DR

• "MFA enabled" lets users choose to register. "MFA enforced" blocks access until they do. Your policy should demand the second state.
• Microsoft now requires MFA for Azure and admin portals and, since October 2025, for Azure CLI, PowerShell and other create, update and delete operations. Break-glass accounts are not exempt.
• Admin and email accounts need phishing-resistant methods (FIDO2 passkeys, security keys, certificate-based sign-in). SMS codes and standard authenticator-app codes do not qualify.
• Roll out in stages: report-only mode, registration with a grace period, then enforcement. Issue a Temporary Access Pass before you lock privileged roles down.
• Healthcare organizations should document the method choice in their HIPAA risk analysis, not just switch MFA on.

Table of Contents

• What an MFA enforcement policy actually covers
• What Microsoft now enforces, and what it means for your policy
• Choosing methods: not all MFA is equal
• Admin accounts: the first group to lock down
• Building the technical policy with Conditional Access
• A staged rollout that avoids lockouts
• What to put in the written policy
• Healthcare and regulated teams
• Our perspective
• Where we can help
• Related reading
• FAQ
• Sources

What an MFA enforcement policy actually covers

The phrase gets used for two different things, and a good program needs both.

The governance policy is the document. It states the requirement in plain language, assigns an owner and defines exceptions. Auditors for SOC 2, ISO 27001, PCI-DSS and HIPAA will ask for it, then ask for evidence that the system matches it.

The technical policy is the configuration: Conditional Access rules, Security Defaults, registration policies or the equivalent in Okta, Google Workspace or your VPN. This is what blocks the sign-in.

A gap between the two is the most common failure we see. The document says "all users must use MFA" while a handful of legacy accounts, service mailboxes and old protocols quietly skip it.

Enabled versus enforced

This is the question people search most around this topic. When MFA is merely enabled, users may register a second factor when prompted, and some never do. When it is enforced, the second factor is a condition of access. Microsoft's own guidance frames the move from optional settings to required policies as the point of the exercise, and attackers specifically look for accounts where MFA exists but isn't strictly required.

The practical test: pick a user who has never registered a method and try to sign in. If they get in with a password alone, you have MFA available, not MFA enforced.

What Microsoft now enforces, and what it means for your policy

If you run Microsoft 365 or Azure, part of your policy has been written for you. Microsoft's mandatory MFA plan rolls out in two phases:

Read-only operations are currently excluded from Phase 2. Microsoft also let customers with complex environments postpone Phase 2 until July 1, 2026. That window has closed as of today, 18 October 2026, so assume enforcement applies to every tenant, including test and development environments.

Three consequences belong in your policy text:

1. No permanent exemptions for admins. Anyone performing administrative work in Azure needs MFA, whatever the account's history.
2. Automation needs a plan. Scripts that sign in as a user account with a password will break. Move them to workload identities such as managed identities or service principals.
3. Break-glass accounts must be modernized. Emergency access accounts are not exempt. They need phishing-resistant methods, such as passkeys or certificate-based authentication, and a password-only emergency account will fail the requirement.

There is also a housekeeping point. Legacy per-user MFA settings are officially discouraged. Use Security Defaults if you are a small organization with simple needs, or Conditional Access if you need granularity, exclusions or risk-based signals. Mixing the two frequently produces sign-in failures and policy conflicts, so pick one model and retire the other.

Choosing methods: not all MFA is equal

Your policy should list approved methods, ranked. Here is how the common ones compare against the NIST SP 800-63B definition of phishing resistance, which requires the authenticator output to be bound to the session, through channel binding (as with PIV/CAC smart cards) or verifier name binding (as with FIDO2/WebAuthn).

Why does it matter? CISA's phishing guidance and the FBI-CISA advisory on Ghost (Cring) ransomware both press for phishing-resistant MFA on privileged and email accounts. A code typed into a lookalike login page is a code handed to the attacker.

Still, a weaker MFA beats none. Microsoft reports that accounts are over 99% less likely to be compromised with MFA enabled. The policy goal is to get everyone to the baseline fast, then move high-value accounts up the ladder.

Admin accounts: the first group to lock down

Searches for "MFA for admin accounts" are small in volume but high in stakes. Privileged roles are the accounts attackers want most, and the blast radius of one compromise is the whole tenant.

For administrators, write these requirements into the policy:

• Phishing-resistant MFA on every privileged role, enforced by a Conditional Access policy that targets directory roles rather than named individuals, so new admins are covered automatically. Microsoft documents this in its guide to requiring phishing-resistant MFA for administrator roles.
• Separate admin accounts, not the daily email-and-browsing identity.
• Two or more emergency access accounts, each with its own passkey or certificate, stored offline and tested on a schedule.
• A review of role assignments each quarter.

For security keys, you need hardware that supports FIDO2. Some teams buy YubiKeys for administrators; one Bulgarian-language explainer on Azure's mandatory MFA requirements is written by a reseller of Yubico keys and walks through the October 2025 changes with hardware options in mind. Whichever model you pick, buy at least two keys per administrator so a lost key is an inconvenience and not an outage.

One warning from Microsoft's documentation deserves its own line: if you require phishing-resistant MFA before administrators have registered a compatible method, you can lock them out immediately. Issue a Temporary Access Pass so each admin can enroll a passkey safely, confirm registration, and only then switch the policy from report-only to on.

Our 90-day phishing-resistant MFA plan lays out that sequence week by week, and our piece on privileged access management covers what to vault once the front door is secured.

Building the technical policy with Conditional Access

Conditional Access is where most mid-sized Microsoft shops enforce MFA, and it answers the "MFA conditional access" question directly: it lets you require MFA based on who is signing in, to what, from where and under what risk.

A baseline set of policies

Start with a small number of clear policies rather than a dozen overlapping ones:

1. Require MFA for all users. Microsoft's all-users policy guide recommends excluding emergency access accounts and service accounts or service principals, which are non-interactive and not tied to a person. Note the tension with the earlier section: excluding a break-glass account from your own Conditional Access policy is a lockout safeguard, but it doesn't exempt that account from Microsoft's mandatory enforcement. Secure it with a passkey or certificate and monitor every sign-in.
2. Require phishing-resistant MFA for admin roles. As above.
3. Require MFA to register security information. Otherwise an attacker holding a stolen password can register their own device.
4. Block legacy authentication. Protocols that cannot do a second factor undermine everything else. Microsoft's guidance for healthcare also stresses making sure every protocol in use is multifactored.
5. Add risk-based rules if your licensing includes Entra ID Protection: step up to MFA, or block, on risky sign-ins.

Report-only first

Before enforcing, run each policy in report-only mode and review the sign-in logs. You will find the surprises: an old scanner emailing through a user account, a vendor's shared login, a contractor who never enrolled. Fixing them in a log is far cheaper than fixing them during an outage.

The registration policy and the grace period

The MFA registration policy in Entra ID Protection pushes users to register. Under it, users typically get a 14-day window to complete registration before being blocked. During that period they may skip registration if no Conditional Access policy forces MFA, and after it expires they cannot sign in. We suggest watching registration numbers daily during rollout, and contacting stragglers personally before the cutoff.

A staged rollout that avoids lockouts

Here is the order we recommend for an organization of 50 to 500 people. Adjust the timing to your size.

1. Inventory. List every identity: staff, admins, service accounts, shared mailboxes, contractors, break-glass accounts. Note which apps still use legacy authentication.
2. Write the governance policy. Scope, approved methods, exceptions process, enrollment rules, lost-device procedure, owner.
3. Pilot. Enroll IT and a friendly department. Use report-only Conditional Access.
4. Admins first. Temporary Access Pass, passkey registration, then enforce phishing-resistant MFA on privileged roles.
5. Everyone else. Announce the date, run registration with the grace period, then enforce.
6. Close exceptions. Every exception gets an owner, a reason and an expiry date.
7. Monitor. Review failed and denied MFA attempts. CISA advises tracking denied or attempted MFA logins and locking an account when unusual activity or ongoing malicious attempts appear, so attackers can't wear users down with push prompts.

The help desk is part of the rollout. Plan for the lost-phone call: how is identity verified before a new method is issued? A help desk that resets MFA for anyone who sounds convincing hands attackers a bypass. Our guide to credential stuffing shows why stolen passwords are so cheap to try at scale, and why that makes the reset process a target.

What to put in the written policy

Use this skeleton and fill it in for your environment.

• Purpose and scope. Which systems, which user populations, including contractors and vendors.
• Requirement. MFA is mandatory for all access to company email, cloud applications, VPN and remote access, and all administrative functions.
• Approved methods. Ranked list. State that privileged users and email accounts use phishing-resistant methods.
• Registration. Deadline, grace period, how new hires enroll, and the use of Temporary Access Pass.
• Exceptions. Who can approve, maximum duration, compensating controls, and logging. State clearly that break-glass accounts follow their own hardened procedure.
• Non-human accounts. Service accounts move to workload identities or certificates, with ownership documented.
• Recovery. Identity verification steps for lost devices.
• Monitoring and review. What is logged, who reviews it, how often.
• Consequences. What happens on non-compliance: access blocked until enrolled.

Keep it to two pages. A policy nobody reads is not enforced either.

Healthcare and regulated teams

If you handle electronic protected health information, the question is not just "do we have MFA" but "can we show why this MFA is right for our risk." HHS guidance explains that the HIPAA Security Rule is technology-neutral: it doesn't mandate a specific product, but your documented risk analysis should guide which authentication controls you choose. The same newsletter points to OCR's US$1.25 million resolution agreement with Banner Health, which involved failures including weak authentication processes.

For your records, that means your MFA policy should reference the risk analysis, name the methods for remote access to ePHI, and explain why SMS or app codes are or are not acceptable for each user group. The HHS healthcare cybersecurity practices for medium and large organizations also single out MFA on the email platform as a way to blunt compromised credentials. Our post on patient data encryption for HIPAA audit readiness covers the neighbouring control.

Our perspective

Most of the MFA problems we are called in to fix are not technology problems. The tenant has MFA. The policy document says everyone uses it. Then an incident review shows a forgotten service account, a break-glass login with a password nobody rotated, or a group of executives excluded two years ago "temporarily."

That is the cost of fragmented security: identity is managed by one team, email by another, compliance evidence by a third, and nobody owns the gap between them. We think MFA enforcement should be run as a single program with one accountable owner, covering the policy, the Conditional Access build, the help-desk process, the monitoring and the audit evidence. When the same people watch sign-in alerts and maintain the compliance documentation, an exception that appears in the logs gets closed instead of filed.

Our advice is blunt. Enforce on admins first with phishing-resistant methods. Put an expiry date on every exception. Treat break-glass accounts as the most sensitive credentials you own. And measure enforcement by what you can prove from sign-in logs, not what the policy says.

— Nick - Sr. Executive

Where we can help

If you would rather not run this rollout alongside your day job, our team handles it as part of managed IT and cybersecurity services: Conditional Access design, phishing-resistant MFA for privileged roles, 24/7 monitoring of sign-in activity, and compliance assessments for SOC 2, HIPAA, PCI-DSS and ISO 27001, under one contract and one point of accountability.

Related reading

MFA is one layer. These guides cover the ones around it: remote access security aligned to CISA and NIST Zero Trust guidance, business email compromise prevention and a Zero Trust roadmap for IT leaders.

FAQ

Is Microsoft going to enforce MFA?

It already does. Phase 1 covered the Azure, Entra and Intune portals from late 2024 and the Microsoft 365 admin center from February 2025. Phase 2, covering Azure CLI, PowerShell, IaC tools and create, update and delete REST calls, began on October 1, 2025. The postponement option for Phase 2 ended on July 1, 2026.

What is the difference between MFA enabled and enforced?

Enabled means the option exists and users may register a second factor. Enforced means access is refused unless the second factor is presented, typically through a Conditional Access policy or Security Defaults. Only enforcement closes the gap attackers look for.

How do I check whether MFA is enforced for a user?

Don't rely on the per-user status screen alone, since legacy per-user settings are discouraged. Review which Conditional Access policies apply to the user, then check the sign-in logs to see whether recent sign-ins satisfied an MFA requirement. Report-only mode shows what a new policy would have done before it goes live.

Do emergency access accounts need MFA?

Yes. Microsoft's mandatory enforcement does not exempt break-glass accounts. Give them phishing-resistant credentials such as passkeys or certificate-based authentication, keep them out of everyday use and alert on any sign-in.

Is SMS acceptable under an MFA policy?

It is better than a password alone, but NIST does not treat SMS, voice calls or standard one-time-code apps as phishing-resistant. Reserve it as a fallback for low-risk users and plan to move privileged and email accounts to FIDO2 or certificate-based methods.

Sources

• Plan for mandatory Microsoft Entra multifactor authentication (Microsoft Learn)
• Require phishing-resistant MFA for Microsoft Entra administrator roles (Microsoft Learn)
• Require MFA for all users with Conditional Access (Microsoft Learn)
• Configure the MFA registration policy (Microsoft Learn)
• NIST SP 800-63B: Authenticators
• CISA: Phishing Guidance, Stopping the Attack Cycle at Phase One
• CISA and FBI: #StopRansomware Ghost (Cring) Ransomware
• HHS OCR Cybersecurity Newsletter, June 2023
• HHS HICP Technical Volume 2: Medium and Large Healthcare Organizations