Chrome si aggiorna ogni due settimane: come gestire il nuovo ritmo in azienda

di EP ConsultingInformatica per aziende
Cover EP Consulting sulla gestione aziendale degli aggiornamenti Chrome ogni due settimane

Dal rilascio di Chrome 153 dell’8 settembre 2026, Google ha dimezzato il ciclo delle versioni Stable: un nuovo milestone arriva ogni due settimane invece che ogni quattro. Il cambiamento riguarda Chrome su desktop, Android e iOS e non va confuso con i normali aggiornamenti di sicurezza intermedi, che Google distribuiva già con maggiore frequenza. Per un singolo utente l’effetto può essere quasi invisibile; per un’azienda che certifica applicazioni web, governa estensioni o mantiene decine di browser, il calendario di test diventa invece molto più stretto. La buona notizia è che Google mantiene il canale Extended Stable a otto settimane per i browser gestiti su Windows e macOS. La scelta, però, non dovrebbe ridursi a “aggiornare più lentamente”: occorre bilanciare velocità delle correzioni, compatibilità e capacità reale del reparto IT di validare le nuove versioni.

Aggiornamenti Chrome ogni due settimane: cosa cambia con Chrome 153

Google aveva annunciato il nuovo calendario il 3 marzo 2026 e lo ha reso operativo con Chrome 153, pubblicato nel canale Stable l’8 settembre. Da questa versione, sia Stable sia Beta ricevono un nuovo milestone ogni due settimane. Il cambiamento vale per desktop, Android e iOS; i canali Dev e Canary non cambiano.

Un milestone è una versione principale del browser, identificata dal primo numero: 153, 154 e così via. Prima del passaggio, un nuovo milestone Stable arrivava ogni quattro settimane. Il calendario ufficiale prevede, per esempio, che Chrome 153 sia seguito da Chrome 154 il 22 settembre 2026. Google motiva la scelta con la volontà di portare più rapidamente prestazioni, correzioni e nuove capacità, distribuendo contemporaneamente release di portata più piccola. Secondo il team Chrome, un insieme ridotto di modifiche dovrebbe anche rendere più semplice isolare eventuali regressioni.

Questo non significa che prima Chrome restasse quattro settimane senza correzioni. Dal 2023 Google pubblica aggiornamenti di sicurezza settimanali. Il nuovo schema modifica soprattutto la frequenza delle versioni principali, con possibili cambiamenti di API web, comportamento del browser, criteri aziendali e compatibilità delle estensioni.

Perché il nuovo ritmo interessa davvero le aziende

Il browser è ormai una componente applicativa: ospita gestionali SaaS, portali bancari, strumenti di firma, videoconferenze, console cloud e applicazioni sviluppate internamente. Una regressione non colpisce soltanto la navigazione, ma può bloccare un processo operativo. Con una release ogni due settimane si riduce il tempo tra una versione e la successiva, quindi anche la finestra disponibile per verificare le applicazioni critiche.

Le organizzazioni più interessate sono quelle che:

  • usano applicazioni web legacy o sviluppate su misura;
  • dipendono da estensioni Chrome per autenticazione, sicurezza o produttività;
  • gestiscono browser tramite criteri di dominio, MDM o Chrome Enterprise Core;
  • bloccano temporaneamente le versioni per eseguire test di compatibilità;
  • hanno postazioni condivise, chioschi, call center o terminali operativi;
  • devono dimostrare che patch e configurazioni sono governate.

Per una piccola impresa senza applicazioni particolari, lasciare attivi gli aggiornamenti automatici rimane in genere la scelta più semplice e sicura. Per una realtà con dipendenze critiche serve invece un processo leggero ma ripetibile: gruppo pilota, inventario, controllo delle versioni e percorso di rollback documentato.

Stable o Extended Stable: la decisione da prendere

Stable: più rapido e raccomandato per la maggior parte degli utenti

Il canale Stable riceve ora un nuovo milestone ogni due settimane. È la scelta indicata per la maggior parte delle postazioni perché porta prima correzioni, miglioramenti e cambiamenti che rafforzano la sicurezza. Google definisce Stable l’opzione più sicura rispetto a Extended Stable quando la priorità è ridurre l’esposizione e non il costo operativo dei test.

La frequenza maggiore non obbliga a distribuire tutto nello stesso minuto. Un’amministrazione centralizzata può scaglionare il rollout e usare una piccola popolazione di utenti come anello di validazione. L’errore da evitare è trasformare il test in un blocco indefinito: mantenere un browser fermo su una versione obsoleta espone a vulnerabilità note.

Extended Stable: otto settimane, ma non equivale a “niente aggiornamenti”

