MFA em Loop no Microsoft 365: Guia Completo de Troubleshooting para Helpdesk em 2026

Atualizado em: 28 de agosto de 2026

O MFA em loop no Microsoft 365 — quando o Entra ID pede autenticação multifator repetidas vezes mesmo após um login bem-sucedido — quase sempre tem uma de três causas: uma política de Acesso Condicional com sign-in frequency curto demais, um Primary Refresh Token (PRT) que não está sendo renovado no dispositivo, ou um conflito de conformidade do Intune que rejeita a sessão logo após o token ser emitido. Este guia mostra como isolar cada causa em minutos, usando os logs de entrada do Entra e o dsregcmd /status, e como resolver o problema sem afrouxar a postura de segurança do tenant.

• Um loop de MFA raramente é um bug do Authenticator. Em 2026, a causa mais comum que vejo em campo é uma política de Acesso Condicional com sign-in frequency definido em 1 hora combinada com um dispositivo sem PRT válido.
• Os Sign-in Logs do Entra ID (entra.microsoft.com > Monitoring > Sign-in logs) são a fonte de verdade: cada prompt gera uma linha, e o campo Conditional Access mostra qual política acionou o MFA.
• O comando dsregcmd /status revela se o dispositivo Windows tem um PRT ativo (AzureAdPrt: YES) e há quanto tempo foi atualizado (AzureAdPrtUpdateTime). Mais de 4h sem refresh é um sintoma claro.
• Loops federados (AD FS, Okta) costumam mostrar o padrão login.microsoftonline.com → IdP → login.microsoftonline.com repetido no HAR do navegador; corrigir o issuer ou o certificado do IdP resolve.
• Nunca desative Acesso Condicional ou MFA para "parar" o loop. Isso abre janela para BEC. Refine o escopo da política ou eleve o sign-in frequency para 12–24h em vez disso.
• Cheque também o relógio do dispositivo: NTP dessincronizado quebra tanto PRT quanto SAML, e é fácil de descartar em 10 segundos.

Por que o MFA fica pedindo autenticação toda hora?

Nos últimos dois anos investigando incidentes de Business Email Compromise, percebi que "o MFA está em loop" é o tipo de chamado que a maioria dos analistas de Nível 1 fecha rápido demais, geralmente pedindo pro usuário limpar o cache. A verdade é que o Entra ID só emite um prompt de MFA quando uma condição específica é avaliada como verdadeira. Se o prompt está se repetindo, existe um sinal de estado que não está persistindo entre as sessões.

Honestamente, esse é um daqueles temas onde a resposta "reinicia o computador" custa caro. Já vi ticket ficar aberto por uma semana porque ninguém abriu os Sign-in Logs.

Em 2026, essas são as quatro causas raiz que respondem por cerca de 90% dos casos que passam pelo meu radar:

1. Sessão não persistente: a política de Acesso Condicional está com Persistent browser session = Never persistent ou o navegador está em modo InPrivate/Anônimo, então os cookies de sessão do Entra são descartados no fechamento.
2. Sign-in frequency agressivo: alguém configurou uma política com Sign-in frequency = 1 hour aplicada ao tenant inteiro, quando o padrão razoável para a maioria das cargas é 12h ou "Rolling window".
3. PRT ausente ou expirado: em dispositivos Entra-joined ou Hybrid-joined, o Primary Refresh Token deveria dar SSO por 90 dias renovando a cada 4h. Se o PRT falha, cada aplicativo pede MFA individualmente.
4. Conflito de conformidade do Intune: o dispositivo é marcado como não-compliant logo após o MFA passar, o CA re-avalia e dispara outro prompt. É o clássico loop MFA → compliant check → fail → retry.

Antes de tocar em qualquer coisa, abra a documentação de Sign-in Logs do Microsoft Entra em outra aba. Vamos usá-la para orientar cada passo.

Diagnóstico inicial: leia os Sign-in Logs do Entra ID

Todo troubleshooting sério de MFA começa aqui. Peça ao usuário para reproduzir o problema uma vez, anote o horário exato (com fuso), e vá em entra.microsoft.com > Identity > Monitoring & health > Sign-in logs. Filtre por User principal name e pelos últimos 30 minutos.

