Ask a practice whether it has multi-factor authentication and the answer is usually yes. Ask where, and the answer is usually email.
The ASD's Essential Eight is considerably more specific than that, and reading its actual requirements is a quick way to find the gaps. Multi-factor authentication is one of eight mitigation strategies — alongside patching applications and operating systems, restricting administrative privileges, application control, restricting Microsoft Office macros, user application hardening and regular backups — and the maturity model spells out what implementing it means.
What the baseline actually asks for
At Maturity Level One, the maturity model requires MFA in six places. Three of them are the ones practices miss.
- to authenticate users to your own online services that process, store or communicate your sensitive data
- to authenticate users to third-party online services that process, store or communicate your sensitive data
- where available, to third-party online services holding your non-sensitive data
- to your own online customer services holding sensitive customer data
- to third-party online customer services holding sensitive customer data
- to authenticate customers to online customer services holding sensitive customer data
The third-party limb is the one that changes the answer. Every cloud service your practice uses that holds client information is in scope — document storage, the case management system, the e-signature provider, the accounting package, the translation vendor's portal. MFA on your mailbox does not address any of them.
The last limb is the one nobody expects: where you run a client portal holding sensitive client information, the requirement extends to authenticating the clients themselves.
What counts as a factor
The maturity model defines it: MFA uses either something users have and something users know, or something users have that is unlocked by something users know or are.
Two consequences. A password plus a security question is not MFA — both are things you know. And a passkey on a device unlocked by a fingerprint satisfies the second form.
At Maturity Level Two the requirements tighten in a way worth planning for even if you are not targeting it. MFA extends to authenticating both privileged and unprivileged users of systems, not just online services, and the MFA used for online services and for systems must be phishing-resistant — with a phishing-resistant option offered to customers of online customer services.
That matters because it is a direct answer to the attack that actually happens. Maturity Level Two describes adversaries who actively target credentials using phishing and employ technical and social engineering techniques to circumvent weak multi-factor authentication. Code-based MFA is bypassed by relaying the code in real time; a passkey or hardware key is not.
ImmiAccount is a Code problem before it is a security one
The instinct in a busy practice is to share the ImmiAccount login so paralegals can lodge without waiting for an agent.
Set aside the security argument entirely. Section 25(3) of the Code requires an agent to take all reasonable steps to ensure their MARN is not used in a way suggesting that immigration assistance given by another person was given by the agent. Section 25(4) requires written notice to the Authority within 14 days of becoming aware the MARN is being used by another person.
OMARA's practice management guidance names this specifically, listing among the supervisory arrangements an agent should have in place that their MARN "is not improperly used by employees to lodge visa applications through ImmiAccount".
A shared credential makes both obligations impossible. You cannot show whose work a lodgement was, and you would have no way of detecting the misuse you are obliged to report. Our ImmiAccount workflow guide covers the practical alternatives, and the Code compliance checklist covers the surrounding duties.
The MFA point follows from that. A second factor attached to an account four people use does not authenticate anyone.
An order to do this in
The ASD's small business cyber security guide is the practical entry point for a practice without an IT team. In a migration practice, the sequence that removes most risk first is:
- Email, because it is the reset mechanism for everything else. An attacker with the mailbox has every other account.
- The case management system, because it holds the files.
- Document storage, if it is separate from the case management system.
- Government-facing accounts — one per person, no exceptions.
- Accounting and banking, particularly anything that can change payee details.
- Remote access, if anyone connects to an office network.
- The client portal, so clients uploading passports are protected too.
Recovery is the part that gets skipped
MFA introduces a new failure mode: the person is available and the factor is not. Phone lost, staff member on leave, device replaced.
Practices handle this badly in one of two directions. Either there is no recovery path, and a lost phone becomes a day of lost work at exactly the wrong moment — or the recovery path is so loose that it is easier to attack than the MFA itself. A help desk that resets a factor on the strength of a phone call has not implemented MFA; it has implemented a queue.
Three things make this manageable:
- Two factors registered per person, so losing one is an inconvenience rather than an outage.
- Recovery codes stored somewhere that is not the mailbox they protect — a password manager or a sealed physical copy.
- A break-glass account for the practice's core systems, with a long unique passphrase, MFA, no day-to-day use, and an alert when it is used. Test it once a year and never let it become someone's convenience login.
The MFA audit
Go through this once, listing every service that holds client information:
- Which services hold client information, including ones you did not procure formally?
- Which of those have MFA enabled — not merely available?
- Does anyone still share a login anywhere?
- Is MFA phishing-resistant, or code-based?
- Does each person have a second registered factor?
- Where are the recovery codes, and are they in the mailbox they protect?
- Would a departing staff member lose access to everything on their last day?
- Does your client portal require more than a password?
Where a system helps
Fewer systems is the underrated control. Every additional service holding client information is another login to protect, another recovery path to secure, another account to remove when someone leaves, and another vendor whose breach becomes your breach.
A practice running client files across email, a shared drive, a signing tool, a spreadsheet and a messaging app has five MFA problems and five offboarding problems. Consolidating the work reduces the number of doors before you start locking them. Our guide to moving off legacy tools covers what that transition involves.
LodgeHQ keeps matters, documents, correspondence and client access under one set of individual accounts. Start a free trial and count how many separate logins currently touch a single client's file.
Verify before you rely on it
The Essential Eight maturity model is updated regularly and the requirements described here move between levels over time. Read the current model directly before setting a target, and check the ASD's small business guidance for the plain-language version.
This is general information for migration practices, not security advice tailored to your environment. Where you handle protection matters or hold information whose exposure could put someone at physical risk, get proper advice on your controls.