• Cloud, Guide, Microsoft 365, Sicurezza, Sistemi Operativi
• 29 Gennaio 2026

Introduzione

Se in azienda utilizzate ancora MBAM (Microsoft BitLocker Administration and Monitoring), siete in buona compagnia. Per anni è stato lo standard enterprise per la gestione di BitLocker con portale self-service, helpdesk, compliance e soprattutto escrow delle recovery key in modo centralizzato. Ma ora la musica sta cambiando, definitivamente: il supporto esteso di MBAM arriva al capolinea il 14 aprile 2026. Considerando che siamo appena entrati nel 2026 e la scadenza è fissata al 14 aprile, mancano ormai pochi mesi: abbastanza per migrare con metodo, troppo pochi per rimandare al prossimo trimestre.

Questo articolo è pensato per voi IT admin che state cercando un’alternativa a MBAM per la gestione di BitLocker. Che il vostro ambiente sia full cloud con solo Microsoft Intune, oppure ibrido con dispositivi Microsoft Entra Hybrid joined e magari anche Configuration Manager in co-management, l’obiettivo rimane portare la gestione della cifratura verso un modello modern management, eliminando complessità superflue nel vostro ambiente di lavoro.

In questa guida vedremo nel dettaglio:

• Cosa succede a MBAM
• Metodi alternativi a MBAM per la gestione BitLocker
• Escrow delle recovery key
• Mini demo: come configurare BitLocker con Microsoft Intune
• Troubleshooting
• Checklist finale
• Conclusioni

Cosa succede a MBAM

MBAM (Microsoft BitLocker Administration and Monitoring) fa parte del pacchetto MDOP (Microsoft Desktop Optimization Pack) e, per anni, è stato uno dei riferimenti enterprise per la gestione di BitLocker con automazione dell’abilitazione della cifratura, archiviazione centralizzata (escrow) delle recovery key, reportistica e integrazione con i processi helpdesk. Il punto è che ormai MBAM è arrivato alla fine del suo ciclo di vita. Microsoft ha standardizzato la data di fine supporto esteso per diversi strumenti MDOP al 14 aprile 2026, includendo anche MBAM. Oltre questa data, non saranno più rilasciati aggiornamenti (non che fossero frequenti) e non sarà più disponibile il supporto.

In altre parole, la domanda non è se migrare, ma come farlo nel modo più indolore e controllato possibile, soprattutto quando lo scenario include:

• dispositivi già cifrati
• recovery key attualmente archiviate nel database MBAM
• Group Policy che potrebbero entrare in conflitto con nuove configurazioni
• ambienti ibridi e/o co-managed, dove è fondamentale definire chiaramente l’ambito di applicazione delle policy (per evitare sovrapposizioni)

Metodi alternativi a MBAM per la gestione BitLocker

Già dal 2019 Microsoft ha indicato chiaramente la direzione del BitLocker management in ambito enterprise, puntando su due alternative principali:

• Microsoft Intune
  à gestione cloud di BitLocker e delle recovery key
• Microsoft Configuration Manager
  à gestione on-prem, ancora molto diffusa in contesti più tradizionali o in fase di transizione

Intune consente di configurare BitLocker e gestire recovery key/reportistica, includendo anche funzionalità moderne come la rotazione delle recovery key, con integrazione in Microsoft Entra ID per l’escrow delle chiavi. Se per vincoli organizzativi o tecnici non potete ancora portare quella parte in cloud, Configuration Manager offre una gestione BitLocker on-prem e Microsoft documenta i passaggi principali per transitare da MBAM. In questo ultimo caso, però, fate attenzione ai conflitti (le GPO di MBAM possono sovrascrivere le impostazioni locali di ConfigMgr e far fallire l’onboarding e la gestione).

Ad ogni modo, anticipato nell’introduzione, in questo articolo ci concentreremo principalmente sulla soluzione con Microsoft Intune.

Escrow delle recovery key

Prima di scendere nei tecnicismi partiamo con una rassicurazione: durante una migrazione MBAM → Intune non è necessario ricifrare tutti i pc già protetti. Visto che partiamo da una situazione in cui BitLocker è già attivo sui nostri device, il focus principale sarà quello di spostare la gestione e soprattutto l’escrow delle recovery key verso Microsoft Entra ID, rendendole quindi consultabili da Intune. In pratica, potrete mantenere la cifratura dei pc così com’è, ma bisognerà assicurarsi che ogni dispositivo abbia almeno una recovery key correttamente salvata in Entra ID prima di dismettere l’infrastruttura MBAM, altrimenti rischiate di ritrovarvi con dischi cifrati e chiavi recuperabili solo dal vecchio portale/database.

