📁 Microsoft 365 / Segurança · ⏱ Leitura: ~18 min · 👤 Nível: Administrador · 🗓 Abril 2026
A Autenticação Multifator (MFA) é a medida de segurança com maior impacto na proteção de contas Microsoft 365 — a Microsoft estima que bloqueia mais de 99,9% dos ataques de comprometimento de conta. Este guia cobre a implementação completa: métodos disponíveis, Security Defaults, Acesso Condicional, configuração do Microsoft Authenticator, e gestão de utilizadores e exceções.
✅ NIS2 / Decreto-Lei n.º 125/2025: A implementação de MFA é considerada uma medida técnica obrigatória para entidades abrangidas pela diretiva NIS2 em Portugal. A ausência de MFA em acessos administrativos pode constituir incumprimento regulatório.
📋 Índice
- Métodos de MFA Disponíveis no M365
- Security Defaults — Ativação Rápida
- MFA por Utilizador (Per-User MFA)
- Acesso Condicional — Implementação Avançada
- Configurar o Microsoft Authenticator
- Forçar Registo de MFA nos Utilizadores
- Gestão de Exceções e Exclusões
- Monitorizar e Auditar MFA
- Resolução de Problemas Comuns
1. Métodos de MFA Disponíveis no M365
O Microsoft 365 suporta vários métodos de segundo fator, com segurança e conveniência distintas. Recomenda-se a adoção do método mais seguro compatível com o perfil dos utilizadores:
| Método | Como funciona | Segurança | Recomendado |
|---|---|---|---|
| Microsoft Authenticator (notificação) | Notificação push no telemóvel — aprovar ou recusar | Alta | ✅ |
| Microsoft Authenticator (TOTP/código) | Código de 6 dígitos rotativo a cada 30 segundos | Alta | ✅ |
| Chave de segurança FIDO2 (YubiKey, etc.) | Chave física USB/NFC — resistente a phishing | Máxima | ✅ |
| Windows Hello for Business | PIN ou biometria (impressão digital, reconhecimento facial) | Máxima | ✅ |
| SMS / Chamada de voz | Código enviado por SMS ou chamada telefónica | Média | ⚠️ último recurso |
⚠️ SMS e chamada de voz: Vulneráveis a ataques de SIM swapping e interceção SS7. A Microsoft recomenda evitar estes métodos e migrar para o Authenticator assim que possível. Usar apenas como método de fallback ou em utilizadores sem smartphone.
2. Security Defaults — Ativação Rápida
Os Security Defaults são um conjunto de políticas de segurança pré-configuradas pela Microsoft, ativadas com um único clique. São a opção mais simples para organizações sem licença P1/P2 do Azure AD.
| O que os Security Defaults ativam | Impacto |
|---|---|
| MFA obrigatório para todos os utilizadores | 14 dias para registar — depois bloqueia sem MFA |
| MFA sempre obrigatório para Administradores | Sem exceções para contas com funções privilegiadas |
| Bloqueio de autenticação legacy (Basic Auth) | Clientes que não suportam Modern Auth deixam de funcionar |
| Proteção do Azure AD Privileged Identity Management | Ações privilegiadas requerem MFA adicional |
Como ativar os Security Defaults
|
1
|
Aceder ao portal Microsoft Entra com conta de Administrador Global |
|
2
|
Navegar para Identidade → Descrição Geral → Security Defaults (ou pesquisar “Security defaults” na barra de pesquisa) |
|
3
|
Em “Security defaults”, colocar o toggle em Enabled e clicar em Save |
|
4
|
Os utilizadores recebem um período de 14 dias para registar o método MFA em aka.ms/MFASetup. Após este prazo, o acesso fica condicionado ao MFA. |
🛑 Incompatibilidade: Os Security Defaults não podem coexistir com políticas de Acesso Condicional. Se o tenant já tem políticas de Acesso Condicional ativas, os Security Defaults estarão desativados e não devem ser ativados — usar o Acesso Condicional para gerir o MFA (Secção 4).
3. MFA por Utilizador (Per-User MFA)
O MFA por utilizador permite ativar o MFA individualmente, sem depender de Security Defaults ou Acesso Condicional. É o método mais simples para organizações pequenas ou para ativações graduais.
⚠️ Nota: A Microsoft considera o Per-User MFA uma abordagem legada e recomenda o Acesso Condicional para novos deployments. Contudo, é válido para tenants sem licença Azure AD P1/P2.
3.1 — Ativar via Portal
- Aceder ao Centro de Administração Microsoft 365
- Navegar para Utilizadores → Utilizadores Ativos
- Clicar em “Autenticação multifator” na barra de ações
- Selecionar os utilizadores pretendidos e clicar em “Ativar”
- Confirmar a ação — os utilizadores serão solicitados a registar o MFA no próximo início de sessão
3.2 — Ativar via PowerShell (em massa)
PowerShell — MSOnline
# Instalar módulo se necessário
Install-Module MSOnline -Force
Connect-MsolService
# Ativar MFA para um utilizador específico
$mfa = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$mfa.RelyingParty = “*”
$mfa.State = “Enabled”
Set-MsolUser -UserPrincipalName [email protected] -StrongAuthenticationRequirements $mfa
# Ativar MFA para TODOS os utilizadores do tenant
Get-MsolUser -All | ForEach-Object {
Set-MsolUser -UserPrincipalName $_.UserPrincipalName -StrongAuthenticationRequirements $mfa
}
# Verificar estado de MFA de todos os utilizadores
Get-MsolUser -All | Select DisplayName, UserPrincipalName, @{N=”MFA”;E={$_.StrongAuthenticationRequirements.State}} | Sort MFA
4. Acesso Condicional — Implementação Avançada
O Acesso Condicional (Conditional Access) permite definir políticas granulares de MFA — por utilizador, grupo, aplicação, localização ou dispositivo. Requer licença Azure AD Premium P1 (incluída em M365 Business Premium, E3, E5).
4.1 — Política Base: MFA para Todos os Utilizadores
|
1
|
Aceder ao Microsoft Entra → Proteção → Acesso Condicional → + Nova Política |
|
2
|
Assignments (Atribuições):
|
|
3
|
Access controls → Grant:
|
|
4
|
Ativar a política: Colocar em “Report-only” primeiro para avaliar o impacto sem bloquear utilizadores. Após validação, mudar para “On”. |
4.2 — Políticas Avançadas Recomendadas
| Política | Condição | Controlo |
|---|---|---|
| MFA para Admins | Utilizadores com funções de administrador | Exigir MFA em todos os acessos |
| Bloqueio fora do país | Localização fora de Portugal (ou UE) | Bloquear ou exigir MFA + dispositivo gerido |
| Dispositivos não geridos | Dispositivo não conforme ou não registado no Intune | Exigir MFA + sessão limitada (sem download) |
| Proteção de aplicações sensíveis | Azure Portal, Exchange Admin, SharePoint Admin | Exigir MFA + dispositivo conforme |
| Sign-in de risco | Risco de início de sessão médio/alto (Identity Protection) | Exigir MFA ou bloquear |
4.3 — Gerir Políticas via PowerShell (Microsoft Graph)
PowerShell — Microsoft Graph
# Listar todas as políticas de Acesso Condicional
Connect-MgGraph -Scopes “Policy.Read.All”
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State, CreatedDateTime | Sort DisplayName
# Ver detalhes de uma política específica
Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.DisplayName -like “*MFA*”} | Format-List
5. Configurar o Microsoft Authenticator
O Microsoft Authenticator é o método recomendado pela Microsoft — disponível para iOS e Android, gratuito, e suporta tanto notificações push como códigos TOTP.
5.1 — Registo pelo Utilizador (self-service)
|
1
|
Instalar a app Microsoft Authenticator no telemóvel (iOS App Store ou Google Play) |
|
2
|
Aceder a aka.ms/MFASetup no browser do computador (com as credenciais da conta M365) |
|
3
|
Clicar em “+ Adicionar método” → selecionar “Aplicação de autenticação” → seguir o assistente que apresenta um QR Code |
|
4
|
Na app Authenticator, tocar em “+” → “Conta profissional ou escolar” → “Digitalizar código QR” → apontar a câmara para o QR Code no browser |
|
5
|
O browser envia uma notificação de teste para o telemóvel — aprovar na app. O registo está concluído. |
5.2 — Number Matching (Proteção Anti-Fatigue)
O Number Matching obriga o utilizador a introduzir na app o número apresentado no ecrã de login — impedindo ataques de MFA fatigue (aprovar notificações repetidas sem saber porquê). Está ativo por defeito em novos tenants desde 2023.
PowerShell — Microsoft Graph
# Verificar configuração do Number Matching no Authenticator
Connect-MgGraph -Scopes “Policy.Read.All”
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations | Where-Object {$_.Id -eq “MicrosoftAuthenticator”} | Format-List
6. Forçar Registo de MFA nos Utilizadores
Para garantir que todos os utilizadores completam o registo de MFA antes de serem bloqueados, é possível forçar o processo de registo via Acesso Condicional ou verificar o estado atual:
6.1 — Verificar Estado de Registo de MFA
PowerShell — Microsoft Graph
# Utilizadores SEM qualquer método MFA registado
Connect-MgGraph -Scopes “UserAuthenticationMethod.Read.All”, “User.Read.All”
Get-MgReportAuthenticationMethodUserRegistrationDetail | Where-Object {
$_.IsMfaRegistered -eq $false
} | Select UserPrincipalName, IsMfaRegistered, IsMfaCapable, DefaultMfaMethod
# Exportar relatório completo para CSV
Get-MgReportAuthenticationMethodUserRegistrationDetail | Select UserPrincipalName, IsMfaRegistered, IsMfaCapable, DefaultMfaMethod | Export-Csv “MFA_Report.csv” -NoTypeInformation -Encoding UTF8
6.2 — Política de Registo de MFA (Acesso Condicional)
Criar uma política específica que força o registo de métodos de autenticação sem bloquear o acesso:
| Campo | Valor |
|---|---|
| Nome | CA — Require MFA Registration |
| Users | All users (excluir break-glass) |
| Target resources | All cloud apps |
| Grant | Require authentication strength → Multifactor authentication |
| Session | Sign-in frequency → Every time (para utilizadores sem MFA registado) |
7. Gestão de Exceções e Exclusões
7.1 — Conta de Break-Glass (Emergência)
É fundamental manter pelo menos uma conta de acesso de emergência excluída do MFA e das políticas de Acesso Condicional — para situações onde o MFA falha globalmente ou o administrador fica sem acesso.
🔐 Boas práticas para a conta de break-glass:
- Usar um domínio
*.onmicrosoft.com(não federado, não afetado por problemas de ADFS/Entra) - Password longa e aleatória (30+ caracteres) — guardar em cofre físico ou gestor de passwords partilhado
- Excluir explicitamente de todas as políticas de Acesso Condicional
- Monitorizar os inícios de sessão desta conta — qualquer acesso deve gerar alerta
- Testar periodicamente (trimestralmente) para confirmar que o acesso funciona
- Não usar no dia-a-dia — apenas em situações de emergência real
7.2 — Excluir Utilizadores ou Grupos de Políticas CA
Microsoft Entra — Acesso Condicional
# Na política de Acesso Condicional → Assignments → Users
# Separador “Exclude” → adicionar:
– Conta(s) de break-glass (por UPN direto)
– Grupo “CA-Exclude-MFA” (para gerir exceções temporárias)
– Contas de serviço sem interatividade (usar Managed Identity em alternativa)
7.3 — Localizações de Confiança (Trusted Locations)
É possível dispensar o MFA quando o utilizador acede a partir de uma rede de confiança (ex: escritório com IP fixo):
|
A
|
Entra → Proteção → Acesso Condicional → Localizações Nomeadas → + Localização de intervalos IP |
|
B
|
Adicionar o IP público do escritório em formato CIDR (ex: |
|
C
|
Na política de Acesso Condicional → Conditions → Locations → Exclude → “All trusted locations” — o MFA não será pedido quando o acesso provém dessas redes. |
8. Monitorizar e Auditar MFA
8.1 — Relatórios de Início de Sessão
Portal: Microsoft Entra → Monitorização → Inícios de Sessão — filtrar por “MFA result” para ver sucessos, falhas e isenções.
PowerShell — Microsoft Graph
# Inícios de sessão sem MFA nas últimas 24h
Connect-MgGraph -Scopes “AuditLog.Read.All”
$start = (Get-Date).AddDays(-1).ToString(“yyyy-MM-ddTHH:mm:ssZ”)
Get-MgAuditLogSignIn -Filter “createdDateTime ge $start and authenticationRequirement eq ‘singleFactorAuthentication'” | Select UserPrincipalName, CreatedDateTime, AppDisplayName, IpAddress, Status
# Falhas de MFA por utilizador
Get-MgAuditLogSignIn -Filter “createdDateTime ge $start and status/errorCode ne 0 and authenticationRequirement eq ‘multiFactorAuthentication'” | Select UserPrincipalName, CreatedDateTime, Status, IpAddress | Sort CreatedDateTime -Descending
8.2 — Alertas Recomendados
| Evento a monitorizar | Ferramenta | Ação recomendada |
|---|---|---|
| Múltiplas falhas de MFA do mesmo utilizador | Entra Sign-in logs / Sentinel | Investigar possível ataque de MFA fatigue |
| Acesso com a conta de break-glass | Entra / Log Analytics | Alerta imediato — verificar se é legítimo |
| MFA desativado para um utilizador | Audit logs do Entra | Verificar quem fez a alteração e porquê |
| Início de sessão de localização atípica | Identity Protection (P2) | Rever atividade da conta — possível comprometimento |
| Política de Acesso Condicional alterada | Audit logs do Entra | Confirmar que a alteração foi autorizada |
9. Resolução de Problemas Comuns
Problema 1
Utilizador perdeu o telemóvel / não tem acesso ao Authenticator
O utilizador não consegue autenticar porque o único método registado era a app Authenticator no telemóvel perdido.
✅ Solução: O administrador pode gerar um Temporary Access Pass (TAP) — código de uso único com prazo definido — que permite ao utilizador autenticar-se sem MFA temporariamente e registar um novo método.
Entra → Utilizadores → [utilizador] → Métodos de autenticação → + Adicionar método de autenticação → Temporary Access Pass
Problema 2
Aplicações legacy (IMAP, POP3, SMTP básico) deixam de funcionar após ativar MFA
Clientes de email antigos ou aplicações que usam autenticação básica (username/password) não suportam o fluxo de MFA OAuth 2.0 e são bloqueados.
✅ Solução: Migrar para clientes que suportam Modern Auth (Outlook 2016+, aplicações que usam OAuth 2.0). Para aplicações que não podem ser atualizadas, criar App Passwords (passwords de aplicação) em aka.ms/MFASetup → Segurança adicional. Nota: App Passwords não estão disponíveis com Security Defaults ou Acesso Condicional — apenas com Per-User MFA.
Problema 3
O utilizador recebe repetidas notificações MFA que não solicitou (MFA Fatigue Attack)
Um atacante que tenha obtido a password está a tentar o acesso repetidamente, gerando notificações push no telemóvel do utilizador na esperança de que este aprove por engano.
✅ Solução imediata: O utilizador não deve aprovar as notificações — reportar ao administrador. O administrador deve revogar todas as sessões ativas e forçar alteração de password.
Prevenção: Ativar Number Matching no Authenticator (ver Secção 5.2) e Additional Context (mostra a localização e app que pede o MFA). Considerar migrar para FIDO2 (resistente a phishing).
Problema 4
Administrador ficou sem acesso ao tenant (sem MFA configurado e Security Defaults ativado)
O administrador ativou os Security Defaults sem ter configurado MFA previamente e agora não consegue autenticar.
✅ Solução: Se existir conta de break-glass excluída das políticas, usar essa conta para aceder. Caso contrário, contactar o suporte Microsoft — será necessário verificar a identidade do proprietário do tenant para recuperar o acesso.
