Disconnected Apps: The #1 Source of Orphaned Accounts (and How to Fix It Fast)

Imagine this scenario: 

Your IT team just finished a successful Okta deployment. Single sign-on (SSO) is working beautifully, automated provisioning is humming along, and you finally have the centralized identity control you’ve been working toward for months.

Then reality hits during your first post-deployment audit. Greg from Marketing left three weeks ago, and while his Okta access was properly revoked, he still has active accounts in Slack, Asana, and two AI tools adopted by the team last quarter.

Lisa from Engineering’s contract ended last month, but she’s still showing up as an admin in GitHub and three other development tools. 

This discovery kicked off two weeks of manually checking every application to build a comprehensive offboarding checklist—exactly the kind of painful, repetitive work that’s consuming more IT time each quarter.

The uncomfortable realization? 

Even with a perfectly implemented identity provider (IdP), 30-40% of your application portfolio remains completely disconnected from your centralized security controls. 

These disconnected apps include everything from contractor-heavy tools like Slack and GitHub to the explosion of new AI-based SaaS tools your teams are adopting. Thus, they create massive blind spots in your identity governance.

Disconnected apps lack support for critical identity and security standards, including Security Assertion Markup Language (SAML), System for Cross-Domain Identity Management (SCIM), OpenID Connect (OIDC), and application programming interfaces (APIs) that enable centralized identity management. 

The real impact hits where it hurts the most:

• Security gaps: 53% of breaches involve orphaned accounts that should have been deprovisioned
• Manual burden: IT teams spend 2+ hours per week just on manual identity cleanup
• Hidden costs: Companies typically discover 200-2,000 unused licenses in their first disconnected app audit
• Compliance risks: Audit failures often trace back to incomplete access visibility.

To be clear, your identity infrastructure is not broken. It’s just incomplete. While you’ve secured the front door with Okta, dozens of side doors remain wide open, each creating security risks and draining valuable IT time through manual management.

The anatomy of disconnected apps

You’ve probably encountered these apps without realizing they had a name. Disconnected apps, also called non-standard, non-federated, or unmanaged applications, are any applications that cannot integrate with your central IdP for authentication and access management.

The common characteristics of disconnected apps that you'll recognize are:

• Authentication happens locally within the app, not through your IDP
• No SSO integration, forcing users to maintain separate credentials
• Missing support for enterprise identity standards (SAML, OIDC, SCIM)
• Independent user management requiring direct admin access
• Isolated security policies that don't sync with your central controls
• Manual onboarding and offboarding processes that eat up IT time.

Now, the question isn’t whether you have disconnected apps. It involves understanding why they’ve become such a persistent part of every IT environment, despite your best efforts to centralize everything.

Why the market pushes back: The economics and reality behind disconnected apps 

Disconnected apps aren’t due to negligence—they’re a byproduct of market dynamics.
 

They’re the inevitable outcome of competing market forces that consistently prioritize speed and cost over enterprise security. Understanding these forces explains why this problem persists and why traditional “just integrate everything” approaches often fall short in practice.

1. Vendor priorities

The proliferation of disconnected applications stems from fundamental market dynamics that favor rapid deployment and user experience over enterprise security capabilities. 

Most SaaS vendors, particularly those targeting the small-and-medium-sized (SMB) market initially, face a strategic choice between building core functionality that drives adoption and implementing enterprise security features that serve a smaller, more complex customer segment. 

Strategic resource allocation

While SAML implementation isn’t technically complex for most modern applications, vendors often delay enterprise security features as part of deliberate market segmentation strategies. 

Development teams focus on user-requested features that drive broad market adoption, while enterprise security capabilities are reserved for higher-tier offerings or delayed until there’s sufficient enterprise customer demand to justify the investment in sales processes, customer support, and compliance frameworks that enterprise features require. 

The adoption-security gap

Modern workplace tools increasingly follow a bottom-up adoption pattern, where individual users or teams discover productivity tools and drive organizational adoption before IT involvement. This creates a predictable sequence: 

