Entra ID SSPR Apenas Métodos Registrados a Partir de Novembro 2026: O Que Muda e Como Corrigir

Entra ID SSPR Apenas Métodos Registrados a Partir de Novembro 2026: O Que Está Mudando

A partir de 9 de novembro de 2026, o Microsoft Entra ID SSPR passará a aceitar apenas métodos registrados para a verificação de redefinição de senha — exatamente a mudança que o interesse de busca já rotula como Entra ID SSPR apenas métodos registrados a partir de novembro 2026. As informações de contato provenientes do diretório — os atributos mobilePhone, businessPhone e otherMails, preenchidos via sincronização do Microsoft Entra Connect ou definidos diretamente por um administrador — deixarão de contar como verificação SSPR válida, a menos que o usuário tenha registrado explicitamente esse mesmo número de telefone ou endereço de e-mail como método de autenticação.

Trata-se de um endurecimento discreto, mas de grande impacto. Muitos tenants dependem, há tempos, de atributos de contato sincronizados ou preenchidos por administradores como um fallback implícito do SSPR, já que esses valores permitem que um usuário redefina uma senha esquecida mesmo sem nunca ter passado pelo fluxo de registro de métodos de autenticação da Microsoft — um comportamento que a própria documentação da Microsoft sobre o preenchimento prévio dos dados de contato do SSPR confirma até hoje. Segundo o aviso de lançamento da Microsoft (post do Message Center MC1325414), aproximadamente 86% das verificações de SSPR já usam métodos registrados hoje — o que também significa que uma parcela relevante das redefinições atuais só é bem-sucedida graças a esse fallback que está prestes a ser removido.

A Microsoft está implementando a mudança em duas etapas com datas definidas, confirmadas no artigo do Microsoft Learn citado acima e no post do Message Center MC1325414:

• 5 de outubro de 2026 — uma campanha de registro integrada começa a notificar usuários conectados e administradores que ainda não têm métodos registrados suficientes para concluir o SSPR conforme sua política. Nenhuma ação do administrador é necessária para ativar isso.
• 9 de novembro de 2026 — aplicação da regra: a verificação SSPR passa a aceitar somente métodos explicitamente registrados. Números de telefone e endereços de e-mail do diretório não registrados deixam de funcionar, definitivamente.

O blog do Microsoft Entra descreve isso como o fechamento de uma lacuna de longa data: o SSPR nunca deveria confiar em atributos cuja propriedade ninguém verificou. Um número de telefone sincronizado a partir de um campo local telephoneNumber/mobile, ou digitado no perfil de um usuário por um administrador durante o onboarding, pode estar desatualizado, ter sido reatribuído ou simplesmente estar errado — e, até agora, ainda assim conseguia redefinir a senha desse usuário.

Isso ocorre no meio de uma onda mais ampla de mudanças de autenticação no Entra este ano, ao lado da desativação do MFA por SMS/voz em favor de passkeys e da desativação dos Custom Controls no Conditional Access — nenhuma delas é opcional de ignorar se o seu tenant ainda depende de fallbacks de autenticação legados.

Detecção

Como métodos registrados e não registrados funcionam de forma idêntica no SSPR hoje, não há um evento no log de login que sinalize "esta redefinição usou um método não registrado" — a lacuna só se torna visível se você inventariar diretamente a cobertura de registro, antes da virada em 9 de novembro.

Consulte diretamente com o Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Reports.Read.All"

Get-MgReportAuthenticationMethodUserRegistrationDetail -All `
  -Filter "isSsprEnabled eq true and isSsprCapable eq false" |
  Select-Object UserPrincipalName, IsSsprRegistered, IsSsprCapable, MethodsRegistered

Ou a chamada REST equivalente do Graph:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isSsprCapable eq false and isSsprEnabled eq true

Todo usuário retornado por essa consulta pode redefinir a senha hoje por meio de um atributo do diretório, e não conseguirá fazer isso em 9 de novembro — um pico na central de suporte prestes a acontecer, se não for corrigido antes.

Correção

1. Faça o inventário agora. Extraia o relatório completo de userRegistrationDetails e isole todas as contas habilitadas para SSPR em que isSsprCapable seja false. Priorize contas com funções privilegiadas — um administrador bloqueado do SSPR tem um caminho de recuperação muito mais caro. Nosso guia de auditoria de segurança do Microsoft Entra ID aborda esse relatório junto com o restante da sua postura de MFA e Conditional Access.
2. Registre métodos reais, não cópias do diretório. Peça aos usuários afetados que concluam o fluxo combinado de registro de MFA/SSPR para que um número de telefone ou e-mail seja explicitamente registrado, não apenas presente como atributo de perfil. Registrar mobilePhone como método de autenticação é uma ação única por usuário, não algo automático. Sempre que possível, direcione os usuários para uma passkey como primeiro método registrado em vez de telefone/e-mail, já que ela atende aos requisitos de MFA e de SSPR ao mesmo tempo.
3. Confirme o número de métodos exigidos pela sua política de SSPR. Em Central de administração do Entra → Authentication methods → Password reset properties, verifique quantos métodos sua política exige. Se for um, as lacunas de registro afetam menos pessoas; se forem dois, as lacunas se acumulam.
4. Não dependa apenas da campanha. A campanha de registro de 5 de outubro só avisa usuários que já estão sem métodos — ela não preenche nada retroativamente e pode ser excluída para grupos específicos. Comunique o prazo de 9 de novembro diretamente à sua organização, em vez de presumir que os lembretes automáticos alcançarão todos a tempo.
5. Execute o relatório novamente antes de 9 de novembro. Confirme que isSsprCapable está true para todos os usuários habilitados para SSPR e verifique novamente após o prazo para identificar retardatários antes que liguem para o suporte.

Como a EtcSec Detecta Isso

A auditoria de Entra ID da EtcSec verifica exatamente esse tipo de lacuna de registro. AUTH_METHODS_NO_REGISTRATION sinaliza tenants que não ativaram a campanha de registro de métodos de autenticação da Microsoft, SSPR_NOT_ENABLED sinaliza tenants com o SSPR totalmente desativado, e SSPR_NOT_REQUIRED_ADMINS identifica o caso de maior risco — administradores isentos dos requisitos de registro do SSPR, que perderão o fallback não registrado junto com todos os demais.