Notifications
Clear all
Topic starter
12/06/2026 1:12 am
TL;DR: Mid-lifecycle moves expose a governance gap that onboarding and offboarding workflows often miss, because role changes can alter application access, approval chains, and data exposure without a full lifecycle reset, according to Zluri. The control problem is not just automation debt but access drift across human identity and SaaS entitlements.
NHIMG editorial — based on content published by Zluri: Lifecycle Management Top 3 Challenges of Mid-Lifecycle Change Management Team
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should organisations handle access when an employee changes roles or departments?
A: Treat the move as a governance event, not an admin update.
Q: Why do mid-lifecycle changes create more risk than onboarding in many IAM programmes?
A: Onboarding is usually structured and visible, while mover events are scattered across HR, IT, and application owners.
Q: How can security teams tell whether mover workflows are actually working?
A: Look for evidence that access is removed as often as it is added, that app owners can approve changes quickly, and that periodic reviews catch stale entitlements.
Practitioner guidance
- Trigger access revalidation on every mover event Re-evaluate application, file, and admin entitlements whenever a person changes role, department, or location.
- Map mid-lifecycle changes to role-based policies Translate common movement scenarios into policy rules so access can be adjusted consistently across SaaS, directory groups, and shared drives.
- Add discovery for shadow IT and unsanctioned app use Track applications that appear outside the approved software catalogue, then reconcile them against mover workflows and access reviews.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step workflow examples for handling role changes across applications and approvals
- Detailed guidance on employee app store request flows and how users submit access changes
- Operational handling of shadow IT discovery and SaaS buying integration in the same workflow
- Interface-level instructions for checking changelogs and request updates inside the platform
👉 Read Zluri's article on mid-lifecycle change management and access control →
Mid-lifecycle access changes: what IAM teams are missing?
Explore further
12/06/2026 10:58 am
Mid-lifecycle change is where access governance most often fails by omission. Joiners and leavers usually get process attention, but movers are where privilege creep accumulates quietly. When an employee changes role, the old entitlement set often survives because the access model was built around static employment states, not changing work patterns. The practitioner takeaway is that lifecycle governance must treat movement as a first-class control event.
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.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who should be accountable for access when an employee transfers to a new team?
A: Accountability should sit with the current business owner, not only with HR or central IT. HR can trigger the event, but the receiving manager and application owner must confirm the access set matches the new role. Without named ownership, mover events become gaps that nobody closes.
👉 Read our full editorial: Mid-lifecycle access changes expose the real IAM governance gap
