Desafios e Soluções na Implantação de Chaves de Acesso Corporativas

1. Introdução: a realidade operacional das chaves de acesso corporativas para funcionários#

As chaves de acesso (passkeys) chegaram à força de trabalho. A pergunta não é mais "a tecnologia funciona?". A pergunta agora é "como operamos isso em escala?". Os pontos de atrito mudaram para a camada operacional: o problema "do ovo e da galinha" do registro inicial (bootstrapping), a diferença entre chaves de acesso vinculadas a dispositivos e sincronizadas, interoperabilidade multiplataforma e mecanismos de recuperação que não revertem para a insegurança de uma senha.

Este guia aborda os desafios do mundo real na implantação de chaves de acesso em ambientes Microsoft Entra ID, cobrindo armadilhas de configuração, fluxos de trabalho operacionais e estratégias de recuperação. Especificamente, vamos responder às seguintes perguntas:

1. Qual é a diferença entre chaves de acesso vinculadas a dispositivos e sincronizadas no Entra ID?
2. Como faço a configuração inicial (bootstrap) de chaves de acesso para novos funcionários sem senhas?
3. Como os usuários recuperam o acesso quando trocam de telefone e perdem o autenticador?
4. Quais erros de configuração causam falhas no registro de chaves de acesso?
5. Como lido com convidados B2B ao exigir MFA resistente a phishing?
6. Devo usar chaves de segurança de hardware (YubiKeys) ou chaves de acesso móveis?
7. Como gerencio dispositivos macOS junto com Windows em uma implantação de chaves de acesso?
8. Quais medidas proativas evitam a sobrecarga do suporte de TI devido à troca de telefones?

2. Entendendo as chaves de acesso no Microsoft Entra#

No Entra, "chaves de acesso" = credenciais FIDO2/WebAuthn. Em vez de uma senha, o usuário prova a posse de uma chave privada armazenada em um autenticador. É resistente a phishing porque o WebAuthn vincula a credencial à origem de login real (para que um site de phishing semelhante não possa repeti-la). Veja a visão geral da Microsoft na documentação de conceitos de Passkeys (FIDO2).

Na prática, o Entra suporta dois "modos" de chaves de acesso que se comportam de maneira diferente.

2.1 Chaves de acesso vinculadas a dispositivos no Entra#

Estas chaves de acesso estão vinculadas a um dispositivo físico (não sincronizáveis). A chave privada existe em um elemento de hardware específico (TPM em um laptop, Elemento Seguro em uma YubiKey). Ela é não exportável.

No Entra, a história das credenciais vinculadas a dispositivos geralmente se traduz em:

• Chaves de acesso do Microsoft Authenticator
• Chaves de acesso do Windows Hello ou Windows Hello for Business (WHfB) (não sincronizadas a partir de janeiro de 2026)
• Chaves de segurança FIDO2 (chaves de hardware como YubiKeys)
• Smartcards

A documentação base da Microsoft para configuração de chaves de acesso vinculadas a dispositivos pode ser encontrada aqui: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Casos de uso: Acesso de alto privilégio, contas de emergência ("break-glass"), ambientes de estações de trabalho compartilhadas. Desvantagem: Alto atrito. A perda do dispositivo significa a perda da credencial. Alto custo operacional (por exemplo, envio de YubiKeys).

2.2 Chaves de acesso sincronizadas no Entra#

Estas são chaves de acesso armazenadas em um ecossistema de provedor e sincronizadas nos dispositivos do usuário (por exemplo, iCloud Keychain, Google Password Manager ou provedores de terceiros). A chave privada é criptografada e armazenada na infraestrutura de sincronização de um provedor de nuvem.

A partir de janeiro de 2026, no Entra, as chaves de acesso sincronizadas são tratadas por meio do recurso de visualização: Chaves de acesso sincronizadas (visualização). Para habilitar e controlar chaves de acesso sincronizadas, o Entra usa Perfis de Chave de Acesso (visualização).

Adequação regulatória: Recentemente validado pelo Suplemento 1 do NIST SP 800-63B como atendendo aos requisitos AAL2. Esta é uma grande vitória regulatória, validando que as chaves de acesso sincronizadas são "resistentes a phishing" o suficiente para uso geral da força de trabalho.

Casos de uso: Trabalhadores do conhecimento, usuários BYOD (Traga Seu Próprio Dispositivo), conveniência executiva. Desvantagem: Garantia "menor" do que o hardware. Dependência da segurança do fluxo de recuperação de conta do provedor de nuvem.

Aqui você encontra uma visão geral dos provedores de chaves de acesso sincronizadas suportados pelo Entra:

Na página de Informações de Segurança de um usuário, as chaves de acesso sincronizadas e vinculadas a dispositivos são claramente distinguidas. Abaixo, você pode ver como uma chave de acesso sincronizada (do 1Password) e uma chave de acesso vinculada a um dispositivo (YubiKey 5C NFC) aparecem:

2.3 Alinhamento regulatório: níveis AAL do NIST#

• Historicamente, o AAL3 exigia autenticadores baseados em hardware e vinculados a dispositivos (como YubiKeys ou Smart Cards) que utilizam uma chave privada não exportável.
• O AAL2 agora pode ser alcançado com chaves de acesso sincronizadas, conforme as diretrizes do NIST.
• Nuance: Embora as chaves de acesso sincronizadas (como as do iCloud) sejam excelentes para usuários padrão, elas podem não atender estritamente ao requisito de "não exportabilidade" do AAL3 para os níveis de privilégio mais altos. Portanto, uma estratégia segmentada é necessária: chaves de hardware para administradores (AAL3), chaves de acesso sincronizadas para a força de trabalho (AAL2).

2.4 Requisitos de prontidão do dispositivo#

