MFA and Conditional Access: What It Means for Your Organization

What are MFA and Conditional Access?

MFA is a sign-in that needs two different kinds of proof. CISA explains the point simply: “With MFA enabled, if one factor, such as a password, becomes compromised, unauthorized users will be unable to access the account if they cannot also provide the second factor.”

Conditional Access is the policy layer in Microsoft Entra ID, the identity service behind Microsoft 365. Microsoft describes Conditional Access policies as “logical if then statements.” If the assignments (users, resources and conditions) are true, then the policy applies access controls. A simple example from Microsoft: if you are an administrator signing in to a Microsoft admin portal, then you must complete MFA.

With Conditional Access you can require MFA for everyone, require a stronger method for administrators, require a managed device before anyone opens sensitive apps, block sign-ins from places you never do business, and block old sign-in methods entirely.

What does this cover, and what doesn’t it?

It covers: which sign-in methods you allow, which people and apps must use MFA, how strong the method must be for administrators and sensitive access, blocking legacy sign-in, emergency access accounts, and how you review sign-in activity.

It is not:

• A password policy by itself. Strong passwords still matter, but MFA assumes a password can be stolen.
• Protection for every system automatically. Conditional Access covers apps that sign in through Microsoft Entra ID. Other systems need their own MFA or a connection to your identity service.
• A one-time project. People join and leave, methods change, and new apps arrive. The rules need review.
• A guarantee. MFA makes account takeover much harder. It does not replace monitoring, training or backups.

Do MFA and Conditional Access apply to you?

If your staff sign in to email, files or business apps over the internet, MFA applies to you. It matters most when:

1. You hold regulated or sensitive information. Patient information, controlled unclassified information for defense work, financial records or personal information of Texans.
2. You answer security questionnaires. Customers and cyber insurers commonly ask whether MFA is required for email, remote access and administrator accounts.
3. You rely on a few administrator accounts. One stolen administrator sign-in can reach everything.

Quick check: does this apply to you?

• Your organization uses Microsoft 365 or other cloud apps with staff sign-ins.
• Any of those sign-ins can reach business, customer or patient information.

If both are true, MFA very likely applies to you. If a law, contract or insurance policy names specific MFA requirements, confirm with your attorney or broker how those requirements apply.

What do you need to have in place?

Which MFA methods are phishing-resistant?

CISA ranks MFA methods from strongest to weakest:

1. Phishing-resistant MFA. FIDO/WebAuthn (for example security keys, passkeys and sign-in built into a device) and PKI-based methods such as certificates or smart cards. CISA says push bombing, SS7 and SIM swap attacks “are not applicable.”
2. App-based codes, token codes and push notifications with number matching. Still vulnerable to phishing, but resistant to push bombing. CISA says these are “the best options for small- and medium-size business that cannot immediately implement phishing-resistant MFA.”
3. Push notifications without number matching. Vulnerable to push bombing and user error.
4. Text message or voice codes. Vulnerable to phishing, SS7 and SIM swap attacks. CISA says this form “should only be used as a last resort.”

NIST reaches a similar place. NIST SP 800-63B-4, published in July 2025, states that “Passwords are not phishing-resistant,” “Out-of-band authentication is not phishing-resistant,” and “OTP authentication is not phishing-resistant.” At authentication assurance level 2, verifiers “SHALL offer at least one phishing-resistant authentication option.” NIST writes these guidelines for federal agencies, but many organizations use them as a reference. NIST allows syncable authenticators, such as synced passkeys, at AAL2 under extra safeguards, but not at AAL3, which requires a non-exportable key.

In Microsoft Entra ID, a Conditional Access control called authentication strength lets you require specific methods. Microsoft’s built-in phishing-resistant strength allows FIDO2 security keys, certificate-based authentication (multifactor) and the sign-in built into supported managed computers.

What is the Conditional Access baseline?

Microsoft gives you two starting points:

• Security defaults. Microsoft makes these available “at no extra cost.” They require all users to register for MFA, require administrators to use MFA, require users to use MFA when necessary, block legacy authentication protocols and block device code flow. They cannot be customized.
• Conditional Access. Microsoft publishes Microsoft-managed policies, created in report-only mode, that include MFA for administrators accessing Microsoft admin portals, MFA for all users, blocking legacy authentication, blocking device code flow, and risk-based policies for plans that include them. Microsoft’s licensing guidance says Conditional Access “requires Microsoft Entra ID P1 licenses.” Entra ID P1 is included in Microsoft 365 Business Premium, E3 and E5. Risk-based policies (sign-in risk and user risk) need Microsoft Entra ID P2, which is included in Microsoft 365 E5.

Microsoft 365 also offers a baseline security mode in its admin center that bundles recommended settings. Two of those settings appear as Conditional Access policies: requiring phishing-resistant authentication for administrators and blocking legacy authentication.

Microsoft now requires MFA for its admin portals as well. It began enforcing MFA for its cloud, identity and device admin centers in October 2024 and for the Microsoft 365 admin center in February 2025, rolling out gradually across organizations. A second phase, starting October 1, 2025, extends MFA to command-line, scripting and API tools that make changes to cloud resources.

Why block legacy authentication?

