Microsoft 365 security monitoring

Entra ID writes a sign-in log, keeps a user list, records which accounts have multi-factor authentication, and tracks your conditional-access policies. For a team without a SOC, the problem is not a lack of data — it is that nobody is reading it between the moment something looks wrong and the moment it becomes an incident.

XIBA connects to Microsoft Graph with read access and keeps watching, so a risky sign-in or an account that quietly lost MFA surfaces on its own instead of waiting to be noticed.

Read-only, on a schedule, with nothing installed in your tenant:

• The sign-in log — scanned for anomalies such as impossible travel and unexpected sign-in patterns.
• MFA coverage — which accounts have strong authentication and which do not, re-checked on a regular sweep so a gap is caught rather than assumed closed.
• The user and admin list, and the authentication methods registered against accounts.
• Conditional-access and policy posture, so a weakening change is visible.

A finding is only useful if it reaches someone. XIBA turns Microsoft 365 findings into incidents in one queue alongside your domains, infrastructure and service desk, and routes them by rules you set — on type, severity and keyword — to the Teams or Slack channels and email recipients you choose.

Everything administrative is written to an audit ledger: who changed what, when, and from which address.

The directory permissions XIBA needs are read permissions: the sign-in log, the user list, policies and authentication methods. It does not request access to mailboxes, files, calendars or message content.

Credentials are encrypted with AES-256-GCM using a key held outside the database, and once saved a secret is never returned to a browser. Every read and write is scoped to your organization — there is no shared queue or index across customers.