External MFA in Entra ID: hoe het werkt en wat het betekent voor custom controls

Samantha Kloos-Kilkens
26-02-2026 · Samantha Kloos-Kilkens

Het preview-label is weg uit de documentatie van external authentication methods in Microsoft Entra ID, en de feature heet voortaan External MFA. Hangt jouw externe MFA-provider nog via een Conditional Access custom control aan je tenant, dan is dit de koppeling waar Microsoft je naartoe wil hebben. In deze blog: wat er tijdens de sign-in precies gebeurt, waarom het resultaat als MFA telt waar een custom control dat nooit deed, en wat ik zou controleren voordat je migreert.

Een overdekte loopbrug tussen twee bakstenen gebouwen Foto: Getty Images via Unsplash

Wat er deze week veranderd is

Op 24 februari heeft Microsoft de documentatie bijgewerkt. Het preview-label is weg bij Manage an external MFA method in Microsoft Entra ID, de feature heet nu External MFA en de knop in het admin center onder Authentication methods heet Add external MFA. De Graph-resources (externalAuthenticationMethodConfiguration voor de tenant policy en externalAuthenticationMethod voor de registratie van een gebruiker) stonden in januari al in v1.0. De public preview begon in mei 2024 met negen providers: Cisco Duo, Entrust, HYPR, Ping Identity, RSA, Silverfort, Symantec VIP, Thales en TrustBuilder.

Custom controls zelf staan nog precies waar ze stonden: een preview-feature die nooit uit preview is gekomen. Sinds de aankondiging van de preview in 2024 noemt Microsoft external authentication methods de vervanger, maar op het moment dat ik dit schrijf is er geen datum gepubliceerd waarop custom controls verdwijnen. Ik zou daar niet op wachten: de functionele beperkingen van custom controls hieronder zijn op zichzelf al reden genoeg om over te stappen.

Wat er tijdens een sign-in gebeurt

External MFA is gebouwd op OpenID Connect, en de provider reference is de moeite waard om helemaal te lezen, ook als je zelf nooit een provider bouwt. De flow is kort. De gebruiker doet de eerste factor in Entra ID, Conditional Access besluit dat MFA nodig is, de gebruiker kiest de externe methode en Entra ID stuurt de browser met een form POST naar het authorization_endpoint uit het discovery-document van de provider. Dat gaat via de implicit flow met response_type=id_token, met daarbij een id_token_hint: een door Entra ID ondertekend token dat de gebruiker beschrijft (oid, tid, sub, preferred_username) met de client ID van de provider als audience. Die hint wordt bewust al verlopen uitgegeven, zodat hij alleen als hint bruikbaar is en nooit als credential.

De provider valideert de hint tegen de gepubliceerde keys van Entra, zoekt de gebruiker eventueel op in Graph met oid en tid, doet zijn eigen authenticatie en POST een id_token terug naar https://login.microsoftonline.com/common/federation/externalauthprovider. Entra ID controleert dat token strenger dan de meeste mensen verwachten: 
{
  "iss": "https://mfa.provider.example",
  "aud": "<client ID van Entra ID bij de provider>",
  "sub": "<dezelfde sub als in de id_token_hint>",
  "nonce": "<nonce uit het request>",
  "acr": "possessionorinherence",
  "amr": ["otp"],
  "iat": 1772100000,
  "exp": 1772100300
}
De sub moet overeenkomen met de hint, de nonce moet terugkomen, acr moet een van de waarden zijn waar Entra om vroeg, en amr moet precies één waarde uit een vaste lijst bevatten. Entra ID vertaalt die amr naar een type factor (otp, sms, tel, fido, hwk, pop, sc en swk zijn possession; fpt, face, iris, retina en vbm zijn inherence) en controleert dat dit type verschilt van dat van de eerste factor. Pas dan geldt MFA als voldaan, en vanaf dat moment draagt de sessie MFA op precies dezelfde manier als na een goedkeuring in Authenticator. De provider meldt dus welk soort factor er gebruikt is, en Entra ID bepaalt of dat optelt tot MFA.

Een paar details verklaren de meeste mislukte koppelingen. De discovery URL moet eindigen op /.well-known/openid-configuration zonder query string, de issuer moet teken voor teken kloppen (een expliciete :443 is al genoeg om het te breken), de JWKS moet x5c bevatten en de encoding van de kid moet in token en JWKS gelijk zijn. Entra ID cachet de metadata van de provider 24 uur, wat ertoe doet bij key rollover, en geeft de poging ongeveer 5 minuten na de redirect op. Heeft de multitenant app van de provider geen admin consent in jouw tenant, dan krijg je AADSTS900491; voor die consent heb je minimaal Privileged Role Administrator nodig.

