Microsoft Entra MFA — Multi-Factor Authentication em 2026

Segurança · Entra ID · MFA · NIS2 · Conditional Access

Por Duarte Spínola · 27 junho 2026 · kbase.pt

O Multi-Factor Authentication (MFA) deixou de ser uma opção de reforço para se tornar o alicerce obrigatório de qualquer estratégia de identidade no Microsoft Entra ID. Com a entrada em vigor plena da diretiva NIS2 nos Estados-Membros da União Europeia e o endurecimento dos requisitos de Security Defaults em inquilinos Microsoft 365, em 2026 não há organização — por pequena que seja — que possa funcionar sem MFA ativo. Este guia percorre, do conceito ao diagnóstico, tudo o que precisas para implementar MFA de forma robusta, económica e auditável.

Tema

Microsoft Entra MFA

Versão / data

Junho 2026

Audiência

Administradores IT, gestores de segurança, decisores PME

Pré-requisitos

Inquilino Entra ID, Microsoft Graph PowerShell SDK

Legislação

Diretiva NIS2 (UE) 2022/2555, transposta em PT

1. O que é MFA e porque é obrigatório em 2026 (NIS2)

Multi-Factor Authentication é a verificação de identidade através de dois ou mais fatores independentes, pertencentes a categorias distintas: algo que o utilizador sabe (password), algo que tem (telemóvel, chave de segurança) ou algo que é (biometria). A combinatória impede que o comprometimento de um único fator — tipicamente a password — dê acesso ao inquilino.

A diretiva NIS2 (UE) 2022/2555, transposta em Portugal, impõe medidas mínimas de gestão de riscos cibernéticos a entidades essenciais e importantes. O artigo 21 exige explicitamente autenticação multifator ou equivalente para acesso a sistemas. A Microsoft, por seu lado, habilita Security Defaults em todos os novos inquilinos e descontinua a configuração legacy de MFA por utilizador no Entra ID.

Em concreto, em 2026, três vetores convergem:

• O regulatório (NIS2) torna MFA juridicamente exigível, com sanções para incumprimento.
• O fabricante (Microsoft) remove gradualmente os mecanismos antigos de MFA per-user e impõe Security Defaults por defeito.
• A ameaça (phishing, credential stuffing, ataques a token OAuth) torna a password isolada estatisticamente insuficiente — a Microsoft reporta que MFA bloqueia mais de 99% dos ataques automatizados a contas.

O ecossistema de identidade em 2026

Para contextualizar, o Entra ID em 2026 é o centro de um ecossistema que inclui não apenas MFA, mas também Identity Governance, Conditional Access, Identity Protection, Privileged Identity Management e Continuous Access Evaluation. O MFA é o pilar mais visível, mas a sua eficácia depende do equilíbrio com as outras peças. Uma implementação de MFA sem gestão de métodos, sem monitorização de sign-in logs, e sem plano de resposta a comprometimento é uma implementação frágil.

O artigo Zero Trust para PME em 2026 descreve como o MFA se insere no modelo Zero Trust, onde cada pedido de acesso é verificado explicitamente, independentemente da rede de origem. O MFA é o mecanismo que torna essa verificação possível sem depender apenas de passwords.

Tipos de fator e a matemática do risco

A eficácia do MFA deriva da independência estatística entre fatores. Se um atacante compromete a password (fator “saber”), continua a precisar de um segundo fator de categoria diferente para entrar. Os ataques mais comuns em 2026 — phishing via AI generativa, credential stuffing via bots, spray de passwords — são todos mitigados por MFA porque operam apenas sobre o fator password.

A Microsoft publica regularmente dados no seu Security Defaults e no Digital Defense Report: contas com MFA têm probabilidade de comprometimento reduzida em mais de 99% face a contas sem MFA. Este número, por si só, justifica o investimento regulatório e técnico.

2. Métodos de autenticação disponíveis

O Entra ID suporta vários métodos que podem ser usados como segundo fator ou como autenticação primária passwordless. A escolha determina o equilíbrio entre usabilidade, custo e resiliência a phishing.

Método	Tipo	Resistência a phishing	Notas
Microsoft Authenticator (push)	App móvel	Média (com number matching: alta)	Recomendado para a maioria dos cenários
Microsoft Authenticator (TOTP)	App móvel (código)	Média	Funciona sem internet no dispositivo
SMS / chamada	Telefone	Baixa	Susceptível a SIM-swap; descontinuado como método por defeito em novos inquilinos
FIDO2 / WebAuthn	Hardware ou passkey	Alta (anti-phishing nativo)	Estado da arte; recomendado para administradores
Token hardware OATH	Dispositivo físico (TOTP)	Média	Útil onde telemóvel não é permitido
Software OATH (Google Auth, etc.)	App genérica	Média	Suportado mas Authenticator é preferido
Password temporária (Temporary Access Pass)	Passe administrativo	N/A	Para recuperação e onboarding inicial

Comparação detalhada de métodos

A escolha do método de autenticação tem impacto direto na segurança, na experiência do utilizador e no custo. A tabela seguinte resume os trade-offs.

