El recanvi de la política de risc no cobreix convidats (i l'anterior tampoc)

L'1 d'octubre va vèncer el termini que Microsoft portava un any anunciant per a les polítiques de risc heretades d'Entra ID Protection. No hi va haver caiguda, ni correu, ni icona vermella en cap consola — tampoc n'hi va haver el 31 de juliol del 2025, quan aquelles dues pantalles van passar a només lectura i vas deixar de poder-les tocar sense que es notés. El que ens interessa de la data no és el drama, és el que descobreixes en reconstruir aquelles polítiques a Accés Condicional: el control que Microsoft recomana declara per escrit que no està suportat per a usuaris externs i convidats. És la línia que no vam trobar a cap de les guies de migració que vam llegir.

El control de destinació no fa el mateix que el d'origen. Deixa fora un tipus de compte concret, i amb aquell tipus de compte la història completa és més estranya del que explica ningú. I per saber si funciona cal baixar al registre d'inicis de sessió, on el camp que ho explicaria es diu d'una manera que enganya. El que ve surt, gairebé sencer, de llegir-se seguides unes quantes pàgines de la documentació de Microsoft que normalment es llegeixen per separat.

Què es va retirar, amb la citació al davant

Microsoft ho escriu en un requadre d'avís a les dues pàgines que toquen el tema, amb la mateixa data i amb dues redaccions diferents: «The legacy risk policies configured in Microsoft Entra ID Protection are retiring on October 1, 2026» a la pàgina de concepte, i «…will be retired on October 1, 2026» a la del procediment. Són dues polítiques: la de risc d'usuari i la de risc d'inici de sessió, les que es configuraven des d'ID Protection —abans Identity Protection—, no les que vius avui com a condicions dins d'Accés Condicional. Aquestes hi continuen; de fet són la destinació.

El que la documentació no diu és què li passa a l'objecte l'endemà. I aquí hi ha una diferència que val la pena mirar a poc a poc, perquè gairebé tota la cobertura del tema se la salta: les guies que circulen afirmen que les polítiques deixen d'aplicar-se, mentre que l'anunci original de Microsoft, el de juny del 2025, parlava de retirar la interfície d'usuari d'aquelles dues polítiques. No és el mateix apagar una protecció que treure la pantalla des de la qual es configurava. No hem trobat cap frase de Microsoft que digui que deixen d'avaluar-se, així que no la posarem nosaltres.

Si el que passa és el que assumeix tota la indústria —que deixen d'aplicar-se—, la manera de fallar és la que ja coneixem d'altres retirades en aquest mateix producte: una política retirada no retorna error. No hi ha inici de sessió fallit ni alerta ni tiquet; hi ha un usuari marcat com d'alt risc que entra com qualsevol altre dia. És el mecanisme que vam descriure quan Entra va retirar la pertinença dinàmica per memberOf: el que es retira no cau, es queda quiet. I si el que passa és l'altra cosa —que la pantalla desapareix i la regla continua viva—, tampoc no et convé, perquè llavors tens una protecció en vigor que ja ningú no pot llegir ni corregir.

Migrar no és moure, i l'ordre importa

El procediment que publica Microsoft té dos passos obligatoris i un d'opcional, i l'ordre dels dos primers no és decoratiu. Un: crear les polítiques equivalents de risc d'usuari i de risc d'inici de sessió a Accés Condicional en mode només informe i, un cop confirmat el comportament, passar el commutador de «Només informe» a «Activada». Dos: només llavors anar a ID Protection i posar la política antiga a «Deshabilitada». El tercer, que Microsoft marca com a opcional, és crear altres polítiques de risc si calen. Si inverteixes els dos primers —apagar i després construir— et quedes amb la finestra descoberta justament els dies en què estàs tocant identitat.

Hi ha un senyal que això no és automàtic i no és una opinió nostra: a la mateixa pàgina, sota el procediment, Microsoft publica un guió detallat per obrir una incidència de suport dedicada a aquesta migració, amb l'assumpte literal «Migrate legacy ID Protection policy» i la ruta exacta de menús fins a l'equip que l'atén. Un fabricant no documenta un camí de suport per a una cosa que es mou sola.

I un detall que es salta molta gent en reconstruir: Microsoft avisa que no s'han de combinar la condició de risc d'inici de sessió i la de risc d'usuari a la mateixa política d'Accés Condicional. Són dues polítiques separades. Si veníes de dues polítiques a ID Protection i et temptava ajuntar-les en una sola «política de risc» més neta, el fabricant t'està dient que no.

El control recomanat no és el que tenies

Aquí hi ha el primer salt que la paraula «migrar» amaga. Per a risc d'usuari alt, el que Microsoft recomana avui no és «exigir canvi de contrasenya», sinó un control diferent: «Require risk remediation», correcció del risc. I en seleccionar-lo s'apliquen automàticament dos ajustos més: «Require authentication strength» queda seleccionat com a control de concessió, i «Sign-in frequency – Every time» s'aplica com a control de sessió i la documentació el marca com a obligatori. No són opcionals ni els has triat tu: vénen amb el control.

Que sigui millor no vol dir que sigui igual. La força d'autenticació és un control amb criteri propi sobre quins mètodes valen —en vam parlar quan explicàvem per què un MFA de tercers pot no comptar com a MFA per a Entra—, i la reautenticació «cada vegada» és un canvi que l'usuari nota. Si hi arribes el dilluns migrant a corre-cuita i el dimarts reps trucades de gent a qui es demana identificar-se contínuament, no és una errada: és el control que et van recomanar, fent el que porta escrit.

Hi ha a més regles de precedència que importen precisament durant la finestra de convivència: «Require risk remediation» té prioritat sobre «Require password change», i «Block» sobre totes; i Microsoft demana assignar cada usuari a una sola d'aquelles polítiques alhora per evitar conflictes. Durant la migració tindràs, a propòsit, la vella i la nova vives al mateix temps. És el correcte, però convé saber quina mana mentre dura.

La part que no és a cap llista: els convidats

La frase és a la documentació del control, a la secció de consideracions especials, i és tan curta que es passa per alt: «Require risk remediation is not supported for external and guest users because Microsoft Entra ID doesn't support session revocation for those users». No està suportat per a usuaris externs i convidats, perquè Entra no pot revocar sessions d'aquells comptes.

El motiu és coherent i per això no canviarà: la credencial i la sessió d'un convidat viuen al seu tenant d'origen, no al teu. Tu li dónes accés a un recurs; no ets l'amo de la seva identitat. El que sí que és teu és la conseqüència: en una pime que treballa amb proveïdors, consultors, un auditor extern o un client ficat en un Teams compartit, els comptes convidats són justament aquells de qui no controles la higiene de credencials. No veus el seu MFA, no gestiones la seva contrasenya, no saps si el seu portàtil té EDR.

Convé ser precisos, perquè aquí és fàcil passar-se de frenada en la direcció contrària i vendre una regressió que no existeix. La política antiga tampoc no corregia els convidats. Microsoft ho documenta en una pàgina a part, la d'ID Protection per a usuaris B2B: «If a guest user triggers the ID Protection user risk policy to force password reset, they will be blocked», perquè no es poden restablir contrasenyes al directori del recurs; «Guest users do not appear in the risky users report», perquè el risc s'avalua al seu directori d'origen; i un administrador del tenant que convida «cannot dismiss or remediate a risky B2B collaboration user». Traduït: amb la política heretada, el proveïdor en risc el bloquejaves sense tenir manera de desbloquejar-lo tu, i sense veure'l en cap informe.

El que no vas tenir mai, i ara per fi està escrit on toca, és la correcció automàtica del risc d'usuari per a aquells comptes. La capacitat és la mateixa de sempre; el que ha millorat és la franquesa del fabricant. Abans bloquejava el teu proveïdor i ho explicava en una pàgina que calia anar a buscar expressament; ara el control nou ho declara a les seves consideracions especials, a la vista de qui escriu la política.

I llavors què es fa amb els convidats? Aquí la resposta de Microsoft és la contrària de la que esperàvem quan vam començar a llegir, i és la part que més ens ha fet corregir l'esborrany d'aquest post. La seva guia Zero Trust per a accés de convidats diu, literalment: «we recommend that you exclude guests from risk-based MFA policies and require these users to always use MFA». I la guia d'Accés Condicional per a usuaris B2B arriba a explicar el com: crear un grup amb tots els externs de la teva organització i afegir-lo com a exclusió de les teves polítiques basades en risc, tant la d'usuari com la d'inici de sessió. És a dir: per als convidats no es condiciona l'MFA al risc, s'exigeix sempre.

Amb dos paranys que convé saber abans de tocar res, perquè tots dos acaben al mateix lloc —el proveïdor trucant-te perquè no pot entrar—. El primer: la política de risc d'inici de sessió sí que s'avalua per a un convidat, però «if a user hasn't previously registered for Microsoft Entra multifactor authentication in the resource tenant, the user is blocked», i és deliberat, perquè un atacant amb la contrasenya robada no registri el seu propi segon factor a casa teva. El segon és més fi i se'l salta tothom: «you can only apply authentication strength policies to external users who authenticate with Microsoft Entra ID»; per als convidats de contrasenya d'un sol ús per correu, SAML/WS-Fed o federació amb Google cal fer servir el control d'MFA a seques. El convidat de codi per correu és el més comú en una pime, i és justament el que es queda fora de la força d'autenticació.

La resta de la feina amb convidats no és una casella. És abast —què pot tocar i des de quan—, caducitat —revisions d'accés amb data, no per sempre— i la decisió escrita de què s'exigeix a qui entra des de fora. Ho diem sabent que és la part que més s'ajorna: als tenants que portem, el padró de convidats és gairebé sempre l'inventari més vell de la casa.

L'híbrid que no es pot corregir sol

El següent avís no és en aquella pàgina, és a l'altra: la del procediment, just on fas la migració. Hi posa dos requisits previs: els usuaris han d'haver registrat MFA abans de trobar-se en una situació que exigeixi correcció, i per als usuaris híbrids sincronitzats des d'un directori local cal tenir habilitada l'escriptura diferida de contrasenyes (password writeback). Del primer, Microsoft n'escriu també el desenllaç: «Users not registered are blocked and require administrator intervention». I una línia més, que val el seu pes: un canvi de contrasenya fet fora del flux de correcció —l'usuari que entra al seu perfil i la canvia pel seu compte— no compleix el requisit de canvi segur de contrasenya.

Ajunta-ho amb el parc típic d'una pime amb anys a sobre: directori local sincronitzat a Entra, gent que va registrar l'MFA fa tres anys i gent que el va anar esquivant, i una escriptura diferida que algú va configurar al seu dia i ningú no ha tornat a mirar. Un usuari surt marcat com d'alt risc un dilluns al matí. Si no tenia MFA registrat, la documentació diu sense embuts com acaba: bloquejat, i cal un administrador. El que li passa a l'usuari híbrid a qui li falta l'escriptura diferida no ho hem trobat escrit, així que ho diem com el que és —una deducció nostra, i de les que convé provar al teu propi tenant abans de donar-les per bones—: sense writeback no hi ha canvi segur de contrasenya contra el directori local, i sense canvi segur no hi ha autocorrecció. Prova-ho tu; nosaltres no ho podem afirmar.

Com es prova que està migrat (mirar la pantalla no val)

Una política encesa en una pantalla no prova que estigui actuant. La prova viu al registre d'inicis de sessió, i té un parany documentat que convé conèixer abans de donar la feina per tancada. Tres lectures:

• Que la teva política hi aparegui no vol dir que s'apliqués. La secció del registre es diu appliedConditionalAccessPolicies, i la pròpia documentació de Microsoft ho adverteix amb totes les lletres: «the section is called applied Conditional Access policies; however, policies that were not applied also appear in this section». Hi ha una entrada per política. El que et diu alguna cosa és el resultat de l'entrada de la teva, no la seva presència. Si continua en mode només informe, està documentant el que hauria fet; no ho està fent.
• Comprova que hi ha risc per llegir. El camp riskLevelAggregated retorna el valor hidden quan l'usuari o l'inici de sessió no estava habilitat per a ID Protection. Un hidden sobre algú que creus cobert vol dir que la teva política de risc no té d'on llegir. Aquí és on apunta la llicència: les polítiques basades en risc requereixen Microsoft Entra ID P2 (o Entra Suite per a l'accés complet a ID Protection). Sense això, la política existeix i no avalua res.
• Fes-ho amb dos comptes, no amb el teu. Un membre i un convidat. És l'única manera de veure amb els teus ulls el forat de la secció anterior en comptes de refiar-te que algú t'ho expliqui —nosaltres inclosos—. I revisa també les exclusions que la pròpia documentació recomana i que cal refer a la política nova: comptes d'accés d'emergència (break-glass) i comptes de servei. Amb un matís que sorprèn molta gent i està escrit: les crides fetes per entitats de servei no les bloqueja una política d'Accés Condicional dirigida a usuaris; per a això hi ha les polítiques d'identitats de càrrega de treball.

