Análise editorial original do OrbTrail, ampliada com pesquisa complementar, contexto prático e referências verificadas.
A ampliação do MFA no Salesforce não é apenas uma nova caixa marcada em Setup. A plataforma passou a avaliar a força de cada autenticação e a exigir respostas diferentes conforme o usuário entra diretamente ou por SSO e conforme possui permissões comuns ou privilegiadas. Em 10 de agosto de 2026, novos grupos de produção entraram na janela de aplicação. Para muitas empresas, o risco imediato deixou de ser descumprir uma recomendação e passou a ser descobrir, durante o expediente, que a evidência enviada pelo provedor de identidade não é a que o Salesforce espera.
A questão central, portanto, é operacional: como implantar a exigência sem bloquear administradores, equipes de linha de frente, integrações e canais móveis? A resposta começa por separar três problemas que costumam ser tratados como um só: cobertura de MFA para todos os usuários internos, autenticação resistente a phishing para contas privilegiadas e prova técnica da força do login quando existe federação. O OrbTrail cruzou o cronograma e as tabelas de autenticação do Salesforce com a experiência documentada do rollout e com a configuração de passkeys no Microsoft Entra ID para montar um plano verificável.
Classificar o nível de acesso
Identifique se a conta é comum ou se recebe privilégios por perfil, permission set ou grupo de permissões.
Comprovar a força correta
Login direto usa verificadores do Salesforce; SSO precisa entregar sinais AMR ou ACR aceitos para o nível exigido.
Testar perda e recuperação
Registre método alternativo, responsável por desbloqueio e procedimento de emergência antes da aplicação.
O calendário agora depende do grupo de release
O Salesforce iniciou a aplicação em sandboxes em julho e dividiu produção por grupos de instâncias. A documentação publicada em 14 de julho informa janelas específicas: os grupos R2a e R2b começam em 10 de agosto, com término previsto em 17 e 13 de agosto, respectivamente; Japão e Coreia aparecem em 1º de setembro, e as demais instâncias não listadas, em 3 de setembro. A data genérica de início não basta. Cada equipe precisa identificar a instância da organização e consultar o grupo correspondente.
Essa precisão importa porque o rollout já teve uma pausa. O Salesforce Ben registrou que a aplicação foi interrompida brevemente depois que usuários com chaves existentes receberam solicitações indevidas para cadastrar novas credenciais. O cronograma foi retomado com novas datas. A conclusão prática não é desconfiar do controle, mas abandonar planos baseados em um único dia: acompanhe o artigo oficial, valide primeiro em sandbox e mantenha comunicação preparada para mudanças de janela.
Usuários comuns e privilegiados não enfrentam a mesma regra
Para usuários internos sem privilégios elevados, o Salesforce aceita MFA padrão ou resistente a phishing. No login direto, isso inclui Salesforce Authenticator e aplicativos TOTP, além de passkeys e chaves compatíveis. Para usuários privilegiados, o patamar sobe: perfil System Administrator ou permissões como Modify All Data, View All Data, Customize Application e Author Apex colocam a conta no escopo de MFA resistente a phishing. TOTP e aprovações push continuam úteis para a população comum, mas não satisfazem sozinhos a exigência privilegiada.
O inventário não pode olhar apenas o nome do perfil. Permission sets e permission set groups podem conceder uma das permissões críticas a pessoas que nunca foram chamadas de administradoras. Uma revisão segura cruza usuários ativos, perfis e permissões efetivas, define um dono para cada conta privilegiada e elimina acessos temporários que se tornaram permanentes. Esta é análise do OrbTrail: reduzir privilégios desnecessários diminui simultaneamente a superfície de ataque e a população que precisa do método de autenticação mais rígido.
SSO não é isenção: o Salesforce precisa receber a evidência
Em uma federação, a tela do provedor de identidade pode mostrar que MFA foi concluído e, ainda assim, o Salesforce classificar o login como fraco. O motivo está nos sinais AMR e ACR enviados na asserção SAML ou no token OIDC. A documentação do Salesforce organiza métodos em três níveis — resistente a phishing, MFA padrão e fraco ou sem MFA — e decide o resultado a partir do verificador direto ou dos sinais emitidos pelo IdP. Uma política correta no Entra, Okta ou outro provedor não ajuda se a aplicação Salesforce recebe uma afirmação genérica, ausente ou incompatível.
O teste decisivo não é uma captura da tela de Conditional Access, mas uma autenticação real por persona. Escolha um usuário comum e um privilegiado, execute o fluxo completo em sandbox e confirme qual método foi usado, quais sinais chegaram ao Salesforce e se houve pedido adicional de cadastro. No Microsoft Entra ID, passkeys FIDO2 podem ser aplicadas por grupos, com opções para credenciais ligadas ao dispositivo ou sincronizadas, attestation e restrições por AAGUID. A política deve refletir o risco do grupo e o sinal que a aplicação consumidora efetivamente reconhece.
Passkeys reduzem phishing, mas exigem decisões de dispositivo e recuperação
Passkeys e chaves WebAuthn evitam o segredo reutilizável que uma página falsa tentaria capturar. Há, porém, escolhas operacionais. Uma credencial ligada ao dispositivo oferece controle forte, mas depende daquele hardware; uma passkey sincronizada melhora continuidade entre dispositivos, embora introduza o provedor de sincronização no modelo de confiança. Para administradores e funções sensíveis, a organização deve decidir se exige attestation, restringe modelos de chave e fornece uma segunda credencial registrada antes de qualquer perda ou troca de equipamento.
A compatibilidade também precisa entrar no desenho. A documentação do Salesforce informa que autenticadores integrados não funcionam como verificador de MFA no aplicativo móvel Salesforce, em Experience Cloud, para acesso por API ou no login OAuth do Data Loader; nesses cenários, um método alternativo pode ser necessário. Recuperação não pode significar voltar silenciosamente a um fator fraco. Defina quem pode remover um autenticador perdido, como validar a identidade da pessoa, quando emitir um código temporário de administrador e como auditar o evento depois.
Um plano de implantação que evita o dia do bloqueio
Primeiro, determine escopo. Liste usuários ativos, método de entrada, dispositivo principal, uso do aplicativo móvel, privilégios efetivos e dependência de contas compartilhadas ou automações. Separe contas humanas de usuários API-only e valide exceções legítimas com a documentação e, quando necessário, com o suporte do Salesforce; a permissão de dispensa não deve ser tratada como atalho para usuários internos. Em seguida, escolha o padrão por persona: MFA padrão para a população elegível, passkey ou chave para privilegiados e políticas de SSO capazes de emitir evidência suficiente.
Segundo, pilote o caminho inteiro. Cadastre pelo menos dois métodos para quem não pode ficar sem acesso, teste login direto e SSO, navegação móvel, Data Loader e recuperação de dispositivo. Registre tempo de conclusão, falhas por navegador ou equipamento e chamados abertos. Terceiro, publique instruções curtas antes da janela da instância e prepare o service desk para reconhecer a diferença entre registro de passkey, MFA padrão, ativação de dispositivo e step-up authentication; mensagens semelhantes podem ter causas diferentes.
Por fim, trate a aplicação como uma mudança controlada. Monitore falhas de login, usuários não cadastrados, emissões de código temporário e chamados de recuperação nas primeiras horas. Mantenha um administrador de emergência protegido, com credenciais independentes e procedimento testado, sem transformar a conta em login cotidiano. Após estabilizar, revise permissões elevadas e métodos antigos. O resultado esperado não é apenas passar pelo enforcement, mas sair com uma arquitetura de identidade mais clara e recuperável.
Conclusão: MFA agora é parte da arquitetura da plataforma
A exigência de 2026 une configuração Salesforce, desenho de identidade, política de dispositivos e operação de suporte. Ativar MFA continua necessário, mas não suficiente. A organização precisa demonstrar a força certa para cada usuário, transmitir essa evidência corretamente pelo SSO e recuperar o acesso sem reabrir a porta que o controle tentou fechar. Quem testa personas e falhas antes da sua janela transforma uma obrigação em redução real de risco; quem olha apenas o toggle pode descobrir a arquitetura no pior momento possível.
