What is Orphaned Non-Human Identity?

Definition

An orphaned Non-Human Identity (NHI) is an NHI that:

• Has no current owner.
• And/or is no longer used for any active purpose.
• And/or belongs to a decommissioned workload, integration, or use case.

Orphans typically accumulate when departing employees leave their NHIs behind, when use cases retire without cleanup, or when ad-hoc creations are never inventoried.

In simple terms:

An orphan NHI is one that nobody owns, nobody monitors, nobody uses — but might still have permissions and credentials adversaries can exploit.

---

Why It Matters

• Orphans are common — 20–50% of NHIs in mature environments.
• Orphans are over-permissioned and unmaintained.
• Orphans are prime targets for adversaries (no one notices abuse).
• Compliance frameworks call for stale identity remediation.

---

How NHIs Become Orphans

1. Departed Employee Created Them

Developer left; their personal SAs / API keys / OAuth grants remain.

2. Retired Use Case

Project ended; NHIs not decommissioned.

3. Ad-Hoc Creation

Created for a quick task; never registered; never reviewed.

4. Workload Deletion

K8s namespace deleted; cloud SA persists; IAM bindings persist.

5. SaaS App Uninstalled

Connected app uninstalled in UI; OAuth grant remains.

6. Vendor Integration Ended

Vendor relationship terminated; NHI not removed from your side.

7. Pilot Becomes Forgotten

Pilot completed; NHIs stay active "in case we need them."

8. Migration Leftovers

Migrated from system A to system B; A's NHIs not cleaned up.

---

Risks

1. Compromise Goes Unnoticed

• No owner = no anomaly investigation.

2. Over-Permissioned

• Permissions accumulate over orphan's life; never reviewed.

3. Static Credentials Persist

• API keys / SA keys long-lived; leak risk grows.

4. Compliance Findings

• "Identity X has not been recertified in 3 years."

5. Insider Risk

• Departing employee's "personal" NHI may be retained for insider use.

6. Attack Surface Bloat

• Each orphan = additional attack surface.

7. Cost Surprise

• Orphan that consumes resources / bills.

8. Audit Gap

• Activity tracked to no human.

---

Real-World Examples

1. Departed Developer's Service Account

SA created by dev who left 18 months ago; in 14 IAM roles; quietly used by an old script. Owner: nobody. Found in audit; decommissioned.

2. Retired Pilot

Pilot ran for 3 months in 2022; 5 SAs created; pilot ended; SAs stayed active. Still had access to production data. Decommissioned in NHI cleanup.

3. Uninstalled Slack App

App uninstalled in UI 6 months ago. OAuth grant still active. Vendor compromised → grant abused. Mitigation: explicitly revoke OAuth on uninstall.

4. Migration Leftovers

Migrated CI from Jenkins to GitHub Actions. Jenkins SAs forgotten; remained in cloud IAM with broad permissions. Found in NHI audit.

5. Ad-Hoc API Key

Engineer made an OpenAI key for a quick test; left for new role; key stayed; bill spiked when test script reactivated. Found via cost monitoring.

---

Detection

1. No Owner

• NHI has no recorded owner; or owner is departed.

2. Unused

• Audit logs show no activity in 30 / 60 / 90 days.

3. Decommissioned Workload

• Associated workload no longer exists.

4. Use Case Retired

• Documented use case marked retired.

5. Stale Credentials

• Last used > N months.

6. Cross-Reference

• Inventory + activity logs + workload registry → orphan candidates.

---

Remediation Pattern

1. Detect Candidates

Continuous via tooling (Forestall, IGA).

2. Ownership Confirmation

Reach out via auto-detected owner / team.

3. Justify or Decommission

Owner justifies (then assign / recertify) or no claim → decommission.

4. Suspend First

Disable for 30 days; catch dependencies.

5. Notify Dependent Services

If dependencies surface, restore + reassign owner.

6. Delete

After suspend window with no issues, delete.

7. Archive Audit Trail

Preserve history for investigations.

8. Update Inventory

Mark as decommissioned.

---

Best Practices

1. Continuous discovery — orphans accumulate constantly.
2. HR integration — leaver triggers ownership transfer or decommissioning.
3. Workload integration — workload deletion → NHI cleanup.
4. Recertification quarterly to detect stale.
5. Suspend-then-delete to avoid breaking dependencies.
6. Audit retention post-deletion for IR.
7. KPIs — orphan count, mean age, decommission rate.
8. No-owner SLA — must be owned within X days or decommissioned.
9. Tag enforcement at creation to prevent new orphans.
10. Cross-functional governance.

---

Checklist

• Continuous orphan detection?
• HR-triggered transfers / decommissioning?
• Workload-triggered cleanup?
• Quarterly recertification?
• Suspend-then-delete pattern?
• Audit retention?
• Orphan KPIs?
• No-owner SLA?
• Tag enforcement at creation?
• Decommissioning playbook?

---

How Forestall Helps

Forestall:

• Detects orphans via ownership + usage + lifecycle signals.
• Initiates ownership / decommissioning workflows.
• Tracks orphan KPIs over time.

---

Frequently Asked Questions

How many orphans are normal?

In an unmanaged environment, 20–50%. After NHI governance, < 5%.

Should I delete orphans immediately?

Suspend first; delete after window with no issues.

What if an orphan turns out to be needed?

Suspend window catches this; restore + assign owner + recertify.

Are orphans always risky?

Generally yes — over-permissioned, unmonitored, stale credentials.

Can I prevent orphans?

Largely — HR integration + workload integration + tag enforcement + ownership SLA at creation.

---

Conclusion

Orphaned NHIs are the silent risk in modern environments — over-permissioned, unmonitored, and easy to abuse. Detect continuously, integrate with HR and workload events, recertify quarterly, suspend-then-delete, and prevent new orphans via creation-time controls. With orphan management in place, your NHI inventory shrinks to what's actually needed — and so does your attack surface.