Because connector scope rarely keeps pace with the full application estate. Native integrations cover the common systems first, while legacy platforms, custom builds, and SaaS apps without SCIM support remain outside automated lifecycle control and fall back to helpdesk or app-owner queues.
Why manual provisioning persists after go-live
IGA does not eliminate manual work the moment a programme goes live because the integration backlog is usually larger than the first deployment wave. The platform may be ready, but the application estate is not. Teams inherit legacy systems, custom workflows, and SaaS tools that do not expose the right lifecycle hooks, so provisioning keeps falling back to tickets, app owners, or the helpdesk.
That gap is usually structural, not accidental. Go-live proves the programme can automate a subset of the estate; it does not mean connector coverage, authoritative source mapping, or entitlement design is complete across every business application. In practice, the manual queue often becomes the control surface for exceptions, edge cases, and systems that are not yet economically worth integrating.
The underlying challenge is that IGA must cope with different application classes at once. A foundational IAM and IGA model covers provisioning and governance together, but the automation path for a modern SaaS app is very different from the path for a mainframe, a bespoke internal tool, or a vendor portal with limited APIs. That mismatch is why “live” and “fully automated” are not the same state.
Where the automation boundary usually breaks
Manual provisioning usually persists where the connector cannot express the real business rule, not just where a connection is missing. Common breakpoints include applications with weak role models, inconsistent entitlement naming, no SCIM or equivalent lifecycle interface, multiple admin planes, or approval logic that still lives outside the IGA workflow.
Another frequent cause is poor application classification. The programme may prioritise high-volume systems first, while low-volume but business-critical apps remain outside the automation backlog for months. That leaves a long tail of “special handling” applications that still need human intervention for joiners, movers, and leavers.
Connector design also tends to lag entitlement design. If the team has not standardised roles, ownership, and source-of-truth rules, even a technically integrated application can remain partly manual because the control cannot reliably decide what access should be granted. The Role Mining and Role Design Guide is useful here because bad role structure often looks like a connector problem when it is really an authorization problem.
Why the manual queue does not disappear on day one
After go-live, many programmes discover that the manual queue is carrying more than temporary backlog. It absorbs exceptions, compensating controls, and systems whose owners have not yet agreed to standardised provisioning rules. In other words, the queue becomes the operational bridge between the target state and the messy application reality.
This is also why access governance and lifecycle governance have to move together. If onboarding is automated but offboarding remains partially manual, the programme may still leave stale access behind. A JML process only works when the full lifecycle is defined, including the systems that cannot yet be auto-provisioned.
For practitioners, the question is less “why is it still manual?” and more “which manual steps are unavoidable exceptions, and which are just unresolved automation debt?” That distinction determines whether the programme needs better connectors, better role engineering, or stronger application ownership discipline. The IGA Buyer’s Guide is useful because connector coverage, disconnected applications, and vendor due diligence should be treated as core implementation concerns rather than afterthoughts.
Risk and Threat Considerations
Manual provisioning is not just inefficient, it creates inconsistent access paths that are harder to audit and easier to misuse. Every application left outside automated lifecycle control increases the chance of stale accounts, delayed removals, and undocumented privilege grants, especially when requests move through email or ticket queues instead of enforced workflows.
Failure mechanism: The programme automates the common applications first, but the remaining estate stays on ad hoc human handling, so provisioning, deprovisioning, and entitlement changes are applied unevenly and are often weakly evidenced.
Impact: Access drift grows over time, joiner and leaver actions become unreliable, and audit teams lose confidence that the IGA programme reflects the real application estate. That can widen the blast radius of account misuse and make remediation slower when an access issue is found.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Automated provisioning and deprovisioning are core account management obligations. |
| IA-5 — Authenticator Management | Manual provisioning often leaves credential issuance and revocation outside controlled lifecycle handling. | |
| AC-6 — Least Privilege | Partial automation often creates overbroad access in manually handled applications. | |
| Recommendation — Standardise account lifecycle actions and remove manual provisioning where integration exists. Tie credential issuance and revocation to governed lifecycle workflows. Limit entitlements in exceptions to the minimum access needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Manual provisioning is an access-control governance issue when applications remain outside automated lifecycle control. |
| A.5.16 — Identity management | The question concerns identity lifecycle handling across applications after go-live. | |
| A.5.18 — Access rights | Manual fallback processes often delay timely removal and review of access rights. | |
| Recommendation — Define consistent access approval and revocation rules for all application classes. Maintain authoritative identity records for every application and exception path. Review and remove access rights on a defined schedule, including manual queues. | ||
Practitioner Guidance
What to prioritise: Classify the manual queue by reason, not just by volume. Separate true exception handling from applications that are simply waiting for connector work, role design, or owner decision-making.
What to verify: For every manual application, confirm who owns the entitlements, what the authoritative source is, and whether the manual process includes evidence of approval, completion, and revocation. If those three are unclear, the control is not just manual, it is ambiguous.
Common mistake: Treating “go-live” as the end of implementation. In reality, go-live is the point at which the programme starts revealing the long tail of systems that need either integration, retirement, or a formal exception path.
Practitioner takeaway: Manual provisioning is acceptable only when it is a deliberate, governed exception; if it persists by default, the programme has not yet closed the gap between access policy and application reality.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org