MFA Is Not a Checkbox: The Gap Australian SMEs Still Have

Ask an Australian business whether they have multi-factor authentication and most will say yes. Ask which systems actually require it, which sign-in routes can skip it, and who has been quietly exempted since March, and the conversation slows down. The Australian Signals Directorate (ASD) has already priced this in. Its Essential Eight maturity model describes attackers at one level circumventing weak multi-factor authentication (MFA) using technical and social engineering techniques, and attackers at the next level up defeating stronger implementations by stealing authentication token values to impersonate a user. Two of the four maturity levels are defined partly by the ability to get past MFA.

That is worth sitting with. The framework Australian businesses measure themselves against assumes, in writing, that the control they feel best about can be beaten. MFA still earns its place as one of the eight ASD mitigation strategies: it puts a second check between a stolen password and your systems, so one leaked credential stops being enough to get in. The protection comes from where the check is enforced, how it is delivered and who gets to skip it, and every one of those is a configuration question with a checkable answer. Four of them decide whether yours would hold: coverage, enforcement, method and exceptions.

TL;DR: What to remember

• ✅ ASD's maturity model treats getting past weak MFA as ordinary attacker capability, not an elite move. Two of the four maturity levels are partly defined by it.
• ✅ Four questions decide whether yours holds: where it is enforced, whether a sign-in can skip it, which method it uses, and who is exempt.
• ✅ Token theft gets an attacker in without your password and without your code. Session controls matter alongside the sign-in itself.
• ✅ MFA is one of eight strategies, and ASD asks for the same maturity level across all eight before any single one goes higher. A strong sign-in next to an untested backup is still a gap.

Contents

• Coverage: which systems actually require it
• Enforcement: whether a sign-in can skip it
• Method: which second factor you are actually using
• Exceptions: the exemptions nobody remembers granting
• Multi-factor authentication, answered plainly

Four questions decide whether yours holds

Most renewal conversations touch MFA at some point, and it is usually the control the business is most confident about, on the basis that it is switched on somewhere. Switched on somewhere is a start. Enforced MFA is a different state: a written list of covered systems, no sign-in route around the second check, a method chosen for the risk it carries, and every exemption documented with a review date. The gap between the two states is where accounts get taken over, and closing it rarely needs new software. It needs the four checks below, in order, and most of them cost an afternoon.

1. Coverage: which systems actually require it

The first question is not whether you have MFA. It is the list of systems where it is required, written down, held up against the list of systems that would hurt if somebody else got into them.

The gap is usually not the obvious one. Email and remote access tend to be covered, because those are the doors everybody thinks about. What gets missed sits slightly to the side: legacy systems that do not support modern authentication, service accounts and shared mailboxes, third-party platforms holding customer data, the administrative consoles for the tools that manage everything else, and access paths that predate the current setup and were never revisited. None of those doors advertises itself, and an attacker only needs one of them.

There is a practical exercise here that takes an afternoon. List every system that holds customer information or moves money. Mark each one enforced, available but optional, or unsupported. Most businesses find at least one entry in the third column that they assumed was in the first, and finding it on paper is considerably cheaper than finding it in an incident report.

2. Enforcement: whether a sign-in can skip it

Available and enforced are different states, and the difference is usually invisible from the admin console at a glance. MFA that a user can decline, postpone indefinitely, or route around through an alternative sign-in path is a suggestion, and attackers do not take suggestions.

The most common version of this in a real environment is a legacy authentication protocol left enabled alongside the modern one. The new path demands a second factor; the old path never did; an attacker simply uses the old path. It is rarely deliberate. It is usually the residue of a migration that left the old door open so something would keep working, and then everybody moved on to the next job. The something kept working. So did the door. Close the older path, then check it stayed closed. Lock it down.

Two questions worth putting to whoever administers your environment: can any user complete a sign-in to a covered system today without a second factor, and if so, by which route? A clear answer means somebody has checked. An answer about policy means nobody has.

3. Method: which second factor you are actually using

ASD's maturity descriptions distinguish weak implementations from stronger ones, which is a useful prompt to ask which method your business actually deployed, because the label MFA covers a wide range of strength.

Codes delivered by text message (SMS) are widely deployed and widely understood to be the weakest common option, because the delivery channel can be attacked without touching your systems at all. Push notifications are stronger, and they introduce a failure mode of their own: a user who receives repeated prompts at an inconvenient moment may approve one just to make it stop, which is a documented social engineering technique rather than a hypothetical. Number matching, which requires the user to enter a digit displayed on the screen they are signing in from, closes most of that gap cheaply. The strongest commonly available options are phishing-resistant methods that bind the authentication to the site being signed in to, so a convincing fake sign-in page cannot relay it. Whether that strength is warranted depends on the maturity level you are targeting and what you are protecting, which is the risk-based approach ASD asks for rather than a blanket recommendation.