Método	Custo	Experiência utilizador	Dependência de telemóvel	Recomendado para
Authenticator push + number matching	Gratuito	Muito boa	Sim	Utilizadores gerais
Authenticator TOTP (código)	Gratuito	Boa	Sim (mas funciona offline)	Utilizadores em zonas sem internet
FIDO2 hardware key	25-60€ por chave	Muito boa (tap)	Não	Admins, ambientes regulados
FIDO2 passkey (plataforma)	Gratuito	Muito boa (biometria)	Não (vinculada ao dispositivo)	Windows Hello, Touch ID, Face ID
Token hardware OATH (TOTP)	10-30€ por token	Razoável (código manual)	Não	Ambientes sem telemóvel permitido
SMS	Gratuito (custo de SMS)	Razoável	Sim	Avoid; apenas fallback temporário
Chamada de voz	Gratuito (custo de chamada)	Má	Sim	Avoid; descontinuado
Temporary Access Pass	Gratuito	N/A (admin gerado)	Não	Onboarding, recuperação

Configurar métodos permitidos via Authentication Methods Policy

A gestão centralizada de métodos faz-se via Authentication Methods Policy, acessível em Entra > Security > Authentication methods > Policies. Aqui defines, por método, se está enabled, para quem, e com que restrições. Em 2026, a Microsoft recomenda desativar SMS e chamada de voz sempre que possível, e privilegiar Authenticator e FIDO2.

# Listar métodos e estado atual
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod","Policy.Read.All"
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -All | `
    Select-Object Id, State, @{N="OdataType";E={$_.AdditionalProperties."@odata.type"}} | `
    Format-Table -AutoSize

Phishing e a importância do origin binding

A diferença fundamental entre FIDO2 e os outros métodos é o origin binding: a chave FIDO2 só responde a challenges assinados para o domínio correto (login.microsoft.com). Mesmo que um utilizador seja vítima de phishing e visite um site clonado, a chave FIDO2 não vai autenticar-se nesse domínio. SMS, TOTP e push (sem number matching) não têm esta proteção — o código gerado pode ser reenviado para o site do atacante.

Por esta razão, o passwordless com FIDO2 é a recomendação para contas de alto valor. O artigo BitLocker com Entra ID Join aborda como o FIDO2 se integra também na proteção de dispositivos Windows.

3. Licenciamento: Free vs P1 vs P2

O Entra ID tem três tiers principais que determinam as capacidades de MFA disponíveis. A compreensão do limite de cada tier é essencial para dimensionar custo vs. requisitos regulatórios.

Capacidade	Free / Security Defaults	Entra ID P1	Entra ID P2
MFA para todos os utilizadores	Sim (Security Defaults)	Sim (Conditional Access)	Sim (Conditional Access)
Conditional Access policies	Não	Sim	Sim
Exclusões granulares por utilizador/grupo	Não	Sim	Sim
Report-only mode	Não	Sim	Sim
Identity Protection (risco de utilizador/sign-in)	Não	Limitado	Sim
Privileged Identity Management (PIM)	Não	Não	Sim
Conditional Access para risco em tempo real	Não	Não	Sim
Retenção de sign-in logs (30 dias)	7 dias interativos	30 dias	30 dias

O tier Free, via Security Defaults, habilita MFA para todos os utilizadores mas sem qualquer granularidade. P1 desbloqueia Conditional Access, permitindo excluir contas break-glass, aplicar MFA apenas em redes não fidedignas, exigir MFA em apps específicas. P2 acrescenta Identity Protection e PIM — essenciais para organizações sujeitas a auditoria NIS2 rigorosa.

Para PME com Microsoft 365 Business Basic/Standard/Premium, as licenças Business incluem Entra ID P1 (Business Standard) ou P2 (Business Premium). Verifica licensing para detalhes atualizados.

Que licença comprar em cada cenário

Cenário	Recomendação	Custo aprox.
PME < 10 users, sem contas de serviço, sem compliance exigente	Free + Security Defaults	0€
PME com contas de serviço ou scripts	Entra ID P1	~6€/user/mês
PME com Microsoft 365 (já tem Exchange/SharePoint)	Microsoft 365 Business Standard (inclui P1)	~10€/user/mês (inclui Office apps)
Organização com admins privilegiados e necessidade de PIM	Entra ID P2	~9€/user/mês (apenas para admins)
Microsoft 365 Business Premium	Inclui P2 + Defender for Business	~16€/user/mês
Enterprise com requisitos avançados	Microsoft 365 E5 (inclui P2 + tudo)	~50€/user/mês

Verificar licenças via PowerShell

Connect-MgGraph -Scopes "Organization.Read.All","User.Read.All"

# Listar SKUs disponíveis no inquilino
Get-MgSubscribedSku | Select-Object SkuPartNumber, `
    @{N="PrepaidUnits";E={$_.PrepaidUnits.Enabled}}, `
    @{N="Consumed";E={$_.ConsumedUnits}}, `
    @{N="Enabled";E={$_.PrepaidUnits.Enabled}}

# Verificar que utilizadores têm P1/P2
Get-MgUser -Filter "assignedLicenses/any(s:s/skuId eq 4b9405b0-7788-4564-add2-1c7791c6b8e3)" -All | `
    Select-Object DisplayName, UserPrincipalName
# (substitui o skuId pelo GUID real do Entra ID P1 no teu inquilino)

4. Security Defaults vs Conditional Access

Security Defaults e Conditional Access são duas abordagens mutuamente exclusivas para enforcement de MFA. Não podes ter ambos ativos no mesmo inquilino.

Security Defaults

Security Defaults é uma configuração gratuita, global, que habilita:

• MFA obrigatório para todos os utilizadores, via Microsoft Authenticator app.
• Bloqueio de protocolos de autenticação legacy (IMAP, POP, SMTP sem AUTH, EWS).
• MFA obrigatório para administradores (todas as roles privilegiadas).
• Proteção de atividades de risco (verificação adicional quando detetado risco).

A principal limitação: não há exceções. Todas as contas, incluindo contas de serviço e integrações legacy, ficam sujeitas a MFA, o que pode partir scripts e automações. É adequado para PME simples sem contas de serviço complexas.

Comparação direta

Característica	Security Defaults	Conditional Access (P1/P2)
Custo	Gratuito	Incluído em P1 (~6€/user/mês) ou P2 (~9€/user/mês)
MFA para todos	Sim, obrigatório	Configurável por policy
Exceções por utilizador/grupo	Não	Sim, via ExcludeGroups/ExcludeUsers
MFA só fora de rede trusted	Não (sempre)	Sim, via named locations
MFA por aplicação	Não	Sim, IncludeApplications/ExcludeApplications
Modo report-only (testar antes)	Não	Sim
Bloquear protocolos legacy	Sim, automático	Sim, via policy dedicada
Exigir dispositivo conforme/compliant	Não	Sim
Integração com Identity Protection (risco)	Limitada	Sim (especialmente P2)
Recomendado para	PME sem necessidades granulares	Qualquer organização com requisitos de compliance, contas de serviço, ou administração delegada

Fluxo de migração Security Defaults → Conditional Access

1. Adquirir licenças P1 (ou Microsoft 365 Business Standard, que inclui P1).
2. Atribuir licenças a pelo menos um administrador e ao grupo de piloto.
3. Criar grupo de exclusão break-glass e adicionar as duas contas de emergência.
4. Criar policy CA-MFA-AllUsers em modo report-only.
5. Criar policy CA-Block-Legacy-Auth em modo report-only.
6. Monitorizar sign-in logs durante 5-10 dias, verificar que não há utilizadores ou apps críticas afetadas.
7. Agendar janela de manutenção (fora de horas de pico, idealmente fim de semana).
8. Desativar Security Defaults.
9. Mudar policies de report-only para enabled, numa ordem: primeiro Block-Legacy-Auth, depois MFA-AllUsers.
10. Verificar login de administrador e de utilizador de piloto imediatamente após.
11. Comunicar à organização que nos próximos logins será pedido registo de MFA.

# Desativar Security Defaults (exige Microsoft.Graph)
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"
$sd = Get-MgPolicyIdentitySecurityDefaultEnforcedPolicy
Update-MgPolicyIdentitySecurityDefaultEnforcedPolicy -IsEnabled:$false

5. Configurar Conditional Access policies para MFA

Uma policy de Conditional Access bem desenhada cobre todos os utilizadores, exclui contas break-glass, exige MFA quando o risco é significativo, e é testada em modo report-only antes de entrar em enforce.

Policy base: exigir MFA para todos os utilizadores

# Pré-requisito: Microsoft.Graph PowerShell SDK
# Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Group.Read.All","User.Read.All"