Extended Stable continua a ricevere un nuovo milestone ogni otto settimane. È disponibile per browser Chrome gestiti su Windows e macOS, non su Android o iOS. Durante le sei settimane successive alla fase iniziale, Google pubblica refresh settimanali con le correzioni di sicurezza della linea Stable quando il backport è tecnicamente possibile.

Il limite è importante: cambiamenti complessi o funzionalità ampie che migliorano la sicurezza potrebbero essere disponibili soltanto su Stable. Extended Stable offre quindi più tempo per validare le funzionalità, ma non deve essere presentato come soluzione intrinsecamente più sicura. È un compromesso operativo per aziende che non riescono a sostenere un milestone ogni due settimane.

La selezione del canale avviene tramite il criterio TargetChannel. Su Windows sono disponibili anche pacchetti MSI dedicati; su macOS Google prevede distribuzione PKG o DMG. Prima di cambiare canale bisogna considerare la differenza di versione: passando da Stable a Extended Stable, il browser potrebbe dover attendere il milestone compatibile o richiedere un rollback controllato.

Come organizzare il test senza raddoppiare il lavoro

Un ciclo più breve non richiede necessariamente il doppio delle ore. Richiede soprattutto test più mirati e automazione. Google consiglia di mantenere una quota di utenti sul canale Beta; la documentazione Chrome Enterprise indica come riferimento il 5% e suggerisce di rappresentare i diversi tipi di hardware presenti. Con il nuovo calendario, la Beta viene resa disponibile tre settimane prima della corrispondente Stable.

Per una PMI il gruppo pilota può essere molto più piccolo, purché includa ruoli e scenari significativi. Un contabile che usa portali fiscali, un addetto vendite che lavora nel CRM e un tecnico che accede alle console cloud offrono più valore di tre postazioni casuali. Conviene includere anche almeno un dispositivo per sistema operativo e profilo hardware rilevante.

Cosa testare davvero

Il test non deve tentare di coprire ogni pagina Internet. Deve concentrarsi sulle dipendenze aziendali:

  • accesso con identità aziendale, autenticazione multifattore e smart card;
  • applicazioni web critiche e operazioni ad alto valore;
  • estensioni obbligatorie, agenti DLP e componenti di sicurezza;
  • download, upload, stampa, firma e apertura di documenti;
  • videoconferenze, microfono, webcam e condivisione schermo;
  • proxy, ispezione TLS, DNS filtrato e accesso remoto;
  • criteri visibili in chrome://policy.

Il precedente approfondimento EP Consulting sullo zero-day CVE-2026-85046 in Chrome mostra perché il controllo delle versioni non può essere soltanto amministrativo. Il nuovo ritmo riduce il tempo disponibile per la validazione, ma non elimina la necessità di installare rapidamente le correzioni urgenti.

Policy, version pinning e rollback: usarli senza creare debito

Su Windows, Google Update può essere governato tramite modelli ADMX e Group Policy; i criteri a livello computer sono rispettati dai dispositivi uniti a un dominio o gestiti tramite MDM. Google raccomanda di mantenere attivi gli aggiornamenti automatici. Disabilitarli espone a crash e vulnerabilità e dovrebbe essere una misura eccezionale, accompagnata da un processo alternativo di distribuzione.

È possibile fissare temporaneamente un milestone o una versione completa. La sintassi del solo milestone consente di ricevere le revisioni più recenti disponibili su quella linea; bloccare una build completa è più rischioso, perché quella build può essere superata da una correzione successiva. Google raccomanda di usare il pinning soltanto durante test o incidenti e di rimuoverlo appena possibile.

Anche il rollback è una procedura di emergenza, non una strategia ordinaria. Su Windows Chrome conserva per impostazione predefinita gli snapshot locali delle tre versioni principali più recenti; una configurazione errata degli snapshot può comportare la perdita dei dati locali del profilo durante il downgrade. Inoltre, tornare a una versione precedente significa accettare vulnerabilità note. Per questo il piano deve specificare chi autorizza il rollback, su quali gruppi e per quanto tempo.

Le aziende che già governano gli endpoint possono integrare Chrome nello stesso processo usato per gli aggiornamenti Windows dietro firewall e proxy: anelli di distribuzione, finestre operative, telemetria e verifica finale. Il prodotto cambia, ma il principio rimane lo stesso.

Cosa significa per una PMI

Il cambiamento non impone automaticamente l’acquisto di nuovi strumenti. Se i dispositivi sono pochi e non esistono applicazioni web sensibili, può bastare mantenere l’aggiornamento automatico, verificare periodicamente le versioni e chiedere agli utenti di riavviare il browser quando necessario. Il problema nasce quando non c’è visibilità: una flotta con installazioni personali, canali diversi e browser mai riavviati rende impossibile sapere se una correzione è realmente applicata.