Per fare il backup delle chiavi esistenti su Entra ID, il metodo più diretto è eseguire l’escrow tramite PowerShell. Microsoft mette a disposizione il cmdlet BackupToAAD-BitLockerKeyProtector, che salva in Microsoft Entra ID il key protector di tipo RecoveryPassword di un volume BitLocker. Questo approccio è particolarmente utile quando i device sono già cifrati tramite MBAM e volete semplicemente trasferire l’escrow. In contesti enterprise, il modo più pratico per farlo in massa è distribuire un remediation script di Intune che:

• rileva il KeyProtectorId di tipo RecoveryPassword sull’unità (es. C:)
• esegue il backup su Entra ID con BackupToAAD-BitLockerKeyProtector

Fatto questo, potrete verificare dal portale Intune che la recovery key risulti disponibile sul device.

In questo modo la migrazione non si trasforma in un progetto di re-encrypt, ma in un passaggio controllato di governance e operatività. Le policy di encryption BitLocker che configureremo in Intune saranno fondamentali per i nuovi dispositivi, per quelli reinstallati e per i pc che oggi non risultano ancora cifrati. Per i dispositivi già esistenti e già protetti, invece, la priorità è mettere subito in sicurezza l’escrow delle recovery key su Microsoft Entra ID, così da garantire il recupero delle chiavi anche senza dipendere da MBAM. Solo in un secondo momento ha senso standardizzare le impostazioni BitLocker in Intune dove necessario e, come ultimo step, procedere con la dismissione dell’infrastruttura MBAM.

Remediation script

Un esempio di PowerShell script, per l’escrow delle recovery key BitLocker, da distribuire ai dispositivi tramite remediation script in Intune può essere qualcosa del genere:

Anche se può sembrare controintuitivo, non è strettamente necessario creare una remediation completa; lo stesso script può essere distribuito anche solamente come detection script. In questo modo lo script girerà sicuramente, ed eseguendolo sui dispositivi gestiti, ogni client effettuerà l’escrow della propria recovery key su Microsoft Entra ID. Eseguendolo manualmente su un pc di test, l’output sarà simile a quello mostrato in figura.

Figura 1: Escrow recovery key

Mini demo: come configurare Bitlocker con Microsoft Intune

Abbiamo visto come eseguire il backup (escrow) delle recovery key su Microsoft Entra ID, che è il passaggio più importante per avviare una migrazione da MBAM a Intune in modo sicuro. A questo punto passiamo alla parte operativa con una mini-demo, in cui vedremo come iniziare a gestire BitLocker tramite Microsoft Intune come alternativa moderna a MBAM, mantenendo uno scenario tipico enterprise con dispositivi Microsoft Entra hybrid joined e recupero centralizzato delle recovery key.

Licenze e requisiti di sistema

Partiamo dai requisiti e licensing. Qui c’è un punto che genera spesso confusione. La tecnologia Bitlocker è disponibile su più edizioni di Windows, mentre la gestione avanzata e centralizzata (Bitlocker management) ha invece requisiti di licensing specifici.

Tabella 1: Edizioni Windows supportate per Bitlocker management

Tabella 2: Licenze che garantiscono l’entitlement per BitLocker management

Per maggiori informazioni sul licensing potete consultare le pagina Microsoft Windows edition and licensing requirements – Configure BitLocker mentre alla pagina System requirements – Overview trovate i requisiti di sistema.

Scenario, scope e premesse

Lo scenario della demo rappresenta una migrazione pilota della gestione di BitLocker su un singolo dispositivo. Nella demo passeremo dalla gestione Bitlocker tramite un’infrastruttura MBAM (stato as-is) ad una gestione moderna tramite Microsoft Intune (stato to-be), con l’obiettivo di validare configurazione, assenza di conflitti con altre configurazioni e recupero centralizzato delle recovery key. Lo scenario della demo include:

• Infrastruttura MBAM già presente (solo per rappresentare lo stato attuale e le recovery key esistenti)
• Group Policy (GPO) di encryption configurata con gli ADMX di MBAM (scenario molto comune in ambienti enterprise)
• Microsoft Intune operativo (tenant configurato, permessi adeguati, dispositivo già enrolled)
• Un dispositivo Microsoft Entra Hybrid Joined (nel nostro caso Windows 11) gestito in co-management tramite Intune e Configuration Manager

