Out of the Box Alerts help you proactively monitor risk, application usage, credentials, and vendor incidents without complex setup. This guide explains how to access, configure, and manage alerts effectively.
User Permissions
Only users with Default Admin or Client Admin permissions can manage alerts.
Accessing Alerts
Partner Level
- From the left panel, click Alerts
- Select Manage Alerts to configure alerts
- Select Triggered Alerts to view alert activity
Client Level
- Open a client tenant
- Navigate to Alerts from the left panel
- Use Manage Alerts and Triggered Alerts as needed
Understanding the Alerts Interface
Manage Alerts
Create, edit, and control alert configurations.
Key fields:
- Alert event name
- Conditions
- Status (Enabled/Disabled)
- Destination
- Delivery delay
- Date created / updated
- Last triggered
- Created by
Triggered Alerts
Monitor alert activity and take action.
You can view:
- Status (Triggered or Acknowledged)
- Alert type
- Incident details
- Timestamp
Pro tip: Regularly review and acknowledge alerts to track what’s been actioned and avoid duplicate work.
Creating a New Alert
- Go to Manage Alerts
- Click Create Alert
- (Partner level only) Choose to apply the alert to all clients or a specific client
- Select an Alert Event and Alert Type
- Configure conditions (if applicable)
- Set the destination:
- Select users
- Or enter an email address
- Choose a delivery delay:
- Immediately → Sent as soon as triggered
- Daily → Grouped and sent daily
- Weekly → Sent Mondays
- Monthly → Sent first Monday
Triggered alerts always appear immediately in the UI regardless of delivery setting.
- Save the alert
Pro tips:
- Start with pre-configured alerts for immediate value
- Use delivery delay (daily/weekly) to reduce notification noise
- Route alerts to the right stakeholders using user selection
Managing Alerts
Use the Actions menu on each alert:
Edit
- Update destination
- Adjust delivery delay
Clone
- Duplicate an alert
- Modify conditions as needed
Enable / Disable
- Control which alerts are active
Delete
- Remove alerts no longer needed. Note: previously triggered alerts are retained, but their conditions will no longer be available once the configuration is deleted.
Available Alert Events & Types
Applications
New App Discovered
Triggers when a previously unseen application is actively used within the environment, identified through SSO logs, browser activity, or other ASM discovery methods. Enables rapid identification of shadow IT, shadow AI and unauthorized SaaS adoption.
Identity Management Integration
Failure (Microsoft / Google)
Triggers when the Microsoft Entra or Google Workspace identity management integration fails, disrupting users sync and security event ingestion from the identity provider.
Login
New Shared Credentials Found in Use
Triggers when multiple users are newly detected using the same login credential to access an application, which poses security risks and makes it difficult to track individual user activity.
New Service Credentials Found in Use
Triggers when a new service account credential (e.g., support@example.com, administrator@example.com) is detected in the environment, helping identify unmanaged access, reduce security risk, and maintain access governance.
New Personal Credentials Found in Use
Triggers when a new account using a non-organization domain (e.g., personal email) is detected in the environment, helping identify shadow IT and reduce risk from non-work software usage.
User Login Activity Detected (Client level only)
Triggers when a selected user accesses an application in the selected lifecycle stage, helping detect unauthorized or post-offboarding activity.
Pro tip: Set this alert for users being offboarded who should no longer access applications, or for users transitioning between applications to detect usage of unapproved applications.
Users
New Application Usage by User
Triggers when an individual user begins using an application in the selected lifecycle stage, helping track adoption patterns and potential unauthorized software usage.
New Application Usage with Tag by User
Triggers when an individual user begins using a tagged application for the first time, helping track adoption patterns and potential unauthorized software usage.
Pro tip: Tag applications that should not be used and set up this alert to be notified when a user starts using them.
Vendor Incident
Any App
Triggers when a vendor reports a security incident, data breach, or vulnerability impacting an application, enabling rapid risk assessment and mitigation.
Discovered App
Triggers when a vendor reports a security incident, data breach, or vulnerability impacting an application that has been discovered in your environment, enabling rapid risk assessment and mitigation.
Understanding the “New Shared Credentials Found in Use” alert
What the alert means
The New Shared Credentials Found in Use alert is generated when Auvik SaaS Management detects multiple users accessing the same application with the same login credential.
The alert details may identify:
- The users associated with the activity
- The application that was accessed
- The credential or account identifier associated with the shared use
A shared credential can make it difficult to determine which individual performed an action and can reduce the effectiveness of access reviews, offboarding, and role-based access controls.
Why the alert does not show the password
For security reasons, alert details should not be used to retrieve the password value or a complete history of every use of the credential. Auvik SaaS Management does not collect passwords or other sensitive credential contents.
The alert is intended to identify a potential shared-account risk and direct an administrator to the appropriate application, identity, security-log, or credential-management records for further review.
How to investigate the alert
An administrator or security team member can:
- Review the alert details to identify the affected users, application, and credential or account identifier.
- Open the relevant application or user details in Auvik SaaS Management.
- Review available Security Logs for activity associated with the application or users.
- Review the organization’s password vault or credential-management system, if one is used, to determine where the shared credential is stored and who has access to it.
- Compare the activity with the application’s own audit or sign-in logs.
- Confirm whether the shared account is intentional, such as a documented service account, or whether it represents an unmanaged shared user account.
Auvik Security Logs and user activity data may have retention limits. If older activity is required, review the application’s native audit logs or the organization’s security-information and event-management system.
AAA, RADIUS, and TACACS logs are generally not required to investigate this SaaS Management alert. Use those logs when investigating shared credentials used for network-device authentication rather than shared credentials used to access SaaS applications.
Recommended remediation
If the shared use is not intentional:
- Create individual user accounts for the affected application.
- Assign access through roles or groups rather than a shared login.
- Remove unnecessary access to the shared account.
- Rotate the shared credential through the application administrator or approved password-management process.
- Update integrations, scripts, or automation that depend on the old credential.
- Confirm that users can access the application with their individual accounts.
- Review the alert again after the change to confirm that new shared use is no longer detected.
Credential rotation and account changes should be performed by an application administrator or security team member with the required permissions.
If the shared credential is intentional, document its purpose, owner, approved users, storage location, and review schedule. Consider treating service accounts separately from human user accounts where the application supports that distinction.
Best practices
- Use unique credentials for each user whenever the application supports them.
- Use role-based access control to assign only the permissions each user requires.
- Store shared service credentials in an approved password vault.
- Avoid using shared human accounts for routine access.
- Review application audit logs and security logs during access reviews.
- Rotate shared or service credentials according to the organization’s security policy.
- Use the alert to identify and document exceptions rather than disabling it without investigating the underlying account use.