Who should be accountable for onboarding and offboarding when an app is only partially integrated with IAM?

Why This Matters for Security Teams

When an application is only partly integrated with IAM, onboarding and offboarding stop being a simple workflow question and become a control ownership problem. The risk is not just delayed access changes; it is the gap between the business request and the system of record that can leave accounts, secrets, and approvals drifting out of sync. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls still points to defined accountability for account management, while NHIMG research shows the operational maturity gap clearly: 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, according to the 2024 Non-Human Identity Security Report.

The practical issue is that partial integration creates a false sense of automation. Teams may assume an app is covered because SSO exists, while deprovisioning, periodic review, or service account cleanup still happens manually or not at all. That is where accountability must be explicit, because the control owner is responsible for the outcome even when the mechanism is fragmented. In practice, many security teams discover the missing control only after a former user, contractor, or service account is still active weeks later.

How It Works in Practice

The accountable owner should be the IAM or identity operations function, because that team is best positioned to enforce consistent joiner, mover, and leaver controls across both integrated and partially integrated systems. Application owners and IT administrators support the process by supplying app-specific knowledge, validating technical constraints, and executing manual steps where automation is unavailable. Business approvers can authorise access need, but they should not own the operational control.

A workable model usually combines four elements. First, every partially integrated app should have a named control owner, a documented provisioning path, and a documented deprovisioning path. Second, if the app cannot be fully automated, the manual process must define who performs the action, what evidence is captured, and how completion is verified. Third, access reviews should include these exceptions so that orphaned accounts and stale entitlements are not hidden outside the IAM toolchain. Fourth, the organisation should track whether the app can later be moved toward fuller lifecycle control, using the NHI Lifecycle Management Guide as a practical reference for lifecycle ownership and review discipline.

This is especially important for non-human identities, because shared service accounts, API keys, and workload credentials often outlive the human process that created them. NIST SP 800-63 Digital Identity Guidelines is focused on identity assurance, but the operational lesson carries over: identity governance only works when issuance and revocation are reliable, traceable, and attributable. The same logic applies to Top 10 NHI Issues, where lifecycle failure is a recurring risk pattern. These controls tend to break down when ownership is split across teams without one function assigned to verify completion, because manual exceptions become permanent exceptions.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance speed of access against the risk of orphaned or over-privileged accounts. That tradeoff is real in legacy apps, vendor portals, and line-of-business systems that do not support SCIM, APIs, or strong admin auditing. In those environments, best practice is evolving, but there is no universal standard for this yet beyond clear ownership and repeatable evidence.

One common edge case is when business teams believe they own access because they sponsor the application. Sponsorship matters, but it does not replace control ownership. Another is when IT operations manages the server but not the application account lifecycle. That split often creates a gap where nobody revokes access because each team assumes the other one does. A third case is outsourced or partner-managed applications, where the vendor may execute changes but the organisation still retains accountability for ensuring the process actually happens.

For this reason, partial integration should be treated as a risk condition, not an excuse. The accountable function should require compensating controls such as periodic certification, ticket-based evidence, and exception registers until the app can be brought into a more complete lifecycle process. Where manual processing is unavoidable, consistency matters more than elegance.

Related resources from NHI Mgmt Group

• Who is accountable when a desktop credential app weakens its isolation to gain system-wide features?
• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?