SMS-based MFA is now treated as a failed control by ASD’s Essential Eight guidance and by every major cyber insurer. If your Melbourne business still relies on text-message codes for accounts that matter, you are running a security control your insurer will dispute on claim day. Here is the practical fix.
What “phishing-resistant” actually means
The term gets thrown around loosely. The technical definition is sharper than people realise. A phishing-resistant authenticator is one where the secret used to prove identity cannot be replayed, phished or intercepted between the user and the legitimate service, and where the authentication is cryptographically bound to the actual domain being authenticated to.
In practice that means the authenticator checks the relying party, the actual domain the browser is connecting to, and refuses to release credentials to an attacker’s lookalike site. SMS does not do this. TOTP authenticator apps that spit out six-digit codes do not do this. Push notifications that show “approve or deny” without binding to a domain do not do this either, which is why attackers spent 2022-2024 perfecting MFA fatigue attacks.
The three things that actually qualify as phishing-resistant in 2026:
- FIDO2 security keys, physical hardware tokens like YubiKey 5, Google Titan, or Feitian devices that perform cryptographic challenge-response against the verified origin.
- Platform passkeys, credentials stored in Windows Hello, Touch ID, Face ID or Android’s keystore, syncing through iCloud Keychain or Google Password Manager, using the same FIDO2 protocol.
- Microsoft Authenticator with number matching and Authenticator-based passkeys, the modern Microsoft Authenticator experience now supports both number-matching push (a meaningful improvement) and full FIDO2 passkeys (the actual fix).
Notice what is missing. SMS, voice calls, email codes, TOTP apps like Google Authenticator or Authy, and old-school push notifications without number matching. All of those are second-factor controls, but none of them is phishing-resistant in the technical sense. Your insurer’s renewal questionnaire is going to ask very specifically.
Why SMS failed
SMS as a second factor has four structural problems that no configuration can fix.
SIM swapping. An attacker convinces your telco to port your number to their SIM. This is not theoretical. In a typical SIM-swap case the entire attack runs from “ported number” to “Microsoft 365 inbox compromised” in under ninety minutes, often on a weekend, with no malware involved. The MFA code went straight to the attacker.
SS7 interception. The signalling protocol that routes SMS messages between carriers has known weaknesses that allow message interception without touching the victim’s phone. Less common than SIM swapping, but documented in the wild against high-value targets.
Phishing kits with relay. Modern phishing kits (Evilginx, Modlishka, EvilProxy and their successors) act as transparent proxies between the user and the real Microsoft login page. The user types their password and SMS code into the attacker’s lookalike, the attacker relays both to Microsoft in real time, and walks away with a valid session cookie. SMS does not stop this attack at all. The user is genuinely authenticating; the attacker is just sitting in the middle.
User behaviour. SMS codes get forwarded, screenshotted, read out loud in open-plan offices, and pasted into chat windows. They are six-digit numbers transmitted in plain text. They were never designed to be a hard security control.
The ASD’s Essential Eight maturity model now explicitly requires phishing-resistant MFA at Maturity Level 2 for privileged users and Maturity Level 3 for all users. If you are aiming for ML2 or higher, SMS does not count. Essential Eight alignment is becoming a procurement prerequisite for state government work and an increasing number of private contracts, so this is not just a security debate.
YubiKey 5 vs platform passkeys: the cost comparison
Once you accept that SMS has to go, the next question is which phishing-resistant option to standardise on. The honest answer is “both, for different purposes”. Here is the comparison we walk Melbourne clients through.
| Factor | YubiKey 5 (USB-C / NFC) | Platform passkey (Windows Hello / Touch ID) | Microsoft Authenticator passkey |
|---|---|---|---|
| Hardware cost per user | $85-$110 for one key, $170-$220 for two (recommended) | $0 (uses existing device) | $0 (uses existing phone) |
| Lifespan | 5-10 years, no battery | Tied to device replacement cycle | Tied to phone replacement cycle |
| Cross-device usability | Excellent (works on any computer with USB/NFC) | Limited to the OS ecosystem (Apple-to-Apple, Microsoft-to-Microsoft) | Excellent via QR code cross-device |
| Recovery if lost | Backup key required, or admin reset | iCloud Keychain / Google sync handles it | Cloud-synced through Microsoft account |
| Phishing resistance | Full FIDO2 | Full FIDO2 | Full FIDO2 (when passkey enabled, not just push) |
| Best for | Privileged admins, break-glass accounts, shared workstations, executives | General staff on managed devices | Staff who prefer phone-based, BYOD-tolerant scenarios |
| Insurance acceptance | Highest signal of intent | Accepted | Accepted |
For most Melbourne SMEs, the right answer is platform passkeys or Authenticator passkeys for the general staff population, plus YubiKey 5 (in pairs, primary and backup) for the privileged admin accounts and the break-glass emergency account. Total hardware spend for a 50-person business is usually in the $800-$1,500 range, not the eye-watering number people imagine.
TechAssist’s rollout order: privileged first, then finance/exec, then all staff
Doing this in the wrong order is how rollouts get stuck. The sequencing matters more than the technology choice. Here is the order that actually works.
Phase 1: privileged accounts (week 1-2)
Every global admin, every Exchange admin, every SharePoint admin, every Azure subscription owner. Two YubiKeys each (one carried, one in a safe). FIDO2 enforced via Conditional Access. Old MFA methods removed for those accounts entirely. This is the population an attacker actually wants, and it is small enough to do in a fortnight.
For a typical 45-person business this phase covers perhaps seven accounts: a few IT admins, the CEO, the CFO, and the office manager who has been a global admin since 2017 for reasons nobody remembers. Three of those seven had their admin rights stripped during the phase, because they did not need them.
Phase 2: finance and executive (week 3-4)
Anyone who can authorise a payment, anyone who can sign a contract, anyone whose inbox compromise would lead to a business email compromise wire fraud incident. Platform passkeys or Authenticator passkeys are usually the right tool here, with YubiKeys offered for users who travel internationally or work across multiple devices.
This phase is the one the CEO cares about, because it is also the population most likely to be socially engineered. BEC against the CFO’s inbox is the single most common direct-loss incident we see in Melbourne SMEs. The phishing-resistant control is the actual fix.
Phase 3: all remaining staff (week 5-8)
Roll passkeys out by department, in waves of fifteen to twenty users. Set a hard date by which SMS-based MFA is removed as an option in Conditional Access. Provide hands-on registration in the office for anyone who needs it. We typically allocate one engineer-hour for every five users for the registration push.
By week eight, your Conditional Access policies should be enforcing phishing-resistant MFA for all user sign-ins, with SMS removed from the available authentication methods list. That is the point you can tell the insurer the work is done.
The three traps that derail most rollouts
Even with the right order, three things consistently trip up MFA migration projects. We have learned to address these up front, not as afterthoughts.
Trap 1: shared mailboxes
Shared mailboxes in Microsoft 365 do not have their own sign-in credentials. They cannot have MFA in the traditional sense. The trap is that people forget about the user accounts behind them, the “reception”, “accounts”, “support” mailboxes that started life as full licensed users and got converted to shared at some point, but where the underlying user object is still active and signable-in.
We did a sweep at a Box Hill manufacturer last quarter and found four accounts converted to shared mailboxes years earlier where the user object still had a password, no MFA, and was a member of the global admin group. That is a real incident waiting to happen, and Conditional Access alone will not catch it unless the accounts are properly disabled.
Trap 2: service accounts
Service accounts, for the scan-to-email function on the photocopier, for the integration with the line-of-business app, for the legacy reporting tool that runs at 2am, were typically created without MFA because “you can’t put MFA on a service account”. This is partially true and entirely solvable.
The fix is a combination of: moving to certificate-based auth or app registrations with managed identities where possible, applying conditional access policies that restrict service accounts to specific source IPs or compliant device states, and putting compensating controls (privileged access workstations, vaulted credentials) around the genuinely legacy ones that cannot be modernised. Our managed IT services team treats this as a separate workstream because it always takes longer than the human user migration.
Trap 3: break-glass admin accounts
You need at least one global admin account that is excluded from your Conditional Access policies, so that if your tenant configuration somehow locks everyone out you can still log in and fix it. This account is by definition not protected by your normal controls, which makes it the single highest-value target in the tenant.
The correct setup is two break-glass accounts, each with a long random password stored in two separate physical safes, each requiring a FIDO2 security key (also stored separately), with sign-in alerts configured to notify multiple senior people if either account is ever used. The accounts should be tested quarterly to make sure they still work, and the test should be logged. Most Melbourne SMEs we audit have either no break-glass account, a break-glass account that is also a daily-driver, or a break-glass account whose password is in a sticky note in the IT manager’s desk. All three are wrong.
Conditional Access: the policy that makes it real
You can buy all the YubiKeys you like, but if your Conditional Access policies still allow SMS as a fallback, users will fall back to SMS. The policy work is what turns the rollout from “available” to “enforced”.
The minimum viable policy set for a Melbourne SME running Entra ID (formerly Azure AD) looks like this:
- All users (excluding break-glass) require phishing-resistant MFA for all cloud apps.
- Privileged role activations require FIDO2 security key specifically, not just any MFA method.
- Legacy authentication protocols (POP, IMAP, SMTP AUTH, legacy ActiveSync) are blocked entirely.
- Sign-ins from outside Australia require either compliant device state or additional verification.
- Risky sign-ins (per Microsoft Entra ID Protection signals) require password reset.
This policy stack costs nothing extra if you already have Microsoft 365 Business Premium, which includes the relevant Entra ID P1 features. If you are on Business Standard, the gap is about $9 per user per month for the Entra ID P1 add-on. For a 30-person business that is roughly $3,200 a year, cheaper than a single business email compromise incident excess on most cyber policies.
Cyber insurance: the elephant in the room
Every Australian cyber insurance renewal questionnaire we have seen in the last twelve months asks the phishing-resistant MFA question directly, in some form. The wording varies, but the intent is identical: “Do all privileged accounts use phishing-resistant MFA? Yes/No.” A “No” answer either triggers a steep premium increase, a coverage exclusion for BEC-related losses, or in some cases a refusal to quote.
We had a Hawthorn law firm client whose 2025 renewal came back with a 60% premium increase plus a $50,000 BEC sub-limit, specifically because they were still on SMS MFA for the partners. We did the rollout in three weeks, got the underwriter the updated configuration evidence, and the renewal was repriced to the previous year’s level with the sub-limit removed. The phishing-resistant MFA work paid for itself in one premium cycle.
This is now the most cost-effective security investment a Melbourne SME can make on an ROI basis, full stop. The technology cost is modest, the configuration time is measurable in days not weeks, and the insurance saving is direct and immediate. There is no better-value security project on the table in 2026.
What this looks like at TechAssist
We run phishing-resistant MFA rollouts as a structured project, not an ad hoc ticket. A typical engagement runs four to eight weeks elapsed, depending on the size of the user base and the state of the existing Conditional Access policies. We do the discovery, the policy design, the YubiKey procurement and shipping, the user registration sessions (on-site for Melbourne metro clients with same-business-day response if anything goes wrong), and the cutover.
Because our practice is Essential Eight aligned, the documentation pack is structured to give your insurer or auditor exactly what they ask for. That matters more than it sounds. Businesses that do MFA rollouts internally often struggle to produce the evidence the underwriter wants at renewal. The rollout was fine; the paperwork was the problem.
The same approach works for construction firms, manufacturers, law firms and healthcare providers. The technical work is similar across industries; the change management is what varies. A law firm partnership is a different conversation from a warehouse-floor manufacturer, and the rollout plan has to reflect that.
Frequently Asked Questions
Will my staff actually use FIDO2 keys or will they revolt?
Genuine objections drop fast once people use the keys for a week. The sign-in experience with a YubiKey is faster than typing a six-digit SMS code, touch the key, done. Platform passkeys are even faster because they use the biometric the user is already using to unlock the laptop. The main grumbling tends to come from executives who travel and need to use multiple devices, which is a real concern that pairs of YubiKeys solve.
What happens if a user loses their YubiKey?
This is why we issue two per privileged user. The user uses the primary, the backup is in a safe (often a home safe for senior staff who travel, or a locked drawer in the office). If both are lost simultaneously, the admin can reset the user’s authentication methods via a separate verified process. The point is to design the recovery path before it is needed, not after.
Can we just use Microsoft Authenticator and skip the hardware keys?
For general staff, yes. Microsoft Authenticator with passkey support is genuinely phishing-resistant and meets the bar. For privileged admin accounts and break-glass accounts, we still recommend hardware keys because they are not tied to a phone that can be lost, stolen, broken or compromised. The privileged accounts justify the extra cost.
Do we need to upgrade our Microsoft 365 licences for this?
If you are on Microsoft 365 Business Premium, no, you already have the Entra ID P1 features needed for Conditional Access. If you are on Business Standard or Business Basic, you need either to upgrade to Premium or add Entra ID P1 as an add-on. The cost is usually in the order of $5-$10 per user per month depending on the path.
How does this interact with our existing TOTP authenticator app?
TOTP (the six-digit code apps like Google Authenticator) is not phishing-resistant and should be retired alongside SMS. The migration usually runs in parallel, users register their passkey or YubiKey, verify it works, then remove TOTP as a registered method. Conditional Access policies should explicitly require phishing-resistant authentication strength, which excludes TOTP from being a valid method.
How long does the whole project take?
For a typical 40-person Melbourne SME on Microsoft 365, four to six weeks from kickoff to fully enforced. The first fortnight covers discovery, policy design and privileged accounts. Weeks three and four cover finance and executive. Weeks five and six cover the broader staff base. Faster is possible but rarely advisable, the change management is what determines whether the rollout sticks.
What to do this week
If you take nothing else from this article, do three things this week. First, find out what authentication methods your Microsoft 365 tenant currently allows, the “Authentication methods” blade in the Entra admin centre tells you. Second, identify how many of your global admin accounts could be compromised by an SMS-based phishing attack today. Third, get a quote for FIDO2 security keys in pairs for that admin population.
That is a half-day of work that gives you the starting position. From there, the rollout is a structured project with measurable milestones. The Melbourne SMEs that have done this in 2025 are now paying lower insurance premiums, sleeping better, and not having the awkward “yes we still use SMS” conversation with their auditors.
If you would like a hand running this for your business, discovery through cutover, talk to us. We know where the traps are.
