Entra never sends the password to an external MFA provider. A rogue one can simply ask again

One authentication role in five carries no warning label

Microsoft's built-in roles reference lists 136 Entra roles. Thirty five of them carry Microsoft's PRIVILEGED label, the marker Microsoft applies to roles that can, in its own words, "modify credentials, authentication or authorization policies, or access restricted data".

Five of those 136 roles have the word Authentication in their name. Four carry the label: Authentication Administrator, Authentication Extensibility Administrator, Authentication Extensibility Password Administrator and Privileged Authentication Administrator. One does not.

The one that does not is Authentication Policy Administrator. It is the role that can add an external multifactor authentication provider to a tenant's authentication methods policy, which is the role at the centre of research published this month showing plaintext passwords being harvested during ordinary Entra sign-ins.

That is the arithmetic, and it is checkable against Microsoft's own page in about a minute.

What it does not establish is the story the coverage told.

The claim, and what Microsoft's protocol actually sends

On 16 September 2026 Varonis Threat Labs published research by Elad Ghvarh under the name TrustSink. On 22 September BleepingComputer covered it under the headline "Rogue external MFA providers can steal passwords during logins".

That headline is true about the outcome and misleading about the mechanism, and the difference decides what a defender should do about it.

The question worth asking is precise: does an external MFA provider observe or receive the user's password, or is it invoked only after primary authentication has already succeeded?

Microsoft's external MFA method provider reference answers it without ambiguity, and the answer is the second one.

Microsoft documents the sequence in eleven steps. Step one is the user signing in "with a first factor, like a password". Step two is Entra determining that another factor is needed. Only at step four does Entra redirect the browser to the provider, and what it hands over is a token Microsoft describes as containing "information to identify the user and tenant".

The reference then lists the contents of that token, the id_token_hint, claim by claim: iss, aud, exp, iat, tid, oid, preferred_username and sub, with given_name, family_name and upn available as optional additions. There is no credential in that list, and Microsoft goes further than silence. The token is deliberately crippled: "To prevent the token from being used for anything other than a hint, it's issued in the expired state."

So the primary factor is complete, verified by Entra, before the provider is contacted at all. The provider never sees the password, because Entra never sends it.

What crosses the boundary into the external provider, from Microsoft's external MFA method provider reference on Microsoft Learn

Stated by Microsoft as sent	Not sent, or not stated
An id_token_hint issued in the expired state, carrying iss, aud, exp, iat, tid, oid, preferred_username and sub	The user's password, or any other secret that authenticates the user. No credential appears in any documented claim.
Optional claims given_name, family_name, preferred_username and upn where the provider configures them	Any signal about what the provider's page displays or collects. Entra validates the response, not the render.
A nonce, a state value, the redirect URI, the client id and a client-request-id, sent by HTTP POST	Any requirement that the provider prove possession of its signing key beyond a matching key id and a valid signature.
A claims request naming the acr and amr values Entra will accept back	Any Microsoft check on where the provider's signing key came from, or on its certificate chain.

What the provider gets instead, and why it is worth more

Reading the protocol as an exoneration would be a mistake. The provider does not receive the password. It receives something a phishing operator would ordinarily spend weeks and a convincing domain trying to manufacture: a full page inside a sign-in the user has already started on Microsoft's own domain, arriving at the exact moment a password request looks reasonable.

Varonis makes the timing point well. The user "has just typed their real password on Microsoft's domain, so a second prompt inside the same flow does not raise suspicion the way an emailed link would".

The provider also gets a signature Entra will honour. Varonis reports that its test provider generated a self signed RSA key pair at first launch and served the public half at its own jwks endpoint, and that Entra accepted it: "Microsoft checks only that the key ID matches and the signature is valid. It does not check the certificate chain or where the key came from." The provider then returned two hardcoded claims, an acr of possessionorinherence and an amr of hwk, asserting a hardware key ceremony that never happened. Entra validated the token and completed the sign-in.

The persistence is the part that should worry an incident responder more than the capture. Varonis found that "resetting a captured password did not remove the rogue provider. It remained in the authentication flow and captured the replacement password at the user's next sign-in."

That inverts the standard containment reflex. The instinct after credential theft is to rotate, and rotation here feeds the trap. The provider has to come out of the authentication methods policy first, and the application, service principal and consent grant with it, before a single password is changed.

Who can put a third party inside your sign-in

