CAS (Central Authentication Service or Cloud Access Security) may generate suspicious-login alerts when it detects unusual access patterns. Use the steps below to determine whether a specific alert represents a legitimate user login or potentially unauthorized access.
Step 1: Collect all alert details
Start by gathering as much information as possible from the alert so you can compare it with your logs and with what the user reports.
- Full username or account identifier shown in the alert, including any tenant or account context.
- IP address reported in the alert.
- Exact date and time of the login attempt, including the timezone, and any alert time window (for example, a 30-minute window).
- The system or application that was accessed (name of the product or service).
- Any known details about the user, such as their usual location and permission level (for example, a low‑privilege user based in Australia).
- A screenshot or copy of the alert message and any related log snippets, if available.
- Explicit permission, if required by your processes, to access the affected account so logs can be pulled and reviewed.
With these details available, you can review audit and authentication logs and correlate the activity with the account’s configuration and other local information.
Step 2: Verify the alerted identity
Next, confirm that the identity reported in the alert matches the expected account owner and that the account itself is known and valid.
- Confirm the email address or username in the alert matches the actual account owner.
- Check whether the account’s role or permission level (for example, Account Administrator or low‑privilege user) aligns with the type of activity reported.
If the alerted email or username does not match any known account, or if the role does not fit the observed activity, treat this as a signal to investigate further using your incident response procedures.
Step 3: Confirm directly with the account owner
Whenever possible, validate the alert by asking the affected user about the activity.
- Share key alert details with the user, such as the timestamp, application, and originating IP address (including information about it being unfamiliar, if applicable).
- Ask whether they performed the login during that time window and from that location or network.
If the user confirms they logged in as described, treat the alert as a legitimate login and mark or close the alert as resolved. If the user does not recognize the activity, or explicitly denies performing the login, follow your organization’s incident response procedures for suspicious logins.
Step 4: Review authentication and security logs
If you cannot confirm directly with the user, or you need additional assurance, review the relevant logs for the time window of the alert.
- Locate relevant events: Use the user identifier, originating IP, and alert time window to find matching authentication or security events.
- Check authentication outcomes: Review whether the login attempts were successful or failed.
- Verify authentication method: Confirm whether multi‑factor authentication (MFA), if configured, was completed successfully for the login.
- Confirm account role and context: Review whether the account’s identity and role (for example, Account Administrator) explain the activity observed in the logs.
If the logs show a successful login by the expected user or role from a plausible IP and time, and MFA was completed as expected, you can treat the alert as a legitimate login. If the logs show failed authentication, missing or unknown MFA events, or other anomalies, continue investigating according to your incident response process.
Step 5: Check recent credential and session state
As part of your validation, consider any recent changes to the account and its current session state.
- Check whether there were any password changes or other credential modifications at or near the alert time.
- Verify whether the user is currently logged in or whether the session has already ended.
If the alerted email matches the account, there are no unusual credential changes around the alert time, and the user is no longer logged in, the activity is more likely to be legitimate. Use the alert’s IP and timestamp or time window to correlate with access logs if you need further confirmation.
Step 6: Follow your incident response procedures when uncertain
If the user cannot be reached, does not confirm the activity, or you observe anomalies in the logs, treat the alert as potentially unauthorized.
- Continue collecting evidence such as timestamps, IP information, MFA events, and activity logs for the account.
- Follow your normal investigation or incident-response procedures for suspicious logins, such as escalating to your security operations team, suspending the account, or performing further forensic checks, according to your policy.
By consistently applying these steps, you can distinguish legitimate user logins from suspicious or unauthorized access attempts when CAS raised a suspicious-login alert.