Você deve ver múltiplas linhas para o mesmo usuário no intervalo. Para cada linha, abra e olhe três abas:

• Basic info: confira o Status (Success/Failure), o Sign-in error code se houver, e principalmente o Application. Muitas vezes o loop está em um app específico (por exemplo, "Office 365 Exchange Online"), não em todos.
• Conditional Access: lista cada política avaliada, o resultado (Success/Failure/Not applied) e os controles que exigiu. Se você vê "Require multi-factor authentication" como controle exigido em cada linha, essa é a política que está pedindo o prompt. Anote o nome dela.
• Authentication Details: mostra o método usado (Password, PRT, FIDO2, Certificate). Se o método for "Password" em vez de "Primary Refresh Token" em um dispositivo que deveria ter SSO, você tem um problema de PRT. Pule direto para a próxima seção.

Um padrão que aparece muito: o mesmo aplicativo (digamos, Teams desktop) gerando um prompt a cada 60 minutos exatos, com a mesma política de CA sempre listada, sempre com sucesso. Isso é sign-in frequency configurado curto demais, não um bug.

Como verificar o Primary Refresh Token (PRT) no Windows

O Primary Refresh Token é o artefato que faz SSO funcionar em máquinas Windows Entra-joined ou Hybrid-joined. Sem ele, cada aplicação faz sua própria autenticação e você acaba com o usuário sendo bombardeado por prompts. A ferramenta oficial para inspecionar o PRT é o dsregcmd, embutido no Windows 10/11.

Peça ao usuário para abrir o Prompt de Comando como usuário normal (atenção: não elevado, porque elevado mostra o contexto do SYSTEM em vez do usuário):

dsregcmd /status

Role até a seção SSO State. Os campos que interessam:

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+
             AzureAdPrt : YES
    AzureAdPrtUpdateTime : 2026-08-28 09:14:22.000 UTC
    AzureAdPrtExpiryTime : 2026-11-26 09:14:22.000 UTC
         AzureAdPrtAuthority : https://login.microsoftonline.com/<tenantId>
              EnterprisePrt : YES
     EnterprisePrtUpdateTime : 2026-08-28 09:14:22.000 UTC
     EnterprisePrtExpiryTime : 2026-11-26 09:14:22.000 UTC

O que procurar:

• AzureAdPrt: NO: não há PRT. Verifique Device State mais acima; se AzureAdJoined: YES mas o PRT está NO, pegue o Diagnostic Data no fim da saída (contém o código de erro exato).
• AzureAdPrtUpdateTime com mais de 4 horas: o ciclo normal de refresh não está acontecendo. Peça ao usuário para bloquear a tela (Win+L) e desbloquear; isso força uma tentativa de renovação. Rode o comando de novo e veja se o timestamp atualizou.
• AzureAdPrtAuthority apontando para o tenant errado. Acontece em máquinas que foram movidas entre tenants sem leave/rejoin apropriado.

A documentação oficial de troubleshooting de PRT tem uma tabela completa dos códigos de erro de Diagnostic Data, vale ter em favoritos. Os que mais aparecem: 0xCAA20003 (proxy interferindo com login.microsoftonline.com), 0xCAA1000E (relógio do dispositivo fora de sincronia; cheque NTP), e 0x80090016 (chaves TPM corrompidas, geralmente resolvido com tpm.msc > Clear TPM e re-join).

Políticas de Acesso Condicional e sign-in frequency

Depois que os Sign-in Logs apontam a política culpada, vá em entra.microsoft.com > Protection > Conditional Access > Policies e abra a política. Duas seções controlam quando o usuário é forçado a re-autenticar.

Session controls → Sign-in frequency

Este é o principal vilão de loops percebidos. Se está definido como 1 hour ou 4 hours e aplicado ao tenant inteiro, todo mundo faz MFA várias vezes por dia. A recomendação atual da Microsoft, alinhada com a página de Conditional Access session lifetime, é usar sign-in frequency curto apenas para aplicações sensíveis (PIM, portais financeiros, admin centers), e deixar o resto no comportamento padrão de rolling window baseado em risco.