1. Employees discover and adopt SaaS tools that solve immediate productivity needs.
2. These tools lack enterprise security infrastructure but become business-critical.
3. IT inherits responsibility for securing apps meant for individual or small team use.

ChatGPT illustrates this pattern clearly: Released in November 2022, it became essential for knowledge work across countless organizations within months. 

OpenAI introduced SSO support approximately a year later with ChatGPT Enterprise and Team workspaces, but by that time, organizations were already managing hundreds of individual accounts. 

This rapid adoption timeline, from launch to gaining critical mass in less than six months, outpaced the typical enterprise feature development cycle.

This pattern repeats across the SaaS landscape. Tools gain organizational traction faster than enterprise security features can be developed and deployed, leaving IT teams to bridge the gap through manual account management while waiting for vendor roadmaps to catch up with business reality.

2. The “SSO tax”

The "SSO tax, " a term coined by frustrated IT buyers, describes the significant price premium many SaaS vendors charge for enterprise identity features. While the term reflects genuine customer frustration with pricing structures, the reality involves complex economics that affect both vendors and customers trying to implement comprehensive identity management.

The price isn’t right 

Enterprise tiers that include SSO and SCIM capabilities often cost 2–5x more than standard plans—and in extreme cases, up to 50x more. This markup stems from the added cost of infrastructure, dedicated support, security certifications, and compliance investments. 

Some vendors even hide SSO pricing behind “Contact Us” enterprise plans, making basic identity features financially inaccessible for many organizations.

Thus, vendors bundle SSO with other enterprise capabilities, which means that organizations have to pay for unwanted features to access basic identity integration. This particularly impacts mid-market organizations that lack enterprise-level budgets but face enterprise-level security challenges.

The hidden cost burden

Organizations that can't afford enterprise tiers face operational trade-offs that extend beyond direct licensing costs:

• Manual account management consuming valuable IT resources
• Increased security exposure from human error in access management
• Higher help desk volume from password-related issues
• Compliance gaps from inconsistent access controls.

Stitchflow research shows the true cost of managing disconnected apps extends far beyond licensing fees. Manual provisioning takes an average of 7 hours per employee, with deprovisioning requiring even more time. Studies indicate 68% of security breaches stem from human errors in these manual processes.

The "SSO Wall of Shame" documents extreme pricing disparities across popular business tools:

• HubSpot charges a 6300% markup for SSO features.
• Monday.com requires a 286% price increase for enterprise security.
• Slack demands a 72% premium for SCIM provisioning.
• Notion restricts SSO to enterprise tiers, charging 88% more than the base plan.

3. Legacy or Homegrown Systems

Legacy applications represent a different category of disconnected app challenge entirely. Unlike modern SaaS tools where vendors choose not to implement security features, these systems often cannot support modern identity standards due to fundamental technical limitations. 

They predate the widespread adoption of modern identity standards or serve specialized functions where retrofitting integration proves prohibitively complex, forcing IT teams to maintain manual processes indefinitely.

The modernization dilemma 

Many organizations rely on business-critical systems that were built before SAML and SCIM became industry standards. These applications typically function perfectly for their intended purpose but lack the technical architecture necessary for seamless identity integration. 

While modernization is theoretically possible, the cost and complexity often exceed what organizations can justify, particularly when the core system meets operational needs effectively.

Industry-specific complications

Specialized sectors face additional hurdles that extend beyond typical integration concerns. Healthcare organizations manage electronic health record (EHR) systems with strict HIPAA requirements, medical device management platforms with specialized access controls, and patient portal systems that balance accessibility with privacy. 

Financial services encounter similar complexity with challenges, such as treasury management systems with complex authentication needs, trading platforms requiring rapid access without compromising security, and risk management tools with regulatory audit requirements.

The common thread across these scenarios isn’t necessarily technical impossibility, but rather the economic and operational reality that comprehensive modernization projects compete with other business priorities while manual identity management provides a workable, if inefficient, interim solution. 

