Microsoft Intune : activer BitLocker et gérer les clés de récupération

La gestion BitLocker via Intune (intune bitlocker gestion clés) est aujourd'hui la méthode de référence pour chiffrer les postes Windows 10/11 gérés par Microsoft Endpoint Manager, sans infrastructure PKI complexe ni serveur MBAM. La clé de récupération est automatiquement escrowée dans Azure AD / Entra ID, consultable par les administrateurs depuis le portail Azure en quelques clics. Avant Intune, le moindre oubli de sauvegarde de clé signifiait un disque illisible et un utilisateur bloqué — un classique du support technique. Aujourd'hui, avec une politique correctement configurée, la clé existe toujours quelque part dans le cloud, et le processus de récupération prend moins de cinq minutes. Ce guide couvre l'intégralité de la configuration : création du profil Disk Encryption, paramètres AES-256-XTS, PIN préboot, rotation des clés, rapport de conformité et vérification PowerShell en production. Sur les migrations Intune que j'ai accompagnées ces deux dernières années, la moitié des organisations avaient des clés BitLocker manquantes ou non sauvegardées — un risque métier énorme en cas de panne matérielle ou de perte de machine.

Pourquoi gérer BitLocker via Intune plutôt que par GPO classique ?

La question revient souvent lors des migrations vers le cloud. La réponse courte : la GPO BitLocker fonctionne parfaitement dans un environnement hybride ou full AD on-premise. Mais dès qu'une partie du parc est Entra ID Joined (anciennement Azure AD Joined) sans liaison au domaine local, la GPO ne s'applique plus. Intune prend le relais et gère les deux populations — hybrides et cloud-only — depuis une interface unique.

L'autre avantage majeur : la centralisation des clés de récupération. Avec une GPO classique, les clés partaient dans l'AD on-premise, et leur consultation nécessitait soit un accès RSAT, soit un portail MBAM. Avec Intune et Entra ID, n'importe quel administrateur global ou helpdesk — avec le rôle adéquat — consulte la clé depuis le portail Azure en quelques secondes. La traçabilité est automatique : chaque consultation est journalisée dans les logs d'audit Entra ID. C'est faisable à vérifier dans Entra ID > Journaux d'audit, filtre Activité = "Recover BitLocker key".

Dernier point : le chiffrement silencieux. Avec Intune, si le poste dispose d'un TPM et remplit les prérequis, BitLocker s'active en arrière-plan sans aucune interaction utilisateur. Aucun déploiement SCCM, aucun script de démarrage, aucune séquence de tâches — juste une politique assignée à un groupe Entra ID et le chiffrement démarre à la prochaine synchronisation MDM. Sur du matériel moderne, le chiffrement complet d'un SSD NVMe de 512 Go prend moins de 30 minutes sans impact perceptible sur les performances.

Prérequis techniques avant le déploiement

Quelques vérifications s'imposent avant de créer le premier profil. Passer à côté d'un prérequis peut bloquer silencieusement le chiffrement sans alerte claire dans l'interface Intune — l'appareil reste simplement en statut "Not Encrypted" sans raison apparente.

• Appareils Entra ID Joined ou Hybrid Joined — les appareils AD on-premise non-hybrides ne reçoivent pas les politiques Intune.
• Chip TPM 1.2 minimum, TPM 2.0 recommandé — vérifiable avec Get-WmiObject Win32_Tpm -Namespace root\cimv2\security\microsofttpm.
• Licence Microsoft 365 E3/E5 ou Intune Plan 1 — BitLocker Management est inclus sans surcoût dans ces licences.
• Appareils inscrits dans Intune — statut "Enrolled" visible dans le portail Endpoint Manager.
• Partition système de 250 Mo minimum — BitLocker nécessite un volume système séparé du volume OS, présent par défaut sur toute installation Windows 10/11 propre.
• Secure Boot activé pour les appareils UEFI — recommandé par le guide de déploiement BitLocker Microsoft Learn.

Créer le profil Disk Encryption dans Intune

La création se fait dans Intune > Endpoint Security > Disk Encryption > Create Policy. Choisissez la plateforme "Windows 10 and later" et le profil "BitLocker". Voici les paramètres clés à configurer et leur justification :

Comment configurer le PIN préboot sans bloquer les utilisateurs ?

Le PIN préboot est la fonctionnalité qui divise le plus les équipes IT. D'un côté, il renforce significativement la protection — même si le disque est extrait physiquement, il reste illisible sans le PIN. De l'autre, il ajoute une étape au démarrage que les utilisateurs détestent, surtout sur les ordinateurs portables qui redémarrent après chaque mise à jour Windows.

