I blog di Writefreely

2026-07-16 19:46:19

⚠️ ATTENZIONE ⚠️ - Il nostro account ripubblica automaticamente i post di alcuni blog Writefreely. Purtroppo c'è stato un attacco di spam ad alcune istanze Writefreely aperte al pubblico in registrazione aperta e noi abbiamo ripubblicato anche lo spam.

EDIT: nel fratempo abbiamo avvisato alcune delle istanze pubbliche italiane basate su #Writefreely che hanno deciso di sospendere temporaneamente il servizio o la semplice visibilità pubblica, in attesa che venga risolta una grave vulnerabilità segnalata ad aprile e ancora non corretta dagli sviluppatori della piattaforma

Ci scusiamo per il disagio arrecato dal nostro account, ma è stato proprio grazie a questo disagio che siamo riusciti ad allertare gli amministratori delle nostre istanze, dal momento che Writefreely non presenta strumenti di amministrazione che consentano agli admin di monitorare puntualmente le attività degli utenti

(in)sicurezza digitale

2026-07-16 11:10:11

SS7, il protocollo del 1970 che ha tradito i soldati USA: come l’Iran ha tracciato le truppe americane in Medio Oriente

Mentre i missili iraniani cadevano sulle basi americane in Iraq e Bahrain nella primavera del 2026, qualcun altro stava già facendo il lavoro sporco a monte: individuare dove dormivano, mangiavano e lavoravano i soldati statunitensi. Non con un drone o un informatore, ma con un protocollo di telecomunicazioni progettato negli anni ’70 per instradare chiamate tra centrali telefoniche. Un’indagine del progetto no-profit Mobile Surveillance Monitor, ripresa dal Financial Times e da TechCrunch, sostiene che Teheran abbia sfruttato sistematicamente le debolezze di SS7 per tracciare il personale militare USA in Medio Oriente prima e durante il conflitto con Israele e Stati Uniti.

Un protocollo vecchio quanto la Guerra Fredda tecnologica

Signaling System 7 (SS7) è l’infrastruttura di segnalazione che dagli anni ’70 permette agli operatori di rete 2G e 3G di scambiarsi informazioni su instradamento di chiamate, SMS e roaming. Il problema è noto da oltre un decennio agli specialisti di sicurezza delle telecomunicazioni: SS7 si basa su un modello di fiducia reciproca tra operatori che non prevede autenticazione robusta tra le reti. Chiunque abbia accesso — legittimo o comprato sul mercato grigio della sorveglianza — a un nodo SS7 può inviare query di tipo “Send Routing Information” (SRI) per ottenere la cella a cui è agganciato un numero di telefono, ottenendo così una localizzazione approssimativa del dispositivo, ovunque nel mondo, senza che l’utente se ne accorga.

È la stessa classe di debolezza usata in passato da broker di sorveglianza commerciale e da servizi di intelligence per intercettare SMS di autenticazione a due fattori o localizzare dissidenti. Ciò che rende il caso iraniano rilevante non è la tecnica in sé, già documentata, ma la scala e il tempismo: un uso operativo in tempo di guerra, contro obiettivi militari di una potenza nucleare.

La scoperta: un’impennata di query SS7 nel Golfo

Gary Miller, ricercatore che ha fondato Mobile Surveillance Monitor e collabora con il Citizen Lab dell’Università di Toronto, ha rilevato un’impennata anomala di “SS7 ping” — richieste ripetute di localizzazione — su reti di telecomunicazione di diversi paesi mediorientali. L’attività sarebbe iniziata a ridosso dell’operazione aerea congiunta USA-Israele contro i siti nucleari iraniani, per poi intensificarsi nei primi giorni del conflitto, quando l’Iran ha lanciato missili e droni contro le posizioni americane nella regione.

I segnali intercettati indicherebbero un interesse mirato per numeri associati a basi militari e hotel utilizzati da personale e contractor statunitensi in Iraq, Bahrain e altri paesi della regione — non una raccolta indiscriminata, ma query concentrate su specifiche fasce numeriche e reti locali note per essere frequentate da soggetti occidentali.