Para garantir que os dispositivos estejam preparados para a autenticação sem senha resistente a phishing, eles devem executar estas versões mínimas:

Sistemas operacionais mais antigos podem exigir autenticadores externos (chaves de segurança FIDO2) para suportar a autenticação sem senha resistente a phishing.

Além dos requisitos de versão mínima, o suporte a recursos no lado do navegador também varia de acordo com a plataforma. De acordo com a análise de recursos de cliente WebAuthn do Corbado Passkey Benchmark 2026, o suporte no 1º trimestre de 2026 fica entre 97–100% para Conditional Get e Hybrid Transport, mas apenas 83–92% para Conditional Create em um mix típico de navegadores de consumidores — uma restrição que afeta mais o Windows, porque o Windows Hello não é um caminho de Conditional Create, e o Edge, especificamente, relata suporte muito baixo para Conditional Create no mesmo conjunto de dados. O benchmark cobre implantações B2C voltadas para o consumidor em vez de ambientes corporativos, mas os mesmos tetos de recursos de navegador/SO subjacentes ainda se aplicam às implementações do Entra ID; populações corporativas com uso intenso de Edge podem ficar materialmente abaixo da faixa combinada de 83–92% do Conditional Create.

2.5 Recomendações de credenciais baseadas em persona de usuário#

A Microsoft recomenda uma abordagem baseada em persona de usuário para implantação de credenciais. Funções diferentes têm requisitos de segurança e níveis de atrito aceitáveis diferentes:

Credenciais portáteis (podem ser usadas em vários dispositivos):

Credenciais locais (específicas do dispositivo):

O objetivo final: A maioria dos usuários deve ter pelo menos uma credencial portátil, além de credenciais locais em cada dispositivo de computação.

3. Experiências de implantações reais de chaves de acesso#

Ao conversar com organizações que implantaram chaves de acesso, alguns pontos de atrito e padrões reais são reconhecidos.

3.1 Mudança operacional#

"Os desafios não estão na pilha de tecnologia, mas na camada operacional." Isso confirma que os obstáculos técnicos como erros de "Chave de acesso não registrada" ou a invisibilidade das opções do Windows Hello em dispositivos pessoais não são anomalias exclusivas, mas pontos de atrito sistêmicos inerentes à maturidade atual do ecossistema. Para operações corporativas, a chave é separar as falhas esperadas das inesperadas no monitoramento. Agrupe os erros de WebAuthn explicitamente e rastreie NotAllowedError, AbortError e erros de chave de acesso do Credential Manager como sinais distintos. Nosso manual de análises de autenticação fornece uma estrutura para classificar esses sinais, e as análises de chaves de acesso cobrem KPIs específicos, como taxas de ativação e login.

3.2 Registro: o momento decisivo#

O registro é a fase mais difícil da implantação, exigindo um gerenciamento de mudança significativo.

• Complexidade do pré-registro: Integrar novos funcionários que não têm credenciais anteriores é o principal gargalo. A dependência do registro mediado pelo administrador cria uma experiência de usuário desconectada.
• Fragmentação de plataforma: "Frustração do usuário com os passos" devido a iterações independentes de navegadores, Sistemas Operacionais e gerenciadores de senhas. Isso leva a inconsistências temporárias em que um fluxo funciona no Chrome/Windows, mas falha no Safari/macOS ou falha em dispositivos pessoais não gerenciados enquanto tem sucesso nos corporativos.

3.3 Lacuna de modelo mental#

"Os usuários não precisam de criptografia, eles precisam de um modelo mental". A confusão terminológica cria carga cognitiva:

• Chave de acesso (Passkey)
• Chave de segurança
• Chave de hardware
• YubiKey
• Sem senha (Passwordless)
• Segurança do Windows
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Login pelo telefone

Para usuários com menos conhecimento tecnológico, ou mesmo aqueles mais experientes, as diferenças entre esses termos muitas vezes não são óbvias.

Recomendamos evitar jargões como "resistente a phishing" ou "par de chaves" nas comunicações com os usuários finais. Em vez disso, concentre-se no conceito de "desbloqueio": "Use seu rosto para desbloquear os sistemas da empresa," analogamente a desbloquear o telefone.

3.4 Limitações de comunicação#

A adoção forte no início é crítica para o sucesso, mas a comunicação tem seus limites. Você não pode enviar e-mails regulares pedindo aos usuários que verifiquem seus métodos de autenticação. Em geral, você não pode planejar bem o comportamento do usuário. Essa realidade impulsiona a necessidade de medidas técnicas proativas, em vez de depender apenas da educação do usuário.

4. Análise aprofundada da configuração do Microsoft Entra ID#

Implantar chaves de acesso em um ambiente corporativo exige compreender e configurar políticas interdependentes. Chaves de acesso não são apenas um recurso que você pode simplesmente ativar, pois têm um enorme impacto em cada funcionário em seu trabalho diário.

4.1 Política de métodos de autenticação#

Os portais herdados de MFA e SSPR foram descontinuados. Toda a configuração FIDO2 deve ocorrer na seção unificada de Política de Métodos de Autenticação.

• Método de Chave de Segurança FIDO2: Isso deve ser ativado e direcionado. Recomenda-se direcionar "Todos os Usuários" para habilitação, mas controlar a aplicação (enforcement) via Acesso Condicional.
• Restrições de Chave (AAGUIDs): Todo dispositivo FIDO2 (por exemplo, YubiKey 5 NFC, Microsoft Authenticator no iOS, Google Password Manager) possui um Autenticador Attestation GUID (AAGUID) exclusivo. Como prática recomendada para ambientes de alta segurança, utilize a configuração "Impor Restrições de Chave" para Permitir apenas AAGUIDs específicos e aprovados. Isso evita que os usuários registrem chaves de segurança baratas e não verificadas do "mercado cinza".

