How We Actually Deploy MFA for Small Businesses in Arizona

Multi-factor authentication is no longer the hard part. Getting the scope right, and keeping it right, is.

Most small businesses we take over already have MFA somewhere. What they do not have is a clear answer to where it is actually enforced — and that gap is not academic. It is the single most common wrong answer on cyber insurance applications, and it is the answer that got a $1 million policy rescinded in Travelers v. International Control Services, where the insured had attested to MFA on email, remote access and endpoints while it was in fact deployed only on the firewall.

This is how Axio Networks deploys MFA across small businesses in Scottsdale and the Phoenix metro: what we turn on by default, where MFA still cannot reach, what actually breaks afterwards, and how to handle the awkward cases nobody writes about — the shared front desk, the service account, the scanner that emails.

What we deploy by default

For a Microsoft 365 client — our preferred platform — the default is Microsoft Authenticator, using both push notification and passkey. For a client on Google Workspace, it is Google Authenticator against their Workspace accounts.

The reason for passkeys rather than codes is that a passkey cannot be phished. A stolen password is worth nothing against it, and an adversary-in-the-middle proxy — the technique that has replaced simple credential theft — has nothing to relay. A one-time code, by contrast, can be typed into a convincing fake login page by a careful person having a busy morning. That is why sign-in strength and endpoint detection are complementary rather than alternatives: one narrows the ways in, the other catches what still gets through.

The good news is that this argument no longer needs to be won. Passkeys have become genuinely easy to deploy, particularly now that they sync through password managers, and we see very little client resistance compared with a few years ago. The objection we used to plan around has largely evaporated.

Push notification is worth keeping alongside, and it is safer than it once was: Microsoft has had number matching enabled by default for Authenticator push since May 2023, which closed off the push-bombing attack where an attacker simply spams approval prompts until someone taps to make it stop.

You are almost certainly already paying for this

Before anyone prices an MFA product, it is worth checking what is already sitting unused in the licence.

When we audit a new client’s Microsoft 365 tenant, more than half of them have not been configured at all. Somebody bought a handful of licences, created user accounts on the company domain, and started working. That is the whole configuration. The tenants that have gone further are usually still very loose on security groups, and nothing has been touched beyond the initial Microsoft 365 admin center — drill down into Entra, Exchange or Defender and it is bare-bones defaults, no customisation, no spam or phishing filtering. It is also why turning on Copilot in an unconfigured tenant goes badly: the permissions were already too broad, and Copilot just makes them easy to ask about.

The capability was there the entire time. Phishing-resistant sign-in, conditional access, alerting on suspicious sign-ins: all of it ships with the licence a business is already buying. It just requires somebody to turn it on and own it afterwards, which is the difference between a managed tenant and a rented one.

This is the same pattern behind almost every incident we clean up. The tools are not missing. They were never configured, nobody owns them, and the alerts they generate are not going anywhere a person looks. MFA is simply the most consequential example, because it is the control standing between a stolen password and your email.

Where MFA still cannot reach

Here is the part that surprises people. In the environments we manage, almost everything is on push or passkey. The weak authentication is not in the systems we control — it is in the third-party portals your staff log into all day.

Banking portals and credit card systems are the worst offenders. A great many financial web applications still offer SMS or email codes and nothing else. SMS is the weakest factor in common use: it is exposed to SIM swapping, to interception, and to a support agent at a mobile carrier being talked into a transfer.

You usually cannot fix this, because the option does not exist. What you can do is know where it applies, treat those specific accounts as higher risk, and make sure the email account that receives the reset codes is itself protected with something phishing-resistant. If an attacker owns the mailbox, every “email me a code” fallback in the business belongs to them too. That is why email security and MFA are the same project rather than two.

What actually breaks, and when

The fear is that MFA will cause a support pile-up on day one. In practice the morning after go-live is usually quiet, because we set a trusted exclusion for the office IP address so staff in the building are not challenged on every sign-in. The friction arrives later, and it is predictable.

A user gets a new phone. This is the big one. Historically it meant a lost authenticator and a re-enrolment. It has improved a great deal now that Microsoft Authenticator backs up to the user’s account and to the phone’s own backup service, but it remains the most common MFA ticket we see. It is worth telling people, before they upgrade rather than after, that the authenticator needs moving deliberately — and it is exactly the kind of five-minute job a help desk should absorb without it becoming an afternoon.

Somebody travels. Signing in from an unfamiliar location, particularly from another country, will legitimately trigger additional challenges. This is the control working. It is still worth warning people who are about to fly.

Occasional grumbling about prompt frequency. Usually the interval is reasonable, and once the reason is explained the objection tends to disappear. We have found this is a communication problem far more often than a configuration one.

None of these are reasons to weaken the deployment. They are reasons to tell people what to expect, which costs nothing and removes most of the friction.

MFA is the floor. Conditional Access is the building.

Turning MFA on answers “is this the right password.” Conditional Access answers the more useful question: should this sign-in be allowed at all, from this device, in this state? It ships with the licence most businesses already hold, and it is almost never configured.

This is the baseline we deploy. It is not exotic, and that is the point.