Nel nostro ambiente di test, le impostazioni di encryption sono attualmente governate da una GPO basata
su
admx MBAM. Prima di applicare nuove configurazioni da Intune, dobbiamo evitare che le impostazioni esistenti continuino a imporsi sul dispositivo della demo. Per questo motivo, per il device selezionato ho applicato un deny sulla GPO in modo da impedirne l’applicazione. Questo passaggio è fondamentale per prevenire conflitti tra le configurazioni legacy e quelle che andremo a distribuire con Intune. Inoltre, nella demo vogliamo abilitare la silent encryption (cifratura senza interazione utente), per questo è importante verificare che il dispositivo soddisfi i prerequisiti richiesti da Microsoft per la silent encription, che potete trovare alla pagina Prerequisites for silent encryption – Manage Bitlocker Policy.

Figura 2: Deny applicazione GPO di MBAM su dispositivo pilota

Importante: in un ambiente reale, invece di usare un deny secco, è spesso preferibile lavorare con security filtering, OU dedicate o gruppi pilota, così da controllare in modo più granulare l’ambito delle policy durante la migrazione.

Poiché il client pilota è già stato cifrato tramite MBAM, a scopo puramente dimostrativo disattiverò temporaneamente Bitlocker in modo da lasciare ad Intune il compito di riabilitare la cifratura applicando la nuova configurazione che andremo a creare. Per farlo, è sufficiente avviare il comando manage-bde -off C: da un prompt dei comandi eseguito con privilegi amministrativi. Per visualizzare lo stato di avanzamento, possiamo poi utilizzare il comando manage-bde -status.

Figura 3: Decrittografia completata su pc pilota

Configurazione in Microsoft Intune

Finite le premesse, passiamo all’atto pratico. Come si configura Bitlocker con Microsoft Intune? Ci sono vari modi per farlo, ma vi suggerisco i due metodi principali:

• Disk Encription à sezione Endpoint Security
• Device configuration profile à utilizzando il template Endpoint Protection

In termini di risultato, entrambi portano all’abilitazione di BitLocker e, se i prerequisiti sono rispettati, anche alla silent encryption (vedi Figure 8 e 9). La differenza principale sta nel fatto che Disk encryption dalla sezione Endpoint Security di Intune è più focalizzato sulla cifratura e, se si utilizza Windows 11, include anche un profilo dedicato per la configurazione PDE (Personal Data Encryption), mentre il template Endpoint protection creato tramite un Device configuration profile accorpa BitLocker dentro una baseline più ampia di endpoint protection, ma per la gestione PDE bisogna utilizzare un settings catalog o un profilo apposito. Se volete approfondire la questione vi consiglio di consultare la pagina Microsoft Policy types for BitLocker encryption.

Per lo scopo di questa demo il risultato non cambia, procederemo con il template Endpoint Protection, mentre se volete recuperare la guida per l’abilitazione di Bitlocker tramite Endpoint Security, vi suggerisco di leggere la guida di Nicola Ferrini che potete trovare alla pagina Abilitare Bitlocker con Microsoft Intune – ICTPower.

Torniamo a noi. Per prima cosa, colleghiamoci al Microsoft Intune Admin Center e navighiamo in Devices > Configuration e nella sezione Policies facciamo click su Create > New Policy

Figura 4: Creazione Endpoint Protection policy per Bitlocker – Parte 1

Nel wizard che si apre sulla vostra destra selezionare Platform Windows 10 and later e come Profile type selezionate Templates. A questo punto, nella textbox di ricerca scrivete “Endpoint” e apparirà sotto il template denominato Endpoint protection; selezionatelo e procedete facendo click su Create

Figura 5: Creazione Endpoint Protection policy per Bitlocker – Parte 2

Adesso siamo pronti per configurare la nostra policy. Nella sezione Basics, assegnare un nome al profilo (ad es. “Bitlocker”), una descrizione (facoltativo) e procedere cliccando su Next.

Figura 6: Creazione Endpoint Protection policy per Bitlocker – Parte 3

Nella sezione Configuration settings troviamo varie impostazioni di endpoint protection; a noi interessano solo le impostazioni di Windows Encryption, quindi procedete espandendo quella categoria.

Figura 7: Creazione Endpoint Protection policy per Bitlocker – Parte 4

