Custom controls: l'MFA de tercers que Entra no compta com a MFA

La pàgina de Microsoft Learn sobre els custom controls d'Accés Condicional té un requadre amb vuit coses per a les quals aquell control no serveix. La tercera diu, literalment: «Satisfying multifactor authentication claim requirements». L'usuari passa el segon factor del teu proveïdor i entra, però el token amb què continua navegant no porta la marca d'haver fet MFA.

Convé acotar el titular abans de continuar, perquè això no s'aplica a tot l'MFA de tercers. Un proveïdor federat que emet el claim correcte sí que compta. L'External MFA que Microsoft ofereix avui com a substitut també compta. El que no compta és el mecanisme concret dels custom controls, que és el que es va muntar al seu dia en molts tenants i el que continua funcionant cada matí en uns quants.

Muntem i mantenim Accés Condicional en tenants de clients, així que aquesta pàgina ens toca de prop. La portem ara per una raó de calendari: la mateixa documentació diu que a partir del setembre de 2026 —aquest mes— ja no es poden crear custom controls nous ni editar els que hi ha.

Primer, mira si en tens un

Gairebé ningú sap de memòria si el seu tenant porta un custom control, perquè qui en té sol haver-lo heretat amb el tenant. Es veu al portal, a la secció «Custom controls» d'Accés Condicional, però això només et diu que existeix; el que importa és quines polítiques el referencien. Això es pregunta a Microsoft Graph.

El recurs conditionalAccessGrantControls de Graph v1.0 té una propietat anomenada customAuthenticationFactors, descrita com «List of custom controls IDs required by the policy». Si en alguna política ve amb contingut, aquí tens la resposta. Amb l'SDK de PowerShell i permís Policy.Read.All:

Connect-MgGraph -Scopes Policy.Read.All

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object { $_.GrantControls.CustomAuthenticationFactors } |
  Select-Object DisplayName, State,
    @{n='CustomControls'; e={ $_.GrantControls.CustomAuthenticationFactors -join ', ' }}

Si no retorna res, aquest post no va amb tu i t'has estalviat la resta. Si retorna alguna cosa, apunta el nom d'aquelles polítiques: són les que cal revisar, i el que és interessant no és que caduquin, sinó què han estat cobrint fins avui.

Què és un custom control, i per què això ho explica tot

La documentació ho descriu així: el navegador de l'usuari es redirigeix al servei extern, allà fa el que hagi de fer, i torna; Entra verifica la resposta i, si és vàlida, l'usuari continua el flux d'Accés Condicional. Una redirecció i una tornada, i aquí hi ha l'explicació de les vuit limitacions: Entra no rep una asserció d'autenticació que pugui integrar al token, sinó un «aquest usuari ha tornat i el proveïdor diu que sí», que li serveix per prendre aquella decisió d'accés en aquella política concreta i per res més.

La primera frase de la pàgina, per cert, diu una cosa que a molta gent sorprendrà: «Custom controls are a preview capability of Microsoft Entra ID». Mai no va sortir de preview, i ha sostingut el segon factor d'organitzacions senceres durant anys.

Les vuit, i què significa cadascuna al teu tenant

Aquests són els vuit usos exclosos, en l'ordre en què els enumera Microsoft, amb la traducció al que passa en un tenant real:

Llegeix-la un altre cop pensant en un quadre de compliment. No són casos rars: són l'elevació de privilegis, l'alta de dispositius, la recuperació de compte, la resposta automàtica al risc, la caducitat de la sessió i la relació amb tercers. El control existeix, es veu al portal, redirigeix i funciona cada dia, i no cobreix cap d'aquelles sis coses.

És el mateix patró del qual ja hem parlat aquí: una casella marcada que no equival a un control exercit. Ho vam veure amb un informe d'impacte zero que només mesurava el que sabia mirar i amb el token d'una app connectada que no torna a demanar MFA.

La data: el mes, no el dia

La pàgina de Learn, revisada el 19 de maig de 2026, ho diu així: «Adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Full retirement is scheduled for early 2027». L'avís del centre de missatges de Microsoft 365 —MC1422061, publicat el 9 de juliol de 2026, visible només des del mateix inquilí— coincideix al setembre de 2026 per al congelat, però situa la retirada total al maig de 2027 amb una data d'actuació del 30 d'abril de 2027.

Dues fonts oficials, dues redaccions diferents: «principis de 2027» i «maig de 2027» no són el mateix, i nosaltres planifiquem contra la més primerenca de les dues, perquè el cost d'equivocar-se en aquella direcció és tenir la feina feta abans d'hora. Hi ha a més un detall que gairebé ningú mira: cap de les dues no dona un dia de setembre. Si comptes amb fer un darrer ajust abans que es tanqui la finestra, no saps quin matí et trobaràs el botó en gris.

«Editar» vol dir esborrar i tornar a crear

