Expiração Políticas de Risco Entra ID em Outubro de 2026: Migração para Conditional Access Sem Caminho Automático

Expiração Políticas de Risco Entra ID em Outubro de 2026 Migração para Conditional Access: O Que Está Mudando

A expiração políticas de risco Entra ID em outubro de 2026 migração para Conditional Access é um corte definitivo para os controles originais de resposta a risco do Entra ID Protection. Segundo o Microsoft Learn, as políticas legadas de risco de usuário e risco de login — aquelas configuradas diretamente no próprio dashboard do Identity Protection, não via Conditional Access — "serão desativadas em 1º de outubro de 2026". O rastreador de descontinuações do Microsoft 365 da admindroid cita a mesma data e o mesmo enquadramento: a interface de política de risco de usuário ou de risco de login no Entra ID Protection (antigo Identity Protection) será desativada em 1º de outubro de 2026.

Nenhuma das duas fontes descreve qualquer conversão automática. A orientação de migração da própria Microsoft é totalmente manual: os administradores precisam construir políticas equivalentes baseadas em risco no Conditional Access por conta própria, validá-las, ativá-las e só então voltar e desativar as antigas. Nada na documentação move a configuração de política de risco existente de um tenant para o Conditional Access sozinho.

Por Que "Nenhuma Migração Automática" É a Parte Que Morde

A resposta baseada em risco é um dos poucos controles do Entra ID Protection que age sobre sinais de comprometimento de identidade sem um humano no processo — é o que transforma uma detecção de "usuário de risco" ou "login de risco" em um desafio de múltiplo fator real, uma troca de senha forçada ou um bloqueio. Um tenant que ainda depende da interface de política legada e não faz nada antes da expiração não é migrado de graça: ele perde essa resposta automatizada no momento em que a política legada para de funcionar — a menos que um equivalente em Conditional Access já esteja em vigor.

Esse é um problema mais estreito e mais duro do que "existem detecções de risco, mas ninguém age sobre elas" (a lacuna mais geral do Identity Protection que a EtcSec já cobriu separadamente). Aqui, um tenant pode ter uma política de risco funcionando e aplicada hoje e ainda assim acabar com zero aplicação baseada em risco em 2 de outubro de 2026 — não porque alguém mudou algo, mas porque ninguém mudou.

Detecção: Você Ainda Está no Caminho da Política Legada?

Duas coisas precisam ser verificadas, e o próprio passo a passo de migração do Microsoft Learn mostra exatamente onde:

1. Políticas de risco legadas. No Microsoft Entra admin center, vá em ID Protection → Dashboard e abra os cartões de política de Risco de Usuário e Risco de Login. Se algum mostrar Aplicar política: Ativada, esse tenant ainda depende do tipo de política que será descontinuado.
2. Cobertura baseada em risco no Conditional Access. Vá em Entra ID → Conditional Access → Políticas e verifique se alguma política usa Condições → Risco de usuário ou Condições → Risco de login. Se nenhuma existir — ou se as únicas presentes ainda estiverem em modo somente relatório — não há substituto funcionando ainda, independentemente do que o dashboard legado mostrar.

Um tenant pode falhar em qualquer uma das duas verificações de forma independente: alguns já construíram políticas de risco no Conditional Access e simplesmente esqueceram de desativar as legadas (redundante, não urgente); outros não têm nenhuma das duas, que é a combinação que zera a aplicação baseada em risco na data de expiração.

Correção: Migrando Antes de 1º de Outubro de 2026

O Microsoft Learn documenta um caminho de migração específico, em três etapas:

1. Construa primeiro os equivalentes em Conditional Access, em modo somente relatório. Crie no Conditional Access uma política baseada em risco de usuário e uma baseada em risco de login (manualmente, ou a partir de um modelo de Conditional Access), direcionadas a Todos os usuários, com as contas de acesso de emergência/break-glass excluídas. Se você começar de um modelo, adicione essa exclusão você mesmo assim que a política existir: os modelos da Microsoft excluem apenas a conta que criou a política, não as contas break-glass do tenant. Deixe Ativar política definido como Somente relatório no início.
2. Valide e só então ative as políticas. Use os insights de somente relatório do Conditional Access para confirmar que as novas políticas disparam da mesma forma que as antigas, antes de mudar Ativar política de Somente relatório para Ativada.
3. Desative as políticas legadas. De volta em ID Protection → Dashboard, abra cada política legada de Risco de Usuário e Risco de Login e defina Aplicar política como Desativada — a orientação da Microsoft não chega a recomendar excluí-las, apenas desativá-las.

Para tenants que precisam de ajuda direta, o Microsoft Learn documenta um caminho específico de solicitação de suporte: abrir uma nova solicitação de suporte, descrever o problema como "Migrate legacy ID Protection policy" e selecionar Microsoft Entra Sign-in and Multifactor Authentication → Configuring new or existing policy settings.

Dois assuntos relacionados vale a pena revisar junto com essa migração: as políticas de risco — de login e de usuário, seja vindas do ID Protection ou do Conditional Access — são listadas pela Microsoft como um recurso do Entra ID P2 ou do Microsoft Entra Suite e não estão disponíveis no Free ou P1, e qualquer política nova deveria passar pela mesma disciplina de validação em modo somente relatório que se aplica a todo outro rollout de Conditional Access — uma política deixada indefinidamente em modo somente relatório oferece a mesma aplicação zero de não ter política nenhuma. Também vale revisar a cobertura geral da política baseline de Conditional Access já que você estiver nisso, já que um tenant que está migrando políticas de risco é um tenant que já está auditando sua postura de Conditional Access.

Essa expiração se junta a uma sequência de prazos datados do Entra em 2026 — a aplicação de apenas métodos registrados do SSPR em novembro é outro caso com um corte rígido e sem fallback silencioso — e a lição operacional é sempre a mesma: um aviso de "será desativado" da Microsoft é uma tarefa pendente, não uma migração automática em segundo plano.

Como a EtcSec Detecta Isso

O Azure Audit da EtcSec mede exatamente o que ainda existe depois da expiração: se uma política de Conditional Access ativada realmente carrega uma condição de risco. CA_NO_RISK_BASED_USER e RISK_NO_USER_RISK_POLICY disparam quando nenhuma política de Conditional Access ativada define níveis de risco de usuário; CA_NO_RISK_BASED_SIGNIN e RISK_NO_SIGNIN_RISK_POLICY disparam quando nenhuma define níveis de risco de login. Todos os quatro leem o conjunto de políticas de Conditional Access do tenant — nenhum lê a interface legada de política do ID Protection.

Duas consequências merecem ser ditas com precisão. Primeiro, um tenant cuja resposta a risco vive apenas na interface legada do ID Protection falha nessas verificações hoje, não em 2 de outubro de 2026 — o achado já está no audit, e é exatamente a tarefa de migração que esse prazo cria. Segundo, as verificações só contam uma política no estado enabled: uma política de Conditional Access baseada em risco ainda estacionada em modo somente relatório não as satisfaz, o que é a mesma realidade de aplicação descrita acima.