A non-interactive sign-in is an authentication performed on your behalf by an app or a token, without you typing a password or approving an MFA prompt. Microsoft Entra ID records these on a separate tab that most people never open, and that is precisely where a stolen session token quietly reuses your identity long after MFA was satisfied. If your monitoring only watches the interactive sign-ins the login screen produces, you are looking at a fraction of what actually authenticates against your tenant, and usually the least interesting fraction.
What is a non-interactive sign-in in Microsoft Entra ID?
Entra ID splits authentication events into distinct categories, and the sign-in logs default to showing you only the first one:
| Sign-in type | Who authenticates | What triggers it | MFA prompt? | Where it shows |
|---|---|---|---|---|
| Interactive user | The person, actively | Password plus MFA at the login screen | Yes, evaluated now | Sign-ins, "Interactive" (default tab) |
| Non-interactive user | An app or client on the user's behalf | Refresh or access token reuse, background mail sync, SSO to the next app | No, the MFA claim is already in the token | Sign-ins, "Non-interactive" (separate tab) |
| Service principal | An app as itself, no user | A client secret or certificate | Not applicable, no user | "Service principal sign-ins" tab |
| Managed identity | An Azure resource | An Azure-assigned identity | Not applicable | "Managed identity sign-ins" tab |
The interactive event is the one everyone pictures: you type a password, you approve a push, you are in. Everything after that is mostly non-interactive. Your mail client refreshing in the background, a token being exchanged for a new one, single sign-on carrying you into the next app. Each of those is a real authentication event Entra ID records, and on most tenants non-interactive events outnumber interactive ones by ten to fifty times.
Why are non-interactive sign-ins a security blind spot?
Two reasons, and they compound.
First, visibility. The Entra sign-in logs open on the interactive tab. Seeing non-interactive events takes a deliberate tab switch, and the richer report needs an Entra ID P1 or P2 license. On the free tier, sign-in logs are retained for only 7 days; P1 and P2 extend that to 30. If you have not exported logs to a SIEM, most of your authentication history has already aged out before anyone thinks to look.
Second, and more important: non-interactive sign-ins are where authentication happens without re-proving anything. The MFA claim already lives inside the token, so no prompt fires. That is the normal, intended behavior that keeps you from re-authenticating every fifteen minutes. It is also the exact property an attacker relies on.
How does token theft hide in non-interactive sign-in logs?
This is the mechanism behind modern MFA bypass. In an adversary-in-the-middle (AiTM) phishing attack, the victim really does complete the login, password and MFA included, on a proxy the attacker controls. The attacker captures the resulting session token. From that point on they do not need the password and they do not need to pass MFA again, because the token already carries a satisfied MFA claim.
When the attacker replays that stolen token, Entra ID does not see a failed login or a new MFA challenge. It sees a non-interactive sign-in, because from the platform's perspective an existing token is simply being used. The compromise leaves almost no trace on the interactive tab that most alerting watches. Microsoft's own guidance is blunt about it: give immediate attention to non-interactive sign-ins, especially from unfamiliar locations or devices. The account takeover is happening on the tab nobody opened.
What should you actually watch?
You cannot triage what you never surface, so start by making these events visible and durable:
- Export sign-in logs to a SIEM or Log Analytics. Do not rely on the 7 or 30 day in-portal window. Token theft investigations depend on non-interactive history you still have.
- Hunt non-interactive sign-ins for unfamiliar properties: a new IP, ASN, or country appearing shortly after a legitimate interactive login from somewhere else. That is impossible travel at the token layer.
- Turn on Continuous Access Evaluation (CAE) so revoking a session takes effect in near real time instead of waiting out the token lifetime.
- Enable Identity Protection risk detections and token protection to flag replayed tokens with anomalous properties automatically.
- Shrink the blast radius: fewer standing privileged sessions means fewer high-value tokens worth stealing.
The theme running through all of it is the same one behind token theft and MFA bypass generally. MFA proves who logged in once. The token is what actually carries access afterward, and the token lives in the logs you are not reading.
SecValley surfaces the identity posture behind this exposure across its Entra ID controls: privileged accounts with weak session and token protection, sign-in activity that includes non-interactive events instead of hiding them, and the accounts whose standing access makes a stolen token most valuable. You see where token replay would land before someone replays one.
Frequently Asked Questions
Are non-interactive sign-ins dangerous by themselves?
No. The vast majority are completely normal: background token refreshes, mail clients syncing, single sign-on carrying a user between apps. The risk is not that they happen, it is that they are voluminous, hidden on a separate tab, and the one category where a replayed stolen token blends in. The goal is not to eliminate them, it is to monitor them so a malicious one stands out.
Do non-interactive sign-ins require MFA?
Not at the moment they occur. The MFA requirement is evaluated at the interactive sign-in, and the resulting token carries a claim that MFA was satisfied. Non-interactive events reuse that token, so no new prompt fires. This is why an attacker who steals a post-MFA session token can act without ever facing MFA again, and why token protection and Continuous Access Evaluation matter more than the MFA prompt alone.
How long are Entra ID non-interactive sign-in logs kept?
Microsoft Entra ID retains sign-in logs for 7 days on the free tier and 30 days with a P1 or P2 license. Non-interactive user sign-ins follow the same window. For anything longer, and for real token-theft investigations, export the logs to Microsoft Sentinel, a Log Analytics workspace, Event Hub, or storage, because 30 days is often shorter than the time between a token being stolen and the intrusion being noticed.
