TL;DR: Disconnected apps now make up a large share of enterprise SaaS and legacy estates, and the source article argues that identity teams still govern them with tickets, spreadsheets, and manual password updates, creating visibility, compliance, and remediation gaps according to Cerby. Manual control can extend coverage, but it does not scale as a durable identity governance model.
At a glance
What this is: This is an analysis of disconnected apps and the governance gap they create when identity tools cannot natively control them.
Why it matters: It matters because IAM, IGA, and PAM teams still need auditable access control, review, and offboarding for apps that sit outside standard identity integrations.
By the numbers:
- Around 65% of SaaS applications used within organizations are not approved by IT.
Context
Disconnected apps are applications that do not support modern identity standards such as SAML or SCIM, so they cannot be governed through the usual identity integrations. In practice, that means identity teams face a control gap when applications are business-critical but still sit outside the normal request, review, and offboarding flow.
The article argues that this is not only a SaaS issue. Legacy on-premises systems, portals, and homegrown applications create the same governance problem, which turns disconnected access into a broader IAM and IGA blind spot rather than a niche integration challenge.
Cerby’s core claim is that many organisations fall back to manual governance for these apps, and that the result is incomplete compliance, audit friction, and avoidable risk exposure.
Key questions
Q: What breaks when disconnected applications are not brought into identity governance?
A: When disconnected applications sit outside the identity system, provisioning, review, and offboarding become inconsistent and hard to evidence. Access can persist after business need ends, audit trails fragment, and incident response loses confidence in who still has access. The result is not only operational drag but a control gap that weakens the entire identity perimeter.
Q: Why do disconnected apps create operational and compliance risk?
A: Disconnected apps create risk because the organisation cannot consistently prove who has access, who owns the account, or whether access was removed at the right time. That makes compliance evidence incomplete and turns routine identity changes into manual work that consumes time, slows delivery, and increases the chance of mistakes.
Q: How should security teams govern applications that do not support SCIM or SAML?
A: They should treat those applications as lifecycle exceptions that still need full governance, not as exempt systems. The practical response is to inventory them, prioritise the highest-risk apps, and use resilient automation or controlled manual evidence for provisioning, deprovisioning, and recertification. The objective is consistent access control, not connector completeness.
Q: Should organisations prioritise remediation of disconnected apps before expanding access governance?
A: Yes, if the disconnected estate is large or contains sensitive systems, because adding more workflow around a blind spot only scales the gap. Teams should first establish inventory, ownership, and revocation paths, then expand review and approval coverage.
Technical breakdown
Why disconnected apps evade standard identity controls
Disconnected apps are systems that lack the identity interfaces that IAM and IGA products expect, especially SAML, SCIM, or usable APIs. Without those integration points, the identity plane cannot automatically provision, deprovision, certify, or synchronize entitlements. The control problem is not that the apps are inherently insecure, but that their governance path sits outside the normal automation layer, forcing identity teams to treat them as exceptions rather than managed assets.
Practical implication: catalogue every app that cannot participate in your standard identity workflow and treat it as an explicit governance exception.
Why manual governance breaks at scale
Manual control usually means tickets for onboarding and offboarding, spreadsheets for access reviews, and emails for password updates. That approach can work for a small number of edge cases, but it does not create reliable entitlement evidence, consistent owner accountability, or repeatable remediation. The failure mode is operational drift: each manual step depends on a person, and each person introduces delay, inconsistency, and incomplete records into the identity lifecycle.
Practical implication: measure how much of your app estate still depends on human-run identity tasks, then assume that number understates the real governance gap.
How session control and credential rotation close part of the gap
When disconnected apps cannot be governed through native connectors, the remaining control surface is often the credential and the active session. Automating password rotation, MFA enforcement, session termination, and deprovisioning reduces residual access after access changes or reviews. This does not make the app native to IAM, but it does create a defensible control layer over accounts that would otherwise remain exposed after the initial governance event.
Practical implication: prioritise session termination and credential rotation for disconnected apps that carry elevated or persistent access.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
- Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
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
Disconnected apps create an identity governance boundary problem, not just an integration problem. If an application cannot speak the standards your identity stack expects, it falls outside the automated lifecycle that makes governance auditable. That means access control becomes partial by design, and the gap is structural rather than accidental. Practitioners should treat the disconnected-app boundary as a governance domain of its own, not a leftover exception.
Manual identity management cannot be the durable operating model for disconnected estates. Tickets, spreadsheets, and email-based password handling can temporarily extend coverage, but they do not produce stable entitlement evidence or consistent offboarding assurance. The practical issue is not effort alone, it is repeatability. Identity programmes that depend on human memory and handoffs will always trail the pace of application sprawl.
100% governance coverage is the wrong success metric if the control model is still fragmented. Coverage claims matter only if review, remediation, and owner accountability are actually enforceable across the app estate. Disconnected apps force teams to confront the difference between nominal governance and governed operations. The real benchmark is whether identity controls remain enforceable after the app leaves the native integration path.
Disconnected app governance is becoming a core IAM maturity test. The organisations that can inventory, classify, and remediate these apps will have stronger control over access reviews, audit response, and joiner-mover-leaver outcomes. Those that cannot will keep discovering the same blind spot in every audit cycle. Practitioners should make disconnected apps a standing programme item, not a one-time cleanup exercise.
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.
What this signals
Disconnected-app governance is a lifecycle problem, not a single-control problem. The hard part is not merely finding these applications, but keeping ownership, access review, and offboarding aligned after business teams adopt them outside IT. That pushes IAM programmes toward lifecycle discipline across the whole estate, rather than assuming the native integration path will do the work.
Disconnected app coverage becomes the practical test of whether governance is real. If an organisation can only certify what is connected, it is governing the toolchain, not the application estate. The signal for practitioners is clear: inventory quality, owner accountability, and revocation assurance now matter as much as the identity platform itself.
For practitioners
- Inventory disconnected apps as a separate governance estate Build a distinct inventory for applications that lack SAML, SCIM, or usable API control, and record owners, admins, entitlement models, and lifecycle path for each one.
- Replace spreadsheet-based reviews with app-owner evidence Require each disconnected app to have a named owner who can validate entitlements, approve access, and confirm offboarding evidence during access certification.
- Automate password rotation for manual-control apps Set shorter credential lifetimes for apps that still depend on human-managed logins, especially where admin access or shared accounts remain in use.
- Add session termination to offboarding workflows Make session kill and credential revocation part of the same offboarding flow so disconnected apps do not retain residual access after a governance decision.
Key takeaways
- Disconnected apps create a governance blind spot because standard identity integrations cannot reach them, so access control depends on compensating processes.
- Manual tickets, spreadsheets, and password emails may extend coverage, but they do not produce reliable lifecycle evidence or repeatable remediation.
- The practical answer is to inventory disconnected applications separately, assign ownership, and enforce revocation, rotation, and session termination where native controls are missing.
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 NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Disconnected apps make offboarding fail when accounts and sessions remain outside native identity workflows. |
| NHI-05 — Overprivileged NHI | Manual governance often leaves disconnected app accounts with excessive standing access. | |
| NHI-07 — Long-Lived Secrets | Password rotation is central where disconnected apps rely on persistent credentials. | |
| Recommendation — Map disconnected-app offboarding to NHI-01 and verify every app has a revocation path. Review disconnected-app entitlements for excess privilege and remove access that is not explicitly required. Shorten credential lifetimes for disconnected-app accounts and rotate any long-lived secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing access permissions across applications the identity stack cannot reach directly. |
| Recommendation — Apply PR.AA-05 to ensure disconnected-app permissions are inventoried, approved, and reviewed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Manual password updates and rotation are a core control theme in the article. |
| Recommendation — Use IA-5 to manage disconnected-app authenticators with defined rotation and revocation processes. | ||
Key terms
- Disconnected App: A disconnected app is a business system that does not participate in the enterprise identity fabric and is managed outside central IAM workflows. Access is often granted locally, reviewed manually, and forgotten easily. These apps create governance blind spots because ownership, revocation, and evidence are fragmented across teams.
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
- 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 June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org