Varonis names the requirement as "a Global Administrator or Authentication Policy Administrator account". Microsoft's how to guide splits that more finely, and the split matters.

Adding the method needs "at least" Authentication Policy Administrator. Granting admin consent to the provider's application needs "at least the Privileged Role Administrator role". Doing it through Microsoft Graph instead of the portal needs the Policy.ReadWrite.AuthenticationMethod permission. A Global Administrator holds all of that at once, which is why the research used one.

So a lone Authentication Policy Administrator can create a disabled external method and cannot switch it on. That is a real constraint, and it is worth stating plainly rather than rounding the threat up. It is also thinner than it sounds, because in a great many tenants the same person holds Global Administrator anyway, and because an attacker who has one privileged identity is usually shopping for a second.

Roles named for authentication in Microsoft's Entra built-in roles reference, with Microsoft's privileged label as published on 24 September 2026

Role	Carries Microsoft's PRIVILEGED label	Relevance to an external MFA method
Authentication Policy Administrator	No	Can create and manage the authentication methods policy, which is where an external method is registered
Authentication Administrator	Yes	Manages an individual user's methods, not the tenant policy
Privileged Authentication Administrator	Yes	Manages any user's methods including administrators
Authentication Extensibility Administrator	Yes	Manages custom authentication extensions

What the tenant can see, and where the documentation goes quiet

The registration is loud. Varonis found the act of registering the provider wrote three audit events in sequence, and that an automated deployment through Graph also created an application, a service principal and a consent grant within seconds of each other. Every sign-in the provider handled recorded the provider's issuer URL in the sign-in logs, along with the acr and amr values it asserted. Varonis calls an unfamiliar issuer carrying hwk "the most reliable signal, because the provider cannot avoid leaving it".

The operation is silent. Nothing in Microsoft's documentation offers a tenant administrator any view of what the provider renders or what it collects. Entra's validation, as documented, covers the returned token's issuer, audience, expiry, subject, nonce, acr and amr. There is no documented inspection of the page, no attestation about the provider's user experience, and no channel through which a tenant could obtain one.

There is also a reporting gap Microsoft states outright, and it is easy to miss. Users who satisfy MFA through an external method "aren't included in reports about authentication method registration". The population relying on the delegated factor is exactly the population your registration reporting does not count.

Tenant visibility of an external MFA provider, from Microsoft Learn and from the artefacts Varonis observed in its test tenant

What the tenant can observe	What it cannot observe, or is not stated
The authentication methods policy entry, its type, its display name and its included and excluded groups	What the provider's page shows the user at the moment of redirect
The application registration, its reply URLs, the service principal and the consent grant	What the provider collects, stores, logs or forwards on its own infrastructure
The provider's issuer URL and the acr and amr claims recorded against each sign-in	Whether the asserted ceremony, for example a hardware key check, actually took place
Audit events for the policy change and for the application and consent objects created alongside it	Which users rely on the external method, because Microsoft excludes them from registration reports

What an external method can never be made the only factor for

The strongest structural answer to the inversion worry is in the claim vocabulary, and it is easy to verify.

Entra accepts a fixed list of amr values back from a provider: face, fido, fpt, hwk, iris, otp, pop, retina, sc, sms, swk, tel and vbm. Microsoft publishes a type mapping for every one of them, and each maps to either possession or inherence. Not one maps to knowledge. Microsoft states the rule directly: "only methods with a different type can satisfy the second factor requirement".

An external provider therefore cannot assert the knowledge factor at all. It cannot be your password. It cannot be the only factor in an MFA sign-in. The inversion that the headline implies, an organisation outsourcing its second factor and losing its first, is real as a consequence and impossible as a protocol state. The first factor is not delegated. It is phished, separately, by a party you invited into the flow.

Two further limits are worth knowing because both are defensive levers.

First, and this is the important one, Microsoft states that "grant controls based on authentication strengths, including the built-in MFA strength, aren't satisfied by the external MFA method", and that policies using an external provider "should only be configured with Require multifactor authentication". A Conditional Access policy that demands a phishing resistant authentication strength cannot be met by an external provider at all. That is a hard boundary, and it is the single most useful sentence in the documentation for anyone drawing up controls.

