BAV2ROPC in Your Entra ID Logs: The Legacy Login Attackers Are Still Using

At the end of December 2026, Microsoft will switch off basic authentication for SMTP AUTH by default in existing Exchange Online tenants.  Anything still sending mail with a stored username and password—the scan-to-email printer, the monitoring box that emails alerts, the line-of-business app nobody has touched in years—will start failing. Administrators will be able to switch it back on, and some may, which means the deadline alone won’t necessarily close this door. You have to find out what’s using it first.

One of the best places to look is a peculiar user agent string that shows up in Entra ID sign-in logs and that Microsoft has never properly explained: BAV2ROPC. Unlike the familiar “Mozilla” or “Microsoft Azure PowerShell” entries, this one arrives without explanation, leaving administrators wondering what it represents and whether they should be concerned.

They should be. BAV2ROPC is a largely undocumented Microsoft user-agent identifier associated with legacy username-and-password authentication that is translated into OAuth 2.0 Resource Owner Password Credential (ROPC) flows. Failed BAV2ROPC sign-ins usually mean someone is trying password-only logins against your accounts (or a forgotten device is still trying an old password). Successful ones mean a password-only path is open—and in Exchange Online today, SMTP AUTH basic authentication should be your first suspect because basic authentication has been removed from the other major Exchange Online client protocols.

Attackers have noticed. Between March 18 and April 7, 2025, researchers at Guardz tracked a coordinated campaign abusing BAV2ROPC logins against Entra ID tenants: more than 9,000 suspicious Exchange login attempts, with concentrated bursts against administrator accounts—one set of admin accounts took nearly 10,000 attempts from 432 IP addresses in eight hours.  Legacy authentication remains a preferred target for credential-based attacks, and SMTP AUTH—historically enabled by default and still active in many organizations—is the last major Basic Authentication path into an Exchange Online mailbox. 

What BAV2ROPC Actually Means

BAV2ROPC is generally read as “Basic Authentication Version 2 Resource Owner Password Credential.” When you see this string in your sign-in logs, it usually means someone or something attempted to authenticate with a username and password over a legacy protocol, with Microsoft’s infrastructure handling the request through an OAuth 2.0 ROPC flow. (User agent strings are set by the client, so attack tools can send this one too. Treat it as a strong signal, not proof of which protocol was used.)

For successful BAV2ROPC sign-ins in Exchange Online, SMTP AUTH should now be the first protocol you investigate. Beginning in October 2022, Microsoft permanently turned off basic authentication for POP3, IMAP4, Exchange ActiveSync, and the other legacy Exchange Online protocols, but exempted SMTP AUTH because so many devices and applications still depended on it. Attackers still throw password attempts at the retired protocols, but those attempts fail. SMTP AUTH is the live case.

This conversion sounds like a security improvement, and in one sense it is. ROPC is technically an OAuth 2.0 flow rather than pure basic authentication. But here’s the problem: ROPC is a password-only flow. There’s no browser and no prompt, so the user can never complete a multi-factor challenge. Conditional Access still evaluates these sign-ins, and a policy that requires MFA or blocks legacy authentication will stop them—but only for the accounts it covers. In practice, accounts still using SMTP AUTH may include service accounts and shared mailboxes set up for printers and applications—the kinds of accounts organizations sometimes exclude from broader MFA or blocking policies. For those accounts, a password is all an attacker needs.

Basic authentication survives because Microsoft faces a practical dilemma. They’ve spent years trying to deprecate basic authentication across Microsoft 365, but complete removal breaks too many legitimate devices and applications. Printers that scan to email, monitoring systems that send alerts via SMTP, legacy line-of-business applications that send notifications with a stored mailbox password—these systems don’t support modern authentication protocols, and replacing all of them isn’t realistic for most organizations. That’s why the SMTP AUTH retirement has already been postponed, and why even the December 2026 change leaves administrators able to switch basic authentication back on.

In practice, this BAV2ROPC/ROPC handling acts as a bridge: it brings legacy password-based sign-ins into Entra ID, where they can be logged and evaluated, but ROPC still can’t satisfy interactive MFA challenges. And attackers know exactly how to exploit it.

Why Attackers Target Legacy Authentication

Attackers specifically target legacy authentication for several reasons that make it an attractive attack vector:

