Autenticação sem senha com o Microsoft Intune

A autenticação sem senha reduz o phishing e o roubo de credenciais, substituindo senhas por métodos de entrada mais robustos, como Windows Hello, chaves de segurança FIDO2, chaves de acesso, certificados, entrada pelo telefone Microsoft Authenticator e Passe de Acesso Temporário.

O Microsoft Intune não emite credenciais sem senha. Em vez disso, ele prepara dispositivos, aplicativos e experiências do usuário para que esses métodos sem senha funcionem de forma confiável em escala. O Microsoft Entra ID é a autoridade de identidade que verifica as credenciais e impõe as políticas de autenticação e Acesso Condicional, enquanto o Microsoft Intune define as configurações do dispositivo, impõe a conformidade e habilita os recursos de plataforma dos quais esses métodos dependem. Juntos, o Microsoft Entra ID e o Microsoft Intune fornecem a base de identidade e a preparação do dispositivo necessárias para adotar a autenticação sem senha em diversas plataformas e formatos.

A experiência sem senha varia de acordo com a plataforma. No Windows, geralmente abrange a entrada do dispositivo e o acesso ao aplicativo por meio do SSO. No macOS, ele se concentra na autenticação da plataforma e no SSO nos aplicativos, em vez da identidade profunda vinculada ao dispositivo. No iOS/iPadOS e no Android, ele se concentra com mais frequência na entrada do aplicativo, na autenticação agenciada e no comportamento da chave de acesso do que na entrada do dispositivo. Lembre-se dessas distinções ao avaliar os requisitos da plataforma e planejar a implantação.

Este artigo explica como o Microsoft Intune dá suporte a uma estratégia sem senha da perspectiva de um administrador. Para obter detalhes de implantação, siga os links de implementação para cada método sem senha.

Como funciona a solução sem senha da Microsoft

A solução sem senha da Microsoft combina o Microsoft Entra ID para identidade e logon único (SSO) com o Microsoft Intune para configuração de dispositivo e imposição de política. Essa combinação permite que os usuários se autentiquem usando credenciais fortes, como biometria, chaves de segurança FIDO2 ou chaves de acesso, sem inserir senhas.

O Microsoft Entra ID é o principal provedor de identidade. Ele verifica credenciais sem senha, como PINs do Windows Hello, chaves FIDO2 e chaves de acesso. Após a autenticação bem-sucedida, o Microsoft Entra ID emite um Token de Atualização Principal (PRT) ou equivalente, permitindo o SSO contínuo para o Microsoft 365, o Azure e outros recursos protegidos. As políticas de Acesso Condicional avaliam o estado do dispositivo, a força da autenticação e os sinais de risco antes de conceder acesso.

O Microsoft Intune prepara os dispositivos para a entrada sem senha definindo as configurações, reforçando a conformidade, implantando os aplicativos necessários e dando suporte às experiências de plataforma que tornam a prática sem senha em escala. O Microsoft Intune oferece aos administradores um plano de gerenciamento para Windows, macOS, iOS/iPadOS e Android.

Os recursos da plataforma no Windows, macOS, iOS e Android fornecem a experiência vinculada ao dispositivo, incluindo biometria, hardware seguro (TPM no Windows, Secure Enclave no macOS), suporte a senha e logon único agenciado.

Essa separação é importante. O Microsoft Entra ID é a autoridade de identidade. O Microsoft Intune é a camada de gerenciamento que ajuda os usuários a adotar e usar esses métodos com êxito.

Sem senha, MFA e resistência a phishing

A autenticação sem senha não elimina os fatores de segurança. A maioria dos métodos sem senha realmente atende aos requisitos de autenticação multifator (MFA). Por exemplo, o Windows Hello usa uma credencial vinculada ao dispositivo (posse) emparelhada com um gesto biométrico (inerência) ou um PIN (conhecimento), satisfazendo a MFA por padrão. Como resultado, as políticas de força de autenticação de Acesso Condicional classificam muitos métodos sem senha como compatíveis com MFA ou até mesmo como MFA resistentes a phishing.

