If your answer to "which third-party tools does this employee have access to" is "check Okta," you already know the problem. Okta shows you which applications are federated through SSO. It has no visibility into the Notion workspace someone was invited to directly, the analytics tool the marketing team is paying for on a credit card, the AI tool a developer signed up for with their work email, or the legacy system that was never connected to the IdP.

The complete answer to "who has access to what" across all third-party tools requires consolidating signals from multiple sources that each see a different slice of the access landscape.

Why SSO Alone Doesn't Give You Complete Access Visibility

SSO is the access control layer for the applications your IT team deliberately onboarded to the identity stack. When a user authenticates through Okta or Entra ID, those events are logged and visible. When access is revoked through the IdP, SSO-connected applications respond.

The gap is everything outside the SSO perimeter:

Shadow IT. Applications that employees or departments adopted without going through IT procurement. These tools never got configured in Okta; they authenticate independently. When the employee leaves, no IdP deprovisioning event affects them.

Direct-invite applications. SaaS tools like Notion, Figma, or Miro that allow team-level access through direct email invitations. The account exists in the application, not in the IdP. The account persists after the person leaves unless someone explicitly removes it.

Applications that don't support SSO at the tier you're on. Many SaaS tools require enterprise-tier licensing to enable SCIM or SAML. At lower tiers, they have their own authentication, which puts them outside IdP visibility.

Legacy and on-premises systems. Applications that were never federated to the modern IdP and authenticate through local accounts or legacy directory integrations.

Tracking employee access across all of these requires sources beyond SSO logs.

The Five Discovery Sources That Build a Complete Access Map

SSO and Identity Provider logs. Okta, Entra ID, Google Workspace, and JumpCloud all log authentication events. Connecting these to a discovery platform surfaces which applications federated users are authenticating to and when. This covers the formally onboarded application stack and provides last-login timestamps for activity analysis.

Direct application integrations. For applications with admin APIs — over 300 in a platform like Zluri's integration catalog — connecting directly to the application's API pulls granular data: specific user accounts, permission levels (not just application-level access but role and entitlement detail), last activity timestamps, and license assignment. This is more authoritative than SSO logs because it reflects the application's own user record rather than inferred state from authentication events.

Financial and expense system analysis. Corporate card transactions and expense reports in tools like NetSuite, Expensify, or Concur identify recurring SaaS subscriptions that were purchased outside IT procurement. The analytics tool that the marketing team is paying for on a shared card shows up as a recurring charge — and the charge provides the starting point for discovering that the tool exists and investigating who has access.

Browser and desktop agents. Lightweight extensions and agents deployed at the endpoint level track which URLs and applications employees actually access, regardless of whether the application is in the IdP, in the financial system, or in the integration catalog. This is the discovery mechanism that finds shadow IT and shadow AI tools — tools that never went through any formal channel but are being used. The agent sees browser traffic; an employee accessing an unauthorized AI tool with their work laptop generates a signal that surfaces the tool.

HRMS data. Workday, BambooHR, Personio, or similar HR systems provide the authoritative identity context: employment status, department, role, manager, and start/end dates. Cross-referencing application access records against HRMS data is what converts a list of active accounts into actionable findings — "this account belongs to someone whose employment ended 3 months ago" is the orphaned account finding that manual audits miss and automated cross-referencing catches.

How These Sources Get Stitched Together

Each data source sees a different portion of the access landscape, and they often overlap. A user may appear in Okta (as an authenticated SSO user), in a direct Salesforce integration (with their specific Salesforce permissions), and in browser agent data (with their actual usage frequency). For the same user, these three sources need to be reconciled into a single identity record rather than three separate entries.

Identity matching. The primary matching key is typically email address, with alias matching (checking alternative email fields) to catch cases where the same person has slightly different addresses across systems. For organizations where email addresses change (transfers between subsidiaries, name changes), a static employee ID from the HRMS provides a more reliable primary key.

Source precedence. When multiple sources provide overlapping data — application access status from both Okta and a direct integration — a precedence hierarchy determines which source is authoritative. Direct integrations generally take precedence over SSO for application-level data because they reflect the application's own record. SSO logs may be more current for last-login timestamps in some cases. The hierarchy is configurable per attribute rather than applied uniformly.

Activity vs. last-used distinction. Two metrics matter for determining whether access is still necessary:

Activity is the log of specific actions — login events, page views, feature usage — captured with timestamps from SSO, direct integrations, and browser agents. This tells you what the user has actually done in the application.

Last used is calculated from the most recent activity detected across all sources. A user whose last login was 120 days ago has a different access review priority than someone who logged in yesterday, even if both have the same role assigned.

The combination of these two metrics — what they've done and when they last did it — is what enables meaningful access reviews rather than flat lists of accounts to rubber-stamp.

What Complete Visibility Enables

Accurate offboarding. When an employee leaves, the offboarding workflow is pre-populated with every application in their access profile — not just the SSO-connected applications. Every tool discovered through financial analysis, browser agents, or direct integration is included in the deprovisioning scope. The orphaned accounts that auditors find (active accounts for users who left months ago) are the accounts that fell outside the SSO perimeter and were missed by IdP-based offboarding.

Access reviews with real context. Periodic access certification campaigns are meaningless if reviewers don't know whether users are actually using the access they're certifying. Surfacing "this user hasn't logged in for 90 days" alongside the access record gives reviewers grounds for a revocation decision rather than a blind approval.

License reclaim at scale. Dormant accounts — active access to applications that haven't been used recently — represent license spend with no business value. Automated identification of accounts inactive for 30, 60, or 90 days enables either automated reclaim workflows or targeted "Request to Forego" prompts that let users self-select out of licenses they're not using.

Continuous governance. Once the access map is built, automated rules that detect specific risk patterns can trigger immediate remediation: a suspended user account accessing a restricted application, an account appearing in a browser agent for a tool on the restricted list, a new expense charge for a SaaS tool not in the approved catalog. Continuous monitoring turns the access map from a point-in-time snapshot into a live governance feed.

Frequently Asked Questions

How do you find out which SaaS tools employees are using outside of SSO?

The most comprehensive approach combines three signals: financial/expense system analysis (to find tools purchased outside IT procurement), browser and desktop agents (to track actual application usage at the endpoint), and direct application integrations (to pull user records from the applications themselves). Each source covers a different slice of the access landscape that SSO logs don't reach.

What is shadow IT and how does it affect employee access tracking?

Shadow IT refers to applications adopted by employees or departments without formal IT approval or provisioning. Because these tools aren't connected to the IdP through SSO, disabling a departing employee's Okta account doesn't affect their shadow IT accounts. Discovery that surfaces shadow IT — through browser agents, financial transaction analysis, or direct application scanning — is the prerequisite for including these tools in offboarding and access review workflows.

What is the difference between "activity" and "last used" in employee access tracking?

Activity is the log of specific actions a user has taken within an application — login events, page views, feature usage — with timestamps. Last used is the most recent date of any activity detected across all discovery sources. Both matter for access governance: activity data provides usage context for access review decisions; last-used dates identify dormant accounts (inactive for 30+ days) that are candidates for license reclaim or access revocation.

How do you track access to applications that don't have APIs or SSO support?

For applications without APIs, browser and desktop agents capture usage at the endpoint level — they track which URLs and applications are accessed regardless of how authentication works. This covers the tool from a usage visibility perspective. For the access record in the application itself (which users have accounts, at what role level), manual processes — periodic CSV exports from the application administrator — may be required for the access review cycle.