Lockout & account recovery
Every design system covers the forgotten password. Almost none of them treat it as what it is here: a clinician standing at a workstation at 03:40, unable to reach a patient's data, with a decision waiting on them and nobody to ask.
Losing a credential is a clinical event with a clock on it. The route back is stated on the failure itself, is staffed at the hour the failure happens, and states how long it will take.
And: the recovery route is never the emergency access control. A recovery path that doubles as a clinical bypass will be used as one — every time recovery is slow, which is every time it matters.
What this covers
Sign in & sign out handles the session: locking to read-only rather than blank, switching user, and the audited break-glass path when authentication itself is the obstacle. It assumes the clinician has a working credential.
This page is the case where they do not. Forgotten, expired, locked out after failed attempts, revoked by a system nobody told them about, or working on a device that has never seen their badge. These are the ordinary failures, they are far more common than the emergency, and they are where a security team's defaults land on a clinical floor without anyone having designed the landing.
Why this is a safety pattern and not an IT one
The instinct outside healthcare is that recovery is an inconvenience to be traded against account security, and that a slow, cautious process is the safe choice. On a ward that trade has a second term nobody prices: every minute of the recovery is a minute the clinician is not doing the thing they were locked out of.
The consequences are predictable and are all worse than the risk being managed:
- They borrow a colleague's session, which destroys attribution for everything that follows — the failure Sign in is built to prevent.
- They use the emergency access route for a non-emergency, which turns break-glass into routine and its audit trail into noise.
- They write it down, or ask someone else to act for them, or wait — and waiting is the option with a patient attached to it.
So the design goal is not "make recovery hard". It is make recovery fast enough that nobody has a reason to route around it, while keeping the identity proofing strong. Those are compatible; they are simply not compatible with a process designed for an office.
Lockout after failed attempts
Lockout thresholds are usually invisible until they fire, which is the worst possible arrangement: a clinician learns the limit by hitting it.
- The remaining attempts are stated before the last one. "2 attempts remaining before this account is locked" — because the person on their third try is often someone with a gloved hand and a keyboard, not an attacker, and telling them costs an attacker nothing they could not establish by trying.
- Caps Lock, keyboard layout and the badge reader are ruled out first. Per Sign in, these are the actual causes of repeated failure on a clinical keyboard.
- Lockout is temporary by default, with the duration stated as a clock time rather than a countdown — "unlocks at 03:52" rather than "try again in 12 minutes", because the second requires the clinician to keep the page open and keep watching it.
- A lockout never blocks the emergency path, and never hides clinical data already on screen. The screen degrades exactly as it does when locked: readable, not writable.
- Lockout is logged as an availability event, not only as a security one. A ward generating forty lockouts a month has a usability problem that the security dashboard is recording as a success.
Too many failed attempts. It unlocks automatically at 03:52.
Sooner, if you need it now:
- Call the clinical systems desk — ext. 4400 Staffed 24 hours. Typical unlock time 5 minutes.
- Any colleague with a working badge can unlock you at this workstation Their identity is recorded as the person who authorised it.
Patient data on this screen stays visible. Alarms are unaffected.
The second route matters more than it looks. In-person vouching by a colleague who is already authenticated is stronger identity proofing than a link sent to an email account, and it takes thirty seconds instead of twenty minutes. It is available because somebody thought about where the clinician actually is.
Expiry, which is entirely predictable and still surprises everyone
A credential that expires does so on a date the system has known for ninety days. Presenting that as a sudden obstacle at the moment of use is a choice, and it is the wrong one.
- Warnings begin far enough out to act on and are shown when the clinician is not mid-task — at sign-in, not at the point of writing. A password change forced between a decision and its record is how a note is lost.
- Expiry never happens mid-session. A session that was valid when it started stays valid until it ends. Anything else takes credentials away from someone in the middle of a resuscitation.
- The change is deferrable a stated number of times, with the count visible. An undeferrable prompt at 03:40 gets answered with the weakest password the policy will accept, which is a worse security outcome than a deferral.
- An expired credential is distinguished from a wrong one. "Your password expired on 12 Aug" and "that password is not correct" send the clinician to completely different places, and merging them into a generic failure wastes the time this pattern exists to protect.
The route back is stated, staffed and timed
Three properties, all of which are usually missing:
| Property | What it means here |
|---|---|
| Stated | On the failure screen itself, not in an intranet article. A clinician who cannot sign in frequently cannot reach the place the instructions live. |
| Staffed | At the hour the failure happens. A route that says "Monday to Friday, 9 to 5" is not a route for a night shift, and publishing it as one is worse than saying there is none. |
| Timed | With a typical duration, so the clinician can decide whether to wait or escalate. "We'll get back to you" forces them to guess, and they will guess in favour of a workaround. |
If no staffed route exists at 03:40, the honest thing is to say so and name what to do instead. An interface that implies help is available when it is not spends the clinician's time discovering the truth.
Recovery is a way in, and is proofed accordingly
Recovery is the softest edge of any authentication system: whatever proof it accepts becomes the real strength of every account. So the proofing is at least as strong as the proofing used to issue the credential in the first place — and where it cannot be, the recovered access is limited rather than full.
- Recovered access can be scoped — read plus the current patient, say — until stronger proofing happens in daylight. A limited route back beats an unlimited one that is too slow to use.
- Every recovery is recorded and attributable, including who authorised it, and is visible to the account holder afterwards. A recovery the owner never learns about is indistinguishable from a compromise.
- Recovery never reveals whether an account exists. The response to an unknown identifier is the same as to a known one. This is one of the few places where the security convention wins outright, because the clinical cost is a few seconds and the alternative is a directory of staff usernames.
- Recovery does not use the emergency control, and cannot be reached from it. Break-glass is time-boxed, notified and audited as an exception; the moment it is the fastest route to a routine problem, it becomes the normal route and the exception report becomes unreadable.
The channel has to exist where the clinician is
Recovery flows tend to assume a personal phone and a personal inbox. On a clinical floor, both assumptions fail routinely: phones are in lockers, wards are in basements with no signal, workstations block webmail by policy, and agency staff may have no organisational address at all.
So at least one route must work on the device in front of them, with no second device. In-person vouching, a badge already enrolled elsewhere, or a phone call to a staffed desk all satisfy this. A one-time code sent to a phone in a locker does not, and designing around it produces a system that works in the office where it was tested.
States
| State | Rendering |
|---|---|
| Failed attempt, attempts remaining | Generic failure message, remaining count stated, Caps Lock and layout surfaced. |
| Locked | Unlock time as a clock time, plus every available route with its typical duration. Screen stays readable; alarms unaffected. |
| Expired | Distinguished from wrong, with the expiry date and a change route. Never presented mid-task. |
| Expiring soon | At sign-in only, deferrable a stated number of times with the count visible. |
| Revoked | Stated as revoked rather than as a failure, with who to contact. A clinician quietly treated as having forgotten their password will spend the night trying to remember it. |
| Recovered with limited access | The limits stated on screen for the whole session, per Safety configuration's rule that a reduced mode is never silent. |
| No staffed route at this hour | Said plainly, with the alternative named. Not a form that will be read in the morning. |
Who holds each rule
Recovery is identity-provider behaviour. The package holds what the screen says while it happens and the record of it happening.
| Rule | Held by | Where |
|---|---|---|
| Every recovery is recorded and attributable | Event log | A recovery is an entry with an actor. An unattributed one is not writable. Asserted: EventLog: every entry names an actor, and says whether it was software |
| Lockout is logged as an availability event, and stays logged | Event log | The entry cannot be removed after the fact. Asserted: EventLog: no entry can be edited, removed or cleared |
| An expired credential is distinguished from a wrong one | Text field | The error is added beside the hint, not in place of it, so the distinction you write is read alongside the format. Writing the distinction is yours. Asserted: TextField: an error never destroys the hint |
| The remaining attempts are stated before the last one | The implementer | A count from your identity provider, and a sentence you render. |
| Caps Lock, keyboard layout and the badge reader are ruled out first | The implementer | Diagnostics you run before deciding a credential was wrong. |
| Lockout is temporary by default; never blocks the emergency path | The implementer | Policy in the identity provider. The most consequential rule on this page, and nothing rendered can hold it. |
| Warnings begin far enough out to act on; expiry never happens mid-session | The implementer | Timers and session logic. |
| The change is deferrable a stated number of times | The implementer | A counter you keep. |
| Recovered access can be scoped | The implementer | Authorisation. |
A pattern page has no component underneath it, so a rule stated here is held by whoever builds against it unless a component already holds it. Of these 9 rules, 3 are held by a component this package ships, and 6 are the implementer’s. Three held, six not, and the one that decides whether a clinician can reach a patient at three in the morning is on the other side.
Do's and don'ts
Locked. Unlocks at 03:52. Clinical systems desk, ext. 4400, staffed 24 h — typically 5 minutes.
Stated, staffed, timed. The clinician can decide whether to wait, and decides with a number rather than a guess.
Your account has been locked. Please contact your administrator.
Which administrator, reachable how, at 03:40, and how long? Every missing answer is a minute, and the workaround costs none of them.
Your password expires in 9 days. Change it now, or defer — 2 deferrals remaining.
Shown at sign-in, with a stated budget. Nobody is choosing a password under pressure with a patient waiting.
Your password has expired. You must change it to continue. (shown on pressing Save)
Interrupts between a decision and its record, and produces the weakest password the policy permits.
A colleague with a working badge can unlock you here. Their name is recorded as authorising it.
Works on the device in front of them, needs no second device, and is stronger proofing than a link to an inbox.
We've sent a code to your registered mobile number.
The phone is in a locker and the ward has no signal. The route exists and does not work here, which is the same as not existing.
Two separate controls: Recover my access and Emergency access — audited.
Different problems, different records. Break-glass stays exceptional, so its audit trail stays worth reading.
Can't sign in? Use emergency access
Makes the bypass the fastest fix for a forgotten password. Within a month it is the normal route and the exception report is noise.
Accessibility
- No time limit a user can fail — SC 2.2.1. Unlock windows and code validity are stated, generous, and extendable without restarting; a code that expires while someone is reading it magnified has excluded them from the system.
- Failure messages are live regions, announced when they appear, and are
associated with the field by
aria-describedbyrather than only sitting near it. - Never block paste in any credential field. It defeats password managers and produces weaker credentials, and it is a hard barrier for anyone using dictation or a switch.
- The route back is text, reachable by keyboard, with the phone number as real selectable text — never an image, never only a QR code, which is unusable to a person holding the only device that could scan it.
- The remaining-attempts count is announced politely, not only rendered in a colour that changes — SC 1.4.1.
- Targets are at least 44 px — SC 2.5.8. This screen is used by someone already frustrated and frequently in gloves.
Outcomes of use
What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.
- Effectiveness — the clinician gets back to the patient's data as themselves. Every alternative outcome — a borrowed session, a misused bypass, a delay — is a failure of this screen, and none of them shows up in an authentication metric.
- Efficiency — measured in minutes to restored access, which is the number this pattern exists to move, and which almost nobody instruments.
- Satisfaction — being treated as a colleague with a problem rather than a suspect. The tone of a lockout screen is the clearest signal a system sends about who it thinks it is protecting itself from.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1). Lockout and expiry parameters are deployment-wide settings and carry the blast radius of Safety configuration. Each bullet says what checks it: a component that holds the rule, a test in your verification file, deployment configuration, post-market surveillance, or a design review where no test can see it. A control checked by nothing is a sentence.
- Lockout never blocks the emergency path or hides data on screen. (a test in your verification file) Mitigates: information withheld during a time-critical event.
- The route back is stated on the failure, staffed at that hour, with a duration. (deployment configuration) Mitigates: borrowed sessions and misused break-glass, both of which destroy attribution.
- At least one route works on the device in front of the user. (a test in your verification file) Mitigates: a recovery process that functions only where it was tested.
- Recovery is separate from emergency access and unreachable from it. (a test in your verification file) Mitigates: break-glass becoming routine and its audit trail becoming unreadable.
- Credentials never expire mid-session, and changes are deferrable. (a test in your verification file) Mitigates: a clinician losing access mid-task, and pressure-chosen passwords.
- Expired, wrong and revoked are distinguished. (held by Text field) Mitigates: time spent solving the wrong problem.
- Recovery proofing is at least as strong as issuance, or access is limited and the limits are stated. (deployment configuration) Mitigates: recovery becoming the real strength of every account.
- Lockouts are reported as availability events. (held by Event log) Mitigates: a usability failure recorded only on a security dashboard, where it reads as success.
Related
- Sign in & sign out — the session, read-only locking, and audited emergency access.
- Safety configuration — lockout and expiry as deployment-wide settings with a blast radius.
- Acting for someone else — the legitimate form of the thing a borrowed session is an illegitimate form of.
- Voice & tone — the register of a screen that meets someone at their worst moment.
- Text field — credential fields, paste, and error association.
- AcuteLine — the reference application, and the 03:40 shift it was written for.