Acesso Condicional Registrar Informações de Segurança Windows Hello macOS Platform SSO: Mudança de Escopo (13 de julho de 2026)

Acesso Condicional Registrar Informações de Segurança Windows Hello macOS Platform SSO: O Que Mudou

Acesso Condicional Registrar Informações de Segurança Windows Hello macOS Platform SSO — esse é o trava-língua que os administradores do Microsoft Entra agora precisam conhecer. A partir de 13 de julho de 2026, as políticas de Acesso Condicional direcionadas à ação de usuário Registrar informações de segurança também passam a reger o registro de credenciais do Windows Hello for Business (WHfB) e do macOS Platform Single Sign-on (SSO) — independentemente de essa ter sido a intenção original ao definir o escopo da política. Se o seu tenant restringiu essa ação de usuário de forma estreita — por exemplo, cobrindo apenas a experiência combinada de registro de MFA/SSPR —, o registro de WHfB e macOS Platform SSO agora fica inesperadamente sujeito aos mesmos controles de concessão (Grant). Se o seu tenant excluiu esses fluxos de propósito para manter o provisionamento de dispositivos sem atrito, essa exclusão também deixa de valer: os fluxos agora entram no escopo por padrão.

Antes dessa mudança, o registro do Windows Hello for Business e do macOS Platform SSO simplesmente não avaliava políticas de Acesso Condicional voltadas para Registrar informações de segurança — mesmo que existisse uma política direcionada a essa ação de usuário, ela não era considerada durante o registro de WHfB/Platform SSO. A orientação oficial da Microsoft é explícita sobre o que mudou e o que não mudou:

A Microsoft também confirmou a janela de lançamento e o escopo de impacto na publicação MC1326253 do Message Center, "Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration": o rollout começou em 6 de julho de 2026 e foi concluído em 13 de julho de 2026; tenants sem nenhuma política de Acesso Condicional voltada para Registrar informações de segurança não sofrem nenhuma mudança — a aplicação padrão de MFA para o registro de credenciais sem senha permanece intacta.

Como funciona a aplicação

O mecanismo em si não é novo — é a mesma ação de usuário Registrar informações de segurança que há anos governa a experiência combinada de registro de MFA/SSPR. A novidade é que o provisionamento do Windows Hello for Business e o registro do macOS Platform SSO agora passam pela mesma avaliação de Acesso Condicional. Na prática, após a aplicação, um usuário que registra credenciais do WHfB ou do macOS Platform SSO precisa satisfazer os controles de concessão exigidos pela política correspondente — authentication strength, um local confiável, um método de MFA específico ou conformidade do dispositivo — antes que o registro seja concluído.

Dois detalhes da orientação da Microsoft importam para o seu planejamento:

• Os métodos de autenticação externos atualmente são incompatíveis com authentication strength como controle de concessão para essa ação de usuário — uma lacuna de compatibilidade que ecoa a descontinuação mais ampla dos Custom Controls para métodos de autenticação externos já em curso no Entra. Se a sua política combina Registrar informações de segurança com uma exigência de authentication strength e o seu tenant depende de métodos de autenticação externos, a Microsoft recomenda usar o controle de concessão Exigir autenticação multifator no lugar.
• O Temporary Access Pass (TAP) satisfaz a exigência de MFA do Acesso Condicional para o registro, e é assim que a Microsoft espera que os administradores façam o bootstrap de novos usuários no WHfB/macOS Platform SSO sem cair num problema do tipo "ovo e galinha" (um usuário não consegue satisfazer um controle de concessão de MFA/authentication strength com uma credencial que ainda não registrou). O TAP não funciona para usuários convidados.

Quem é pego de surpresa

Trata-se de uma mudança de escopo, não de uma política nova que você precise criar — e é justamente por isso que é fácil passar despercebida. Vale checar especificamente dois cenários de falha:

