Multi-factor authentication is one of the most valuable controls a business can deploy, but the label covers very different experiences and levels of protection. A code sent by text message, a time-based code from an app, a push notification, a synced passkey, and a hardware security key may all appear as MFA on a questionnaire. They do not fail in the same way.

The deployment around the factor matters just as much. An organization can issue strong security keys to administrators and still leave an older mail protocol, app password, recovery call, or enrollment workflow that accepts only a stolen password. It can require MFA at login and leave active sessions untouched for months. It can collect alerts for factor changes without assigning anyone to read them. The control exists, but the attack path goes around it.

Start with the threat, not the label

MFA combines evidence from different factor categories: something a person knows, something they possess, or a biometric characteristic used with an authenticator. Two passwords are not two factors because both are knowledge. A fingerprint used to unlock a device-bound cryptographic key can participate in multifactor authentication; the relying service does not need to receive or store the fingerprint.

The basic threat is a stolen password. Any properly enforced second factor raises the cost of using that password. The more demanding threat is real-time phishing, where a fake site relays the user's password and one-time response to the legitimate service. Another threat is device compromise, where malware steals a session after authentication. Recovery fraud, support-desk impersonation, malicious application consent, and theft of a long-lived API credential create different bypasses again.

Choose authenticators according to the accounts and threats involved. The answer does not need to be one method for every person and every application, but it does need an intentional minimum, a stronger standard for high-impact roles, and a migration path away from weak or bypassable methods.

Why one-time codes can still be phished

An SMS or voice code proves access to a phone channel at that moment. It is better than relying on a password alone, but the channel and account-recovery processes can be attacked. More commonly, a convincing phishing site asks the victim for the code and forwards it immediately. The legitimate service sees the correct password and correct code within the allowed window.

A time-based code generated by an authenticator app avoids dependence on the mobile network, but it is still a value a person can type into the wrong site. A relay proxy can submit it before it expires. This distinction is important: an authenticator app is not automatically phishing-resistant simply because it runs on a smartphone.

Push approval removes typing, but a plain approve or deny prompt can be abused through repeated requests or misleading context. Number matching, where the person enters a value displayed by the sign-in session, helps prevent blind approval and should be enabled where supported. Prompts should also show useful application and location context. Push with number matching is a practical improvement, but a relay phishing site can still guide a victim through a real session.

Phishing resistance is a protocol property

FIDO2 and WebAuthn authenticators, including appropriate passkeys and security keys, use public-key cryptography and bind the authentication response to the legitimate web origin. A lookalike site has a different origin, so it cannot obtain a response that works at the real site. The safeguard is performed by the browser, operating system, and authenticator rather than by asking the person to inspect a domain perfectly.

The private key stays with the authenticator or protected credential provider; the service stores a public key. A device PIN or biometric may unlock use of the credential locally. That does not turn the biometric into a password sent across the internet. Hardware security keys can keep keys on a dedicated device. Synced passkeys can improve recovery and cross-device use but introduce reliance on the security and recovery of the account that synchronizes them. Choose based on role, device model, recovery requirements, and the assurance the business needs.

For tenant, domain, security, backup, finance, and other high-impact administrators, require phishing-resistant authentication wherever the service supports it. Register at least two controlled authenticators or a tested alternative so a lost key does not force an insecure reset. Do not keep SMS as an unrestricted fallback if possessing the phone number can bypass the stronger method.

Coverage comes before perfection

A business should not leave most employees on passwords while designing an ideal passkey program for a small technical team. Establish MFA coverage for every interactive account first, using the strongest practical method supported by current applications. Eliminate unenrolled and permanently exempt accounts. Then move high-impact roles to phishing-resistant factors and expand from there.

Inventory applications by authentication path, user population, data sensitivity, available methods, legacy dependencies, and business owner. Central identity and single sign-on can bring many applications under one MFA policy, but verify that local credentials are disabled or controlled. A launch tile does not prove the application delegates authentication. Test browser, mobile, desktop, command-line, and API access.

Pilot with real work patterns. Include a new starter, device replacement, travel, accessibility needs, lost authenticator, offline or field use, shared workstations, and a service outage. Provide clear enrollment instructions and staffed support during rollout. Make the secure method the default choice rather than one option buried beneath SMS and security questions.

Close legacy and alternate sign-in paths

Protocols and clients that cannot perform modern authentication may allow a valid password to reach mail or other data without an MFA challenge. Disable legacy authentication where it is not explicitly required. Identify application passwords and old client exceptions, assign owners, and retire or isolate the underlying dependency. Monitor attempts after blocking because they reveal forgotten devices, applications, and attack traffic.

Local accounts in federated applications are another bypass. Keep only the minimum necessary emergency or service access, use unique controlled credentials, restrict where it can be used, and monitor every sign-in. Test that disabling a central identity ends access and that a user cannot select a different login route.

Remote-access gateways, administrative consoles, older appliances, and support tools deserve direct tests. Do not infer coverage from the main productivity tenant. If a critical legacy system cannot support MFA, place it behind a controlled access layer, narrow the network path, restrict source devices, and establish a dated modernization or retirement plan. A compensating control should be specific and temporary where possible.

Enrollment and reset are authentication events

An attacker with a stolen password may try to register their own factor before the employee does. Require enrollment from a trusted context or after a verified identity step. Alert on new factors, removal of factors, changes to recovery details, generation of recovery codes, and changes to authentication policy. For high-impact accounts, consider independent approval or in-person verification for these actions.

