Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk What do security teams get wrong about application…
Governance, Ownership & Risk

What do security teams get wrong about application onboarding in IGA projects?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated August 11, 2026 Domain: Governance, Ownership & Risk

They often assume onboarding is a late-stage operational task rather than the hidden critical path. In reality, onboarding reveals whether governance decisions can actually be enforced. If the application cannot receive, apply, and prove the change, the control is incomplete even when the workflow is technically approved.

Why This Matters for Security Teams

Application onboarding in IGA is where governance becomes real. If an application cannot accept entitlements, enforce approval logic, and produce evidence of access state, then the control is only documented, not deployed. That matters because onboarding is often treated as integration work, when it is actually the point where policy, identity data, and operational ownership must line up.

Security teams also underestimate how much onboarding exposes gaps in service accounts, privilege design, and evidence collection. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and 71% of NHIs are not rotated within recommended time frames. That is a strong signal that onboarding is not a clerical step; it is where hidden NHI risk becomes measurable.

Current guidance across identity and Zero Trust programs aligns with this view. NIST’s Cybersecurity Framework and Zero Trust thinking both assume that access must be continuously governed, not simply approved once. In practice, many security teams discover onboarding defects only after a business unit tries to certify access and finds the system cannot prove what it granted or why.

How It Works in Practice

Effective onboarding starts before the connector is built. Security and identity teams need to define the entitlement model, the source of truth for identities, the approval path, and the audit evidence that the target application can actually emit. If an app only supports coarse admin roles, the IGA workflow may still be approved, but the resulting control will be too blunt to satisfy least privilege.

For NHI-heavy applications, onboarding must also account for service accounts, API keys, OAuth grants, and machine-to-machine credentials. This is where many programs fail: they map human joiner-mover-leaver processes onto non-human access without adjusting for lifecycle, ownership, or rotation. The State of Non-Human Identity Security highlights a broader confidence gap, which is consistent with onboarding teams lacking complete visibility into what the application really uses behind the scenes.

  • Confirm the app can ingest authoritative identity data, not just a flat list of users.
  • Validate that entitlement grants are reversible and time-bound where possible.
  • Require evidence of effective access, not only workflow approval status.
  • Document who owns exceptions when the app cannot support standard IGA controls.
  • Test deprovisioning and revocation early, before go-live.

Practitioners should also check whether the application can distinguish role assignment from actual privilege enforcement. Some platforms present a successful provisioning event even though downstream permissions are delayed, cached, or overridden locally. IGA should verify the end state in the target system, not trust the connector alone. This aligns with general identity guidance in the FATF Recommendations, where traceability and accountability matter as much as formal assignment.

These controls tend to break down in legacy applications with custom directories, opaque admin APIs, or manual approval steps outside the IGA tool because the system cannot reliably prove entitlement state after the workflow completes.

Common Variations and Edge Cases

Tighter onboarding controls often increase implementation cost and delay release schedules, requiring organisations to balance governance quality against application complexity. That tradeoff becomes visible in edge cases where the app is business-critical but was never designed for automated identity governance.

One common variation is partial onboarding. Security teams may integrate only access requests while leaving recertification, birthright access, or deprovisioning manual. That can be acceptable as a temporary bridge, but current guidance suggests treating it as an exception with a documented expiry, not a stable operating model. Another edge case is third-party or partner access, where ownership is shared and entitlement data may be incomplete. In those environments, the onboarding question is less about whether the workflow exists and more about whether the application can prove boundary conditions cleanly.

There is also no universal standard for what “complete onboarding” means across all IGA programs. Some organisations consider request and approval coverage sufficient; others require lifecycle automation, event-driven revocation, and certification reporting before declaring success. The practical test is simple: if access cannot be reconciled after a change, the application is not truly onboarded, even if the connector is live.

NHIMG’s Ultimate Guide to NHIs is a useful reference for teams deciding where to draw that line, especially when non-human accounts and secrets are part of the same onboarding scope.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01Onboarding exposes incomplete NHI lifecycle ownership and hidden credentials.
OWASP Agentic AI Top 10A-03Autonomous tools and agents make onboarding a runtime access enforcement problem.
CSA MAESTROGOV-02Agent and workload governance depends on enforceable onboarding and evidence.
NIST CSF 2.0PR.AC-4IGA onboarding must enforce least privilege and managed access state.
NIST AI RMFGOV-3Governance processes must be defined and measurable for identity-enabled systems.

Validate provisioning, deprovisioning, and recertification against least-privilege requirements.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org