Adesso dobbiamo configurare le voci che ci interessano per abilitare Bitlocker e gestirlo con Microsoft Intune. Per lo scopo di questa demo non ci sono grosse pretese; quindi, di seguito andremo a configurare solo alcune delle impostazioni che ci saranno utili per questo scenario. Per adattare al meglio la configurazione alle vostre esigenze, vi suggerisco di leggere attentamente la descrizione delle opzioni disponibili alla pagina Endpoint Protection – Windows Encryption Settings di Microsoft. Come anticipato, il nostro scopo è quello di abilitare Bitlocker con la silent encryption, per fare ciò ci sono un paio di accorgimenti da seguire:

Base settings + OS drive settings:

• Warning for other disk encryption = Block
• Allow standard users to enable encryption during Microsoft Entra join = Allow
• User creation of recovery key = Allow or Do not allow 256-bit recovery key
• User creation of recovery password = Allow or Require 48-digit recovery password

TPM settings:

• Compatible TPM startup = Allow TPM or Require TPM
• Compatible TPM startup PIN = Do not allow startup PIN with TPM
• Compatible TPM startup key = Do not allow startup key with TPM
• Compatible TPM startup key and PIN = Do not allow startup key and PIN with TPM

Per non appesantire la lettura, nelle schermate successive evidenzierò le impostazioni che useremo come baseline di esempio per abilitare e gestire BitLocker con Intune in modalità silent.

Figura 8: Creazione Endpoint Protection policy per Bitlocker – Parte 5

Salviamo le informazioni di recovery in Microsoft Entra ID abilitando l’apposito toggle button Save Bitlocker recovery information to Microsoft Entra ID, e abilitiamo la recovery password rotation selezionando Key rotation enabled for Microsoft Entra joined and hybrid joined devices che farà in modo di generare una nuova recovery key monouso di 48 cifre dopo che la chiave corrente di un dispositivo è stata utilizzata per sbloccarlo. È un ulteriore livello di sicurezza a cui vi suggerisco di non rinunciare.

Figura 9: Creazione Endpoint Protection policy per Bitlocker – Parte 6

Concludiamo configurando, se necessario, le impostazioni della sezione Bitlocker fixed data-drive settings, infine fare click su Next.

Figura 10: Creazione Endpoint Protection policy per Bitlocker – Parte 7

A questo punto, nella sezione Assignments, possiamo assegnare la nostra policy al gruppo pilota desiderato. Per distribuire ad un gruppo specifico fare click su Add groups, cercare il gruppo desiderato, selezionarlo con l’apposita checkbox ed infine fare click su Select. Infine, proseguiamo cliccando nuovamente su Next.

Figura 11: Creazione Endpoint Protection policy per Bitlocker – Parte 8

Per la nostra demo non sarà necessario, ma nella sezione Applicability Rules possiamo definire regole per targettizzare meglio la policy (ad esempio applicarla solo a determinate versioni di Windows o a specifiche edizioni), utile soprattutto in fase di pilot per ridurre i falsi errori “Not applicable“.

Figura 12: Creazione Endpoint Protection policy per Bitlocker – Parte 9

Infine, nella pagina Review + create controlliamo attentamente che sia tutto configurato come previsto. Se è tutto ok, proseguite cliccando su Create.

Figura 13: Creazione Endpoint Protection policy per Bitlocker – Parte 10

Dopo poco, Intune ci informerà che il nostro Device configuration profile è stato creato con successo.

Figura 14: Endpoint Protection policy per Bitlocker creata con successo

Se tornate in Devices > Configuration e troverete la nuova policy correttamente creata e assegnata. Se volete apportare modifiche, potete selezionarla e modificarla.

Figura 15: Overview Endpoint Protection policy per Bitlocker

(Opzionale) Configurazione SCCM workloads per co-management

Come abbiamo visto, nel nostro ambiente demo il dispositivo è in co-management con Configuration Manager e Microsoft Intune. Tuttavia, nel caso specifico, BitLocker è gestito da MBAM tramite GPO e non da Configuration Manager: di conseguenza, l’aspetto più importante da controllare (per evitare sovrapposizioni) è la GPO MBAM, come mostrato in Figura 2 nel capitolo “Scenario, scope e premesse”, più che la configurazione dei workloads.

Se invece nel vostro ambiente gestite la parte di BitLocker/Windows Encryption
da Configuration Manager, e volete che la gestione passi a Intune, dovete assicurarvi che il workload Endpoint Protection sia impostato su:

