Audit Ready Two Factor Authentication for Australian Healthcare

Yes, implement phishing-resistant multi-factor authentication on electronic health records, remote and VPN access, and privileged accounts first. This single step closes the gap that credential theft exploits most often. ACSC guidance backs this priority, and organisations following it should keep audit evidence ready: configuration records, access logs and test results that show MFA is live where it counts.
TL;DR:
- Prioritize enabling MFA on electronic health records, remote access, and privileged accounts, as these are most likely to be targeted in healthcare breaches.
- Use phishing-resistant methods like security keys or passkeys for sensitive and privileged accounts, while employing authenticator apps for general staff.
- Design MFA deployment around clinical workflows, supporting risk-based prompt frequency, single sign-on, and clear recovery processes to reduce prompt fatigue.
- Maintain thorough documentation, including access logs, MFA configuration records, testing results, and staff training to ensure regulatory compliance.
- Continually monitor and review MFA effectiveness through audits, support ticket analysis, and periodic testing, especially during phased rollout to manage support overload.
Table of Contents
- What multi-factor authentication is and why it matters in healthcare
- Where to apply MFA: a prioritised map of systems and access routes
- MFA methods: recommended choices and what to avoid
- Designing MFA for clinicians: frequency, SSO and usability
- Policy and compliance checklist for regulatory alignment
- Deployment checklist: from inventory to ongoing assurance
- What rolling out MFA across a health service actually teaches you
- How Meddle supports compliance-first practices
- FAQ
- Sources
What multi-factor authentication is and why it matters in healthcare
Multi-factor authentication asks for two or more proof types before granting access: something you know (a passphrase), something you have (a security key or phone), and something you are (a fingerprint or face scan). ACSC guidance groups these as knowledge, possession and inherence factors, and recommends combining at least two categories rather than relying on a password alone.