La solution intermédiaire adoptée par la plupart des organisations matures : exiger le PIN uniquement pour les profils à risque élevé (direction, finance, RH, IT) et activer le chiffrement silencieux pour le reste du parc. Le chiffrement silencieux s'appuie uniquement sur le TPM, sans étape utilisateur, mais offre une protection moindre contre les attaques physiques sophistiquées de type DMA ou cold-boot. Pour les postes qui voyagent fréquemment — commerciaux, consultants — le PIN préboot est non-négociable.

Pour les machines sans TPM (rares sur du matériel post-2016 mais encore présentes dans certains parcs hétérogènes), il faut activer l'option "Allow BitLocker without a compatible TPM" et utiliser un mot de passe de démarrage. Moins pratique pour l'utilisateur, mais fonctionnel. Personnellement, je recommande de profiter de ce contexte pour planifier le remplacement des machines sans TPM — en 2026, c'est du matériel qui dépasse souvent les 8 ans et qui présente d'autres risques de sécurité.

Vérifier l'état de chiffrement avec PowerShell

Le portail Intune donne une vue globale, mais pour un audit précis poste par poste ou pour diagnostiquer une non-conformité, PowerShell reste indispensable. Ces commandes s'exécutent en local sur le poste ou via une session PowerShell distante.

# Vérifier l'état de chiffrement de tous les volumes
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionPercentage, LockStatus, KeyProtector

# Obtenir le détail des protecteurs de clé (TPM, PIN, Recovery Key)
$volumes = Get-BitLockerVolume
foreach ($vol in $volumes) {
    Write-Host "Volume: $($vol.MountPoint) — Statut: $($vol.VolumeStatus)"
    foreach ($protector in $vol.KeyProtector) {
        Write-Host "  Protecteur: $($protector.KeyProtectorType) | ID: $($protector.KeyProtectorId)"
    }
}

# Forcer la sauvegarde de la clé de récupération dans Entra ID
# Nécessaire pour les machines déjà chiffrées avant l'inscription Intune
$vol = Get-BitLockerVolume -MountPoint "C:"
$recoveryKeyId = ($vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }).KeyProtectorId
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $recoveryKeyId

# Vérifier que la sauvegarde a bien eu lieu (Event Log Event 845)
Get-WinEvent -LogName "Microsoft-Windows-BitLocker/BitLocker Management" |
    Where-Object { $_.Id -eq 845 } |
    Select-Object -First 5 TimeCreated, Message

La commande BackupToAAD-BitLockerKeyProtector est particulièrement utile lors de la migration depuis une GPO : les clés existantes ne sont pas automatiquement escrowées dans Entra ID. Selon l'audit Microsoft Learn sur la gestion du chiffrement dans Intune, cette étape est obligatoire pour garantir la récupération centralisée des clés.

Gérer les clés de récupération depuis le portail Azure

Depuis Portail Azure > Entra ID > Appareils > Clés de récupération BitLocker, les administrateurs et le helpdesk peuvent consulter la clé de récupération d'un appareil spécifique. Les rôles qui ont accès à cette fonctionnalité sont "Cloud Device Administrator", "Intune Service Administrator" et "Global Administrator".

Chaque consultation de clé est tracée dans les journaux d'audit Azure AD. Cela permet de détecter des consultations anormales — un compte helpdesk qui consulte 50 clés en une nuit est un signal d'alerte fort. Ces logs sont accessibles dans Entra ID > Journaux d'audit, filtre Activité = "Recover BitLocker key".

Pour les organisations soumises à ISO 27001 ou NIS 2, cette traçabilité est un élément de conformité important. Notre service d'accompagnement ISO 27001 inclut systématiquement la vérification de la gestion des clés de chiffrement comme contrôle A.8.24.

Configurer la rotation automatique des clés de récupération

La rotation automatique est activée dans le profil BitLocker via le paramètre "Enable client-driven recovery password rotation". Une fois activée, chaque fois qu'un utilisateur utilise sa clé de récupération pour déverrouiller son disque, une nouvelle clé est générée et escrowée dans Entra ID — l'ancienne est invalidée automatiquement.

Sans rotation, la même clé reste valide indéfiniment. Si un utilisateur la partage par email ou par téléphone au helpdesk — et ça arrive bien plus souvent qu'on ne le croit — ou si elle est compromise lors d'un incident, le disque reste vulnérable. La rotation élimine ce risque résiduel. La documentation officielle Microsoft sur ce paramètre est disponible dans le guide BitLocker Group Policy Settings.

Pour forcer une rotation immédiate sans attendre une utilisation de clé, le portail Intune propose l'action "Rotation des clés BitLocker" sur l'appareil cible (Intune > Appareils > appareil > ... > Rotation des clés BitLocker). La nouvelle clé apparaît dans Entra ID en général dans l'heure suivante, après la prochaine synchronisation MDM.

Surveiller la conformité BitLocker dans les rapports Intune

