Identity automation breaks down where app standards never arrive

At a glance

What this is: This analysis argues that the application identity gap is persistent because vendor incentives, legacy infrastructure, and brittle custom integrations keep many apps outside IAM and IGA control.

Why it matters: It matters because lifecycle governance, deprovisioning, and access review programmes cannot depend on standards support that many critical applications will never provide.

By the numbers:

• Fewer than 7% of applications support SCIM.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Cerby's analysis of why the app identity gap will not disappear

Context

Identity automation depends on application support for standards such as SCIM, user management APIs, or federated workflows. When those capabilities are missing, lifecycle tasks move back to manual execution, which increases delay, inconsistency, and governance drift across IAM and IGA programmes.

The problem is not limited to fringe software. Critical on-premises and private applications, plus custom integrations that break when endpoints or UIs change, keep many organisations stuck with a permanent manual identity execution layer. That is why lifecycle control becomes a programme design issue, not a tooling feature request.

Key questions

Q: How should organisations manage applications that cannot support SCIM or federation?

A: They should treat those applications as permanent exceptions, not temporary gaps. Build a manual-execution register, assign owners, define approval and validation steps, and apply compensating controls such as tighter review cadence and stronger logging. The goal is to preserve governance even when the application cannot join normal IAM automation.

Q: Why do custom IAM connectors often fail to deliver lasting coverage?

A: Custom connectors usually depend on specific app versions, private endpoints, or UI states, so they break when the application changes. That creates ongoing maintenance tax and makes the control path brittle. Organisations should assume these connectors need continuous support rather than one-time delivery.

Q: How can security teams reduce risk from manual identity execution?

A: By narrowing where manual execution is allowed, documenting each exception, and enforcing audit-ready workflows for every non-automated access change. Manual processes should still have approvals, evidence, and ownership. Without those controls, identity changes become hard to prove and harder to reverse.

Q: Who should own lifecycle control when the application vendor does not support identity standards?

A: Ownership stays with the enterprise, not the vendor. Security, IAM, and application teams must agree on compensating controls, exception handling, and review responsibilities. If the app cannot support automated provisioning or revocation, the business still needs a controlled offboarding and access governance process.

Technical breakdown

Why SCIM coverage remains a structural exception

SCIM, the System for Cross-domain Identity Management, is designed to standardise user provisioning and deprovisioning across applications. In practice, many vendors prioritise core product features, reliability, and growth integrations before identity standards, and some reserve those capabilities for premium tiers. That creates a market where standards support is uneven and often incomplete, even when customers want it. The technical result is fragmented lifecycle automation across the application portfolio.

Practical implication: treat SCIM coverage as an application-by-application control attribute, not a baseline assumption.

Why custom connectors create maintenance tax

Custom IAM connectors can close individual gaps, but they are usually built against a specific app version, API shape, or UI state. That makes them brittle when vendors change private endpoints or ship interface updates. They also scale poorly because each app may require separate work for multiple versions and workflows. The technical debt is not just engineering effort. It becomes operational fragility that teams must continually repair.

Practical implication: model custom integrations as ongoing control debt, not one-time implementation work.

Why disconnected applications force manual identity execution

Where an app exposes no SCIM endpoint and no usable API, conventional IAM and IGA automation has nothing to connect to. In those cases, identity lifecycle actions such as joiner, mover, and leaver steps cannot be executed by standard tooling. Manual processing becomes the only remaining control path, even in well-funded environments. That is why disconnected applications persist as an identity governance exception class rather than a short-term transition state.

Practical implication: maintain an explicit manual-execution register for apps that cannot be automated and review it regularly.

NHI Mgmt Group analysis

Disconnected applications are not an edge case, they are a permanent identity governance class. The article makes clear that SCIM gaps, on-premises persistence, and brittle custom work are not temporary roadblocks on the way to full automation. They are structural conditions that keep many critical applications outside normal lifecycle control. Practitioner implication: governance programmes must classify and manage disconnected apps as a standing portfolio risk.

Maintenance tax is the real cost centre in identity automation. Custom connectors look like a bridge to coverage, but every API change, UI update, or version split turns that bridge into recurring operational debt. This shifts the problem from initial integration effort to continuous control fragility. Practitioner implication: budget for connector upkeep as part of identity governance, not as a one-time project line item.

