Legacy Authentication and ROPC Retirement Guide: Find, Migrate and Block Password-Only Sign-ins

Legacy authentication and the OAuth password grant let a username and password on their own produce a session or token, so every MFA policy you have written is skipped on that path. Basic authentication to mail protocols, app passwords and the Resource Owner Password Credentials (ROPC) grant are the usual culprits, and they hide in printers, scripts, old line-of-business apps and service accounts long after users have moved to modern sign-in. This guide explains what counts as legacy authentication, what BAV2ROPC means in Microsoft Entra ID sign-in logs, how to inventory the remaining dependencies, how to migrate each one and how to block the path safely with report-only testing and a rollback plan. It is written for identity engineers, Microsoft 365 and Google Workspace administrators and detection engineers. Windows NTLM is a separate problem with its own roadmap: see the NTLM Deprecation and Elimination Guide.

Key takeaways

• The password-only path is the attack path. Microsoft reports that more than 97% of credential stuffing attacks and more than 99% of password spray attacks use legacy authentication protocols.
• ROPC is deprecated by the standard, not just by vendors. RFC 9700 (BCP 240, January 2025) says the resource owner password credentials grant MUST NOT be used, and the OAuth 2.1 draft leaves it out entirely.
• BAV2ROPC is a signal, not an attacker tool. The string appears when a basic authentication session is translated into an ROPC token request, most often for SMTP AUTH from devices, scripts and spraying tools alike.
• Most remaining dependencies are non-human. Scanners, monitoring scripts, CI jobs and vendor integrations that send a stored password should move to OAuth, managed identities, workload identity federation or certificate credentials.
• Block in report-only first, then enforce in rings. A Conditional Access policy targeting Exchange ActiveSync clients and Other clients, with break-glass exclusions and a migration register, retires the path without outages.

What counts as legacy authentication

"Legacy authentication" is a working term rather than a protocol name. Microsoft describes it as authentication over protocols that do not support multifactor authentication. In practice it covers three mechanisms that share one property: the client holds the user's password and presents it to a service other than an interactive identity provider page.

Two clarifications save time in scoping. First, certificate-based authentication for Exchange ActiveSync is still classed as legacy authentication by Microsoft and can be blocked by Conditional Access. Second, "modern authentication" means OAuth 2.0 tokens obtained through a flow where the identity provider handles the user's credentials and can apply MFA and policy: authorisation code with PKCE, device authorisation, broker-based sign-in, or app-only flows for workloads. See the OAuth 2.0 and OpenID Connect Guide for the flows themselves.

ROPC and what BAV2ROPC means in your logs

The Microsoft identity platform still accepts ROPC on /oauth2/v2.0/token for work and school accounts, with heavy caveats. Microsoft's own documentation opens with the recommendation not to use it, says it requires "a very high degree of trust in the application", and lists hard limits: no personal accounts, no invited personal accounts, no passwordless or FIDO accounts, no users who must complete MFA, and no federated users redirected to AD FS unless a Home Realm Discovery policy sets AllowCloudPasswordValidation to true with password hash sync. The tenant segment cannot be common or consumers, so you will see ROPC calls against a tenant ID or organizations.

The standards position is firmer. RFC 9700, section 2.4, states: "The resource owner password credentials grant [RFC6749] MUST NOT be used." The reasons given are that it exposes the resource owner's credentials to the client, increases the places credentials can leak, trains users to type passwords outside the authorisation server, is not designed for two-factor authentication, and may make WebAuthn impossible. The OAuth 2.1 Internet-Draft (draft-ietf-oauth-v2-1-16, dated 3 September 2026, still a working group draft when checked on 28 October 2026) says the implicit and resource owner credentials grants are not specified in OAuth 2.1.

BAV2ROPC

Microsoft does not document the string publicly. Research by Red Canary (now published by Zscaler, June 2023) describes it as Microsoft translating a legacy basic authentication session into an OAuth ROPC flow, so the legacy client receives a token without being upgraded, and confirms the behaviour for SMTP AUTH. The fields to recognise are:

A burst of failed BAV2ROPC sign-ins across many accounts is password spraying against the legacy door (ATT&CK T1110.003 Password Spraying). A single successful one from an unknown IP is the event to escalate, because it means a valid password worked without MFA (T1078.004 Cloud Accounts).

Where legacy authentication still lives in 2026

Platform retirements have closed most of the user-facing doors. What remains is concentrated in a few places that each need a different fix.