Nem todas as opções sem senha fornecem o mesmo nível de proteção. Compreender a diferença entre métodos resistentes a phishing e não resistentes a phishing ajuda você a selecionar os pontos fortes de autenticação corretos e projetar uma estratégia de identidade segura.

  • Os métodos resistentes a phishing usam chaves criptográficas assimétricas associadas ao hardware que não podem ser interceptadas ou reproduzidas, mesmo que um usuário interaja com um prompt mal-intencionado ou falsificado.
  • Métodos não resistentes a phishing usam fluxos sem senha, mas ainda podem ser comprometidos por engenharia social, manipulação imediata ou fadiga de MFA.

Cada método descrito posteriormente neste artigo inclui seu nível de resistência a phishing.

Saiba mais

Benefícios da autenticação sem senha com o Microsoft Intune

Ao usar o Microsoft Intune, o Microsoft Entra ID e os recursos de plataforma juntos, sua organização ganha:

  • Logon único contínuo: os usuários entram uma vez no dispositivo e obtêm acesso automático a aplicativos, serviços de nuvem e, em alguns casos, recursos locais. As chamadas de redefinição de senha e os prompts de autenticação repetidos são eliminados.
  • Conveniência do usuário em todos os dispositivos: os usuários obtêm uma experiência nativa e consistente em todos os dispositivos. O Windows Hello usa a entrada do sistema operacional, o macOS integra o Touch ID ao Microsoft Entra ID e as plataformas móveis usam o Microsoft Authenticator e as chaves de acesso da plataforma. Os usuários não precisam fazer malabarismos com senhas separadas por dispositivo.
  • Postura de segurança mais forte: métodos resistentes a phishing evitam roubo de credenciais e ataques de repetição. A restrição de conformidade do dispositivo garante que até mesmo as credenciais válidas funcionem apenas em dispositivos gerenciados e íntegros, alinhando-se aos princípios de Confiança Zero.
  • Carga de suporte de TI reduzida: menos redefinições de senha, integração mais suave com o Passe de Acesso Temporário e opções de recuperação de autoatendimento reduzem o volume do suporte técnico.
  • Arquitetura pronta para o futuro: à medida que os padrões evoluem, novos métodos sem senha, incluindo chaves de acesso sincronizadas e credenciais com suporte para hardware, podem ser conectados à mesma arquitetura do Microsoft Entra ID + Microsoft Intune sem a necessidade de grandes reformulações.

Como o Microsoft Intune impulsiona a adoção sem senha

O Microsoft Intune habilita e operacionaliza a autenticação sem senha, garantindo que os dispositivos e aplicativos estejam configurados corretamente para usar credenciais fortes e modernas. Embora o Microsoft Entra ID regule a política de identidade e autenticação, o Microsoft Intune prepara o ambiente do dispositivo do qual os métodos sem senha dependem.

As principais contribuições incluem:

  • Preparação do dispositivo: registrar, registrar e configurar dispositivos para que eles possam participar de fluxos de entrada sem senha.
  • Implantação de configuração: fornecendo as políticas necessárias para o Windows Hello para Empresas, autenticação baseada em certificado, SSO da Plataforma Apple e recursos de plataforma semelhantes.
  • Sinais de conformidade e acesso: fornecimento de dados de integridade e conformidade do dispositivo que o Acesso Condicional avalia antes de conceder acesso.
  • Provisionamento de aplicativos e agentes: implantação de aplicativos principais, como Microsoft Authenticator e Microsoft Intune Portal da Empresa, que permitem cenários de corretagem de identidade e SSO sem senha.
  • Gerenciamento unificado multiplataforma: fornecendo uma estrutura consistente de política e gerenciamento no Windows, macOS, iOS/iPadOS e Android para simplificar a implantação corporativa.

Os métodos sem senha disponíveis para os usuários dependem da plataforma do dispositivo e das opções de autenticação habilitadas no Microsoft Entra ID. O Microsoft Intune garante que cada dispositivo esteja preparado, configurado e capaz de fornecer uma experiência segura e confiável sem senha.