4.2 Atestado: o ponto de decisão crítico#

Uma das decisões de configuração mais significativas é "Impor Atestado" (Enforce Attestation).

• O que faz: Força o autenticador a provar criptograficamente sua marca e modelo ao Entra ID durante o registro.
• Conflito: Chaves de acesso sincronizadas (armazenadas em provedores de software como iCloud Keychain, Bitwarden ou Google Password Manager) geralmente não suportam atestado porque são baseadas em software e agnósticas à plataforma. Elas não podem assinar um desafio com um certificado de lote de hardware.
• Compensação:
  • Definido como SIM: Exigido para alta garantia (AAL3). Garante que a chave esteja vinculada ao hardware. Bloqueia provedores de chaves de acesso baseados em software.
  • Definido como NÃO: Permite chaves de acesso sincronizadas. Reduz um pouco a garantia (AAL2). Permite provedores de chaves de acesso baseados em software.

Você não pode aplicar uma política global de "Sem Atestado" se tiver administradores de alto privilégio que exigem chaves de hardware. Você deve usar os Perfis de Chave de Acesso (Visualização):

• Perfil A (Administradores): Impor Atestado = Sim
• Perfil B (Equipe Geral): Impor Atestado = Não

4.3 Perfis de chave de acesso explicados#

Pense nos Perfis de Chave de Acesso como o mecanismo para definir:

• "Esses usuários podem usar chaves de acesso sincronizadas"
• "Esses usuários devem usar apenas chaves vinculadas a dispositivos"
• "Atestado exigido vs não exigido" (e, portanto: chaves de acesso sincronizadas permitidas vs excluídas)
• "Restringir a certos tipos de autenticador (restrições AAGUID)"

Abaixo você pode ver a página de configurações de Chaves de acesso (FIDO2) no centro de administração do Microsoft Entra onde você configura os perfis de chave de acesso:

Ao editar um perfil de chave de acesso, você pode configurar a imposição de atestado, tipos de alvo (vinculado a dispositivo, sincronizado ou ambos) e restrições específicas de AAGUID:

4.4 Acesso Condicional e forças de autenticação#

A imposição pode ser gerenciada por meio de políticas de Acesso Condicional (CA) utilizando as Forças de Autenticação (Authentication Strengths).

• Força MFA Resistente a Phishing: Esta força nativa exige FIDO2, Windows Hello for Business (WHfB) ou Autenticação Baseada em Certificado (CBA).
• Armadilha de Bloqueio: Se você criar uma política de CA que exige "MFA Resistente a Phishing" para "Todos os Aplicativos em Nuvem" e aplicá-la a "Todos os Usuários", você bloqueará imediatamente todos os usuários que ainda não registraram uma chave de acesso. Eles não conseguirão sequer fazer login para registrar uma.
• Paradoxo de "Registrar Informações de Segurança": Esta é uma Ação de Usuário específica em CA. Se você exigir MFA Resistente a Phishing para realizar a ação de Registrar Informações de Segurança, você cria uma dependência circular (o ovo e a galinha). Um usuário não pode registrar sua primeira chave de acesso porque ele precisa de uma chave de acesso para entrar na página de registro.

Aqui está uma visão geral de quais métodos de autenticação satisfazem quais requisitos de força:

4.5 Autenticação preferencial do sistema#

O recurso de "Autenticação multifator preferencial do sistema" do Entra ID força o mecanismo de login a solicitar ao usuário o método registrado mais seguro.

Se um usuário tem SMS e uma chave de acesso registrados, o sistema adotará por padrão a chave de acesso. Isso impulsiona a adoção de chaves de acesso organicamente sem imposição rígida. Na essência, ele "atualiza" a postura de segurança do usuário automaticamente assim que ele registra a credencial.

Abaixo, você pode ver a experiência de login da chave de acesso. O usuário é solicitado a usar "Rosto, impressão digital, PIN ou chave de segurança" e pode selecionar sua chave de acesso em uma extensão de navegador ou gerenciador de credenciais do sistema:

4.6 Considerações sobre o macOS: Platform SSO#

Para organizações com ambientes mistos de Windows/macOS, o Platform SSO do macOS fornece o equivalente da Apple ao Windows Hello for Business. Combinado com soluções MDM, você pode obter:

• Credenciais vinculadas ao dispositivo atreladas ao Secure Enclave do Mac
• Experiência de SSO em aplicativos nativos e aplicativos web
• Autenticação resistente a phishing que atende aos requisitos AAL2/AAL3

Nota: O Platform SSO do macOS exige macOS 13+ e configuração adequada de MDM. A configuração difere significativamente do WHfB do Windows, portanto planeje trilhas de implantação separadas.

5. Erros de configuração comuns: por que "só funciona com o Microsoft Authenticator"#

Se seu objetivo são as chaves de acesso sincronizadas em dispositivos não gerenciados, estes são os bloqueadores mais comuns:

5.1 Chaves de acesso sincronizadas não habilitadas/direcionadas#

Não é suficiente apenas habilitar o "FIDO2" de forma geral no Entra. Para chaves de acesso sincronizadas você tipicamente precisa de:

• O caminho do recurso de visualização descrito em Chaves de acesso sincronizadas (visualização)
• Uma configuração de perfil utilizando os Perfis de Chave de Acesso

Se um grupo não é alvo de um perfil que permite chaves de acesso sincronizadas, você voltará a ficar restrito apenas às opções "vinculadas a dispositivos".

5.2 Atestado imposto (bloqueia chaves de acesso sincronizadas)#

Isto causa a maior parte das dúvidas em organizações focadas em segurança:

