Michael Narehood
You do not need a SIEM to notice a stolen password, leftover IMAP, or an admin in a browser nobody recognizes. You need a weekly look at Entra ID sign-in logs — the place Microsoft already records every attempt into your Microsoft 365 tenant.
This is the five-minute version: high-signal checks, not a dashboard nobody opens. If you still have password-only accounts, turn on MFA first. If you have Entra ID P1, put the baseline in Conditional Access instead of relying on a weekly review to block bad sign-ins.
Where to look
In the Microsoft Entra admin center, go to Entra ID → Monitoring & health → Sign-in logs. Microsoft’s overview is Sign-in logs in Microsoft Entra ID. Open a row and use the tabs — Basic info, Location, Device info, Authentication details, and Conditional Access — documented in sign-in log activity details. If you use Conditional Access, the same event shows which policies applied: view applied Conditional Access policies.
Do filter the last seven days (or last 24 hours if you are catching up after vacation). Do not export everything into a spreadsheet and call it a program.
Retention is short on a default tenant. Microsoft’s Entra data retention table currently stores sign-ins for seven days on Microsoft Entra ID Free and 30 days on P1 or P2. Many Microsoft 365 Business Premium tenants include P1; a week of history is usually licensing, not a broken portal. Miss a week on Free and those rows are gone unless you routed them to Azure storage, Azure Monitor, or another supported destination first.
1. Failed MFA and interrupted sign-ins
Filter Status to Failure and Interrupted. Interrupted means the sign-in needed another action or control decision — such as MFA, Conditional Access, or user interaction. Do not assume every interrupted event proves that the password was accepted; open the event details.
Look for:
- One user with a burst of MFA failures or abandoned prompts
- Admins in that list (treat those first)
- The same IP hammering several accounts
Do call the person if it looks like them fat-fingering Authenticator after a password change. Do not ignore a spray of prompts they did not start. Open Authentication details on a sample row so you see which method was tried, not just that it failed. For privileged accounts, repeated push prompts are another reason to move toward phishing-resistant MFA.
2. Success from odd countries (and “impossible” travel)
Filter Status to Success. Scan Location. You know your office, home towns, and usual travel. A successful sign-in from a country nobody visits is the check. Two successes for the same user a few minutes apart from distant cities is the same check with a louder alarm.
Microsoft is explicit that IP-to-location is best effort. VPNs, cellular carriers, and cloud egress can land far from the laptop.
Do ask whether they were on the office VPN, a hotel network, or a new ISP before you declare an incident. Do not skip this filter because location is messy. A success from a region you have never served, especially after failed MFA, is still worth a password reset and session revoke. If it is clearly hostile, stop the weekly pass and move into incident response.
3. Legacy authentication
Add the Client app column (or filter) and look for the old mail stack: IMAP, POP, SMTP AUTH, Exchange ActiveSync from unknown devices, and anything labeled basic / legacy. Those protocols often skip modern MFA even when the rest of the tenant is locked down.
Do identify the mailbox and the device (a copier that still SMTP-auths, an old phone mail profile, a line-of-business app). Do not leave “we’ll modernize it later” on a shared mailbox that can send as finance. Either move it to a modern client or block the protocol on purpose and watch the log go quiet.
A handful of leftover legacy rows every week is a configuration problem. A sudden new IMAP client on a user who never had one is a compromise problem.
4. New device or browser on an admin
Filter to your privileged accounts — Global Administrator, Exchange/SharePoint/User admin, and the people who can reset MFA. For those users, open Device info: browser, OS, managed/compliant flags, and whether the device looks like last week’s laptop.
Do expect a new browser after a PC replacement or a first sign-in on an enrolled work phone. Do not shrug at a Global Admin success from a consumer Windows install, a random Chrome profile, or an unmanaged device. Confirm with the admin, then revoke sessions if the story does not match.
If you have Conditional Access, the Conditional Access tab on that same event tells you whether the policy you think is protecting admins actually evaluated. “Not applied” on an admin sign-in is a policy-design finding, not a trivia item.
5. Consent to a new enterprise app
Sign-in logs show apps being used. New consent lives next door in Entra ID → Monitoring & health → Audit logs. Microsoft documents the exact audit activities in View activity logs of application permissions: Consent to application, Add delegated permission grant, and Add app role assignment to service principal. Also review Add service principal events, then glance at Enterprise applications for anything added that you did not deploy.
Do match the app to a person, an owner, its granted permissions, and a business reason. Do not treat “someone clicked Accept on an OAuth prompt” as harmless. Broad Graph permissions and no accountable owner are the problem. If the app is junk or over-privileged, revoke consent the same day. For approved business SaaS, force SSO where the service supports it so identity ownership is explicit.
Bottom line
Five filters, once a week, in the Entra admin center: failed and interrupted MFA, successful sign-ins from places you do not expect, leftover legacy clients, admin device and browser changes, and new app consent. That is not a SOC. It is the cheapest way to notice identity trouble before the mailbox forwarding rule appears.