Una data vicina e una parola tecnica possono creare facilmente un falso allarme. Dal 30 settembre Android inizierà a impedire l’installazione di alcune app non registrate, ma non in Italia e non per ogni APK scaricato dal web. Google indica una prima applicazione in Brasile, Indonesia, Singapore e Thailandia, su telefoni e tablet certificati con Android 7 o successivo. In quella fase saranno coinvolti Google Play, Galaxy Store e altri store che hanno aderito al programma. Le installazioni dirette e gli store non compresi nell’elenco iniziale non cambieranno ancora. La novità si chiama Android developer verification. Non è una revisione del contenuto dell’app simile a quella effettuata da uno store: collega il nome del pacchetto e la sua chiave di firma a una persona o organizzazione verificata. L’obiettivo dichiarato è rendere più costoso per un truffatore pubblicare di nuovo un’app dannosa dopo la rimozione della precedente. Google sostiene che il software installato da fonti esterne presenti una concentrazione di malware molto maggiore rispetto a Play; il dato è dell’azienda e va letto come motivazione del cambiamento, non come prova che ogni app esterna sia pericolosa.
Perché è importante
- Il 30 settembre 2026 non scatterà un blocco in Italia: la prima applicazione riguarda Brasile, Indonesia, Singapore e Thailandia e soltanto gli store partecipanti.
- Dal 2027 Google estenderà la verifica a livello globale sui dispositivi Android certificati dalla versione 7 in poi, anche per app distribuite fuori da Play.
- L’installazione da sviluppatori non verificati resterà possibile attraverso un percorso avanzato, ma richiederà scelte intenzionali, attesa e conferma dell’identità dell’utente.
Il 30 settembre parte una fase regionale, non un blocco italiano
Per chi usa Android in Italia, quindi, il telefono non smetterà di accettare app esterne a settembre. La pagina ufficiale colloca l’espansione globale nel 2027 e oltre, senza indicare oggi un giorno unico per tutti i Paesi. Non serve attivare opzioni nascoste, registrare il proprio documento o pagare una quota per continuare a usare lo smartphone. Se un messaggio chiede denaro o un codice con questa giustificazione, è un segnale di truffa. La verifica riguarda chi crea e distribuisce l’app. Gli sviluppatori presenti su Google Play sono in gran parte già identificati e Google dichiara che il 99% delle app Play può essere registrato automaticamente. Chi pubblica soltanto sul proprio sito o su uno store indipendente userà invece Android Developer Console. L’account per distribuzione completa costa 25 dollari; studenti, docenti e hobbisti possono usare gratuitamente una modalità limitata fino a venti dispositivi, senza documento governativo.
Cosa puoi farci concretamente
- Gli utenti italiani possono continuare a installare le app come oggi e devono evitare procedure o pagamenti che promettono di «sbloccare Android» prima della scadenza.
- Chi distribuisce APK fuori da Google Play dovrebbe aprire Android Developer Console, verificare identità e pacchetti e conservare con cura le chiavi di firma.
- Imprese e scuole devono censire le app interne: quelle distribuite dallo store aziendale su dispositivi gestiti sono escluse, ma conviene documentarne firma e proprietario.
Il sideloading resta, ma installare software anonimo diventa una scelta più deliberata
Sideloading significa installare un’app da una fonte diversa dallo store principale, spesso aprendo un file APK. È utile per software libero, versioni interne, progetti sperimentali e servizi non presenti su Play. È anche il percorso sfruttato da campagne che convincono una persona a installare una falsa app bancaria, di assistenza o di investimento. La nuova regola non elimina il sideloading: prova a distinguere il caso ordinario, con uno sviluppatore identificato, da quello in cui l’autore sceglie di restare non verificato. Android prevede un «percorso avanzato» per gli utenti consapevoli. La documentazione aggiornata il 27 agosto descrive una procedura che richiede l’attivazione delle opzioni sviluppatore, una conferma per escludere che qualcuno stia guidando l’utente durante una truffa, il riavvio del telefono e un’attesa di ventiquattro ore. Dopo l’autenticazione con volto, impronta o PIN, l’utente potrà consentire le app non verificate per sette giorni o senza scadenza. Gli avvisi resteranno visibili e gli aggiornamenti delle app non registrate richiederanno che il percorso sia attivo.
Il ritardo di un giorno non serve a valutare il codice. Interrompe invece la pressione tipica dell’ingegneria sociale: una telefonata in cui un falso operatore detta i passaggi e chiede di agire subito. È un controllo sul comportamento, non una garanzia sulla qualità del software. Anche un’app firmata da uno sviluppatore verificato può contenere errori, raccogliere troppi dati o diventare dannosa dopo un aggiornamento. Identità, provenienza, permessi e reputazione restano controlli distinti. Gli sviluppatori potranno continuare a installare liberamente con ADB, lo strumento usato per sviluppo e test collegando il dispositivo al computer. Le app distribuite dallo store interno di un’organizzazione su telefoni gestiti non devono completare la verifica, perché l’amministratore le ha già approvate. Queste eccezioni evitano di bloccare laboratorio e gestione aziendale, ma non dovrebbero diventare scorciatoie offerte al pubblico: chiedere a una persona comune di usare ADB per installare un’app è un segnale che merita spiegazioni e verifiche indipendenti.
Quello che conta adesso
Un utente italiano non ha una procedura urgente da completare. Quando installa un’app esterna dovrebbe leggere l’indirizzo del sito, verificare che il produttore lo indichi tra i propri canali ufficiali, controllare la firma quando possibile e rifiutare richieste di disattivare protezioni durante una chiamata. Se l’app serve per banca, identità digitale o pagamenti, il collegamento va aperto partendo dal sito conosciuto dell’ente. La guida su come riconoscere le truffe con voce e video generati dall’AI aiuta a riconoscere la pressione costruita attorno a richieste tecniche. Per chi distribuisce software, rimandare al 2027 è rischioso. Bisogna scegliere il percorso Play Console o Android Developer Console, verificare l’identità, registrare i nomi dei pacchetti e associare le chiavi di firma. Per le organizzazioni è richiesto un numero D‑U‑N‑S, che può richiedere fino a ventotto giorni. Se la chiave di firma è stata persa, il pacchetto potrebbe non essere registrabile: per questo backup protetti e gestione documentata delle chiavi fanno parte della continuità del prodotto, non soltanto della sicurezza.
Le piccole imprese dovrebbero creare un inventario delle app Android usate fuori da Play: nome del pacchetto, proprietario, fonte, chiave, dispositivi interessati e modalità di aggiornamento. Il controllo è simile a quello necessario per un agente AI con accesso alla posta elettronica: sapere chi può distribuire, che cosa può cambiare e come si revoca l’accesso evita interventi improvvisati. Le app interne su telefoni gestiti restano escluse, ma un inventario permette di capire se vengono installate anche su dispositivi personali. La valutazione editoriale è equilibrata. Collegare un’app a un’identità reale può ridurre la capacità di riapparire anonimamente dopo una rimozione. Il percorso avanzato conserva la libertà di installare software non verificato, con più attrito. I limiti sono altrettanto chiari: Google diventa il soggetto che registra l’identità anche fuori dal proprio store e la verifica non certifica che un’app sia sicura o rispettosa della privacy. Per l’Italia oggi cambia soprattutto la preparazione degli sviluppatori; per gli utenti, il cambiamento concreto arriverà con il calendario globale del 2027.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