• O Entra pode exigir atestado para alguns cenários de chaves de acesso (ajuda a validar o tipo/procedência do autenticador)
• As chaves de acesso sincronizadas não suportam atestado no Entra, então se o atestado for imposto, o registro das chaves de acesso sincronizadas falhará e você acabará apenas com as opções vinculadas a dispositivos

5.3 Lista de permissões de AAGUID bloqueia provedores#

O Entra permite que você restrinja quais autenticadores são permitidos (muitas vezes por meio de listas de permissão/bloqueio de AAGUID). Se você permitir apenas o Microsoft Authenticator (ou um conjunto restrito de autenticadores), provedores sincronizados de terceiros podem ser implicitamente bloqueados. A parte confusa é que a autenticação local (por exemplo, Touch ID, Face ID, biometria do Windows) funciona, mas a página de login do Entra exibe um erro em seguida.

5.4 Acesso Condicional força certos tipos de chaves de acesso#

Mesmo se as chaves de acesso estiverem habilitadas, o Acesso Condicional pode efetivamente forçar os usuários a usar um subconjunto de métodos (por exemplo, "Apenas Authenticator" ou uma configuração de força que não permite o perfil de chave de acesso pretendido). Na prática, isso cria a "dependência do Authenticator" mesmo quando o plano são chaves de acesso sincronizadas.

5.5 Contas de convidados B2B vs membros#

Se parceiros externos são usuários convidados B2B em um locatário de recurso (resource tenant), existem limitações conhecidas sobre onde/como eles podem registrar métodos de autenticação. Este é frequentemente o "por que não funciona" oculto quando a intenção é "parceiros usam chaves de acesso em nosso locatário".

6. Desafios operacionais e soluções#

6.1 O paradoxo da configuração inicial (bootstrapping)#

O problema mais difundido ("O registro é a parte mais difícil") é o problema de inicialização: Como emitir com segurança uma credencial de alta garantia para um usuário que atualmente não tem credenciais (ou apenas tem as de baixa garantia)?

6.1.1 Passe de Acesso Temporário (Temporary Access Pass - TAP)#

O Passe de Acesso Temporário (Temporary Access Pass) é uma abordagem arquitetônica para a integração sem senha.

• O que é: Uma senha por tempo limitado (ex: 1 hora), de alta entropia que o Entra ID trata como um método de "autenticação forte". Isso elimina a necessidade de uma senha ou MFA existente.
• Fluxo de trabalho:
  1. Verificação de Identidade: A identidade do novo funcionário é verificada (ex: via processo de RH ou verificação do Gerente).
  2. Emissão: Um administrador (ou Logic App automatizado) gera um TAP para o usuário.
  3. Login "Mágico": O usuário acessa aka.ms/mysecurityinfo. Ele insere seu nome de usuário e o TAP.
  4. Registro: Como o TAP satisfaz o requisito de "Autenticação Forte", o usuário tem permissão para acessar a seção de Informações de Segurança. Ele clica em "Adicionar Método" e registra sua chave de acesso.
  5. Estado Estável: O TAP expira. O usuário agora possui uma credencial resistente a phishing. Ele nunca digitou uma senha.

6.1.2 Automação via API do Graph#

Para grandes organizações, a emissão manual de TAP não é escalável. A melhor prática é automatizar via Microsoft Graph API.

• Cenário: Uma nova contratação é processada no sistema de RH (Workday/SuccessFactors).
• Gatilho: O evento de provisionamento dispara um Azure Logic App.
• Ação: O Logic App chama a API do Graph via POST /users/{id}/authentication/temporaryAccessPassMethods.
• Entrega: O TAP é entregue com segurança ao gerente de contratação do usuário ou por e-mail pessoal (criptografado) para o acesso no primeiro dia.

6.1.3 Microsoft Entra Verified ID para integração de alta garantia#

Para integração remota ou cenários que exigem alta garantia de identidade, o Entra Verified ID da Microsoft com o Face Check oferece um caminho de registro primariamente sem senhas:

1. Comprovação de identidade: Novo usuário verifica a identidade por meio de um parceiro de IDV (digitalização de ID governamental).
2. Correspondência biométrica: O Face Check compara uma selfie ao vivo com a foto do documento de identidade usando o Azure AI Vision. Apenas uma pontuação de confiança na correspondência é compartilhada (sem dados biométricos brutos).
3. Credencial verificada emitida: O usuário recebe uma credencial do Verified ID.
4. Emissão do TAP: Após a verificação bem-sucedida, o sistema emite um Passe de Acesso Temporário.
5. Inicialização da chave de acesso: O usuário registra sua primeira chave de acesso usando o TAP.

O fluxo do Face Check guia os usuários através de três etapas: Verificar (compartilhar credenciais), Confirmar (executar a digitalização facial) e Revisar (ver o resultado da correspondência):

Esse fluxo permite contas verdadeiramente sem senha desde o primeiro dia. Nenhuma senha é criada em nenhum momento.

6.2 O problema de troca de telefone (o desafio oculto de escala)#

Esta é frequentemente a maior fonte de chamadas de helpdesk nas implantações de chaves de acesso. Organizações com grandes populações BYOD (por exemplo, mais de 10.000 dispositivos) podem ver um número enorme de chamadas de suporte apenas por usuários que compram telefones novos e não conhecem o processo para registrar novamente os métodos de autenticação.

Quando você introduz as chaves de acesso na mistura, isso se torna ainda mais crítico porque:

• Usuários instalam aplicativos (como o Outlook) no telefone novo
• Estes aplicativos solicitam autenticação
• O prompt de MFA aparece no telefone antigo (que eles já podem ter trocado ou apagado)
• O usuário fica bloqueado e liga para o helpdesk

6.2.1 Matriz de cenários para substituição de telefone#

O objetivo é mudar o máximo de casos possível para as duas primeiras linhas, minimizando o envolvimento do helpdesk.

