Multi-Factor Authentication Rollout: Where Growing Companies Leave the Gaps

A 90-person company answers "yes" to the MFA question on a customer security questionnaire. It is true in the way most answers are true: multi-factor authentication was switched on for the main email platform during a security push two years ago. Nobody has checked since whether the finance director's exception is still in place, whether the old shared mailbox still accepts a password alone, or whether the VPN ever got the same treatment.

That gap between "we turned MFA on" and "MFA covers every way in" is where most account takeovers happen at companies this size. The control works. The rollout is what leaves holes.

Why the Control Is Worth Finishing

Microsoft's research on its own identity platform found that MFA reduced the risk of account compromise by 99.22 percent across the population studied, and by 98.56 percent even when the account's password had already leaked. Those numbers describe accounts where MFA was actually enforced. They say nothing about the accounts where it was not.

The financial exposure is concrete. IBM's 2025 Cost of a Data Breach Report put the global average cost of a breach at $4.44 million and the average in the United States at $10.22 million. A 100-person company will rarely see a figure that large, but the direction matters: a single compromised mailbox with payment authority or customer data can turn a missing control into an expensive event once response, notification, downtime, and lost contracts are counted.

Cyber insurers have noticed. MFA on email, remote access, and administrator accounts is now a standard line on underwriting applications, and carriers increasingly ask for evidence rather than attestation. A "yes" you cannot prove is a liability at renewal.

The Six Places Rollouts Leave Gaps

Almost every incomplete MFA deployment fails in one of the same six ways. A review of your own environment against this list will find at least two.

1. Standing exceptions that never expired

During rollout, someone could not get the prompt to work on a phone, traveled without a signal, or objected loudly. An exception was granted "for now." Exceptions are usually granted to the most senior and most targeted people in the company, and they rarely carry an end date or an owner.

2. Legacy authentication paths

Older protocols such as IMAP, POP, SMTP basic authentication, and some older desktop mail clients do not support modern authentication prompts. If those protocols remain enabled, an attacker can present a stolen password directly and skip the MFA check entirely. In Microsoft 365 and Google Workspace environments, this is a setting, and it is frequently left at its permissive default on tenants that are several years old.

3. Shared and service accounts

Shared mailboxes, scanner accounts, and integration accounts often sign in with a password only because no individual person is attached to them. They tend to hold broad permissions and tend to be forgotten in access reviews. Each one needs to be either converted to a managed identity or application credential, or locked down so it cannot sign in interactively.

4. Admin accounts treated the same as everyone else

Administrator accounts are the highest-value targets in the company. Many growing companies enforce MFA for staff but leave global administrator accounts using the same method, or no better method, than everyone else. Administrators should use the strongest method available and should have separate accounts for daily work and elevated tasks.

5. Applications outside the main identity system

The email platform gets MFA. The accounting system, the CRM, the banking portal, the HR platform, and the code repository each have their own login, and many are never connected to the central identity provider. Any one of them may hold more sensitive data than email does.

6. Weak methods in a strong wrapper

Text-message codes can be intercepted by SIM-swapping. Push-approval prompts can be abused through repeated requests until an exhausted user taps "approve." The Cybersecurity and Infrastructure Security Agency (CISA) calls this push bombing and has published guidance recommending number matching for push-based MFA and phishing-resistant methods for higher-risk accounts. Having MFA enabled is not the same as having MFA that resists the attacks currently in use.

Not All Methods Are Equal

CISA's guidance describes phishing-resistant MFA, built on FIDO2/WebAuthn standards such as hardware security keys and passkeys, as the strongest option, because the credential is bound to the legitimate website and cannot be handed to a fake login page. Authenticator-app codes and push approvals are a clear step up from passwords but can still be phished or fatigued out of a user.

Method	Phishing resistance	Typical use at this size
Text message code	Low	Fallback only, retire where possible
Authenticator app code	Medium	Default for general staff
Push with number matching	Medium to high	Default where supported
Passkey or hardware key	High	Administrators, finance, executives

A practical position for a 50 to 200 person company is simple. Require an authenticator app with number matching for everyone, require a passkey or hardware key for administrators and anyone who can move money, and remove text messages as a primary method.

A Rollout Checklist You Can Act On

Use this sequence to finish a rollout that is partly done, or to run a clean one.

