Is Monitoring SaaS Configuration Changes as Important as Monitoring Logins?

The exact approach depends on the application and its contractual requirements. Some SaaS vendors provide detailed audit trails and retention as part of the service, so duplicating every event in your own SIEM may not be necessary. In other cases, the platform only exposes audit data through an API or webhook, leaving the customer responsible for collecting and storing it. Either way, login monitoring alone is not enough; procurement and security reviews should establish what events are available, how long they are retained, and how they can be investigated later.

You’re not overthinking it. Identity logs show who authenticated, but they don’t show what happened afterward. A hijacked session or an over-privileged administrator could grant roles, disable controls, export data, or delete records without the identity provider revealing the actual activity. At minimum, high-risk administrative actions, permission changes, exports, and destructive operations should be monitored and retained. Salesforce Setup Audit Trail and Microsoft 365’s unified audit log are examples of the kinds of records worth collecting, especially because SaaS platforms may have limited default retention.

SaaS environments can be compromised through stolen sessions, access tokens, or third-party OAuth applications, even when authentication is protected by a central identity system. Those paths can let an attacker operate with someone else’s existing permissions. It’s worth evaluating SaaS Security Posture Management tools, but tooling shouldn’t replace basic controls such as least privilege, periodic access reviews, audit-log collection, and alerts for unusual admin or data-handling activity.