Entra ID Custom Controls Descontinuação External Authentication Methods: Guia de Migração Antes de Setembro de 2026

Entra ID Custom Controls Descontinuação External Authentication Methods: O Que Está Mudando e Por Quê

A Entra ID Custom Controls Descontinuação External Authentication Methods já tem prazo definido. Segundo a própria documentação do Microsoft Learn sobre Conditional Access, criar novos custom controls ou editar os existentes deixa de ser possível a partir de setembro de 2026, com a descontinuação total prevista para o início de 2027. Um aviso do Microsoft 365 Message Center, o MC1422061 ("Microsoft Entra ID: Retirement of Custom Controls in Conditional Access and migration to External MFA"), confirma o mesmo bloqueio de setembro de 2026 e fixa a descontinuação total em maio de 2027, quando os custom controls deixam de ser suportados por completo. External Authentication Methods — a capacidade baseada em padrões que a Microsoft agora chama de External MFA — é o único substituto suportado.

Os custom controls nunca foram um recurso mainstream e de disponibilidade geral do Conditional Access — o Microsoft Learn os descreve, desde o início, como "uma capacidade em preview". Quando uma política usava um custom control, o navegador do usuário autenticado era redirecionado para um serviço de terceiros aprovado, completava a autenticação lá e voltava para o Entra ID, que verificava a resposta antes de continuar o fluxo de login. É exatamente essa indireção que está sendo descontinuada: o mesmo resultado — MFA de terceiros aplicado dentro do Conditional Access — agora passa por um método de autenticação nativo e GA, em vez de um handshake de redirecionamento e verificação.

Como os Custom Controls Funcionam — e Por Que o External MFA os Substitui

A descontinuação não é cosmética. A própria orientação de migração da Microsoft lista lacunas funcionais concretas que os custom controls sempre tiveram — lacunas que o External MFA fecha:

Fonte: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access."

A documentação de custom controls do Microsoft Learn traz a mesma lacuna pelo lado oposto: custom controls explicitamente não podem ser usados para satisfazer o requisito automatizado de MFA do Identity Protection, a redefinição de senha self-service do Microsoft Entra, requisitos de claim de MFA, controles de sign-in frequency, ativação de função no PIM, registro de dispositivos no Intune, cross-tenant trust ou device join. Um tenant que depende de um custom control para "MFA" está, na prática, rodando uma imitação que várias outras funcionalidades do Entra sequer reconhecem como MFA — uma lacuna relevante frente aos métodos nativos abordados na nossa análise sobre as mudanças no registro de MFA sem senha.

Também vale destacar uma pegadinha de nomenclatura para não gerar confusão no meio da migração: o substituto foi lançado em preview como "external authentication methods" e depois alcançou disponibilidade geral sob o nome External MFA (External Multifactor Authentication), segundo o anúncio de GA da Microsoft no blog do Entra. O Microsoft Learn, a interface do admin center e os objetos da Graph API (externalAuthenticationMethodConfiguration) ainda usam internamente a terminologia "external authentication method" — portanto espere ver os dois nomes, dependendo de onde você estiver olhando.

Detecção: Encontre Toda Política de Conditional Access Que Usa Custom Controls

Antes de mexer em qualquer coisa, faça o inventário de quais políticas de Conditional Access realmente usam um custom control hoje. Segundo a orientação de migração da Microsoft, isso pode ser feito de duas formas:

Portal: Entre no Microsoft Entra admin center pelo menos como Authentication Policy Administrator, navegue até Protection > Conditional Access > Policies e revise, em cada política, os controles de Grant em busca de uma referência a custom control. Para cada correspondência, registre o nome e o ID da política, os usuários/grupos e cloud apps visados, o provedor do custom control referenciado e quaisquer condições (localizações, plataformas de dispositivo).

Microsoft Graph PowerShell (mais rápido em tenants grandes — a orientação da Microsoft observa que alguns ambientes têm dezenas ou centenas de políticas de Conditional Access para checar):

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

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Fonte: Microsoft Learn, "Migrate from custom controls to external MFA in Conditional Access."