Windows Hello

Resistente a phishing

O Windows Hello substitui senhas por uma chave assimétrica vinculada ao dispositivo que é gerada e selada no TPM. O acesso à chave é controlado por um PIN ou gesto biométrico (impressão digital ou reconhecimento facial), combinando posse e inerência em uma única etapa de entrada. Esse método é respaldado por hardware e resistente a phishing para dispositivos Windows.

Função do Intune
O Microsoft Intune prepara dispositivos Windows para o Windows Hello fornecendo e aplicando as configurações de política do Windows Hello para Empresas.

Esse método é mais relevante quando você precisa:

  • Prepare os dispositivos Windows que priorizam a nuvem para entrar sem senha.
  • Forneça as configurações de política do Windows Hello para Empresas durante o registro e o gerenciamento contínuo.
  • Alinhe a entrada do Windows com a conformidade do dispositivo e o gerenciamento moderno.

Saiba mais

Chaves de segurança FIDO2

Resistente a phishing

As chaves de segurança FIDO2 são dispositivos físicos (USB, NFC ou Bluetooth) que armazenam uma credencial FIDO e fornecem autenticação resistente a phishing sem depender da plataforma do dispositivo. Como a credencial está vinculada à chave de hardware e verificada por meio de um desafio criptográfico, ela não pode ser interceptada ou reproduzida. As chaves FIDO2 são ideais para dispositivos compartilhados, ambientes de alta segurança ou como um caminho de recuperação junto com credenciais baseadas em plataforma.

Função do Intune
O Microsoft Intune pode ajudar a preparar dispositivos para esse método gerenciando plataformas compatíveis e experiências de entrada relacionadas.

Esse método geralmente é uma boa opção quando as organizações precisam:

  • Uma opção portátil sem senha para dispositivos compartilhados ou especializados.
  • Uma opção forte e resistente a phishing que não está vinculada a uma única plataforma ou ao Microsoft Authenticator.
  • Uma recuperação ou caminho alternativo ao lado de credenciais baseadas na plataforma.

Para obter diretrizes de implementação, consulte:

Chaves de acesso

Resistente a phishing

As chaves de acesso são o guarda-chuva baseado em padrões para credenciais FIDO que podem ser vinculadas ao dispositivo ou sincronizadas entre dispositivos. No Microsoft Entra ID, você pode usar:

  • Chaves de acesso associadas ao dispositivo armazenadas em hardware seguro (TPM ou Secure Enclave) em um único dispositivo, como por meio do Windows Hello ou Microsoft Authenticator no iOS 17+ e Android 14+.
  • Chaves de acesso sincronizadas gerenciadas por gerenciadores de senhas de plataforma (como iCloud Keychain ou Google Password Manager) ou provedores de terceiros compatíveis, que permitem o uso entre dispositivos.
  • A chave de acesso do Microsoft Entra no Windows é uma chave de acesso FIDO2 que usa o Windows Hello para verificação biométrica, mas não requer ingresso ou registro do dispositivo. Os usuários podem registrar várias chaves de acesso para várias contas do Microsoft Entra no mesmo dispositivo, tornando-o adequado para dispositivos compartilhados, pontos de extremidade não gerenciados e cenários em que o Windows Hello para Empresas não está provisionado.

Função do Intune
De uma perspectiva do Microsoft Intune, as chaves de acesso têm a ver principalmente com a preparação da plataforma e do aplicativo, gerenciando os pré-requisitos do dispositivo e do aplicativo que viabilizam a adoção da chave de acesso entre plataformas.

Essa dependência é especialmente importante em:

  • Windows, em que a entrada da plataforma e o Windows Hello podem se cruzar com um planejamento mais amplo sem senha. A chave de acesso do Microsoft Entra no Windows estende a cobertura de chave de acesso a dispositivos que não estão registrados ou ingressados, complementando o Windows Hello para Empresas em dispositivos gerenciados.
  • iOS/iPadOS e Android, em que as chaves de acesso podem depender do estado do dispositivo móvel e do comportamento do agente de aplicativos.
  • macOS, em que a integração da identidade da plataforma e a experiência de entrada do usuário moldam a adoção.

