Blog do Chesley

Blog Chesley · chesley.com.br | Segurança de Identidade · Microsoft 365 · Entra ID

Sumário

1. Introdução
2. O Mapa dos Métodos de Autenticação
3. Autenticação Primária (Primary Authentication)
4. Autenticação Multifator — MFA (Multi-Factor Authentication)
5. Redefinição de Senha por Autoatendimento — SSPR (Self-Service Password Reset)
6. Recuperação de Conta (Account Recovery)
7. Métodos Resistentes a Phishing (Phishing-Resistant Methods)
8. Como Configurar os Principais Métodos via PowerShell
9. Campanhas de Registro (Registration Campaigns) e Passkeys
10. Mitos e Correções — O Que Circula de Errado nos Blogs
11. Boas Práticas de Segurança e Governança
12. Referências do Microsoft Learn

Introdução

O Microsoft Entra ID suporta uma lista crescente de métodos de autenticação — e a expansão das Campanhas de Registro (Registration Campaigns) para incluir chaves de acesso (passkeys) está levando muitas organizações a repensar toda a sua estratégia de identidade.

Mas existe um padrão que ainda se repete em quase toda organização: os administradores conhecem os métodos disponíveis, mas nem sempre sabem onde cada um pode (ou deve) ser usado.

As perguntas que mais aparecem no dia a dia são:

• Esse método pode ser usado para login principal (primary sign-in)?
• Ele funciona como segundo fator (MFA)?
• Suporta autenticação sem senha (passwordless)?
• Pode ser registrado para redefinição de senha (SSPR)?
• É possível usar External MFA ou TAP para SSPR? (A resposta é não.)

Essa distinção não é trivial. Ela é fundamental ao projetar um modelo de autenticação seguro e amigável. Nem todo método MFA é adequado para redefinição de senha. Nem todo método forte permite recuperação de conta. E — ponto crítico — nem todo método de autenticação forte é resistente ao phishing.

Este artigo traz uma visão completa dos métodos, como configurá-los, as armadilhas mais comuns e as boas práticas que organizações maduras já adotam.

O Mapa dos Métodos de Autenticação

A tabela abaixo apresenta todos os métodos disponíveis no Microsoft Entra ID e em quais cenários cada um pode ser utilizado.

¹ Windows Hello for Business pode servir como MFA de step-up se o usuário tiver uma passkey (FIDO2) registrada. ² Email OTP está disponível para membros de tenant para SSPR e também pode ser configurado para usuários convidados (guests). ³ Verified ID é uma capacidade de verificação de identidade, não um método de autenticação tradicional. Fornece prova de identidade para recuperação de conta, mas não pode ser usado para sign-in, MFA ou SSPR.

Autenticação Primária

A autenticação primária (primary authentication) é o primeiro fator que o usuário apresenta ao fazer login. Nem todos os métodos suportam esse papel — entender quais suportam é o ponto de partida para qualquer redesenho de estratégia.

Métodos que suportam autenticação primária

• Password — O método mais tradicional; ainda presente na maioria dos ambientes, mas deve ser combinado com MFA.
• Microsoft Authenticator passwordless — Login sem senha via notificação push com correspondência de número. Experiência superior de UX e segurança.
• Microsoft Authenticator push notifications — Push com número de correspondência para evitar MFA fatigue.
• Passkey (FIDO2) — Chaves de segurança físicas (ex: YubiKey) ou passkeys de plataforma. Login mais rápido e forte que senha+MFA.
• Passkey in Microsoft Authenticator — Passkey sincronizada gerenciada dentro do app Authenticator.
• Platform Credential for macOS — Credencial baseada em hardware do macOS (Secure Enclave).
• QR code — Autenticação via código QR; indicado para cenários de trabalhadores de linha de frente (frontline workers) sem e-mail corporativo.
• SMS sign-in — Login via código SMS. Prático mas com menor resistência a SIM swap.
• Synced passkey — Passkeys sincronizadas entre dispositivos (ex: iCloud Keychain, Google Password Manager).
• Temporary Access Pass (TAP) — Código temporário de uso único ou limitado; ideal para onboarding e recuperação de dispositivo.
• Windows Hello for Business — Autenticação biométrica ou PIN vinculada ao dispositivo, com suporte a TPM. Resistente a phishing.