Non solo SS7: l’ad-tech come arma di sorveglianza

Il report segnala un secondo livello di raccolta, complementare a SS7: l’uso di tecnologie pubblicitarie commerciali (l’ecosistema RTB, “real-time bidding”) per identificare smartphone tramite advertising ID (IDFA/GAID) e correlarli, attraverso data broker, a posizioni geografiche precise. È la stessa superficie di rischio già segnalata da anni riguardo alla possibilità per chiunque compri dataset pubblicitari di ricostruire pattern di movimento di individui specifici — qui però applicata, secondo i ricercatori, a fini di targeting militare in un teatro di guerra attivo.

La combinazione delle due tecniche — segnalazione telefonica di rete e dati pubblicitari commerciali — rappresenta un salto di sofisticazione rispetto alle classiche operazioni SS7 isolate: un attore statale che integra fonti SIGINT tradizionali con l’enorme mole di dati commerciali normalmente destinata al marketing.

Timeline essenziale

• Fine febbraio 2026: primo aumento rilevato delle query SS7 sospette, in coincidenza con l’avvio della campagna aerea USA-Israele contro l’Iran.
• Marzo-aprile 2026: intensificazione del tracciamento durante lo scambio di attacchi missilistici e con droni contro le posizioni statunitensi in Iraq e Bahrain.
• 14 luglio 2026: pubblicazione del report da parte del Financial Times, ripreso da TechCrunch, Security Boulevard e altre testate di settore.

Due righe per i difensori

Per chi si occupa di sicurezza delle telecomunicazioni e di protezione del personale ad alto rischio (militari, diplomatici, giornalisti in zone di conflitto, dirigenti esposti), il caso ribadisce alcuni punti che il settore conosce ma fatica a far diventare prassi diffusa:

• Le difese SS7 lato operatore (firewall di segnalazione, filtri su messaggi SRI-SM/PSI provenienti da reti non attendibili) restano disomogenee a livello globale, specialmente in aree di conflitto dove la cooperazione tra operatori è debole.
• Il personale ad alto rischio dovrebbe evitare la SIM del proprio operatore domestico quando si muove in teatri sensibili, preferendo dispositivi dedicati, SIM locali “pulite” o soluzioni di comunicazione satellitare/crittografata che non transitano su rete 2G/3G tradizionale.
• La disattivazione del roaming 2G/3G e l’uso forzato di reti 4G/5G con autenticazione più robusta riduce, senza eliminarla, l’esposizione a query SS7 (il 4G usa Diameter, comunque non immune da abusi simili).
• Gli advertising ID dei dispositivi militari o di personale sensibile dovrebbero essere disattivati o randomizzati sistematicamente, e le app non essenziali rimosse prima di operazioni in teatri a rischio.

Il caso si inserisce in un pattern più ampio: dal 2014 a oggi, ricercatori indipendenti e vendor di sicurezza mobile hanno ripetutamente dimostrato che SS7 resta uno dei punti ciechi più sottovalutati della sicurezza nazionale, proprio perché la sua debolezza non risiede in un bug patchabile ma nell’architettura stessa di fiducia tra operatori, difficile da riformare su scala globale in tempi brevi.

Indicatori e pattern di rilevamento

Non essendo un malware ma un abuso di protocollo, non esistono IoC nel senso classico. I pattern che i team SOC delle telco e i CERT dovrebbero monitorare includono:

# Pattern di rilevamento abuso SS7 (indicativi, non esaustivi)
- Volume anomalo di messaggi SRI / SRI-SM verso uno stesso MSISDN o range di MSISDN
  in un intervallo di tempo ristretto (query ripetute = tentativo di tracciamento continuo)
- Richieste PSI (Provide Subscriber Info) o ATI (Any Time Interrogation) originate
  da Global Title esterni non associati a roaming legittimo dell'abbonato
