Passkeys l'1 de setembre: els casos que no encaixen

El 25 de juliol vam publicar aquí el calendari de la retirada de l'SMS i la veu a Entra ID, quan l'anunci tenia dotze dies. Cinc dies després d'aquell post Microsoft va publicar una FAQ que en aquell moment no existia, i demà passat arriba la primera de les dues dates. Així que aquest no és el mateix article un altre cop: és el que continua sense resoldre's a quaranta-vuit hores de l'1 de setembre, i són gairebé tot casos rars.

Conflicte d'interès per endavant: administrem inquilins de Microsoft 365 de clients i venem lloc de treball gestionat, així que ens fa guanyar diners que això et preocupi. Per això tot el que ve porta la font enganxada, i la font és la documentació pública de Microsoft. Contrasta-ho tu.

Què passa demà passat, en una frase

No cau cap sessió. El que canvia l'1 de setembre és la configuració del teu inquilí: els usuaris habilitats per a SMS o veu a l'Authentication Methods Policy —o a la configuració heretada d'MFA— queden autohabilitats per a passkeys, en un perfil que admet tots els tipus, i la teva campanya de registre passa a estat «Microsoft Managed» apuntant a passkeys, amb aquests usuaris ja dins de l'abast. El pròxim cop que facin MFA els surt l'avís, i per defecte poden posposar-lo indefinidament.

La campanya de registre és una política teva: l'administres des d'Entra ID > Authentication methods > Registration campaign. La documentació deixa l'única sortida admesa escrita en una frase seca: «si no vols que això passi, treu els usuaris d'SMS o veu a l'AMP abans de l'1 de setembre». És a dir, la manera que el proveïdor no et toqui la política és fer tu, en quaranta-vuit hores, allò mateix cap a on la política empeny. S'entén el disseny, i continua sense agradar-nos el mecanisme.

La taula de fites de l'article té tres files, no dues: l'1 de setembre, l'1 de febrer del 2027 —quan es retira el lliurament d'SMS i veu que dona Microsoft— i una tercera que descriu què passa després d'aquesta data. Cinc mesos entre la primera i la segona. Això és tot el marge que hi ha, i comença demà passat.

La sortida per operador propi té les seves pròpies dates

Convé repetir el matís que el titular es menja, perquè decideix el que has de fer: el que es retira és l'SMS que lliura Microsoft. El títol de la mateixa pàgina porta l'adjectiu al davant, Microsoft-provided, i la FAQ confirma que els inquilins que configurin un operador propi «poden continuar usant SMS o veu segons les polítiques de la seva organització».

El que canvia respecte al juliol són les condicions, que ja estan datades. La informació sobre els operadors no es publica fins al 18 de setembre del 2026, i la possibilitat de seleccionar-ne i configurar-ne un no arriba fins al 30 d'octubre del 2026. La FAQ és honesta i vaga alhora sobre el preu: sí que hi ha cost, varia per proveïdor i regió, i és típicament per missatge segons volum i distribució geogràfica. Migrar a passkeys, diu, no costa res addicional.

La nostra lectura, marcada com a lectura i no com a fet publicat: això no és una alternativa còmoda, és una sortida d'emergència estreta. Se't demana decidir ara sobre una opció el preu de la qual no coneixeràs fins d'aquí a tres setmanes i que no podràs contractar fins a finals d'octubre, amb la porta tancant-se l'1 de febrer. Si el teu pla és «ja contractaré un operador», entre el dia que s'obre la contractació i el tall queden poc més de tres mesos per triar proveïdor, signar i pilotar.

El «No» de la FAQ, i el que diu tres línies més avall

La FAQ porta una pregunta que es titula, literalment, «Es quedaran els clients bloquejats fora dels seus comptes l'1 de febrer del 2027?». La resposta comença amb un «No» i continua així: rebran un avís bloquejant de registre, ja no se'l podran saltar i hauran de completar el registre de la passkey abans de poder continuar entrant. L'article principal ho repeteix amb les mateixes paraules i hi afegeix, en negreta i tres vegades al llarg de la pàgina, que per a aquest comportament no hi ha exclusió possible i que s'aplica a tots els inquilins.

Tècnicament el «No» és correcte: el compte no es tanca. Però per a l'usuari la distinció entre «compte bloquejat» i «no passes fins que facis una cosa» només existeix si aquesta cosa la pot fer on és i amb el que porta a sobre. El comercial a l'aeroport, l'operari del magatzem amb un mòbil d'empresa sense biometria configurada, la persona d'administració que entra des d'un equip compartit: per a aquests tres, l'1 de febrer un «No» de la FAQ val exactament el mateix que un sí.

On cau la feina: el restabliment de contrasenya

