Finding orphan accounts in a remote-first business environment

A contractor needs access “for two weeks.” A consultant needs a Snowflake export “yesterday.” Someone spins up a CI job and creates ci-deploy-prod because the pipeline was blocked and we were all tired. Fast-forward three months and we’re staring at an access review thinking: who owns this account, what can it do, and why is it still here?

Remote-first didn’t invent orphaned accounts. It just made them easier to create, harder to track, and probably more socially acceptable to ignore (“we’ll tidy it up after the release”). Meanwhile, attackers keep doing the obvious thing: they go after identities.

Microsoft reports 97% of identity attacks were password spray attacks. Cheap through dark web services, scalable, and invariably successful against stale or weakly governed accounts. Verizon’s 2025 DBIR also flags credential abuse as an initial access vector in 22% of breaches, which is why “forgotten access” is such a gift. 

Remote-first tool sprawl is verging on the biblical. Okta’s Businesses at Work 2025 said that the average company uses 101 apps, which is 101 places to forget to offboard someone and a clear call for robust identity-governance. 

Why Orphaned Accounts Are So Common Now

Remote-first didn’t create the problem, but it removed the friction that used to hide it. Now everything is faster, more distributed, and more automated… so orphaned accounts scale slyly in the background unless we go out and actively hunt them.

It’s a systems story:

• Contractors and consultants often live outside HR-driven joiner/mover/leaver flows. They get direct accounts in SaaS, guest access, and one-off cloud roles that don’t map cleanly to a person.
• Service accounts nobody owns multiply through CI/CD, integrations, bots, and “temporary” scripts that become permanent infrastructure. Service accounts, API keys, and now AI agent security. They just don’t “leave” in a visible way.
• Leavers not in HR systems. Agency staff, interns, vendors, “someone’s mate from a previous gig,” don’t reliably trigger deprovisioning.

Remote team SaaS collaboration makes it worse. SaaS Alerts’ 2025 SASI report found guest user accounts increased by over 1.4 million from 2023 to 2024, and guest accounts are exactly the kind that get created fast (and forgotten faster). 

Third-party exposure adds fuel. SecurityScorecard’s 2025 report estimates 35.5% of breaches in 2024 were third-party related. If you have orphaned partner access, you’re not just carrying risk, you’re renting it out.

In-office environments had, to a greater degree, informal checks: someone noticing a name, a login, a device. Remote setups remove those passive signals.

What “Orphaned” Really Means In Cloud And SaaS

An orphaned identity is not only “a user who left.” In modern estates it often means:

• No accountable owner (no team, sponsor, or escalation path)
• No verified workload linkage (you can’t prove what depends on it)
• No recent activity, but elevated, active permissions (the dangerous combo)
• Remote work bypasses formal access channels: In distributed teams, managers and engineers frequently grant direct app or cloud access to keep work moving across time zones. Those ad hoc grants often sit outside central identity governance, making offboarding inconsistent and leaving behind valid-but-forgotten credentials.

And “active permissions” is the key phrase. Attached policies are trivial; what matters is what the identity can actually do right now, across inheritance, trust relationships, group membership, and role chaining.

Three Identity Governance Pillars That Actually Work

1) Non-Human Identity Ownership Mapping (stop guessing)

Ownership mapping breaks the moment it depends on a single field like “created by.” In a remote-first environment, that usually points to someone who has moved teams, changed roles, or left the company entirely.

A more practical approach is to infer ownership from access and behaviour, not just metadata.

Instead of trying to perfectly reconstruct how an identity was created, focus on what matters now:

• Where the identity has access (cloud accounts, SaaS apps, roles, permissions)
• What it can actually do (effective permissions, not just attached policies)
• How it’s being used (recent activity, patterns of access, or lack of them)
• Who is closest to that access (teams, approvers, or users interacting with the same resources)

From there, you can establish accountability, even if you can’t prove original ownership.