Le tableau de bord de conformité BitLocker est accessible dans Intune > Rapports > Endpoint Security > BitLocker. Il affiche par appareil : le statut de chiffrement du volume C:, la méthode de chiffrement, la présence d'un protecteur TPM, la disponibilité de la clé de récupération dans Entra ID, et la conformité avec la politique assignée.

Pour les organisations qui ont besoin d'un rapport plus détaillé ou d'une exportation CSV, l'automatisation via PowerShell et Microsoft Graph API permet d'interroger Intune et de générer des rapports personnalisés. Notre article sur l'automatisation de l'audit Microsoft 365 avec PowerShell couvre les bases de cette approche. Les politiques de conformité M365 au sens large sont abordées dans notre guide sur les outils d'audit M365.

Que faire si BitLocker ne s'active pas sur un poste ?

Les causes de non-activation sont variées. Voici les plus fréquentes par ordre de probabilité, avec le diagnostic à effectuer :

1. TPM non initialisé ou désactivé dans le BIOS/UEFI — Vérifier dans Device Manager > Security Devices et dans les paramètres UEFI (option "Security > TPM" ou similaire selon le constructeur).
2. Partition système manquante ou trop petite — BitLocker nécessite une partition système distincte de 250 Mo minimum, présente automatiquement depuis Windows Vista mais parfois absente sur des disques clonés depuis des images mal préparées.
3. Appareil non encore synchronisé avec Intune — Forcer une synchronisation depuis l'application Portail d'entreprise > Paramètres > Synchroniser, ou via le portail Intune > Appareils > appareil > Synchroniser.
4. Conflit avec une GPO BitLocker existante — Les GPO on-premise peuvent bloquer les politiques Intune si elles définissent des paramètres contradictoires. Utiliser gpresult /h rapport.html pour identifier la source du conflit.
5. Licence Intune non assignée — Vérifier dans Entra ID > Utilisateurs > Licences que l'utilisateur dispose bien d'une licence Intune Plan 1 ou Microsoft 365 E3/E5.

# Diagnostic complet des prérequis BitLocker
# Vérifier l'état du TPM
$tpm = Get-Tpm
Write-Host "TPM présent: $($tpm.TpmPresent)"
Write-Host "TPM activé: $($tpm.TpmEnabled)"
Write-Host "TPM propriété établie: $($tpm.TpmOwned)"
Write-Host "Version TPM spécification: $($tpm.ManufacturerVersion)"

# Vérifier les erreurs Intune dans le journal des événements
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Operational" |
    Where-Object { $_.Message -like "*BitLocker*" } |
    Select-Object TimeCreated, Id, Message -First 10

# Vérifier les stratégies MDM BitLocker appliquées
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\FVE"
if (Test-Path $regPath) {
    Get-Item $regPath | Get-ItemProperty | Format-List
} else {
    Write-Warning "Aucune stratégie BitLocker trouvée dans le registre MDM"
}

# Outil diagnostic MDM complet (génère un rapport HTML)
MdmDiagnosticsTool.exe -out C:\Temp\MdmDiag

Intégration avec l'architecture Zero Trust Microsoft 365

Dans une architecture Zero Trust, le chiffrement du disque est l'un des signaux de confiance évalués par les politiques d'accès conditionnel Entra ID. Un appareil non chiffré peut se voir refuser l'accès aux applications cloud sensibles — Microsoft Teams, SharePoint, Exchange Online — via les politiques Conditional Access.

La configuration se fait dans Entra ID > Accès conditionnel > Nouvelle politique, condition "État de conformité de l'appareil = Conforme". La conformité BitLocker est l'un des critères de la politique de conformité appareil Intune. Pour approfondir l'implémentation Zero Trust M365, notre guide sur l'architecture Zero Trust Microsoft 365 détaille l'ensemble des contrôles complémentaires, notamment l'intégration avec la sécurisation des accès M365 avec MFA.

Je recommande systématiquement de combiner chiffrement BitLocker, MFA et politique d'accès conditionnel dès le début du déploiement Intune, plutôt que d'ajouter ces contrôles en ordre dispersé sur plusieurs mois. Le rattrapage est toujours plus douloureux qu'une configuration correcte dès le départ — et les incidents de sécurité n'attendent pas la fin du projet de déploiement.

Migrer depuis MBAM on-premise vers Intune

Si votre organisation vient d'un environnement MBAM (Microsoft BitLocker Administration and Monitoring) on-premise, la migration vers Intune nécessite une étape de transition pour que les clés existantes s'escrowent dans Entra ID. La commande BackupToAAD-BitLockerKeyProtector est le pivot de cette migration.

# Script de migration des clés BitLocker MBAM vers Entra ID
# A déployer via Intune comme script PowerShell sur les machines cibles

param([string]$MountPoint = "C:")