Les excepcions que el teu motor de polítiques ja té

Llegint la mateixa pàgina apareix una cosa que es mereix el seu propi apartat. Durant la correcció del risc, Entra fa servir un flux dedicat i segur per a accions com la revocació de sessió, i la documentació diu que aquell flux «es permet continuar sense veure's afectat per altres polítiques d'Accés Condicional». Publica fins i tot els identificadors: AppId 93625bc8-bfe2-437a-97e0-3d0060024faa al núvol públic i ResourceId 00000003-0000-0000-c000-000000000000.

No és un forat i no el vendrem com a tal. És la sortida d'una abraçada mortal: si la política bloqueja l'usuari en risc, l'usuari no pot corregir el seu risc, i llavors la peça que et protegeix et deixa el compte inservible fins que algú el rescati a mà. L'excepció existeix perquè sense ella el sistema es mossega la cua.

La lectura honesta per a qui està muntant Zero Trust és aquesta: «tot passa per la política» és fals en qualsevol motor de polítiques real, inclòs el teu. El que distingeix una implantació madura no és no tenir excepcions; és tenir la llista escrita, amb el seu identificador, el seu motiu i qui la va signar. La de dalt ve amb les tres coses de fàbrica, i per això és un bon exemple. Les que muntes tu un divendres per desencallar algú, normalment no vénen amb cap —i d'això ja en vam parlar quan explicàvem les polítiques d'Accés Condicional que apareixen al teu tenant sense que les escriguis—.