6.2.2 Truque de inscrição no Intune#

Um insight inteligente: Exigir uma chave de acesso para o registro no Intune força os usuários a concluírem a configuração do Microsoft Authenticator em seus novos telefones imediatamente - antes que possam acessar aplicativos corporativos.

• Hoje: O registro no Intune requer step-up de MFA. Isso significa que, se você quiser fazer login em um telefone novo, você instala o Outlook lá. No entanto, a solicitação de MFA vai para o telefone antigo.
• Com o requisito da chave de acesso: Os usuários devem configurar as chaves de acesso do Microsoft Authenticator no novo telefone primeiro para concluir o registro. Isso acontece rapidamente (no dia da troca do telefone), em vez de meses depois, quando o telefone antigo já se foi.

Isso não resolve a recuperação, mas muda a linha do tempo. Os usuários registram seu novo dispositivo enquanto ainda têm acesso ao antigo.

6.3 Chaves de segurança de hardware vêm com problemas de logística#

Chaves de hardware (YubiKeys, etc.) às vezes são posicionadas como a solução universal. Em teoria, elas são, mas o mundo real mostra mais desafios:

• Pesadelo logístico: Organizações que implantaram tokens físicos no passado (como o RSA SecurID) muitas vezes passaram anos tentando eliminá-los. Substituir um programa de token físico por outro não é atraente.
• Envio direto: A Yubico pode enviar as chaves diretamente aos usuários e elas não precisam de substituição de bateria a cada poucos anos (ao contrário do SecurID). Mas se alguém esquece a sua chave, não consegue iniciar a sessão (em áreas de trabalho compartilhadas).
• Carga local de TI: Supervisores locais não devem se tornar suporte de TI de fato para chaves esquecidas.
• Custo: Chaves de hardware adicionam um custo por usuário que escala com o número de funcionários.

Quando chaves de hardware fazem sentido:

• Administradores Tier 0: Administradores de domínio, contas "break-glass"
• Estações de trabalho compartilhadas: Ambientes de quiosque, chão de fábrica, tablets de campo
• Terceirizados sem BYOD: Usuários externos que não usarão dispositivos pessoais

6.4 Desafios de dispositivos não gerenciados#

Muitos usuários reclamam que não conseguem ver as opções de uso de chaves de acesso em um dispositivo pessoal. Este é um ponto de atrito clássico de "dispositivo não gerenciado".

6.4.1 Análise de erro "Chave de acesso não registrada"#

Os usuários podem não conseguir adicionar chaves de acesso em um dispositivo pessoal, enquanto funciona em um dispositivo corporativo. Isso se deve provavelmente à interação das Políticas de Conformidade do Intune com o fluxo de registro.

• Mecanismo: O Windows Hello for Business (WHfB) é uma credencial de plataforma. Ela é vinculada ao TPM do dispositivo específico (chave de acesso vinculada ao dispositivo).
• Restrição: Para registrar o WHfB, o dispositivo geralmente deve estar associado (Entra Joined ou Hybrid Joined) ao locatário. Um dispositivo pessoal que está apenas "Registrado" (Workplace Joined) pode ter restrições de política aplicadas via Intune que bloqueiam o provisionamento de contêineres do WHfB se o dispositivo não for totalmente gerenciado ou compatível. Veja os requisitos de login por chave de segurança FIDO2.
• Opção de "Chave de acesso": Em um dispositivo pessoal, o usuário deveria tentar registrar uma Chave de Segurança FIDO2 (roaming) ou uma Chave de Acesso entre Dispositivos (no telefone dele), não o Windows Hello for Business (a menos que a inscrição BYOD seja totalmente suportada).
• Problema de visibilidade do Entra ID: Se o "Windows Hello" não aparecer como uma opção, o dispositivo não concluiu a inscrição MDM que é pré-requisito.

6.4.2 Falhas de Autenticação entre Dispositivos (CDA)#

Em dispositivos não gerenciados, os usuários costumam tentar o fluxo de Autenticação entre Dispositivos (CDA) (digitalizando um código QR no PC com o telefone).

• Dependência de Bluetooth: O CDA requer que o Bluetooth esteja habilitado tanto no PC quanto no telefone. Eles não precisam emparelhar, mas devem realizar um handshake de Bluetooth Low Energy (BLE) para provar a proximidade. Revise as informações sobre chaves de acesso vinculadas a dispositivos no Microsoft Authenticator para detalhes.
• Bloqueio por Política Corporativa: Se o Bluetooth estiver desativado em laptops corporativos via BIOS ou GPO por "segurança", você já quebrou o mecanismo primário para chaves de acesso em roaming.
• Bloqueio de Websocket: O fluxo de CDA usa uma conexão de websocket com cable.ua5v.com ou cable.auth.com. Firewalls corporativos agressivos ou configurações de Zscaler geralmente bloqueiam esses domínios, fazendo com que a leitura do código QR trave ou falhe silenciosamente. Veja a documentação da chave de acesso do Microsoft Authenticator.

6.5 B2B e identidades externas#

Outro ponto de dor para as empresas é lidar com consultores externos (convidados B2B).

• Problema: Um consultor tenta acessar um site do SharePoint. O locatário impõe uma política de Acesso Condicional exigindo "MFA Resistente a Phishing".
• Falha: O consultor tenta registrar uma chave FIDO2 no locatário do recurso. Isso falha. O Entra ID não oferece suporte a usuários convidados registrando chaves FIDO2 no locatário de recurso.
• Correção: Configurações de acesso entre locatários
  • Lógica: Em vez de forçar o convidado a registrar uma credencial no seu locatário, você deve confiar na credencial que eles usam em seu locatário de origem.
  • Configuração: Vá para Identidades Externas > Configurações de acesso entre locatários. Selecione a organização parceira. Em Confiança de Entrada, marque "Confiar na autenticação multifator de locatários do Microsoft Entra".
  • Resultado: Quando o consultor faz o login usando uma YubiKey em seu locatário de origem, seu locatário recebe uma declaração (claim) de "MFA Satisfeito + Resistente a Phishing". O acesso é concedido sem que o usuário precise registrar nada. Isso terceiriza o gerenciamento do ciclo de vida da credencial para o parceiro, reduzindo sua responsabilidade e a carga de suporte.