1. Política restrita, atrito novo. Uma política com escopo em Registrar informações de segurança e Grant: exigir authentication strength (criada para proteger o registro de MFA/SSPR) agora também se aplica ao WHfB e ao macOS Platform SSO. Um novo funcionário registrando um dispositivo Windows gerenciado fora de uma rede confiável pode ficar bloqueado no meio da configuração, porque ainda não consegue satisfazer a authentication strength exigida pela política — exatamente a lacuna que o Temporary Access Pass existe para fechar.
2. Exclusão deliberada, revertida silenciosamente. Se a sua equipe mantinha de propósito o provisionamento de WHfB/macOS Platform SSO fora do escopo do Acesso Condicional — por exemplo, para não atrasar a implantação zero-touch de dispositivos —, essa exceção deixou de existir a partir de 13 de julho de 2026. O fluxo de registro agora é aplicado por padrão; excluí-lo novamente exige uma mudança explícita.

Leitura relacionada: nossa cobertura sobre a mudança no registro de MFA sem senha e o guia mais amplo sobre lacunas do Acesso Condicional tratam de decisões de escopo adjacentes que vale a pena revisitar junto com este rollout.

Detecção — audite a exposição do seu tenant

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2026-07-06T00:00:00Z and createdDateTime le 2026-07-13T23:59:59Z) and conditionalAccessStatus eq 'failure'

Get-MgAuditLogSignIn -Filter "createdDateTime gt 2026-07-06T00:00:00Z" | Select-Object `
  @{Name="User";Expression={$_.UserDisplayName}}, `
  @{Name="ClientApp";Expression={$_.ClientAppUsed}}, `
  @{Name="CA Result";Expression={$_.ConditionalAccessStatus}}, `
  @{Name="FailureReason";Expression={$_.FailureReason}}, `
  @{Name="Device";Expression={$_.DeviceDetail.DeviceDisplayName}}

Remediation — passos para agir agora

1. Levante todas as políticas com escopo em Registrar informações de segurança e anote seus controles de concessão. Essa é toda a superfície de exposição dessa mudança — nada mais no seu conjunto de políticas de Acesso Condicional é afetado.
2. Rode cada política novamente em modo report-only e revise os resultados de impacto de política antes de presumir que o comportamento não mudou em 13 de julho.
3. Exclua contas de acesso de emergência (break-glass) e contas de serviço/service principals de qualquer política voltada para essa ação de usuário, conforme a recomendação padrão da Microsoft — veja nossa cobertura sobre contas break-glass sobre por que contas de emergência não excluídas são um achado recorrente.
4. Emita um Temporary Access Pass para novos funcionários e reprovisionamento de dispositivos, para que o registro de WHfB/macOS Platform SSO não esbarre no problema de "ovo e galinha" da authentication strength. O TAP satisfaz a exigência de MFA do Acesso Condicional para o registro — mas não funciona para usuários convidados.
5. Não combine métodos de autenticação externos com um controle de concessão de authentication strength obrigatório nessa ação de usuário; use Exigir autenticação multifator no lugar, conforme o aviso explícito de incompatibilidade da Microsoft.
6. Atualize a documentação do helpdesk sobre os novos prompts de autenticação que os usuários podem ver no meio da configuração — essa foi a própria recomendação da Microsoft na MC1326253, e é a forma mais barata de reduzir chamados de suporte de novos funcionários confusos. Nosso guia de auditoria do Entra ID mostra onde as revisões de escopo do Acesso Condicional se encaixam numa revisão mais ampla do tenant.

Como a EtcSec detecta isso

As verificações de Acesso Condicional da EtcSec sinalizam exatamente as configurações incorretas que transformam esse rollout de um não-evento em uma interrupção: CA_POLICY_REPORT_ONLY identifica políticas deixadas em modo report-only que os administradores acreditam estar aplicando (de modo que a mudança de 13 de julho foi testada, mas nunca realmente ativada), CA_NO_BREAK_GLASS_EXCLUSION identifica contas de acesso de emergência que não estão excluídas de uma política de Registrar informações de segurança — agora um risco de lockout no registro, não apenas no login — e CA_EXCESSIVE_EXCLUSIONS sinaliza políticas cujas listas de exclusão cresceram tanto que o estreitamento de escopo trazido por esse rollout se torna, na prática, irrelevante.