An orphaned account is not a mystery login from a novel. It is a user object that still authenticates, or still holds a seat, after the worker it belonged to is gone from the HRIS. Mid-market SaaS companies accumulate these in the IdP, in SaaS tenants that never saw SCIM, and in local admin tables. Rutagon builds orphaned account cleanup as a reconcile job: HRIS versus IdP versus SaaS, then a revoke list with owners, not a spreadsheet of “looks unused.”
The failure mode we keep seeing is a quarterly access review that certifies accounts the reviewer cannot map to a living employee. Reviewers approve the familiar email domain and skip the rest. Auditors later sample a contractor who left two cycles ago and still has a production role. Cleanup after that finding is a fire drill. Cleanup as a standing reconcile is a system.
We do not treat “no sign-in for ninety days” as the definition of orphaned. Inactive living staff are a different queue. Orphaned means no living worker in the HRIS (and no approved non-human owner) can be bound to the account. That bind is the engineering problem.
Orphaned Account Cleanup Across HRIS, IdP, and SaaS
Orphaned account cleanup starts with three extracts that do not share a primary key. The HRIS speaks employee ID and employment status. The IdP speaks username, email, and external IDs. SaaS tenants speak whatever they stored on the day the account was created, often a personal email that later changed. We build a matcher that is conservative: high-confidence links auto-classify, low-confidence links become review items, and unmatched privileged accounts become a same-week page, not a backlog novel.
HRIS is the living-worker source, not the IdP. Contractors and vendors who never entered HR still need an owner record. We require a named internal sponsor and an expiry for those identities. An account with no sponsor and no HR row is an orphan candidate even if it signed in yesterday.
SaaS extracts include local users, SCIM-provisioned users, and API tokens that impersonate a user. A disabled IdP user with a live SaaS session is still in scope. Joiner-mover-leaver automation prevents new orphans on terminate. This job hunts the ones already living in the walls.
How We Bind Accounts When Emails Disagree
Email is a hint. It is not a join key. People change names, contractors use vendor domains, and shared mailboxes impersonate teams. We match on HR employee ID stored in the IdP, on SCIM external ID, on verified secondary emails, and on a short manual link table that GRC owns. Fuzzy name match never auto-revokes.
When a match fails, we emit a packet: SaaS user ID, groups, last activity if present, and the HR search we already ran. A human confirms “this is the departed contractor” or “this is a service identity; assign an owner.” That confirmation is evidence. A silent delete is not.
Non-human identities get a different path. A CI bot that is not a person should not be deleted because it is missing from Workday. It should be moved onto workload identity and stripped of a standing user, which is a credential cutover when the orphan is an AWS key glued to a fake person. Cleanup and credential elimination meet there.
The Revoke List and the Hold List
Every reconcile run produces two lists. The revoke list is high-confidence orphans: HR terminated, IdP still enabled or SaaS still active. The hold list is unmatched privileged accounts and accounts that look like shared break-glass. Hold items have a named owner and a due date inside the same week. If the due date passes, the item escalates; it does not age into “accepted risk” without a recorded decision.
Revoke is ordered. IdP disable first when SSO is the front door, then SaaS local delete or deactivate, then token revoke, then seat reclaim if a license is attached. We wait for the vendor to acknowledge the mutate before we mark the row closed. Partial failure stays open.
reconcile_id: orph-run-184
source: hris + idp + saas
revoke:
- saas: billing-console
user: c7f1
reason: no living worker
confidence: high
hold:
- saas: prod-admin
user: breakglass
reason: unmatched privileged
owner: security-oncall
That artifact is what we attach. Security automation owns the extractors and the mutate jobs. Your GRC platform stores the run.
What Auditors Sample After Cleanup
Auditors do not need a story about how hard identity is. They need a population, a join, and a result. We keep the input extracts, the match table, the revoke list, and the hold decisions with timestamps. If they pick an account from the SaaS export, we can show the HR miss, the decision, and the mutate.
We also keep a negative sample: accounts that matched a living worker and were left alone. That proves the job is not a blind disable. Custom application reviews still recertify living access; cleanup does not pretend to replace that.
On the AWS side, unused IAM users and keys are a related population. AWS documents how to find unused credentials. We use that as one extract, then we still require the HR bind. A key with no last-used date is not automatically a person who left. It might be a forgotten pipeline. Classification comes first.
Guest tenants, shared mailboxes, and the second IdP
Orphans are not only leftover employees. Guest users in a collaboration tenant, shared mailboxes that outlived the team, and a second IdP from an acquisition all produce accounts with no living worker in the current HRIS. We include those populations in the same reconcile. A guest with no sponsor and no ticket is an orphan candidate even if the email domain looks corporate.
Shared mailboxes need an owner row, not a deceased display name. We transfer ownership to a living team, then we disable the personal login that still pointed at the mailbox. Leaving the personal login is how a departed contractor reads invoice mail. The reclaim of the mailbox seat, if one exists, is a sibling of SaaS license work only in the report; the access revoke is mandatory either way.
Acquisition IdPs are the ugly extract. Usernames do not match. Employee IDs were never written. We do not auto-revoke the acquired admin set on week one. We isolate it, require a sponsor map, and put privileged unmatched accounts on the hold list with a same-week clock. The cleanup job is allowed to be slower than a single-IdP run. It is not allowed to skip the privileged rows.
Service identities that were created as people—deploy-bot@ as a human user—get classified, not deleted on the first miss. Classification is the bind step. Deletion without classification is how production jobs die and the orphan program gets shut down. We would rather hold a bot for a week than pretend HR was the system of record for a pipeline user.
When the second IdP is finally retired, we run the reconcile again against the surviving directory. Retirement without a reconcile is how local SaaS users become invisible. The extract order stays the same: HRIS living workers, surviving IdP, SaaS, then revoke and hold.
Frequently Asked Questions
Is an inactive employee the same as an orphaned account?
No. An inactive living employee still has an HR row and a manager, so that is a recertification or a disable-for-leave workflow. An orphaned account has no living worker to own it. Mixing the two produces angry reopen tickets and missed contractor leftovers.
What if HR never created a record for a contractor?
Then the contractor was never in the living-worker set, and the account should have been created with a sponsor and an expiry. Cleanup treats a sponsor-less contractor identity as an orphan candidate. The fix going forward is a joiner path that refuses to mint SaaS access without that sponsor row.
Do we delete the IdP user or only the SaaS user?
We disable or delete according to your retention rules, but we never leave SaaS active after IdP disable if SSO is supposed to be the only door. Local SaaS passwords are the usual hole. The reconcile includes those local users even when the IdP looks clean.
How often should orphaned account cleanup run?
We run it on a fixed cadence and also after bulk HR imports, IdP migrations, and vendor SSO cutovers. Those events create orphans in batches. A quarterly-only job misses the month an acquisition dumped three tenants into production.
See what an Access & Credential Governance Diagnostic finds in your environment. Call 907-841-8407, email contact@rutagon.com, or use rutagon.com/contact.