• Pilot Intune (consigliato in fase pilota, applicato solo ai dispositivi nella pilot collection)
• oppure Intune (per estendere la gestione a tutti i dispositivi in co-management)

Per i dettagli sulla configurazione dei workloads, fate riferimento alla documentazione ufficiale Co-management workloads – Microsoft Learn.

Figura 16: Workload Device configuration > Endpoint Protection in Configuration Manager console

Verifica finale e troubleshooting

Terminata la nostra configurazione lato Intune, vediamo adesso che cosa succede nel nostro dispositivo pilota. Come prima cosa, possiamo notare che il profilo è stato correttamente assegnato. Per verificare ciò è possibile accedere alle Impostazioni di Windows > Account > Accedi all’azienda o all’istituto di istruzione > Selezionare la connessione alla vostra azienda e fare click su Informazioni.

Figura 17: Informazioni Account aziendale

A questo punto, possiamo vedere che la nostra policy è stata correttamente applicata.

Figura 18: Verifica policy Bitlocker correttamente applicata al dispositivo

Registro di sistema

Per la verifica puntuale di tutti i settings distribuiti tramite il Device configuration profile, possiamo fare un rapido check sul registro di sistema. Al percorso HKLM:\Software\Microsoft\PolicyManager\current\Device\Bitlocker possiamo trovare la configurazione attiva che Windows sta usando in questo momento. Noterete che molte voci, come ad esempio EncriptionMethodByDriveType_ADMXInstanceData, non contengono direttamente il valore finale “leggibile” ma rimandano a un percorso sotto il provider MDM, identificato da un GUID. In questo caso, il percorso è HKLM:\Software\Microsoft\PolicyManager\providers\<GUID>\default\device\Bitlocker ed
è di fatto un modo alternativo (rispetto al report MDM Diagnostics) per vedere cosa il dispositivo ha ricevuto come policy BitLocker.

Figura 19: Troubleshooting policy Bitlocker via registro di sistema – Parte 1

Se infatti ci rechiamo al percorso sopraccitato HKLM:\Software\Microsoft\PolicyManager\providers\<GUID>\default\device\Bitlocker vedremo l’elenco dei parametri configurati da Intune (con i relativi valori) e potremo confrontarli con quanto impostato nel profilo Intune, per verificare rapidamente che la configurazione sia arrivata correttamente al client.

Figura 20: Troubleshooting policy Bitlocker via registro di sistema – Parte 2

Inoltre, dopo l’applicazione lato MDM, le impostazioni vengono replicate anche nel percorso HKLM:\SOFTWARE\Policies\Microsoft\FVE (Full Volume Encryption), lo stesso albero di registro storicamente utilizzato dalle Group Policy per BitLocker. Questa replica viene eseguita da un’attività pianificata del sistema (BitLocker MDM policy Refresh al percorso \Microsoft\Windows\BitLocker del Task Scheduler di Windows), che copia i valori ricevuti via MDM dall’area PolicyManager alla chiave FVE affinché il motore BitLocker possa applicarli correttamente.

In fase di troubleshooting, questo è un dettaglio importante poiché eventuali valori residui o conflitti (ad esempio con vecchie GPO/MBAM) possono emergere proprio sotto HKLM:\SOFTWARE\Policies\Microsoft\FVE, influenzando il comportamento della cifratura.

Figura 21: Troubleshooting policy Bitlocker via registro di sistema – Parte 3

Riga di comando

Quando BitLocker viene avviato in modalità silent, possiamo monitorare lo stato di avanzamento della cifratura anche da riga di comando. Per farlo, è sufficiente avviare il comando manage-bde -status da un prompt dei comandi eseguito con privilegi amministrativi. L’output mostrerà lo stato dell’unità e la percentuale di avanzamento.

Figura 22: Crittografia in corso su pc pilota

Quando la crittografia sarà completata, la situazione sarà come di seguito.

Figura 23: Crittografia completata su pc pilota

In parallelo, aprendo una finestra di Esplora file > Questo PC, noterete che l’unità di sistema C: risulta protetta. L’icona del disco cambia e viene visualizzato il classico lucchetto, indicando che BitLocker è attivo.

Figura 24: Verifica Bitlocker attivo da Esplora file

Event Viewer

Anche l’Event Viewer è molto utile per capire quando la cifratura parte, quando termina e se durante il processo si verificano errori o blocchi. In particolare, potete consultare i log dedicati a BitLocker al percorso Microsoft\Windows\BitLocker-API sul log Management. Qui troverete eventi che indicano l’avvio della cifratura, l’avanzamento e l’eventuale completamento, oltre a messaggi di errore utili per il troubleshooting (ad esempio quando un prerequisito non è soddisfatto o quando una policy impedisce il backup della recovery key).

