TL;DR: An API-first developer ecosystem can extend identity security by letting teams build, certify, and distribute integrations across disconnected, legacy, and SaaS applications, while also exposing how much governance depends on connector quality and lifecycle discipline, according to Saviynt. The real issue is not extensibility itself, but whether JML, approvals, and access controls remain enforceable once integrations move into a shared marketplace model.
At a glance
What this is: Saviynt's developer ecosystem article argues that app onboarding can scale through APIs, connectors, and a shared marketplace, but governance must keep up with how those integrations are built, certified, and reused.
Why it matters: Identity teams need to track how marketplace-style integration models affect lifecycle control, certification, and access governance across legacy, SaaS, and disconnected applications.
By the numbers:
- The marketplace currently features over 400 apps and solutions.
Context
Application onboarding becomes a governance problem when integrations are no longer one-off builds but shared assets that can be reused, distributed, and certified across the estate. In this model, identity governance has to follow the connector, not just the target application.
The article is about API-first extensibility for identity governance, with a strong focus on disconnected applications, lifecycle management, and approval workflows. That matters because onboarding speed often improves faster than control inheritance, especially when legacy and SaaS applications are mixed in the same integration layer.
Key questions
Q: How should teams govern reusable app connectors in an identity programme?
A: Treat reusable connectors as governed assets, not convenience code. Each connector should have an owner, a review path, a security check, and a clear retirement process. If the same integration is reused across multiple apps or business units, the organisation also needs version control and change approval so control assumptions do not drift as the connector spreads.
Q: Why do marketplaces make app onboarding harder to control?
A: A marketplace separates development from consumption. That creates a gap where a connector can be built, certified, and reused in ways that exceed the original assurance boundary. The harder problem is not technical publication, but proving that approval, ownership, and lifecycle controls still apply after distribution.
Q: What breaks when disconnected apps do not support modern provisioning?
A: Lifecycle governance breaks first. Joiner, mover, and leaver events may stop flowing cleanly into the target system, so access changes rely on file imports, custom connectors, or manual handling. That raises the chance of stale access, missed deactivation, and incomplete certification because the identity signal no longer reaches the app consistently.
Q: How do teams know if app onboarding is actually governed?
A: Look for evidence that each integration has an owner, a certification state, a version history, and a deactivation path. If apps can be onboarded quickly but cannot be retired or revalidated with the same discipline, governance is incomplete. The useful test is whether the onboarding process still works when the integration must be changed or removed.
Technical breakdown
API-first application onboarding and connector reuse
An API-first identity platform exposes programmable interfaces, SDKs, and frameworks that let developers create connectors, automate onboarding flows, and extend functionality beyond built-in integrations. That changes application onboarding from a fixed-product exercise into a governed build-and-distribute model. Once connectors become reusable assets, the control question shifts from whether an integration exists to whether it was built, tested, and approved under consistent lifecycle rules. Practical implication: treat connectors as governed artifacts, not just technical shortcuts.
Practical implication: govern connectors as lifecycle-managed assets, not ad hoc integration code.
How marketplace distribution changes approval and certification
A marketplace introduces a second trust boundary after development. The article describes certification for use-case validation, design, and security, which means the governance model must separate what a developer can build from what an organisation can safely consume. That distinction matters because a shared app catalog can make distribution easy even when the underlying approval lineage is weak. Practical implication: define clear release gates for marketplace apps and connectors before they are widely adopted.
Practical implication: certify marketplace apps before consumption, not after adoption.
JML and lifecycle control across disconnected applications
Disconnected applications often lack modern authentication or provisioning standards, so onboarding and offboarding rely on connectors, file ingestion, or alternative control paths. The article's examples show why joiner, mover, and leaver events must still map cleanly into target systems even when the app itself cannot speak modern identity protocols. Without that mapping, lifecycle control becomes inconsistent across the estate and access certification loses completeness. Practical implication: verify that lifecycle events still drive create, update, and deactivate actions in every connected app.
Practical implication: confirm that lifecycle events still reach legacy and disconnected apps.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Connector governance is now part of identity governance. Once integrations are packaged, shared, and reused through a marketplace model, the connector itself becomes a governance object. That means review, certification, and lifecycle control can no longer stop at the target application. The practitioner implication is that integration sprawl must be managed as identity governance sprawl.
Marketplace distribution creates a control inheritance problem. A certification process can validate one build, but it does not automatically validate every downstream deployment, reconfiguration, or resold variant of that integration. The article illustrates the gap between developer creativity and operational accountability. Practitioners need to assume that reuse changes the assurance boundary.
Joiner, mover, and leaver discipline is only as strong as the least capable application. The article's disconnected app examples show that lifecycle orchestration fails when legacy and SaaS systems do not accept the same identity signals. If create, update, and deactivate actions diverge by app type, governance becomes uneven by design. The operational conclusion is that onboarding architecture should be measured by offboarding fidelity as much as by connection speed.
Identity onboarding is shifting from connector count to governed distribution. The notable change is not simply more integrations, but a broader ecosystem in which apps can be built, certified, shared, and consumed at scale. That favours programmes that can track provenance, approval state, and lifecycle enforcement across the connector chain. The practitioner takeaway is to evaluate whether the programme can govern reuse, not just integration volume.
API-first extensibility does not remove governance friction, it relocates it. The friction moves from one-off implementation effort to ongoing control over use-case validation, approval workflow integrity, and entitlement data quality. In identity terms, the programme is now accountable for the whole integration supply chain. Practitioners should treat each shared app as a governance dependency, not a convenience feature.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Connector provenance becomes a programme-level control point: once integrations are shared and reused, teams need to know who built them, who certified them, and who can retire them. That makes connector lineage just as important as application ownership in identity governance.
The operational risk is not limited to missing onboarding. It also shows up when offboarding, certification, and entitlement ingestion depend on different integration paths for different app classes, which is where governance gaps usually surface first.
Where this model is strongest, developers can extend identity controls without bypassing them. Where it is weakest, the marketplace becomes a distribution layer for inconsistent assurance rather than a control layer for application onboarding.
For practitioners
- Define connector governance standards Set a required review path for any new connector, extension, or marketplace app before it is promoted for wider use. Include design review, security validation, ownership, and a revocation path so the integration can be retired when the business need changes.
- Map lifecycle events to every target app Check that joiner, mover, and leaver events create, update, and deactivate access in each connected application, including disconnected and legacy systems. Where the app cannot accept modern provisioning, document the compensating control and the residual risk.
- Separate build approval from consumption approval Do not assume a connector that is valid for development is automatically valid for production distribution. Require a second approval step for marketplace publication, reselling, or internal reuse so certification remains tied to the actual deployment context.
- Track entitlement ingestion quality Verify that entitlement files, connector mappings, and imported user data remain accurate as applications are onboarded at scale. Poor ingestion quality undermines access certification and makes identity governance decisions less reliable.
Key takeaways
- The article frames app onboarding as a governance problem, not only a development problem, because reusable connectors change how identity control is inherited.
- Marketplace-style distribution raises the bar for certification, ownership, and lifecycle enforcement across legacy, disconnected, and SaaS applications.
- The practical test is whether joiner, mover, and leaver events still reach every connected app with enough fidelity to support access governance.
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 addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Shared connectors and partner apps create third-party identity dependencies across the onboarding chain. |
| NHI-01 — Improper Offboarding | Lifecycle control fails when disconnected apps cannot be cleanly deactivated or removed. | |
| Recommendation — Review third-party connectors as trusted dependencies and remove any integration that cannot prove its governance. Verify every onboarding path has a matching offboarding path for users, accounts, and integrations. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on account creation, update, and deactivation across many application types. |
| Recommendation — Apply account management controls so every connected app can create, update, and disable access consistently. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity governance depends on consistent entitlement handling during onboarding and certification. |
| Recommendation — Enforce entitlement governance so onboarding, certification, and access revocation remain consistent across apps. | ||
Key terms
- Application Onboarding Management: Application Onboarding Management is the workflow used to register new applications into an identity or governance platform with the right controls from the start. It helps teams collect basic application data, apply standard settings, and extend identity features later without rebuilding the onboarding process.
- Connector Governance: Connector governance is the control of integrations that let an AI system reach data, tools, and downstream services. It matters because the security boundary is often the connector, not the model itself, and weak connector control expands both access and blast radius.
- Lifecycle Management: Lifecycle management is the process of creating, reviewing, rotating, and retiring identities and their secrets in a controlled way. For NHIs, it is essential because stale credentials, orphaned accounts, and incomplete offboarding are common paths to long-lived exposure and unauthorised access.
- Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org