El que no estem dient

No diem que la retirada sigui dolenta. És millor, i la pròpia pàgina enumera per què: gestionar les polítiques d'accés en un sol lloc, mode només informe, API de Graph, poder exigir reautenticació, combinar el risc amb altres condicions com la ubicació, diverses polítiques de risc apuntant a grups i nivells diferents, millor diagnòstic al registre d'inicis de sessió sobre quina política de risc es va aplicar, i suport del sistema d'autenticació de reserva. Són avantatges reals i les volem.

Tampoc no diem que Microsoft ho hagi amagat. L'avís és en un requadre, amb la data, a les dues pàgines que toquen el tema; l'hem citat literal més amunt. El que ens grinyola és el verb. «Migrar» suggereix moure una cosa d'un lloc a un altre amb les seves propietats intactes, i aquí el que cal fer és reconstruir-ho, comprovar-ho i acceptar que el resultat no és idèntic. Amb una part —els convidats— que no té equivalent i cal cobrir per un altre camí.

I la pega contra el nostre propi interès, que és la que menys agrada: si mai no vas tenir activades aquelles polítiques, l'1 d'octubre no et va passar absolutament res. Tampoc no et va passar res el juliol del 2025, quan vas deixar de poder crear-les. Això no és una bona notícia: vol dir que fa anys que no tens resposta automàtica al risc d'identitat, i el calendari de Microsoft no hi té res a veure. Si a més no tens P2, aquest article sencer no t'aplica; el primer pas llavors no és una política, és una decisió de llicència, i hi ha coses més barates i més rendibles a fer abans —començant per MFA resistent al phishing per a qui administra—. Conflicte d'interès per davant: venem exactament aquesta feina, així que llegeix el de dalt amb aquella sospita posada.

