Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Identity lifecycle bottlenecks: what onboarding and offboarding still break


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9439
Topic starter  

TL;DR: Slow onboarding and incomplete offboarding still create productivity drag, security exposure, and audit pain because many teams rely on tickets, siloed systems, and manual approvals, according to Lumos. Fast lifecycle management is no longer just an IT convenience; it is a control point for least privilege, revocation, and compliance.

NHIMG editorial — based on content published by Lumos: How Lumos Speeds Up Onboarding and Offboarding

By the numbers:

Questions worth separating out

Q: How should teams reduce onboarding delays without weakening access control?

A: Teams should use event-driven onboarding tied to HR and identity sources, then separate birthright access from exception-based requests.

Q: Why do offboarding failures create such persistent security risk?

A: Offboarding failures persist because revocation is often partial.

Q: What do security teams get wrong about self-service access requests?

A: They often treat self-service as a UX feature instead of a governance control.

Practitioner guidance

  • Connect lifecycle events to authoritative identity sources Trigger joiner and leaver actions from HRIS and identity provider events so provisioning and deprovisioning start from one governed record.
  • Separate birthright access from exception access Define which apps are provisioned automatically, which require app-owner approval, and which need policy exceptions with documented review.
  • Require closure evidence for every leaver Capture task completion timestamps, revocation confirmations, and app-owner responses so offboarding is auditable across directory and application layers.

What's in the full article

Lumos's full blog covers the operational detail this post intentionally leaves for the source:

  • Step-by-step workflow logic for provisioning and deprovisioning across HRIS, IdP, and SaaS integrations
  • Examples of self-service request routing and app-owner approval paths in the platform
  • Operational detail on AI-driven role recommendations and how the vendor positions access bundles
  • Audit trail handling for offboarding tasks, task reminders, and revocation confirmation

👉 Read Lumos's blog on accelerating onboarding and offboarding →

Identity lifecycle bottlenecks: what onboarding and offboarding still break?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8923
 

Identity lifecycle remains a control problem, not a workflow problem. The article correctly shows that onboarding and offboarding fail when organisations treat them as ticket queues rather than governance events. The deeper issue is that access authority, app ownership, and HR status are often not bound tightly enough to produce reliable joiner and leaver decisions. Practitioners should treat lifecycle as an access-control boundary, not an administrative convenience.

A few things that frame the scale:

  • Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
  • 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.

A question worth separating out:

Q: How should organisations apply lifecycle governance to service accounts and AI agents?

A: They should apply the same joiner-mover-leaver discipline used for employees, but with actor-specific controls for creation, ownership, rotation, delegation, and revocation. Service accounts and AI agents do not leave through resignation, so offboarding must be event-based, explicit, and traceable across the systems they can access.

👉 Read our full editorial: Onboarding and offboarding remain the identity lifecycle bottleneck



   
ReplyQuote
Share: