A growing number of Microsoft account holders are discovering successful sign-ins from IP addresses inside Microsoft's own network—despite having two-factor authentication (2FA) enabled and receiving no login prompt. The anomaly, first spotlighted in a German investigation and corroborated across Reddit and Microsoft's Q&A boards, has triggered alarm and confusion. Are these legitimate infrastructure flows, or do they signal a deeper bypass of 2FA security? The answer sits at the intersection of misunderstood cloud routing, legacy authentication loopholes, and increasingly polished attack techniques that capture session tokens to defeat multi-factor protections.

The pattern is both specific and unsettling: affected users see entries in their Recent activity or My sign-ins page that originate from IPv4 or IPv6 addresses resolving to MICROSOFT-CORP-MSN-AS-BLOCK. Locations listed include data centers in Canada, Ireland, and Des Moines, Iowa. In some cases, Microsoft later disabled the account for spam or compromise. In others, the owner discovered the access only after a manual log review, weeks after the fact. The common thread is that 2FA was active, yet no push notification or approval request ever appeared.

The reports that set off the alarm

The first detailed public case came from German blog reader Tom, whose Microsoft account was flagged as compromised and blocked for spam. His activity history showed successful logins from an unknown IP in Ireland. Shortly after blogger Günter Born published the initial report, more users came forward.

On Reddit, a thread from late July 2025 described a successful login from a Microsoft corporate IP in Canada. The user had 2FA enabled but received no alert. Two Microsoft Q&A threads from the same week told similar stories: one from a user in Des Moines who discovered a login from an unfamiliar device with no Authenticator prompt, and another from a user in China who saw a successful US-based login without any warning. In each instance, the IP traced back to Microsoft’s own infrastructure.

Some users noticed a correlation with mobile app activity. One commenter observed that the events often coincided with opening the Outlook or OneDrive app on a smartphone. Another recalled that a Canadian IP entry appeared right after re-entering Outlook credentials in Apple Mail. Yet not every case fits that mold—the first reported victim, Tom, did not use an iPhone or iPad for email, and his account was definitively breached for spamming purposes.

Why your activity list shows a Microsoft datacenter IP

Before concluding that Microsoft is secretly accessing accounts, it’s critical to understand the legitimate reasons these IPs appear. Microsoft operates a vast global network of front-end servers and proxies that sit between client apps and back-end tenant services. When an app like Outlook mobile or OneDrive syncs data, it often routes through these proxies for performance and reliability. The sign-in event recorded in Azure AD or the Recent activity page may then show the proxy’s IP instead of the user’s device IP.

Microsoft openly documents this behavior. In community answers and support articles, the company explains that mobile app sign-ins, background sync operations, and other service-to-service flows can generate log entries attributed to Microsoft-owned IP ranges. These are not “hidden” accesses; they are routine infrastructure operations, though their visibility in user-facing logs can be jarring.

But that’s not the whole picture. The same logs also record non-interactive sign-ins—automated authentication requests that do not go through the normal interactive login page. Service accounts, legacy email clients, and scripts often use non-interactive flows that bypass MFA challenges entirely. Until recently, many organizations left these protocols open because they were needed for older applications. Attackers have long exploited this blind spot.

How attackers slip past 2FA even when it's enforced

Three well-documented techniques allow adversaries to gain or maintain access to an account without ever triggering a second-factor prompt. All three have been written about by both Microsoft’s security teams and independent researchers, and they explain how accounts with 2FA can still be breached.

OAuth and adversary-in-the-middle (AiTM) phishing. In an AiTM attack, the victim is lured to a proxy login page that mimics the real Microsoft sign-in. When they authenticate—including completing MFA—the proxy captures the resulting session cookie or token. The attacker then replays that token to access the account from their own machine. Because the token is already authenticated, no new MFA challenge is issued. Proofpoint documented active AiTM campaigns throughout 2025 that intercepted thousands of sessions, allowing attackers to read mail, send phishing emails from trusted accounts, and persist even after passwords were changed.

Abuse of third-party OAuth apps. A compromised or malicious application can request delegated permissions—reading mail, sending messages, maintaining access—that the user unwittingly consents to. Once consent is granted, the app can operate for months without any further authentication prompt. Microsoft has warned that verified-publisher apps and cleverly crafted reply URLs make these consent phishing attacks highly effective. In some cases, attackers create new credentials within the app, effectively establishing a backdoor that outlasts the initial token.

Legacy and non-interactive authentication. Basic Authentication, POP3, IMAP, and other legacy protocols do not support modern MFA. Background jobs that use these protocols authenticate with username and password alone. Until Microsoft began disabling Basic Auth by default in mid-2025, many tenants still relied on it. Even now, non-interactive sign-ins from service principals or daemon apps can evade MFA if not governed by conditional access policies.

Taken together, these vectors explain how a datacenter IP could appear in a compromised account’s activity list. If an attacker used an AiTM-obtained token to perform actions via a Microsoft Graph API or connected app, the traffic might route through Microsoft’s own infrastructure, showing as a corporate IP. The account owner would not see a login notification because the session was already established.

Microsoft’s mid-2025 security overhaul and why it matters