# 1. Criar grupo de exclusão para break-glass accounts (se ainda não existir)
$bgGroupName = "BreakGlass-Exclusion-MFA"
$bgGroup = New-MgGroup -DisplayName $bgGroupName `
  -MailEnabled:$false -SecurityEnabled -MailNickName "breakglass-excl"

# 2. Objeto da policy de Conditional Access
$params = @{
    DisplayName = "CA-MFA-AllUsers-Require"
    State = "enabled"   # usar "enabledForReportingButNotEnforced" para testar primeiro
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
            ExcludeUsers = @()
            ExcludeGroups = @($bgGroup.Id)
            ExcludeRoles = @()
        }
        Applications = @{
            IncludeApplications = @("All")
            ExcludeApplications = @()
        }
        ClientAppTypes = @("browser","mobileAppsAndDesktopClients")
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("mfa")
    }
}

# 3. Criar a policy
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

# 4. Verificar
Get-MgIdentityConditionalAccessPolicy | Where-Object DisplayName -eq "CA-MFA-AllUsers-Require"

Policy adicional: bloquear autenticação legacy

$legacyParams = @{
    DisplayName = "CA-Block-Legacy-Auth"
    State = "enabled"
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
        }
        Applications = @{
            IncludeApplications = @("All")
        }
        ClientAppTypes = @("exchangeActiveSync","other")
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("block")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $legacyParams

Policy por localização: exigir MFA fora da rede corporativa

# Definir network "trusted" com IPs corporativos (cria em Entra > Security > Named locations)
# Em seguida, policy que só exige MFA fora da rede trusted

$namedLocation = Get-MgIdentityConditionalAccessNamedLocation -Filter "DisplayName eq 'Corp-Network'"

$locParams = @{
    DisplayName = "CA-MFA-Untrusted-Network"
    State = "enabled"
    Conditions = @{
        Users = @{ IncludeUsers = @("All"); ExcludeGroups = @($bgGroup.Id) }
        Applications = @{ IncludeApplications = @("All") }
        Locations = @{
            IncludeLocations = @("All")
            ExcludeLocations = @($namedLocation.Id)
        }
        ClientAppTypes = @("all")
    }
    GrantControls = @{ Operator = "AND"; BuiltInControls = @("mfa") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $locParams

Documentação de referência: conditional-access-overview e concept-conditional-access-policies.

6. Configurar Microsoft Authenticator (push e number matching)

O Microsoft Authenticator é o método de MFA mais usado no Entra ID. Suporta notificações push (com number matching), códigos TOTP e, em inquilinos configurados, passwordless phone sign-in.

Habilitar push com number matching

O number matching obriga o utilizador a ver um número no ecrã de login e introduzi-lo na app, eliminando ataques de “push fatigue” em que o utilizador aprova sem ler. Esta capacidade está ativa por defeito em 2026.

# Ver configuração atual do Authentication Methods Policy
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod","Policy.Read.All"

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "MicrosoftAuthenticator"

# Ativar number matching e push
$params = @{
    "@odata.type" = "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration"
    State = "enabled"
    Features = @(
        @{
            FeatureType = "numberMatching"
            State = "enabled"
        }
    )
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "MicrosoftAuthenticator" -BodyParameter $params

Fluxo de registo inicial do utilizador

O utilizador regista os seus métodos em https://aka.ms/mfasetup (My Sign-Ins). A experience combinada (Combined Registration) permite registar todos os métodos de uma vez, em vez do legacy security info separado.

1. O utilizador acede a mysignins.microsoft.com com a sua conta.
2. Adiciona o Microsoft Authenticator app lendo o QR code.
3. Adiciona um telefone de fallback (apenas se SMS ainda permitido no inquilino).
4. Adiciona FIDO2 key se aplicável.

7. FIDO2 security keys passwordless

FIDO2 / WebAuthn representa o estado da arte em autenticação: é passwordless, resistente a phishing por construção (origin binding criptográfico) e não depende de telemóvel ou rede. Ideal para administradores, ambientes regulados e organizações que querem eliminar passwords.

Habilitar FIDO2 no inquilino

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

# Ver estado atual
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2"

# Habilitar FIDO2 com restrições (AAGUIDs permitidos)
$params = @{
    "@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    State = "enabled"
    IsAttestationEnforced = $true
    KeyRestrictions = @{
        IssuerIdentifier = "microsoft"
        KeyType = "shared"
        EnforcedType = "allow"
        AAGUIDs = @(
            "de1e552d-db1d-4423-a619-566b625cdc84",  # Microsoft
            "90a3ccdf-f077-456e-a08f-57150cb3d2ca"   # YubiKey 5
        )
    }
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2" -BodyParameter $params

Registo de uma FIDO2 key pelo utilizador

1. O utilizador acede a mysignins.microsoft.com > Security info > Add method > Security key.
2. Escolhe USB ou NFC.
3. Toca na chave, define PIN, regista impressão digital se aplicável.
4. A partir desse momento, pode fazer sign-in passwordless em apps que suportem WebAuthn.

Modelo	Tipo	AAGUID (exemplo)	Notas
YubiKey 5 NFC	USB-C + NFC	90a3ccdf-…	Suporta FIDO2, U2F, OpenPGP, PIV
YubiKey C Nano	USB-C discreto	90a3ccdf-…	Ideal para desktop permanente
Feitan ePass FIDO	USB-A	varia	Económico, suporte básico FIDO2
Google Titan	USB-C + NFC	varia	Compatível, sem NFC em todos os modelos

Referência: howto-authentication-passwordless-security-key.

Passkeys: FIDO2 sem hardware dedicado

Em 2026, as passkeys (FIDO2 de plataforma) permitem usar a biometria do dispositivo (Windows Hello, Touch ID, Face ID, Android biometric) como credential FIDO2, sem precisar de uma chave física separada. A Microsoft suporta passkeys no Entra ID via Microsoft Authenticator (que pode armazenar uma passkey sincronizada entre dispositivos do mesmo utilizador) e via plataformas nativas.

As passkeys reduzem a barreira de entrada para passwordless: em vez de comprar YubiKeys para todos, os utilizadores podem registar a biometria do seu portátil ou telemóvel. Para ambientes BYOD ou híbridos, isto é significativamente mais escalável.

Característica	FIDO2 hardware key	Passkey (plataforma)	Passkey (Authenticator sync)
Custo hardware	Sim (25-60€)	Não	Não
Portabilidade	Sim (USB/NFC)	Não (vinculada ao dispositivo)	Sim (sincronizada entre dispositivos do mesmo ecossistema)
Resistência a phishing	Alta	Alta	Alta
Recomendado para	Admins, ambientes regulados, high-security	Corporate devices	BYOD, utilizadores gerais
Gestão centralizada	Sim (AAGUIDs permitidos)	Sim (via policy FIDO2)	Sim (via policy FIDO2)

8. Exclusões e break-glass accounts

Toda a política de MFA deve ter exceções planeadas para evitar lockout total do inquilino. Break-glass accounts são contas de emergência, administrativas, cloud-only, com passwords longas e aleatórias, excluídas de MFA (ou com MFA via método offline independente) para garantir acesso mesmo que Conditional Access ou Identity Protection falhem.

Regras para break-glass accounts

• Duas contas, no mínimo, para redundância.
• Cloud-only (não sincronizadas de AD on-prem), sem licenças atribuídas.
• Password com 20+ caracteres aleatórios, guardada em cofre físico separado e/ou vault digital segmentado.
• Excluídas de Conditional Access policies.
• MFA configurado (FIDO2 ou TOTP offline) mas não enforced via CA — para não impedir login se CA estiver em mau estado.
• Monitorizadas com alertas em qualquer sign-in (alerta imediato para administradores).
• Auditoria mensal: verificar password, métodos, últimos sign-ins.

# Criar duas break-glass accounts
$pw = ConvertTo-SecureString (New-Guid.ToString() + (New-Guid.ToString())) -AsPlainText -Force

$bg1 = New-MgUser -DisplayName "BG-Admin-01" `
    -UserPrincipalName "[email protected]" `
    -PasswordProfile @{ Password=$pw; ForceChangePasswordNextSignIn=$false } `
    -AccountEnabled -MailNickname "bgadmin01" `
    -PasswordPolicies "DisablePasswordExpiration"

# Atribuir role Global Admin (temporário, apenas em emergência)
$gaRole = Get-MgDirectoryRoleTemplate -Filter "displayName eq 'Global Administrator'"
# (a atribuição real é feita após criar a directory role)

# Adicionar ao grupo de exclusão de CA
$bgGroup = Get-MgGroup -Filter "displayName eq 'BreakGlass-Exclusion-MFA'"
New-MgGroupMember -GroupId $bgGroup.Id -DirectoryObjectId $bg1.Id

Monitorização de break-glass accounts

As break-glass accounts devem ser usadas apenas em emergência. Qualquer sign-in deve gerar alerta imediato. Em P1/P2, configura Conditional Access em modo report-only para estas contas, ou usa Azure Monitor / Log Analytics para alertar.

# Criar alerta para sign-in de break-glass account via Diagnostic Settings + Log Analytics
# Primeiro, configura Diagnostic Settings no inquilino para exportar sign-in logs para Log Analytics

# KQL query para alerta: qualquer sign-in de break-glass account
# SigninLogs
# | where UserId in ("[email protected]", "[email protected]")
# | project TimeGenerated, UserPrincipalName, Location, IPAddress, ResultType
# Criar alert rule com esta query, severidade 1, alerta imediato

# Via PowerShell: verificar última atividade das break-glass
$bgUsers = @("[email protected]","[email protected]")
foreach ($upn in $bgUsers) {
    $u = Get-MgUser -Filter "userPrincipalName eq '$upn'"
    $signins = Get-MgAuditLogSignIn -Filter "userId eq $($u.Id)" -Top 5 -Sort "createdDateTime:desc"
    Write-Host "$upn - Últimos sign-ins:"
    $signins | Select-Object CreatedDateTime, IPAddress, Location, Status | Format-Table
}

Auditoria trimestral de break-glass

Agenda uma revisão trimestral com os seguintes passos:

1. Verificar que as passwords não foram comprometidas (rodar periodicamente, mesmo sem uso).
2. Confirmar que as contas não têm sign-ins não esperados.
3. Verificar que as contas continuam cloud-only e sem licenças atribuídas.
4. Confirmar que estão no grupo de exclusão de Conditional Access.
5. Verificar que os métodos de MFA (FIDO2 ou TOTP offline) continuam registados e funcionais.
6. Atualizar o registo documental: quem tem acesso ao cofre, quando foi aberto, porquê.

9. MFA para administradores

Administradores têm acesso privilegiado e são alvo prioritário de ataques. O Entra ID trata administradores de forma especial:

• Security Defaults exige MFA para todas as roles privilegiadas, sem exceção.
• Conditional Access permite criar policies específicas para administradores, exigindo MFA sempre (mesmo em redes trusted) e exigindo dispositivo conforme.
• Com P2, Privileged Identity Management (PIM) permite just-in-time activation: o admin só tem role ativo durante uma janela temporal, com MFA e justification em cada ativação.

Policy de MFA sempre para administradores

# Roles privilegiadas a incluir
$adminRoles = @(
    "62e90394-69f5-4237-9190-012177613609",  # Global Administrator
    "194ae4cb-b126-40b2-bd5b-6091b380977d",  # Security Administrator
    "f28a1f50-f6e7-4571-818b-6a124f547c46",  # Conditional Access Administrator
    "b1be1c3e-b8ca-4cb4-bf91-ada1c1bd06c6",  # User Administrator
    "729827e3-9c14-49f7-bb1b-9608f156bbb8"   # Privileged Role Administrator
)

$params = @{
    DisplayName = "CA-MFA-Admins-Always"
    State = "enabled"
    Conditions = @{
        Users = @{
            IncludeRoles = $adminRoles
            ExcludeUsers = @()
            ExcludeGroups = @($bgGroup.Id)
        }
        Applications = @{ IncludeApplications = @("All") }
        ClientAppTypes = @("all")
    }
    GrantControls = @{
        Operator = "AND"
        BuiltInControls = @("mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Recomendação PIM (P2)

# Verificar eligibility de PIM para Global Admin
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
Get-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -All

# Atribuir elegibilidade (não atribuição permanente) para um admin
$gaTemplate = Get-MgDirectoryRoleTemplate -Filter "displayName eq 'Global Administrator'"
$params = @{
    Action = "AdminAssign"
    RoleDefinitionId = $gaTemplate.Id
    DirectoryScopeId = "/"
    PrincipalId = $adminUserId
    ScheduleInfo = @{
        StartDateTime = (Get-Date).ToString("o")
        Expiration = @{
            Type = "AfterDuration"
            Duration = "PT8H"
        }
    }
}
New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

Com PIM, mesmo que o administrador tenha MFA válido, a role só fica ativa quando ele explicitamente a ativa, com MFA adicional e justification. Isto reduz drasticamente a superfície de ataque a contas privilegiadas. Referência: pim-configure.

Roles que devem ter MFA sempre e PIM

Role	MFA sempre (CA)	PIM just-in-time	Notas
Global Administrator	Sim	Sim	Máximo privilégio; deve ter apenas 2-5 elegíveis
Security Administrator	Sim	Sim	Gestão de security defaults, policies
Conditional Access Administrator	Sim	Sim	Pode alterar todas as policies de MFA
Privileged Role Administrator	Sim	Sim	Gestão de PIM; atacar esta role é atacar tudo
User Administrator	Sim	Sim	Pode redefinir passwords e métodos de MFA de outros
Exchange Administrator	Sim	Recomendado	Acesso a mailbox de todos os utilizadores
SharePoint Administrator	Sim	Recomendado	Acesso a todos os sites
Application Administrator	Sim	Recomendado	Pode criar app registrations com permissões elevadas
Cloud Application Administrator	Sim	Recomendado	Similar ao Application Admin

Verificar contas com roles privilegiadas permanentes

# Listar todos os atribuições permanentes de roles (não PIM)
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

Get-MgDirectoryRoleAssignment -All | `
    Where-Object { $_.RoleDefinitionId -in $privilegedRoleIds } | `
    Select-Object PrincipalId, RoleDefinitionId, DirectoryScopeId

# Comparar com PIM eligibility
Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -All | `
    Select-Object PrincipalId, RoleDefinitionId, StartDateTime, EndDateTime

