When you manage identity for a 900-person company across six years, your Okta tenant becomes a graveyard.
Former employees' integrations. Tools that were evaluated and rejected but never fully disconnected. Acquired company SSO configs that were supposed to be temporary. SCIM provisioning jobs running against APIs that no longer exist, silently erroring out on every sync. Apps with 400 assigned users where the last login was fourteen months ago.
Nobody deprovisioned any of this intentionally. It just... accumulated.
The problem with leaving zombie integrations in place isn't just aesthetic. It's a security surface area you're not managing. An active integration to a decommissioned vendor still has credentials. A SCIM job in error state might be silently failing to deprovision departed employees. An "orphaned" app with no IT owner doesn't get reviewed when you update your security policies.
How I Built the Auditor
The tool takes your Okta tenant data (exported via the Okta API or manually assembled) and runs it through a risk scoring engine that evaluates each integration on four dimensions:
Usage recency. When did anyone last log in through this integration? No logins in 90 days is a flag. No logins ever is a critical finding. A $40k/year enterprise contract with zero recorded Okta logins means either people are bypassing SSO (which is its own problem) or nobody is using the tool.
SCIM health. Is SCIM provisioning enabled? Is it in an error state? Active SCIM with errors means your provisioning is broken — new hires aren't getting accounts, or departed employees aren't getting deprovisioned. Either is a problem.
Assignment hygiene. Apps assigned to 0 users and 0 groups are almost always zombie integrations. They're connected, they're consuming a slot in your integration count, but nobody is using them through Okta.
Name-based signals. A crude but effective heuristic: integrations with "admin," "legacy," or "test" in their name are more likely to be problematic. It's not definitive, but it's a useful first-pass signal for where to look.
Each integration gets a 0–100 risk score. Critical (60+), High (40–59), Medium (20–39), Low (0–19). The output is a prioritized remediation list — not just "here are your risky integrations" but specifically what to do about each one.
What We Found
When I ran this against our actual Okta tenant:
- 34 integrations with no Okta logins in the past 90 days. 12 of those had no logins ever recorded.
- 7 SCIM jobs in active error state. Three of those were for tools we'd actually deprecated — the SCIM job was still trying to sync to a dead API endpoint.
- 19 integrations with zero user or group assignments. Connected, active, no users.
- 4 integrations named something like "test-saml-2023" or "legacy-sso-migration" that were clearly never cleaned up.
Total: 64 integrations flagged for review out of roughly 300. About 21% of the tenant was either zombie, broken, or actively misconfigured.
That's not unusual. Security teams are always chasing active threats; Okta hygiene is the kind of quiet technical debt that builds up over years.
The Remediation Process
The tool outputs a CSV with one row per flagged integration, including the recommended action (disable, investigate, fix SCIM config, update ownership). I used that as the input to a four-week cleanup project:
Week 1: Disabled the zero-login, zero-user integrations. Low risk of impact; if anyone complained, we'd re-enable and investigate.
Week 2: Fixed the SCIM error states. Three were genuinely dead (deprecated vendor) and got fully disconnected. Four needed API credential rotation.
Week 3: Investigated the high-usage apps with no recorded Okta logins. Two turned out to be legacy SAML apps where users had bookmarked the SP-initiated login URL that bypassed Okta. That's a shadow SSO situation — users were authenticating directly with the vendor, not through Okta, which meant no centralized deprovisioning. Fixed by enforcing IdP-initiated SSO and disabling the SP-initiated endpoint.
Week 4: Ownership assignment. Every integration now has a named IT owner in a custom Okta attribute. Unowned integrations get escalated to the CISO dashboard.
Running It Yourself
The tool has a demo mode with 20 sample apps — you don't need Okta credentials to kick the tires. If you want to run it against your actual tenant, you'll need an Okta API token with okta.apps.read scope and the ability to export your apps list.
The code is on GitHub. The risk scoring logic is configurable — if your org has different thresholds for what counts as "stale" (maybe 180 days instead of 90), that's a single config value.
The thing I'd say to anyone who's been at a company for more than three years: run the audit. Whatever you find will not surprise you exactly, but the scale of it might.