1. Inventory every sign-in surface. List email, VPN, remote desktop, cloud consoles, finance and banking systems, HR, CRM, code repositories, and any vendor portal that holds company data. Note which are connected to your central identity provider and which are not.
2. Pull an MFA registration and sign-in report. Your identity platform can list every user, whether they have registered a method, and which method. Anyone without a registered method is an open door.
3. List every exception. Collect each user, group, or policy that bypasses MFA. Give each one an owner and a removal date, or remove it now.
4. Disable legacy authentication. Block basic authentication protocols tenant-wide, then handle the few devices or scanners that break by replacing them or moving them to modern authentication.
5. Fix shared and service accounts. Convert them to managed identities, restrict them by location or device, or remove interactive sign-in.
6. Upgrade the methods for high-risk roles. Issue hardware keys or enroll passkeys for administrators, executives, and finance staff. Remove text message as a primary method.
7. Protect the recovery path. Account recovery and help desk resets are an attack route. Require identity verification before resetting a method, and log every reset.
8. Set a recurring review. Re-run the registration report and exception list quarterly. Gaps reappear every time someone joins, leaves, or changes roles.

How to Test That Coverage Is Real

A configuration screen shows intent. A test shows behavior. Once the checklist is complete, pick three accounts at random, including one administrator and one shared mailbox, and try to sign in from an unfamiliar device and location. Attempt a sign-in using an older mail protocol. Ask the help desk to reset a method for a test user and see what verification they require. Each test takes minutes, and each one has a way of surfacing a path the reports missed. Keep the results with the review notes, since they are exactly the evidence a customer or underwriter asks for.

Making Adoption Stick

Technical enforcement fails when people work around it. Three practices reduce friction without weakening the control. Announce the date and the reason two weeks ahead, in plain language, from an executive rather than from IT. Hold short enrollment sessions or provide a one-page guide with screenshots of the exact steps. And give staff a clear path for a lost or replaced phone so that nobody ends up in the exception list because they were locked out on a Monday morning.

Contractors and vendors with access to your systems belong in the same program. Their accounts are often created quickly, rarely reviewed, and frequently outside the normal onboarding path.

Who Owns This After the Rollout

MFA is not a one-time project. It needs a named owner who reads the quarterly report, approves exceptions, and confirms that new applications connect to the identity system before they go live. In many growing companies that owner is the person who set it up, who may have since left or moved to other work.

Elevaire Systems works as Fractional IT Leadership alongside your existing managed service provider or internal IT team. Your provider keeps the identity platform running and the prompts working. The leadership layer decides what the policy is, which exceptions are acceptable, who is accountable for the review, and what evidence you can show a customer or an underwriter. The two roles fit together rather than overlap.

Frequently Asked Questions

How much does it cost to roll out MFA across a 100-person company?

For companies already on Microsoft 365 or Google Workspace, standard authenticator-app MFA is included in the licenses most organizations already pay for, so the main cost is time for configuration, enrollment, and support. Hardware security keys for administrators and finance staff typically add a modest per-person cost. The larger expense is usually cleaning up legacy systems and applications that cannot support modern authentication.

Will MFA slow my team down?

Modern prompts add a few seconds per sign-in, and many are remembered for trusted devices. Most of the friction comes from poor rollout, such as no enrollment support or no plan for lost phones, not from the control itself. Passkeys are often faster than a password plus a code.

How does this work alongside our existing MSP or IT team?

Your managed service provider or internal team usually handles the technical configuration and day-to-day support. Elevaire's Fractional IT Leadership sets the standard they implement against, reviews coverage and exceptions on a schedule, and prepares the evidence for customers, auditors, and insurers. It adds oversight to what they do and does not replace them.

Is text message MFA good enough?

It is better than a password alone, and it is still weaker than an authenticator app or a passkey. SIM-swapping and interception attacks are well documented. Use it only as a fallback, and move administrators and finance staff off it first.

What should we do if a leader refuses to use MFA?

Treat it as a business risk decision, not an IT preference. Executives and finance leaders are the most targeted accounts. Document the exception with an owner and an end date, offer an easier method such as a passkey or hardware key, and escalate to the CEO if it stays open past the deadline.

How do we get started?

Start with the two reports in the checklist above: who has not registered a method, and which policies bypass MFA. Those two lists usually show the size of the problem within an hour. If closing the gaps needs ownership and a schedule your team does not have bandwidth for, a Fractional IT Leadership engagement can set the standard and run the first quarterly review.