The standards tax exposes how vendor incentives shape identity coverage. When SCIM and user management APIs sit behind premium tiers or below product priorities, the market is signalling that enterprise identity control is still optional from the application vendor perspective. That means IAM and IGA teams cannot outsource lifecycle maturity to product roadmaps. Practitioner implication: procurement must treat identity support as a contractual governance requirement, not a hoped-for feature.

Identity lifecycle across human and non-human accounts now depends on the same exception handling model. The article’s core lesson extends beyond user provisioning to service accounts, API-driven access, and any application that resists federation. The common failure is not only a missing connector but an operational assumption that automation will eventually absorb the exception. Practitioner implication: build one lifecycle control model that explicitly covers humans, NHIs, and disconnected apps.

Manual execution is not merely inefficient, it is where accountability evaporates. When access changes are handled outside IAM and IGA systems, the organisation loses a reliable audit trail for who approved, executed, and validated the change. That weakens both access governance and incident reconstruction. Practitioner implication: if an app cannot be automated, its manual process must still be instrumented as a controlled identity workflow.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• For the broader lifecycle angle, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding stay governable even when automation coverage is uneven.

What this signals

Manual identity execution will remain part of the operating model. For most IAM programmes, the practical question is not how to eliminate exceptions, but how to govern them without losing evidence, accountability, or offboarding discipline. That means building a lifecycle process that spans automated and manual apps rather than assuming standards support will eventually arrive.

Maintenance tax should be tracked as a governance metric. If teams cannot say how many custom connectors are in play, who owns them, and how often they break, the identity programme is carrying hidden operational risk. The issue is not just integration cost. It is whether the organisation can still prove access removal and access change integrity when the app layer resists automation.

Identity coverage is now a procurement and architecture problem together. Standards support belongs in buying decisions, but the existing estate still needs exception handling, logging, and review discipline. Organisations that separate those two concerns will keep building automation islands around the same manual core.

For practitioners

• Map disconnected applications as a separate control class Inventory every application that lacks SCIM, user management APIs, or reliable federation and tag it as manual-execution dependent. Use that register to drive exception handling, compensating controls, and remediation priorities across IAM and IGA.
• Treat custom connectors as durable control debt Track every bespoke integration by app version, endpoint dependency, owner, and break/fix history. Reassess whether the connector is still stable enough to carry joiner, mover, and leaver workflows without recurring manual repair.
• Make procurement a governance control point Require identity standards support, lifecycle APIs, and revocation capability in application buying criteria and contract language. If the product cannot support it natively, document the compensating process before deployment.
• Instrument manual workflows for auditability For applications that cannot be automated, define approval, execution, and validation steps in a controlled workflow with logs and ownership. This preserves evidence for access review, offboarding, and incident investigation.

Key takeaways

• Application identity gaps persist because vendors, legacy systems, and custom integrations all work against full lifecycle automation.
• Bespoke connectors create recurring maintenance burden, which turns identity coverage into a durability problem rather than a deployment problem.
• IAM and IGA teams should govern disconnected applications as permanent exceptions with explicit ownership, controls, and audit evidence.

Key terms

• Disconnected Application: An application that cannot be fully managed through standard identity automation such as SCIM, federation, or supported lifecycle APIs. These systems require exception handling because provisioning, revocation, and review cannot be executed reliably through normal IAM controls.
• Manual Identity Execution: Identity change work carried out outside normal IAM or IGA automation, usually through helpdesk tickets, admin consoles, scripts, or ad hoc procedures. It preserves functionality when automation is unavailable, but it also increases drift, delays, and audit difficulty if not tightly controlled.
• Maintenance Tax: The recurring operational cost created when custom integrations must be repaired, retested, and revalidated as applications change. In identity programmes, maintenance tax is a sign that coverage exists only through brittle bespoke work rather than stable, governed automation.
• Standards Tax: The extra cost organisations pay when identity standards such as SCIM or lifecycle APIs are available only in premium tiers or not at all. It reflects a market where baseline governance capabilities depend on vendor prioritisation instead of being available by default.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerby: why the app identity gap will not go away. Read the original.