In July 2025, Microsoft began rolling out Secure by Default changes that automatically block legacy authentication protocols and require admin consent for many third-party app accesses. These new defaults shrink the attack surface for both credential theft and consent phishing. Tenants that adopt them immediately disable Basic Auth, POP, IMAP, and unauthenticated SMTP. They also enforce admin approval workflows so that users cannot grant broad permissions to apps without oversight.

Proofpoint and other security vendors have noted that these defaults will blunt the effectiveness of many AiTM and OAuth abuse campaigns, but they are not a silver bullet. Conditional access policies, token lifetime controls, and user education remain essential. The policy updates also do not retroactively revoke existing app consents or active tokens—admins must audit and clean up what’s already in place.

What you should do right now

The risk is real, and the steps below are ordered by impact. Both consumers and IT administrators can dramatically reduce exposure by taking action today.

For all personal Microsoft account users

  • Review activity and revoke sessions. Go to the Microsoft account Recent activity page, expand any unfamiliar entry, and select “This wasn’t me” if appropriate. Then use the “Sign out everywhere” option to invalidate all active tokens.
  • Rotate your password immediately. Use a strong, unique passphrase and avoid reusing it. Enable passwordless sign-in with Microsoft Authenticator or a FIDO2 hardware key.
  • Audit app permissions. Visit the account’s privacy pane and revoke any third-party apps you don’t recognize. Attackers often persist via delegated app consent.
  • Turn on passwordless or hardware-based MFA. SMS-based codes are vulnerable to SIM swapping. Use Microsoft Authenticator’s number-matching or a physical security key for the strongest protection.

For work, school, and managed tenant admins

  • Enforce modern authentication and block legacy auth. Verify that Security Defaults are enabled or configure conditional access policies to block legacy protocols explicitly. The mid-2025 changes help, but many tenants still need manual hardening.
  • Implement admin consent workflows. Prevent users from consenting to app scopes without admin review. This change was pushed as a default, but confirm it in your Azure portal under Enterprise applications > Consent and permissions.
  • Hunt for anomalous non-interactive sign-ins. Query Azure AD sign-in logs for client apps like “fasthttp,” “axios,” or other unusual strings. Look for sign-ins from datacenter IP ranges that correlate with unexpected behavior. Use Entra ID diagnostic settings to export logs to a SIEM for continuous monitoring.
  • Restrict access with conditional access. Require MFA or device compliance for high-risk operations. Use named locations to block or flag access from unexpected geographies or IP ranges.
  • Revoke stale tokens and force re-authentication. Use the Revoke-AzureADUserAllRefreshToken PowerShell cmdlet for compromised accounts, and set sign-in frequency policies to force periodic re-authentication.

Quick user checklist

  • Change password and revoke app permissions
  • Enable Microsoft Authenticator or a FIDO2 key
  • Sign out of all devices to invalidate tokens
  • Contact Microsoft Support if your account was blocked or used for spam

Distinguishing real threats from innocent routing

Not every datacenter IP entry signals a breach. When you spot one, ask:

  • Did you recently use a Microsoft mobile app (Outlook, OneDrive, etc.)? If yes, the entry may be a routed app flow.
  • Was the activity marked “Unusual” or “Sign-in blocked”? A block for spam suggests substantive misuse beyond a normal sync.
  • Do Azure AD logs show corresponding app consent or token issuance events? For admins, correlating with non-interactive sign-in details is key.

If you find app consent you didn’t authorize or token issuance that doesn’t align with your usage, treat the event as a compromise.

The unverified claims and the need for caution

Several forum threads include speculation that Microsoft staff or automated processes routinely access user mailboxes without 2FA for “porn scans,” CoPilot indexing, or maintenance. These claims remain unverified. Microsoft’s documentation and community responses indicate most datacenter IP entries stem from routed app traffic, not human operator access. The observation that some users see no activity for certain events is consistent with Microsoft’s statement that not all internal service events appear in the Recent activity UI. That explains visibility gaps but does not prove malicious internal access.

Until Microsoft publishes an auditable policy or log proving otherwise, claims of secret bypasses should be treated with caution. The confirmed technical mechanisms—proxy routing, legacy auth, and token theft—are sufficient to explain the symptoms without invoking conspiracy.

The bottom line

The reports from BornCity and community forums highlight a gap between user expectations and the reality of cloud authentication. 2FA is not an unbreakable shield. Attackers have adapted, and legitimate infrastructure quirks can obscure activity that feels invasive or compromising. The documented vectors—AiTM session theft, OAuth consent abuse, and legacy protocol bypasses—account for how accounts get breached without a visible MFA prompt.

Layered defense is mandatory. Modern authentication, app consent governance, token hygiene, endpoint security, and continuous log analysis together close the gaps that attackers exploit. Microsoft’s Secure by Default push is a welcome step, but it’s not retroactive and requires admin action to reach full effectiveness. For users, the immediate priority is to revoke unknown app permissions, switch to strong MFA, and force token revocation. For admins, it’s to lock down legacy auth, audit non-interactive sign-ins, and enforce conditional access.

If you have followed all these steps and still see unexplained successful sign-ins from Microsoft datacenter addresses, document the timestamps, IPs, and any related app consent events, then escalate to Microsoft Support for a tenant-level investigation. The cloud identity landscape is more complex than ever, but with proactive measures, you can stay ahead of the attackers.