Aquí és on el congelat de setembre deixa de ser una molèstia burocràtica. La secció «Editing custom controls» de la documentació té una sola frase: «To edit a custom control, delete the current control and create a new one with the updated information». I per esborrar-lo, diu unes línies abans, «ensure that it isn't being used in any Conditional Access policy».

Encadena les tres regles: des del setembre no pots crear, per editar cal esborrar, i per esborrar cal desvincular-lo de tota política. El control que tens muntat és d'un sol ús. Si el teu proveïdor canvia el bloc JSON —renovació de certificat, canvi d'endpoint, una migració seva— no el pots aplicar, i si l'esborres per intentar-ho, no torna. Això no és un termini de migració: és una peça que ja no es pot reparar.

El que la documentació NO diu

Ens falta una dada i preferim dir-ho que omplir-ho: en cap de les dues pàgines oficials que hem llegit s'explica què li passa a una política d'Accés Condicional que referencia un custom control el dia que la funció es retiri del tot. Deixa d'aplicar-se la concessió i l'usuari entra sense més? Bloqueja? La política queda invàlida? No ho diu. Circula per aquí l'afirmació que s'obre —que l'usuari passa sense desafiament i sense avís—, però no l'hem pogut ancorar a una font de Microsoft, així que no la donem per bona. I un control de seguretat el mode de fallada del qual no està documentat obliga a moure fitxa abans de la data, no després.

El reemplaçament porta la seva pròpia lletra petita

El substitut es diu External MFA (abans «external authentication methods») i funciona d'una altra manera: es configura amb un Client ID, un Application ID d'una app multiinquilí del proveïdor i una Discovery URL, que és l'endpoint de descobriment OIDC. Es gestiona des de la directiva de mètodes d'autenticació, diu la documentació, «just like built-in methods». Això arregla el problema de fons: la mateixa pàgina afirma que aquests usuaris «can use an external MFA to satisfy MFA», i descriu com se'ls redirigeix al proveïdor segons els requisits de frescor configurats a les polítiques de freqüència d'inici de sessió. Les dues coses que el mecanisme vell no podia fer.

Dit això, no és gratis. El que ens apuntem abans de tocar un tenant:

Per a la transició, la part més útil de tot el material és la guia de convivència: Microsoft recomana dues polítiques d'Accés Condicional —una que exigeix el custom control i una altra que exigeix MFA— amb un grup de prova a cadascuna, però no a totes dues. Si un usuari cau a les dues ha de satisfer-les totes dues, i acaba redirigit al proveïdor extern dues vegades seguides. Després ve el que de debò justifica el projecte i gairebé ningú apunta, perquè creu que ja ho tenia: tornar a posar MFA a l'elevació de PIM, a la inscripció de dispositius i a les polítiques de risc.

El que un s'emporta d'aquí

Que un control estigui actiu no diu res sobre el seu abast. Aquest redirigeix usuaris a un proveïdor d'MFA, es cobra la seva llicència i surt en verd a l'informe, mentre la pàgina del mateix fabricant enumera, en lletra petita, vuit usos per als quals no serveix. Ningú va mentir; ningú va llegir el requadre. Per això insistim que el Zero Trust s'audita per efecte i no per configuració: la pregunta no és si la política està posada, sinó què li passa exactament a qui intenta passar.

El pla d'identitat, com vam escriure en el seu dia, no és una aplicació més del catàleg. Si aquest mes has de revisar alguna cosa del teu tenant, mira també què va canviar l'1 de setembre amb les passkeys: són dos moviments de la mateixa peça.

I si la resposta a «tenim un custom control?» a casa teva és «caldria mirar-ho», allà dalt tens la consulta. Nosaltres això ho mirem com a part de la feina de Microsoft 365 i de ciberseguretat, i el normal, per sort, és no trobar-ne cap.

Fonts (verificades el 3 de setembre de 2026): llista literal de limitacions, condició de preview, congelat del setembre de 2026, retirada «early 2027», procediment d'edició i esborrat i avís sobre el JSON — Microsoft Learn, «Custom controls in Microsoft Entra Conditional Access» (revisió del 19-maig-2026). Dates de maig de 2027 i 30 d'abril de 2027 i passos de migració — avís del centre de missatges de Microsoft 365 MC1422061, publicat el 9-jul-2026 (visible només des de l'inquilí). Configuració d'External MFA, rols, nota sobre el kid en base64, exclusió dels informes de registre, comportament davant la pèrdua de consentiment, guia de convivència amb dues polítiques i limitació de Windows 10 a l'OOBE — Microsoft Learn, «How to manage external MFA in Microsoft Entra ID» (actualització del 15-jun-2026). Propietat customAuthenticationFactors — Microsoft Graph v1.0, «conditionalAccessGrantControls». No hem trobat en fonts de Microsoft el comportament d'una política que referenciï un custom control després de la retirada; per això no ho afirmem.