Exporte os resultados antes de começar a migrar. Se uma política não tem referência a custom control, segundo a própria orientação da Microsoft nenhuma ação é necessária nela — não gaste esforço de migração em políticas não afetadas.

Remediação: Migre para External Authentication Methods Antes do Prazo

Com o inventário em mãos, a orientação de migração da Microsoft define um caminho em fases. Primeiro os pré-requisitos: uma licença Microsoft Entra ID P1 ou P2, a função Authentication Policy Administrator (Global Administrator também funciona), Privileged Role Administrator para conceder o admin consent ao aplicativo do provedor, e os metadados do seu provedor de External MFA — o Application ID, o Client ID e a OIDC Discovery URL.

1. Registre o provedor de External MFA. No admin center, vá em Protection > Authentication methods > Policies > Add external method, informe o nome de exibição (não pode ser alterado depois de criado), o Client ID, o App ID e o Discovery Endpoint, e então conceda o admin consent ao aplicativo do provedor. A mesma configuração está disponível via Graph API (POST /policies/authenticationMethodsPolicy/authenticationMethodConfigurations com @odata.type: "#microsoft.graph.externalAuthenticationMethodConfiguration") ou pelo cmdlet do PowerShell New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration, para equipes que automatizam o rollout.
2. Direcione apenas um grupo de teste — não todos os usuários — ao habilitar o método, e registre esses usuários de teste no external authentication method antes de seguir adiante.
3. Construa uma nova política de Conditional Access em modo Report-only usando o grant padrão "Require multifactor authentication" (não o custom control), com o mesmo escopo de cloud apps e condições da política legada, direcionada ao grupo de teste, e excluindo as contas de acesso de emergência e break-glass.

🚨 Perigo: A orientação da Microsoft é explícita ao dizer que o External MFA ainda não é compatível com "Require authentication strength" — apenas o grant padrão "Require multifactor authentication" satisfaz esse requisito. Construir a política de teste sobre um requisito de authentication strength vai falhar silenciosamente em funcionar como esperado.

4. Verifique primeiro em modo Report-only usando a aba Conditional Access dos sign-in logs, confirme que a política é avaliada como esperado e que o método de MFA aparece como o seu provedor externo, depois mude a política para Ativado.
5. Exclua o grupo de teste da política legada de custom control e confirme com a ferramenta What If que só a nova política se aplica a eles, e que os logins de teste são de fato desafiados pelo provedor externo, e não pelo custom control.
6. Faça o rollout em fases — grupo de teste, depois TI/early adopters, depois departamento por departamento, depois todos os usuários — expandindo tanto o grupo-alvo do método de External MFA quanto o escopo da nova política de Conditional Access a cada etapa.
7. Descontinue a política legada por último, não primeiro. Desative (não exclua) a antiga política de custom control e monitore os sign-in logs por uma a duas semanas antes de excluí-la e remover a definição do custom control, mantendo um caminho de rollback disponível caso haja regressões.

Como a EtcSec Detecta Isso

As checagens de Conditional Access da EtcSec expõem exatamente a lacuna que essa descontinuação força à tona: CA_NO_MFA_REQUIREMENT identifica cloud apps e escopos de usuários sem nenhuma política de Conditional Access exigindo MFA de fato — exatamente o estado em que um tenant cai quando uma política de custom control silenciosamente para de funcionar e nada a substitui. MFA_NOT_ENFORCED_ADMINS e MFA_NO_STRONG_METHOD capturam contas privilegiadas e configurações de métodos fracos que um custom control quebrado ou não migrado pode mascarar, já que custom controls nunca foram refletidos como claim nativa de MFA. CA_POLICY_REPORT_ONLY sinaliza políticas — incluindo a política de teste em Report-only recomendada por essa migração — que nunca foram ativadas de fato, para que uma migração pausada não passe despercebida.