El telèfon de la fitxa era una credencial: Entra ID deixa d'acceptar-lo

Pensa en el camp «telèfon mòbil» de la fitxa d'un empleat qualsevol del teu directori. Qui el va escriure? A la majoria d'empreses que coneixem aquell número no el va posar l'usuari: va arribar d'una sincronització des de l'Active Directory de casa, o d'algú que estava donant d'alta una persona un dimarts al matí. I fins ara, amb aquell camp omplert, aquella persona podia restablir la contrasenya al portal d'autoservei. Microsoft deixarà d'acceptar-ho.

Què canvia exactament

L'autoservei de restabliment de contrasenya de Microsoft Entra ID —SSPR, per les sigles en anglès— passarà a exigir mètodes d'autenticació registrats explícitament per verificar qui demana el canvi. Les dades de contacte que viuen als atributs del directori deixaran de valer si l'usuari no les ha registrades com a mètode. La documentació anomena els tres: mobilePhone, businessPhone i otherMails. L'avís del centre de missatges que ho descriu és el MC1325414 i afecta tots els inquilins amb SSPR activat, al núvol públic i als núvols de govern dels Estats Units.

La raó que dóna Microsoft és que la verificació passi a basar-se en «mètodes de confiança validats per l'usuari, en lloc d'atributs procedents del directori». És una frase de nota de producte, però descriu amb precisió el que hi havia abans.

Qui escriu aquell camp

El que és interessant és que això no era un descuit tapat: està documentat com a funcionalitat, amb pàgina pròpia a Microsoft Learn i amb un títol que ho diu tot, «Emplenar prèviament la informació de contacte d'autenticació». Dues frases d'aquella pàgina, literals:

«Aquestes dades sincronitzades es posen a disposició de Microsoft Entra ID i d'SSPR sense requerir interacció de l'usuari. Quan els usuaris necessitin canviar o restablir la contrasenya, ho podran fer encara que no hagin registrat prèviament la seva informació de contacte.»

«Si vas proporcionar un valor per a Telèfon mòbil o Correu alternatiu, els usuaris poden fer servir aquests valors immediatament per restablir les contrasenyes, encara que no s'hagin registrat al servei.»

La mateixa pàgina porta la taula de correspondències del connector de sincronització: telephoneNumber de l'Active Directory local passa a ser Telèfon d'oficina, i mobile passa a ser Telèfon mòbil. Amb això ja hi ha el circuit complet. Un valor escrit en un objecte del domini de casa puja per la sincronització i, a l'altre costat, serveix per demostrar identitat al portal de recuperació sense que el seu titular hagi fet res.

La diferència amb un mètode registrat és qui l'escriu. Un mètode registrat el dóna d'alta el mateix usuari des de la seva pàgina d'informació de seguretat, demostrant que controla aquell telèfon o aquella bústia; també l'hi pot posar un administrador amb el rol d'Administrador d'autenticació amb privilegis, que és una llista curta i auditable. Un atribut de contacte l'escriu qualsevol amb permís d'escriptura sobre l'objecte, i aquella llista no l'ha revisada ningú des que es va crear.

Posat així, tenir permís d'escriptura sobre les dades de contacte d'un usuari ha equivalgut, a la pràctica, a poder recuperar el seu compte. Amb la política d'SSPR exigint dos mètodes calen dos camps, mòbil i correu alternatiu, cosa que una delegació sobre l'objecte normalment sí que concedeix. Aquell permís no apareix en cap matriu de rols, no el revisa cap auditoria d'accessos privilegiats i no dispara cap alerta quan canvia. Ningú el va concedir a propòsit: es va colar per la porta del darrere d'una funcionalitat pensada perquè la gent no truqui al suport el primer dia.

La pregunta que surt d'aquí es respon en una tarda i no depèn de Microsoft: qui pot escriure avui a les dades de contacte d'un usuari qualsevol del teu directori? Fes la llista de debò, amb noms. Si hi apareix gent d'administració, o un procés automatitzat que ningú manté, ja saps per on es recuperen comptes a la teva empresa. Sobre el que s'acumula en un directori quan ningú el mira en vam escriure fa unes setmanes, explicant per què hi ha més fitxes que empleats.

El cas híbrid, que és el que més fa mal

Si sincronitzes des d'un Active Directory local, aquell número no neix a Entra. Neix en un objecte del domini de casa, i el permís d'escriptura sobre els atributs de contacte d'una unitat organitzativa és exactament el tipus de delegació que es va fer fa deu o quinze anys perquè administració pogués actualitzar números de contacte sense molestar sistemes. No hi ha res de malintencionat. Simplement, la cadena completa —qui escriu a l'AD local, què puja per la sincronització, què accepta el portal de recuperació— mai es va dibuixar sencera en una sola pissarra.