- Origine dei messaggi SS7 da reti GT (Global Title) storicamente associate
  a broker di sorveglianza o a operatori "shell" con traffico legittimo minimo
- Correlazione temporale tra query SS7 e attivazione di advertising ID
  dello stesso dispositivo in piattaforme RTB di terze parti
- Assenza di firewall SS7/SIGTRAN conforme alle raccomandazioni GSMA FS.11 e FS.19

La GSMA pubblica da anni linee guida (FS.11, FS.19) per il filtraggio del traffico di segnalazione: la loro adozione disomogenea, soprattutto fuori dai mercati occidentali, resta il vero tallone d’Achille che un attore statale come l’Iran può — e a quanto pare sa — sfruttare con costi minimi e attribuzione tutt’altro che scontata.

(in)sicurezza digitale

2026-07-16 11:07:50

Le telecamere spia di Mosca: come l’intelligence russa sorveglia le rotte NATO verso l’Ucraina

Non servono droni, satelliti spia o infiltrati sul campo: bastano un videocitofono smart lasciato con la password di fabbrica e una connessione a Internet. Le agenzie di intelligence olandesi AIVD (General Intelligence and Security Service) e MIVD (Military Intelligence and Security Service) hanno rivelato che hacker legati allo stato russo hanno compromesso migliaia di telecamere IP e sistemi di videocitofonia lungo le rotte logistiche usate dalla NATO e dall’Ucraina per il trasporto di aiuti militari occidentali, trasformando dispositivi domestici e commerciali in una rete di sorveglianza capillare sul territorio europeo.

Un’operazione di OSINT armata su scala industriale

Secondo quanto riportato inizialmente dal Telegraph e ripreso da Kyiv Post, Pravda e diverse testate di settore, l’obiettivo dell’operazione russa era raccogliere intelligence in tempo reale sui tipi e sui volumi di armamenti inviati a Kyiv dagli alleati occidentali. A differenza delle tradizionali tecniche di sorveglianza satellitare o tramite drone, questa campagna sfrutta dispositivi IoT di consumo già presenti sul territorio: telecamere di sicurezza, citofoni smart e sistemi di videosorveglianza commerciale posizionati, spesso per puro caso logistico, lungo strade e valichi utilizzati per i convogli di aiuti militari.

Le due agenzie olandesi hanno confermato che un numero limitato di telecamere situate direttamente lungo le rotte logistiche nei Paesi Bassi risultava compromesso, e che le organizzazioni proprietarie dei dispositivi sono state avvisate per adottare contromisure. Il fenomeno, però, non si limita al territorio olandese: secondo l’advisory, la campagna ha interessato più Paesi membri della NATO e la stessa Ucraina, delineando un quadro di sorveglianza distribuita su tutta la catena di rifornimento occidentale verso il fronte.

Le tecniche: niente exploit sofisticati, solo superficie d’attacco enorme

Il dato più inquietante emerso dall’advisory congiunto non riguarda la sofisticazione tecnica — che qui è minima — ma la scala e la facilità dell’operazione. “Quando una telecamera IP viene identificata, un attaccante può provare ad accedervi via Internet: spesso è relativamente facile, perché molte telecamere connesse alla rete sono insufficientemente protette”, si legge nel rapporto delle agenzie olandesi. Gli operatori russi si sono affidati sistematicamente a password di default lasciate dal produttore, firmware obsoleti e mai aggiornati, e configurazioni di fabbrica mai modificate dagli utenti finali.

Molti dei dispositivi compromessi sono telecamere IP economiche di produzione cinese, in particolare modelli Hikvision e Dahua — marchi già oggetto in passato di segnalazioni per vulnerabilità di sicurezza e per preoccupazioni geopolitiche legate al loro utilizzo in infrastrutture sensibili. Una volta ottenuto l’accesso, gli aggressori hanno impiegato software di riconoscimento immagini per analizzare automaticamente i flussi video alla ricerca di veicoli militari e per identificarne il carico, automatizzando quello che altrimenti avrebbe richiesto osservazione umana costante.