Fonts (verificades el 3 d'octubre del 2026): la data de retirada amb la seva redacció, els controls de les polítiques de risc d'usuari i d'inici de sessió, el comportament de «Require risk remediation» segons el mètode d'autenticació, les regles de precedència, la no compatibilitat amb usuaris externs i convidats i el flux exempt amb el seu AppId i ResourceId surten de Microsoft Entra ID Protection risk-based access policies (Microsoft Learn). Els passos de migració, el guió de la incidència de suport, l'avís de no combinar condicions de risc a la mateixa política, les recomanacions de nivell de risc, els dos ajustos que s'apliquen sols, el requisit de registre previ d'MFA i d'escriptura diferida de contrasenyes, la nota sobre el canvi de contrasenya fora del flux, les exclusions recomanades, la frase sobre les entitats de servei i el requisit de llicència P2 o Entra Suite, de Risk policies (Microsoft Learn). Les tres limitacions amb convidats —bloqueig en forçar canvi de contrasenya, absència a l'informe d'usuaris de risc i impossibilitat de descartar o corregir el seu risc des del tenant del recurs— de Microsoft Entra ID Protection for B2B users. El bloqueig del convidat sense MFA registrat al tenant del recurs, el límit de la força d'autenticació a externs que autentiquen amb Entra ID i el procediment d'excloure els externs de les polítiques de risc, de Authentication and Conditional Access for B2B users. La recomanació literal d'excloure els convidats de l'MFA basat en risc i exigir-los MFA sempre, de la guia Zero Trust d'accés de convidats i usuaris externs. L'advertiment sobre appliedConditionalAccessPolicies i el valor hidden de riskLevelAggregated, de Learn about the monitoring and health activity log schemas. Amb una excepció declarada: el pas a només lectura el 31 de juliol del 2025 i la formulació que el que es retira és la interfície d'usuari provenen de l'anunci What's new in Microsoft Entra – June 2025, el cos del qual no hem aconseguit obrir; els prenem de les cobertures d'aquell anunci i els donem com el que són, no com una citació que hàgim llegit a l'original. El que és nostre, i no d'aquelles fonts: que «migrar» descriu malament una feina de reconstrucció, la distinció entre retirar la interfície i deixar d'aplicar la política, què significa el buit de convidats per a una empresa amb proveïdors, la deducció sobre l'usuari híbrid sense escriptura diferida —declarada com a deducció—, el procediment de prova amb dos comptes i la lectura Zero Trust de l'excepció documentada.