The connector treadmill exposes the real cost of identity integration

At a glance

What this is: This is a blog post arguing that application integration in identity governance is a recurring operating burden, not a one-time project.

Why it matters: It matters because IAM and IGA teams must budget for ongoing connector maintenance, continuous validation, and governance across disconnected applications rather than assuming onboarding ends the work.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Opnova's analysis of the connector treadmill in identity governance

Context

Identity governance often treats application onboarding as a discrete project with a finish line. In practice, disconnected applications, changing authentication requirements, and shifting schemas turn every connector into a standing operational dependency that has to be maintained for as long as the application exists.

For IAM and IGA teams, the real issue is not whether connectors can be built, but whether the programme is designed to absorb continuous change across human, NHI, and workflow-driven access paths. The connector treadmill describes the gap between procurement assumptions and the operating reality of governed access.

This pattern is typical in large application estates where standards like SCIM cover only part of the landscape. When integration work becomes permanent, governance quality depends as much on lifecycle maintenance as on the original implementation.

Key questions

Q: How should IAM teams budget for identity connectors that need ongoing maintenance?

A: Treat every connector as a recurring operating expense, not a one-time project cost. Budget for change testing, endpoint breakage, schema updates, and re-certification of the integration itself. If maintenance keeps consuming more capacity than new onboarding, the programme needs redesign, not just more delivery funding.

Q: Why do identity connectors fail even when the application vendor says nothing changed?

A: Failures often appear when authentication requirements, entitlement schemas, or deprovisioning flows change upstream. The connector may still report success while the underlying data drifts out of date. That creates false confidence, which is why teams need validation against actual identity state, not connector status alone.

Q: What do teams get wrong about SCIM provisioning and deprovisioning?

A: They often assume the standard itself guarantees clean lifecycle execution. In reality, SCIM only standardises the interface. Security and IAM teams still need to decide how to version schemas, handle soft deletion, validate input, and protect the endpoint as a privileged administrative surface.

Q: How do you know whether identity governance is becoming a treadmill?

A: Look for the point where a growing share of next year’s budget is spent keeping existing connectors alive instead of extending governance to new applications. Stale syncs, repeated rework, and delayed onboarding are early signals that the programme is sustaining itself rather than expanding coverage.

Technical breakdown

Why connector-based identity governance drifts over time

Connector-based governance relies on a fixed mapping between the source system, the target application, and the identity model in between. That mapping degrades when vendors change authentication requirements, deprecate endpoints, alter entitlement schemas, or modify approval flows. The connector may still appear healthy while the underlying data becomes stale, which creates a dangerous gap between operational status and governance truth.

Practical implication: treat connector health as a live control surface, not a one-time implementation artifact.

How intent-driven automation changes the integration model

Intent-driven automation works at the application layer rather than through rigid API or schema assumptions. Instead of depending on a single version of an interface, it can read the state of the application and execute a goal-oriented workflow even when layouts or prompts change. That does not remove governance requirements. It shifts the control point from connector fidelity to verification, auditability, and approval design.

Practical implication: use intent-driven workflows only where you can verify actions, preserve evidence, and control credential exposure.

NHI Mgmt Group analysis

The connector fallacy is a governance assumption failure, not a tooling inconvenience. Identity programmes are often designed around the belief that integration is a bounded project with an end state. That assumption fails because applications, authentication methods, and entitlement models keep changing after go-live. The implication is that governance teams must stop measuring success by onboarding completion and start measuring it by sustained control quality across the application lifecycle.

Connector treadmill: This is the permanent operational cost created when every application-specific integration becomes a maintenance dependency. The article correctly identifies the economic shape of the problem: new applications arrive faster than old connectors are retired, and maintenance consumes the budget that was supposed to fund expansion. That means identity leaders are not just managing integration debt, they are managing programme throughput. Practitioners should treat connector maintenance as a standing operating model concern, not a project variance.