Para obter diretrizes de implementação, consulte:

Entrada pelo telefone Microsoft Authenticator

Não resistente a phishing

A entrada pelo telefone do Microsoft Authenticator substitui senhas por aprovação baseada em push e correspondência de números no dispositivo móvel confiável do usuário. É conveniente e amplamente compatível, mas depende de notificações por push em vez de credenciais vinculadas a hardware, o que significa que não impede totalmente ataques de phishing, como manipulação de prompt de MFA.

Observação

O Microsoft Authenticator também pode armazenar chaves de acesso vinculadas ao dispositivo (iOS 17+, Android 14+), que são resistentes a phishing. Esta seção aborda especificamente o fluxo de entrada por telefone baseado em push.

Função do Intune
O Microsoft Intune dá suporte a esse fluxo implantando e gerenciando os pré-requisitos do dispositivo e do aplicativo móvel.

Em muitos ambientes, esse suporte inclui:

  • Implantar o Microsoft Authenticator em dispositivos móveis gerenciados.
  • Suporte à experiência de entrada agenciada em aplicativos da Microsoft.
  • Considerar as considerações sobre a política de proteção de aplicativos em plataformas móveis quando elas fazem parte do design de acesso móvel mais amplo.

Para obter diretrizes de implementação, consulte:

Passe de Acesso Temporário

Não é um método permanente — usado para integração e recuperação

O TAP (Passe de Acesso Temporário) é uma credencial por tempo limitado que um administrador emite para ajudar os usuários a inicializar ou recuperar o acesso antes que eles concluam sua configuração sem senha de longo prazo. O TAP não é um método permanente sem senha e não é resistente a phishing, mas geralmente é uma parte crítica de uma implementação bem-sucedida porque resolve o problema do primeiro login sem emitir uma senha.

Função do Intune
De uma perspectiva do Microsoft Intune, o Passe de Acesso Temporário é importante quando você deseja:

  • Simplifique a integração com métodos sem senha.
  • Reduzir a dependência de senhas temporárias durante a implantação.
  • Conecte cenários de integração à configuração de dispositivos Windows gerenciados.

Integração do dia zero com a TAP

Um desafio comum em implantações sem senha é o problema do ovo e da galinha : um novo usuário precisa entrar para registrar sua credencial sem senha, mas você não deseja emitir uma senha para o primeiro login. O TAP resolve esse problema fornecendo uma credencial de curta duração para a configuração inicial do dispositivo e o registro de credenciais.

Um fluxo de integração típico tem esta aparência:

  1. Administração emite um TAP — O administrador de TI ou o fluxo de trabalho automatizado gera um TAP por tempo limitado para o novo usuário no centro de administração do Microsoft Entra ou por meio do Microsoft API do Graph.
  2. O usuário configura seu dispositivo — O usuário insere o TAP durante o OOBE do Windows Autopilot, o assistente de configuração do macOS ou o registro do dispositivo móvel. No Windows 11, o logon da Web permite a entrada TAP diretamente na tela de bloqueio.
  3. O usuário registra um método sem senha — Depois de entrar com o TAP, o usuário é solicitado a registrar o Windows Hello, uma chave de segurança FIDO2, uma chave de acesso no Microsoft Authenticator ou outro método sem senha. Esta é a credencial permanente que substitui o TAP.
  4. O TAP expira — O TAP é de uso único ou limitado por tempo (configurável), portanto, não pode ser reutilizado depois que o usuário registra seu método sem senha.

Esse fluxo elimina a necessidade de emitir e revogar uma senha temporária e fornece ao Microsoft Intune um caminho de integração gerenciado desde o primeiro logon.

Para obter diretrizes de implementação, consulte:

Autenticação baseada em certificado (CBA)

Resistente a phishing