Legacy authentication means older clients and protocols, such as older mail protocols, that don’t support modern sign-in. Microsoft explains the risk: “Legacy authentication doesn’t support multifactor authentication. Even if you have a multifactor authentication policy enabled on your directory, an attacker can authenticate by using an older protocol and bypass multifactor authentication.” Microsoft also says that “more than 99 percent of password spray attacks use these legacy authentication protocols.”

Before you block it, find anything that still depends on it, such as an old scanner that sends email or a line-of-business app, and plan a replacement.

What are break-glass accounts?

A break-glass or emergency access account is how you get back in if normal administrator sign-in fails, for example during an outage or if the only administrator leaves. Microsoft’s guidance includes:

• Keep at least two emergency access accounts, cloud-only and not tied to any one person.
• Protect them with phishing-resistant methods, such as a passkey (FIDO2) or certificate-based authentication, that are different from your normal administrator accounts.
• Exclude them from Conditional Access policies that block or restrict sign-in, so a policy mistake cannot lock everyone out.
• Store credentials securely in separate locations, known only to authorized people.
• Alert on every sign-in and review each use afterward.
• Validate the accounts at least every 90 days and after staff changes.

Microsoft also notes that emergency access accounts must complete MFA to reach its admin portals, which is another reason to set them up with phishing-resistant methods now.

How do cyber insurers ask about MFA?

Cyber insurance applications and renewal forms commonly ask about MFA. Typical questions ask whether MFA is required for:

• Email and cloud apps
• Remote access to your network
• Administrator and privileged accounts
• Access to backups

Some applications also ask which methods you use, whether any accounts are exempt, and whether you block legacy sign-in. The exact questions vary by insurer and by year. Answer only what is true today, keep evidence such as MFA registration reports and policy screenshots, and talk with your broker if a question does not fit how your organization works. See our guide to security questionnaires.

How can ALCON DTS help you?

You keep the compliance decisions. We run the controls. You decide the rules, the exceptions and who approves them. ALCON DTS can help configure and run MFA and Conditional Access in your Microsoft 365 environment and keep the records that show it working.

The exact controls depend on your ALCON DTS plan and any project work. ALCON DTS does not provide legal advice, does not certify compliance and does not sign attestations for you.

How do MFA and Conditional Access fit with other rules?

• HIPAA (45 CFR 164.312(d)). The person or entity authentication standard requires you to “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.” The current rule does not name MFA, but your security risk analysis should address how you meet this standard. See our guides on ePHI in Microsoft 365 and the HIPAA security risk analysis.
• Proposed HIPAA Security Rule changes (proposed only). On January 6, 2025, HHS published a proposed rule (90 FR 898) that would add an authentication standard (proposed 45 CFR 164.312(f), with MFA at proposed 164.312(f)(2)(ii)) requiring covered entities and business associates to deploy MFA to all technology assets in their relevant electronic information systems, with limited exceptions. As of September 30, 2026, no final rule has been published in the Federal Register. It is a proposal, not a current requirement.
• CMMC Level 2 (IA.L2-3.5.3). This requirement, from NIST SP 800-171 Rev. 2, says to “Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.” The CMMC scoring rule (32 CFR 170.24) subtracts three points if MFA covers only remote and privileged users and five points if it covers no users. Because either deduction is more than 1 point, a missing or partial MFA requirement can’t be put on a plan of action and milestones (POA&M) to reach Conditional Level 2 status (32 CFR 170.21(a)(2)(ii)). See our CMMC guide for DoD suppliers.
• CIS Controls v8.1, Implementation Group 1. Safeguard 6.3 requires MFA for externally-exposed applications (where supported), 6.4 for remote network access and 6.5 for all administrative access accounts (where supported). All three are IG1 Safeguards. See our CIS Controls IG1 guide.
• Texas Cybersecurity Safe Harbor (SB 2610, Bus. and Com. Code Ch. 542). For businesses with 20 to 99 employees, the program must include the requirements of CIS Controls Implementation Group 1, which includes Safeguards 6.3 through 6.5 (Sec. 542.004(a)(4)(B)). Every qualifying program must also conform to an industry-recognized framework as described in Sec. 542.004(b), and the 100 to 249 employee tier must comply with Subsection (b). Frameworks listed there, such as NIST SP 800-171 and the CIS Critical Security Controls, also address MFA (Sec. 542.004(a)(2), (a)(4)(C), (b)(1)). See Texas SB 2610 Cybersecurity Safe Harbor.
• Cyber insurance. Your policy and application may set their own MFA expectations. Check them with your broker.

Frequently asked questions

Sources

• Implementing Phishing-Resistant MFA, fact sheet, October 2022 (CISA)
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, July 2025 (NIST)
• Microsoft-managed Conditional Access policies (Microsoft Learn)
• Security defaults (Microsoft Learn)
• Conditional Access authentication strengths (Microsoft Learn)
• Manage emergency access admin accounts (Microsoft Learn)
• Plan for mandatory Microsoft Entra multifactor authentication (Microsoft Learn)
• 45 CFR 164.312, Technical safeguards (eCFR)
• HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule, 90 FR 898 (Federal Register)
• NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (NIST)
• 32 CFR Part 170, Cybersecurity Maturity Model Certification Program (eCFR)
• CIS Controls Navigator v8.1 (Center for Internet Security)
• Texas Business and Commerce Code, Chapter 542, Cybersecurity Program (Texas Constitution and Statutes)

Last reviewed: September 30, 2026

This page is general information about multifactor authentication, Conditional Access and related rules, not legal advice for your situation.