Notifications
Clear all
Topic starter
04/07/2026 9:56 pm
TL;DR: Onboarding often fails because teams rely on scattered scripts, group rules, and manual judgment to define access, while birthright policies and lifecycle controls are only partially codified, according to Lumos. The governance problem is not provisioning speed alone but ownership, policy design, and lifecycle consistency across joiner, mover, and leaver states.
NHIMG editorial — here’s why we think this discussion matters
Questions worth separating out
Q: How should teams design onboarding access policies without creating role sprawl?
A: Start by defining a small number of trusted entitlement patterns based on real job function and application usage, then assign ownership to each pattern.
Q: Why do onboarding workflows often produce excessive access on day one?
A: Because teams optimise for speed before they have a clear policy model for what each new hire should receive.
Practitioner guidance
- Centralise entitlement definitions in one policy layer Define standard onboarding entitlements once, then push them through the identity provider so the grant logic does not depend on scattered scripts or local exceptions.
- Assign named owners to every access policy Require a business or application owner for each role and entitlement set so there is accountability when access is too broad or no longer aligned to function.
- Use policy mining as a drafting input only Mine real HR attributes and observed usage to draft RBAC candidates, then validate each role against actual task need before approving it for production.
What to expect at the briefing
Lumos's full webinar covers the operational detail this post intentionally leaves for the source:
- How the access policy layer sits on top of the identity provider in a real onboarding flow
- How lifecycle management is applied to joiner, mover, and leaver events in practice
- How RBAC Policy Mining uses HR attributes and usage data to draft role policies
- How named policy ownership is handled in the Lumos workflow and governance model
👉 Register for Lumos's webinar on autonomous identity onboarding and access policies →
Autonomous identity onboarding on Jul 30: what changes for access policy?
Explore further
04/07/2026 10:03 pm
Onboarding failure is usually a governance design problem, not an automation problem. The article shows that broad day-one access persists when entitlement definition is scattered across scripts, group rules, and workflow logic. That fragmentation creates a policy vacuum where nobody owns what good access should look like. Practitioners should treat onboarding as a control design issue, not a ticketing issue.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: What should IAM teams review before adopting policy mining for RBAC?
A: They should review whether the underlying HR attributes are reliable, whether the usage data reflects actual work, and whether each mined role will still need human approval. Policy mining is strongest as evidence for governance, not as a substitute for it.
👉 Read our full editorial: Autonomous identity onboarding is shifting access policy ownership