Prima di scegliere Extended Stable, una PMI dovrebbe chiedersi se il vero limite sia la frequenza delle release o l’assenza di un processo. Spostare tutti su otto settimane può ridurre i cambiamenti funzionali, ma non sostituisce inventario, test e aggiornamenti di sicurezza. In molti casi è più efficace lasciare la maggioranza su Stable, creare un piccolo gruppo Beta e monitorare due o tre flussi critici.

Se Firefox o Thunderbird sono presenti nello stesso parco, è utile coordinare i calendari: anche Mozilla ha accelerato le proprie release, come spiegato nella guida EP Consulting sugli aggiornamenti ogni due settimane di Firefox e Thunderbird. Un registro unico dei browser evita procedure separate e incoerenti.

Checklist operativa per il nuovo ciclo di Chrome

  1. Censire le installazioni: versioni, sistema operativo, canale e metodo di gestione.
  2. Identificare le dipendenze: applicazioni web, estensioni, smart card, proxy e strumenti di sicurezza.
  3. Definire gli anelli: Beta per un gruppo rappresentativo, Stable per la maggioranza, Extended Stable solo dove serve davvero.
  4. Ridurre i test: verificare i processi essenziali e non una lista generica di siti.
  5. Controllare le policy: confermare canale e aggiornamenti in chrome://policy.
  6. Evitare blocchi permanenti: assegnare una data di scadenza a ogni pinning.
  7. Preparare il rollback: documentare autorizzazione, snapshot del profilo e ritorno alla versione corrente.
  8. Misurare la conformità: verificare quanti dispositivi hanno applicato la versione attesa e riavviato il browser.
  9. Informare gli utenti: spiegare quando è necessario chiudere e riaprire Chrome.

FAQ sugli aggiornamenti Chrome ogni due settimane

Chrome riceverà soltanto aggiornamenti di sicurezza ogni due settimane?

No. Il cambiamento riguarda il ciclo dei milestone Stable e Beta, che passa da quattro a due settimane. Le release possono includere funzionalità, correzioni, miglioramenti delle prestazioni e modifiche della piattaforma web. Google distribuiva già refresh di sicurezza settimanali dal 2023, quindi non bisogna confondere i due calendari.

Extended Stable elimina gli aggiornamenti frequenti?

No. Extended Stable mantiene lo stesso milestone per otto settimane, ma riceve refresh di sicurezza settimanali. Google prova a trasferire le correzioni critiche, alte e medie dalla linea Stable quando tecnicamente possibile; cambiamenti complessi potrebbero però restare disponibili solo su Stable. È una cadenza funzionale più lenta, non un browser da lasciare fermo.

Extended Stable è disponibile anche su smartphone?

No. La documentazione Google indica Extended Stable per browser gestiti su Windows e macOS. Non è supportato su Android o iOS. Il nuovo ciclo Stable ogni due settimane, invece, riguarda anche le piattaforme mobili.

Conviene bloccare Chrome 153 per avere più tempo?

Soltanto in presenza di una regressione verificata e per un periodo breve. Google sconsiglia di fissare a lungo una versione, perché il browser può perdere correzioni critiche. È preferibile usare gruppi pilota, rollout progressivo ed eventualmente Extended Stable per i reparti che richiedono una finestra di test più ampia.

Cosa deve fare subito un responsabile IT?

Deve verificare canale e versione realmente installati, controllare che gli aggiornamenti automatici non siano disabilitati da vecchie policy e individuare le applicazioni web critiche. Il passo successivo è costruire un piccolo gruppo pilota e definire una verifica quindicinale. Per assistenza nella gestione centralizzata dei browser e degli endpoint, è possibile valutare le soluzioni IT di EP Consulting.

Considerazioni EP Consulting

Il nuovo ritmo di Chrome rende meno sostenibile il modello “testiamo tutto manualmente una volta al mese”, ma offre anche release più piccole e una correzione più rapida dei problemi. La risposta non dovrebbe essere rallentare indistintamente ogni dispositivo. È più efficace classificare le postazioni per rischio, anticipare i controlli con Beta e riservare Extended Stable ai flussi che hanno davvero bisogno di otto settimane.

Per una PMI, il risultato pratico deve essere semplice: sapere quali browser sono installati, chi li governa, quando sono stati aggiornati e quali applicazioni possono bloccare. EP Consulting può affiancare l’azienda nel censimento degli endpoint, nella definizione delle policy e nella costruzione di un rollout che protegga l’operatività senza lasciare indietro le correzioni di sicurezza.

Fonti