La retirada no és només del segon factor. La FAQ ho contesta en una línia: la retirada de l'SMS i la veu natius «aplica a tot Entra, inclòs el restabliment de contrasenya d'autoservei». I hi afegeix la porta del darrere a la frase següent, que convé no tallar: els usuaris sí que poden continuar fent servir SMS i veu si contractes operador propi al Security Store. Sense operador propi, l'SSPR per SMS se'n va amb tota la resta.

És una cadena curta i bastant lletja. Qui oblidava la contrasenya i la recuperava només amb un codi per SMS deixa de poder-ho fer. Aquest usuari no truca a seguretat: truca a qui despenja el telèfon, un dilluns al matí, alhora que altres vint. I la mateixa FAQ reconeix que la peça que tancaria aquest forat encara no existeix: Microsoft diu que planeja introduir suport perquè canviïn la contrasenya els usuaris que entren sense contrasenya, i remata amb un «més detalls properament». Quan la documentació d'un proveïdor diu això a cinc mesos del tall, no és una funció: és una intenció.

Qui no hi és, i el forat dels convidats

Toca dir també a qui no afecta, perquè hi ha bastant gent espantada sense motiu. El calendari val només per al núvol públic; els altres entorns aniran després i Microsoft diu que avisarà amb antelació. Azure AD B2C queda fora i no l'afecta. Microsoft Entra External ID té el seu propi anunci l'any que ve. I els mètodes d'MFA externs no hi entren, tret que a més l'usuari estigui habilitat per a SMS o veu.

I després hi ha els convidats, que a la FAQ ocupen dues frases seguides que convé llegir juntes. Una: el suport de passkeys per a usuaris B2B i convidats interns «està previst que estigui disponible per a finals de l'any natural 2026». Dues, immediatament després: «aquests usuaris estan inclosos en l'abast de la retirada». El substitut està previst per al desembre i la porta es tanca al febrer. Si el teu negoci viu de col·laborar amb externs —assessories, enginyeries, qualsevol amb una carpeta compartida amb proveïdors— aquesta és la casella que miraríem primer, i aquesta setmana. Va en la línia del que explicàvem sobre el directori amb més fitxes que empleats: el problema gairebé mai són els teus empleats, són els que no ho són.

L'única cosa urgent aquesta setmana és un número

Tot l'anterior és opinió fins que sàpigues quants usuaris del teu inquilí continuen habilitats per a SMS o veu. Amb aquest número al davant, la decisió es pren sola: si en són quatre, això és una tarda; si en són cent quaranta, és un projecte amb comunicació a usuaris i finestra de suport reforçat.

Microsoft publica un script per treure-ho, l'entra-sms-voice-usage-analyzer, a la seva organització de GitHub. Demana tenir actiu un d'aquests tres rols: lector global, administrador de directives d'autenticació o lector de seguretat. La FAQ resumeix el criteri d'abast en una línia que va molt bé per a un correu intern: qualsevol resultat diferent de zero significa que hi ets a dins.

L'interruptor de sortida existeix, viu a /beta, i no te'l recomanem

Hi ha una exclusió temporal per al tram de l'1 de setembre a l'1 de febrer. No és al portal: s'aplica amb una crida a Microsoft Graph, amb el permís Policy.ReadWrite.AuthenticationMethod, posant la propietat passkeyDynamicMigration a true dins d'optOutSettings a la directiva de mètodes d'autenticació. L'endpoint que documenta Microsoft per a aquesta crida és /beta.

Dues coses sobre això. La primera és d'ofici: escriure a /beta vol dir que la forma d'aquesta crida pot canviar sense que ningú t'avisi, així que si l'apliques, apunta-la amb data i amb responsable i posa't un recordatori per revisar-la al gener. La segona és criteri nostre: fes-lo servir només en dos casos. Un, que ja tinguis decidit amb data que contractaràs operador propi i només necessitis arribar al 30 d'octubre. Dos, que l'1 de setembre t'agafi enmig d'una altra migració i no puguis fer soroll a l'inici de sessió. Fora d'aquí et compra cinc mesos que no faràs servir, i l'1 de febrer arriba igual, amb la diferència que llavors l'avís ja no es pot posposar.

El que la documentació no diu i sí que decideix el teu dilluns

Hem llegit les dues pàgines senceres i hi ha una cosa que no apareix en cap: els comptes d'emergència. Aquest parell de comptes d'administrador global que gairebé tothom té apartats per al dia que cau l'accés condicional o el proveïdor d'identitat. Si algun d'ells té com a segon factor un SMS a un número d'empresa, aquest és el primer que cal moure, i ho diem com a criteri propi i no com a citació: no volem descobrir al febrer que el compte reservat per a quan res no funciona depèn justament d'allò que s'acaba de retirar. És la mateixa idea que ja vam escriure sobre tractar el proveïdor d'identitat com a infraestructura i no com una aplicació més.

