New research: SaaS attacks that avoid EDR and network monitoring | Read more →

Ready to help

View SaaS apps & employee activity


Use the reports in the Push admin console to understand which accounts and SaaS applications employees are using at work, and to identify security risks such as:

  • Compromised passwords

  • Weak passwords

  • Reused passwords

  • Shared account credentials

  • Lack of MFA

  • Suspicious mail rules

  • Unused third-party integrations

  • Not using a password manager

You can use ChatOps to work directly with employees to fix issues as they arise. See: Configure ChatOps.

In order to gain a full inventory of your cloud identities and apps, you must perform both an API integration and the installation of the Push browser extension on employee browsers in your environment. They each play a role in providing full visibility:

  1. The API integration provides visibility into SaaS applications that your employees access via social login, such as Sign In with Google and Sign In with Microsoft, as well as third-party OAuth integrations they consent to. The integration also finds any security risks associated with these platforms, such as a lack of MFA and suspicious mail rules in employee inboxes.

  2. The Push browser extension provides visibility into accounts that your employees create and access with a username and password, including unmanaged and non-SSO accounts, as well as vulnerabilities associated with these accounts.

View SaaS usage details

The Employees and SaaS pages in the Push admin console provide an overview of SaaS apps in use in your organization from two different perspectives: at the level of the employee, and at the level of the app.

Prerequisites: In order to see complete data on SaaS usage, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace) and enroll employee browsers using the Push browser extension.

Employees page: Available in the left sidebar at Employees, this page shows a per-employee view into which SaaS a person uses. It includes the following details:

  • Employee name, email address, and (if available via the API integration or Gravatar) photo.

  • A count and list of the SaaS apps used by that employee.

  • Employee browsers used with the Push extension.

  • Recommended security improvements for their account, such as enabling MFA, improving a weak password, or changing a reused password to something unique.

  • Ability to filter by employee name, SaaS, browser, OS, browser extension status, and ChatOps status.

  • Ability to export the list to csv.

Employees page - docs - View SaaS activity

Click on an employee record to view the full list of SaaS apps and any recommended security improvements.

Employee record - docs - View SaaS activity

Securing findings can include:

  • Weak password

  • Reused password

  • Compromised password

  • Shared account credentials

  • Lack of MFA protection

  • Mail rules associated with the account that forward email to external recipients

  • Not using a password manager

The employee record view also shows you which browsers they use, the browser version, the Push extension version, and when the extension last checked in.

Browser profile pane - docs - View SaaS activity

SaaS page: Available in the left sidebar at SaaS, this page shows you an inventory of all SaaS apps in your environment discovered by Push. It includes the following details:

  • A table or tile view of all the SaaS apps discovered in your environment.

  • Security findings for each app, such as no MFA, shared account credentials, etc.

  • An entry for each app showing how many accounts use it, and whether it was discovered via the browser extension through username and password logins, or via API integration.

  • Ability to filter by app name, which employees use it, login types, and security findings.

  • Icons to represent if an app has been classified according to its sensitivity level and approval status.

  • Ability to set an owner for each app from the list of licensed employees.

SaaS page - table view - docs - View SaaS activity

Click on a SaaS entry to view the security findings for that app, and which employees have an account for that app.

Use the Sensitivity level field to classify apps that feature High, Medium, or Low sensitivity data or permissions. Use the Approval status field to classify apps that are approved or unapproved for use in your environment. Note that classifying an app does not trigger any actions in the Push platform; these categories are meant to support your record-keeping and risk assessment activities.

Use the Owner field to set a single owner for an app, selected from the list of licensed employees. The Owner field allows you to document who is responsible for an individual app, such as the primary administrator or team leader, to make communication about app management easier. Note that adding an owner does not trigger any actions in the Push platform.

View account security

Find security issues with employee accounts, such as weak and reused passwords, and identify whether accounts are protected by multi-factor authentication (MFA) on the Account security page, available in the left sidebar at Explore > Account security.

Prerequisites: In order to see MFA usage data, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace). In order to see password security data, you must enroll employee browsers using the Push browser extension.

Account security page - docs - View SaaS apps & activity

On this page, you can view the following details:

  • Whether an account is using social login or a password.

  • Whether a password is reused.

  • Whether a password is easily guessable.

  • Whether a password contains words found in a custom restricted word list.

  • Whether employees are sharing account credentials.

  • Whether an employee appears to be using a password manager, or is manually typing their passwords.

  • When an account for a specific SaaS app and employee was last used.

  • Whether the employee has registered for MFA on their primary work account (Google or Microsoft) as well as certain popular SaaS apps, and what authentication methods they use for MFA.