És la mateixa idea que vam defensar en explicar que el teu proveïdor d'identitat no és una aplicació més: si el directori decideix qui entra a tot, els permisos sobre el directori pesen més que els permisos sobre qualsevol aplicació de les que en pengen. Un camp de text inclòs.

El 86 %: mira el denominador

La xifra que acompanya aquest canvi i que tranquil·litza tothom és aquesta: aproximadament el 86 % de les verificacions d'SSPR ja fan servir mètodes registrats. El substantiu importa. Són verificacions, no usuaris.

Una verificació la genera algú que fa servir el sistema. Pensa en la persona que va entrar el 2019, se sap la contrasenya de memòria i no ha trepitjat mai el portal de recuperació: no aporta ni una verificació a aquella estadística, ni per bé ni per mal. És invisible al numerador i al denominador. I és exactament qui es trobarà la porta tancada el dia que la necessiti, probablement després d'unes vacances o d'una baixa llarga, que és quan a la gent se li oblida la contrasenya. El 86 % descriu com li va al que ja fa servir el sistema. No diu res del que no l'ha fet servir mai.

La mesura útil és una llista de comptes, no un percentatge. Es treu de l'informe de detalls de registre d'usuari del centre d'administració d'Entra, a Mètodes d'autenticació → Supervisió, filtrant per usuaris capaços d'SSPR; o per línia d'ordres, que és més còmode de repetir cada setmana:

Get-MgReportAuthenticationMethodUserRegistrationDetail -All ``
  -Filter "isSsprEnabled eq true and isSsprRegistered eq false" ``
  | Select-Object UserPrincipalName, UserDisplayName

Un advertiment sobre aquell informe, perquè va just en la direcció del problema: no hem trobat documentat si isSsprRegistered distingeix un mètode registrat per l'usuari d'un valor heretat del directori. Si no ho distingeix, l'informe arrossega el mateix biaix que el 86 % i deixa fora la gent que corre perill. Contrasta-ho en una mostra petita mirant els atributs en cru, que és mitja dotzena d'ordres:

Get-MgUser -UserId '[email protected]' ``
  | Select businessPhones, mobilePhone, otherMails | Format-Table

Quatre dates per a un mateix tall

Si has llegit alguna cosa sobre això els últims mesos, probablement portis apuntat el 7 de setembre del 2026. Aquella era la data de la primera versió de l'avís, publicat el 28 de maig. El MC1325414 es va actualitzar el 4 d'agost i el calendari es va moure sencer. Però en recopilar les dates ens vam trobar que no n'hi ha una, n'hi ha quatre, i no quadren entre si:

L'última fila és la que importa, i no és un matís. Microsoft Learn té les dues dates invertides respecte al centre de missatges: diu que el 5 d'octubre «SSPR només acceptarà mètodes d'autenticació registrats explícitament» i que la campanya de registre arrenca el 9 de novembre. És a dir, la campanya que serveix per preparar la gent arribaria un mes després del tall. Una de les dues pàgines està malament, i des de fora no es pot saber quina.

La conclusió pràctica és curta: planifica com si el 5 d'octubre fos la data de tall, perquè és la primera data en què una pàgina oficial de Microsoft diu que això deixa de funcionar. I confirma-ho al teu propi centre de missatges, que és on hi ha la versió que aplica al teu inquilí. Nosaltres llegim el MC1325414 en arxius públics que recopilen aquests avisos, no en un tenant real.

Això no ve sol

El canvi d'SSPR és una peça d'un moviment més gran i els terminis se solapen. Des de l'1 de setembre del 2026, fa cinc dies, els usuaris habilitats per a SMS o veu s'autohabiliten per a claus d'accés i entren en una campanya de registre gestionada per Microsoft que els insisteix en completar el segon factor. I a partir de l'1 de febrer del 2027 es retira el lliurament d'SMS i veu proporcionat per Microsoft: qui el necessiti haurà de contractar un proveïdor de telecomunicacions propi a través de la botiga de seguretat de Microsoft. La documentació no deixa marge: «No hi ha exclusió voluntària d'aquest comportament de l'1 de febrer. S'aplicarà a tots els inquilins». Hi ha una exclusió temporal, sí, però només cobreix el tram de setembre a febrer.

Sobre l'arrencada de setembre i els casos que no encaixen al guió feliç ja en vam escriure amb detall fa uns dies. I si el teu pla passa per recolzar-te en un doble factor de tercers, convé llegir abans per què hi ha un MFA que Entra no compta com a MFA. La lliçó s'assembla a la d'avui: el que val és el que el directori reconeix com a mètode, no el que tu saps que l'usuari té.