• Exchange Online: Microsoft has disabled basic authentication in all tenants for Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, Offline Address Book, Autodiscover and Outlook clients, and it cannot be re-enabled. SMTP AUTH is the exception: it was left on in tenants that used it, and Microsoft has announced its retirement. Check the current SMTP AUTH timeline on the Exchange team blog before you plan, because it has been revised.
• Google Workspace: Google turned off access to less secure apps for all Google Accounts on 14 March 2025. IMAP, SMTP, POP, CalDAV, CardDAV and Google Sync (Exchange ActiveSync) no longer accept the account password; OAuth is the supported route, with app passwords remaining as an exception for some devices.
• Entra ID token endpoint: ROPC itself remains available for custom applications. This is the dependency most often missed, because it is not tied to a mail protocol and looks like a normal OAuth call.
• Multifunction devices and appliances: scan-to-email printers, monitoring appliances and building systems that send SMTP AUTH with a stored mailbox password. See the Printer and Print Server Security Guide.
• Scripts and service accounts: PowerShell or Python jobs that hold a user account's password to call Graph, send mail or read a mailbox, frequently with MFA excluded for "the service account". See the Service Account Security Guide.
• Other identity providers and in-house apps: many identity platforms still offer a password grant or "resource owner password" option for first-party apps. Inventory where it is enabled per client, not per tenant.

Finding every dependency

Discovery is the phase that decides whether enforcement goes smoothly. Use at least 30 days of sign-in data, ideally 90, so monthly batch jobs show up.

1. Filter the interactive and non-interactive sign-in logs. In the Entra admin center, under Monitoring and health, open Sign-in logs, add the Client App column and filter on the legacy protocols. Repeat on the User sign-ins (non-interactive) tab: unattended scripts appear there, not in the interactive view.
2. Run the Sign-ins using legacy authentication workbook. It needs Entra ID P1 and a Log Analytics workspace, covers up to 90 days and lets you drill from protocol to application to user.
3. Query for ROPC directly. In Log Analytics or your SIEM, filter on AuthenticationProtocol == "ropc" or UserAgent == "BAV2ROPC" across SigninLogs and AADNonInteractiveUserSignInLogs, then group by AppId, UserPrincipalName and IPAddress. Each distinct AppId and account pair is one migration item.
4. Check SMTP AUTH at every level. Run Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled for the organisation and Get-CASMailbox for mailboxes where SmtpClientAuthenticationDisabled is False. The per-mailbox value overrides the organisation value, so an org-wide "disabled" can hide enabled mailboxes.
5. Review Google Workspace and other SaaS. Look for app passwords still issued, and for vendor integrations configured with a username and password rather than OAuth.
6. Record each item in a migration register: account, owner, protocol or flow, source IP or device, business function, target method, deadline and exception expiry.

Migration paths by dependency type

Match the replacement to whether a user is present. Microsoft's ROPC documentation makes the same split: user-context apps move to interactive or broker flows, and workloads with no user move to service principal authentication.

For the Azure case specifically, see the Azure Managed Identities Security Guide; for client secrets that replace passwords, see the Azure Entra Client Secrets Security Guide, because a long-lived secret is only a modest improvement on a password.

Blocking safely: phased rollout and rollback

1. Phase 0, prerequisites: confirm two cloud-only break-glass accounts exist and are excluded (see the Break-Glass Account Guide), the migration register is populated and sign-in logs stream to your SIEM.
2. Phase 1, report-only: create a Conditional Access policy for All users and All resources, set Conditions, Client apps, Configure to Yes, select only Exchange ActiveSync clients and Other clients, grant Block access, and set Enable policy to Report-only. Review the report-only result for two to four weeks; every "would be blocked" success is either a register item or a surprise to investigate.
3. Phase 2, pilot ring: switch the policy On for a pilot group (IT, then one business unit). Keep a small, named exception group for register items with an expiry date, never a broad exclusion such as "all service accounts".
4. Phase 3, enforce for all users: extend to All users. Disable SMTP AUTH at the organisation level with Set-TransportConfig -SmtpClientAuthenticationDisabled $true, and enable it per mailbox only for register items. Without Conditional Access licences, security defaults also block legacy authentication and disable SMTP AUTH.
5. Phase 4, close ROPC in applications: for your own app registrations, remove code paths that request grant_type=password; for third-party apps, require the vendor to move to a supported flow at renewal.
6. Rollback: if a critical process fails, add the specific account to the time-boxed exception group or set that one mailbox's SmtpClientAuthenticationDisabled to $false. Do not turn the whole policy back to report-only; record the rollback in the register with a new deadline.