Help-desk resets should follow a written verification process that does not rely on information easily found in email, social media, or company directories. The support person must know whether the caller holds a privileged or financial role and use a stronger path accordingly. Do not accept an incoming phone number as identity. Where feasible, verify through an existing authenticated session, manager and support checks, or a known registered method. Record who requested, approved, and completed the reset.

Recovery must be usable during an outage. Maintain emergency identities or recovery material that does not depend entirely on the same identity provider, phone, or administrator. Protect it from routine access, require more than one person for the highest-impact recovery where practical, and test it on a schedule. After emergency use, review activity and replace exposed secrets or codes.

Non-human identities cannot approve a prompt

Service accounts, API keys, certificates, and automation require a different design. Do not label them MFA-exempt and stop there. Prefer managed workload identities or short-lived tokens tied to a specific workload. Limit permissions, source, audience, and lifetime. Store secrets in an appropriate secret manager, rotate them through a tested procedure, and monitor use outside expected systems and patterns.

Each non-human identity needs a business and technical owner, a purpose, dependencies, credential location, last-used evidence, and a removal trigger. Separate production and non-production credentials. Prevent interactive sign-in for accounts that do not need it. Review application consent and delegated permissions because an authorized integration can retain data access without performing an ordinary user login.

When a vendor integration ends, revoke tokens and consent as well as deleting the visible account. A password change may not invalidate an OAuth grant or certificate. Test removal from the application's side and the identity platform's side.

MFA does not protect an already authenticated session

After sign-in, the session token becomes the credential presented on later requests. Malware, a malicious browser extension, or an adversary-in-the-middle technique may steal or misuse that session. The attacker may not need the password or factor again until the session expires or is revoked. This is why phishing-resistant authentication, while essential, is not a complete endpoint or session defense.

Use managed-device and risk signals for sensitive access where available. Keep browsers and endpoints patched, control extension installation, deploy appropriate endpoint protection, and restrict high-impact actions from unmanaged devices. Set session lifetimes and reauthentication according to the resource and action instead of choosing one indefinite default. Revoke sessions during incident response, factor reset, device loss, high-risk role change, and offboarding.

Monitor for unusual sign-in context, token replay indicators the platform exposes, impossible combinations of location and device, mass downloads, new forwarding rules, and privilege changes. Treat alerts as leads requiring context rather than automatic proof of compromise. The response path should have an owner and enough identity, device, and application data to investigate.

Conditional access needs controlled engineering

Policies that require authentication strength, managed devices, location, or risk signals can close gaps across many applications. They can also lock out the business. Use report-only or audit modes where available, evaluate the predicted effect, resolve dependencies, and enforce in small groups. Exclude emergency accounts only where needed, monitor them heavily, and avoid broad exclusions that become permanent bypasses.

Order policies carefully. A weak factor should not satisfy a rule intended to protect administrators simply because both methods are categorized as MFA. Define required authentication strength explicitly where the platform permits it. Step up again for sensitive actions such as changing factors, granting roles, exporting data, or altering payment details.

Record policy ownership, purpose, scope, exclusions, change history, rollback, and review date. Send changes to a monitored alert path. A compromised administrator who can weaken policy without prompt detection can turn a strong MFA deployment into a decorative one.

What to verify operationally

A defensible program can produce more than an enrollment percentage

  • Every interactive identity has an approved factor or a documented, expiring exception.
  • High-impact roles require phishing-resistant authentication and separate administrative accounts.
  • Legacy protocols, app passwords, and local application accounts are blocked or specifically controlled.
  • New factor enrollment, recovery changes, privileged resets, and policy changes generate reviewed alerts.
  • Emergency access and lost-device recovery have been tested.
  • Service identities use scoped, owned credentials and cannot sign in interactively without a reason.
  • Session revocation works across priority applications and forms part of offboarding and incident procedures.
  • Conditional policies have named owners, narrow exclusions, and tested rollback.

Run controlled negative tests. Attempt a legacy sign-in with a test account. Try a lower-strength factor against a high-impact role. Remove a user centrally and verify that application sessions and alternate routes behave as designed. Test a lost authenticator without coaching the support person in advance. Use safe test identities and agreed windows; the purpose is to validate the process, not surprise staff.

Failure modes worth finding early

The recurring failures are partial coverage, administrator exemptions, SMS fallback that bypasses a security key, enrollment based only on a password, weak help-desk verification, unmonitored recovery changes, persistent sessions, forgotten app passwords, APIs outside policy, and service accounts with broad permanent credentials. Another is prompt overload: repeated challenges teach people to approve first and interpret later.

A smooth login is not evidence of weak security, and constant friction is not evidence of strength. Good policy uses strong evidence at sign-in and sensitive transitions, remembers it for an appropriate period, and reacts when context changes. User reports of confusing prompts are security data because confusion makes social engineering easier.

The standard behind the checkbox

The right board statement is not simply that MFA is enabled. It is that all relevant identities are covered, the most consequential roles use phishing-resistant authentication, bypass and recovery paths are controlled, sessions and endpoints are considered, and material changes are monitored. That is specific enough to test.

MFA works best as a lifecycle: issue the factor, verify enrollment, use it under clear policy, replace it safely, revoke it promptly, and investigate changes. When the organization treats each of those steps as part of authentication, the checkbox begins to represent a control rather than a setting.