Who are you when the network is down? Staff identity during hospital downtime
On 19 February 2026 the University of Mississippi Medical Center took its own network offline to contain a ransomware attack. Computers on wheels, its vice chancellor wrote, "were pushed aside and replaced by binders and reams of paper". For nine days, staff cared for patients using paper charts.
Nine days is not unusual. Ascension, which then ran about 140 US hospitals, detected an attack on 8 May 2024 and did not have its record system back everywhere until 14 June. A study of 374 ransomware attacks on US healthcare organisations between 2016 and 2021 found that at least 8.6% were followed by disruption lasting more than two weeks. Europe has its own cases: the review of the 2021 attack on Ireland's health service found that its continuity plans "did not envisage a severe but plausible total IT loss scenario". The Joint Commission tells the organisations it accredits to be prepared to have life- and safety-critical technology offline for four weeks or longer.
Downtime guidance deals with paper forms, runners and phone trees. The guidance we read rarely answers a simpler question. With the directory unreachable, how do staff prove who they are?
Where the guidance stops
Apart from a line on authenticating transcribed orders once systems return, we found nothing in the Joint Commission alert on how staff sign in to downtime systems or how their actions are attributed.
A federal downtime checklist goes furthest. It asks hospitals to make sure staff know their user IDs, to keep local administrator passwords accessible offline and to post instructions for accessing unknown IDs, passwords and PINs. The same bullet asks them to ensure compliance with password security protocol. It does not explain how the last two fit together.
What hospitals do in practice
Published downtime procedures show the range. These are individual organisations' own documents, not a survey.
At one Canadian health authority, the downtime record viewer opens with a single emergency user name. Staff then type their full name and a reason, and that typed name is what the audit relies on. At an Ontario hospital system, one local account unlocks the downtime computers, with its password held in a vault that leaders and charge nurses can open. The viewer then asks for the user's own login.
Medicines are the sharper case. During the Ascension outage, nurses told Michigan Public they were being told to override the medication dispensers, which, one said, meant orders no longer went to a pharmacist first. "I'm the only check," the nurse said.
None of this is negligence. It is what happens when the question is first asked during the outage.
Why ordinary logins fail offline
Windows keeps a local cache so that people can sign in when no domain controller answers, but by default it remembers ten logons. At that setting, a shared ward PC knows its ten most recent users. Someone who has never signed in on that machine with a domain account cannot.
Stronger credentials do not fix this by themselves. Microsoft's FAQ on FIDO2 security keys for Windows sign-in says the first sign-in needs internet connectivity, and that after it cached sign-in "should work". Offline capability is per person and per device, and it has to be arranged in advance.
Five things to settle before the outage
1. List every downtime login. Record viewer, medicine cabinets, doors, the downtime PCs themselves. For each one, write down which credential works with the network gone and who holds it.
2. Prefer credentials that verify locally. A public-key credential can be checked against a key the verifying device already holds, with no call to a server. The EU Digital Identity Wallet architecture allows for this: where either side has no internet connection, a wallet must be able to present credentials in proximity to a reader that supports the ISO mobile-document standard. The same principle works for a staff credential, with two caveats. The keys must be distributed before the outage, and revocation data goes stale during it.
3. Prepare the machines. Choose the downtime workstations, set their cached-logon limit deliberately, and make sure the people who will need them have signed in there. Then test with the network cable out.
4. Fence in any shared account. If a generic login is unavoidable, seal it, log each use and disable or change it afterwards. Yale's break-glass procedure is a public example: pre-staged emergency accounts kept, for example, in sealed envelopes, with each use reviewed.
5. Protect the way back. Recovery needs administrators who can still sign in. Microsoft recommends two or more emergency access accounts, lists a FIDO2 passkey as the recommended sign-in method and advises storing credentials in fireproof safes in separate locations.
Put it in the drill
A downtime drill that leaves the directory running tests the paper forms. It does not test whether people can get in. Next time, switch the logins off as well.