Il contesto più ampio: la guerra ibrida contro la logistica occidentale

Questa campagna di compromissione delle telecamere si inserisce in un pattern più ampio di iniziative russe volte a mappare, disturbare o neutralizzare i vantaggi tecnologici che sostengono lo sforzo bellico ucraino. Un’inchiesta congiunta di The Insider, Der Spiegel e Le Monde, citata da Kyiv Post, ha rivelato che Russia e Cina hanno discusso segretamente, nell’ambito del terzo Forum di cooperazione tecnico-militare Cina-Russia tenutosi a Guangzhou, piani per neutralizzare la costellazione satellitare Starlink, da cui l’Ucraina dipende fortemente per comunicazioni e intelligence in tempo reale sul campo di battaglia.

Le slide trapelate, attribuite alla China Aerospace Science and Technology Corporation (CASC), delineavano un approccio multi-dominio contro Starlink: mezzi fisici per distruggere satelliti in orbita bassa, jamming elettromagnetico dei segnali e operazioni cyber pensate per caricare payload malevoli attraverso i terminali utente. Il documento proponeva inoltre una vera e propria “alleanza di sicurezza” tra Pechino e Mosca, con condivisione di intelligence e collaborazione su tecnologie chiave per contrastare il dominio strategico statunitense nello spazio.

Letta in questo contesto, la compromissione delle telecamere IP appare come un tassello a basso costo ma ad alto valore informativo di una strategia più ampia: se Starlink rappresenta il bersaglio ad alta quota della guerra ibrida russa, le migliaia di dispositivi IoT scarsamente protetti lungo le rotte logistiche europee rappresentano il fronte a bassa quota, silenzioso e diffuso, della stessa battaglia per la superiorità informativa.

Due righe pratiche per i difensori

Per i team di sicurezza, in particolare in ambito enterprise, logistico e delle infrastrutture critiche, questa vicenda è un promemoria brutale di quanto i dispositivi IoT di consumo restino l’anello debole della catena, specialmente quando dislocati in prossimità di asset sensibili o rotte strategiche. Le raccomandazioni delle agenzie olandesi, applicabili anche al contesto italiano ed europeo in generale, si concentrano su igiene di base della sicurezza IoT piuttosto che su contromisure avanzate:

• Cambiare immediatamente le password di default su tutte le telecamere IP, videocitofoni smart e dispositivi di videosorveglianza connessi a Internet.
• Aggiornare il firmware dei dispositivi IoT con regolarità, verificando la disponibilità di patch presso il produttore.
• Segmentare la rete in modo che le telecamere IP non abbiano accesso diretto a Internet né alla rete aziendale principale, utilizzando VLAN dedicate.
• Per le organizzazioni logistiche che operano lungo rotte sensibili, effettuare un censimento dei dispositivi IoT esposti pubblicamente tramite piattaforme come Shodan o Censys.
• Segnalare alle autorità nazionali competenti (in Italia, CSIRT-Italia) eventuali dispositivi sospetti o comportamenti anomali di rete rilevati su telecamere aziendali.
• Valutare con attenzione l’adozione di dispositivi IoT di produttori con precedenti riscontrati di vulnerabilità sistemiche, specialmente in contesti a rischio geopolitico elevato.

La vicenda dimostra ancora una volta che l’intelligence russa non ha bisogno di zero-day costosi o di infrastrutture offensive sofisticate quando l’anello debole è semplicemente la scarsa igiene di sicurezza di milioni di dispositivi IoT di consumo lasciati esposti online con le impostazioni di fabbrica. È una lezione che vale ben oltre il contesto bellico ucraino, e che riguarda direttamente chiunque gestisca infrastrutture di videosorveglianza connesse in rete.

netzpolitik.org

2026-07-15 16:29:58

