Roll out MFA without locking the business out

Begin with the accounts that control the business

Multi-factor authentication, or MFA, asks for more than one type of evidence when someone signs in. Australian government cyber guidance recommends enabling it for business accounts. Start with email, administrator access, banking, domain registration and other high-impact services, then extend coverage. A compromised email account can affect password resets elsewhere, so protecting only the accounting system leaves an important gap.

MFA reduces risk; it does not make an account immune to compromise. Staff still need to recognise suspicious requests, keep devices updated and protect recovery access. Treat rollout as a small operational project with an owner and completion checks rather than an instruction to everyone to install an app by Friday.

Map the available methods

Check the methods each product actually supports in your edition. Options may include authenticator apps, physical security keys, passkeys or SMS. They differ in usability, recovery and resistance to phishing. Ask your IT provider to recommend an appropriate method for high-impact accounts and explain the trade-offs in language staff can use.

Do not choose a method solely because it is familiar if it creates a single point of failure. For example, a code delivered to a phone may be inaccessible when the phone is lost or the staff member leaves. Do not share one employee's personal authentication method among several people. Use individual accounts and a documented recovery process that remains under business control.

Plan recovery before enforcement

Identify at least two authorised people who can administer important services where the platform permits it. Keep emergency recovery material in a secure, controlled location and document how it may be used. Test a recovery scenario without deliberately locking out the only administrator. If the vendor has an emergency access design, have a competent person configure and review it.

Record where recovery codes are stored, who can access them and when they need replacing. Do not paste the codes into an ordinary checklist, email or this website's tools. A checklist can track that a recovery method exists without collecting the secret itself. Review recovery details after a role change, lost device or suspected account incident.

Pilot with representative staff

Start with a small group covering office, mobile and administrator roles. Confirm that sign-in works on normal devices and applications, including email clients and integrations. Older applications or unattended processes may need a different supported authentication arrangement. Do not disable security across the whole business to keep one untested legacy integration working.

Give staff short instructions showing the expected sign-in prompt, how to report an unexpected request and whom to contact after a lost phone. An unexpected approval request should be treated as a reason to stop and report, not as a nuisance to approve until it disappears. Keep support available during rollout, especially for staff working away from the office.

Verify coverage and deal with exceptions

Use the administration view to check which accounts are enrolled and which are required to use MFA. A staff member saying they installed an app is not proof that protection is enforced on every relevant service. Include owners, contractors and privileged accounts. Record any exception with its reason, owner, compensating measure and review date.

Do not describe checklist completion as a validated security rating. The account security checklist tracks actions, not assurance. A proper assessment may need log review, configuration testing and specialist advice. Prioritise unresolved high-impact exceptions rather than chasing a perfect percentage that hides an unprotected administrator account.

Keep a practical decision record

Track the rollout by service as well as by person. A user may have strong protection on email but a separate unprotected supplier account. For each important service, record whether MFA is supported, enabled and enforced, along with the authorised recovery owner. Keep exceptions visible until they are resolved or formally accepted. If the business uses a central identity platform, confirm which applications actually rely on it and which retain independent logins. Central administration is useful, but an assumed connection is not evidence that every account follows the same policy.

Maintain the rollout

Add MFA setup to onboarding and recovery review to offboarding. Update the method when staff change devices, and remove obsolete access. Keep the product's current instructions with your internal procedure because interfaces and supported methods change. Recheck high-impact accounts periodically and after a supplier changes your identity configuration.

A practical first action is to list ten critical services, their owners, current method and recovery status. Assign a due date to gaps and ask for evidence of enforcement. Combine that work with a staff offboarding process and a phishing response plan. MFA is a useful control when it is operated consistently and recoverably, rather than installed once and forgotten.