View SaaS apps & employee activity
Overview
Use the reports in the Push admin console to understand which SaaS applications employees are using at work, and to identify security risks such as:
Weak passwords
Reused passwords
Lack of MFA protection
Suspicious mail rules
Unused or risky third-party integrations
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 SaaS estate, 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:
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 protection and suspicious mail rules created by employee accounts.
The Push browser extension provides visibility into SaaS applications that your employees access with a username and password, as well as any security risks associated with these logins such as a weak or reused password.
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, and OS.
Ability to export the list to csv.

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

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
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.

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.

Click on a SaaS entry to view the security findings for that app, and which employees have an account for that app.
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.

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.
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.
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.

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.

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.

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.

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.

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.

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.