External MFA als authenticatiemethode

External MFA staat in de authentication methods policy naast Authenticator en passkeys, en je scopet het op groepen zoals elke andere methode. Van de provider heb je drie waarden nodig: de App ID van hun (meestal multitenant) app, een client ID en de discovery URL. De display name die je invult, zien gebruikers in de methodekeuze en die kun je achteraf niet meer wijzigen, dus kies hem met dat in je achterhoofd. Het is alleen een tweede factor; als eerste factor of voor SSPR kun je het niet gebruiken.

Gebruikers registreren de methode in Security info onder External Auth methods, via de registratiewizard bij het aanmelden, of een admin registreert hem namens hen. Geregistreerde gebruikers verschijnen niet in de rapportages over registratie van authenticatiemethoden, waardoor je MFA-dekking er slechter uitziet dan hij is.

Bij system-preferred MFA is de documentatie het niet met zichzelf eens. De wijziging van februari 2025 die externe methoden aan system-preferred MFA toevoegde, zet ze op plek drie, na Temporary Access Pass en passkeys maar boven Authenticator-notificaties. Diezelfde wijziging laat gebruikers die in scope van de externe methode vallen ook hun andere tweede factoren verwijderen, zelfs als dat de standaardmethode is. De manage-pagina gebruikt echter het voorbeeld van een gebruiker met Authenticator die eerst number matching krijgt en zelf de externe methode moet kiezen. Test dit met een pilotgebruiker die beide heeft voordat je de instructies voor eindgebruikers schrijft.

External MFA voldoet niet aan authentication strengths, ook niet aan de ingebouwde Multifactor authentication-strength. Policies hebben de gewone grant Require multifactor authentication nodig. Eis je phishing-resistant MFA voor admins via een strength, of beveilig je PIM-activatie met een authentication context die naar een strength verwijst, dan komen die gebruikers met External MFA daar niet doorheen.

Waar custom controls tekortschieten

Een custom control is een grant control. Conditional Access stuurt de gebruiker door, krijgt een positief antwoord terug en die ene policy is voldaan. Er komt niets in de sessie te staan waaruit blijkt dat er MFA heeft plaatsgevonden. De pagina over custom controls somt op wat daardoor niet werkt: ID Protection-policies die MFA eisen, SSPR, het voldoen aan MFA-claimvereisten, sign-in frequency, PIM, Intune-enrollment, cross-tenant trusts en het joinen van devices aan Entra ID. Waar ik als eerste naar zou kijken: PIM, Azure en Security info.

PIM-activatie met "require MFA" accepteert de custom control niet, dus voor zover ik kan zien valt PIM terug op Microsoft MFA, en dat betekent voor een gebruiker bij wie de custom control de enige tweede factor is dat hij eerst een Microsoft-methode moet registreren. In de aankondiging van de preview van external authentication methods stond PIM-activatie juist expliciet genoemd als iets waar ze aan voldoen.

Over mandatory MFA voor Azure is Microsoft duidelijk: de custom controls-preview voldoet niet aan de eis, external authentication methods wel. Nu fase 2 sinds oktober 2025 wordt uitgerold (Azure CLI, Azure PowerShell, IaC-tools en de REST API voor create-, update- en delete-acties), is dat een praktisch probleem geworden voor admins bij wie een custom control de enige tweede factor is.

Security info vraagt om MFA in de huidige sessie (sinds augustus 2025 opnieuw als de laatste MFA meer dan 10 minuten geleden is). Een custom control levert die MFA niet, dus in de praktijk hebben gebruikers ook een Microsoft-methode nodig, alleen al om hun security info te beheren. Zo eindigen tenants met custom controls met twee MFA-systemen naast elkaar, zonder dat iemand daar echt voor gekozen heeft.

Beide naast elkaar tijdens de migratie

