Les polítiques d'accés condicional que no vas escriure ja són al teu tenant

Obre la llista de polítiques d'accés condicional del teu tenant i mira la columna «Creada per». Si alguna fila diu Microsoft, aquella política no la va escriure ningú de la teva empresa. És en «només informe», que sona inofensiu, i no ho és del tot: és un compte enrere. L'encendrà Microsoft.

La mecànica està documentada i és literal: «The policy is automatically created in your tenant in a Report-only state» i «Microsoft enables these policies no less than 30 days after they're introduced in your tenant if they're left in the Report-only state». Avisen per correu i pel Centre de missatges dues setmanes abans. I hi ha una nota que convé llegir sencera: «In some cases, policies might be enabled faster than 30 days».

Aquest número s'ha mogut, i en la direcció que menys convé a qui va just. Quan Microsoft va arrencar amb això, el novembre de 2023, la promesa era una altra: «you'll have 90 days to review and customize (or disable) them before we turn them on». Avui la seva documentació ja no promet una finestra, promet un terra: «no menys de 30 dies», més la nota que pot ser abans. Conclusió pràctica: no planifiquis amb el número, planifica amb el mecanisme.

Les deu que hi ha avui

Aquesta és la llista publicada per Microsoft en el moment d'escriure això. Canvia: n'han anat afegint.

Dues d'aquella llista —«exigir autenticació resistent al phishing als administradors» i «blocar l'autenticació heretada»— pertanyen també al mode de seguretat de referència del centre d'administració de Microsoft 365, i aquí hi ha una diferència que importa per saber a qui culpar: aquelles les crea l'administrador, no Microsoft. Apareixen a la mateixa pantalla, però amb «Mode de seguretat de referència» a la columna de creador i es gestionen des d'un altre lloc. Del mode de seguretat de referència i de per què el seu informe d'impacte surt gairebé sempre a zero ja en vam escriure aquí.

L'única cosa que pots tocar és la llista d'exclusions

Literal: «Organizations can't rename or delete any Microsoft-managed policies». Pots excloure identitats, pots passar-les de «només informe» a activada o desactivada, i pots duplicar-les si necessites més marge —amb l'avís que la mateixa pàgina inclou: «Be careful not to lower your security posture with those changes»—. Res més.

D'aquí surt la primera tasca, i és d'avui, no de d'aquí a un mes: el teu compte d'emergència. Microsoft ho diu sense embuts —«Exclude your break-glass or emergency access accounts from managed policies just like other Conditional Access policies»— i té tota la raó. Un compte trenca-vidres que no està exclòs de totes les polítiques, incloses les que no vas escriure, no és un compte trenca-vidres: és un compte més. La diferència es descobreix el dia que no pots entrar a arreglar per què no pots entrar. Quan ens fem càrrec d'un tenant que ha portat un altre, això és el primer que mirem: abans que el Secure Score, abans que les polítiques pròpies.

Les tres que trenquen coses

Cap d'aquestes polítiques no és mala idea. El que tenen són efectes laterals concrets en llocs concrets, i els llocs no són els que la gent espera.

1. Blocar el flux de codi de dispositiu

Microsoft resumeix l'argument en una frase difícil de rebatre: «Device code flow is rarely used by customers, but is frequently used by attackers». És aquell inici de sessió en què comences en un aparell i acabes en un altre, i existeix justament perquè hi ha andròmines on no pots escriure una contrasenya. Andròmines com una sala de reunions amb equip de Teams. El dia que aquella política passa a activada, el que cau no és «un usuari»: és la sala gran, un dilluns a les nou, amb gent a dins. Microsoft publica una guia específica per acotar l'excepció dels dispositius de Teams sense desactivar la política sencera, i aquesta és la manera correcta de fer-ho.

2. Blocar l'autenticació heretada

La dada que dona Microsoft és demolidora: «more than 99 percent of password spray attacks use these legacy authentication protocols». El que hi entra és, en les seves paraules, «older clients like Office 2010, or clients that use protocols like IMAP, SMTP, or POP3», i d'aquesta última meitat surt l'inventari real d'una pime, que ja no ho diu Microsoft sinó nosaltres: el multifunció que escaneja a correu, l'ERP que envia factures, l'script que llegeix una bústia per IMAP per introduir comandes. Res d'això no té cara ni es queixa al Teams: simplement deixa de funcionar, i el normal és assabentar-se'n pel client que no ha rebut la factura.

3. MFA per a tots els usuaris

El que trenca aquí no és la gent. La gent té Authenticator o se l'instal·la en cinc minuts. El que trenca són els comptes de servei que algú va crear com si fossin persones: amb llicència, amb bústia, amb contrasenya en un fitxer de configuració, i sense ningú al darrere que pugui tocar un mòbil. La mateixa documentació ho avisa per a la política de risc —«All Users could include service accounts or break-glass accounts, so you might want to exclude them»— i l'avís val igual per a aquesta. Si no saps quants en tens, aquest és l'inventari que cal fer aquesta setmana, no la política.

El detall que gairebé ningú no ha llegit: les teves llicències dibuixen el perímetre

