MFA FIDO2 Resistente a Phishing: Como Configurar no Microsoft 365 e Google Workspace

MFA · FIDO2 · Phishing Resistente · Microsoft 365 · Google Workspace · Entra ID · YubiKey  |  ✎ Duarte Spínola  |  13 de Junho de 2026

A MFA FIDO2 resistente a phishing substitui passwords e códigos TOTP por uma chave criptográfica (passkey ou chave de hardware) que está bloqueada ao domínio original — atacantes não conseguem fazer phishing porque o browser recusa apresentar a credencial em sites falsos. Em 2026, a Microsoft exige MFA resistente a phishing para contas privilegiadas (Secure Future Initiative, Nov-2023), o Google já tem mais de 800M accounts com passkeys activas, e o CISA (EUA) classifica MFA FIDO2 como o único método aceitável para contas de administração. Este artigo mostra como activar MFA FIDO2 em Microsoft 365 / Entra ID (para admins e utilizadores finais) e em Google Workspace, cobrindo políticas de Conditional Access, device-bound vs synced passkeys, chaves de hardware (YubiKey, Feitian), e os 10 problemas mais comuns em deployment empresarial.

1. O que é MFA FIDO2 e porque é diferente

A MFA tradicional (TOTP via app, SMS, email) tem 3 falhas críticas que FIDO2 resolve:

2. Cenários onde se aplica

• [T] Conta pessoal Google (Gmail) ou Microsoft (Outlook.com) com passkey.
• [T] Microsoft 365 Business/Education/Enterprise — activar FIDO2 para todos os utilizadores.
• [T] Google Workspace Business — activar passkeys para utilizadores finais.
• [T] Conta privilegiada (admin global, Domain Admin) — chave de hardware obrigatória.
• [T] Hybrid (Entra ID + on-prem AD) com SSO e FIDO2 sincronizado via Kerberos.
• [D] Apps mobile que suportam FIDO2 (Microsoft 365, Outlook iOS/Android, Gmail).
• [D] Smart card / cartão de cidadão (AADJ) com chaves FIDO2.
• [D] Conditional Access com signal "authentication strength = phishing-resistant".

3. Diagnóstico prévio

Antes de activar FIDO2 em produção, valide 3 coisas:

3.1 Inventário de autenticação actual

# PowerShell — listar métodos activos em cada utilizador
Get-MgUserAuthenticationMethod -UserId [email protected] |
    Select-Object Id, AdditionalProperties

# Google Workspace Admin SDK — audit métodos 2FA activos
# Admin Console → Security → Authentication → 2-step verification
# Exportar CSV de utilizadores com 2FA

3.2 Compliance com políticas

Identifique utilizadores com passwords fracas ou MFA apenas TOTP/SMS — estes são os candidatos prioritários para migração.

3.3 Dispositivos e browsers

4. Solução genérica (passo a passo)

A implementação segue sempre esta sequência:

1. Piloto — começar com 5-10 utilizadores (IT team + 1-2 áreas).
2. Activar FIDO2 no tenant (Entra ID ou Google Workspace).
3. Definir política (key restrictions, allowed AAGUIDs, attestation).
4. Criar Conditional Access (requer phishing-resistant MFA em apps confidenciais).
5. Registar chaves (passkeys, YubiKey).
6. Validar login em todos os cenários.
7. Expandir gradualmente (10% → 50% → 100%).
8. Descontinuar TOTP/SMS (manter como fallback temporário).

5. Implementar MFA FIDO2 em Microsoft 365 / Entra ID

5.1 Activar método "Passkey (FIDO2)" no tenant

1. Entra admin center (https://entra.microsoft.com) → Protection → Authentication methods → Policies → Passkey (FIDO2).
2. Enable → escolher grupos (recomendado: começar por grupo piloto).
3. Configurar Key restrictions:

– Allow self-service setup: Yes (utilizadores podem registar a sua chave). – Enforce attestation: Yes (recomendado para validar a chave). – Enforce key restrictions: Yes → Restrict specific keys se quiser allowlist.

5.2 Conditional Access: exigir phishing-resistant MFA

1. Entra admin center → Protection → Conditional Access → Create new policy.
2. Name: "Require phishing-resistant MFA for admins".
3. Assignments:

– Users: Global Administrator, Privileged Role Administrator, Exchange Administrator, Security Administrator, e todas as privileged roles. – Cloud apps: All cloud apps (ou específico: Azure portal, M365 admin center).

1. Grant: ✅ Require authentication strength → Phishing-resistant MFA.
2. Session: deixe vazio (aumenta fricção).
3. Enable policy: On → Create.

5.3 Registar passkey como utilizador (Windows Hello)

1. Sign in em https://mysignins.microsoft.com.
2. Security info → + Add sign-in method → Passkey → Add.
3. Sistema pergunta o tipo:

– Windows Hello (plataforma) — PIN ou biometria. – Security key (roaming) — inserir YubiKey.

1. Confirmar biometria/PIN. A passkey fica associada à conta.

5.4 Registar YubiKey como admin

1. Comprar YubiKey 5 NFC ou YubiKey 5C NFC (€50-70 cada, 5-10 anos de durabilidade).
2. Inserir na porta USB ou aproximar (NFC).
3. Em mysignins.microsoft.com → Security info → + Add sign-in method → Security key.
4. Tocar no botão da YubiKey quando solicitado.
5. Repetir com segunda YubiKey (backup obrigatório para contas admin).
6. Testar login em https://portal.azure.com.

5.5 PowerShell para auditar e gerir

# Listar métodos FIDO2 activos num utilizador
Get-MgUserAuthenticationFido2Method -UserId [email protected] | Format-List

# Listar utilizadores SEM phishing-resistant MFA
$users = Get-MgUser -All
foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $u.Id
    $hasFido = $methods | Where-Object { $_.AdditionalProperties["@odata.type"] -like "#microsoft.graph.fido2*" }
    if (-not $hasFido) { Write-Host "Sem FIDO2: $($u.UserPrincipalName)" }
}