Then there is the attack that bypasses the whole question. ASD's Maturity Level Three description names attackers circumventing stronger MFA by stealing authentication token values to impersonate a user. In plain terms: once you sign in successfully, your session is represented by a token, and an attacker who obtains that token is already inside. They never need your password. They never see your code. That is why session controls, sign-in monitoring and the ability to revoke active sessions matter alongside the authentication itself, and why a password reset without a session revocation sometimes changes nothing at all. The attacker you just locked out of the front door is still sitting in the lounge room.

4. Exceptions: the exemptions nobody remembers granting

Every environment accumulates exemptions. An executive travelling with poor connectivity. A device that could not enrol. An integration that broke when the control went on. A contractor who needed access for a fortnight in March. Each one was reasonable on the day it was granted, and very few of them ever get reviewed. The fortnight ends; the exemption stays.

ASD's assessment guidance takes a clear position on this. Exceptions should be documented, approved through an appropriate process, given compensating controls, and monitored and reviewed regularly, and where that is done properly an exception should not preclude an organisation from meeting the requirements for a maturity level. The distinction that matters is between a managed exception and a forgotten one. A managed exception has a name, a reason, a compensating control and a review date. A forgotten exception is a permanent hole nobody can see, because it was never written down.

A single forgotten exemption also costs more than itself. Under the same guidance, every control within a mitigation strategy must be assessed as effective, or as an equivalent alternate control, for that strategy to be claimed as implemented. An MFA deployment carrying an exemption that was never documented, approved or given a compensating control is the kind of thing that can stop a maturity level being claimed for that system. A properly managed exception does not have that effect, which is exactly why the distinction is worth the hour it takes to write them down.

Reviewing exemptions is unglamorous, takes an hour a quarter, and is the highest-return security work most businesses are not doing. It is also the reason this cannot be an annual project. Configuration drift is continuous, and a control that was effective in March is not automatically effective in September, which is why inSUPPORT maintains control state as ongoing work under the 6 Step Cyber Strength System rather than checking it once a year and hoping.

Multi-factor authentication, answered plainly

Is SMS-based MFA better than nothing?

Considerably better than nothing, and the weakest of the common options. If SMS is what you can deploy across everyone today, deploy it today and plan the upgrade, rather than waiting for the ideal rollout that keeps not happening. The businesses that get hurt are rarely the ones using a weaker second factor. They are the ones with no second factor on the system that mattered.

Our staff find MFA annoying. Can we reduce the prompts?

Usually yes, and doing it properly is a configuration question rather than a trade-off against security. Conditional access based on device compliance, and single sign-on so people authenticate once rather than repeatedly, both reduce friction while keeping the control. Treat trusted-device and sign-in-frequency settings more carefully: they genuinely cut prompts, and they also lengthen the window in which a session can be used without re-authentication, so set them deliberately rather than treating them as a free win. A blanket exemption for an individual is the version that actually removes the control, and it is the one to refuse.

Does MFA stop business email compromise?

It closes the most common entry route, and it does not close all of them. An attacker who steals a session token has bypassed the authentication entirely, and an invoice fraud run from a lookalike domain never touches your accounts at all. Pair it with out-of-band verification of any change to payment details, every time, no matter how plausible the email reads.

How do we know ours is configured properly?

Have it tested rather than described. ASD ranks evidence quality: testing a control ranks above reviewing a configuration, which ranks above a policy statement or a verbal assurance. "MFA is enabled" is the weakest form of evidence a provider can offer you. "We attempted sign-in on these systems by these routes and here is what happened" is the strongest, and it is the answer worth asking for by name.

Citations

• "Essential Eight maturity model", Australian Signals Directorate. The maturity level descriptions used above, including attackers circumventing weak multi-factor authentication and attackers stealing authentication token values to impersonate a user, and the requirement to reach the same maturity level across all eight strategies. cyber.gov.au
• "Essential Eight assessment process guide", Australian Signals Directorate. Evidence quality ranking, the treatment of exceptions and compensating controls, and the rule that every control in a strategy must be effective for that strategy to be claimed. cyber.gov.au
• "Essential Eight explained", Australian Signals Directorate. Multi-factor authentication as one of the eight mitigation strategies. cyber.gov.au

Framework guidance changes. This reflects ASD's published material as at August 2026, and ASD opened a consultation on evolving the Essential Eight in June 2026.

Related Reading

• Let's Talk About Passwords
• How the Essential 8 Maturity Model Benchmarks Cybersecurity
• The 6 Step Cyber Strength System
• What is included in inSUPPORT support

Content reviewed by Probably Genius for accuracy and relevance.

inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.