function Migrate-BitLockerKeyToAAD {
    param([string]$Drive)

    $vol = Get-BitLockerVolume -MountPoint $Drive -ErrorAction Stop
    $keyProtectors = $vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }

    if (-not $keyProtectors) {
        Write-Warning "[$Drive] Aucune clé de récupération trouvée — génération d'une nouvelle clé"
        # Ajouter un protecteur Recovery Password
        Add-BitLockerKeyProtector -MountPoint $Drive -RecoveryPasswordProtector
        # Récupérer le nouveau protecteur
        $vol = Get-BitLockerVolume -MountPoint $Drive
        $keyProtectors = $vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }
    }

    foreach ($protector in $keyProtectors) {
        try {
            BackupToAAD-BitLockerKeyProtector -MountPoint $Drive -KeyProtectorId $protector.KeyProtectorId
            Write-Host "[$Drive] Clé sauvegardée dans Entra ID : $($protector.KeyProtectorId)" -ForegroundColor Green
        } catch {
            Write-Error "[$Drive] Échec sauvegarde clé $($protector.KeyProtectorId) : $_"
        }
    }
}

Migrate-BitLockerKeyToAAD -Drive $MountPoint

# Vérifier l'état final
$vol = Get-BitLockerVolume -MountPoint $MountPoint
Write-Host "Statut final : $($vol.VolumeStatus) | Méthode : $($vol.EncryptionMethod)"

Ce script peut être déployé directement depuis Intune > Appareils > Scripts sur un groupe de machines ciblées. Après exécution, vérifier dans Entra ID > Appareils > Clés de récupération BitLocker que les clés apparaissent bien. Notre guide sur l'audit de sécurité Microsoft 365 propose un processus complet de vérification post-migration.

Questions fréquentes sur BitLocker et Intune

BitLocker Intune chiffre-t-il aussi les disques externes et les clés USB ?

Oui, via le profil BitLocker dans Intune, vous pouvez exiger le chiffrement BitLocker To Go pour les lecteurs amovibles. Le paramètre "Removable data drives require BitLocker protection" impose le chiffrement avant toute écriture sur une clé USB ou un disque externe. La clé de récupération peut être sauvegardée dans Entra ID ou dans le compte Microsoft de l'utilisateur selon la configuration. Cette option est particulièrement utile pour les organisations soumises au RGPD qui veulent éviter la fuite de données personnelles via des supports amovibles.

Comment récupérer une clé BitLocker si le portail Azure n'est pas disponible ?

Si le portail Azure est inaccessible, les clés de récupération peuvent être consultées via Microsoft Graph API avec un token d'accès valide, ou via PowerShell avec Get-MgDeviceBitlockerRecoveryKey du module Microsoft.Graph. Pour les environnements critiques, il est conseillé d'exporter périodiquement les clés dans un coffre-fort sécurisé hors-ligne ou Azure Key Vault. Le NIST recommande dans sa publication NIST SP 800-111 de disposer d'au minimum deux copies des clés de chiffrement stockées séparément.

Quelle est la différence entre le chiffrement silencieux et le chiffrement avec PIN préboot ?

Le chiffrement silencieux utilise uniquement le TPM comme protecteur — le disque se déverrouille automatiquement au démarrage si le matériel n'a pas changé. C'est transparent pour l'utilisateur mais ne protège pas contre un attaquant ayant accès physique au système allumé. Le PIN préboot ajoute un facteur d'authentification supplémentaire qui bloque le démarrage sans le PIN, même pour quelqu'un qui aurait extrait le disque. Pour les postes qui ne voyagent pas ou restent dans des locaux sécurisés, le chiffrement silencieux est souvent suffisant.

BitLocker via Intune est-il compatible avec les exigences NIS 2 et ISO 27001 ?

Oui. Le chiffrement des données au repos est une exigence explicite de la directive NIS 2 (article 21, mesures techniques) et de l'ISO 27001:2022 (contrôle A.8.24 — utilisation de la cryptographie). Intune BitLocker avec escrow Entra ID répond à ces exigences et fournit la traçabilité nécessaire aux audits de certification. Notre service de conformité NIS 2 et notre accompagnement ISO 27001 peuvent vous aider à documenter cette conformité dans votre SMSI.

Peut-on forcer la rotation immédiate d'une clé de récupération sans attendre qu'elle soit utilisée ?

Oui, via le portail Intune (Appareils > appareil cible > ... > Rotation des clés BitLocker) ou via Graph API avec POST /deviceManagement/managedDevices/{id}/rotateBitLockerKeys. La rotation est asynchrone — la nouvelle clé apparaît dans Entra ID en général dans l'heure suivante, après la prochaine synchronisation MDM. La rotation manuelle est utile après une suspicion de compromission d'une clé, par exemple si un utilisateur a communiqué sa clé par email ou téléphone au support.