• MFA required for all users and all resources. No carve-outs by seniority. The owner is the most-targeted account in the business, not the least.
• Legacy authentication blocked entirely. Older protocols predate MFA and cannot enforce it, so leaving them enabled leaves a door that ignores every other policy. This one change closes off a large share of password-spray attacks.
• Unsupported operating systems blocked. If a device is running something that no longer receives security updates, it does not get to authenticate. This is the policy that turns an unpatched Windows 10 machine into a login failure rather than a slow-burning risk.
• Mobile app protection policies, and compliant-device requirements on desktops. Company data on a phone stays inside managed apps; desktops must be enrolled and healthy before they are trusted.
• Device code flow blocked. A legitimate feature that has become a favoured phishing technique, because it produces a real Microsoft prompt the victim is talked into completing.
• Sign-in risk policy at medium and above, and user risk policy at high. Microsoft’s own signals — impossible travel, anonymous IP, leaked credentials — trigger a challenge or a block automatically, without anybody watching a dashboard.
• Token protection, and protection around password reset. This is the countermeasure to the session-hijacking attack that defeats ordinary MFA: binding the token to the device it was issued to means a stolen session cannot simply be replayed elsewhere.
• Intune enrolment, so device compliance is something measured rather than assumed.

Then the administrative model, which is where most small tenants are weakest. Global administrator rights are stripped from ordinary user accounts — no public-facing, email-receiving, web-browsing account carries admin privilege. Where someone genuinely needs administrative access, a separate admin account is created and scoped strictly to what that person needs. And every technician Global Administrator account we hold is FIDO2-enforced.

That last point is one to hold your own provider to. An external administrative account without phishing-resistant MFA is one of the highest-value targets in your environment, and asking the question costs nothing.

The cases nobody writes about

Generic MFA advice assumes one person, one account, one phone. Real small businesses are messier, and these three cases are where deployments quietly get abandoned.

The shared front-desk computer. The instinct is a shared login, which destroys accountability and makes MFA impossible. The answer is that the machine is shared and the accounts are not. Set it up so each person signs in with their own Entra ID account and gets their own profile on that machine. Someone locks it, the next person unlocks with their own PIN, and everyone still has an individual identity, individual permissions and an individual audit trail. Nothing about a shared desk requires a shared account.

Service accounts. These are handled case by case, because what is possible depends entirely on what the service supports. The principle is to make the security as tight as the platform allows and to know exactly which accounts are exceptions — an undocumented service account is worse than a documented weak one, because nobody is watching it.

The scanner that emails. Multifunction printers are notoriously poor at security and ship with well-known default management passwords. Ours do not get direct access to internal systems or a mailbox credential. Instead the device sends through an SMTP relay that brokers the handshake between the scanner and the mailbox. The scanner never holds credentials worth stealing, and compromising it does not hand anyone a way into the tenant.

That last one matters more than its size suggests. A device sitting on the network with a default password and a working mailbox credential is a foothold, and it is exactly the kind of thing that survives every audit because nobody thinks of the copier as a computer.

Getting the scope right

Because “do you have MFA” is the wrong question, here is the one worth answering. MFA needs to be enforced on:

1. Email, for every user without exception, including the owner.
2. Every remote access path — VPN, remote desktop, any published application. This is the one most often missed, because it was set up before the tenant was.
3. All administrative accounts, including any held by an outside IT provider. If your MSP has an admin account without phishing-resistant MFA, that is your exposure, not theirs.
4. Finance and anyone who can move money. These are the accounts an attacker actually wants, per our walkthrough of how wire fraud reaches Arizona businesses.

If you cannot answer all four with a confident yes, then the honest answer on an insurance application is no or partial — and as we cover in our guide to what cyber insurance covers and what gets denied, an honest no with a remediation date is worth far more than an optimistic yes.

Frequently asked questions

Is SMS-based MFA better than nothing?

Yes, meaningfully so — it defeats simple password reuse. But it is the weakest factor in common use, vulnerable to SIM swapping and interception, and it should not be the method protecting email or administrative access. Where a third-party portal offers nothing else, accept it, note it, and make sure the mailbox receiving the fallback codes is protected by something stronger.

Are passkeys hard to roll out in a small business?

Not any more. Deployment has become straightforward, especially now that passkeys sync through password managers, and in our experience client resistance is minimal compared with a few years ago. The obstacle now is usually that nobody has scheduled the work.

Does MFA stop phishing?

Phishing-resistant MFA does. Passkeys, FIDO2 security keys and Windows Hello for Business cannot be relayed by a proxy login page. Codes and push approvals can still be defeated by an adversary-in-the-middle attack that captures the resulting session token, which is why the method matters and not just the presence of a second factor.

How do we handle MFA on a shared computer?

Share the machine, not the account. Each person signs in with their own Entra ID account and gets their own profile on that device, so identity, permissions and audit trail all stay individual. A shared login is what makes MFA look impossible, and it is avoidable.

What happens when someone gets a new phone?

It is the most common MFA support ticket. Modern authenticator apps, Microsoft Authenticator included, back up to the user’s account and the phone’s backup service, which has made this much less painful — but it still needs doing deliberately. Tell people to move the authenticator before they wipe the old handset, not after.

Should our IT provider’s admin accounts have MFA?

Absolutely, and phishing-resistant MFA specifically. Every technician Global Administrator account we hold is FIDO2-enforced, and we strip global admin rights from ordinary user accounts entirely so that no account which receives email also carries administrative privilege. An external administrative account without phishing-resistant MFA is one of the highest-value targets in your environment — ask your provider directly what protects theirs.

Sources and further reading

• Microsoft Entra: number matching in Microsoft Authenticator — default since May 2023.
• Microsoft Entra: passwordless and passkey authentication.
• CISA: More Than a Password — guidance on phishing-resistant MFA.
• FBI Internet Crime Complaint Center annual reports.