# Identificar contas com role permanente que deviam ser PIM
# Qualquer role permanente (não via PIM) é um alerta de review

10. Gestão de métodos de autenticação

O Authentication Methods Policy (Entra > Security > Authentication methods) permite controlar que métodos estão disponíveis, quem os pode usar e como são configurados. Em 2026, este é o mecanismo centralizado que substitui as configurações dispersas do MFA legacy.

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod","Policy.Read.All"

# Ver configuração completa
Get-MgPolicyAuthenticationMethodPolicy | ConvertTo-Json -Depth 10

# Listar todos os métodos disponíveis e respetivo estado
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -All | `
    Select-Object Id, State, @{N="Type";E={$_.AdditionalProperties."@odata.type"}}

# Desativar SMS (recomendado em 2026)
$params = @{
    "@odata.type" = "#microsoft.graph.smsAuthenticationMethodConfiguration"
    State = "disabled"
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Sms" -BodyParameter $params

# Ativar Temporary Access Pass (para recuperação e onboarding)
$params = @{
    "@odata.type" = "#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration"
    State = "enabled"
    DefaultLength = 8
    DefaultLifetimeInMinutes = 60
    IsUsableOnce = $false
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "TemporaryAccessPass" -BodyParameter $params

Lista de métodos configuráveis

Método (ID)	Estado recomendado 2026
MicrosoftAuthenticator	enabled (com number matching)
Fido2	enabled (com AAGUIDs permitidos)
Sms	disabled (se possível)
Voice	disabled
Email	enabled apenas para self-service password reset
TemporaryAccessPass	enabled (para recuperação)
SoftwareOath	enabled (fallback)
HardwareOath	enabled se houver tokens físicos
WindowsHelloForBusiness	enabled
QRCodePin	opcional

Geração de Temporary Access Pass para um utilizador

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"

# Gerar TAP para um utilizador específico
$userId = (Get-MgUser -Filter "userPrincipalName eq '[email protected]'").Id

$params = @{
    LifetimeInMinutes = 60
    IsUsableOnce = $false
}
$tap = New-MgUserAuthenticationTemporaryAccessRequestMethod -UserId $userId -BodyParameter $params
Write-Host "TAP gerado: $($tap.TemporaryAccessPass)"
Write-Host "Válido até: $($tap.ExpirationDateTime)"
# Comunicar o TAP ao utilizador por canal seguro (telefone, presencial)
# O utilizador entra em mysignins.microsoft.com usando o TAP como método

Verificar métodos registados por utilizador

# Listar todos os métodos de MFA de um utilizador
$userId = (Get-MgUser -Filter "userPrincipalName eq '[email protected]'").Id
Get-MgUserAuthenticationMethod -UserId $userId | ForEach-Object {
    $type = $_.AdditionalProperties."@odata.type" -replace "#microsoft.graph.",""
    Write-Host "Método: $type"
    if ($type -eq "microsoftAuthenticatorAuthenticationMethod") {
        Write-Host "  Device: $($_.AdditionalProperties.displayName)"
        Write-Host "  DeviceTag: $($_.AdditionalProperties.deviceTag)"
    }
    if ($type -eq "fido2AuthenticationMethod") {
        Write-Host "  Model: $($_.AdditionalProperties.model)"
        Write-Host "  AAGUID: $($_.AdditionalProperties.aaguid)"
    }
    if ($type -eq "phoneAuthenticationMethod") {
        Write-Host "  PhoneType: $($_.AdditionalProperties.phoneType)"
        Write-Host "  PhoneNumber: $($_.AdditionalProperties.phoneNumber)"
    }
}

# Relatório de todos os utilizadores e quantos métodos têm
$users = Get-MgUser -Filter "accountEnabled eq true" -All -Property Id,DisplayName,UserPrincipalName
$report = foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $u.Id
    [PSCustomObject]@{
        User = $u.UserPrincipalName
        MethodCount = $methods.Count
        HasAuthenticator = ($methods.AdditionalProperties."@odata.type" -contains "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod")
        HasFIDO2 = ($methods.AdditionalProperties."@odata.type" -contains "#microsoft.graph.fido2AuthenticationMethod")
        HasPhone = ($methods.AdditionalProperties."@odata.type" -contains "#microsoft.graph.phoneAuthenticationMethod")
    }
}
$report | Format-Table -AutoSize

11. Diagnóstico: sign-in logs e What-If

O diagnóstico de MFA passa por duas ferramentas principais: sign-in logs (o que realmente aconteceu) e Conditional Access What-If (o que aconteceria se um utilizador específico tentasse login num contexto específico).

Sign-in logs

Os sign-in logs registam cada tentativa de autenticação, incluindo: método de MFA usado, resultado (success/failure), Conditional Access policies aplicadas, e detalhes de risco (com P2). A retenção varia por licença: 7 dias no Free, 30 dias no P1/P2. Para retenção longa, exporta para Log Analytics ou Storage Account.

# Listar sign-ins falhados por MFA nas últimas 24h
Connect-MgGraph -Scopes "AuditLog.Read.All","Sign-in.Read.All"

$yesterday = (Get-Date).AddDays(-1).ToString("o")
$filter = "createdDateTime ge $yesterday and status/errorCode ne 0"

Get-MgAuditLogSignIn -Filter $filter -Top 50 | `
    Select-Object UserPrincipalName, CreatedDateTime, `
        @{N="ErrorCode";E={$_.Status.ErrorCode}}, `
        @{N="FailureReason";E={$_.Status.FailureReason}}, `
        @{N="ConditionalAccessStatus";E={$_.ConditionalAccessStatus}} | `
    Format-Table -AutoSize

