Push Fatigue, a Persuadable Service Desk and a Clinical Veto
Meridian Health Partners runs 4 hospitals and 90 clinics with 6,800 staff and 1,200 affiliated physicians. All workforce accounts are behind single sign-on; multifactor is enforced for 100 percent of accounts, but 38 percent still use SMS or voice callbacks and 62 percent use push notification. Last week an attacker called the service desk six times over two days, each time posing as a different clinician, and had the password reset and the MFA method re-registered to a new phone number. Two of the accounts had access to the electronic health record. The service desk followed its published script, which asks the caller for employee ID and date of birth. Separately, an audit found 240 clinical workstations sharing one local administrator password and 14 accounts holding standing domain administrator rights. The emergency department refuses any change that adds more than a few seconds to login, citing a 4-minute door-to-doctor target, and the CMO has veto power over clinical workflow changes.
1. Where exactly did the control fail, and what would you change at the service desk within two weeks?
Read the worked answer
The failure is identity proofing at the reset, not multifactor. MFA was re-registered to an attacker-controlled number because the reset process trusted attributes the caller supplies - employee ID and date of birth are both discoverable and are not secrets. Once the reset succeeded, the attacker satisfied every subsequent MFA prompt legitimately.
Two-week changes:
- Verify against a contact channel already on record, not one the caller provides. Call back the mobile number in the HR system, or require a manager or on-call confirmation for privileged and clinical accounts.
- Treat MFA re-registration as a higher-risk action than a password reset: cooling-off period of hours before a new factor becomes usable, notification to the old factor and to the manager, and a block on the account if both change in one session.
- Detect volume patterns. Six resets across six identities in two days is an anomaly a queue-level alert would catch; alert on reset rate per agent and per hour, and on repeated resets of accounts with recent risky sign-ins.
- Add a self-service reset path behind existing MFA to remove routine resets from human judgement.
Track time-to-reset and abandoned-call rate so the added friction does not push staff into informal workarounds.
2. Sequence the MFA and privileged-access improvements. How do you satisfy the emergency department without leaving the highest-value accounts last?
Read the worked answer
Rank by the value of the account to an attacker, not by coverage percentage. Sequence:
- Free and immediate: enable number matching and disable push-only approval everywhere. This alone removes push fatigue at no licensing cost.
- Tier 0 first: the 14 standing domain administrator accounts and any identity-provider or EHR superuser accounts move to phishing-resistant FIDO2 keys, with standing rights removed in favour of just-in-time elevation. Attackers target these accounts precisely because they are few and powerful.
- High-risk and remote access: all VPN, vendor and remote clinical access to FIDO2 or platform biometrics; eliminate SMS for these populations first.
- General workforce: retire SMS and voice over a planned migration.
For the emergency department, do not fight the veto - redesign the friction. Issue tap-and-go badge credentials with a PIN, which are phishing-resistant and faster than a push prompt, and set a short re-authentication window (for example 15 minutes) on shared clinical workstations so staff are not challenged per patient. Compensate on shared devices with 60-second auto-lock, restricted application sets and no email. Present it as a workflow improvement that also happens to be stronger authentication, and pilot it in one ED pod with measured login times.
3. Design the break-glass capability for this environment and explain how it survives a compromised identity provider.
Read the worked answer
Break-glass exists for availability - when the identity provider or the normal authentication path fails, clinicians still need the EHR. Design constraints:
- Two accounts per tier (identity provider global admin, EHR superuser), cloud-only, excluded from the conditional access policies that could lock them out, with long random passwords split between a safe and a sealed envelope held by different people (dual custody).
- Credentials and FIDO2 keys stored physically apart from the systems they unlock, and never in the same vault as routine privileged accounts.
- Any use triggers a real-time page to the SOC and the CISO, a justification ticket within 15 minutes, and an automatic review within 24 hours.
- Credentials rotate after every use, and after every staff change in the custodian group. Test quarterly, without warning, and record the result.
- Logging of break-glass sessions is fully retained and cannot be disabled by the account itself; an unmonitored break-glass account is just a backdoor.
Surviving a compromised identity provider means the break-glass path must not depend on the same provider for its own authentication: keep one identity-provider admin account outside the federation, with its own hardware key and separate recovery process, and rehearse the scenario where the tenant itself is suspect.