How do organizations deal with the disconnected app problem?

To combat the security risks and operational drag of disconnected applications, organizations have historically relied on few strategies that can be bucketed into three categories. Understanding these approaches and their inherent limitations is critical for developing a truly comprehensive identity governance strategy.

1. The authentication modernization approach

Many IT teams gravitate toward authentication modernization as their first line of defense against disconnected apps. This strategy focuses on forcing disconnected applications to comply with modern identity standards. By using middleware, identity gateways (e.g., Keycloak, EmpowerID), or custom reverse proxies, this approach intercepts an application's login process and routes it through a central identity provider.

The goal is to extend the reach of an organization's primary identity provider. In theory, this approach standardizes the login experience with SSO, enforces crucial security policies like multi-factor authentication (MFA) and device trust, and reduces the number of separate passwords employees must manage. For auditors, it brings more authentication events under a single, visible umbrella.

While beneficial for centralizing logins, this approach falls short of comprehensive identity management in several critical ways that become apparent once you’ve invested the effort to implement it. 

• Fragile and complex implementation: Each application requires a unique and often brittle integration. These custom "wraps" or proxy configurations are prone to breaking whenever the underlying application is updated. What starts as a one-time integration project becomes a continuous support commitment. 
• Incomplete coverage: Authentication modernization is ineffective for many types of applications, including local desktop tools, complex on-premises systems, and any application without a standard web-based login flow. It leaves a large portion of the application portfolio completely unmanaged, defeating the goal of comprehensive coverage.
• Limited deprovisioning capability: This is the most critical gap. An authentication gateway can block a user from logging in, but it cannot deprovision the account. The user's identity, access rights, and data remain active within the application—creating orphaned accounts that are invisible to IT and pose a serious security risk.
• Persistent shadow IT risk: The approach only works for known applications. If a department purchases a new SaaS tool without informing IT, it becomes a case of shadow IT, remaining entirely invisible and disconnected from any security controls.

2. The SaaS management platform (SMP) approach

The SMP approach utilizes platforms that aim to provide a centralized dashboard for an organization's SaaS portfolio. These tools integrate with HR systems and use application APIs to automate user provisioning, track software usage, and monitor spending.

SMPs promise a unified view of the SaaS environment, helping organizations optimize costs by identifying unused licenses and automating onboarding and offboarding workflows for supported applications. 

By integrating with HR systems, they can trigger access changes based on an employee's role or employment status, providing a clear audit trail for compliance.

The SMP approach works particularly well for organizations with standardized SaaS portfolios where most applications offer robust API connectivity. They work well when managing cost optimization, usage analytics, and workflow automation across API-enabled applications. 

However, the effectiveness of this approach is fundamentally tied to API availability, which is the very thing disconnected apps lack.

• The "API-or-bust" problem: SMPs work best with modern, API-first SaaS applications. They offer little to no native control over truly disconnected, legacy, or homegrown applications, which often represent the highest risk.
• Coverage gaps in hybrid environments: Because they are API-reliant, SMPs create a false sense of security. The dashboard may look clean, but it is blind to any application that cannot be integrated, leaving significant gaps in governance.
• Manual work remains: To compensate for the blind spots, IT teams must resort to manually exporting and uploading CSV files to track unsupported apps. This defeats the purpose of an automation platform and reintroduces the risk of human error and stale data.
• Partial automation: Even for applications with APIs, connectors can be limited in function, only automating a subset of the required user lifecycle management tasks. Some integrations provide comprehensive lifecycle management, while others may only support basic provisioning or limited user attribute synchronization, requiring supplementary manual processes.

3. The manual and ad-hoc automation approach

This approach represents the default reality for most organizations attempting to bridge the gap between formal identity management systems and the practical needs of managing disconnected apps. 

The ad-hoc and/or manual approach ranges from purely manual processes that involve using spreadsheets and ticketing systems (e.g., ServiceNow, Jira) to track access to "do-it-yourself" automation using scripts (e.g., PowerShell) or workflow tools (e.g., Zapier, Power Automate). 

