Notifications
Clear all
Topic starter
12/06/2026 9:22 pm
TL;DR: Fewer than 7% of applications support SCIM, and most on-premises or private apps still resist federation, leaving manual identity execution as the default for many lifecycle tasks, according to Cerby. The app gap is structural, so IAM teams need governance models that assume disconnected systems will persist rather than disappear.
NHIMG editorial — based on content published by Cerby: why the app identity gap will not go away
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.
Questions worth separating out
Q: How should organisations manage applications that cannot support SCIM or federation?
A: They should treat those applications as permanent exceptions, not temporary gaps.
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.
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.
Practitioner guidance
- 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.
- Treat custom connectors as durable control debt Track every bespoke integration by app version, endpoint dependency, owner, and break/fix history.
- Make procurement a governance control point Require identity standards support, lifecycle APIs, and revocation capability in application buying criteria and contract language.
What's in the full article
Cerby's full blog post covers the operational detail this post intentionally leaves for the source:
- How the article breaks down vendor incentives around SCIM and user management APIs
- The specific ways on-premises and private applications resist federation and automation
- Examples of brittle custom connector maintenance and why they fail over time
- The infographic-linked breakdown of hidden costs from manual identity execution
👉 Read Cerby's analysis of why the app identity gap will not disappear →
App standards gaps: what it means for IAM and lifecycle teams?
Explore further
12/06/2026 11:23 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity automation breaks down where app standards never arrive
