Skip to main content
Our philosophy is to only alert when it matters. Alert fatigue is a real security risk because it makes the real alerts look like all the others.
Petra alerts on one thing: a real account compromise. An attacker got into a user’s M365 account and is actively in there. That’s it. We don’t alert you on anything else.

​
When Petra sends a notification

Petra only sends notifications for time-sensitive events, the ones you’d want to act on right now. Notifications route through whatever channels you’ve configured (email, SMS, phone call, Teams, Slack, PSA ticket, webhook). Configure them in Incident Notification Methods. Notifications fire for:
  • Live compromises. An attacker is actively in the account right now. Alerted immediately.
  • Compromises uncaught before Petra. The Scan lookback found a historical compromise on a tenant you just onboarded. Alerted on publish so you can review and clean up any leftover artifacts.
Notifications do not fire for:
  • Leftover persistence on a previously-remediated incident. The original compromise has already been remediated and the account is no longer accessible to the attacker, but an artifact (like an inbox rule the attacker disabled but didn’t delete) is still present. These show up on the incident page for cleanup but don’t alert you. See Leftover Persistence.
  • Previously remediated compromises with no active attacker in the account. The attacker is already out, so there’s nothing time-sensitive to alert on. The incident still appears on the incident page for your records.

​
What Petra does not alert on

  • Inbound phishing emails. A phish landing in a user’s inbox is not a compromise. Petra retracts phish once an account compromise is detected, but the inbound delivery itself is not an alert. To pull a phishing campaign from multiple tenants, see Cross-Tenant Phish Removal.
  • Link clicks. A user clicking a phishing link is not a compromise. Most clicks don’t lead to stolen credentials, and most stolen credentials don’t lead to account access because of MFA.
  • Password leaks and sprays without compromise. Attackers constantly try leaked passwords. Microsoft and Petra see these all day. If the attempt fails or is stopped by MFA, the account is not compromised.
  • Failed logins. Failed login attempts are background noise at internet scale. Alerting on them buries real incidents under volume. See our research on why failed-login alerts don’t work.
  • Logins from unexpected locations. IP geolocation is unreliable. Mobile carriers geolocate across states, backbone carriers geolocate wrong, VPNs route through arbitrary exit nodes. Petra doesn’t alert on location alone, and we recommend against travel allowlists: see why travel allowlists cause more harm than good.
  • Microsoft datacenter logins. Microsoft routes traffic through its own datacenters for Exchange, SharePoint, Teams, and many service clients. Tesla vehicles, IoT devices, and Microsoft service apps all show up as datacenter logins. Almost always benign: see what’s up with all that “impossible travel” and when a Tesla looks like an attacker.

​
”I think Petra missed something”

Petra ingests more M365 signal than most other tools and takes a holistic view of an account before deciding whether it’s compromised. Most other tools flag on individual events (a login from an unfamiliar location, a failed MFA prompt, a click on a link) even when those events are benign on their own. We correlate across the full picture, which is why the same event that pages you from another tool often doesn’t page you from Petra. So when another tool alerts and Petra doesn’t, the usual explanation is travel, mobile carrier geolocation, a VPN, a Microsoft datacenter IP, or a password spray that got stopped at MFA. You know your environment though. If you believe a user has been compromised and Petra hasn’t alerted, run through the checks in Is A User Compromised? to triage the login logs yourself.

​
The attacker stole the password but Petra didn’t alert

If an attacker has a user’s correct password but MFA blocks them, they did not get into the account. That is not a compromise. There is no active attacker to lock out, nothing to remediate in-session, and nothing time-sensitive to alert on. Petra does not alert in this case by design. The user’s password should still be reset, since it’s known to attackers, but the account itself is not compromised. To confirm this is what happened, walk through the login logs using Is A User Compromised?. The short version: look for an MFA challenge from an unfamiliar IP with no successful login following it.

​
FAQs

​
Why haven’t I received any alerts from Petra yet?

One of two things:
  1. Petra hasn’t found any active attackers in your tenants. This is the most common answer, and it’s a good sign. We only alert on real compromises, so a quiet inbox means the tenants we’re monitoring are clean.
  2. You haven’t set up your incident notification methods. Petra only sends notifications through the channels you’ve configured (email, SMS, call, Teams, Slack, PSA, webhook). If none are set up, there’s nothing to send to. Go to Incident Notification Methods to configure them.
If you want to confirm notifications are wired up correctly, run a Fire Drill from the same settings page. It sends a test notification through every configured channel.