Topic starter
05/10/2026 6:49 pm
TL;DR: Identity Connectivity uses autonomous agents to execute identity lifecycle actions directly in target applications, dynamically choosing APIs, SCIM or agents at runtime while preserving existing IGA policy and audit models, according to StackBob. The shift matters because onboarding has been constrained by connector limits, manual fulfilment and brittle RPA, so governance now moves from static integration design to adaptive execution.
Editorial analysis by NHI Mgmt Group, based on content published by StackBob: “StackBob Identity Connectivity: The Next Evolution of IGA”.
Questions worth separating out
Q: What breaks in IGA when connector strategy becomes runtime-driven?
A: What breaks is the assumption that governance can be designed around one stable execution path.
Q: Why do manual fulfilment and RPA approaches create governance risk?
A: They create risk because the policy decision and the actual identity change are separated by tickets, scripts or browser automation, which makes fulfilment failure and delayed reconciliation more likely.
Q: How should teams decide which applications need adaptive identity connectivity first?
A: Start with the applications that are hardest to onboard, most business-critical, or most exposed to manual workarounds.
Practitioner guidance
- Inventory applications by governance difficulty Classify target applications by API maturity, SCIM fit, reconciliation quality and connector fragility so you can see where adaptive execution is actually needed.
- Separate policy decisions from execution paths Keep approval logic, entitlement policy and attestation requirements independent from the mechanism used to complete the request, whether API, SCIM, agent or manual fallback.
- Define evidence requirements for runtime-selected actions Require the same audit evidence regardless of which interaction mechanism the model selects, including who approved, what changed and how the change was verified.
Identity connectivity: what it means for IAM and IGA teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
05/10/2026 6:49 pm
Identity Connectivity is an execution model, not a new governance model. The article describes a shift in how identity actions are carried out, but the governance obligations remain the same: approval, reconciliation, auditability and lifecycle accountability. The practical difference is that the control environment must now supervise a runtime decision layer that chooses the execution path. Practitioners should treat this as an expansion of IGA execution options, not a replacement for policy ownership.
A few things that frame the scale:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
A question worth separating out:
Q: How do you keep IGA controls consistent when multiple execution methods are allowed?
A: Define the control outcome first, then require every execution path to prove the same outcome. If the request can be completed by API, SCIM, agent or a fallback process, the evidence standard should stay constant so audit and certification remain comparable.
👉 Read our full editorial: Identity connectivity is reshaping IGA onboarding and governance