Die schwarz-rote Koalition will nicht nur bei der Informationsfreiheit, sondern auch beim Datenschutz die Axt anlegen. Sie plant unter anderem pauschale Ausnahmen für kleine und mittelständische Unternehmen und will die Aufsicht zentralisieren. Kritik kommt von Datenschutzexpert:innen, Aufsichtsbehörden und Zivilgesellschaft.

netzpolitik.org/2026/reformpak…

Schwarz-Rot will 99 Prozent der deutschen Unternehmen vom Datenschutz ausnehmen

^{Ingo Dachwitz (netzpolitik.org)}

Spcnet.it

2026-07-15 18:08:01

RoguePlanet (CVE-2026-50656): la race condition in Microsoft Defender che regala privilegi SYSTEM

Il 9 luglio 2026 Microsoft ha rilasciato la correzione per RoguePlanet, una vulnerabilità zero-day nel Malware Protection Engine di Microsoft Defender che permetteva a un attaccante con accesso locale di ottenere privilegi SYSTEM su qualsiasi macchina Windows 10 o Windows 11 completamente aggiornata. Il dettaglio che rende questo bug particolarmente istruttivo per chi amministra flotte Windows non è tanto la gravità – con un CVSS 4.0 di 7.8 non è la falla più critica dell’anno – quanto il fatto che a essere vulnerabile sia proprio il componente che dovrebbe proteggere il sistema, e che il proof-of-concept pubblico funzioni indipendentemente dallo stato della protezione in tempo reale.

Cos’è RoguePlanet (CVE-2026-50656)

RoguePlanet è tracciata come CVE-2026-50656 ed è una vulnerabilità di elevazione dei privilegi locale nel Microsoft Malware Protection Engine, il motore di scansione condiviso da Defender e da altri prodotti Microsoft di sicurezza. La causa tecnica è una improper link resolution before file access, in pratica una race condition simile alle classiche TOCTOU (time-of-check to time-of-use): il motore di scansione risolve un percorso o un link simbolico/junction in un momento diverso da quello in cui accede effettivamente al file, e questa finestra temporale può essere sfruttata per far operare il processo, che gira con privilegi SYSTEM, su un file diverso da quello previsto.

Il ricercatore che ha scoperto e divulgato pubblicamente il bug, noto con lo pseudonimo Chaotic Eclipse (in alcune fonti riportato come Nightmare-Eclipse), ha pubblicato dettagli tecnici e codice exploit già a giugno 2026, prima che Microsoft rilasciasse una patch, nel contesto di una disputa pubblica con l’azienda sulle tempistiche di risposta alle segnalazioni di vulnerabilità. Questo ha reso RoguePlanet una vulnerabilità “N-day pubblica” per diverse settimane, con Microsoft che ha classificato lo sfruttamento come “Exploitation More Likely” sul proprio Exploitability Index.

Perché disattivare Defender non è una mitigazione valida

Un dettaglio operativo importante per chi ha dovuto gestire l’incidente: il proof-of-concept pubblicato funziona indipendentemente dal fatto che la protezione in tempo reale sia attiva o meno. Questo significa che la contromisura “tampone” spesso adottata in scenari di zero-day – disattivare temporaneamente il modulo vulnerabile finché non arriva la patch – non era efficace in questo caso, perché il motore di scansione resta comunque presente e invocabile sul sistema anche a protezione realtime disattivata.

Come funziona l’attacco in pratica

RoguePlanet è un exploit post-compromise: non è una falla che consente l’accesso iniziale a un sistema, ma serve ad ampliare i privilegi una volta che l’attaccante ha già ottenuto un punto d’appoggio, ad esempio tramite credenziali rubate, malware, phishing o un’altra vulnerabilità. Lo schema tipico è:

• L’attaccante ottiene accesso come utente standard (senza privilegi amministrativi) su un endpoint Windows.
• Sfrutta la race condition nel Malware Protection Engine per far scrivere, sostituire o manipolare un file in un percorso controllato dall’attaccante mentre il motore opera con privilegi SYSTEM.
• Ottiene l’esecuzione di codice arbitrario con privilegi SYSTEM, uscendo di fatto dal sandbox dei permessi utente.
• Da lì può disabilitare protezioni, esfiltrare dati, installare impianti persistenti o muoversi lateralmente nella rete.