• Potential monitoring blind spots. Security teams that focus primarily on interactive sign-ins and modern authentication flows can give legacy authentication attempts less scrutiny, especially if those protocols are assumed to be disabled.
• No way to complete MFA. Push notifications and authenticator prompts need a user on the other end. Legacy protocol requests can’t satisfy them, so MFA can only block these sign-ins, never challenge them—and any account excluded from blocking policies is protected by its password alone.
• Clearer success indicators. Legacy protocols provide straightforward success or failure responses, making them efficient for credential validation at scale.
• Credential stuffing efficiency. Attackers can rapidly test credentials obtained from breaches at other organizations against your Microsoft 365 environment using legacy protocols.

Microsoft’s own analysis puts it bluntly: more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication.  The challenge for security teams is that legacy authentication often persists in environments where administrators believe they’ve already disabled it.

The Configuration Complexity Problem

Here’s where things get particularly frustrating for security teams: you may believe you’ve disabled legacy authentication when you actually haven’t.

SMTP AUTH configuration in Microsoft 365 exists in multiple locations, and settings in one location can override settings in another. This creates a configuration complexity that even experienced administrators struggle to manage.

• Organization-wide SMTP AUTH setting. This is the global setting most administrators check first, found in the Exchange admin center’s mail flow settings or set with Set-TransportConfig. You can disable SMTP AUTH at the organizational level here, but this setting can be overridden at the mailbox level.
• Per-mailbox SMTP AUTH settings. Individual mailboxes can have SMTP AUTH enabled or disabled independently of the global setting. These per-mailbox configurations take precedence, meaning a single misconfigured mailbox creates an authentication pathway into your environment even when your global settings appear secure.
• Exchange authentication policies. A separate mechanism that can block basic authentication for SMTP before the password is ever checked, applied as an organization default or to individual users. Because it is separate from the SMTP AUTH enablement settings, it can be overlooked during reviews.
• Security defaults. If security defaults are turned on in Entra ID, SMTP AUTH is already blocked. But security defaults have to be turned off before an organization can use Conditional Access; removing them also removes that particular protection, so if no other control blocks legacy authentication, it may become available wherever Exchange settings allow it.
• Conditional Access policies. In a fresh username-and-password ROPC flow, these policies can block the sign-in after primary authentication has succeeded. That means some interrupted sign-ins can reveal that a credential was accepted, although the exact result code and authentication context matter and not every Conditional Access failure proves a password was correct.

This multi-layer configuration model creates gaps that are difficult to identify through the administrative interface alone. You need to query your environment systematically to understand what’s actually enabled and where. In Exchange Online PowerShell, two commands get you most of the way:

# Organization-wide setting (True = SMTP AUTH disabled for the org)
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

# Mailboxes explicitly enabled for SMTP AUTH, overriding the org setting
Get-CASMailbox -ResultSize Unlimited |
    Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
    Select-Object PrimarySmtpAddress, SmtpClientAuthenticationDisabled

A mailbox showing a blank value simply follows the organization-wide setting. A mailbox showing False has SMTP AUTH turned on, regardless of what the global setting says.

Hunting for BAV2ROPC in Your Environment

If you want to understand your actual legacy authentication exposure, you need to actively hunt for it in your logs. BAV2ROPC indicators appear in two primary locations: Entra ID sign-in logs and the Unified Audit Log.

In the Entra admin center, open the sign-in logs, add the Client App column, and filter for the legacy authentication protocols—then repeat on the non-interactive sign-ins tab, because these logins can appear on either.  BAV2ROPC shows up in the user agent field of each sign-in’s details. Microsoft also provides a Sign-ins using legacy authentication workbook for broader triage,  and if your sign-in logs stream to Microsoft Sentinel or another security platform, the same signals can be turned into ongoing detections there.

Whatever tool you use, these are the signals that matter. The result codes are Microsoft’s own, listed in its Entra error code reference: 

• User agent BAV2ROPC: A strong indicator of a password-only or legacy-authentication attempt. Because user agent strings can be spoofed, treat it as a signal rather than proof.
• Client app “Authenticated SMTP,” same record: The attempt came through SMTP AUTH. Successful logins attributed to any other legacy protocol are unexpected in Exchange Online today and worth escalating.
• Result 50126, same record: Wrong username or password. Repeated events across users or sources are consistent with password guessing; repeated events for one account may also be a stale legitimate credential.
• Result 50034 in bursts: The account doesn’t exist. Bursts across many names may indicate username enumeration or password spraying.
• Result 53003, 53000, 53001, 50074, 50076, 50079, or 50055, same record: Interpret these carefully. In a fresh password-based attempt, 50074, 50076, and 50079 are strong indicators that primary authentication succeeded before MFA or MFA registration stopped the sign-in. Results 53000, 53001, and 53003 show that a device or Conditional Access control blocked the request and can indicate valid credentials in a known fresh ROPC attempt, but the codes alone don’t prove that a password was submitted or accepted. Result 50055 means the password is expired and warrants investigation, but it likewise should not be treated by itself as proof that an attacker supplied the correct current password. For unfamiliar source addresses, investigate the account and reset credentials when the surrounding evidence indicates exposure.
• Success from an unfamiliar IP address: Potential compromise. Check message trace for what the account sent and investigate the source.
• Steady, low-volume successes from your own office IP addresses: Likely your printers and applications—which is exactly the list you need before December.
• A spike in accounts targeted per hour, across many IP addresses: Consistent with a spraying campaign rotating its sources, like the one Guardz observed. Look at the whole tenant over time, not just one account or one address.
• Logins outside business hours or from unusual locations: Worth investigating even when the other signals are quiet.