This is where a unified identity and entitlement view becomes essential. When you can see every identity, human and non-human, across AWS, Azure, GCP, and SaaS in one place, ownership stops being a guessing game and starts becoming a resolvable question.

Instead of:

“Who created this service account?”

You can ask:

“Who relies on this access, who approves it, and who should be responsible for it now?”

That shift matters. It turns identity governance from a forensic exercise into an operational one.

In practice, that means:

• Grouping identities by shared access patterns and environments
• Highlighting identities with no clear ownership signal
• Assigning responsibility through workflows (not tribal knowledge)
• Continuously updating that ownership as access changes

You may never get perfect lineage. But you can get current, defensible ownership — which is what auditors, and more importantly, incident responders actually need.

2) Detect Unused But High-Risk Permissions (the money shot)

CIS explicitly recommends disabling dormant accounts after 45 days of inactivity, where supported. NIST’s account management guidance reinforces that disabling inactive or anomalous accounts reduces attack surface. 

But in cloud, “inactive” can be misleading. Service accounts might run weekly. A role might only be used during incidents. So focus on unused + high blast radius:

• AWS examples: iam:PassRole, broad sts:AssumeRole, wildcard permissions, org-level admin, sensitive KMS decrypt, wide S3 read
• Entra/Azure examples: directory roles, privileged RBAC, and high-risk Graph app permissions
• GCP examples: roles/owner, org-level bindings, service account token creation permissions

Example: An Entra service principal hasn’t performed any action for weeks, but its secret never expires and it still has high privilege permissions. That isn’t “quiet.” That’s “parked.”

A modern entitlement platform should correlate what permissions exist, what’s used, and what’s risky, then let you prove the gap with evidence (not vibes). 

3) Revocation Automation (because humans won’t win this fight)

Manual cleanup doesn’t scale, and it fails exactly when you’re busy (which is always). The practical approach is tiered identity governance:

• Quarantine: disable interactive login, remove privileged group membership, revoke keys/tokens, keep the object temporarily
• Validate dependencies: confirm what will break (pipelines, workloads, integrations)
• Hard revoke: remove bindings, delete keys/secrets, delete the identity when safe
• Prevent recurrence: require owners, enforce expiry, and use just-in-time elevation instead of standing privilege

This “grant briefly, revoke automatically, keep receipts” model is exactly what you want for contractors and bots: access for minutes, not months. 

What This Looks Like in Real Life

• Contractor offboarding gap: contractor gets guest access to M365 and a direct SaaS admin role “just for the project.” Project ends, no HR event triggers. Guest remains. (SASI data shows guest accounts are rising fast, so this isn’t edge-case behavior.)
• CI service account orphan: ci-deploy-prod role has broad permissions because it was faster. The repo moved teams. The original owner left. The pipeline still works, so nobody touches it. Until it becomes the easiest escalation path in your environment.
• Consultant key rot: access key created for “temporary reporting,” copied into a script, never rotated, still valid. Everyone assumes “someone else” owns it.

The Simple Fix

Orphaned accounts, fuelled by remote-first practices, aren’t a quarterly clean-up job. They’re the background radiation of remote-first operations: apps everywhere, identities everywhere, ownership nowhere.

Fixing it means effective identity governance: 

• Continuous identity inventory.
• Ownership mapping for human and non-human identities.
• Detection of unused high-risk entitlements.
• Automated revocation workflows with just-in-time access.

Only then does “temporary access” stop becoming a permanent by-product of remote-first working.

You can move towards effective identity governance with clarity instead of guesswork via our totally free, full-feature trial. In as little as 30 minutes we can show you every entitlement across your estate. It issues access only when it’s genuinely required, withdraws it automatically when it’s not, and produces audit-ready evidence without friction. No credit card, no hoops. No assumptions. Just evidence. Manual approvals replaced with policy-driven controls and Slack or Teams chat-based workflows. “This should be fine” is replaced with enforceable guardrails that do exactly what they say they will. You’re welcome.