The connector treadmill exposes the real cost of identity integration

At a glance

What this is: This is a blog post about why identity integration is never really finished, with the key finding that connectors create a lasting maintenance burden as target applications keep changing.

Why it matters: It matters because IAM, IGA, and NHI governance teams often budget for implementation but not for the ongoing connector lifecycle, which leaves coverage gaps, audit drift, and hidden operational cost.

Context

Identity integration is the work of connecting applications so access, provisioning, and governance can happen across systems that were never designed to fit together. The article's core claim is that this work does not end when the connector goes live; it becomes an ongoing maintenance obligation that expands as the application estate changes.

For IAM and IGA programmes, that changes the operating model. A connector that stops syncing entitlements, misses an MFA change, or breaks after a schema update can leave governance dashboards looking healthy while the underlying data is stale. The article frames that drift as a structural programme cost, not an exception.

Key questions

Q: How should IAM teams handle applications that never stay stable enough for a fixed connector?

A: Treat those applications as lifecycle-managed integration problems, not one-off projects. Prioritise the systems that change most often, assign ongoing ownership for connector upkeep, and accept that some applications will need a different automation approach if coverage is to remain current.

Q: Why do identity governance programmes spiral into long, expensive projects?

A: They spiral when manual discovery, schema mapping, review handling, and connector maintenance are treated as normal work rather than implementation debt. That creates a programme that consumes time and people just to stay functional, which is especially problematic when access decisions are increasing across cloud, SaaS, and non-human identities.

Q: What are the signs that connector-based governance is failing?

A: Look for connectors that still report healthy while entitlements stop syncing, audits uncover stale access data, or the team spends most of its time rebuilding existing integrations instead of onboarding new ones. Those are signs that control coverage is drifting.

Q: Should organisations replace brittle connectors with intent-driven automation?

A: Only where the maintenance burden of the connector is clearly greater than the governance value it delivers. Intent-driven automation can reduce fragility for changing applications, but it still needs evidence, approval gates where required, and continuous testing against the real estate.

Technical breakdown

Why custom connectors keep breaking

Custom connectors are fragile because they are written against one version of one interface, then left to survive as the target application changes around them. The article points to SSO enforcement, MFA prompts, API or endpoint deprecation, schema changes, and permission model shifts as common breakpoints. In IGA terms, the connector is part software asset and part control dependency, so every target change creates both functional failure risk and governance drift. The problem is not only failure at launch, but silent failure after launch when the connector still reports healthy while entitlements stop syncing.

Practical implication: Treat each connector as a maintained control surface, not a finished integration.

Why SCIM did not remove the integration burden

SCIM was intended to standardise provisioning, but the article argues that economics limited adoption more than engineering. Vendors often reserve deep integration capabilities for higher-tier pricing, so many enterprises still face a mix of custom connectors, partial standards, and paywalled functionality. That leaves legacy systems, internal tools, partner portals, and vendor-locked SaaS outside the standardised path. In practice, the standard exists, but the market incentives to implement it broadly do not, so teams inherit a long tail of bespoke maintenance work.

Practical implication: Assume a large portion of the estate will remain custom and plan governance capacity accordingly.

Why intent-driven automation changes the integration model

The article contrasts brittle connectors with intent-driven automation that operates applications directly, reading the interface and pursuing the desired outcome rather than depending on a fixed code path. That reduces dependence on a specific schema or UI state, which is why a layout change or new prompt does not break the workflow in the same way. But the author is explicit that this is not autonomous governance by itself. It still needs oversight, evidence, approval gates where needed, and continuous testing against the real applications in use. The value is less about replacing all connectors and more about reducing how many rigid integration points must be kept alive.

Practical implication: Use intent-driven automation where connector maintenance is consuming more effort than the governed task itself.

NHI Mgmt Group analysis

Connector lifecycle debt is the real identity integration problem: the hidden cost is not initial build effort but the continuous labour needed to keep integrations aligned with changing applications. That maintenance debt accumulates across each custom connector, turning IGA from a project into an operating model. Practitioners should judge integration programmes by lifecycle cost, not go-live success.

Identity governance metrics that ignore broken synchronization create false confidence: a connector can appear healthy while entitlement data silently drifts out of date. That is a governance failure, not just a technical glitch, because access review, certification, and audit evidence all depend on current source data. Teams need to treat stale sync as control degradation, not a minor incident.

SCIM is a partial standard, not a universal answer: the article correctly identifies that market incentives limit how widely standards are implemented and maintained. That means programme design cannot assume standard coverage as a baseline. The practical implication is that governance architecture must account for a mixed estate of standards, custom work, and long-tail applications that will never be simple to integrate.

Intent-driven execution narrows the connector treadmill but does not remove governance responsibility: the article's strongest point is that some tasks can be executed against the application state rather than a brittle connector contract. That changes the maintenance equation, but it does not eliminate the need for evidence, approvals, and continuous validation. The practitioner conclusion is that automation strategy should be chosen for lifecycle resilience, not just initial speed.

Identity programmes should budget for integration as a permanent control cost: the connector fallacy is assuming integration is an implementation line item rather than recurring operational expense. That assumption fails as soon as application estates, prompts, schemas, and authorisation models keep changing. The implication is that governance leaders must re-plan budget, staffing, and coverage targets around steady-state maintenance, not project completion.

From our research library:

• 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.
• Read next: Identity Security Programme Guide

What this signals

Connector lifecycle debt: the real cost of identity integration sits in keeping old work alive while new applications keep arriving. Programmes that do not explicitly fund maintenance will keep reallocating budget away from expansion and toward repair.

Standardisation helps, but only where the market actually adopts the standard. For the rest of the application estate, teams need a governance model that assumes a mixed environment of standards, custom connectors, and disconnected systems rather than a clean universal layer.

For practitioners

• Budget for connector maintenance as a recurring control cost Separate initial build effort from year-on-year connector upkeep, testing, and rework. The programme plan should assume that applications, schemas, prompts, and access rules will change after go-live.
• Classify silent sync failure as control drift Monitor for connectors that report healthy while entitlements, approvals, or identity attributes stop updating correctly. Treat stale governance data as an operational risk, not a dashboard issue.
• Prioritise applications with the highest maintenance load Rank integrations by rebuild frequency, change rate, and audit impact so the team focuses on the connectors consuming the most time and risk first.
• Use intent-driven automation where rigid connectors stall coverage Apply application-facing automation to disconnected systems when a fixed connector would require repeated rewrites every time the interface moves.
• Measure programme success by sustained coverage, not go-live Track how much of the identity budget goes to new integrations versus keeping old ones alive, because the balance reveals whether the programme is expanding or merely treading water.

Key takeaways

• Identity integration is not a one-time implementation task, because every connector becomes an ongoing maintenance obligation as applications and access models change.
• Governance programmes can look funded and still underperform when stale synchronization creates silent drift between policy and actual access state.
• The practical response is to budget for lifecycle upkeep, reduce dependence on brittle connectors where possible, and measure success by sustained coverage rather than initial go-live.

Key terms

• Connector lifecycle: Connector lifecycle is the full set of steps that covers creating, scoping, reviewing, rotating, and retiring integration accounts and add-ons. The lifecycle matters because integrations often remain active after business ownership changes, which creates hidden access and audit risk. Governance has to track the connector from birth to offboarding.
• Silent sync failure: A condition where an integration appears healthy while the underlying identity data is no longer updating correctly. In governance terms, this is especially dangerous because dashboards can show normal operation while certification and access data drift out of date.
• 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.
• 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.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.