Third-party apps

Overview

Third-Party Apps is elba's organization-wide application inventory. It combines evidence from identity and direct application integrations, OAuth grants, email activity, Browser Security usage, privacy-safe AI account status observations, and installed browser extensions into one application record.

Every signal keeps its source and an explanation of how it was established. Browser activity is an observation, not proof that an account exists; email activity supports evidence of use; and only accounts or grants from a connected source are confirmed. Use this distinction to understand adoption without turning browser observations into access or remediation decisions.

Open the module for your Elba region:

• EU admin workspace
• US admin workspace

Navigate the workspace

The module has five tabs:

• Radar highlights the risks and inventory changes that need attention.
• Inventory lists detected applications, users, evidence, freshness, and organization policy.
• Issues tracks security issues and their remediation status.
• Playbooks contains available automation templates and your configured workflows.
• Sources shows the connections that supply application data.

The sources and actions available to your organization depend on its connected integrations and Browser Security deployment. Use the capability, freshness, and connection status shown in elba as the source of truth.

Use the Radar

The Radar contains seven current widgets:

• Risky usage for applications with risky permissions
• Critical & High risk CVEs for recently reported high-severity vulnerabilities
• Data Breaches for applications potentially affected by a reported breach
• Playbooks for configured workflows and available templates
• Discovered apps grouped by reputation status
• Shadow AI apps for AI applications that have not been explicitly approved
• Low adoption apps for applications with low user counts

Select See all on a widget to open the related filtered inventory. Use Export to download the Radar report when you need an offline review.

Reputation widgets use applications that elba has assessed. An organization-private application can still appear in Inventory while elba is matching it to the application catalog. It is marked Identification in progress, and its Reputation score shows Reputation score not yet available until a catalog profile is available.

Review the inventory

The Inventory table displays:

• Application, with its detection sources and identification status
• Reputation score, based on elba's automatically assessed catalog profile when one is available
• Access exposure, based only on verified connector evidence
• SSO adoption, when verified account evidence supports the calculation
• Users, deduplicated across current evidence, with browser users who were not recently detected shown separately
• Usage policy, which records your organization's approval decision

Search by application name or use the Usage policy and Reputation score filters alongside owner, source, hosting location, category, compliance information, CVEs, data breaches, AI classification, or risky permissions. Source filtering includes Browser Security sources.

How evidence is established

The Users view explains how each signal was established:

• Confirmed by a connected source: an account or OAuth grant reported by a connected source
• Supported by email activity: email activity that supports evidence of use but does not verify an account
• Observed in the browser: browser application usage, a browser-observed AI account status, or a browser-extension installation

The same person and application can have evidence from several sources. elba combines those signals under one user where they can be linked safely, while preserving every source, evidence type, first- and last-seen date, and whether the signal is current.

Browser evidence is current for 30 days after it was last observed. Older browser evidence remains visible as Not recently detected so an application does not disappear from history. Connector evidence is not aged out by this browser window; its own last synchronization date remains visible.

Application identity and automated catalog assessment

elba resolves applications using catalog identifiers accepted by its automated reviewer, such as exact source mappings and domains, never a display name alone. A high-confidence application that does not yet match the global catalog is kept as an organization-private provisional identity and marked Identification in progress. Its display name and safe application domain can support your investigation without exposing the private record to another organization.

Catalog assessment is performed by elba's automated enrichment and review pipeline; this status does not represent manual human approval. Your organization's Approved, Not approved, or Needs review policy remains a separate administrator decision.

Applications, suites, and standalone browser extensions appear in the default inventory. Signals classified as devices, operating systems, platform components, general websites, or ambiguous items are held outside the default inventory for classification instead of being presented as ordinary SaaS applications.

Reputation score

Elba maps the application score to four states:

• Trusted: 7 to 10
• Questionable: 5 to less than 7
• Untrusted: 0 to less than 5
• Reputation score not yet available: no score is available yet