El que faríem, en ordre

• Treure la llista de comptes habilitats per a SSPR sense mètodes registrats. Amb nom i cognoms, i repetir-la cada dilluns fins que baixi a zero.
• Auditar qui escriu als atributs de contacte. A Entra i, si ets híbrid, a l'AD local. Fins al tall, aquella llista és la teva llista real de gent capaç de recuperar comptes d'altri. Després del tall passa a ser una altra, molt més curta: la de qui té rol d'administrador d'autenticació amb privilegis. Val la pena mirar-se les dues, perquè canvia de mans un privilegi.
• No esperar la campanya de Microsoft. Llançar la teva abans del 5 d'octubre, amb el teu text i el teu to, reparteix la càrrega en setmanes en comptes de concentrar-la el dia que el sistema comenci a insistir pel seu compte. I si Learn té raó amb les dates, la campanya de Microsoft arribaria tard.
• Definir el camí de suport humà. Qui no pugui registrar-se ni restablir acabarà trucant, i allà qui verifica identitat és una persona amb pressa. Escriu com es verifica qui truca abans que calgui, perquè aquell passa a ser el teu camí de recuperació de debò i és el més fàcil d'enganyar.
• Assajar-ho amb un compte de debò, cronòmetre a la mà.

L'últim punt és el que se salta tothom i l'únic que descobreix alguna cosa. En infraestructura ho diem així des de fa anys: una còpia sense provar no és una còpia, és un amulet. La recuperació d'identitat es comporta igual, i li vam dedicar un post sencer al pla de continuïtat que ningú ha assajat, perquè el patró es repeteix a tot arreu. El que només es prova el dia de l'incident és just el que no et pots permetre que falli aquell dia.

Quan això no va amb tu

Si tens vint persones, totes amb Authenticator registrat i el mòbil a la mà, aquest canvi et passarà per damunt sense que te n'assabentis, i està bé que sigui així. No cal muntar un projecte. Però el problema de fons té una versió domèstica que aplica a qualsevol: mira l'adreça de correu de recuperació del compte del teu registrador de dominis, o del tauler del teu proveïdor de núvol. En més casos dels que sembla apunta a la bústia d'algú que ja no treballa aquí, o a una llista de distribució que llegeix mitja empresa. Allà la dada de recuperació tampoc la controla el titular del compte, i no hi ha cap Microsoft que ho vagi a arreglar per tu.

Ens quedem amb dues preguntes per a un empleat qualsevol del teu directori. Quin camp seu, escrit per qui, podria avui tornar-li l'accés al seu compte. I què passa quan aquell camp deixi de valer i ell no hagi registrat res.

Fonts: les dues frases citades sobre l'ús de dades sincronitzades sense registre previ, la taula de correspondències telephoneNumber/mobile, el rol d'Administrador d'autenticació amb privilegis, les ordres de lectura d'atributs i les dates del 5 d'octubre i el 9 de novembre procedeixen de «Emplenar prèviament la informació de contacte d'autenticació de l'usuari per a SSPR», Microsoft Learn. L'identificador MC1325414, la data de publicació (28 de maig del 2026), la d'actualització (4 d'agost del 2026), l'abast i les dates del centre de missatges —títol el 9 de novembre, cronologia amb campanya el 5 d'octubre i aplicació el 7 de novembre, camp «actuar abans de» el 6 de novembre— surten de l'arxiu públic del centre de missatges de Microsoft 365. Les dates de la primera versió (campanya el 6 de juliol, aplicació el 7 de setembre) i la frase de Microsoft sobre «mètodes de confiança validats per l'usuari», de la cobertura de Petri. La xifra del 86 % de les verificacions i el Get-MgReportAuthenticationMethodUserRegistrationDetail, de Tony Redmond a Office 365 for IT Pros, 17 de juny del 2026. Les dates de claus d'accés i de la retirada d'SMS i veu, i la frase sobre l'absència d'exclusió voluntària, de Microsoft Learn, actualitzat el 10 d'agost del 2026. El que no afirmem: no hem llegit el MC1325414 en un inquilí real, sinó en arxius públics que recopilen els missatges, així que les dates les has de confirmar al teu propi centre de missatges; no sabem quina de les dues pàgines de Microsoft té bé les dates, només que es contradiuen; no sabem si l'informe de registre distingeix un mètode registrat d'un atribut heretat, i ho diem on toca; no sabem quantes empreses espanyoles tenen usuaris sense mètodes registrats, perquè ningú publica aquesta dada; i no descrivim cap abús real d'aquest camí, perquè no en tenim cap de documentat per citar.