Service Account Sprawl After a Hospital Merger
Two hospitals merged into a 6,200-staff regional system. Identity is hybrid: on-premises Active Directory synced to Okta, with 380 service accounts, 61 of which have passwords set to never expire. One account, svc_backup, runs backup jobs on 90 servers and its password is stored in a Git repository used by the engineering team. Twelve shared break-glass administrator accounts are documented in a spreadsheet held by the service desk. A PAM vault covers 40% of servers. The service desk verifies identity for MFA resets using caller ID plus employee number, and average handle time is four minutes. Internal audit found 140 accounts with local administrator rights on workstations. A recent phishing test achieved a 19% click rate among clinical staff. The CISO wants a 90-day plan that improves identity security without delaying patient-care systems.
1. Rank the identity weaknesses by risk and justify the first one you would fix, weighing exploitability, blast radius, and effort.
Read the worked answer
Ranking: first, svc_backup with a password in Git and rights on 90 servers. Second, the twelve shared break-glass accounts in a spreadsheet. Third, 140 workstation local-admin accounts. Fourth, 61 never-expiring service account passwords. Fifth, the caller-ID MFA reset process.
The backup account is first because it combines a low-effort exploit (repository access or a leaked clone, no phishing needed) with an enormous blast radius: backup agents typically run with high privileges, and compromise gives data access across 90 servers plus the ability to destroy recovery capability. It is also cheap to fix relative to segmentation: move the credential into the PAM vault, rotate it, remove the Git history, replace the interactive service logon with a managed service account or gMSA, and scope the account to backup paths only. Break-glass is second because shared credentials held by a service desk are both an insider and outsider path to domain control, and the fix is procedural plus technical rather than a migration. Local admin is high volume but lower per-account blast radius and slower to remediate because of application compatibility testing. Tackle it with LAPS in the same 90 days, but after the first two.
2. Redesign break-glass access so emergency access survives an outage without shared credentials in a spreadsheet.
Read the worked answer
The design goal is emergency access that does not depend on the systems most likely to be unavailable, and does not rely on a credential multiple people know. Use two physically sealed emergency kits held in separate safes with dual control: each kit contains a unique credential and a hardware token, sealed in a tamper-evident bag with a serial number logged by security. The accounts are cloud-backed where possible but have a local AD fallback, are excluded from federation so an Okta outage does not block them, and are not used for routine work. Opening a kit requires two authorized approvers, triggers an immediate alert to the SOC, opens a ticket, and starts a time-boxed session with full logging. Credentials rotate automatically after every use and on a fixed schedule, even if unused. Test the process quarterly with a tabletop plus a live login, because an untested break-glass path is just a rumor. Compensating controls for the spreadsheet gap: remove the document, revoke and rotate every credential in it, and review authentication logs for those accounts over the past year to see if any were used outside declared emergencies.
3. Harden the MFA reset process with controls that add less than 60 seconds to the average call.
Read the worked answer
The current process fails because caller ID is spoofable and employee numbers are semi-public, so an attacker with modest reconnaissance can talk a four-minute call into an MFA reset. Replace verification with something the service desk cannot see or guess and the user already holds. Practical option: require the user to complete Okta Verify number matching on an already-enrolled device, or have the service desk send an approval push to the manager in Okta, before the reset. This adds seconds, not minutes, because it is a click, and it removes knowledge-based questions entirely. For users who lost the device, route to a video call with badge or manager attestation, which is a smaller, higher-risk queue that can afford five minutes. Log every reset with the approver, reason, and source IP, and alert on resets followed by a new device enrollment within 24 hours, which is the classic takeover pattern. Also rate-limit resets per user and per calling number. The residual risk is a compromised manager account approving a fraudulent reset, so require step-up authentication for the approver and review approvals weekly.