How to Enforce MFA for Employees (Practical Guide)

If you want to enforce MFA for employees (not just “enable it”), the most reliable approach is to require MFA at your SSO/IdP using conditional access, then remove bypass paths (legacy auth, app passwords), roll it out in phases, and continuously verify enforcement in sign-in logs.

TL;DR - Enforce MFA at the identity provider (SSO/IdP) using conditional access—not per-app toggles. - Prefer phishing-resistant MFA (FIDO2/passkeys/security keys) for admins and high-risk access; phase it in for everyone. - Block legacy authentication and app passwords; use break-glass accounts and monitor sign-in logs for drift.

Detailed Explanation

Enforcing MFA means three things operationally: (1) it’s mandatory, (2) it’s hard to bypass, and (3) you can prove it (auditability). The most common failure mode is enabling MFA “somewhere,” while leaving exceptions, legacy protocols, or unmanaged apps that bypass the control.

1) Enforce MFA at the right control point (IdP/SSO first)

If you have SSO (an identity provider such as Microsoft Entra ID, Google Workspace, Okta, Ping, etc.), enforce MFA there. Per-application MFA settings are inconsistent and create coverage gaps.

What to do - Make the IdP your enforcement point for: - Cloud apps (SAML/OIDC) - Email access - Admin portals - Remote access (VPN/ZTNA), ideally integrated with the IdP - Require MFA for: - All interactive sign-ins - High-risk sign-ins (impossible travel, new device, new location) - Privileged roles (admins) with stricter requirements

Why it matters - Central enforcement prevents “shadow exceptions.” - One policy applies across many apps. - You get unified logs for auditing.

2) Choose MFA methods that resist phishing (and set a minimum bar)

Not all MFA is equal. If you enforce MFA but allow weak methods, attackers can still succeed via credential phishing + MFA fatigue or OTP interception.

Recommended method order (best to good) 1. FIDO2/WebAuthn security keys or passkeys (phishing-resistant) 2. Authenticator app with number matching / push with protections (good, but beware fatigue) 3. TOTP codes (acceptable baseline) 4. SMS/voice OTP (last resort; avoid if possible)

Policy approach - Require phishing-resistant MFA for: - Admin accounts - Finance/payroll - Access to email and file storage - Remote access (VPN/ZTNA) - For the broader workforce, start with authenticator app/TOTP and migrate toward passkeys.

3) Implement “no-bypass” controls: block legacy auth and app passwords

Many MFA programs fail because older protocols bypass modern authentication.

Key actions - Disable or block: - Legacy email authentication (e.g., IMAP/POP/SMTP AUTH where not needed) - App-specific passwords - Basic authentication flows - Enforce modern auth and token-based access.

4) Plan a rollout that doesn’t break the business

A practical MFA rollout is a change-management project as much as a security one.

Suggested rollout sequence 1. Inventory: users, apps, service accounts, remote access paths 2. Pilot group: IT + a cooperative business unit 3. Admins first: enforce strongest MFA, remove exemptions, require device compliance if available 4. High-risk apps: email, finance, HR, customer data platforms 5. All users: staged by department/location 6. Cleanup: remove temporary exceptions; confirm legacy blocks

Operational essentials - Provide a self-service enrollment portal and step-by-step enrollment guide. - Prepare the helpdesk with scripts for common issues (new phone, lost device, token desync). - Define an “MFA reset” identity proofing process (to avoid social engineering the helpdesk).

5) Handle edge cases safely (break-glass, service accounts, shared devices)

Some accounts should not use “normal user MFA” patterns:

Break-glass (emergency) accounts
Create 1–2 emergency admin accounts.
Store credentials securely (offline or in a vault with strict controls).
Exclude from MFA only if absolutely required by your architecture—and compensate with:
- Long random passwords
- No mailbox/license where possible
- IP restrictions
- Continuous alerting on use
Service accounts
Prefer workload identities, managed identities, or certificate-based auth instead of human MFA.
If you must keep a legacy service account, restrict its permissions and network access; rotate secrets.
Shared/frontline devices
Use device-based sign-in modes designed for shared devices, or enforce MFA per shift with shorter session lifetimes.
Avoid shared accounts; if unavoidable, treat them as privileged and isolate access tightly.

Tip: If you’re also standardizing credential storage and recovery processes, pairing MFA enforcement with an employee-ready password manager can reduce helpdesk load. For example, 1Password Business supports strong admin controls and recovery workflows—see details here: Try 1Password →.

6) Validate and continuously monitor

MFA enforcement is not “set and forget.” You must monitor sign-in patterns and policy exceptions.

What to monitor - Sign-ins without MFA where MFA is expected - Users stuck on weak MFA methods - Repeated MFA prompts (fatigue attack indicators) - Spikes in MFA resets (possible social engineering)

Technical Notes: rollout checklist you can operationalize

Use this as an internal checklist during rollout:

[ ] MFA policy defined (methods allowed, minimum required)
[ ] Admins require phishing-resistant MFA
[ ] Conditional access requires MFA for all users
[ ] Legacy authentication blocked
[ ] App passwords disabled
[ ] Break-glass accounts created + monitored
[ ] Service accounts reviewed and modernized
[ ] Helpdesk runbook prepared (reset + identity verification)
[ ] Sign-in logging + alerts configured
[ ] Exceptions documented with expiry dates

Technical Notes: log patterns to confirm enforcement

Regardless of platform, look for these concepts in your IdP sign-in logs:

Authentication requirement satisfied by: MFA / single-factor
Authentication method: FIDO2/WebAuthn, authenticator push, TOTP, SMS
Conditional access/policy result: success, failure, not applied
Legacy protocol indicator: IMAP/POP/SMTP/basic auth
Location/device: new device, unmanaged device, unfamiliar location

Example queries differ by vendor, but the goal is the same: identify sign-ins that did not meet MFA when they should have, and eliminate the path.

Common Misconceptions

“If I enable MFA in the email app, I’m done.”

Not necessarily. Users often access the same mailbox via mobile mail clients, legacy protocols, or third-party apps. Enforce MFA at the IdP and block legacy auth so there’s no alternate route.

“SMS MFA is good enough for everyone.”

SMS is better than nothing, but it’s not ideal. It can be vulnerable to SIM swap and interception, and it doesn’t stop real-time phishing toolkits as well as phishing-resistant methods. Use FIDO2/passkeys for admins and sensitive roles.

“MFA annoys employees, so I’ll only require it outside the office.”

Attackers sign in from “trusted” networks too (compromised devices, VPNs, insider threats). If you use location/device signals, treat them as additional context, not a replacement for MFA—especially for admin actions and sensitive data.

“Break-glass accounts are a security risk, so I won’t have them.”

Not having a recovery path can lock you out during an outage or misconfiguration—creating business risk. Break-glass accounts are safe when tightly controlled, monitored, and rarely used.

“Once enrolled, MFA is enforced forever.”

Policy drift happens: exceptions get added, new apps appear, legacy protocols re-enable, or users switch to weaker methods. You need regular reviews and alerting to ensure MFA remains enforced.

What is MDR (Managed Detection and Response)? If you want additional coverage for identity-based attacks and rapid response, start here: what is mdr
Best password manager for small business (2026): guidance for rollouts, admin controls, and recovery: password manager for small business 2026

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.