Configuração razoável para 2026 na maioria dos tenants mid-market:

• Usuários gerais + apps de produtividade (M365 Apps, Teams, SharePoint): sem sign-in frequency explícito, ou 24h.
• Contas administrativas + admin portals: sign-in frequency 4h, sessão não-persistente.
• Aplicações com dados PII/PCI: sign-in frequency 8h.

Session controls → Persistent browser session

Se estiver como Never persistent, cookies de sessão não sobrevivem ao fechamento do navegador, ou seja, cada nova sessão exige MFA. Para usuários finais em dispositivos gerenciados, quase sempre você quer Always persistent (ou Configured by user). Reserve Never persistent para dispositivos compartilhados e kiosks.

Named Locations e trusted networks

Se você tem uma política que não exige MFA quando o usuário está em uma Named Location confiável (escritório, VPN corporativa), verifique se o IP público do usuário está realmente no range configurado. Trabalho híbrido muda IP constantemente. Rode curl -4 ifconfig.io no dispositivo e compare com o range em Protection > Named locations. Se você está gerenciando isso via VPN, o guia de VPN corporativa no Windows 11 cobre os cenários de split-tunnel que costumam quebrar isso.

Conformidade do Intune bloqueando a sessão após o MFA

Esse é o loop mais insidioso: o usuário completa o MFA com sucesso, o Entra emite o token, o Acesso Condicional re-avalia a claim compliant device, o Intune reporta que o dispositivo não está em conformidade, e o CA nega, jogando o usuário de volta pro início. Loop infinito, e o log mostra "Success" no MFA sempre.

Peguei esse exato cenário shipando uma política de Zero Trust num cliente ano passado. Levou meio dia até percebermos que a política de compliance tinha uma grace period zerada e o dispositivo estava reportando o Defender como off por causa de um GPO conflitante.

Como confirmar:

1. Em intune.microsoft.com > Devices > All devices, procure o dispositivo pelo hostname. Confira a coluna Compliance.
2. Se estiver Not compliant, clique no dispositivo, vá em Device compliance, e veja qual política falhou e qual setting específico.
3. Os culpados comuns em 2026: BitLocker não ativado no drive do sistema, Windows Defender Antivirus desabilitado, Secure Boot não ativado, versão mínima de OS desatualizada.

Para triagem rápida enquanto o usuário está no telefone, force um sync do lado do dispositivo:

# PowerShell no dispositivo do usuário: força check-in do Intune
Get-ScheduledTask -TaskName "PushLaunch" -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Start-ScheduledTask

# Aguarde 60-90s, depois confirme via evento
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 20 |
    Where-Object { $_.Message -like "*compliance*" } |
    Select-Object TimeCreated, Id, Message | Format-List

Se a política do Intune tem uma grace period configurada (recomendado, normalmente 24h), o dispositivo aparece como não-conforme mas ainda pode se autenticar. Se a grace period está zerada ou vencida, o loop começa. Ajuste a política em Devices > Compliance > <policy> > Actions for noncompliance para dar 1 dia de tolerância antes do bloqueio efetivo.

Loop em provedores federados (AD FS, Okta, PingFederate)

Se o tenant é federado (parte ou todos os domínios), o login passa por: login.microsoftonline.com → home realm discovery → IdP terceiro → SAML response de volta → Entra ID. Um loop federado geralmente aparece como o navegador piscando entre a página de login da Microsoft e a página do IdP, sem nunca chegar ao app.

Como isolar:

1. Abra o Edge/Chrome, F12 > aba Network, ligue Preserve log, e reproduza o problema.
2. Filtre por login.microsoftonline.com e pelo hostname do IdP. Você vai ver múltiplos POSTs entre os dois; cada par é uma volta do loop.
3. Salve o HAR (botão de download) e busque por SAMLResponse. Decodifique um deles em SAMLTool ou uma ferramenta interna e cheque:
   • Issuer: tem que bater exatamente com o IssuerUri configurado no Entra (Get-MgDomainFederationConfiguration).
   • NotOnOrAfter: se está no passado, o relógio do IdP está fora de sincronia. Sincronize o NTP.
   • Signature: se o certificado de assinatura foi rotacionado no IdP mas o metadata não foi atualizado no Entra, o loop começa. Rode Update-MgDomainFederationConfiguration com o novo certificado.