Microsoft ondersteunt custom controls en External MFA naast elkaar en adviseert twee Conditional Access-policies met aparte pilotgroepen: de bestaande met de custom control en een kopie met Require multifactor authentication. Valt een gebruiker in beide policies, dan wordt hij twee keer naar de provider gestuurd, één keer voor MFA en één keer voor de custom control. De volgorde die ik zou aanhouden:
  1. Inventariseer elke policy die een custom control gebruikt, ook die in report-only of uitgeschakeld.
  2. Vraag je provider om hun External MFA-integratie (App ID, client ID, discovery URL); een provider die alleen custom controls ondersteunt is de echte blokkade.
  3. Voeg de methode toe, geef consent en scope hem op een pilotgroep.
  4. Registreer de pilotgebruikers, of laat ze dat zelf doen.
  5. Sluit de pilotgroep uit van de custom control-policy en neem hem op in de MFA-policy; controleer de sign-in logs, PIM-activatie en Security info.
  6. Breid de groep uit, zet daarna de custom control-policy uit en verwijder de control.
Voor de inventarisatie en de registratie door een admin is Graph PowerShell genoeg: 
Connect-MgGraph -Scopes "Policy.Read.All","UserAuthMethod-External.ReadWrite.All"

# Conditional Access-policies die een custom control vereisen
Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object { $_.GrantControls.CustomAuthenticationFactors } |
    Select-Object DisplayName, State,
        @{N='CustomControls'; E={ $_.GrantControls.CustomAuthenticationFactors -join ', ' }},
        @{N='BuiltIn';        E={ $_.GrantControls.BuiltInControls -join ', ' }},
        @{N='Operator';       E={ $_.GrantControls.Operator }}

# External MFA-methoden in de authentication methods policy
$amp = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy"
$amp.authenticationMethodConfigurations |
    Where-Object { $_.'@odata.type' -eq '#microsoft.graph.externalAuthenticationMethodConfiguration' } |
    ForEach-Object { [pscustomobject]@{ Id = $_.id; Name = $_.displayName; State = $_.state; DiscoveryUrl = $_.openIdConnectSetting.discoveryUrl } }

# External MFA registreren namens een gebruiker
# (de ingelogde admin heeft Authentication Administrator of Privileged Authentication Administrator nodig)
$body = @{ configurationId = "<Id uit de vorige output>"; displayName = "<naam van de methode>" } | ConvertTo-Json
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/users/<user id>/authentication/externalAuthenticationMethods" -Body $body -ContentType "application/json"

Wat gebruikers zien

De methode verschijnt in de methodekeuze onder de display name die je hebt gekozen, en wie hem selecteert komt op de eigen pagina van de provider terecht. Hoe vaak dat gebeurt, bepaalt je sign-in frequency, dus dit is een goed moment om je reauthenticatie-instellingen na te lopen in plaats van de opzet van de custom control over te nemen. Eén bekend gat: Windows 10 OOBE ondersteunt External MFA niet voor een identiteit die geen andere methode heeft, en Microsoft is niet van plan dat nog toe te voegen; op Windows 11 werkt het wel.

Deze week op de lijst: het inventarisatiescript draaien, je MFA-leverancier vragen om de gegevens van hun External MFA-integratie, en een pilotgroep inrichten met een of twee admins die PIM gebruiken, want daar zie je het verschil het eerst.

Update maart 2026: In de aankondiging van general availability op de Microsoft Entra-blog (24 maart) kregen custom controls een datum: ze worden op 30 september 2026 deprecated. Ook in maart (pagina gedateerd 18 maart) is de system-preferred-rangorde op Learn herschreven en staan Microsoft Authenticator-notificaties nu boven External MFA, in lijn met het number matching-voorbeeld op de manage-pagina.

Update juni 2026: In Microsoft Entra ID security updates: What organizations need to do now heeft Microsoft dit in twee data opgesplitst: custom controls worden op 30 september 2026 uitgefaseerd en zijn in mei 2027 end of life. Op Learn staat nu ook een migratiehandleiding van custom controls naar External MFA.

Update juli 2026: Message Center MC1422061 maakt duidelijk wat de septemberdatum betekent: vanaf dan kun je geen custom controls meer aanmaken of wijzigen, en bestaande blijven werken tot mei 2027. Omdat wijzigen van een custom control altijd al neerkwam op verwijderen en opnieuw aanmaken, kun je na september niets meer aanpassen aan de JSON van de control, ook niet als je provider daarom vraagt.

Bronnen

Geschreven door een expert van Argus IT

Zo’n expert in je team, of zelf zo werken in security, IAM of cloud?

Neem contact op Werken bij Argus IT

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.