Códigos de erro comuns em MFA:

Código	Significado	Ação
50074	MFA required but not performed	Utilizador dispensou MFA; educar ou ajustar policy
500121	Authentication failed during strong auth	Método inválido; re-registar método
50097	Device authentication required	Verificar se Conditional Access exige dispositivo conforme
53003	Blocked by Conditional Access	Policy bloqueou; ver What-If para diagnosticar
700016	Application not found in directory	App ID errado ou app desativada
50158	External challenge not satisfied	FIDO2 ou Authenticator não completou o challenge

Conditional Access What-If

O What-If permite simular uma tentativa de login e ver que policies se aplicariam. Está disponível em Entra > Security > Conditional Access > What-If, e também via API. É indispensável antes de ativar uma policy nova.

# What-If via Graph (preview endpoint)
Connect-MgGraph -Scopes "Policy.Read.All","User.Read.All"

$whatIfParams = @{
    User = @{ Id = $userObjectId }
    Application = @{ Id = "00000003-0000-0ff1-ce00-000000000000" }  # Microsoft 365
    ClientAppType = "browser"
    SignInRiskLevel = "medium"
}
# Nota: o endpoint What-If está em /identity/conditionalAccess/policies/whatIf
# Ver docs atualizadas para o exato endpoint Graph

