Topic starter
06/06/2026 11:07 am
TL;DR: Disconnected enterprise apps create an app gap that blocks SCIM, SAML, and OIDC-driven lifecycle automation, forcing manual provisioning and brittle custom connectors, according to Cerby. The governance problem is structural: access review, deprovisioning, and audit readiness cannot scale when identity standards are missing at the application layer.
Editorial analysis by NHI Mgmt Group, based on content published by Cerby: “Modernizing identity lifecycle management: How Cerby closes the identity automation gap”.
By the numbers:
- At the start of 2025, only 20% of monday.com’s applications were centrally managed through Okta via SAML or SCIM, according to Cerby.
- Barely six months later, that figure rose to 78% for monday.com applications managed through Okta via SAML or SCIM, according to Cerby.
- Cerby says nearly 200 applications that previously had no identity integration were connected to Okta via its network.
Key questions
Q: What breaks when enterprise apps do not support SCIM or OIDC?
A: Provisioning, deprovisioning, and access governance stop flowing through the normal identity plane, so teams fall back to manual work or brittle custom integrations.
Q: Why do disconnected applications create identity governance risk?
A: They create risk because the organisation cannot reliably see, certify, or revoke access through the same control plane used for integrated systems.
Q: How can teams tell whether identity lifecycle automation is actually covering the full app estate?
A: Look for the percentage of applications that are managed through the identity plane versus those that still require manual provisioning or manual revocation.
Practitioner guidance
- Inventory disconnected applications by control reach Classify apps by whether they support SAML, SCIM, OIDC, user management APIs, or none of the above, then mark the gaps where lifecycle policy cannot be enforced natively.
- Replace fragile one-off connectors with survivable automation Review custom integrations for ownership, dependency on specific endpoint versions, and failure handling, then retire the patterns that stop working when an app or API changes.
- Extend governance into on-prem and private apps Include private-network applications in joiner, mover, and leaver design so offboarding, role changes, and access reviews are not limited to internet-facing SaaS.
Bottom line: Disconnected apps create a structural lifecycle gap because standard identity protocols do not reach the full enterprise application estate.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 11:44 am
Disconnected-app governance is an access coverage problem, not an integration inconvenience. Identity programmes often assume that once IAM and IGA are deployed, lifecycle policy can be projected across the application estate. That assumption fails where apps do not support the standards those controls require. The practitioner conclusion is that coverage must be treated as a first-class governance metric, not an implementation detail.
A question worth separating out:
Q: Should organisations prioritise connector development or broader automation for disconnected apps?
A: Broader automation usually wins when app sprawl is large, because connector-by-connector builds do not scale and break when app interfaces change. Prioritise the approach that can reach the widest set of apps with the least maintenance burden, including private and unsupported systems.
👉 Read our full editorial: Extending identity lifecycle automation to disconnected apps