Multi-factor authentication is one of the few controls with an unambiguous return. A leaked password alone no longer gets anyone in — which closes a large share of the credential-driven intrusion paths.
It nonetheless stalls in hospitals, not for technical reasons but because of operational friction. Nurses rotate through a ward terminal every few minutes. A phone cannot be handled mid-procedure in theatre. A skeleton night shift works across several terminals. In an emergency, every second before the chart opens counts. These are physical constraints on the work, not attitudes.
So MFA in a hospital starts by abandoning the premise of an all-staff rollout. This article covers where deployment actually reduces risk, and how to reconcile it with the ward.
Disclaimer: This is general information. Guideline interpretation and reimbursement requirements are governed by MHLW publications and regional health bureau notices.
What MFA Closes, and What It Does Not
| Threat | Effect of MFA |
|---|---|
| Use of a phished password | Effective (depending on implementation) |
| Use of a password reused from another service | Effective |
| Brute force and dictionary attacks | Effective |
| Credentials leaked via a supplier | Effective |
| Device flaws exploitable before authentication | Ineffective |
| Abuse of a session on an already-compromised endpoint | Weak |
| Improper action by a legitimate internal user | Ineffective |
| The sharing inherent in a shared ID | Ineffective |
The fifth row is the critical one. Some perimeter device flaws are exploitable without passing authentication at all, so MFA is bypassed entirely. "We deployed MFA, so the VPN is safe" does not follow — it only means something alongside patching. See Managing VPN Device Vulnerabilities.
MFA also does nothing about improper internal access, which occurs after a legitimate login. That belongs to access design and log review: Access Control and Privileged IDs, Logging and Audit Trails. For the overall ordering, see Ransomware Defence for Hospitals.
Where to Start
Remote access and privileged IDs come first, because they combine the greatest consequence of compromise with the smallest population.
| Priority | Target | Population | Consequence | Operational load |
|---|---|---|---|---|
| 1 | Remote access from outside | Small | High (the entrance) | Low |
| 2 | Privileged and administrator accounts | Very small | Highest (reaches everything) | Low |
| 3 | Vendor maintenance accounts | Small | High | Handled by contract |
| 4 | Cloud service administrators | Very small | High | Low |
| 5 | Administrative email and groupware | Medium | Medium | Medium |
| 6 | EMR use on general in-house terminals | Very large | Medium | Highest |
Items 1 to 4 create almost no operational load because so few people are affected, yet they cover much of what appears in disclosed incidents. Item 6 has the largest population, the heaviest load, and comparatively limited additional benefit. Reversing the order exhausts the organisation before it reaches what matters.
Vendor accounts (3) are best treated as a contractual matter: require MFA on maintenance connections, restrict source addresses, and open the path only on request rather than permanently. See Access Control and Privileged IDs, Security Check Sheets for Vendors and ISO/IEC 27001 (ISMS).
Choosing Methods
"Multi-factor" means combining different kinds of factor: knowledge, possession, inherence.
| Method | Strengths | Weaknesses | Fit in a hospital |
|---|---|---|---|
| IC card | Can merge with the staff badge; does not impede sterile work | Forgotten or lost cards; reader cost | Strong for wards and outpatients |
| Fingerprint | Nothing to carry; fast | Gloves and hand sanitiser degrade reading | Difficult where hand hygiene is frequent |
| Face recognition | Contactless | Sensitive to installation environment | Worth considering for shared terminals |
| Smartphone app | No extra hardware | Phones cannot be carried in theatre; personal-device questions | Fits administration and remote access |
| Hardware token | Self-contained, no network needed | Distribution and loss handling | Fits privileged IDs and small groups |
| SMS or email codes | Easy to deploy | Security assessments vary | Supplementary |
Mixing methods by use case is the realistic design: app or token for remote access and privileged IDs; IC card integrated with the staff badge for shared clinical terminals; app for administration. Forcing one method everywhere always breaks somewhere.
Where a smartphone app is used, settle the position on personal devices in policy — see Endpoint Management.
Dealing With Clinical Operational Load
1. Shared terminals with rapid turnover. Producing a phone code many times an hour is not workable. Practical answer: tap-to-authenticate with an IC card; or treat the terminal itself as a managed, trusted environment and strengthen device management in exchange for simplifying login MFA on that terminal — while still requiring step-up authentication for privileged actions and bulk export.
2. Authentication obstructing emergencies. Practical answer: provide a break-glass procedure — access without the normal factor, subject to four conditions: it is automatically recorded and notified; it is always reviewed afterwards (who, and why); it expires automatically; and the people and situations permitted to use it are defined in advance.
The key insight is that not providing an emergency path is the more dangerous choice. Without one, the ward invents a permanently available shared ID of its own. An official path keeps both the record and the control.
3. Night shifts and thin staffing. Practical answer: for each failure mode that can occur overnight — forgotten card, flat battery, system fault — put a single sheet by the terminal naming who to call and what to do, and hold managed spare factors (spare cards, backup codes).
4. Lost or broken devices. Practical answer: decide the reissue procedure and its turnaround in advance. "Unavailable until the next business day" stops work; design the interim alternative and how its use is recorded.
| Item | Decide |
|---|---|
| Enrolment | Who enrols people at joining, and how |
| Reissue | Procedure, turnaround, interim alternative |
| Emergency access | Who may use it; recording and review |
| Spare factors | How backup codes are stored |
| Removal | De-enrolment on leaving or transfer |
| Exceptions | What is excluded, and the compensating measures |
| Support | Contacts including nights and weekends |
Keep the exceptions row explicit. Some places will never take MFA. Rather than leaving them unmanaged, register them, define compensating measures (restricted terminals, restricted actions, focused log review), and review periodically.
Requirements and a Phased Plan
The Electronic Clinical Information Coordination Structure Development Addition sets guideline compliance and a dedicated medical information system safety management officer as common requirements; tier 1 (160 points) adds multi-method backup with part held offline and a cyber-attack BCP with exercises. Tier 2 is 80 points. With security tied to reimbursement, MFA can be presented as part of building the required structure rather than as a cost. See the FY2026 revision overview, Appointing a Safety Management Officer, and The Three Ministries' Two Guidelines Explained.
| Phase | Target | Duration | Prerequisite |
|---|---|---|---|
| 1 | Remote access, privileged IDs, cloud admins | 1–2 months | Enumerate the accounts |
| 2 | Vendor maintenance accounts | At contract renewal | Contract and SLA clauses |
| 3 | Administrative email and groupware | 2–3 months | Staff communication and a support desk |
| 4 | Shared terminals (IC cards) | Requires budget | Reader installation, break-glass design |
| Ongoing | Review exceptions and compensating measures | Annually | Maintain the exception register |
Phase 1 alone is worth doing. It completes quickly, costs little, and covers a substantial share of the intrusion paths seen in disclosed incidents. The decision is not all-or-nothing but starting where the effect is largest.
Conclusion
- MFA is strong against credential-driven intrusion but useless against flaws exploitable before authentication — it presumes patching alongside
- It does not address improper internal access or the sharing inherent in shared IDs; those belong to access design and log review
- Remote access and privileged IDs first — small populations, low friction, large risk reduction
- All-staff deployment on in-house terminals carries the heaviest load for relatively limited gain; the wrong order exhausts the effort before it reaches what matters
- Mix methods by use case: IC cards for shared clinical terminals, app or token for remote
- Provide an official break-glass path. Without one, the ward creates an unofficial shared ID
- Register what cannot be covered as exceptions, with compensating measures and periodic review
If you are weighing where to start and how to reconcile it with clinical constraints, contact us.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Edition 6.0 | MHLW
- On the FY2026 Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: assessments of authentication method security, guideline interpretation and reimbursement requirements are governed by ministry publications and vendor information, and change over time.