Referências: concept-sign-ins e what-if-tool.

Exportar logs para retenção longa

Para auditoria NIS2, 30 dias de retenção (P1/P2) pode não ser suficiente. Configura Diagnostic Settings para exportar sign-in logs para um Log Analytics Workspace ou para um Storage Account com retenção de 1-2 anos.

# Configurar Diagnostic Settings via Graph (preview)
# Em alternativa, via portal: Entra ID > Diagnostic settings > Add

# Via Azure CLI (para Log Analytics Workspace)
# az monitor diagnostic-settings create \
#   --name "EntraSigninLogs" \
#   --resource "/providers/Microsoft.AAD/tenant/$tenantId" \
#   --workspace "/subscriptions/$subId/resourcegroups/$rg/providers/microsoft.operationalinsights/workspaces/$wsName" \
#   --logs '[{"category":"SignInLogs","enabled":true},{"category":"SignInNonInteractiveUserLogs","enabled":true},{"category":"ServicePrincipalSignInLogs","enabled":true}]'

# Query KQL para top utilizadores com MFA falhada (no Log Analytics)
# SigninLogs
# | where TimeGenerated > ago(30d)
# | where ConditionalAccessStatus == "failure"
# | summarize Count = count() by UserPrincipalName
# | order by Count desc
# | take 20

Matriz de diagnóstico

Sintoma	Onde procurar	O que verificar
Utilizador não consegue entrar	Sign-in logs (interactive)	ErrorCode, ConditionalAccessStatus, appliedPolicies
Policy não aplica	What-If + Sign-in logs	Se a policy aparece em “Policies that didn’t apply” e porquê
MFA pedida inesperadamente	Sign-in logs > Conditional Access	Que policy triggered; se é por localização ou risco
MFA não pedida quando devia	Sign-in logs + Authentication Methods	Se o utilizador tem método registado; se policy está enabled
App legacy parte	Sign-in logs > ClientAppType	Se é “exchangeActiveSync” ou “other” (legacy), policy de block aplica
Admin não consegue ativar role em PIM	PIM audit logs	Se MFA falhou durante ativação; se elegibilidade expirou

12. Cenário PME sem custo

Uma PME portuguesa com 10-50 utilizadores, sem licenças Microsoft 365 Business (apenas Exchange Online Plan 1 ou Microsoft 365 Free tier), pode cumprir NIS2 em MFA sem custo adicional usando Security Defaults.

Passo a passo para PME sem custo

