BitLocker Enterprise com Intune em 2026: Como Implementar e Gerir Cifragem para PME?
✎ Duarte Spínola | 2026-07-14
A cifragem de discos deixou de ser opcional em ambientes corporativos. Com o Windows 11 24H2 e a evolução do Microsoft Intune, o BitLocker tornou-se a solução nativa de referência para protecção de dados em repouso em dispositivos Windows geridos. Para uma PME com 25 colaboradores, a combinação BitLocker + Intune + Entra ID oferece gestão centralizada, escrow automático de recovery keys e relatórios de compliance sem custos adicionais de licenciamento de terceiros — desde que correctamente configurada. Este artigo cobre todos os componentes técnicos necessários, desde os requisitos de hardware (TPM 2.0, Secure Boot) até ao troubleshooting avançado com eventos 845/846 e firmware TPM.
A documentação oficial do BitLocker está disponível em learn.microsoft.com — BitLocker, e a configuração via Intune está documentada em learn.microsoft.com — Encrypt devices with BitLocker in Intune.
1. Requisitos de Hardware: TPM 2.0 e Secure Boot
O BitLocker Enterprise em 2026 assenta numa fundação de hardware que garante que as chaves de cifragem nunca são expostas em texto simples no sistema operativo. Dois componentes são indispensáveis:
TPM 2.0 (Trusted Platform Module) — Um chip criptográfico dedicado, soldado à motherboard, que armazena chaves RSA/ECC e executa operações de selagem (sealing) e desselagem (unsealing) sem expor o material criptográfico ao SO. O TPM 2.0 é requisito obrigatório no Windows 11 e pré-requisito para o BitLocker com TPM protector. A Microsoft recomenda especificamente TPM 2.0 com firmware actualizado — ver TPM recommendations e Trusted Platform Module overview.
Secure Boot — Garante que apenas bootloaders assinados digitalmente executam durante o arranque, impedindo bootkits e rootkits de se instalarem antes do Windows. O Secure Boot é parte do UEFI e deve estar activo no firmware. Documentação oficial em learn.microsoft.com — Secure Boot.
| Requisito | Mínimo | Recomendado (2026) | Impacto se Ausente |
|---|---|---|---|
| TPM | 2.0 (spec rev 1.38+) | 2.0 com firmware 15.0+ | BitLocker não activa com protector TPM |
| Secure Boot | Activo (UEFI) | Activo + PK configurado | Chave de arranque não protegida contra tampering |
| Processador | TPM 2.0 pronto a usar | Pluton ou TPM discreto (Infineon, Nuvoton) | Semelhante a não ter TPM |
| Modo de arranque | UEFI (não Legacy/CSM) | UEFI nativo, CSM desactivado | BitLocker não suporta modo Legacy |
| Partição de recuperação | WinRE presente | WinRE com ≥1 GB livre | Recovery ambiente não disponível |
Em máquinas sem TPM 2.0 (por exemplo, hardware legacy anterior ao Windows 11), o BitLocker pode ainda ser activado com protector USB (pen com chave de arranque), mas este cenário é desaconselhado em 2026 por requerer intervenção manual do utilizador em cada arranque e não suportar escrow automático no Entra ID.
Verificação rápida de hardware via PowerShell
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated, ManufacturerVersion# Verificar Secure Boot
Confirm-SecureBootUEFI
# Verificar estado do WinRE
reagentc /info
Se Confirm-SecureBootUEFI retornar False, o Secure Boot está desactivado na UEFI e deve ser activado antes de implementar BitLocker. Se o TPM não estiver Ready, executar Initialize-Tpm após activar o chip na UEFI.
2. Cifragem XTS-AES-256: O Padrão em 2026
O BitLocker utiliza o modo XTS (XEX-based Tweaked-codebook mode with ciphertext Stealing) com o algoritmo AES, conforme o padrão NIST SP 800-38E. Em 2026, a Microsoft recomenda XTS-AES-256 para discos de sistema operativo e XTS-AES-128 para discos de dados e removíveis, equilibrando segurança e performance.
| Parâmetro | XTS-AES-128 | XTS-AES-256 | Notas |
|---|---|---|---|
| Tamanho da chave | 128 bits | 256 bits | XTS usa duas sub-chaves; total 256 ou 512 bits |
| Unidades de cifragem | Sector (512 B ou 4 KB) | Sector (512 B ou 4 KB) | Cifragem sector-a-sector |
| Performance (SSD NVMe) | Base | -2 a -5% vs 128 | Impacto negligenciável em SSDs modernos |
| Performance (HDD) | Base | -8 a -12% vs 128 | Mais notório em discos mecânicos |
| Recomendação Microsoft | Dados/USB | SO (OS drive) | Ver BitLocker FAQ |
| Conformidade FIPS 140 | Sim | Sim | Ambos validados |
A escolha do algoritmo é definida na política do Intune ou via CSP (BitLocker configuration service provider). O CSP do BitLocker está documentado em learn.microsoft.com — BitLocker CSP. A configuração via Group Policy on-premise continua disponível, mas em cenários cloud-only com Intune, o CSP é o mecanismo nativo.
Configurar XTS-AES-256 via Intune (Settings Catalog)
No Intune, a cifragem do disco de SO é configurada em dois locais:
- Endpoint Security > Disk Encryption — perfil BitLocker com opções de cifragem, recovery e OS drive
- Settings Catalog — acesso granular a todas as políticas BitLocker do CSP
A definição EncryptionMethodByDriveType no CSP aceita os valores:
AES256XTS → XTS-AES-256 (recomendado para SO)
Para uma PME, recomenda-se XTS-AES-256 no disco de SO e XTS-AES-128 em discos removíveis, optimizando a performance de pens USB sem comprometer a segurança do disco principal.
Mais detalhes sobre algoritmos e cifragem no BitLocker FAQ oficial.
3. Perfil de Configuração BitLocker no Intune (Endpoint Protection)
A implementação do BitLocker através do Intune faz-se via perfis de Endpoint Security, especificamente o template “Disk Encryption”. O fluxo de criação do perfil é o seguinte:
Passo 1 — Criar o perfil:
- No Intune admin center (intune.microsoft.com), navegar para Endpoint Security > Disk encryption
- Seleccionar Create Profile > Windows 10/11
- Nomear o perfil (ex:
BitLocker-PME-Base)
Passo 2 — Configurar o disco de SO (OS Drive):
| Definição | Valor Recomendado | Descrição |
|---|---|---|
| Enable BitLocker for OS drive | Sim | Activa cifragem automática |
| Encryption method | XTS-AES-256 | Algoritmo de cifragem |
| BitLocker after OS drive | Bloquear | Não permitir arranque sem cifragem |
| TPM protector | TPM + PIN | Protector primário |
| Minimum PIN length | 6 dígitos | Mínimo para PIN numérico |
| Recovery key backup | Entra ID + Active Directory | Escrow duplo (se hybrid) |
| Recovery key rotation | Habilitado (a cada rotação) | Rotação após recovery |
| Pre-boot recovery message | Customizada | Mensagem com contacto IT |
Passo 3 — Configurar discos de dados e removíveis:
| Definição | Disco de Dados Fixo | Disco Removível (USB) |
|---|---|---|
| Cifragem | Opcional (auto-encrypt) | Obrigatória para escrita |
| Read-access sem BitLocker | Bloquear | Bloquear |
| Write-access sem BitLocker | Permitir | Bloquear |
| Auto-unlock | Habilitado com protector TPM | Não aplicável |
| Encryption method | XTS-AES-128 | XTS-AES-128 |
A documentação completa da configuração de perfis no Intune está em Encrypt devices with BitLocker in Intune e Settings Catalog no Intune.
Nota sobre o Endpoint Protection profile (legacy)
O Intune já teve um template “Endpoint Protection” que incluía configurações BitLocker. Em 2026, este foi substituído pelo template “Disk Encryption” em Endpoint Security, mas o template legacy ainda funciona para compatibilidade. Para novas implementações, usar sempre o template Disk Encryption — é mais granular e recebe actualizações mais frequentes. O perfil de Endpoint Protection clássico continua documentado em Device configuration profiles.
Atribuição e filtering
Para uma PME com 25 colaboradores, a atribuição deve ser feita a grupos de dispositivos (não utilizadores) para garantir que a política aplica independentemente de quem inicia sessão. Recomenda-se:
- Grupo
All-Windows-11-Devices— perfil BitLocker base - Grupo
BitLocker-Excluded— dispositivos de excepção (servidores, kiosks)
Usar Intune Filters para excluir automaticamente dispositivos sem TPM 2.0:
# Ou via Intune admin center > Filters > Create
4. Recovery Key Backup no Entra ID e Escrow Automático
O escrow automático de recovery keys é o componente mais crítico do BitLocker Enterprise. Sem escrow, um dispositivo cifrado que perca acesso ao TPM (por atualização de firmware, mudança de motherboard, ou corrupção) torna-se inacessível — os dados são irrecuperáveis sem a recovery key de 48 dígitos.
Como funciona o escrow no Entra ID
Quando um dispositivo Windows 11 está associado ao Entra ID (Azure AD Joined) ou associado de forma híbrida (Hybrid Azure AD Join), o BitLocker regista automaticamente a recovery key no objecto do dispositivo no Entra ID. Este processo é totalmente automático quando configurado via política Intune — não requer intervenção do utilizador.
O fluxo é o seguinte:
- O dispositivo recebe a política BitLocker do Intune
- O BitLocker activa a cifragem com protector TPM (+ PIN se configurado)
- O BitLocker gera uma recovery key numérica de 48 dígitos
- O cliente do Entra ID faz backup da recovery key para o objecto do dispositivo
- O admin pode visualizar a key no portal (entra.microsoft.com > Devices > propriedades do dispositivo > BitLocker recovery keys)
A gestão de recovery keys no Entra ID está documentada em Manage device identities in Entra ID.
Rotação de recovery keys
O Intune suporta rotação automática de recovery keys. Quando activada, a key é regenerada:
- Após cada uso da recovery key (recovery event)
- Após mudança de hardware (TPM reset)
- Manualmente via Intune admin center
A rotação garante que uma key usada para recovery não permanece válida indefinidamente, reduzindo a janela de exposição.
Backup manual via PowerShell
Em cenários onde o escrow automático falha (por exemplo, dispositivo não correctamente joined ao Entra ID), é possível forçar o backup manual:
$vol = Get-BitLockerVolume -MountPoint “C:”
$protector = $vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq “RecoveryPassword” }# Forçar backup da recovery key para o Entra ID (Azure AD)
BackupToAAD-BitLockerKeyProtector -MountPoint “C:” -KeyProtectorId $protector.KeyProtectorId
# Verificar resultado
Get-BitLockerVolume -MountPoint “C:” | Select-Object -ExpandProperty KeyProtector |
Where-Object { $_.KeyProtectorType -eq “RecoveryPassword” }
A documentação do cmdlet BackupToAAD-BitLockerKeyProtector está em learn.microsoft.com — BackupToAAD-BitLockerKeyProtector.
Onde consultar as recovery keys
| Portal | Localização | Permissão Necessária |
|---|---|---|
| Entra ID (entra.microsoft.com) | Identity > Devices > All devices > [device] > BitLocker recovery keys | Global Admin, Cloud Device Admin, Helpdesk Admin |
| Intune (intune.microsoft.com) | Devices > Windows > [device] > Recovery keys | Intune Admin, Helpdesk |
| Microsoft Graph API | /devices/{id}/bitlockerRecoveryKeys |
BitlockerKey.Read.All |
| Azure AD Graph (deprecated) | N/A | Migrado para Graph API |
A API do Microsoft Graph permite automação completa de consulta de recovery keys, útil para sistemas de ticketing integrados.
5. Silent vs Interactive Encryption e Políticas de PIN de Arranque
O Intune oferece dois modos de implementação do BitLocker: Silent (sem interacção do utilizador) e Interactive (com prompts). A escolha depende do perfil de dispositivos e utilizadores.
Silent Encryption
Na cifragem silenciosa, o BitLocker é activado automaticamente em segundo plano, sem qualquer prompt ou notificação ao utilizador. A cifragem ocorre após o registo do dispositivo no Intune e o recebimento da política. O utilizador não precisa de introduzir PIN ou password — o protector é apenas TPM (sem PIN).
| Aspecto | Detalhe |
|---|---|
| Requisitos | TPM 2.0 pronto, Secure Boot activo, Entra ID Join completo |
| Protector | TPM apenas (sem PIN) |
| Experiência do utilizador | Transparente — sem prompts |
| Tempo de cifragem | 20-60 min para SSD 256 GB; 2-6 horas para HDD 1 TB |
| Recovery key backup | Automático para Entra ID |
| Adequado para | Dispositivos Azure AD Joined, Autopilot, hardware standardizado |
Interactive Encryption
Na cifragem interactiva, é pedido ao utilizador para definir um PIN de arranque ou password. O protector é TPM + PIN, o que adiciona uma camada de protecção contra ataques físicos (evil maid attacks).
| Aspecto | Detalhe |
|---|---|
| Requisitos | TPM 2.0 pronto + interacção do utilizador |
| Protector | TPM + PIN (numérico ou alfanumérico) |
| Experiência do utilizador | Prompt inicial + PIN em cada arranque |
| Segurança | Superior — protecção contra evil maid |
| Adequado para | Dispositivos com dados sensíveis, executivos, portable devices |
Configuração do PIN no Intune
A política de PIN é definida no perfil BitLocker do Intune:
| Definição | Valor | Notas |
|---|---|---|
| Configure pre-boot PIN | Require | Obriga PIN no arranque |
| Minimum PIN length | 6 | Mínimo de 4, máximo de 20 |
| Allow enhanced PINs (alphanumeric) | Sim | Permite letras + números |
| Allow standard PINs (numeric only) | Sim | PIN numérico no teclado numérico |
| Reset PIN after failed attempts | 5 | Após 5 tentativas, requer recovery key |
Comparação para PME
| Critério | Silent | Interactive (TPM+PIN) |
|---|---|---|
| Esforço de deployment | Mínimo | Médio (formação de utilizadores) |
| Segurança contra acesso físico | TPM-only | TPM + PIN |
| Suporte de helpdesk | Menos tickets recovery | Mais tickets (PIN esquecido) |
| Compliance (ISO 27001, GDPR) | Suficiente para maioria | Recomendado para dados sensíveis |
| Adequado para 25 colaboradores | Sim — deployment em massa | Selectivo (directores, financeiros) |
Para uma PME típica de 25 colaboradores, a abordagem recomendada é: Silent encryption para todos os dispositivos (baseline de segurança) + Interactive com TPM+PIN para dispositivos de utilizadores com acesso a dados financeiros, clientes ou propriedade intelectual. Esta abordagem dual minimiza tickets de helpdesk enquanto protege os activos mais sensíveis.
6. BitLocker para Discos Removíveis (USB) e Auto-Unlock
O BitLocker To Go é a extensão do BitLocker para dispositivos de armazenamento removíveis — pens USB, discos externos, cartões SD. Em 2026, com o aumento de ataques via dispositivos USB maliciosos e fugas de dados por dispositivos removíveis, a política de discos removíveis é essencial.
Configuração via Intune
No perfil BitLocker do Intune, a secção “Removable drives” permite definir:
| Definição | Valor Recomendado | Descrição |
|---|---|---|
| Configure removable drive encryption | Enabled | Activa gestão de USBs |
| Allow users to apply BitLocker | Sim | Utilizadores podem cifrar USBs |
| Configure removable data drive encryption method | XTS-AES-128 | Performance vs segurança |
| Block write access to non-BitLocker USBs | Sim | Impede escrita em USBs não cifrados |
| Block read access to non-BitLocker USBs | Opcional | Impede leitura de USBs externos |
| Allow BitLocker on non-BitLocker USBs | Não | Impede montagem de USBs sem BitLocker |
Impacto de bloquear escrita em USBs não cifrados
Quando Block write access to removable drives not protected by BitLocker está activo:
- USBs sem BitLocker podem ser lidos (se read-access não bloqueado) mas não escritos
- USBs com BitLocker funcionam normalmente (com password ou smart card)
- Dispositivos formatados em FAT32/exFAT sem BitLocker são bloqueados para escrita
- Excepções podem ser configuradas via Intune Application Control (WDAC)
Auto-Unlock para discos de dados fixos
O Auto-Unlock permite que discos de dados fixos (segundo disco interno, partição de dados) sejam desbloqueados automaticamente quando o disco de SO está desbloqueado, sem necessidade de introduzir password adicional. A chave de auto-unlock é armazenada no disco de SO, protegida pelo protector TPM.
Enable-BitLockerAutoUnlock -MountPoint “D:”# Verificar estado de auto-unlock
Get-BitLockerVolume -MountPoint “D:” | Select-Object MountPoint, AutoUnlockEnabled
# Desactivar auto-unlock
Disable-BitLockerAutoUnlock -MountPoint “D:”
O Auto-Unlock não se aplica a discos removíveis — estes requerem sempre introdução de password ou smart card em cada montagem. O Auto-Unlock é adequado para discos internos secundários em estações de trabalho, mas não deve ser usado em portáteis onde o disco de dados contém informação sensível e o portátil pode ser roubado — nesse caso, preferir protector com password.
Cenário prático: colaborador com pen USB cifrada
- IT envia uma pen USB vazia para o colaborador
- Colaborador liga a pen ao portátil Windows 11 gerido pelo Intune
- Windows detecta que a pen não está cifrada e oferece a opção de activar BitLocker
- Colaborador define uma password para a pen
- A recovery key da pen é armazenada localmente (não há escrow automático para USBs)
- A partir desse momento, a pen só pode ser utilizada em máquinas Windows com BitLocker
Importante: recovery keys de discos removíveis não são automaticamente enviadas para o Entra ID — apenas o disco de SO e discos de dados fixos têm escrow automático. Para USBs corporativos, recomenda-se documentar as passwords num gestor de passwords corporativo (ex: Bitwarden, 1Password Teams).
7. Relatórios de Compliance e Scripts PowerShell para Auditoria
Relatórios de Compliance no Intune
O Intune fornece dashboards nativos para monitorização do estado de cifragem de dispositivos. Estes relatórios são acessíveis em Devices > Monitor > Encryption report e incluem:
| Relatório | Conteúdo | Utilidade |
|---|---|---|
| Encryption report | Estado de cifragem por dispositivo | Visão geral de compliance |
| BitLocker report | Detalhe por volume (OS, dados, removível) | Auditoria granular |
| Device compliance | BitLocker como condição de compliance | Acesso condicional |
| Recovery keys report | Dispositivos com/sem key no Entra ID | Identificar gaps de escrow |
A configuração de compliance policies que verificam BitLocker está documentada em Device compliance in Intune. A monitorização de cifragem está em Monitor encryption with Intune.
Compliance policy com BitLocker
Para garantir que apenas dispositivos cifrados acedem a recursos corporativos:
- Criar uma Compliance Policy no Intune
- Na secção BitLocker, seleccionar “Require BitLocker”
- Atribuir ao mesmo grupo de dispositivos do perfil BitLocker
- Configurar Conditional Access para bloquear acesso a M365 se não-compliant
Isto significa que um dispositivo sem BitLocker activo não pode aceder ao Exchange Online, SharePoint, Teams, etc. — um incentivo automático para compliance.
Scripts PowerShell para Auditoria
Para auditoria fora do portal Intune (por exemplo, execução remota via Intune scripts ou Proactive Remediations):
Script 1 — Verificação de estado de cifragem:
# Verifica estado de cifragem BitLocker em todos os volumes$Volumes = Get-BitLockerVolume | Select-Object MountPoint, VolumeType, ProtectionStatus, EncryptionPercentage, EncryptionMethod
$Report = foreach ($Vol in $Volumes) {
[PSCustomObject]@{
ComputerName = $env:COMPUTERNAME
MountPoint = $Vol.MountPoint
VolumeType = $Vol.VolumeType
Protection = $Vol.ProtectionStatus
EncryptionPct = $Vol.EncryptionPercentage
CipherMethod = $Vol.EncryptionMethod
Timestamp = (Get-Date -Format “yyyy-MM-dd HH:mm:ss”)
}
}
$Report | Format-Table -AutoSize
$Report | Export-Csv -Path “$env:TEMP\BitLocker-Audit.csv” -NoTypeInformation -Encoding UTF8
Documentação de Get-BitLockerVolume em learn.microsoft.com — Get-BitLockerVolume.
Script 2 — Verificação de escrow no Entra ID:
# Verifica se a recovery key foi enviada para o Entra ID$Vol = Get-BitLockerVolume -MountPoint “C:”
$RecoveryProtector = $Vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq “RecoveryPassword” }
if ($RecoveryProtector) {
Write-Output “Recovery protector encontrado:”
Write-Output ” ID: $($RecoveryProtector.KeyProtectorId)”
# Verificar se a key tem flag de backup no Azure AD
# A propriedade KeyProtectorType “RecoveryPassword” indica que existe
# Para confirmar o backup, verificar via dsregcmd
$AadStatus = dsregcmd /status 2>&1 | Select-String “AzureAdJoined|WorkplaceJoined”
Write-Output “Estado Entra ID: $AadStatus”
# Tentar forçar backup se dispositivo estiver Azure AD Joined
$IsAadJoined = (dsregcmd /status 2>&1 | Select-String “AzureAdJoined : YES”)
if ($IsAadJoined) {
BackupToAAD-BitLockerKeyProtector -MountPoint “C:” -KeyProtectorId $RecoveryProtector.KeyProtectorId
Write-Output “Backup forçado para Entra ID executado.”
} else {
Write-Warning “Dispositivo não está Azure AD Joined — escrow automático indisponível.”
}
} else {
Write-Warning “Nenhum recovery protector encontrado no volume C:.”
}
Script 3 — Auditoria em lote (execução via Intune Proactive Remediations):
# Script de detecção para Intune Proactive Remediations
# Retorna 0 se compliant, 1 se não-compliant$Vol = Get-BitLockerVolume -MountPoint “C:” -ErrorAction SilentlyContinue
if (-not $Vol) {
Write-Output “BitLocker não activo no volume C:”
exit 1
}
if ($Vol.ProtectionStatus -ne “On”) {
Write-Output “Protecção BitLocker desactivada no volume C:”
exit 1
}
if ($Vol.EncryptionPercentage -lt 100) {
Write-Output “Cifragem incompleta: $($Vol.EncryptionPercentage)%”
exit 1
}
$HasRecoveryKey = $Vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq “RecoveryPassword” }
if (-not $HasRecoveryKey) {
Write-Output “Sem recovery key protector no volume C:”
exit 1
}
Write-Output “BitLocker compliant no volume C:”
exit 0
# Script de remediação para Intune Proactive Remediations$Vol = Get-BitLockerVolume -MountPoint “C:” -ErrorAction SilentlyContinue
# Se BitLocker não está activo, não activar automaticamente (deixar ao Intune policy)
# Apenas forçar backup de recovery key se já estiver cifrado
if ($Vol -and $Vol.ProtectionStatus -eq “On”) {
$Protector = $Vol.KeyProtector | Where-Object { $_.KeyProtectorType -eq “RecoveryPassword” }
if ($Protector) {
try {
BackupToAAD-BitLockerKeyProtector -MountPoint “C:” -KeyProtectorId $Protector.KeyProtectorId -ErrorAction Stop
Write-Output “Recovery key enviada para Entra ID.”
} catch {
Write-Output “Erro no backup: $_”
}
}
}
8. Troubleshooting: Recovery com manage-bde, Eventos 845/846 e TPM Firmware
Recovery com manage-bde
O manage-bde é a ferramenta de linha de comando para gestão do BitLocker, alternativa ao módulo PowerShell. É especialmente útil em Windows Recovery Environment (WinRE) onde o PowerShell pode não estar disponível com módulos BitLocker. Documentação oficial em learn.microsoft.com — manage-bde.
manage-bde -status:: Verificar protectors do volume C:
manage-bde -protectors -get C:
:: Desbloquear volume C: com recovery key (48 dígitos)
manage-bde -unlock C: -rp 123456-123456-123456-123456-123456-123456-123456-123456
:: Desbloquear volume D: (disco de dados) com password
manage-bde -unlock D: -pw
:: Suspender protecção BitLocker (útil antes de updates de firmware/BIOS)
manage-bde -protectors -disable C:
:: Re-activar protecção após update
manage-bde -protectors -enable C:
:: Forçar rotação de recovery key
manage-bde -protectors -delete C: -id “{GUID-do-protector}”
manage-bde -protectors -add C: -RecoveryPassword
Eventos 845 e 846
Os eventos 845 e 846 no Event Viewer (Microsoft-Windows-BitLocker-API) são os mais comuns em ambientes BitLocker Enterprise:
| Evento | Significado | Causa Típica | Acção |
|---|---|---|---|
| 845 | TPM falhou ao desselar chave de BitLocker | Firmware TPM desactualizado, mudança de motherboard, alteração na UEFI | Usar recovery key, actualizar TPM firmware, re-selar |
| 846 | BitLocker recovery iniciado com sucesso | Utilizou recovery key para arrancar | Verificar causa raiz, rotacionar recovery key |
| 781 | BitLocker recovery initiated | TPM não pôde validar estado do sistema | Analisar dados do evento para causa específica |
| 775 | Recovery key rotacionada | Rotação automática após recovery | Confirmar nova key no Entra ID |
| 832 | BitLocker detectou alteração no ambiente de arranque | Novo boot loader, update de UEFI | Suspender e re-activar BitLocker |
#### Evento 845 — Resolução passo-a-passo
Get-Tpm
# 3. Verificar logs de eventos BitLocker
Get-WinEvent -LogName “Microsoft-Windows-BitLocker-API/Management” -MaxEvents 20 |
Select-Object TimeCreated, Id, Message | Format-List
# 4. Se firmware TPM desactualizado, suspender BitLocker
manage-bde -protectors -disable C:
# 5. Actualizar firmware TPM (conforme fabricante)
# Infineon: https://www.infineon.com/cms/en/product/security-smart-card-solutions/tpm/
# Nuvoton: verificar com fabricante da motherboard
# 6. Após update, reactivar protecção
manage-bde -protectors -enable C:
# 7. Forçar nova verificação TPM
Start-Service Tpm
# 8. Verificar que BitLocker voltou a selar correctamente
Get-BitLockerVolume -MountPoint “C:” | Select-Object ProtectionStatus, EncryptionPercentage
TPM Firmware Update — Precauções Críticas
A actualização de firmware TPM é uma das operações mais sensíveis em ambientes BitLocker. Se o firmware for actualizado sem suspender o BitLocker primeiro, o TPM perde a capacidade de desselar a chave de arranque, resultando num evento 845 e na necessidade de recovery key em todos os arranques subsequentes.
Antes de qualquer actualização de firmware TPM:
- Verificar que a recovery key está disponível no Entra ID
- Suspender BitLocker em todos os volumes:
manage-bde -protectors -disable C: - Actualizar firmware conforme instruções do fabricante
- Reiniciar (pode requerer vários reinícios)
- Reactivar BitLocker:
manage-bde -protectors -enable C: - Verificar re-sealing: confirmar que
ProtectionStatusvolta aOn - Rotacionar recovery key após confirmação
Problemas comuns e resoluções
| Problema | Sintoma | Resolução |
|---|---|---|
| Recovery key não no Entra ID | Dispositivo Azure AD Joined sem key no portal | Executar BackupToAAD-BitLockerKeyProtector manualmente |
| BitLocker não activa automaticamente | Política Intune aplicada mas volume não cifrado | Verificar TPM pronto, Secure Boot activo, WinRE presente |
| Cifragem parada a 0% | EncryptionPercentage = 0 após política recebida |
Verificar espaço em disco, suspender antivírus, verificar Convert-BitLocker |
| PIN esquecido | Utilizador não consegue arrancar | Usar recovery key, redefinir PIN após arranque |
| USB não monta | Dispositivo USB cifrado não reconhecido | Verificar política de discos removíveis, testar noutro PC |
| Evento 845 recorrente | Recovery necessária em cada arranque | Actualizar TPM firmware, verificar bateria CMOS, suspender+reactivar |
9. BitLocker vs LUKS em Linux: Comparação Técnica
O LUKS (Linux Unified Key Setup) é a alternativa open-source ao BitLocker em sistemas Linux. Para PME que operam em ambientes mistos (Windows + Linux), é importante compreender as diferenças para escolher a solução adequada por plataforma.
| Característica | BitLocker (Windows) | LUKS (Linux) |
|---|---|---|
| Sistema operativo | Windows 11/10/Server | Linux (kernel 2.6+) |
| Algoritmo padrão | XTS-AES-256 | XTS-AES-256 (configurável) |
| Gestão centralizada | Intune + Entra ID | Sem equivalente nativo |
| Escrow de recovery keys | Automático via Entra ID | Manual (sem escrow nativo) |
| Integração com hardware | TPM 2.0 nativo | TPM via systemd-cryptenroll ou tpm2-totp |
| Secure Boot | Nativo + medido no TPM | Disponível via shim + MOK |
| Pre-boot authentication | PIN/password/USB/smart card | Password/keyfile/TPM/FIDO2 |
| Recovery | Recovery key 48 dígitos | Header backup + passphrase |
| Monitoring | Intune compliance reports | Sem monitorização centralizada nativa |
| MDM management | Intune (CSP) | Sem MDM nativo para cifragem |
| Open source | Não (proprietário Microsoft) | Sim (cryptsetup, GPL) |
| Multi-plataforma | Windows apenas | Linux apenas |
| Documentação | learn.microsoft.com | gitlab.com/cryptsetup |
Análise comparativa para PME
| Critério | BitLocker | LUKS |
|---|---|---|
| Custo de licenciamento | Incluído no Windows | Gratuito (open source) |
| Custo de gestão | Incluído no Intune | Requer ferramentas adicionais (Ansible, Salt) |
| Tempo de implementação | Horas (Intune policy) | Dias (scripting por servidor) |
| Compliance reporting | Automático (Intune) | Manual ou custom |
| Recovery centralizada | Entra ID portal | Sem solução nativa |
| Adequado para endpoints | Sim (Windows) | Sim (Linux) |
| Adequado para servidores | Sim (Windows Server) | Sim (Linux servers) |
| Adequado para PME 25 cols | Sim — gestão via Intune | Apenas para servidores Linux isolados |
Para uma PME de 25 colaboradores, a recomendação é:
- Endpoints Windows → BitLocker com Intune (gestão centralizada, escrow automático)
- Servidores Linux → LUKS com header backup documentado e gestor de passwords
- Servidores Windows → BitLocker com recovery key em Active Directory on-premise (se híbrido) ou Entra ID
Não existe uma solução única que cubra ambos os ecossistemas com gestão centralizada equivalente ao Intune. Para PME que operam apenas em Windows, BitLocker + Intune é a solução mais eficiente e com menor TCO.
10. Cenários PME: 25 Colaboradores
Cenário 1 — Empresa de serviços com 25 portáteis Windows 11
| Componente | Configuração | Custo |
|---|---|---|
| Licenças | Microsoft 365 Business Premium (inclui Intune) | €20,60/utilizador/mês |
| Dispositivos | 25x portáteis com TPM 2.0 (Dell Latitude, Lenovo ThinkPad) | Existente |
| Intune | Incluído no M365 BP | €0 adicional |
| Entra ID | Incluído no M365 BP (P1) | €0 adicional |
| Perfil BitLocker | Silent encryption, XTS-AES-256, escrow Entra ID | Configuração: 2 horas |
| Compliance policy | Require BitLocker + Conditional Access | Configuração: 1 hora |
| Proactive Remediations | Script de auditoria + remediação automática | Configuração: 1 hora |
| Total mensal adicional | €0 (incluído na licença existente) | |
| Tempo de implementação | 4 horas (configuração) + rollout gradual |
Cenário 2 — Empresa com dados sensíveis (financeiros, saúde)
| Componente | Configuração | Diferença vs Cenário 1 |
|---|---|---|
| Perfil BitLocker | Interactive (TPM + PIN alfanumérico) | Requer formação de utilizadores |
| PIN policy | Mínimo 8 caracteres alfanuméricos | Maior segurança, mais tickets helpdesk |
| USB policy | Bloquear leitura+escrita em USBs não cifrados | Impede uso de USBs pessoais |
| Compliance | Conditional Access + bloco total se não-compliant | Acesso negado a M365 sem cifragem |
| Proactive Remediations | Auditoria diária + alerta se non-compliant | Detecção imediata de falhas |
| Formação | 1 sessão de 30 min para 25 colaboradores | Ensinar PIN, recovery, USB cifrada |
| Tempo adicional | +3 horas (formação + tuning) |
Cenário 3 — Empresa com dispositivos híbridos (office + campo)
| Componente | Configuração | Notas |
|---|---|---|
| Portáteis de escritório (15) | Silent encryption, escrow Entra ID | Deployment automático via Autopilot |
| Tablets/ruggedized de campo (10) | Interactive (TPM + PIN), USB cifrada obrigatória | Dispositivos expostos a roubo |
| Servidor Windows on-premise | BitLocker com recovery key no AD DS | Gestão via GPO, não Intune |
| Estações sem TPM (legacy, 2) | Protector USB (pen de arranque) | Migrar para hardware novo em 6 meses |
| Monitorização | Intune encryption report + export mensal | Compliance audit trail |
Estimativa de tickets de helpdesk
| Tipo de ticket | Cenário 1 (Silent) | Cenário 2 (Interactive) | Cenário 3 (Híbrido) |
|---|---|---|---|
| PIN esquecido | 0/mês | 2-3/mês (inicial), 1/mês (estabilizado) | 1-2/mês |
| Recovery key necessária | 1/trimestre | 2/trimestre | 1/mês (campo) |
| USB não monta | 0/mês | 1-2/mês (transição) | 1/mês |
| Cifragem não activa | 1/mês (setup) | 1/mês (setup) | 2/mês (hardware variado) |
| Total estimado/mês | 1-2 | 4-6 | 4-5 |
Checklist Pré-Produção
- [ ] Confirmar que todos os dispositivos têm TPM 2.0 pronto (
Get-Tpmem cada dispositivo ou via Intune hardware report) - [ ] Confirmar Secure Boot activo em todos os dispositivos UEFI
- [ ] Verificar WinRE presente com espaço suficiente (
reagentc /info) - [ ] Criar perfil BitLocker no Intune (Endpoint Security > Disk Encryption) com XTS-AES-256 para OS
- [ ] Configurar escrow de recovery key para Entra ID (Azure AD) no perfil BitLocker
- [ ] Activar rotação automática de recovery keys após recovery event
- [ ] Definir política de PIN (se Interactive): mínimo 6 dígitos ou 8 alfanuméricos
- [ ] Configurar política de discos removíveis (USB): bloquear escrita em USBs não cifrados
- [ ] Configurar auto-unlock para discos de dados fixos (se aplicável)
- [ ] Criar Compliance Policy com “Require BitLocker” e atribuir aos grupos de dispositivos
- [ ] Configurar Conditional Access para bloquear acesso M365 se dispositivo não-compliant
- [ ] Criar Proactive Remediations script para auditoria diária de estado BitLocker
- [ ] Testar perfil BitLocker em dispositivo piloto (1-3 dispositivos) antes de rollout geral
- [ ] Confirmar que recovery key do dispositivo piloto aparece no Entra ID portal
- [ ] Documentar procedimento de recovery (manage-bde) para equipa de helpdesk
- [ ] Documentar procedimento de suspensão de BitLocker antes de updates de firmware TPM/UEFI
- [ ] Configurar alertas de Intune para dispositivos non-compliant (Notifications)
- [ ] Formar utilizadores sobre PIN de arranque (se Interactive) e uso de USBs cifradas
- [ ] Agendar revisão mensal do Encryption Report no Intune
- [ ] Verificar que dispositivos Azure AD Joined têm
dsregcmd /statuscomAzureAdJoined : YES
Artigos Relacionados
- Windows 11 24H2 e 25H2: O Que Mudou em Segurança e Cifragem
- Microsoft Intune: Guia de Implementação para PME em 2026
- TPM 2.0 e Secure Boot: Configuração e Troubleshooting no Windows 11
- Entra ID (Azure AD): Gestão de Dispositivos e Conditional Access
- Ransomware 2026: Estratégias de Protecção e Recuperação para PME
- Windows Autopilot: Deployment Zero-Touch com Intune
- Conditional Access no Microsoft 365: Configuração Prática