Figura 25: Event ID 768 Bitlocker-API – Bitlocker encryption started

Figura 26: Event ID 845 Bitlocker-API – Bitlocker recovery information backed up in Entra ID

Lettura ed utilizzo delle recovery key

Adesso che Bitlocker è attivo sul nostro dispositivo pilota grazie alle impostazioni distribuite tramite il profilo Intune, vediamo come recuperare la recovery key in caso di necessità. Per prima cosa, colleghiamoci nuovamente al Microsoft Intune Admin Center e navighiamo in Devices > Windows

Figura 27: Recupero recovery key da Microsoft Intune – Parte 1

Nella barra di ricerca di Intune, digitate il nome del dispositivo per il quale volete recuperare la recovery key di BitLocker. Quando il device compare nei risultati, selezionatelo con un click.

Figura 28: Recupero recovery key da Microsoft Intune – Parte 2

All’interno della pagina di dettaglio del dispositivo, nel menu di sinistra, fate click su Recovery keys. Nella schermata successiva troverete il BitLocker Key ID e il link Show recovery key. Cliccando su Show recovery key, si aprirà un pannello laterale (a destra) con i dettagli relativi alla chiave, tra cui data e ora del backup, key id, recovery key.

Figura 29: Recupero recovery key da Microsoft Intune – Parte 3

Per visualizzare la recovery key è sufficiente fare click sull’icona a forma di occhio. Per copiarla, potete utilizzare il pulsante Copy (button azzurro) presente nella stessa schermata.

Figura 30: Recupero recovery key da Microsoft Intune – Parte 4

Una volta visualizzata (e, se necessario, copiata), la BitLocker recovery key può essere utilizzata per sbloccare l’unità nei casi in cui BitLocker richieda una verifica aggiuntiva, ad esempio dopo modifiche significative all’hardware/firmware, dopo interventi sul TPM, o quando il sistema entra in recovery mode. Nel nostro scenario abbiamo anche abilitato la recovery key rotation; questo significa che, dopo l’utilizzo della recovery key, il dispositivo può generare automaticamente una nuova recovery key e aggiornarla nel sistema di escrow (Microsoft Entra ID/Intune). In questo modo, la chiave “vecchia” non resta valida più del necessario e si riduce il rischio che una recovery key usata/circolata possa essere riutilizzata in futuro.

Checklist finale

Ricapitoliamo gli step fondamentali per una migrazione fatta bene.

Partite con un pilot ristretto e verificate prerequisiti e policy esistenti (GPO MBAM/BitLocker, eventuali configurazioni ConfigMgr, baseline già distribuite). Se ci sono GPO legacy, isolate il pilota per evitare conflitti. Poi fate la cosa più importante: escrow delle recovery key su Microsoft Entra ID per i dispositivi già cifrati (ad esempio via Intune Remediations) e verificate dal portale Intune che le chiavi siano effettivamente disponibili. Senza questo passaggio, la dismissione di MBAM diventa un rischio.

Solo dopo passate alla standardizzazione delle policy in Intune (Disk encryption o Endpoint protection) e validate sul pilota cifratura e report. In caso di anomalie, usate Event Viewer e registro (PolicyManager/FVE) per il troubleshooting. Quando tutto è stabile, estendete a ondate e monitorate copertura escrow + stato cifratura. Infine, con evidenze alla mano, procedete alla dismissione dell’infrastruttura MBAM e delle relative GPO/configurazioni legacy.

Ordine corretto: assesment à escrow → policy → verifica à dismissione.

Conclusioni

La fine del supporto esteso di MBAM non è una scadenza da inseguire, ma è un’occasione concreta per semplificare la gestione della cifratura, ridurre dipendenze on-prem e portare BitLocker in un modello
modern management con Microsoft Intune. In questo articolo abbiamo visto cosa cambia con l’end of support, quali alternative mette a disposizione Microsoft e come impostare una mini-migrazione “pilota” in un contesto realistico (GPO MBAM, device Microsoft Entra Hybrid Joined, eventuale co-management), fino alla verifica della cifratura, al monitoraggio e al recupero/rotazione delle recovery key.

È molto più facile governare la migrazione quando siete voi a scegliere i tempi, piuttosto che quando è la data di fine supporto a scegliere per voi.