7. Estratégias de recuperação#

Muitas vezes, as decisões de recuperação ainda ficam para trás do lançamento em si. Existem várias opções de recuperação dependendo das necessidades da sua organização.

7.1 Recuperação de Conta de Autoatendimento (SSAR) com Verified ID#

O novo fluxo de Recuperação de Conta de Autoatendimento (SSAR) do Microsoft Entra ID (em Visualização) permite a recuperação com alta garantia sem a intervenção do helpdesk.

1. Gatilho: O usuário não consegue fazer login. Seleciona "Recuperar minha conta".
2. Verificação de Identidade: O usuário é redirecionado para um provedor de Verificação de Identidade (IDV) terceirizado (ex: Onfido, IDemia).
3. Verificação de Documentos: O usuário digitaliza sua carteira de motorista física, identidade nacional ou passaporte usando a câmera do celular.
4. Verificação de Vitalidade: O usuário realiza um Face Check com selfie. Isso é verificado em relação ao documento de identidade (e potencialmente a foto armazenada no Entra ID). A correspondência usa as APIs Face do Azure AI Vision e apenas uma pontuação de confiança é compartilhada. Nenhum dado biométrico bruto vai para a aplicação.
5. Restauração: Em caso de sucesso, o sistema emite automaticamente um Passe de Acesso Temporário (TAP) ao usuário.
6. Novo Registro: O usuário usa o TAP para registrar uma nova chave de acesso imediatamente.

Recomendação: Este caminho de recuperação automatizado e com base em biometria é superior a "Ligar para o Helpdesk", o qual é vulnerável à engenharia social (ataques de voz Deepfake).

7.2 Recuperação Assistida por Gerente com My Staff#

Se você deseja reduzir a carga do Service Desk, mas não pode habilitar o autoatendimento completo, o Microsoft Entra inclui um recurso de administração delegada nativa chamado My Staff.

• Como funciona: Delegar permissões limitadas a "Gerentes de Equipe" (via Unidades Administrativas no Entra).
• Fluxo: Se um usuário perder o acesso, ele pode contatar um administrador local delegado, que pode usar o portal My Staff para tarefas de recuperação compatíveis, como redefinir uma senha ou atualizar um número de telefone.
• Por que ajuda: Muda o trabalho comum de recuperação de conta do help desk central e acelera o suporte.

7.3 Quiosque de Recuperação de Autoatendimento (intranet)#

Como os usuários muitas vezes ainda têm um laptop confiável e seguro via WHfB, você pode construir uma página simples na intranet para "emergências".

• Construção: Um aplicativo web interno simples que exige login WHfB (autenticação forte).
• Ação: Uma vez autenticado, o usuário clica em "Tenho um telefone novo". O aplicativo usa a API do Microsoft Graph (serviço em segundo plano) para gerar um Passe de Acesso Temporário (TAP) de curta duração e exibe na tela.
• Resultado: O usuário digita esse TAP em seu novo telefone para configurar o aplicativo Microsoft Authenticator. Zero envolvimento do helpdesk.

Esta é a alavanca fundamental para reduzir a necessidade de "limpar métodos de autenticação" sem enfraquecer a política. Se você tem um mecanismo forte de laptop como inicializador, a carga de comunicação cai consideravelmente porque os usuários conseguem recuperar acesso sem precisar saber a sequência perfeita.

8. Recomendações para Implantações de Chaves de Acesso Corporativas#

Estruture seu lançamento em torno de Estágios de Maturidade. Reconheça o atrito ("A tecnologia está pronta, as operações são difíceis") e aplique essas mitigações.

8.1 Ações imediatas (Fase "Corrigir")#

1. Auditar Bluetooth e Firewalls: Garanta que os laptops corporativos permitam o Bluetooth (para verificações de proximidade) e libere os domínios de retransmissão FIDO/WebAuthn (\*.cable.auth.com) para consertar falhas entre dispositivos.
2. Habilitar a Confiança Entre Locatários (Cross-Tenant Trust): Pare de tentar registrar chaves de acesso de convidados. Configure a Confiança de Entrada para MFA em parceiros-chave para resolver os problemas de acesso B2B imediatamente.
3. Implementar TAP na Integração (Onboarding): Exija o uso do Passe de Acesso Temporário (Temporary Access Pass) em toda integração de novos usuários para solucionar o bloqueio de registro "do ovo e da galinha".

8.2 Decisões estratégicas (Fase "Arquitetura")#

1. Adotar um "Modelo de Garantia Híbrido":
   • Nível 0 (Administradores): Impor Atestado e Restrições de Chave. Somente YubiKeys/Hardware permitidos (AAL3).
   • Nível 1 (Força de Trabalho): Desabilitar a imposição de Atestado por meio de Perfis de Chave de Acesso. Permitir chaves de acesso sincronizadas para reduzir atrito e custo (AAL2).
2. Planejar para o macOS: Implemente o Platform SSO com o seu MDM como uma via paralela ao WHfB do Windows.

8.3 Preparação para o futuro (Fase "Otimização")#