Understanding MFA data in Push

The Account security page reflects whether an employee has registered for MFA. With most platforms, users who register for MFA start getting prompted for MFA. However, with some platforms, such as Microsoft 365, users can register for MFA but an administrator still needs to enforce it before the user will be prompted. Refer to our blog post for some ideas on enforcing MFA with M365.

View third-party integrations

Review which third-party OAuth integrations users in your environment have consented to using the Third-party integrations page in the left sidebar at Use cases > Third-party integrations.

Prerequisites: In order to see third-party integrations, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace).

Insight into the third-party integrations in your environment is important for addressing risks like consent phishing, and identifying undesired privileged access granted to potentially malicious third parties.

On this page, you can view the following details:

  • A list of all the third-party integrations discovered in your organization.

  • Which platform an integration is linked to (Microsoft 365 or Google Workspace).

  • Details about each integration's risk characteristics.

  • How many users have consented to an integration and whether an admin has consented to an integration.

  • What permissions an integration has been granted.

  • Whether the app is verified by Google, Microsoft, or the Push team, or has not been verified.

  • When an integration was last used. Note that data for integration usage is collected at the time you complete an API integration. We don’t backfill usage data.

The risk characteristics that Push provides are:

  • User Delegated High-Risk Assets: Whether user-delegated permissions exist for high-risk assets such as email, calendar, and contacts.

  • Exposes Some Data For All Users: Whether the app exposes some data for all users.

  • Long Tail: Whether the app has a “long tail,” meaning it has permissions beyond a simple social login and is used by fewer than 3 users.

  • Social Login Only: Whether an app is used solely for social login.

Third-party integrations page - docs

Click on an integration to view more details:

  • What permissions the application has, and for how many users. Click on a permission to view the exact scope that a user has delegated.

  • Which specific users have consented to the integration.

  • Its reply URLs.

  • Its app ID.

Third-party integration details pane - docs

Delete third-party integrations

If you identify a third-party integration that is unused, unwanted, or otherwise problematic, you can remove it using the Push platform.

There are two ways to remove a third-party integration:

  • From the Push admin console

  • From a ChatOps channel message

For guidance on how to triage a problematic integration, refer to this Push blog post.

Deleting integrations from the admin console

To remove an integration from the admin console, go to Explore > Third-party integrations and then identify the integrations you wish to remove. Then use the Bulk actions > Delete integrations option to remove the selected integrations. You can also remove individual integrations by clicking on the three dots at the end of each row and selecting Delete integration.

Delete integrations - admin console bulk action - KB 10083

You’ll have the option to delete the integrations for all applicable users in the Google Workspace or Microsoft 365 instance integrated with Push, or only those users who are assigned a license on the Push platform.

Third-party integration deletion confirmation screen - KB 10083

Deleting integrations from a ChatOps message

You can delete integrations directly from a ChatOps message if you enable the ChatOps topic for SaaS notifications so that your security team can receive messages in your specified team channel.

Find suspicious mail rules

Attackers often use malicious mail forwarding rules to retain access to sensitive email once they have successfully phished an employee. Use Push to review externally forwarding mail rules and verify whether a rule has been created by the employee or a malicious third party.

Prerequisites: In order to find suspicious mail rules, you must complete an API integration with your work platform (Microsoft 365 or Google Workspace).

As soon as you complete an API integration with your work platform, Push scans employee inboxes for mail rules that forward to external domains and lists the results on the Suspicious mail rules page, available under Explore in the left sidebar of the Push admin console.

Mail rules page - docs

The left panel of the screen shows discovered mail forwarding rules, including whether they’ve been triaged yet and whether the rules are still in use. Click on a rule to see more details about it:

  • The name of the rule.

  • The external email address it forwards to.

  • Which platform it appears on (Google or Microsoft).

  • The rule owner.

  • When the rule was first seen by Push.

  • What the rule is configured to do.

  • A timeline of activity associated with the rule.

From the right panel, you can accept the rule and close the alert in Push, or mark it as suspicious. Push will automatically disable mail rules you mark as suspicious if they were created in Microsoft 365. Google Workspace does not support disabling mail rules.

Mail rules details pane - docs

You can use the ChatOps workflow for suspicious mail rules to automate outreach to employees to ask if they created a rule. ChatOps also allows your security team to receive messages if an employee marks a mail rule as suspicious so they can respond right away. See the ChatOps topic for suspicious mail rules for more information.

Curious about whether you should just disable external email forwarding for your organization? Check out our blog post for Push’s point of view.