These workflows are typically triggered by an event, such as "when a user is terminated in the HR system, run a script to remove their account from a specific application."

This approach offers some genuine advantages that explain its widespread adoption. It is highly flexible and requires little upfront investment. 

It also allows IT teams to tackle the most urgent problems first and create highly customized workflows tailored to their unique environment. In addition, it can be used to fill the gaps left by more formal systems.

While practical for small-scale tasks, this approach is not a scalable or secure governance strategy because of the following reasons:

• Inherently brittle and unscalable: Custom scripts and workflows are notoriously high-maintenance. They can easily break due to minor changes in an application's UI, an API update, or a change in an HR process. As the number of applications grows, this web of custom scripts becomes an unmanageable liability.
• No system of record: While these solutions often work effectively in practice, they do not provide a unified dashboard for visibility or auditing. It is nearly impossible to prove to an auditor that all necessary deprovisioning steps were completed successfully. Leadership is left with no true insight into the organization's security posture.
• Risk of false confidence: Custom workflows can report that a deprovisioning task was "sent," but verifying that the account was removed within the application often requires additional manual checking. If that manual step isn’t taken, it creates a dangerous gap between perceived security and reality.
• The inevitable reversion to manual: When a script fails or an edge case isn't covered, the process reverts to a manual ticket or a spreadsheet entry. This ensures that manual, error-prone work never truly disappears and institutional knowledge is often lost when a key administrator leaves.

The need for a paradigm shift in identity management

The traditional approaches to managing disconnected apps—whether through authentication modernization, SaaS management platforms, or manual processes—share a fundamental limitation: they tackle the problem one application at a time. This app-by-app methodology made sense in an era when organizations adopted new software gradually and could afford the time to properly integrate each tool into their identity infrastructure.

However, the modern workplace has fundamentally changed:

• AI and automation tools are being adopted at unprecedented rates, often faster than vendors can implement enterprise security features.
• The "bring-your-own-app" culture means employees are using dozens of tools IT may not even know about.
• Rising "SSO tax" costs make proper integration financially unfeasible for many applications.
• Traditional integration approaches can't keep pace with the speed of modern business.

This new reality demands a different approach—one that provides immediate, comprehensive visibility and control across an organization's entire application portfolio, rather than slowly building coverage one app at a time.

Such a situation played out at Turing, an AGI (artificial general intelligence) infrastructure company accelerating global innovation by enabling enterprises to design, train, and deploy advanced AI systems and applications. 

With 700 employees and 3,000+ contractors, including 14 Tier-1 sensitivity apps, their IT team faced a big challenge. Manual deprovisioning across multiple IdPs (Okta for employees, Google Workspace for contractors) was consuming their small IT team’s capacity while creating serious compliance and security risks.

Rather than attempting to solve the problem app-by-app, Turing adopted a comprehensive approach by deploying Stitchflow to provide immediate visibility across their entire application portfolio. 

Within 90 days, they were able to close 312 offboarding gaps across Tier-1 apps, reclaimed 150+ idle licenses for $60K in annual SaaS savings, and freed up a full FTE of IT time for higher-value activities.

The key insight from Turing’s experience is that comprehensive coverage delivered faster results and better security outcomes than traditional incremental approaches ever could.

Ready to understand the true scope of your disconnected app challenge? 

Start by getting a complete inventory of your application portfolio and understanding its impact on your security posture.

Join Stitchflow’s free pilot and connect all your apps in just 30 minutes—including those without APIs. In four weeks, you’ll get a full audit of your IT environment, revealing hidden accounts, unused licenses, and compliance gaps across your stack. 

Stitchflow delivers quantified, app-by-app business value and clear, actionable recommendations—like downgrading unused Figma seats or deleting orphaned Google accounts. All insights integrate with your workflows, so you can remediate fast and stay continuously compliant.