La política d'inicis de sessió de risc necessita Entra ID P2. I aquí ve la part interessant, que està escrita i ningú no cita. La política s'aplica a tots els usuaris només si es compleixen dues condicions alhora: «If all your active users have MFA and your P2 licenses equal or exceed the total active users». N'hi ha prou que en falli una —que alguns no tinguin MFA o que no arribin les llicències— perquè Microsoft creï un grup de seguretat anomenat «Conditional Access: Risky sign-in multifactor authentication», el limiti al que tinguis —«capped to your available P2 licenses»— i l'ompli ell: «we select users who can satisfy MFA, prioritizing users with a directly assigned P2 license». Els convidats es queden fora en qualsevol cas.

No és una trampa: és la conseqüència inevitable que la protecció es pagui per usuari, i Microsoft ho explica sense amagar-ho. Però el resultat operatiu sí que mereix un minut: qui està cobert davant d'un inici de sessió de risc a la teva empresa ho decideixen un recompte de llicències i un estat de registre d'MFA, no la teva anàlisi de riscos. Si la direcció financera no té una P2 assignada directament, pot no ser en aquell grup. És un grup normal, el pots editar. Però cal mirar-ho, no suposar-ho.

Hi ha un segon llindar en la mateixa línia. La política que recull els usuaris de l'MFA «per usuari» antic només s'adreça a organitzacions amb menys de 500 usuaris en aquest estat. Té lògica —ningú no vol moure cinc mil persones per sorpresa— i tot i així deixa una ironia que convé dir en veu alta: com més gran és el garbuix heretat, menys ajuda automàtica reps. Aquí la feina és teva, i consolidar aquell MFA antic en accés condicional continua sent una de les tasques amb millor relació esforç/resultat de qualsevol tenant.

Com saber què t'ha tocat, sense suposar

Quatre llocs, de menys a més útil:

Si tens activats els valors predeterminats de seguretat, diverses d'aquestes no t'arriben

Diverses d'aquestes polítiques s'adrecen expressament a organitzacions «where security defaults aren't enabled», i els requisits que llista aquella mateixa pàgina per a l'accés condicional són Entra ID P2 o Microsoft 365 Business Premium. O sigui que hi ha dos mons: el que té valors predeterminats de seguretat —tot o res, sense excepcions fines— i el que té accés condicional. Per a qui ve del primer, Microsoft ofereix un altre joc de quatre polítiques d'arrencada: blocar autenticació heretada, MFA per a administradors, MFA per a tothom i MFA per a la gestió d'Azure. No és mal lloc per on començar, i no cal inventar-se res.

I tot i així, això està bé

Convindria no llegir aquest post com una queixa. Microsoft està encenent per defecte coses que fa anys que recomanem d'una en una, client per client, i perdent la discussió més vegades de les que ens agradaria. El seu argument, per cert, és a la primera línia de la mateixa pàgina: l'MFA «continues to reduce the risk of compromise by more than 99%». Que l'MFA per a administradors arribi sol és una bona notícia, i a nosaltres ens treu una conversa incòmoda de sobre.

La part que sí que cal dir és una altra, i és la de sempre en aquest ofici: una política que no vas dissenyar i no pots esborrar continua sent teva el dia que dispara. El qui es queda fora truca al teu telèfon, no al de Redmond. I l'única palanca que t'han deixat —la llista d'exclusions— cal haver-la fet servir abans. Això no és una crítica; és una tasca amb data.

El que no afirmem

Quan això no va amb tu

Si sou dotze persones, tothom té Authenticator, no hi ha multifunció que enviï correu, no hi ha ERP de fa quinze anys i no hi ha sales de reunions amb equip de Teams: entra, mira la llista, exclou el teu compte d'emergència i vés a fer una altra cosa. Són vint minuts, no un projecte. I ho diem sabent el que diem: venem Microsoft 365 gestionat i consultoria; si després de mirar la llista no hi ha res per excloure, ens n'alegrem i no hi ha factura.

Si en canvi tens comptes de servei amb llicència, dispositius que inicien sessió sense teclat o un MFA antic que ningú no ha consolidat, llavors sí que hi ha feina, i la feina no és «desactivar les polítiques»: és deixar la llista d'exclusions ben posada i treure del mig el que sobreviu només perquè encara ningú no ho ha blocat. És el mateix raonament que quan mirem quines aplicacions connectades entren al teu Microsoft 365 sense passar per l'MFA: el que decideix la teva exposició no és el control que vas activar, és el que se li escapa.

Fonts (verificades el 28 de setembre de 2026): llista de polítiques, estat inicial «només informe», termini de «no menys de 30 dies», avís dues setmanes abans, impossibilitat de reanomenar o esborrar, exclusió de comptes d'emergència, llindar de 500 usuaris d'MFA per usuari, grup limitat a les llicències P2, controls personalitzats i consulta d'auditoria — Microsoft Learn, «Microsoft-managed Conditional Access policies» (actualitzada el 8 d'agost de 2026); anunci original amb el termini de 90 dies — Microsoft Security Blog, 6 de novembre de 2023.