1. Planejar para o SSAR: Inicie um projeto-piloto de Recuperação de Conta de Autoatendimento com o Verified ID para eliminar o helpdesk como vetor de engenharia social.
2. Autenticação Preferencial do Sistema: Habilite esta política para "atualizar" automaticamente os usuários para as chaves de acesso assim que eles registrarem uma, estimulando a adoção sem exigência forçada.
3. Implantar Opções de Recuperação: Implemente o TAP Assistido por Gerente via My Staff e/ou um Quiosque de Recuperação de Autoatendimento.
4. Requisito de Chave de Acesso no Intune: Considere exigir chave de acesso para inscrição no Intune de modo a forçar o registro precoce em novos dispositivos.

8.4 Matriz de solução de problemas#

9. Monitorando a implantação com a Pasta de Trabalho Passwordless Resistente a Phishing#

A Microsoft lançou uma Pasta de Trabalho Passwordless Resistente a Phishing (Phishing-Resistant Passwordless Workbook) que organizações com registros no Azure Monitor podem usar para acompanhar o progresso da implantação. Acesse-a através do centro de administração do Entra em Monitoramento > Pastas de Trabalho (Workbooks):

A pasta de trabalho possui duas seções principais:

9.1 Fase de Prontidão de Registro#

Use esta aba para analisar registros de login e determinar quais usuários estão prontos para registro vs quais podem estar bloqueados. Você pode filtrar por plataforma de SO (Windows, macOS, iOS, Android) e tipo de credencial (Chave de Acesso do Authenticator App, Chave de Segurança FIDO2, Autenticação Baseada em Certificado):

A pasta de trabalho mostra:

• Pares de Usuário/Dispositivo Prontos para o Registro: usuários que podem registrar o tipo de credencial selecionado
• Pares de Usuário/Dispositivo Não Prontos: usuários que podem ter problemas de registro (por exemplo, versões de sistema operacional desatualizadas)

Você pode exportar as listas de usuários que precisam de ações de correção (por exemplo, atualizações de sistema operacional, troca de aparelhos ou opções alternativas de credenciais).

9.2 Fase de Prontidão de Aplicação (Enforcement)#

Assim que os usuários estiverem prontos para a autenticação baseada unicamente em resistência a phishing, use a aba de Prontidão de Aplicação. Primeiro, crie uma política de Acesso Condicional como Somente Relatório que exija MFA resistente a phishing. Isso preencherá os registros de login com dados sobre se o acesso teria sido bloqueado se a imposição estivesse ativa.

O painel mostra:

• Total de usuários no escopo
• Sucesso Apenas no Relatório - usuários que passariam na imposição
• Política Não Satisfeita - usuários que seriam bloqueados (investigue estes!)
• Divisão de Estado do Dispositivo, Plataforma do Dispositivo e Aplicativo Cliente

Use a aba de Análise de Dados Adicionais para investigar por que determinados usuários seriam bloqueados. Esses dados o ajudam a direcionar usuários para remediação antes da ativação da política.

9.3 Lançamento em ondas com monitoramento de help desk#

A Microsoft recomenda executar implantações em ondas com intervalos de datas flexíveis. Monitore o volume de tickets do help desk como sinal:

• O volume de tickets aumenta: Desacelere implantações, comunicações e ações de imposição
• O volume de tickets diminui: Acelere novamente as atividades

Crie grupos de segurança do Microsoft Entra ID para cada onda e adicione grupos às suas políticas progressivamente. Isso evita sobrecarregar as equipes de suporte.

10. Checklist piloto para chaves de acesso sincronizadas#

Se o objetivo é obter chaves de acesso sincronizadas sem depender do Microsoft Authenticator, siga esta postura piloto:

1. Habilitar chaves de acesso sincronizadas (visualização) Siga as Chaves de acesso sincronizadas (visualização).

2. Usar Perfis de Chave de Acesso (visualização) e definir o grupo piloto Crie/atribua um perfil que permita as chaves de acesso sincronizadas como descrito nos Perfis de Chave de Acesso.

3. Não impor atestado (pelo menos para o grupo piloto) A imposição de atestado exclui as chaves de acesso sincronizadas de acordo com a documentação de conceitos de Passkeys (FIDO2).

4. Evitar listas de permissão estritas de AAGUID no início Comece de forma permissiva para confirmar o fluxo, depois aperte as restrições ao ter certeza sobre quais provedores deseja autorizar. Verifique Habilitar chaves de acesso (FIDO2).

5. Confirmar que o Acesso Condicional não força o Microsoft Authenticator Tenha certeza de que as forças de autenticação e CA continuam a aceitar o perfil da chave de acesso que você pretende utilizar (do contrário parece ser uma dependência do Microsoft Authenticator).

6. Validar o modelo de identidade (membro vs convidado) Caso haja usuários convidados, verifique a suportabilidade prevista dentro do modelo do seu locatário (tenant) antes de perder tempo configurando os perfis.

11. Conclusão#

A implantação corporativa de chaves de acesso é operacionalmente complexa, mas o caminho a seguir é bem definido. Aqui estão as principais respostas, alinhadas com as principais perguntas operacionais levantadas acima:

1. Chaves de acesso vinculadas a dispositivos vs sincronizadas: Credenciais vinculadas a dispositivos (por exemplo, Microsoft Authenticator, Windows Hello, YubiKeys, smartcards) estão estritamente atreladas a um único dispositivo e atendem a AAL3. Chaves de acesso sincronizadas (por exemplo, iCloud Keychain, Google Password Manager) funcionam entre dispositivos e atendem a AAL2. A maioria das organizações precisa de ambos: autenticadores de hardware para administradores (AAL3) e chaves de acesso sincronizadas para a força de trabalho mais ampla (AAL2).

2. Configuração inicial para novos funcionários: Use o Passe de Acesso Temporário (Temporary Access Pass - TAP) para resolver o problema do "ovo e da galinha" na integração. Para implantações em larga escala, automatize isso via Graph API. Para casos de uso de alta garantia, complemente a integração com o Entra Verified ID e o Face Check.