È lo schema classico che trasforma una compromissione limitata (un singolo account utente) in una compromissione totale della macchina, ed è per questo che le vulnerabilità di questo tipo vengono trattate con priorità alta anche quando il CVSS non è altissimo: il vettore di attacco (locale, bassa complessità, nessuna interazione utente richiesta) le rende un tassello estremamente efficiente nelle catene di attacco moderne, specie quelle assistite da AI dove le fasi di privilege escalation e lateral movement vengono automatizzate.

Cosa fare subito

La buona notizia è che la correzione è già disponibile e, trattandosi di un aggiornamento del motore antimalware, viene distribuita automaticamente tramite gli aggiornamenti regolari delle definizioni, senza richiedere un intervento manuale sugli endpoint. La versione corretta del Malware Protection Engine è la 1.1.26060.3008 o successiva. Ecco però una checklist di verifica utile in ambienti gestiti:

# Verifica la versione del Malware Protection Engine su un endpoint Windows
Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, AntivirusSignatureLastUpdated

# Forza un aggiornamento immediato delle definizioni e del motore
Update-MpSignature -UpdateSource MicrosoftUpdateServer

# In ambienti con Configuration Manager / WSUS, verifica la data
# dell'ultimo aggiornamento delle definizioni su tutta la flotta
Get-MpComputerStatus | Select-Object ComputerID, AMEngineVersion |
    Export-Csv -Path C:\Reports\defender-engine-status.csv -NoTypeInformation

Se gestisci endpoint tramite Microsoft Defender for Endpoint, puoi verificare la copertura a livello di flotta dal portale Security, sezione Reports > Microsoft Defender Antivirus, filtrando per versione del motore. In ambienti air-gapped o con aggiornamenti WSUS ritardati, questo è il momento di controllare che la cadenza di distribuzione delle definizioni non stia introducendo un ritardo superiore a qualche giorno rispetto al rilascio Microsoft.

Indicatori di compromissione da monitorare

Per chi sospetta un possibile sfruttamento avvenuto prima della patch, Microsoft e i ricercatori indipendenti suggeriscono di dare priorità ai seguenti segnali in fase di threat hunting:

• Processi SYSTEM anomali generati da MsMpEng.exe o da altri componenti del Malware Protection Engine, specialmente se seguiti dall’avvio di una shell (cmd.exe, powershell.exe).
• Modifiche non pianificate alle impostazioni o ai servizi di Microsoft Defender, incluse disattivazioni temporanee della protezione in tempo reale non riconducibili a policy note.
• Creazione di attività pianificate (scheduled task) sospette nella stessa finestra temporale di scansioni antimalware.
• Nuovi meccanismi di persistenza (servizi, chiavi di avvio, WMI event subscription) creati con privilegi SYSTEM da processi non abituali.

Al di là del singolo CVE, RoguePlanet è un buon promemoria di un principio generale di hardening: restringere i privilegi standard degli utenti, limitare l’esecuzione di codice non autorizzato tramite AppLocker o Windows Defender Application Control, e mantenere una cadenza di patching aggressiva restano le difese più efficaci contro l’intera classe di vulnerabilità di elevazione dei privilegi, indipendentemente dal componente specifico coinvolto.

Conclusione

RoguePlanet dimostra ancora una volta che anche i componenti di sicurezza non sono immuni da vulnerabilità e possono, paradossalmente, diventare essi stessi superficie d’attacco. Per i sistemisti la buona notizia è che la correzione è già in distribuzione automatica: il compito principale è verificare che la propria flotta stia effettivamente ricevendo gli aggiornamenti del motore in tempi ragionevoli e, per gli ambienti a rischio più elevato, effettuare una verifica retrospettiva degli indicatori di compromissione descritti sopra.