L'altra peça que no és a la taula de dates és l'inventari de qui pot registrar una passkey i qui no. Microsoft admet dues famílies: les sincronitzades, que viuen en un gestor de credencials de plataforma com iCloud Keychain o Google Password Manager i viatgen entre els dispositius de l'usuari, i les lligades a un dispositiu, que inclouen la passkey del mateix Authenticator, Entra Passkey a Windows i les claus FIDO2 físiques. Aquesta distinció decideix si l'usuari del taller necessita una clau de maquinari o li val el mòbil que ja porta, i també on acaba vivint la credencial: si t'interessa aquesta segona part, la vam explicar en el seu dia mirant de què està feta una passkey sincronitzada. Aquest inventari no te'l farà cap script.

On som nosaltres

En el fons de l'assumpte estem d'acord amb Microsoft. El seu argument és que l'SMS i la veu es troben «entre els mètodes d'autenticació més vulnerables disponibles avui» i protegeixen bastant pitjor que una passkey davant el phishing i el robatori de comptes; el nostre és més terrenal i ve d'arreglar incidents: un codi que viatja a un número de telèfon es pot demanar per un altre camí, i el segon factor que es pot demanar per un altre camí no és un segon factor, és un tràmit. Ja ho vam veure amb el token que no torna a demanar MFA: el que trenca un compte gairebé mai és la contrasenya.

El que no ens convenç és la coreografia. Una data en què el proveïdor et canvia una política de l'inquilí, una alternativa el preu de la qual es publica disset dies després d'aquesta data, una contractació que no obre fins al 30 d'octubre, un forat declarat en els convidats i un tall dur sense exclusió possible. Tot això és defensable per separat i bastant incòmode junt, sobretot per a una empresa de trenta persones sense ningú dedicat a identitat a temps complet. És l'asimetria de sempre: el calendari el posa qui no atendrà les trucades del dilluns.

Si només t'endús una cosa de tot això: treu el número aquesta setmana. És l'única cosa que no pot esperar, i és també l'única que converteix aquesta conversa en un pla.

Fonts (consultades el 30 d'agost del 2026): totes les dates, comportaments, propietats i frases entre cometes surten de dues pàgines de la documentació oficial de Microsoft: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (Microsoft Learn, actualitzada el 10 d'agost del 2026) i la seva FAQ (datada el 30 de juliol i actualitzada el 3 d'agost del 2026, és a dir publicada després del nostre post del 25 de juliol). En concret, de l'article principal: la taula de fites amb les seves tres files —1 de setembre del 2026, 1 de febrer del 2027 i el comportament posterior a aquesta data—, l'avís bloquejant i les tres mencions en negreta que no hi ha exclusió possible; l'autohabilitació a l'AMP, el perfil amb tots els tipus de passkey, el pas de la campanya de registre a «Microsoft Managed», els ajornaments il·limitats i la frase sobre treure els usuaris d'SMS o veu abans de l'1 de setembre, al requadre «Important»; la ruta Entra ID > Authentication methods > Registration campaign, al pas 2; el 18 de setembre del 2026 per a la publicació de la informació d'operadors i el 30 d'octubre del 2026 per poder seleccionar-los i configurar-los, al pas 3; l'opt-out temporal amb passkeyDynamicMigration, el permís Policy.ReadWrite.AuthenticationMethod i l'endpoint /beta, a la secció d'exclusió temporal; l'script entra-sms-voice-usage-analyzer amb els seus tres rols, al pas 1; i la descripció de les dues famílies de passkeys. De la FAQ: la citació «entre els mètodes d'autenticació més vulnerables disponibles avui»; el cost per missatge de l'operador propi i que migrar a passkeys no afegeix cost; l'abast a tot Entra inclòs l'SSPR, juntament amb la frase immediatament posterior segons la qual els usuaris sí que poden continuar usant SMS i veu mitjançant un operador contractat al Security Store; el «més detalls properament» sobre el canvi de contrasenya sense contrasenya; l'abast només a núvol públic; l'exclusió d'Azure AD B2C i l'anunci separat d'External ID; el suport de passkeys per a B2B previst per a finals del 2026 juntament amb el fet que aquests usuaris sí que són dins de l'abast de la retirada; que els mètodes d'MFA externs no hi entren tret que l'usuari també estigui en SMS o veu; el criteri que qualsevol resultat diferent de zero significa ser dins de l'abast; i la pregunta sobre bloqueig de comptes amb la seva resposta «No». Són nostres, i les marquem com a criteri i no com a fets publicats: que la sortida per operador propi és estreta per l'ordre de les seves pròpies dates; que el cost real d'això cau al servei de suport per la via de l'SSPR; que el forat dels convidats és la casella a mirar primer si treballes amb externs; la recomanació de no fer servir l'opt-out tret dels dos casos citats; l'advertiment sobre escriure en un endpoint /beta; i l'avís sobre els comptes d'emergència, que la documentació no esmenta en cap de les dues pàgines.