Second, the predecessor feature was more constrained still. Microsoft's custom controls page lists what custom controls could never satisfy: Identity Protection automation, self service password reset, multifactor authentication claim requirements, sign in frequency controls, PIM role elevation, Intune device enrolment, cross tenant trusts and joining devices to Entra. Custom controls are deprecated. Microsoft's Learn page says new ones cannot be created or edited from September 2026 with "full retirement scheduled for early 2027", while the message centre notice MC1422061 gives September 2026 and May 2027. The two Microsoft surfaces do not agree on the end date, and neither is more authoritative on its face.

A bug Microsoft would patch, or a consequence of delegating a factor

As of 24 September 2026 we found no CVE, no MSRC advisory and no Microsoft security update associated with TrustSink. The BleepingComputer article carries no Microsoft comment. Varonis does not report a disclosure timeline or a Microsoft response, and frames the work as "a warning to defenders" rather than a vulnerability report. We could not reach any Microsoft statement on this research, and readers should treat the absence of one as unresolved rather than as agreement.

On the substance, this is a design consequence, and the reasoning is not difficult.

Every element the technique relies on is documented behaviour working as specified. Entra redirects the browser to a provider URL, because that is how a browser reaches a third party. Entra validates a signed token against published keys, because that is what OpenID Connect prescribes. Entra accepts a self signed key served from the provider's own jwks_uri, because the discovery document is the trust anchor the tenant administrator chose when they entered the URL. Entra does not inspect the provider's page, because Entra cannot: the page is served from someone else's origin to someone else's browser.

There is no patch shaped hole here. Microsoft could reduce the blast radius, and some of the options are obvious enough to name: label Authentication Policy Administrator as privileged, make external method registration a protected action requiring step up authentication, warn users at the redirect that they are leaving Microsoft, or surface external method reliance in registration reports instead of excluding it. Those are product decisions, not security updates, and none of them changes the underlying fact.

The underlying fact is that delegating a factor means delegating a screen. An organisation that adds an external MFA provider is making a statement it may not realise it is making: that this third party may interrupt our users mid sign-in, with a page of its choosing, and we will have no visibility into what it asks them for.

A rogue MFA provider against a rogue identity provider

The comparison sharpens what is distinctive here, and it does not run the way instinct suggests.

A compromised or malicious federated identity provider is strictly more powerful for access. Federation lets the trusted party assert who the user is. It can mint an assertion for any user in scope without that user doing anything, at any hour, with no browser session and no victim present. Measured in doors opened, federation abuse wins easily. It is also, in Microsoft's role model, guarded by External Identity Provider Administrator, which carries the privileged label.

A rogue external MFA provider cannot do any of that. It cannot assert identity, only that a second factor was met, and only for a user who is actively signing in. On access alone it is the weaker position.

What it gets that federation abuse does not is the plaintext password, and the following is our analysis rather than a claim from any source. A rogue identity provider bypasses the password. It never learns it, because in a federated flow the user does not type it into that party at all. The external MFA provider sits downstream of a genuine Microsoft password entry, which is what makes the second prompt credible, and the plaintext it harvests is worth more than Entra access. Passwords are reused. The same string may open a VPN, an on premises directory that Entra synchronises with, a personal mailbox that owns a recovery route, or a supplier portal that never heard of your tenant. Federation abuse gives an attacker your tenant. Credential harvesting gives them the user.

Comparison of a rogue external MFA provider and a rogue federated identity provider. The role labels are from Microsoft Learn; the comparative assessment is our analysis

Capability	Rogue external MFA provider	Rogue federated identity provider
Assert who the user is	No. It can only satisfy a second factor, and only for a possession or inherence type	Yes. It can assert identity for any user in scope
Work with no user present	No. It needs a live sign-in to interpose on	Yes. Assertions can be minted at will
Obtain the plaintext password	Yes, if it chooses to ask for one, because it controls the page	No. The user never types the password into it
Guarding role carries Microsoft's privileged label	Not for Authentication Policy Administrator, which registers the method	Yes, for External Identity Provider Administrator

The link to phishing resistance, made honestly

Yesterday we published a briefing on GOV.UK One Login's passkey rollout. The NCSC position it set out is that passwords, SMS codes, email codes and TOTP are all inherently phishable, and that the benefit of a phishing resistant factor is not realised while a phishable route remains available beside it.

TrustSink is the same principle arriving from an unexpected direction, and the link needs stating carefully rather than stretched.