Fonte: Petri IT Knowledgebase – Microsoft Patches Zero-Day RoguePlanet Defender Flaw

Microsoft Patches Zero-Day RoguePlanet Defender Flaw

Microsoft has released a fix for the RoguePlanet zero-day vulnerability in Defender, addressing a flaw that could allow SYSTEM-level access.

^{Rabia Noureen (Petri IT Knowledgebase)}

Spcnet.it

2026-07-15 18:07:47

Passkey come default in Microsoft Entra ID: guida alla migrazione da SMS e voce entro il 2027

Il 13 luglio 2026 Microsoft ha annunciato un cambiamento che riguarda praticamente ogni amministratore Entra ID: a partire da settembre, le passkey diventeranno il metodo di autenticazione predefinito per i nuovi accessi, mentre SMS e voce – i metodi di verifica più diffusi negli ultimi quindici anni – verranno progressivamente dismessi come servizio nativo, con ritiro definitivo fissato per il 1 febbraio 2027. Non è un annuncio isolato: è la formalizzazione di una traiettoria che Microsoft persegue da tempo, ma con date precise che ogni tenant dovrà rispettare, volenti o nolenti.

Perché Microsoft accelera proprio ora

La motivazione dichiarata da Microsoft nel post ufficiale sul Security Blog non è generica. Il Microsoft Threat Intelligence ha osservato campagne di phishing assistite da AI con tassi di click-through fino al 54%, contro il circa 12% delle campagne tradizionali. A questo si aggiunge la crescente accessibilità di tecniche come il SIM swapping e il bypass dell’autenticazione multifattore, che rendono SMS e voce – entrambi basati su segreti condivisi trasmessi su canali intercettabili – sempre meno affidabili come secondo fattore. Le passkey, basate su crittografia a chiave pubblica anziché su segreti condivisi, sono phishing-resistant per costruzione: non esiste un codice da rubare o da far digitare su un sito civetta, perché la chiave privata non lascia mai il dispositivo dell’utente.

Cosa cambia concretamente: la timeline

Per pianificare la migrazione senza sorprese, questi sono i passaggi principali comunicati da Microsoft:

• 1 settembre 2026 – Tutti gli utenti già abilitati per SMS o voce vengono automaticamente iscritti e sollecitati a registrare una passkey al successivo accesso con autenticazione multifattore.
• 18 settembre 2026 – Microsoft pubblica i dettagli su provider di telecomunicazioni supportati, prezzi e condizioni commerciali per chi deve continuare a usare SMS/voce tramite terze parti.
• 30 ottobre 2026 – Gli amministratori possono selezionare e configurare un provider telecom di terze parti tramite il Microsoft Security Store.
• 1 febbraio 2027 – Microsoft ritira il servizio nativo di autenticazione SMS e voce in Entra ID. Da questa data, chi non ha configurato un provider terzo o una passkey dovrà necessariamente registrarne una prima di poter accedere: non è previsto alcun opt-out.

Il punto da evidenziare per chi pianifica: l’auto-enrollment parte a settembre, ma la scadenza reale – quella che rompe l’accesso per chi non si è mosso – è a febbraio 2027. Sono circa sette mesi di finestra, che possono sembrare tanti ma si riducono rapidamente se il tenant ha migliaia di utenti, dispositivi eterogenei o processi di change management lenti.

Quali tipi di passkey supporta Entra ID

Entra ID distingue due famiglie di passkey, ed è una distinzione operativa rilevante per la policy da adottare:

• Passkey sincronizzate (synced): memorizzate in un gestore di credenziali a livello di piattaforma e sincronizzate tra i dispositivi dell’utente, ad esempio tramite iCloud Keychain o Google Password Manager. Comode per utenti finali, ma con un livello di attestazione hardware inferiore.
• Passkey vincolate al dispositivo (device-bound): legate a un singolo dispositivo o chiave fisica, ad esempio le passkey di Microsoft Authenticator, le Entra passkey su Windows (basate su Windows Hello for Business) e le chiavi di sicurezza FIDO2 hardware. Offrono garanzie di attestazione più solide, adatte a account amministrativi o a scenari con requisiti di compliance stringenti.