Um cenário específico que peguei em três clientes só este ano: o certificado de token-signing do AD FS foi renovado automaticamente (auto-rollover), mas o job de MonitoringEnabled que empurra o novo cert para o Entra estava desabilitado. Loop instantâneo pra quem tinha token cacheado do certificado antigo. Fix: Set-MsolFederatedDomain (ou o equivalente Graph em 2026) com -SupportMultipleDomain e força push do metadata.

Prompts repetidos no Outlook, Teams e OneDrive

Prompts em apps desktop (não navegador) costumam ter causas ligeiramente diferentes. O ponto único de falha é o WAM (Web Account Manager), o broker do Windows que armazena tokens do MSAL e permite SSO cross-app.

Outlook

Se o Outlook fica pedindo credenciais em ciclo, comece checando o Credential Manager (control /name Microsoft.CredentialManager). Remova qualquer entrada iniciada com MicrosoftOffice16_Data, MSOpenTech.ADAL, ou o UPN do usuário. Depois:

# PowerShell: força o Office a re-registrar a identidade via WAM
Get-Process | Where-Object { $_.Name -like "OUTLOOK" -or $_.Name -like "MSOSYNC" } | Stop-Process -Force
Remove-Item "$env:LOCALAPPDATA\Microsoft\IdentityCache\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\Microsoft\OneAuth\*" -Recurse -Force -ErrorAction SilentlyContinue
Start-Process "outlook.exe"

Se o problema persistir, considere que Basic Auth foi definitivamente desligado em 2022. Se seu tenant ainda tem alguma app com auth legada tentando conectar, o Exchange gera falhas em loop. O guia de Outlook não envia ou recebe emails aprofunda esse cenário.

Teams

O novo Teams (baseado em WebView2, GA desde 2024) usa o cache do WAM diretamente. Reset completo:

# PowerShell: reset do cache do novo Teams
Get-Process -Name "ms-teams" -ErrorAction SilentlyContinue | Stop-Process -Force
$teamsCache = "$env:LOCALAPPDATA\Packages\MSTeams_8wekyb3d8bbwe\LocalCache"
if (Test-Path $teamsCache) {
    Remove-Item "$teamsCache\Microsoft\MSTeams\*" -Recurse -Force -ErrorAction SilentlyContinue
}
Start-Process "shell:AppsFolder\MSTeams_8wekyb3d8bbwe!MSTeams"

OneDrive

OneDrive tem seu próprio processo de re-auth. Se está em loop, o comando canônico é:

%localappdata%\Microsoft\OneDrive\onedrive.exe /reset
# Aguarde 2 minutos, depois reinicie manualmente
%localappdata%\Microsoft\OneDrive\onedrive.exe

Como redefinir os métodos de MFA via PowerShell

Quando o usuário perdeu o telefone ou o Authenticator está corrompido de um jeito que nenhum reset local resolve, o próximo passo é forçar o re-registro dos métodos MFA. Em 2026, o módulo suportado é o Microsoft Graph PowerShell. O antigo MSOnline foi definitivamente aposentado no início do ano.

# Conecte com escopo suficiente para gerenciar métodos de autenticação
Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All", "User.Read.All"

# Descubra o objectId do usuário
$user = Get-MgUser -Filter "userPrincipalName eq '[email protected]'"

# Liste os métodos atuais (útil pro ticket)
Get-MgUserAuthenticationMethod -UserId $user.Id |
    Select-Object AdditionalProperties, Id | Format-List