SMTP AUTH only sends mail; it doesn’t read it. So when a suspicious BAV2ROPC login succeeds, message trace is where you see what happened next: what the account sent, to whom, and in what volume. A compromised account sending mail from inside your domain is a ready-made phishing platform. Then check the Unified Audit Log and other sign-in activity for the same account, because a password confirmed through SMTP AUTH may be tried everywhere else it might work.

Moving Beyond Detection to Remediation

Finding BAV2ROPC in your logs is just the beginning. The real work is systematically eliminating the legacy authentication attack surface while maintaining functionality for legitimate devices and applications.

Start with an inventory. Use the PowerShell commands and sign-in log review above to identify every mailbox with SMTP AUTH enabled and every account actually using it. Cross-reference this against your asset inventory to understand which devices or applications depend on these settings. For many organizations, this inventory reveals surprises—mailboxes with SMTP AUTH enabled for devices that no longer exist, or service accounts that haven’t been used in years but remain configured for legacy protocols.

For devices and applications that genuinely need to send email, modern alternatives exist. Applications that can be updated can switch to OAuth for SMTP. Many printers and network devices can instead send through an SMTP relay connector in Exchange Online, authenticated by your static IP address or a certificate rather than a stored password. Direct send can work for devices that only email people inside your organization, though Microsoft now lets administrators reject it, so check your settings first. Yes, this requires configuration work, but it eliminates the credential exposure that makes legacy authentication so dangerous.

Where modern alternatives aren’t feasible, contain what’s left. Enable SMTP AUTH only on the specific mailboxes that need it, and keep it off everywhere else. Give those accounts long, unique passwords and no other privileges. Block legacy authentication with Conditional Access for every other account, and restrict the remaining exceptions to your known IP addresses. These steps won’t eliminate the risk entirely, but they reduce your attack surface meaningfully.

The Broader Context: Authentication as an Attack Surface

BAV2ROPC is one specific manifestation of a larger problem: authentication complexity creates exploitable gaps. As organizations adopt cloud services, implement hybrid environments, and manage increasingly diverse device ecosystems, authentication becomes simultaneously more critical and more complex.

Microsoft’s approach to authentication has evolved over two decades, from simple username-password schemes to sophisticated multi-factor flows with risk-based evaluation. But this evolution has created layers of legacy support that persist because complete removal would break too many real-world implementations.

Other vendors face similar challenges. Most major cloud platforms maintain legacy authentication methods for backward compatibility, and most identity providers still support protocols that security teams would prefer to retire. The result is an authentication landscape where old and new coexist uneasily, and organizations must actively manage the transition rather than assuming defaults are secure.

What This Means for Your Security Program

If you’re responsible for security in a Microsoft 365 environment, BAV2ROPC should be on your radar as both an indicator and a reminder. As an indicator, it reveals ongoing legacy authentication activity that warrants investigation. As a reminder, it highlights that security configurations require active management—default settings and one-time changes aren’t sufficient.

Add BAV2ROPC detection to your security monitoring playbook. Create alerts for unusual volumes or patterns. Include it in your regular security reviews. Most importantly, use its presence as motivation to systematically address legacy authentication across your environment rather than treating it as an isolated issue—and do it before the December 2026 change forces the issue on Microsoft’s schedule instead of yours.

A systematic reduction in authentication attack surface is a sound way to reduce exposure: eliminate legacy protocols where possible, secure them with additional controls where elimination isn’t feasible, and actively monitor for abuse patterns in either case.

That’s not exciting or innovative work. It’s methodical, sometimes tedious, often politically challenging when it requires updating old devices or changing established workflows. But it’s effective. And in a threat landscape where attackers conduct credential-based attacks at massive scale daily, effective beats exciting every time. ■