6. Implementar MFA FIDO2 em Google Workspace

6.1 Activar 2-step verification (pré-requisito)

1. Admin Console (https://admin.google.com) → Security → Authentication → 2-Step Verification.
2. Allow users to turn on 2-Step Verification.
3. Enforcement: On para utilizadores a partir de data X (recomendado agendar 30 dias).

6.2 Forçar passkeys (não TOTP)

1. Security → Authentication → 2-Step Verification → Settings.
2. Em Allowed second factors, desmarcar "Authenticator app" e "SMS" (opcional, recomendado para 2026+).
3. Deixar apenas Security key + Passkey.
4. Save.

6.3 Registar passkey de utilizador

1. Sign in em Google → Manage your Google Account → Security.
2. Em "Passkeys and security keys" → Create a passkey.
3. Sistema detecta dispositivo (Windows Hello, Touch ID, YubiKey).
4. Confirmar biometria → passkey criada.
5. Sincroniza automaticamente com Google Password Manager (entre Chrome e Android).

6.4 Registar YubiKey (roaming)

1. Em myaccount.google.com → Security → 2-Step Verification → Security Keys.
2. Add security key → inserir YubiKey → tocar no botão.
3. Repetir com segunda YubiKey (backup).

6.5 Forçar FIDO2 em apps confidenciais via Context-Aware Access

1. Admin Console → Security → Context-Aware Access.
2. Criar Access level: "Require phishing-resistant 2SV".
3. Atribuir a apps específicas (Gmail, Drive, Admin Console).
4. Save + enforce.

7. Configurações avançadas: AAGUID allowlist

A AAGUID (Authenticator Attestation GUID) identifica o tipo de chave (e.g. YubiKey 5 NFC = cb69481e-8ff7-4039-93ec-0a5869ecd075). Em ambientes de alta segurança, pode restringir quais AAGUIDs são aceites.

7.1 No Entra ID

# Configurar AAGUID allowlist
$authMethodPolicy = @{
    "@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    state = "enabled"
    isSelfServiceRegistrationAllowed = $true
    isAttestationEnforced = $true
    keyRestrictions = @{
        isEnforced = $true
        enforcementType = "allow"
        aaGuids = @(
            "cb69481e-8ff7-4039-93ec-0a5869ecd075",  # YubiKey 5 NFC
            "ee882879-721c-4913-8515-8f77c455d9c7",  # YubiKey 5C NFC
            "2fc0579f-8113-47ea-b116-bb5a8db9202a",  # Windows Hello
            "6d45ba0a-4d0d-4664-8b8f-03b1a4d8a3a4"   # Microsoft Authenticator (device-bound)
        )
    }
}
Update-MgPolicyAuthenticationMethodPolicy -AuthenticationMethodPolicyId "authenticationMethodsPolicy" -BodyParameter $authMethodPolicy

7.2 Porquê AAGUID allowlist?

• Atacante com credenciais comprometidas não pode usar qualquer passkey que queira.
• Passkeys sincronizadas (iCloud, Google) têm AAGUID diferente de device-bound (Windows Hello, Microsoft Authenticator).
• Para contas admin, force apenas hardware keys + device-bound.

Lista de AAGUIDs está em fidoalliance.org/metadata — actualizado mensalmente.

8. Hybrid: Entra ID + Active Directory on-prem

Se tem Active Directory on-prem sincronizado com Entra ID via Azure AD Connect (agora Entra Connect), os métodos FIDO2 do Entra ID aplicam-se ao login Office 365 / Azure. Para Windows logon on-prem com FIDO2:

8.1 Opção 1: Windows Hello for Business (recomendado)

1. Entra Connect → Pass-through authentication ou Federated com ADFS.
2. Activar Windows Hello for Business via Intune ou GPO.
3. Os utilizadores usam PIN/biometria no Windows logon.

8.2 Opção 2: FIDO2 logon via Entra Kerberos (preview)

A Microsoft introduziu Entra Kerberos que permite usar FIDO2 key para login em domain-joined machines via cloud Kerberos ticket. Saiba mais.

9. Verificação

9.1 Confirmar que MFA FIDO2 está activa

# Verificar métodos activos de um utilizador
$user = Get-MgUser -UserId [email protected]
$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
$methods | Select-Object OdataType, DisplayName

9.2 Testar login phishing-resistant

1. Logout completo.
2. Tentar login em https://portal.azure.com.
3. Esperado: aparece opção "Sign in with passkey" ou "Use Windows Hello".
4. Confirmar biometria → login OK.

9.3 Testar resistência a phishing

1. Aceder a site falso (e.g. microsft.com ou login-microsoftonline.com).
2. Esperado: browser não apresenta opção de passkey — só password.
3. Confirmação visual: o ícone de chave na barra de URL mostra site legítimo.

9.4 Validação externa

• Entra ID Sign-in logs → filtrar por Authentication Details → Authentication Method = FIDO2.
• Google Workspace Admin Console → Reports → Security → 2SV usage.

10. Outras causas comuns (10 problemas)

Quando o deployment falha, o problema raramente é o standard — é o contexto operacional:

1. "Phishing-resistant" não aparece no Conditional Access — Entra ID P1/P2 necessário. Licenças Microsoft 365 Business Premium, E3, E5 incluem. Business Basic não.
2. Utilizador perdeu o telemóvel e não tem backup — sem segunda chave ou recovery code, fica bloqueado. Política: 2 chaves no mínimo (1 principal + 1 backup guardado em cofre).
3. Sincronização de passkey entre iPhone e Windows não funciona — iCloud Keychain sync só entre devices Apple. Para PC Windows, precisa de QR code + Bluetooth ou criar passkey nativa no Windows.
4. "Authentication strength" não é seleccionável — só aparece em tenants com Entra ID P1+ (Microsoft 365 E3, E5, Business Premium). Em P0, só dá para escolher métodos individuais.
5. YubiKey não é detectada em VMs/Remote Desktop — USB passthrough em RDP/VDI exige configuração. Citrix Workspace suporta FIDO2 redirection (Citrix Virtual Apps 7 2009+); VMware Horizon precisa de RDM (Remote Device Mapping).
6. TOTP continua a ser pedido mesmo com FIDO2 — alguns serviços mantêm TOTP como fallback "por compatibilidade". Configure Conditional Access para bloquear TOTP se houver FIDO2.
7. On-prem AD rejeita FIDO2 logon — só funciona com Windows Hello for Business Certificate Trust ou Key Trust. Não é nativo no logon tradicional. Use Entra Kerberos (preview) ou Windows Hello for Business.
8. Application não suporta FIDO2 — aplicações legadas (RDP, WinRM, WinSCP) só suportam password. Mitigue com gMSA (Group Managed Service Account) + LAPS em vez de MFA.
9. Falsos positivos em "phishing-resistant" — AiTM proxy — phishing kits modernos (Evilginx, Modlishka) conseguem bypass TOTP mas não FIDO2 (domain binding). Confirme que os logs mostram FIDO2 (não TOTP) — o ataque fica registado.
10. Compliance com regulação legacy (PCI-DSS 3.x, HIPAA) — algumas industrias exigem password + 2 factores. Compense: use FIDO2 como 2º factor (mantenha password legado + FIDO2) até regulação actualizar.

11. Como evitar (boas práticas)

1. Piloto de 5-10 pessoas (IT team + 1 área) durante 2-4 semanas antes de expandir.
2. 2 chaves no mínimo por utilizador (principal + backup). Para admins: 3 chaves, com 1 em cofre.
3. Descontinuar TOTP e SMS gradualmente — manter 90 dias como fallback, depois bloquear via Conditional Access.
4. Conditional Access obrigatório para admins — authentication strength = phishing-resistant MFA.
5. Auditoria mensal — script PowerShell que identifica utilizadores sem FIDO2 em grupos sensíveis.
6. AAGUID allowlist para contas privilegiadas — só YubiKey/Feitian/Windows Hello. Não permita passkeys sincronizadas (iCloud, Google) em admins.
7. Teste de phishing real — use plataforma como GoPhish para simular ataque. FIDO2 deve bloquear 100%.
8. Documentação para helpdesk — fluxo de "utilizador perdeu chave" e "preciso de segunda chave" tem que estar claro.
9. Renovar chaves de hardware a cada 5-7 anos (durabilidade YubiKey ~5-10 anos, com 100k cliques).
10. Educação contínua — passkeys eliminam phishing técnico, mas vishing (ataque por voz) e SIM swap continuam. Mantenha formação trimestral.