3. Recuperação em caso de troca de telefone: Ofereça vários métodos de recuperação: Quiosque de Recuperação de Autoatendimento (use um laptop como dispositivo inicializador), TAP Assistido por Gerente via My Staff e SSAR (Recuperação de Conta de Autoatendimento) com o Verified ID para os casos extremos.

4. Erros de configuração: Os erros mais frequentes incluem a imposição global de atestado, não habilitar recursos de visualização para chaves de acesso sincronizadas, listas de permissões de AAGUID muito restritas e políticas de Acesso Condicional (CA) que geram dependências circulares.

5. Convidados B2B: Evite registrar chaves de acesso diretamente para convidados B2B no seu locatário. Em vez disso, habilite a Confiança de Acesso Entre Locatários (Cross-Tenant Access Trust) para validar as credenciais do locatário de origem do convidado.

6. Chaves de hardware vs chaves de acesso móveis: As chaves de segurança de hardware são obrigatórias para certas funções de alta segurança (administradores, estações de trabalho compartilhadas), mas apresentam obstáculos logísticos em grande escala. As chaves de acesso móveis são geralmente mais práticas para a força de trabalho.

7. macOS junto com Windows: Utilize o Platform SSO com JAMF/MDM para ativar o suporte às chaves de acesso no macOS paralelamente às implantações do Windows. Planeje-se para fluxos de trabalho específicos da plataforma.

8. Medidas proativas: Use o Intune para identificar dispositivos inativos e incentivar os usuários à remediação antes que o bloqueio ocorra. Considere tornar o registro da chave de acesso um pré-requisito para o registro no Intune para estimular a adoção inicial. Construa um fluxo de trabalho de recuperação de autoatendimento usando laptops como dispositivos inicializadores.

A tecnologia está pronta. O desafio principal é a execução operacional. O planejamento da recuperação deve ser um elemento integrante desde o primeiro dia, e não um pensamento tardio. Assim que a infraestrutura estiver sólida, foque na otimização da adoção do login por chaves de acesso para garantir que elas se tornem o método de autenticação primário para toda a sua força de trabalho.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

Perguntas Frequentes#

Por que a habilitação do MFA resistente a phishing no Acesso Condicional bloqueia todos os meus usuários?#

A criação de uma política de Acesso Condicional que exija um MFA resistente a phishing para todos os aplicativos em nuvem bloqueia imediatamente qualquer usuário que ainda não tenha registrado uma chave de acesso, o que inclui o acesso à própria página de registro de Informações de Segurança. Esta dependência circular, chamada de paradoxo de 'Registrar Informações de Segurança', significa que você precisa emitir um Passe de Acesso Temporário aos usuários afetados antes de ativar a imposição, para que eles possam efetuar o seu primeiro registro.

Como lidar com os usuários convidados B2B quando o meu locatário exige um MFA resistente a phishing?#

O Entra ID não suporta usuários convidados que registram as chaves FIDO2 em um locatário de recurso (resource tenant). Portanto, se você tentar impor este registro para os convidados, isso vai falhar. A correção mais apropriada é configurar a Confiança de Acesso Entre Locatários sob Identidades Externas, de forma a aceitar as declarações de MFA do locatário original (home tenant) do convidado. Isto significa que uma YubiKey que o convidado utilize em sua própria organização satisfaz a sua exigência do MFA sem exigir um novo registro no seu locatário.

O que faz com que a autenticação do código QR entre dispositivos falhe silenciosamente no login com uma chave de acesso?#

A Autenticação entre Dispositivos requer que o Bluetooth esteja ativo tanto no PC como no telefone, para conseguir realizar um handshake (ou aperto de mão) de proximidade por BLE. Assim, qualquer política de empresa que desative o Bluetooth fará o fluxo quebrar. Além disso, este fluxo utiliza uma conexão WebSocket para cable.auth.com. Várias vezes, firewalls e até o Zscaler bloqueiam isso, o que acaba suspendendo o funcionamento da leitura do código QR e não exibe um aviso claro de erro.

Como verifico quais funcionários estão prontos para a adoção do MFA resistente a phishing antes de a iniciar?#

A Pasta de Trabalho Passwordless Resistente a Phishing da Microsoft, disponível no painel de gestão Entra em Monitoramento > Pastas de Trabalho (Workbooks), fornece a exibição da Prontidão de Registro. Isto indica os pares usuário/dispositivo aptos para registrar as chaves por cada plataforma. Já para confirmar a sua prontidão de aplicação (enforcement), o ideal é que elabore uma política de Acesso Condicional no formato somente relatório e determine ali um MFA seguro. Depois de feito, verifique os relatórios de inícios de sessão e apure todos que enfrentariam bloqueios.

Qual a estratégia de recuperação recomendada se os funcionários receberem um novo telefone e perderem acesso à chave de acesso atual?#

A abordagem recomendada utiliza o conceito em camadas: o Quiosque de Recuperação de Autoatendimento num laptop seguro por WHfB poderá gerar o Passe de Acesso Temporário graças à Microsoft Graph API, superando grande parte dos casos sem pedir ajuda ao serviço de TI. Quem não possuir laptop conta com o TAP Assistido por Gerente a partir do portal My Staff. Para todos os outros cenários e exceções complexas em que as identidades exigem confirmação completa, fica em vigor o sistema de Recuperação de Conta de Autoatendimento que possui reconhecimento de Face Check pelo Microsoft Entra Verified ID.

Leituras adicionais#

Para estudos aprofundados sobre a implantação de chaves de acesso (passkeys) corporativas e FIDO2, siga as orientações e as publicações regulares sobre as melhores práticas de autenticação no Entra de consultores peritos como o Merill Fernando e o Jan Bakker.