One limit matters for non-human identities: Microsoft notes that service principals are not blocked by user-scoped Conditional Access policies. Workloads that already use app-only tokens need Conditional Access for workload identities, which is covered in the Conditional Access Guide.

Decision guidance

• Block now or migrate first: if report-only shows only failed legacy sign-ins (spray noise) and no successes from known workloads, enforce immediately. If there are successful business sign-ins, migrate or isolate those first, then enforce.
• OAuth SMTP or Graph: choose OAuth SMTP when the sending software supports it and you cannot change the code; choose Graph sendMail for code you own, because it removes the SMTP dependency entirely before the basic auth retirement.
• Relay or replace hardware: a restricted relay is acceptable for a known device fleet with an owner; replace devices that also store other credentials or run unsupported firmware.
• Small organisations: security defaults give legacy blocking without Conditional Access licences, at the cost of fine-grained exclusions. Larger organisations need Conditional Access plus the register, because they will have more long-tail dependencies.
• Exceptions: an exception is justified only for a named account with no MFA-capable alternative, restricted to known source IPs, with a monitored sign-in alert and an expiry no longer than one quarter.

Detection and measurement

After enforcement, legacy sign-ins become a high-signal detection source because legitimate use should be near zero.

• Alert: any successful sign-in with authenticationProtocol ropc or userAgent BAV2ROPC and singleFactorAuthentication outside the exception group. Published detection rules (for example Elastic's "Entra ID OAuth ROPC Grant Login Detected") use this logic and list legitimate automation as the main false positive.
• Hunt: failed legacy sign-ins across many accounts from one IP or ASN, a spray pattern; and sign-ins where appliedConditionalAccessPolicies is empty for a legacy client app.
• Audit: changes to SmtpClientAuthenticationDisabled, Exchange authentication policies, the Conditional Access policy and its exclusion group.

Framework mapping

Common failure patterns

• Blocking only interactive sign-ins: teams check the interactive log, see nothing and miss the scripts in the non-interactive log that break on enforcement day, or worse, keep working through an exclusion.
• "MFA is on" while a password-only account remains: one forgotten account without MFA is enough. In the Microsoft Midnight Blizzard Breach, a low-volume password spray worked against a legacy test tenant account that had no MFA.
• Service account exclusions that never expire: excluding "svc-" accounts from the block policy turns a temporary migration aid into a permanent bypass that attackers can find by spraying.
• Trusting the organisation-wide SMTP setting: per-mailbox SMTP AUTH settings override the organisation value, so a tenant can report SMTP AUTH disabled while dozens of mailboxes accept it.
• Treating the problem as Microsoft-only: password-only logins to SaaS and data platforms carry the same risk. The Snowflake Breach used infostealer passwords against accounts with no MFA across about 165 organisations.
• Replacing a password with an unmanaged secret: moving a script from ROPC to a client secret that never rotates and sits in the same script fixes the MFA gap but not the credential exposure.

Practitioner checklist

• Pull 90 days of interactive and non-interactive sign-ins filtered on legacy client apps, ropc and BAV2ROPC.
• Build a migration register with an owner, target method and expiry for every account and app found.
• Audit SMTP AUTH at organisation and mailbox level and disable it everywhere except register items.
• Move workloads from user passwords to managed identities, workload identity federation or certificate credentials.
• Remove grant_type=password from in-house apps and add ROPC retirement to vendor renewal requirements.
• Deploy the Conditional Access legacy block in report-only, then a pilot ring, then all users, with break-glass exclusions.
• Alert on any successful single-factor legacy or ROPC sign-in and on changes to the block policy and its exclusions.
• Review the exception group monthly and report the five metrics to the identity programme owner.

Standards and references

• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: The OAuth 2.1 Authorization Framework (Internet-Draft)
• Microsoft: Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials
• Microsoft: Block legacy authentication with Conditional Access
• Microsoft: Deprecation of Basic authentication in Exchange Online
• Microsoft: Enable or disable SMTP AUTH in Exchange Online
• Google: Transition from less secure apps to OAuth
• Red Canary (Zscaler): BAV2ROPC research

Related NHI Mgmt Group resources: NTLM Deprecation and Elimination Guide · Conditional Access Guide · Password Spraying and Credential Stuffing Defence Guide · Service Account Security Guide · Phishing-Resistant MFA Guide