Standards reduce friction only when the estate is actually standardised. SCIM and similar protocols solve part of the problem, but partial implementation creates a misleading sense of maturity. In real enterprises, internal tools, legacy systems, partner portals, and paywalled SaaS still require custom handling, which means the long tail dominates the cost curve. The practical conclusion is that governance architecture must assume heterogeneity rather than retrofit a single standard across the whole estate.

Automation based on intent changes the failure mode, but not the accountability model. When a system operates applications directly, it can outlast layout or prompt changes that would break a brittle connector. But that only moves the control burden upward into evidence, approval, and continuous verification. The implication is clear: programmes adopting intent-driven automation must redesign governance around observable outcomes, not connector status.

Identity integration is becoming an ongoing lifecycle discipline, not a deployment milestone. The article points to the right strategic conclusion even if it frames it commercially. Identity governance now has to absorb the same lifecycle reality that NHI teams already face: access paths age, dependencies shift, and operational controls decay unless they are continuously managed. Teams that budget for perpetual maintenance will outlast teams that budget for implementation only.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a deeper lifecycle view, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Connector maintenance is now part of identity governance maturity, not a delivery edge case. Teams that still budget only for implementation will keep inheriting the treadmill problem, because the operational cost arrives after go-live and compounds across the estate. For practitioners, the signal is to shift from project accounting to lifecycle accounting before the backlog becomes unmanageable.

Intent-driven automation changes how governance teams think about control boundaries. If the workflow operates the application directly, the real question becomes whether the organisation can verify every action and preserve evidence at the same level of detail as a traditional connector. That makes action-level auditability and credential containment the control points that matter most.

The broader signal is that identity programmes are converging with the same lifecycle reality already visible in NHI governance. Applications, service accounts, and automated workflows all age, drift, and demand continuous oversight, so the winning operating model is the one that treats change as constant rather than exceptional.

For practitioners

• Rebase the integration budget on lifecycle cost Separate initial connector build cost from annual maintenance, testing, and rework. If the maintenance line is growing faster than onboarding capacity, the programme is already absorbing connector debt rather than reducing it.
• Inventory applications by integration fragility Classify targets by schema volatility, authentication change frequency, and the need for custom logic. Use that inventory to prioritise which applications should move away from brittle connectors and which require tighter operational oversight.
• Measure governance drift, not just connector uptime Track entitlement sync failures, stale access records, and delayed deprovisioning alongside technical uptime. A healthy connector that produces outdated identity data is a control failure, not a success.
• Require verification for every automated change If automation reads or updates application state, force read-back validation, action-level audit logging, and explicit approval for sensitive steps. This is especially important when credentials are hidden from the automation layer.

Key takeaways

• The connector fallacy is that application integration ends after deployment, when in reality it becomes a standing lifecycle obligation.
• Identity governance can look healthy on dashboards while entitlements drift underneath, which makes verification more important than connector uptime.
• Teams that budget for maintenance, validation, and rework will govern more applications than teams that budget only for implementation.

Key terms

• Connector treadmill: The connector treadmill is the repeating cycle in which new application integrations are added more slowly than existing ones need maintenance. In identity governance, this creates a permanent backlog and shifts budget from expanding coverage to preserving fragile integrations.
• Governance Coverage Drift: Governance coverage drift is the gap between the access estate an organisation believes it controls and the access estate actually present across applications and identities. It emerges when discovery is incomplete, integrations lag, or review data does not reconcile cleanly to real entitlements.
• Intent-driven automation: Intent-driven automation is a control model where an operator states the desired outcome and the platform executes the necessary steps within defined boundaries. In resilience operations, this requires approvals, logging, and revocation controls so delegated action remains governed.

What's in the full article

Opnova's full blog covers the operational detail this post intentionally leaves for the source:

• How Opnova frames the economics of custom connector maintenance across disconnected application estates
• The article's practical rationale for intent-based application operation versus rigid connector logic
• The section discussing why LLM-generated code reduces build time but not ongoing integration drift
• The vendor's own view of how governance evidence, approval gates, and verification should be layered around automation

👉 Opnova's full post expands on connector maintenance debt, integration drift, and the case for intent-driven workflows

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.