4,200 Accounts for 3,100 People: Cleaning Up After a Merger
Two regional insurers merged eighteen months ago and consolidated onto a single identity provider. The directory shows 4,200 active accounts for a workforce of 3,100. An access review finds 700 accounts belonging to leavers, 1,100 contractor accounts provisioned by email request with no end date recorded, and 260 shared functional accounts such as warehouse.admin and claims.batch whose passwords live in a spreadsheet maintained by three team leads. MFA is enforced for 82% of users; 190 accounts hold a permanent exemption because they still use a legacy claims client that cannot do modern authentication. The helpdesk resets roughly 900 passwords a month and reports that most callers cannot answer the knowledge-based questions. One audit finding: a terminated contractor kept VPN access for 47 days because the HR feed and the directory disagree on the worker-type field. Business units are refusing a bulk disable until they "check with the teams."
1. Sequence the remediation across two quarters. What goes first, what waits, and how do you justify the order to an auditor?
Read the worked answer
Order by risk times fixability, not by tidiness.
Weeks 1–2 - stop the bleeding: reconcile the worker-type field between HR and the directory; that single field caused the 47-day contractor. Add a daily exception report for terminated identities still active downstream. Then triage the 700 leaver accounts - expect 10–20% to be misclassified service or shared accounts, so verify owner and last logon before disabling. Disable dormant leavers immediately; anything with recent activity goes to the owner for a 48-hour decision, then disable anyway.
Weeks 3–8 - MFA exemptions: the 190 legacy-client accounts are the largest single phishing exposure. Put a hard expiry on each exemption and a named owner.
Quarter 2 - contractor lifecycle: end dates mandatory at request, sponsor named, 90-day re-attestation, automatic suspension at expiry.
Quarter 2–3 - shared accounts: longest lead time, most political.
Justify it as exposure-reduction per engineering hour: leaver accounts and MFA exemptions are cheap, measurable, and directly address the audit finding; shared-account elimination needs application work and will not land inside one quarter.
2. What is your decision on the 260 shared functional accounts, given that warehouse scanners cannot display a login prompt and claims.batch has no human operator?
Read the worked answer
Split the 260 into three populations and treat them differently - a single answer for all of them is how organizations end up vaulting a shared password and calling it governance.
Human-shared (likely the majority): eliminate. Map each to individual accounts plus a role. Where the application genuinely cannot do individual logins, vault the account and require check-out with session recording and per-session rotation, so no human ever knows the standing password. Vaulting without check-out and recording just relocates the spreadsheet into a nicer database.
Device accounts (warehouse scanners): a scanner is a device, not a person. Bind the credential to the device - certificate or enrolled device identity - and rotate on a schedule the device fleet can consume. If the scanner can only take a stored secret, store it in the vault with automated retrieval at provisioning and restrict use to the warehouse network range.
Non-human (claims.batch): this should never have been a shared account. It is a workload identity - give it its own credential, least privilege, and rotation the job can tolerate.
Measure success as the count of credentials known to more than one human, driving it to zero.
3. The business says the legacy claims client cannot be migrated off the 190 MFA-exempt accounts before next year. What do you actually do?
Read the worked answer
Accept a time-boxed risk, not a permanent exemption. The distinction is whether the exception has an owner, a control, and an expiry.
Reduce the population first. Of 190, some are duplicate or dormant accounts that can be disabled outright, and some users can move to the modern client today. Assume 20–30% disappear with no application work.
Compensate for the rest: restrict those accounts to the corporate network or VPN with device posture checks, require EDR health before authentication, and alert on impossible-travel or unusual-hour sign-ins. A network-bound control is weaker than MFA but far stronger than a password alone over the internet.
Put the client behind a reverse proxy or federated gateway that terminates modern authentication and speaks legacy to the app. This is often the cheapest real fix and can be done without touching the client.
Governance: every exemption re-approved monthly by a named application owner, reported to the risk committee, with a hard date tied to the client migration milestone. Track the exemption count as a KPI that must fall each month - a flat count means the control has quietly become permanent.