Métodos que não suportam autenticação primária

• Authenticator Lite, Email OTP, External MFA, Hardware OATH tokens, Software OATH tokens, Voice call, Verified ID — todos esses exigem que outro método já tenha sido apresentado primeiro.

Autenticação Multifator (MFA)

O segundo fator (MFA) é o que eleva a segurança do login. Mas é aqui que começa a confusão mais comum: nem todo método MFA pode ser usado para SSPR ou recuperação de conta.

Métodos que suportam MFA

• Authenticator Lite
• Certificate-based authentication (CBA)
• Email OTP (em cenários específicos — veja nota ²)
• External MFA
• Hardware OATH tokens
• Microsoft Authenticator push notifications
• Passkey (FIDO2) e Passkey in Microsoft Authenticator
• Platform Credential for macOS
• SMS sign-in
• Software OATH tokens
• Synced passkey
• Temporary Access Pass (TAP)
• Voice call
• Windows Hello for Business

Como habilitar a Política de Métodos de Autenticação via PowerShell

A gestão de métodos de autenticação migrou do portal legado (MFA por usuário + SSPR individual) para a Authentication Methods Policy, que é gerenciada de forma unificada.

powershell

# Conectar ao Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
# Listar métodos habilitados na tenant
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations
# Habilitar Microsoft Authenticator para todos os usuários
$params = @{
    "@odata.type" = "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration"
    state = "enabled"
    featureSettings = @{
        companionAppAllowedState = @{
            state = "enabled"
            includeTarget = @{
                targetType = "group"
                id = "all_users"
            }
        }
    }
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "MicrosoftAuthenticator" `
    -BodyParameter $params

Habilitando FIDO2 (Passkeys) para um grupo específico

powershell

# Obter o ID do grupo alvo
$groupId = (Get-MgGroup -Filter "displayName eq 'Piloto-FIDO2'").Id
# Habilitar FIDO2 para o grupo
$fido2Params = @{
    "@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    state = "enabled"
    isAttestationEnforced = $true
    isSelfServiceRegistrationAllowed = $true
    keyRestrictions = @{
        isEnforced = $false
        enforcementType = "allow"
        aaGuids = @()
    }
    includeTargets = @(
        @{
            targetType = "group"
            id = $groupId
            authenticationMode = "any"
        }
    )
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2" `
    -BodyParameter $fido2Params

Redefinição de Senha por Autoatendimento (SSPR)

SSPR (Self-Service Password Reset) é um dos recursos mais críticos de qualquer implantação do Entra ID — e também o mais mal configurado.

Ponto crítico: External MFA e TAP não funcionam para SSPR

⚠️ Atenção: Uma pergunta clássica de administradores é: “Posso usar External MFA ou TAP como método de redefinição de senha no SSPR?” A resposta é não. O Entra ID não aceita esses métodos para o fluxo de SSPR.

Os métodos que suportam SSPR são:

• Email OTP (membros do tenant e, em alguns cenários, guests)
• Hardware OATH tokens
• Microsoft Authenticator push notifications
• SMS sign-in
• Software OATH tokens
• Voice call

Configurando SSPR com dois métodos obrigatórios via PowerShell

powershell

# Recomendação: exigir 2 métodos para redefinição de senha
# Isso protege contra ataques de takeover via SSPR
$sspr = @{
    selfServicePasswordResetEnabled = $true
    numberOfMethodsForReset = 2  # Exigir 2 métodos
    authenticationMethods = @(
        "MobilePhone",          # SMS
        "MobileApp",            # Authenticator push
        "Email",                # Email alternativo
        "OfficePhone"           # Ramal (voice call)
    )
    registrationRequired = $true
    registrationReminderInDays = 14
    kickOffEnabled = $true
}
# Via Graph SDK (preview)
# O SSPR é configurado via Update-MgPolicyAuthenticationMethodPolicy
# combinado com a política de registro

Forçando re-registro periódico

powershell

# Exigir que usuários confirmem métodos de autenticação a cada 180 dias
$reregParams = @{
    "@odata.type" = "#microsoft.graph.authenticationMethodsRegistrationCampaign"
    snoozeDurationInDays = 1
    state = "enabled"
    includeTargets = @(
        @{
            id = "all_users"
            targetType = "group"
            authenticationMethod = "microsoftAuthenticator"
        }
    )
}

Recuperação de Conta (Account Recovery)

A recuperação de conta é o cenário mais restrito de todos. Atualmente, apenas o Verified ID oferece suporte a recuperação de conta no Entra ID — e ele funciona de forma diferente dos outros métodos.

O que é Verified ID?

O Microsoft Entra Verified ID é uma solução de identidade verificável (Verifiable Credentials) baseada em padrões W3C. Ele não é um método de autenticação tradicional — é uma prova de identidade. Antes de emitir credenciais verificáveis para recuperação de conta, o usuário passa por um processo de verificação de identidade real (via governo, e-mail, empregador, etc.).

Atenção: Verified ID não pode ser usado para sign-in, MFA ou SSPR. Seu único papel no ciclo de autenticação é a recuperação de conta quando todos os outros métodos estão inacessíveis.

Nenhum método MFA tradicional funciona para account recovery

Isso pega muitos administradores de surpresa: registrar SMS ou Authenticator não habilita o usuário a recuperar a conta autonomamente em cenários de bloqueio total. Para esse cenário, as opções são:

1. TAP (Temporary Access Pass) emitido pelo helpdesk — para desbloqueio manual.
2. Microsoft Entra Verified ID — para fluxo automatizado de recuperação.
3. Contato com o administrador para reset manual.

Métodos Resistentes a Phishing

Com o aumento de ataques de adversary-in-the-middle (AiTM) — em que o atacante intercepta sessões MFA em tempo real — a Microsoft passou a distinguir explicitamente os métodos resistentes ao phishing dos demais.

Métodos phishing-resistant no Entra ID

Métodos que NÃO são phishing-resistant: SMS, Voice call, Email OTP, OATH tokens (hardware e software), Authenticator push (sem passkey). Esses métodos são vulneráveis a ataques AiTM.

Exigindo autenticação phishing-resistant via Conditional Access

powershell

# Criar política de Conditional Access exigindo métodos phishing-resistant
# para acesso a recursos críticos
$caPolicy = @{
    displayName = "Require Phishing-Resistant MFA - Critical Resources"
    state = "enabled"
    conditions = @{
        users = @{
            includeGroups = @("all_users")
            excludeGroups = @("break-glass-accounts")
        }
        applications = @{
            includeApplications = @("MicrosoftAdminPortals")
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator = "OR"
        authenticationStrength = @{
            id = "00000000-0000-0000-0000-000000000004"
            # ID da força "Phishing-resistant MFA" (built-in)
        }
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $caPolicy

Authentication Strengths — personalizando níveis de força

powershell

# Criar uma Authentication Strength personalizada
# que exige FIDO2 ou Windows Hello for Business
$strengthParams = @{
    displayName = "Força-Maxima-AdminPortal"
    description = "Apenas métodos phishing-resistant para portais de administração"
    allowedCombinations = @(
        "windowsHelloForBusiness",
        "fido2",
        "x509CertificateMultiFactor"
    )
}
New-MgPolicyAuthenticationStrengthPolicy -BodyParameter $strengthParams

Como Configurar os Principais Métodos via PowerShell

Habilitando TAP (Temporary Access Pass)

powershell

# Habilitar TAP para todos os usuários
$tapParams = @{
    "@odata.type" = "#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration"
    state = "enabled"
    defaultLifetimeInMinutes = 60
    defaultLength = 8
    minimumLifetimeInMinutes = 10
    maximumLifetimeInMinutes = 480
    isUsableOnce = $false  # true = uso único; false = válido por todo o período
    includeTargets = @(
        @{
            targetType = "group"
            id = "all_users"
        }
    )
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "TemporaryAccessPass" `
    -BodyParameter $tapParams
# Emitir um TAP para um usuário específico
$userId = (Get-MgUser -Filter "userPrincipalName eq 'user@contoso.com'").Id
$newTap = @{
    startDateTime = (Get-Date).ToUniversalTime().ToString("o")
    lifetimeInMinutes = 60
    isUsableOnce = $true
}
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $userId -BodyParameter $newTap

Verificando métodos registrados por usuário

powershell

# Listar todos os métodos de autenticação registrados de um usuário
$userId = "user@contoso.com"
Get-MgUserAuthenticationMethod -UserId $userId | 
    Select-Object Id, @{N="Tipo";E={$_.'@odata.type'}}

Auditando usuários sem MFA registrado

powershell

# Relatório: usuários sem método de autenticação forte registrado
# Requer Microsoft Graph Reports API
$uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails"
$result = Invoke-MgGraphRequest -Uri $uri -Method GET
$result.value | 
    Where-Object { 
        $_.isMfaRegistered -eq $false -and 
        $_.isPasswordlessCapable -eq $false 
    } | 
    Select-Object userPrincipalName, isMfaRegistered, isPasswordlessCapable, 
                  isSsprRegistered, isPasswordPresent |
    Export-Csv -Path "usuarios-sem-mfa.csv" -NoTypeInformation -Encoding UTF8

Monitorando adoção de métodos com Authentication Methods Activity

powershell

# Obter relatório de atividade de métodos de autenticação
$reportUri = "https://graph.microsoft.com/beta/reports/authenticationMethods/usersRegisteredByMethod"
$adoptionReport = Invoke-MgGraphRequest -Uri $reportUri -Method GET
$adoptionReport.value | Format-Table -AutoSize

Campanhas de Registro e Passkeys

As Registration Campaigns (Campanhas de Registro) são o mecanismo pelo qual o Entra ID incentiva (ou exige) que usuários registrem métodos de autenticação mais seguros durante o login.

Como funciona

Quando uma campanha está ativa, após o login bem-sucedido, o usuário vê um prompt solicitando que registre um método mais seguro (ex: passkey no Authenticator). O usuário pode adiar (snooze) por um número configurável de dias — até que o limite seja atingido e o registro se torne obrigatório.

Por que passkeys estão mudando o jogo

As passkeys combinam o que antes exigia dois passos separados (senha + MFA) em um único gesto rápido e seguro:

• Biometria ou PIN do dispositivo autentica o usuário
• A chave criptográfica nunca sai do dispositivo
• Nenhuma senha para vazar em brechas de dados
• Resistente a phishing por design — a chave é vinculada ao domínio

powershell

# Habilitar Registration Campaign para passkeys no Authenticator
$campaignParams = @{
    "@odata.type" = "#microsoft.graph.authenticationMethodsRegistrationCampaign"
    snoozeDurationInDays = 3
    state = "enabled"
    includeTargets = @(
        @{
            id = "all_users"
            targetType = "group"
            authenticationMethod = "passKeyDeviceBound"
        }
    )
}
Update-MgPolicyAuthenticationMethodPolicy -BodyParameter @{
    registrationEnforcement = @{
        authenticationMethodsRegistrationCampaign = $campaignParams
    }
}

Mitos e Correções

❌ Mito 1: “Posso usar External MFA para SSPR”

Correção: External MFA pode ser usado como segundo fator em fluxos de sign-in, mas não é aceito como método de redefinição de senha no SSPR. O Entra ID exige que os métodos de SSPR sejam métodos nativos da plataforma. Isso é uma limitação arquitetural, não uma configuração incorreta.

❌ Mito 2: “TAP pode ser usado para SSPR”

Correção: O Temporary Access Pass (TAP) serve para bootstrap de autenticação — ajuda o usuário a fazer login e registrar novos métodos. Ele não pode ser usado no fluxo de SSPR como método de redefinição de senha. TAP é um substituto temporário do login, não uma credencial de SSPR.

❌ Mito 3: “SMS é um método forte o suficiente como único fator MFA”

Correção: SMS é vulnerável a ataques de SIM swap e SS7 hijacking. A CISA (Cybersecurity and Infrastructure Security Agency) dos EUA recomenda explicitamente que SMS seja considerado o nível mais baixo de MFA. Para cenários críticos, use FIDO2, passkeys ou CBA.

❌ Mito 4: “Habilitar MFA por usuário é equivalente à Authentication Methods Policy”

Correção: A configuração “MFA per-user” (portal legado) e a Authentication Methods Policy (portal moderno) coexistem — mas têm comportamentos distintos. A Microsoft está descontinuando o gerenciamento legado. Organizações que ainda usam o portal antigo podem ter políticas conflitantes sem perceber. Migre para a Authentication Methods Policy unificada.

❌ Mito 5: “Qualquer método MFA é phishing-resistant”

Correção: MFA não é sinônimo de resistência a phishing. SMS, OATH tokens, notificações push tradicionais e voice call são todos vulneráveis a ataques AiTM (adversary-in-the-middle). Somente métodos baseados em FIDO2/WebAuthn, Hello for Business, Platform Credentials e CBA são verdadeiramente resistentes.

❌ Mito 6: “Passkeys sincronizadas são menos seguras que chaves físicas FIDO2”

Correção: Passkeys sincronizadas (ex: iCloud Keychain, Google Password Manager) são resistentes a phishing porque a chave é vinculada ao domínio criptograficamente — mesmo sendo sincronizadas. O modelo de ameaça é diferente de uma chave física (que não pode ser clonada), mas para a maioria dos usuários corporativos passkeys sincronizadas oferecem uma segurança adequada com UX muito superior.

Boas Práticas de Segurança e Governança

1. Migre para a Authentication Methods Policy unificada

Abandone o gerenciamento separado de MFA por usuário e SSPR. A política unificada oferece:

• Controle granular por grupo
• Suporte a todos os métodos modernos
• Integração com Authentication Strengths
• Relatórios centralizados

2. Implante Conditional Access com Authentication Strengths

Não gerencie força de autenticação apenas por método habilitado — use Authentication Strengths para garantir que os recursos certos exijam os métodos certos.

Recursos críticos (portais admin, Azure) → Phishing-resistant MFA
Recursos sensíveis (SharePoint, Teams) → MFA forte (sem SMS)
Aplicações gerais → MFA básico

3. Exija dois métodos para SSPR

Configurar SSPR com apenas um método aumenta o risco de takeover de conta via reset de senha. Exija sempre no mínimo dois métodos diferentes.

4. Use TAP com validade mínima e de uso único para onboarding

powershell

# TAP de uso único, válido por 1 hora
$newTap = @{
    lifetimeInMinutes = 60
    isUsableOnce = $true
}

5. Monitore o relatório de registro de métodos regularmente

Identifique usuários sem MFA, sem SSPR registrado e sem métodos passwordless. Aja proativamente antes que eles precisem de helpdesk.

6. Proteja contas break-glass com métodos físicos

Contas de acesso de emergência (break-glass) devem ter:

• Chaves FIDO2 físicas armazenadas em local seguro
• Excluídas de políticas de Conditional Access
• MFA configurado fora da conta principal (ex: outra conta para TAP)
• Monitoramento de login em tempo real via Sentinel

7. Desative métodos legados onde não forem necessários

Se a organização não usa tokens OATH de hardware, desative-os para reduzir a superfície de ataque. Aplique o princípio do menor privilégio também à authentication surface.

8. Documente a estratégia de autenticação formalmente

Crie e mantenha um documento de Authentication Strategy que descreva:

• Quais métodos são permitidos por nível de sensibilidade
• Processo de onboarding e offboarding de métodos
• Responsáveis por cada tipo de método
• Processo de resposta a incidentes envolvendo autenticação comprometida

Referências do Microsoft Learn

• Authentication methods in Microsoft Entra ID
• Authentication method policies
• FIDO2 security key authentication in Microsoft Entra ID
• Passkeys in Microsoft Authenticator
• Temporary Access Pass in Microsoft Entra ID
• Self-service password reset in Microsoft Entra ID
• Authentication strengths
• Registration campaigns for Microsoft Entra authentication methods
• Microsoft Entra Verified ID overview
• Certificate-based authentication in Microsoft Entra ID
• Phishing-resistant MFA methods and Microsoft Entra ID
• Migrate MFA and SSPR policy settings to the Authentication methods policy

Artigo publicado no Blog Chesley · chesley.com.br Chesley Fernandes — Especialista em Microsoft 365, Entra ID e Segurança de Identidade