ROPC is on borrowed time.
A lot of organisations are running applications that authenticate using Resource Owner Password Credentials - ROPC. It works, it's been working for years, and nobody's touched it because nothing's broken.
Recently, Microsoft has started tightening the screws on ROPC. Two recent developments have moved this from "something to deal with eventually" to something worth thinking about.
What changed in the admin portal?
Microsoft has been progressively rolling out mandatory MFA enforcement for administrative access across Entra ID. The enforcement is scoped, it targets specific administrative applications and portals and not every app in your tenant. If your organisation has accounts using ROPC to access in-scope admin interfaces, those flows will start failing.
The key thing to understand is that this isn't a CA policy you can exclude your way around. Microsoft is enforcing MFA claims at the resource level, meaning the downstream service rejects tokens that don't carry an MFA claim. A Conditional Access exclusion on your app registration won't help - ROPC authenticates as the user, not the app, so the user's token still hits the enforcement wall.
If you have service accounts or automation hitting admin interfaces via ROPC, audit them now.
What changed in MSAL?
Microsoft.Identity.Client 4.74.0 - the latest MSAL release - formally deprecated the AcquireTokenByUsernamePassword method. Importantly, the method still works today, but the library is now explicitly signalling that this flow is on its way out. Future versions may remove it entirely.
This matters because MSAL is the foundation most modern .NET authentication is built on. If your applications are using a recent version of MSAL and calling AcquireTokenByUsernamePassword, you're now building on a deprecated code path.
The deprecation at the library level is separate from enforcement at the protocol level. Both are moving in the same direction.
Why ROPC is fundamentally the problem
ROPC requires the application to handle the user's plaintext credentials. There's no MFA support, no Conditional Access compatibility, no modern token security. It was a pragmatic workaround for legacy scenarios that predates modern identity architecture.
Microsoft's position is clear - ROPC should not be used for new applications, and existing applications should migrate. The question for most organisations isn't whether to migrate - it's very much ‘when?’, and ‘to what?’
So what to can you do?
For most service account and automation scenarios, the right replacement is the Client Credentials flow - the application authenticates as itself using a certificate or secret, rather than impersonating a user with a password. It's cleaner, more secure, and fully supported by Conditional Access.
For user-delegated scenarios where a real person needs to be represented, Auth Code with PKCE is the correct pattern.
If migration isn't on the immediate roadmap, at minimum:
Document every application using ROPC and what it's accessing
Identify which service accounts are involved and whether they're in scope for admin portal MFA enforcement
Monitor Microsoft's deprecation announcements - they have historically provided 12+ months notice, but scope has been expanding
Treat deferral as an active, monitored position.
For Aussie organisations?
For organisations operating under the ASD Essential Eight, ROPC straddles Maturity Level 2 and 3 requirements around multi-factor authentication. If you're targeting ML2 or above and you have ROPC flows in production, it’s probably a gap worth documenting and managing.
The enforcement timeline is Microsoft's to set. But the risk of being caught flat-footed when scope expands is yours to manage.
If you want help mapping your ROPC exposure or planning a migration path, we’d love to talk.
