Plenty of hospitals are still sending out the notice that says "please change your password every 90 days." And IT staff have a fair idea of what that produces. Sakura2026! becomes Sakura2027!. Someone writes the change date on a slip taped to a monitor. The help desk fields a run of calls asking what the shared terminal's new password is.
A password policy does not get safer by getting stricter. Rules that cannot be followed get worked around, and the workarounds are more dangerous than the rule was strict. Sticky notes, passwords passed along verbally, predictable patterns repeated — each is a sign that the policy and the floor have not been reconciled.
Hospitals also have constraints they cannot trade away. Outpatient terminals are used by several physicians; at a ward station, staff come and go continuously. Care cannot be slowed down. Everyone knows one-person-one-device with a login each time is the ideal, and everyone knows there are places it cannot simply be applied.
This article is about where to draw the line between those two constraints — authentication that cannot be weakened, and operations that must remain workable — by treating the question as authentication design rather than as passwords alone.
Disclaimer: This article is general information. The authoritative sources on authentication for medical information systems are the MHLW guidelines and related ministry publications. Base specific settings on those and on your systems' actual specifications.
The Premises Have Changed
The old standard was "at least eight characters, mixing upper case, lower case, digits, and symbols, changed every 90 days." International guidance has moved decisively away from it.
The US NIST digital identity guidelines (SP 800-63B) set out that users should not be required to change passwords on an arbitrary schedule, and should be required to change them when there is evidence of compromise. Rather than mechanically demanding a mix of character classes, the emphasis falls on length and on rejecting known-breached or easily guessed strings.
The reasoning is straightforward.
- Forced rotation pushes users toward predictable transformations — incrementing a trailing digit
- Mechanical complexity requirements produce passwords that are hard to remember and therefore get written down
- Real-world compromise owes far more to credentials reused from a breached external service, or elicited directly from a user, than to brute-force guessing
In short, effort spent on rotation frequency yields less than effort spent on length, on eliminating reuse, and on multi-factor authentication.
One caution, though. "Stop forcing rotation" is not a decision that stands on its own. It presumes you can detect breached credentials, that multi-factor authentication is in place, and that you can force an immediate change on suspicion of compromise. Remove the expiry without those, and the same password stays in use for years.
For hospitals there is also the reimbursement dimension. The electronic clinical information coordination structure addition introduced in the 2026 revision requires, as a common condition, compliance with the guidelines and appointment of a dedicated medical information system safety management officer. Authentication design is part of how you evidence that compliance. See The 2026 Fee Revision and What the Three-Ministry Guidelines Are.
Setting Length, Complexity, and Rotation
Start by refusing to treat every account the same. A single rule for everything drags the strictest requirement down to the weakest operational reality.
| Category | Examples | Direction |
|---|---|---|
| Individual staff accounts | EMR, departmental systems | Prioritise length (12+ characters as a guide). Relax mechanical complexity; reject breached strings. Consider relaxing rotation once MFA and detection exist |
| Privileged accounts | System and database administrators | Demand length; require MFA. Request and record each use. Move to checkout-based issuance where possible (Privileged ID Management) |
| Vendor maintenance accounts | Remote support connections | Issue per individual; require MFA; state obligations in the contract (Securing Remote Maintenance) |
| Shared-terminal accounts | Outpatient and ward use | Covered below; do not try to solve this with passwords |
| Machine-to-machine credentials | System integrations, medical devices | No human memory involved. Use long random values and document the rotation procedure |
Length is the highest-return element: easier to remember than complexity, and it contributes more to strength. Allowing long passphrases made of several ordinary words makes the policy easier for staff to accept.
Complexity enforced by character class has limited effect. Where a system simply cannot accept a long password — common in older departmental systems — complexity is what remains. Survey the minimum and maximum each system supports before writing the rule.
Rotation — if you drop a blanket schedule, put these in place instead:
- A means of detecting breached credentials (below)
- A procedure to force an immediate change on suspicion of compromise
- Multi-factor authentication (Introducing Multi-Factor Authentication)
- Account handling on departure and transfer
Until those exist, extending the interval (90 days to 180 days or a year) is a legitimate intermediate landing point. Staged change beats an ideal that never ships.
Lockout belongs in the design too. In a hospital, a lockout can obstruct care, so decide the threshold together with who unlocks, how, and how fast. "Locked out at 2am with nobody able to unlock it" does happen.
Detecting Reuse and Breached Credentials
What matters in real compromises is reuse more than complexity. If staff use the same password on hospital systems and personal services, a breach elsewhere reaches inside.
| Measure | What it does | Ease of adoption |
|---|---|---|
| Reject breached passwords | Refuse strings present on known breach lists at the point of setting | Configuration only, where the system supports it; confirm with the vendor |
| Reject dictionary and obvious strings | Block the hospital's name, department names, password, and so on | Supply your own deny list |
| Prohibit reuse of previous passwords | Prevent reverting to an earlier value | Standard in most systems |
| Staff communication | Include "do not reuse hospital passwords on outside services" in training | Free, but needs repetition (Designing Staff Security Training) |
| Multi-factor authentication | Reuse alone no longer gets an attacker in | The most reliable; shared-terminal design is the open question |
Do not build this around asking staff to declare their external service usage. It does not work and it does not get honest answers. Reject what you can technically reject, and absorb the rest with training and MFA.
It also helps to take a position on password managers. Banning sticky notes without offering an alternative leaves staff nowhere to go. Naming an approved tool — or at minimum stating where a password may be recorded — improves reality more than a prohibition does.
The Reality of Shared Terminals
This is the hardest part of a hospital password policy.
Consulting rooms, ward stations, treatment and examination rooms. Staff rotate through these terminals in short bursts, and there are moments when retyping a password at a login screen is itself a safety problem. The predictable result is a shared account left permanently logged in.
The problems with that are clear.
- No record of who did what. Improper access cannot be attributed (Reviewing EMR Access Logs)
- The password is shared among staff, so leavers still know it
- Because changing it means telling everyone, it effectively never changes
Yet "give everyone their own device" is rarely achievable immediately, on cost or on workflow. The way forward is to stop trying to solve it with password strength and change the authentication method instead.
| Alternative | What it does | Watch for |
|---|---|---|
| IC card / staff badge | Tap to identify the individual; the terminal stays shared, the record does not | Card sharing must be addressed operationally |
| Biometrics | Fingerprint, vein, and so on; suitability varies by department (gloves, for example) | Device constraints; a fallback method is required |
| Screen lock with quick re-authentication | Lock after a short idle period, resume with a light second factor | Tune the interval per department to match clinical flow |
| Accounts split by role or unit | Where individual identification is not yet feasible, narrowing the set improves accountability | Interim only; pair it with a plan to reach individual identification |
| Single sign-on | One authentication across systems, reducing keystrokes and making stronger authentication tolerable | Confirm which systems are covered |
Secure individual identification first, then reduce the typing burden. Improving convenience while giving up on identification renders your logs meaningless.
In practice, work outward from the highest-risk locations: terminals that can reach all patient records, terminals with privileged functions, and terminals in busy places with little supervision. Introduce individual identification there and migrate the rest in stages. See also Managing Endpoints: Laptops and Tablets and Network Segmentation and Asset Management.
Writing the Policy Down
Documentation is not only for audits. It is what keeps the operation consistent when the person in charge changes, and what lets you explain later why an exception was granted.
| Section | Content |
|---|---|
| Scope | Systems and account categories covered |
| Requirements | Length, complexity, rotation, and reuse history, per category |
| Issuance and revocation | Procedures and owners for joining, transfer, and departure; vendor accounts |
| Initial passwords | How issued; forced change at first login |
| Lockout | Failure threshold, who unlocks and how, out-of-hours handling |
| Prohibitions | Sharing, conditions on recording, reuse on external services |
| Shared terminals | Permitted operating patterns and how individual identification is preserved |
| Exceptions | Systems that cannot meet the requirements, compensating measures, review date |
| Review | Who checks what, how often |
Always include the exceptions section. Some older departmental systems and medical devices cannot accept long passwords. Listing that fact, with compensating measures (segmentation, restricted access origin, heightened log review), is healthier management than concealing it — and it leaves a list of things to fix at replacement. On specifying requirements at procurement, see Putting Security Into Procurement Requirements.
Finally, a policy that is merely distributed is not communicated. Give each staff group a short explanation of what is being asked and why. "We stopped forcing changes" will be heard as "security got looser" unless the reasoning is given.
Conclusion
- International guidance has moved from blanket forced rotation toward length, rejection of breached strings, and multi-factor authentication
- But dropping rotation does not stand alone — detection, forced-change capability, and MFA come first. Until then, extending the interval is a reasonable middle
- Treat account categories separately: staff, privileged, vendor, machine-to-machine, shared terminal
- What reduces real harm is eliminating reuse, not complexity. Reject technically what you can; absorb the rest with training and MFA
- Do not solve shared terminals with passwords. Identify individuals with cards or biometrics, then reduce the typing burden
- Always document the exceptions and their compensating measures. Never leave an unfollowable rule standing
Revising a password policy touches authentication methods, device layout, and departmental workflow, so a policy decided in isolation tends to stall on the floor. If drawing the line for your own institution is difficult, get in touch — we can help work out where to start, based on how your EMR is actually used.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Version 6.0 (PDF) | MHLW
- NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management
- Information-technology Promotion Agency (IPA)
- On the FY2026 Medical Fee Revision | MHLW
Note: recommendations on authentication change with revisions. Confirm specific requirements against the current edition of each guideline and the specifications of the systems you run.