The score is an investigation aid, not an approval decision. A private provisional application shows Reputation score not yet available until an automatically assessed catalog profile is available. Review the application, publisher, confirmed permissions, evidence, users, and business need before changing its policy.

Usage policy

Your organization can apply one of four policies:

• Not reviewed for a newly detected application
• Needs review for an application awaiting a decision
• Approved for an application your organization permits
• Not approved for an application your organization does not approve

The usage policy is separate from the reputation score and access exposure; elba does not blend them into one risk score. Changing an application to Approved prevents new issues from being created for that application. Review existing issues and your organization's policy before approving it.

An explicitly Not approved private application can be enforced by Browser Security only when elba has a safe registrable application domain. The application details explain when no enforceable domain is available.

Application details

Select an application to open its details. The panel has two tabs:

• About separates Application details, Reputation score, Access exposure, Observed users, and Usage policy. It also shows the available catalog assessment, risky permissions, breaches, CVEs, compliance, hosting, DNS information, and extension installations.
• Users shows linked users or unlinked connector accounts in Detected users and accounts, with detection sources, evidence types and explanations, first and last detection, freshness, authentication method, AI account status, and the actions actually supported for that evidence.

For supported AI tools, Browser Security reports the observed AI account status as Work account, Personal account, No account signed in, or Unknown. The canonical inventory can additionally display Work and personal accounts, but only when current work and personal evidence coexist for the same user and application. This combined status is computed by the inventory rather than reported by the browser, so Browser Logs cannot filter by it. All of these values remain browser observations: Work account does not mean that elba verified an application account. Detected AI account email addresses and domains, page content, tenant hostnames, and full URLs are not exposed in the inventory, Browser Logs, or public API.

Browser-only applications show Reputation score not yet available and No account access confirmed by a connected source. SSO adoption is unavailable until a connected source confirms account access. Browser-observed usage and extension rows do not offer account remediation. Only eligible connector-confirmed evidence can expose a supported distribute or revoke action.

The panel also lets you assign an owner, set business criticality, and update the usage policy.

Investigate issues

The Issues tab is the operational queue for detected account and permission risks. You can filter issues by member, group, source, status, dates, usage policy, application, publisher, category, hosting, compliance information, AI classification, reputation, risky permissions, CVEs, or data breaches.

Available bulk actions are determined by the source and issue state. They can include:

• Distribute issues to enrolled employees
• Ignore selected issues
• Revoke permissions where the source supports it

An issue is not automatically sent to an employee when it is detected. Distribution happens through an admin action or an active playbook.

Configure playbooks

Open Playbooks to select a template or create a workflow. The editor only offers triggers, conditions, and actions supported by the selected source. Depending on the template, a workflow can distribute permission-review issues or notify administrators about CVEs and data breaches.

Before activation:

1. Confirm that the intended source is connected and synchronized.
2. Review the trigger and every condition.
3. Configure exclusions or an allow-list when the source supports them.
4. Check who will receive the action and whether a notification is sent immediately.
5. Activate the workflow and monitor its run history.

Notification timing is controlled by the workflow and communication settings; there is no universal fixed weekly schedule.

Employee remediation

Distributed issues appear in the employee's Checklist. For a Third-Party Apps issue, the employee can:

• Ignore the issue and continue using the application.
• Revoke the permissions when the connected source supports direct revocation.

If a source connection has an error, actions that change the source can be temporarily unavailable. Administrators retain the issue history and can act from the Issues tab.

Recommended review workflow

1. Connect the relevant sources and wait for their initial synchronization.
2. Start with Radar to identify risky usage, vulnerable apps, breaches, Shadow AI, and newly discovered apps.
3. Open Inventory to review the application identity, evidence source, freshness, reputation score, access exposure, and business owner.
4. Set the application to Needs review, Approved, or Not approved according to your policy.
5. Use Issues for verified account- or permission-level investigation and supported remediation.
6. Add a playbook only after validating the intended audience, exclusions, and actions.