Le passkey FIDO2 sono disponibili in tutte le edizioni di Entra ID, inclusa quella Free, senza licenze aggiuntive: un dettaglio non scontato che elimina l’alibi del costo per rimandare l’adozione.

Come prepararsi: guida pratica per amministratori

1. Mappa chi usa ancora SMS o voce

Il primo passo è puramente ricognitivo: individuare quali utenti o gruppi sono ancora configurati su SMS o voce come metodo di autenticazione. Con Microsoft Graph PowerShell:

# Connessione a Microsoft Graph con i permessi necessari
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","Policy.Read.All"

# Elenca gli utenti con metodo di autenticazione telefonico configurato
$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName
foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationPhoneMethod -UserId $u.Id -ErrorAction SilentlyContinue
    if ($methods) {
        [PSCustomObject]@{
            User  = $u.UserPrincipalName
            Phone = ($methods.PhoneNumber -join ", ")
        }
    }
}

2. Configura i passkey profile

Da qualche mese Entra ID supporta i passkey profile, che permettono configurazioni granulari per gruppo anziché un’unica impostazione a livello di tenant: puoi definire requisiti di attestazione, tipo di passkey ammesso (device-bound vs synced) e restrizioni per AAGUID (l’identificativo del modello di authenticator) differenziando, ad esempio, gli amministratori – per cui puoi imporre solo chiavi FIDO2 hardware con attestazione verificata – dal resto del personale, per cui le passkey sincronizzate sono sufficienti. La configurazione si effettua da Entra admin center > Protection > Authentication methods > Passkey (FIDO2), oppure via Graph API sull’endpoint /policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2.

3. Attiva una registration campaign

Per portare gli utenti alla registrazione senza dover organizzare sessioni di onboarding manuali, Entra ID offre le registration campaign: durante un normale accesso MFA, l’utente viene invitato a registrare una passkey in modo contestuale. Si abilitano da Authentication methods > Registration campaign, specificando quale metodo promuovere (in questo caso, passkey) e per quali gruppi.

4. Valuta l’enforcement con Conditional Access

Per i ruoli più sensibili, non basta rendere le passkey disponibili: conviene richiederle esplicitamente. Le authentication strength policy di Conditional Access permettono di imporre l’uso di metodi phishing-resistant (passkey, FIDO2, Windows Hello for Business) per l’accesso a risorse critiche, indipendentemente dal fatto che l’utente abbia ancora SMS configurato come fallback.

5. Se devi mantenere SMS o voce per obblighi regolatori

Non tutti i contesti possono abbandonare SMS/voce immediatamente per vincoli normativi o tecnici (ad esempio utenti privi di smartphone aziendale). In questo caso, il percorso è: documentare i segmenti di utenti interessati, attendere l’apertura del catalogo provider il 18 settembre, configurare un provider supportato tramite il Microsoft Security Store dal 30 ottobre, e testare la configurazione su un gruppo pilota prima del rollout esteso.

Conclusione

La transizione a passkey-by-default non è una feature opzionale da valutare con calma: ha una data di rottura precisa, il 1 febbraio 2027, dopo la quale gli utenti ancora legati a SMS o voce senza un provider terzo configurato saranno bloccati in accesso finché non registrano una passkey. Per i team IT il consiglio pratico è iniziare subito con la ricognizione degli utenti a rischio e l’attivazione di una registration campaign pilota, così da arrivare a settembre con un processo già collaudato invece di gestire l’auto-enrollment massivo come un’emergenza.

Fonte: Microsoft Security Blog – Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID

Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID | Microsoft Security Blog

Starting September 1, 2026, passkeys will become the default authentication experience in Microsoft Entra. Read more about how to prepare.

^{Nadim Abdo (Microsoft Security Blog)}