A autenticação baseada em certificado (CBA) usa certificados digitais e criptografia assimétrica para verificar a identidade, tornando-a resistente a phishing e evitando a repetição de credenciais. Ela é amplamente adotada em setores regulamentados e ambientes governamentais, geralmente por meio de cartões inteligentes, como PIV e CAC. Ao contrário de outros métodos sem senha em que o Microsoft Intune prepara principalmente o ambiente do dispositivo, o CBA é uma área em que o Microsoft Intune desempenha um papel direto na distribuição da credencial em si.

Função do Intune
O Microsoft Intune dá suporte a dois modelos de infraestrutura para entrega de certificados:

  • PKI local: organizações com uma AC (autoridade de certificação) existente podem usar o Conector de Certificados para Microsoft Intune para conectar sua PKI local com o Microsoft Intune. O conector permite que o Microsoft Intune implante perfis de certificado SCEP e PKCS em dispositivos gerenciados usando sua infraestrutura de autoridade de certificação existente. Esse modelo é adequado para organizações que já operam uma CA corporativa ou precisam se integrar a investimentos de PKI estabelecidos.
  • Microsoft Cloud PKI: para organizações que desejam simplificar ou eliminar a infraestrutura de certificados local, a Microsoft Cloud PKI fornece uma CA baseada em nuvem como parte do Microsoft Intune Suite. O Cloud PKI emite e gerencia certificados sem exigir servidores locais, conectores ou módulos de segurança de hardware.

Independentemente do modelo de infraestrutura, o Microsoft Intune fornece certificados para dispositivos usando perfis de certificado:

  • Os perfis de certificado raiz confiáveis distribuem o certificado raiz da autoridade de certificação para que os dispositivos possam estabelecer a cadeia de confiança.
  • Os perfis de certificado SCEP solicitam e implantam certificados de uma autoridade de certificação habilitada para SCEP.
  • Os perfis de certificado PKCS solicitam e implantam certificados usando o padrão PKCS #12.
  • Os perfis de certificado PFX importados implantam certificados pré-gerados que são importados para o Microsoft Intune.

Esses perfis funcionam no Windows, macOS, iOS/iPadOS e Android, tornando o Microsoft Intune o mecanismo de entrega que conecta sua infraestrutura PKI, seja local ou baseada em nuvem, ao método de identidade definido no Microsoft Entra ID.

Para obter diretrizes de implementação, consulte:

Pré-requisitos

Antes de planejar uma implantação sem senha, verifique se o seu ambiente atende aos requisitos de licenciamento e plataforma para os métodos que você pretende usar. Alguns recursos sem senha exigem camadas de licença específicas do Microsoft Entra ID ou do Microsoft Intune, e cada método tem requisitos mínimos de versão do sistema operacional.

Requisitos de licenciamento

Dependendo dos métodos sem senha escolhidos, sua organização pode precisar de licenças do Microsoft Entra ID P1 ou do Microsoft Entra ID P2 para usuários, bem como licenças específicas do Microsoft Intune para gerenciamento de dispositivos e entrega de certificados. A tabela a seguir resume os requisitos de licenciamento para recursos comuns sem senha:

Recursos Requisito de licença
Windows Hello Microsoft Entra ID P1 (para imposição de Acesso Condicional)
Chaves de segurança FIDO2 Microsoft Entra ID P1
Chaves de acesso (associadas ao dispositivo e sincronizadas) Microsoft Entra ID P1
Entrada pelo telefone Microsoft Authenticator Microsoft Entra ID P1
Passe de Acesso Temporário Microsoft Entra ID P1
Autenticação baseada em certificado (CBA) Microsoft Entra ID P1 (P2 para Acesso Condicional baseado em risco)
Políticas de força de autenticação Microsoft Entra ID P1
Acesso Condicional baseado em risco Microsoft Entra ID P2
Microsoft Cloud PKI Microsoft Intune Suite ou licença autônoma do Cloud PKI
Perfis de configuração e conformidade do dispositivo Microsoft Intune (plano 1)

