Orphaned Accounts and a 24-Hour Contractual Clock
Cygnus Health Analytics processes claims for three regional health insurers with 1,150 employees and 400 contractors. Single sign-on through an identity provider covers 46 of its 60 applications; the remaining 14, including the claims adjudication console, use local accounts with passwords that never expire. MFA is enforced at the identity provider but bypassed entirely by those 14 applications.
Contractors are onboarded by emailing the service desk, and nothing records an end date. HR sends leaver notifications on a ticket, which IT closes after an average of nine days, with a worst case last quarter of 47.
A quarterly access review has just found 74 active accounts with no matching HR record. Separately, 88 service accounts run batch jobs; 31 have passwords that have never been rotated, and all of them are stored in a shared spreadsheet on a file share readable by the whole IT department. One payer contract requires evidence of access removal within 24 hours of termination and quarterly review sign-off, and the next audit is in ten weeks.
1. How would you prioritise the 74 orphaned accounts for immediate action, and what would you do with them?
Read the worked answer
Do not work the list alphabetically or by count. Rank by privilege level and by what data the account can reach. The claims adjudication console and any account with administrative rights come first; a dormant read-only reporting account is a much smaller problem.
Break the list into three groups before touching anything:
- Actually dormant - no interactive or programmatic activity in a defined window. Disable immediately.
- Human-shaped but in use - could be a contractor never entered into any system, a shared mailbox owner, or a batch job running under a person's account. Disabling these causes outages that will be used to argue the whole exercise is unsafe.
- Unclear - needs the application owner, not the service desk, to say who uses it.
Do not treat last-logon as proof. A quarterly batch job may log on once a quarter; an account can also be in use purely through API tokens or scheduled tasks that do not surface as interactive logons. Correlate with application-side logs and the batch scheduler.
Disable, then delete. Disable first, monitor for thirty days, then delete. Capture the review evidence - the list, the decision, the approver, the date - because the payer contract asks for evidence, not just action.
Also look backwards. Find out what the account that stayed active for 47 days after termination actually did in that window. If any orphaned account was used from an unexpected location, that is a potential incident, not a hygiene finding.
The uncomfortable conclusion to state in the report: the 74 are a symptom. The cause is that 14 applications sit outside the identity provider and that no authoritative record exists for contractors.
2. Redesign the joiner-mover-leaver process so the 24-hour removal obligation can actually be met. What has to change and what do you measure?
Read the worked answer
Authoritative source first. The current process is a chain of tickets, and the 24-hour obligation cannot be met by a chain of tickets. Employee identity should be driven from HR as the system of record, with automated provisioning and deprovisioning (SCIM or equivalent) into the identity provider.
Contractors are the harder half and the one the current design ignores. They have no HR record, so give them a sponsor-based record: every contractor entry requires a named sponsor, a business justification, and a mandatory end date. The account expires on that date unless the sponsor renews it before it lapses. This inverts the current default, where access persists until somebody remembers.
Close the 14-app gap. Those local accounts are the bypass that makes the whole control structure opt-in. Either bring each application behind the identity provider or, where it cannot support SAML/OIDC, put it behind a directory-backed authentication proxy in front of it. Give each of the 14 an owner and a date. Until an application is integrated it should be reported as an exception to the payer, not quietly excluded from the metric.
Sequence the shutdown to the 24-hour clock. Disable at the identity provider on the HR event, automatically, then propagate downstream. The identity provider disable is what enforces the contractual clock; downstream local accounts are a follow-up with their own SLA.
Measure four things: percentage of leavers disabled at the identity provider within 24 hours (target 100%, measured from the HR event, not the ticket); count of accounts with no matching authoritative record; number of applications still outside SSO; and the age of contractor records past their end date. The first metric is the one the auditor will ask for.
3. What is your plan for the 88 service accounts and the shared spreadsheet, given that poorly timed rotation will break batch jobs?
Read the worked answer
Treat this as an inventory-and-ownership problem before a rotation problem. Rotating 88 passwords you do not understand is how a security project causes a failed nightly claims run and loses its mandate.
Step 1 - inventory with evidence. Use directory and endpoint telemetry to find where each account actually authenticates: service principal names, scheduled tasks, services, application configs, EDR process trees. Reconcile against the spreadsheet and expect it to be wrong in both directions - accounts missing from it and entries that no longer exist.
Step 2 - assign an owner to every account. A named human who can say what breaks if the credential changes and when it is safe to change it. Accounts with no owner get disabled after a challenge period, with the same disable-then-delete pattern.
Step 3 - rank by exposure. Accounts with interactive logon rights, domain or local administrative rights, or reach into the claims data come first. Accounts that run confined to a single application's batch window come later.
Step 4 - replace rather than just rotate where possible. Group managed service accounts, workload identities, or certificate-based authentication remove the stored secret entirely. That is a permanent fix; a quarterly rotation of a password in a spreadsheet is a recurring task that will decay.
Step 5 - vault what remains. A privileged access vault with check-out, audit trail and automated rotation inside change windows.
On the spreadsheet itself: it is the finding. Even a perfectly rotated credential in a file share readable by all of IT is compromised by design. Scope the share, then remove the secret store - not the other way round. Report progress as the number of accounts with a named owner and no plaintext secret, not as the number rotated.