A delegated factor is only as phishing resistant as the party you delegated it to. Entra will record amr: hwk and treat the sign-in as hardware key backed. The sign-in log will say possession. The Conditional Access policy requiring multifactor authentication will be satisfied. And none of that is evidence that a hardware key was touched, because the assertion is the provider's word and Entra has no mechanism to test it.

There is a genuinely reassuring corollary, and it is the practical control. Because external MFA cannot satisfy authentication strengths, a tenant that enforces a phishing resistant strength rather than the generic MFA grant is not exposed to a rogue external provider on those policies at all. The provider is simply not an acceptable answer. The NCSC advice to remove the phishable route, applied here, removes this technique from the paths it covers as a side effect.

What to do, in the order worth doing it

Everything below is read only inventory and defensive configuration. Nothing here reproduces the technique, and the order matters: if you find something unexpected, containment runs before rotation, which is the opposite of the usual reflex.

Read only Microsoft Graph endpoints for the inventory above.
All are GET. None changes tenant state.

External methods registered in the authentication methods policy
  GET /beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations
  Least privilege read scope: Policy.Read.All

Applications, to be filtered locally on reply URL
  GET /v1.0/applications?$select=id,appId,displayName,web,createdDateTime
  Filter client side for the external authentication callback reply URL
  Least privilege read scope: Application.Read.All

Service principals and their reply URLs and key credentials
  GET /v1.0/servicePrincipals?$select=id,appId,displayName,replyUrls,keyCredentials

Delegated permission grants attached to those service principals
  GET /v1.0/oauth2PermissionGrants

Directory audit events for authentication policy and application changes
  GET /v1.0/auditLogs/directoryAudits?$filter=activityDateTime ge 2026-06-24T00:00:00Z
  Least privilege read scope: AuditLog.Read.All

Sign-in logs, to recover the external provider issuers actually seen
  GET /v1.0/auditLogs/signIns?$filter=createdDateTime ge 2026-06-24T00:00:00Z
  Inspect authenticationDetails and the recorded authentication requirement

Role holders to review
  Authentication Policy Administrator  0526716b-113d-4c15-b2c8-68e3c22b9f80
  Privileged Role Administrator        e8611ab8-c189-46e8-94e1-60213ab1f814
  Global Administrator                 62e90394-69f5-4237-9190-012177145e10

What to ask a provider before you delegate a factor

The contractual questions matter more here than in most vendor reviews, because the thing you are buying is the right to interrupt your own users. Microsoft's documentation gives you no visibility into the answers, so the answers have to come from the provider in writing.

What an auditor should expect to see

For a UK organisation under Cyber Essentials Plus, ISO 27001 Annex A controls on access management and supplier relationships, or a regulator with an interest in operational resilience, the evidence pack for a delegated authentication factor is not the same as for an ordinary SaaS supplier. The supplier here is inside the authentication boundary.

Evidence an auditor should expect for a delegated authentication factor. Compiled by pk-sharma.com from the Microsoft documentation cited in this briefing

Evidence	What its absence indicates
A current inventory of external methods with a named business owner for each	Nobody is accountable for who may interrupt a sign-in, and an unfamiliar entry would not be challenged
Dated change records linking each registration to an approved request and an approver	The registration cannot be distinguished from an unauthorised one after the fact
Written provider answers on what the redirect page displays and what it collects	The organisation has delegated a screen it has never seen and cannot describe
Evidence that Authentication Policy Administrator, Privileged Role Administrator and Global Administrator are just in time rather than standing	The precondition for this entire technique is permanently available in the tenant

The question that exposes the gap

The coverage said a rogue external MFA provider can steal passwords during sign-ins. The protocol says Entra sends the provider no password and never has. Both are accurate, and holding both at once is the whole of the analysis: the exposure was never in what Microsoft transmits, it is in what Microsoft cannot see.

Every MFA deployment rests on an assumption that is almost never written down, which is that the screen asking for the factor is the screen the identity provider intended. Entra checks the signature on the answer. Nothing checks the question. There is no mechanism in the specification for checking the question, and there is no advisory to wait for, because nothing here is broken in the sense that a patch repairs.

So the question for anyone who has delegated, or is about to delegate under Microsoft's retirement timetable:

You can produce the contract, the discovery URL and the signing key for every external provider in your tenant. Can you produce a screenshot of what each of them shows your users at the moment of redirect, and does anyone in your organisation check it again after the day it went live?

This analysis was researched with Claude, made by Anthropic.