Healthcare data carries a particular weight. A stolen password alone unlocks a patient’s entire clinical history, Medicare details and referral chain, not just one account. MFA breaks that chain: even when a password leaks through phishing or a data breach elsewhere, the attacker still needs the second factor.
A few patterns show up repeatedly in healthcare breaches:
- Phished clinician credentials used to log into cloud-based EHR portals from unfamiliar locations.
- Stolen VPN credentials used to pivot from remote access into internal clinical systems.
- Compromised vendor or payer portal logins used to exfiltrate billing and patient identity data.
Each of these is stopped, not just slowed, by a properly configured second factor sitting between the password and the data.
Where to apply MFA: a prioritised map of systems and access routes
Not every login carries the same risk, so rollout order matters as much as rollout speed. Start with the access routes that touch the most patient data or the most privileged functions, then work outward.
- Electronic health records and clinical systems, including any portal connected to My Health Record.
- Remote and VPN access, the route most often used to bridge into internal networks from outside.
- Cloud and system administration accounts, where one compromised login can expose entire environments.
- Email, the most common phishing entry point and a frequent source of credential harvesting.
- Backups and disaster recovery systems, often overlooked despite holding full copies of patient data.
- Vendor, payer and referral portals, where third-party access can become an unmonitored side door.
- APIs and integration endpoints, particularly those connecting practice management software to external services.
The Medibank concise statement is instructive here: the regulator’s case centred on a VPN login that lacked MFA, which gave an attacker a path into internal systems that held far more sensitive data than the entry point itself. The lesson is not to secure the front door and stop. Internal sensitive assets, the ones clinicians and admin staff touch every day, need the same protection as the perimeter.
For a small practice, this prioritisation might mean enabling MFA on the practice management system and remote access within the first fortnight. For a larger health service with dozens of integrated systems, it means mapping every access route before committing to a rollout order, since gaps in vendor and API access are easy to miss until an audit or incident exposes them.
MFA methods: recommended choices and what to avoid
Not all second factors offer the same protection. Digital Health guidance recommends strong passphrases paired with a phishing-resistant method, prioritising authenticator apps and security keys over SMS.
- Authenticator apps (TOTP): generate time-based codes on a device, resistant to interception but still vulnerable to real-time phishing if a user is tricked into entering a code on a fake site.
- Security keys and passkeys: use public-key cryptography tied to the specific website or app, making them resistant to phishing because a fake site simply cannot complete the handshake.
- TPM-based certificates and biometrics: bind authentication to the physical device itself, useful for clinical workstations that stay in one location.
- Physical OTP tokens: similar security profile to authenticator apps, useful where staff cannot install apps on personal phones.
- SMS codes: better than a password alone, but vulnerable to SIM-swapping and interception, and explicitly flagged by ACSC as weaker than phishing-resistant alternatives.
For setup mechanics, AHPRA’s guidance walks through the typical authenticator app workflow: download the app, pair it by scanning a QR code or entering a manual key, then enter the six-digit code it generates at each login.
Pro Tip: Treat SMS as a stopgap for staff who cannot yet use an app or key, never as the standard for new accounts.
The practical recommendation for clinical environments is straightforward: default to authenticator apps for most staff, move to passkeys or security keys for privileged and administrative accounts, and phase out SMS wherever a better option is available.
Designing MFA for clinicians: frequency, SSO and usability
Security that clinicians route around is not security. The ADHA developer requirement for MFA recognises this directly, mandating that healthcare software support configurable authentication frequency rather than forcing a single rigid prompt on every login.
That configurability matters in practice. A clinician moving between patient rooms on a hospital-issued, already-authenticated device needs a different prompt frequency than an administrator logging in remotely from an unfamiliar network. Risk-based, or step-up, authentication lets you ask for the second factor only when the context changes: a new device, an unusual location, or access to a particularly sensitive record.
A few design patterns reduce friction without weakening protection:
- Pair MFA with single sign-on so clinicians authenticate once per shift rather than once per application.
- Set session timeouts that match clinical workflow, long enough to avoid repeated interruptions, short enough to limit exposure on shared terminals.
- Build documented emergency override processes for genuine clinical urgency, with every override logged for review.
- Apply stricter, more frequent authentication to privileged and administrative accounts regardless of device or location.
Prompt fatigue is a real failure mode: staff bombarded with constant authentication requests start approving them reflexively, which defeats the purpose. Training that explains why each prompt exists, combined with sensible frequency settings, does more to prevent this than any technical control alone. Our guide to single sign-on in healthcare covers how to combine SSO with MFA without multiplying login friction.
Policy and compliance checklist for regulatory alignment
Technical controls only satisfy a regulator when the paperwork behind them does too. My Health Record Rule 42, assessed by the OAIC, requires participants to maintain documented security and access policies, assign unique login credentials for remote access, manage account provisioning and deactivation, and keep audit logs recording who accessed which record and when.
The OAIC’s own assessment work sets the expectation that these controls are tested, not just written down. The Medibank concise statement shows what happens when they are not: regulatory action followed the absence of MFA on a remote access point, with remediation requirements covering both the entry point and the internal systems it exposed.
Keep these artefacts current and ready for review:
- A documented security and access policy covering authentication, provisioning and deactivation.
- Access logs showing who reached which record, when, and through which system.
- MFA configuration records for every system in scope, including exceptions and their justification.
- Testing records showing MFA was verified working, not just enabled once and forgotten.
- Staff training records covering authentication procedures and phishing awareness.
Our guide to My Health Record compliance walks through these obligations in more detail, and our checklist for securing patient records under APP 11 maps the broader privacy obligations that sit alongside Rule 42.
Deployment checklist: from inventory to ongoing assurance
A rollout works best as a sequence, not a single event. Each stage builds the evidence base the next one needs.
- Inventory every access path to patient data and privileged functions, including vendor portals, APIs and backup systems, and assign an owner to each.
- Pilot with one representative clinical team before a full rollout, tracking login failures and the time clinicians spend authenticating.
- Provision devices and backup codes during onboarding, with a delegated enrolment process for contractors and locums who join outside normal cycles.
- Build recovery flows for lost devices: a trusted-designee process, short-lived support-issued codes, and supervised in-office re-provisioning, with every recovery action logged.
- Manage account lifecycle with rapid suspension on departure, a clear joiner and leaver process, and periodic access reviews to catch stale permissions.
- Monitor continuously through audit log reviews, configuration audits, periodic penetration testing and a documented incident response playbook.
Pro Tip: Measure the pilot by support ticket volume as much as by security metrics. A spike in “I’m locked out” calls tells you the rollout needs better recovery design before it scales.
Our guide to verifying patient identity online is a useful companion for the provisioning and recovery stages, since identity verification and MFA enrolment often share the same workflow. And our security questionnaire guide for healthcare software is worth reviewing before committing to any vendor whose platform will hold patient data, since configurable MFA support should be a baseline requirement, not an afterthought.
What rolling out MFA across a health service actually teaches you
Every MFA rollout surfaces the same tension: the systems with the most sensitive data are often the ones clinicians interact with most impatiently. The organisations that succeed are the ones that pilot properly, measure support call volume alongside security metrics, and treat configurable authentication frequency as essential rather than a nice-to-have.
Recovery design determines whether staff trust the system or work around it. Get that part right first.
— Taylor
How Meddle supports compliance-first practices
We built our platform knowing that allied health clinics juggling patient matching, scheduling and secure messaging need security that works with clinical workflow, not against it. Our focus on AI-powered matching is built on a privacy-first foundation, because a scheduling tool that compromises patient data protection isn’t worth the time it saves.
If your clinic is reviewing authentication and access controls as part of a broader security upgrade, our pricing and rollout options include a Simple Rollout plan alongside add-ons like SMS Notifications and CRM Integration for practices that want tighter workflow integration. For guidance on handling sensitive clinical data and access permissions more broadly, our partner resource on protecting sick note privacy offers a useful perspective from another corner of digital primary care.
Visit our Help Centre to see how onboarding and support resources can fit alongside your existing access security processes.
FAQ
What are the downsides of two-factor authentication?
The main downsides are added login friction for clinicians, device dependency when staff lose or forget their second factor, and support overhead for recovery requests. Well-designed systems reduce this through risk-based authentication frequency and documented recovery flows, but some friction is unavoidable.
How do I get my two-factor authentication code?
Most healthcare systems use an authenticator app: you pair it with your account by scanning a QR code or entering a manual key, then enter the six-digit code it generates at each login, a process AHPRA’s setup guide walks through step by step. Some organisations also offer SMS codes or physical tokens as alternatives.
What MFA requirements apply to My Health Record access?
My Health Record Rule 42 requires participants to maintain documented access security policies, unique login credentials for remote access, and audit logs showing who accessed records and when. Specific mandatory MFA requirements for any future HIPAA-style changes are a matter for the relevant regulator to confirm, and organisations should check current OAIC guidance directly rather than relying on general summaries.
Which authentication method is best for healthcare organisations?
ACSC guidance recommends phishing-resistant options such as security keys, passkeys or TPM-based certificates over SMS, which remains vulnerable to interception. Authenticator apps are a solid middle ground for most staff, with stronger methods reserved for privileged and administrative accounts.
Sources
- Cyber
- Australian Digital Health Agency developer requirement (SEC‑0271 Multi‑factor authentication)
- Passphrases and multi-factor authentication (Digital Health)
- Australian Information Commissioner v Medibank Private Limited concise statement