1. Acede a entra.microsoft.com como Global Admin.
2. Vai a Protection > Security Defaults (ou Identity > Properties > Security Defaults).
3. Ativa Security Defaults.
4. Informa os utilizadores: vão ser pedidos para instalar Microsoft Authenticator no próximo login.
5. Cria duas break-glass accounts cloud-only, com passwords longas, guardadas em cofre físico.
6. Monitoriza os primeiros sign-ins: utiliza os sign-in logs (7 dias de retenção no Free) para identificar utilizadores com problemas de registo.
7. Para utilizadores sem smartphone, usa FIDO2 key (custo ~30€) ou token hardware OATH.

Quando uma PME deve pagar por P1

Situação	Free chega?	Melhor opção
PME simples, sem contas de serviço, sem apps legacy	Sim	Security Defaults
Tem scripts/autenticação service principal	Não	P1 (Conditional Access com exclusões)
Precisa de logs de 30 dias	Não	P1
Quer MFA só fora do escritório	Não	P1 (CA por localização)
Sujeita a auditoria NIS2 como entidade essencial	Não	P2 (Identity Protection, PIM)
Tem administradores com acesso permanente	Não	P2 (PIM just-in-time)

13. Erros comuns

Erro	Sintoma	Causa	Resolução
MFA não pedida após ativar CA	Utilizador faz login sem MFA	Policy em report-only ou usuário em grupo de exclusão	Verificar State = enabled; verificar exclusões de grupo
Lockout total de admins	Ninguém consegue entrar no inquilino	Sem break-glass; CA mal configurada	Usar break-glass account; se não existir, contactar Microsoft Support
Authenticator push não chega	Notificação não aparece no telemóvel	App desatualizada, iOS/Android em modo não perturbar, ou conta removida da app	Atualizar app; re-registar; usar TOTP code como fallback
FIDO2 key rejeitada	“We couldn’t verify your security key”	AAGUID não permitido no policy; attestation enforced e key não atestada	Adicionar AAGUID ao KeyRestrictions; ou desativar attestation enforce
Scripts partem com Security Defaults	Automação falha com erro de MFA	Security Defaults exige MFA para todos, incluindo service principals	Migrar para P1 + Conditional Access com exclusões; usar workload identity
SMS não permite registo	“You can’t use this phone number”	SMS desativado no Authentication Methods Policy (padrão 2026)	Ativar Microsoft Authenticator; fornecer FIDO2 ou TOTP como alternativa
Number matching não aparece	Push chega sem número para introduzir	Number matching não ativo no tenant	Ativar via Authentication Methods Policy > MicrosoftAuthenticator > features
Sign-in logs não mostram CA	Coluna Conditional Access vazia	Policy em disabled ou sem match	Verificar State; usar What-If para simular
Utilizador perde telemóvel	Não consegue fazer MFA	Método único registado	Admin gera Temporary Access Pass; utilizador re-regista métodos
Conditional Access não aplica a uma app	App específica não pede MFA	App na lista de exclusões ou não suporta CA	Verificar IncludeApplications; algumas apps legacy não suportam CA

14. Checklist de implementação

• Auditar inquilino: verificar se Security Defaults estão ativos e que licenças P1/P2 existem.
• Criar duas break-glass accounts cloud-only com passwords de 20+ caracteres.
• Guardar credenciais break-glass em cofre físico separado, com pelo menos duas pessoas com acesso.
• Configurar alertas de sign-in para as break-glass accounts (qualquer login dispara alerta).
• Definir grupos de piloto para testar Conditional Access antes de aplicar a todos.
• Criar policy CA-MFA-AllUsers em modo report-only.
• Monitorizar sign-in logs durante 5-10 dias para validar impacto.
• Mudar policy para enabled.
• Criar policy CA-Block-Legacy-Auth em enabled.
• Criar policy CA-MFA-Admins-Always (MFA sempre para roles privilegiadas, sem trusted network).
• Configurar Authentication Methods Policy: ativar Microsoft Authenticator com number matching e additional context.
• Desativar SMS e Voice se a organização conseguir operar sem eles.
• Ativar Temporary Access Pass para recuperação.
• Habilitar FIDO2 e definir AAGUIDs permitidos.
• Distribuir FIDO2 keys a administradores e contas privilegiadas.
• Orientar utilizadores no registo via mysignins.microsoft.com (Combined Registration).
• Configurar retenção de logs: exportar para Log Analytics se P1/P2 para retenção > 30 dias.
• Se P2 disponível: configurar PIM para todas as roles privilegiadas com just-in-time activation.
• Documentar policies de Conditional Access com nome, objetivo, owner, data de revisão.
• Agendar revisão trimestral de policies, métodos e break-glass accounts.
• Verificar conformidade NIS2: MFA enforced, logs disponíveis, capacidade de resposta a incidente.
• Comunicar aos utilizadores o que esperar nos primeiros logins após implementação.

Referências externas

• Tutorial: Enable MFA — learn.microsoft.com
• Conditional Access overview — learn.microsoft.com
• Security Defaults — learn.microsoft.com
• Authentication methods — learn.microsoft.com
• FIDO2 security keys passwordless — learn.microsoft.com
• Passwordless phone sign-in — learn.microsoft.com
• Conditional Access policies — learn.microsoft.com
• What-If tool — learn.microsoft.com
• Sign-in logs — learn.microsoft.com
• Privileged Identity Management — learn.microsoft.com
• Entra ID licensing — learn.microsoft.com
• Conditional Access with Microsoft Graph PowerShell — learn.microsoft.com
• Temporary Access Pass — learn.microsoft.com