Saiba mais

Requisitos da plataforma

Os métodos sem senha descritos neste artigo dependem de recursos de plataforma específicos que estão disponíveis apenas em determinadas versões do sistema operacional. A tabela a seguir resume os requisitos de plataforma para cada método:

Método Windows macOS iOS/iPadOS Android
Windows Hello Todos os clientes Windows com suporte — — —
Chaves de segurança FIDO2 Todos os clientes Windows com suporte — — —
Chaves de acesso Windows 11 Todas as versões com suporte Todas as versões com suporte Android 14+
Chaves de acesso vinculadas ao dispositivo no Microsoft Authenticator — — Todas as versões com suporte Android 14+
SSO da plataforma (Secure Enclave) — Todas as versões com suporte — —
Logon da Web (TOQUE na tela de bloqueio) Windows 11 — — —
Entrada pelo telefone Microsoft Authenticator — — Todas as versões com suporte Android 11 e acima

Observação

Com suporte refere-se às versões do sistema operacional que o Microsoft Intune suporta atualmente para funcionalidade completa, implantação de política e gerenciamento.
Os requisitos de versão da plataforma podem mudar a cada ciclo de lançamento. Sempre verifique os requisitos atuais na documentação do produto para o método específico que você está implantando.

Saiba mais

Considerações sobre a plataforma

A opção sem senha não é um recurso. É um conjunto de experiências específicas da plataforma que dependem do Microsoft Entra ID para identidade e do Microsoft Intune para gerenciamento de dispositivos.

Windows

O Windows é o exemplo mais completo de como o registro de dispositivo, a entrada na nuvem, a postura de segurança e a experiência do usuário sem senha funcionam juntos.

O Microsoft Intune geralmente dá suporte a cenários sem senha do Windows ao:

  • Preparando dispositivos que priorizam a nuvem e ingressados no Microsoft Entra.
  • Fornecendo a configuração do Windows Hello para Empresas.
  • Suporte a experiências de chave de segurança FIDO2.
  • Alinhando a prontidão do dispositivo com conformidade e gerenciamento moderno.
  • Suporte a experiências de integração que podem se conectar ao Windows Autopilot.

Quando um usuário entra com o Windows Hello ou uma chave FIDO2, o Windows obtém um Token de Atualização Principal do Microsoft Entra ID. Esse PRT permite o SSO contínuo para aplicativos do Microsoft 365, aplicativos SaaS e, quando o Cloud Kerberos Trust é configurado, recursos locais, como compartilhamentos de arquivos, tudo sem prompts de entrada adicionais.

Saiba mais

Considerações sobre híbrido e legado

As experiências sem senha descritas neste artigo pressupõem uma direção que prioriza a nuvem com os dispositivos ingressados no Microsoft Entra. As organizações com dispositivos híbridos ingressados no Microsoft Entra devem estar cientes dessas diferenças:

  • O logon da Web (usado para TAP na tela de bloqueio do Windows) tem suporte apenas em dispositivos ingressados no Microsoft Entra, não em dispositivos ingressados no Microsoft Entra híbrido.
  • O Windows Hello para Empresas funciona em dispositivos ingressados no Microsoft Entra e híbridos no Microsoft Entra, mas implantações híbridas podem exigir infraestrutura adicional, dependendo do modelo de confiança.
  • O acesso ao recurso local de dispositivos ingressados no Microsoft Entra requer confiança Kerberos na nuvem ou confiança baseada em certificado. A confiança do Cloud Kerberos é o modelo recomendado porque não requer a implantação de certificados para autenticação Kerberos. Para obter mais informações, consulte [implantação de confiança do Kerberos na nuvem](/windows/security/identity-protection/> hello-for-business/deploy/hybrid-cloud-kerberos-trust).
  • Os aplicativos herdados que exigem autenticação Kerberos do Active Directory ainda podem funcionar com métodos sem senha, mas os aplicativos que exigem NTLM ou associação LDAP direta podem precisar de planejamento extra.

