Topic starter
25/06/2026 3:18 pm
TL;DR: Provisioning is no longer just account setup: SecurEnds argues it now determines who gets access, when it arrives, and how cleanly it is removed, while manual workflows increase delay, over-provisioning, and orphaned-account risk. That shifts provisioning into the centre of IAM, IGA, and cloud governance.
Editorial analysis by NHI Mgmt Group, based on content published by SecurEnds: “What is Provisioning? Process & Best Practices”.
Key questions
Q: What breaks when access provisioning is still mostly manual?
A: Manual provisioning slows onboarding, delays role changes, and makes revocation easier to miss.
Q: Why does slow provisioning create security risk instead of just user friction?
A: Slow provisioning encourages workarounds, temporary exceptions, and repeated access grants that are hard to unwind later.
Q: How do RBAC and ABAC differ in provisioning decisions?
A: RBAC grants access through predefined job roles, while ABAC uses attributes such as department, location, or device context to make decisions.
Practitioner guidance
- Align provisioning to joiner-mover-leaver lifecycle rules Map account creation, entitlement changes, and revocation to joiner-mover-leaver events so access changes follow role movement rather than ticket timing.
- Replace manual entitlement assignment with policy-driven automation Use workflow triggers and policy rules to provision standard access from HR or identity source changes, then log every entitlement change for review.
- Apply role and attribute logic together Use RBAC for baseline access and ABAC for context-sensitive exceptions such as location, device posture, project window, or contractor terms.
Bottom line: Provisioning is no longer a support function, because it now determines how access is created, changed, and removed across the identity lifecycle.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:45 pm
Provisioning has become the execution layer of IAM governance. The article is right to treat provisioning as more than account setup, because policy has no security value until it is applied to a live entitlement. Once identity decisions determine when access is created, changed, or removed, provisioning becomes the control that turns IAM from a record-keeping function into an enforcement function. Practitioners should treat provisioning as part of governance design, not as a back-office implementation detail.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
A question worth separating out:
Q: What should teams do to keep provisioning auditable across IAM and IGA?
A: Teams should ensure every provisioning event is tied to a policy source, an approval path, and a logged outcome that can be reviewed later. That means provisioning changes should be traceable from request to entitlement to removal. Without that chain, access reviews become retrospective guesswork instead of evidence-based governance.
👉 Read our full editorial: Provisioning is becoming a core IAM control, not just access setup