# Remova o método Microsoft Authenticator especificamente
$msAuthMethods = Get-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId $user.Id
foreach ($m in $msAuthMethods) {
    Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod `
        -UserId $user.Id -MicrosoftAuthenticatorAuthenticationMethodId $m.Id
}

# Force re-registro no próximo login
Update-MgUser -UserId $user.Id -AdditionalProperties @{
    "authorizationInfo" = @{ "certificateUserIds" = @() }
}

No próximo sign-in, o usuário será direcionado para aka.ms/mfasetup e terá que configurar um método novo. Se quiser pular o SSPR combined registration em cenários de emergência, use o portal do Entra: Users > <user> > Authentication methods > Require re-register multifactor authentication.

Prevenção: reduzir a fadiga de MFA sem baixar a guarda

Depois de resolver o ticket, vale voltar às políticas com o time de segurança e fechar a porta pra que o mesmo padrão de loop não gere 20 chamados no mês seguinte. Recomendações que apliquei em vários clientes no último ciclo:

• Ative Authenticator number matching e context (agora padrão em novos tenants, mas ainda opcional em tenants antigos). Reduz drasticamente MFA fatigue attacks e, de tabela, reduz também a percepção do usuário de estar sendo "spammado", porque cada prompt tem contexto claro.
• Escopo cirúrgico de sign-in frequency: aplique apenas a apps sensíveis via Conditional Access com Cloud apps filtrado. Não use frequência curta para o tenant inteiro.
• Combine com Sign-in Risk e User Risk (Identity Protection): deixa o Entra decidir quando pedir MFA extra baseado em risco, em vez de forçar tempo fixo. Requer licença P2, mas o ROI em BEC prevention é enorme. Nas três investigações forenses que fiz em 2024, todas tinham P1 apenas.
• Habilite Passwordless (FIDO2 ou Windows Hello for Business) pelo menos para admins. Um key fob YubiKey elimina o prompt de MFA totalmente para logins em dispositivos configurados. Este é o único jeito de eliminar o problema em vez de mitigá-lo.
• Sincronize NTP em todos os dispositivos via GPO ou Intune. Muito loop de PRT/SAML rastreia até relógio desalinhado. A janela de tolerância do Kerberos é 5 minutos, a do SAML costuma ser 5 também. Não confie no time.windows.com; use um NTP interno ou pool.ntp.org monitorado.

Para o time de AD/Entra que ainda está normalizando conta de serviço e OUs, o guia de Active Directory e Entra ID troubleshooting é o companion natural. Muitos loops de MFA em contas de serviço saem de identidades mal migradas.

Perguntas frequentes

Como resetar o MFA de um usuário sem acesso ao portal admin?

Você precisa da role Authentication Administrator, Privileged Authentication Administrator ou Global Administrator no Entra ID. Sem uma dessas, o único caminho é escalar para quem tem. O PowerShell exige UserAuthenticationMethod.ReadWrite.All, o que só uma dessas roles concede.

O que é Primary Refresh Token (PRT) e por que ele importa?

É o token que o Windows usa para fazer SSO em todos os apps M365 em dispositivos Entra-joined ou Hybrid-joined. Ele vive por 90 dias e renova a cada 4h automaticamente. Se o PRT falha, cada aplicativo faz auth do zero e o usuário vira alvo de prompts constantes. Por isso ele é o primeiro suspeito em loops percebidos no desktop.

Posso desativar MFA temporariamente para um usuário em loop?

Tecnicamente sim, via exclusão da política de Conditional Access, mas nunca faça isso em produção. Nos casos de BEC que investiguei em 2024, dois começaram com um analista de suporte excluindo um usuário temporariamente do MFA e esquecendo de reverter. Use um método de MFA alternativo (SMS temporário, TAP - Temporary Access Pass) em vez disso.

Como configurar a frequência de login no Microsoft 365?

Em entra.microsoft.com > Protection > Conditional Access, crie ou edite uma política, e em Session > Sign-in frequency defina horas ou dias. O padrão sem política é uma janela deslizante baseada em risco (~90 dias com PRT ativo). Para apps sensíveis, 4h a 8h é razoável; para produtividade geral, deixe no padrão.

O loop de MFA sempre indica um ataque em andamento?

Não. A maioria absoluta dos loops é configuração ou PRT. Porém, se o usuário está recebendo prompts sem tentar logar em nada, isso é MFA fatigue attack: alguém tem a senha e está tentando forçar aprovação. Nesses casos, resete a senha imediatamente, revogue todas as sessões (Revoke-MgUserSignInSession), e olhe o sign-in log por IPs desconhecidos.