Se o seu ambiente for híbrido, planeje sua distribuição sem senha começando com os dispositivos ingressados no Microsoft Entra e expanda para dispositivos ingressados no Microsoft Entra híbridos conforme sua infraestrutura oferecer suporte.

Saiba mais

macOS

No macOS, o planejamento sem senha depende de como o Microsoft Entra ID se integra à experiência de entrada e logon único da plataforma. O Microsoft Intune fornece a configuração de dispositivo necessária para integrações de identidade focadas na Apple.

Com o plug-in SSO corporativo da Microsoft e a estrutura SSO da plataforma da Apple, o Microsoft Intune pode implantar uma configuração que permite que os usuários entrem no Mac usando suas credenciais do Microsoft Entra ID. Quando configurado com o método de chave do Secure Enclave, isso fornece uma experiência de entrada com suporte de hardware resistente a phishing, semelhante ao Windows Hello.

Essas informações são importantes quando você está planejando:

  • SSO da plataforma e experiências de entrada relacionadas.
  • Logon único entre o dispositivo e os aplicativos da Microsoft.
  • Um modelo de gerenciamento consistente ao lado do Windows e de dispositivos móveis.

Saiba mais

iOS e iPadOS

No iOS e iPadOS, o planejamento sem senha se concentra mais na entrada do aplicativo, na autenticação agenciada e no comportamento da chave de acesso do que na entrada do dispositivo. O Microsoft Intune implanta e gerencia os aplicativos e as configurações que tornam essas experiências consistentes para os usuários.

A extensão SSO da Microsoft no iOS pode interceptar solicitações de autenticação em aplicativos da Microsoft e de terceiros, permitindo o logon contínuo após a configuração inicial do dispositivo. O Microsoft Authenticator atua como o agente de autenticação e também pode armazenar chaves de acesso vinculadas ao dispositivo no iOS 17+ para autenticação resistente a phishing.

Saiba mais

Android

No Android, o Microsoft Intune estabelece o contexto gerenciado do qual dependem os fluxos de autenticação agenciados e sem senha. Esse contexto é especialmente relevante quando o Microsoft Authenticator ou experiências de aplicativos relacionados fazem parte do design de acesso móvel.

O Portal da Empresa e o Microsoft Authenticator podem atuar como agentes de autenticação no Android. Depois que um usuário entra por meio do agente, o Microsoft Entra ID emite um Token de Atualização Principal que habilita o SSO em todos os aplicativos com reconhecimento de agente no perfil de trabalho. No Android 14+, o Microsoft Authenticator também pode armazenar chaves de acesso vinculadas ao dispositivo para autenticação resistente a phishing.

Saiba mais

Dependências para autenticação sem senha

Arquitetura de Confiança Zero

A autenticação sem senha faz parte de uma estratégia mais ampla de identidade e acesso ao dispositivo. Para um administrador do Microsoft Intune, o planejamento geralmente envolve estas camadas:

  • Identidade: métodos de autenticação resistentes a phishing no Microsoft Entra ID.
  • Confiança do dispositivo: registro, conformidade e configuração do Microsoft Intune.
  • Política de acesso: Acesso condicional e planejamento de exclusão relacionado.
  • Proteção de dados: recursos do Microsoft Purview que ajudam a proteger o conteúdo depois que o acesso é concedido.
  • Investigação e resposta: o Microsoft Defender sinaliza e fluxos de trabalho quando o risco ou comprometimento precisa de acompanhamento.

Saiba mais

Acesso Condicional

O acesso condicional avalia sinais como o estado do dispositivo e a força da autenticação antes de conceder acesso. Quando combinado com métodos sem senha, o Acesso Condicional pode impor políticas de força de autenticação que exigem MFA resistente a phishing, exigindo efetivamente a ausência de senha, bloqueando métodos mais fracos, como senhas ou códigos SMS.

Ao implementar o Acesso Condicional junto com o acesso sem senha, considere também o planejamento de acesso de emergência para evitar cenários de bloqueio acidental.

Saiba mais

