The Service Account That Everyone Knew
Meridian Health Partners has 4,200 employees and 1,150 service accounts. An access review found 280 service accounts with no documented owner, 60 shared local administrator accounts used by desktop support, SSO coverage at 68%, and MFA enforced for only 41% of users. A phishing campaign last month harvested 12 credentials; one was reused on an internal wiki. The CISO has two identity engineers, 90 days before the external audit, and a mandate to reduce privileged access risk. The CIO wants SSO and MFA expanded first because it is visible; the identity team wants to focus on service accounts and shared admin because those are the paths attackers actually used. The audit finding specifically cites orphaned service accounts and shared credentials.
1. How should the CISO prioritize the 90 days? Justify the order using risk, not visibility.
Read the worked answer
Prioritize the identity paths that enable lateral movement and privilege escalation, then use the remaining capacity for SSO and MFA where they close the credential-phishing path. The evidence points to shared local admin and unowned service accounts: 60 shared administrator accounts give an attacker who obtains one credential broad reach across desktops, and 280 orphaned service accounts are unmonitored, often over-privileged, and invisible to joiner-mover-leaver processes. The phishing incident showed credential reuse, so MFA matters, but MFA on a wiki would not have stopped the attacker from using a shared local admin account.
A defensible 90-day order is: (1) contain shared local administrator use by deploying managed local administrator password rotation and removing the 60 shared accounts from daily use; (2) triage the 280 unowned service accounts, disable clearly inactive ones, and assign owners to the rest; (3) enforce MFA for all privileged and remote access, then expand SSO to the highest-risk applications; (4) begin broader MFA rollout. Two engineers can realistically complete the first two if they use automation and do not attempt a full IAM replatform.
The CIO's visibility argument is legitimate for board reporting, but it should not set the sequence. The CISO should agree on a dashboard that shows both workstreams, with shared admin and service-account reduction as the leading risk metrics.
2. Design the minimum viable control set for service accounts that the team can implement in 90 days.
Read the worked answer
The minimum viable set has seven controls. First, a complete inventory with a named business or application owner for every account; accounts without an owner are disabled, not left in a holding pen. Second, a documented purpose and the systems it touches, so that access can be reviewed. Third, credential vaulting and rotation for accounts that cannot use managed service identities; passwords should not sit in scripts or configuration files. Fourth, least privilege: remove interactive logon rights, domain admin membership, and local admin rights unless explicitly justified. Fifth, prefer group managed service accounts or workload identities where the platform supports them. Sixth, logging and alerting on service-account logons from unexpected hosts or at unusual times. Seventh, a lifecycle process tied to application onboarding and retirement, so new service accounts cannot be created without an owner.
The team should not try to eliminate every service account in 90 days. The realistic outcome is that the 280 unowned accounts are either owned, disabled, or placed on a dated exception list, and that new accounts are created through a controlled request. That is enough to close the audit finding and materially reduce the attack path.
3. How should break-glass and emergency access be designed so that the new controls do not block incident response?
Read the worked answer
Break-glass access should be deliberately small, monitored, and tested. Design two emergency accounts per tier, not one shared account: one for identity infrastructure and one for the cloud tenant. Credentials should be stored in a physical safe or a vault that requires two approvers, with hardware tokens rather than SMS. The accounts should not be used for routine administration and should not be exempt from logging; in fact, any use should page the on-call security lead and create a ticket automatically.
During an incident, the responder should be able to retrieve the credential without waiting for a business-hours approver. That means a documented emergency procedure, a pre-authorized on-call approver, and a maximum time-to-access target. After use, the credential must be rotated within a defined window and the use reviewed. Test the procedure quarterly, including the scenario where the primary identity provider is unavailable.
The trade-off is real: break-glass accounts are a standing privilege risk. The control is not to remove them but to make their use rare, visible, and recoverable. If the team cannot monitor them, it should not deploy them.