Acesso de emergência e recuperação

Uma preocupação comum ao remover senhas é o que acontece quando um usuário perde seu único dispositivo sem senha - um telefone, uma chave FIDO2 ou um laptop com o Windows Hello. Sem um plano de recuperação, os administradores podem enfrentar escalonamentos de suporte e os usuários podem ser bloqueados de recursos críticos.

Planeje estes cenários como parte de sua implantação sem senha:

  • Contas de acesso de emergência: mantenha pelo menos duas contas de emergência excluídas das políticas de Acesso Condicional e da imposição sem senha. Essas contas fornecem um caminho de fallback se uma configuração incorreta ou interrupção bloquear todos os outros acessos. Armazene credenciais com segurança e monitore a atividade de entrada nessas contas.
  • Recuperação com passagem de acesso temporária: quando um usuário perde seu dispositivo sem senha, um administrador pode emitir um novo TAP para que o usuário possa entrar e registrar uma credencial de substituição. Essa abordagem evita redefinir o usuário para uma senha e mantém o fluxo de recuperação dentro do modelo sem senha.
  • Vários métodos registrados: incentive os usuários a registrar mais de um método sem senha sempre que possível. Por exemplo, um usuário que usa o Hello para Empresas em seu laptop também pode registrar uma chave de acesso no Microsoft Authenticator em seu telefone. Se um dispositivo for perdido, o outro método ainda funcionará.
  • Gerenciamento de credenciais de autoatendimento: os usuários podem gerenciar seus métodos de autenticação em Minhas Informações de Segurança. Quando combinada com a recuperação baseada em TAP, essa abordagem reduz a dependência da assistência técnica para redefinições de credenciais.
  • Recuperação de perda total com ID verificada: para cenários em que um usuário perde todas as credenciais e dispositivos registrados, a recuperação de conta do Microsoft Entra usando a ID verificada fornece um caminho de recuperação de identidade verificada que não depende de senhas ou credenciais emitidas pela assistência técnica.

É essencial planejar a recuperação antes de impor a autenticação sem senha. Uma implementação que bloqueia senhas sem um caminho de recuperação cria o tipo de cenários de bloqueio que corroem a confiança do administrador e do usuário na transição.

Saiba mais

Conformidade e preparação do dispositivo

A ausência de senha geralmente depende do dispositivo estar no estado correto antes que os usuários possam confiar na experiência. A preparação normalmente inclui:

Verificação e operações em andamento

Para validar uma implantação sem senha, os pontos de verificação comuns incluem:

Adoção e comunicação do usuário

A preparação técnica é apenas uma parte de uma implementação sem senha. Os usuários que estão acostumados com senhas podem encontrar confusão ou resistência quando os fluxos de entrada mudarem. Planejar a comunicação e o suporte do usuário pode fazer a diferença entre uma transição suave e um escalonamento generalizado do suporte técnico.

Considere estas práticas:

  • Comunique a alteração antecipadamente: informe aos usuários que a experiência de entrada está mudando, por que está mudando e o que esperar. Concentre-se nos benefícios: menos senhas para lembrar, entrada mais rápida e segurança mais forte.
  • Fornecer diretrizes específicas da plataforma: a experiência sem senha é diferente no Windows (Olá, biometria ou PIN), macOS (Touch ID com SSO da plataforma), iOS (autenticador ou chaves de acesso) e Android (agente do autenticador). Adapte a comunicação às plataformas que seus usuários têm.
  • Identificar grupos piloto: comece com um grupo de usuários que podem testar a experiência e fornecer comentários antes de aplicar a aplicação sem senha em toda a organização. A equipe de TI, os usuários pioneiros e as equipes preocupadas com a segurança geralmente são bons candidatos.
  • Prepare a equipe da assistência técnica: certifique-se de que sua equipe de suporte saiba como emitir um Passe de Acesso Temporário para recuperação, como orientar os usuários pelo registro de credenciais e onde marcar os logs de login quando surgirem problemas.

Saiba mais

  • Last updated on