A MFA obrigatória na Salesforce chega em 2026 e muda as regras do jogo: o que, durante anos, foi apenas uma recomendação passa a ser uma regra permanente e traz consigo um conjunto de mudanças que vão muito além de um simples segundo fator. Acessos de administradores podem ser bloqueados, relatórios passam a exigir nova validação e integrações antigas correm o risco de deixar de funcionar de um dia para o outro. Pode confirmar os prazos na documentação oficial da Salesforce.
Este guia explica, de forma clara, o que muda, quando muda e o que a sua equipa deve fazer antes dos prazos. Um plano para já ser colocado em prática.
1. Identidade: MFA obrigatória para todos os utilizadores
A Salesforce removeu a possibilidade de desativar a MFA. A opção “Require MFA for all direct UI logins”, em Setup > Session Settings, fica permanentemente ativa e bloqueada para edição, tanto em produção quanto em sandbox. A exigência abrange todos os utilizadores internos (com licença de employee), em logins diretos e via SSO, e passa agora a incluir também as sandboxes (antes excluídas).
Há três consequências práticas:
1 – A permissão “Waive MFA for Exempt Users” deixa de funcionar automaticamente e os utilizadores que dependiam dela serão obrigados a registar um método no primeiro login.
2 – A regra abrange todos os logins de interface, incluindo navegadores móveis e desktop; apenas os acessos exclusivamente via API continuam isentos.
3 – Para quem usa SSO: não basta que o seu fornecedor de identidade (IdP) exija MFA; deve-se também comunicar à Salesforce por meio dos sinais padrão ACR/AMR no token OpenID Connect ou na resposta SAML. Se o sinal não chegar, a Salesforce bloqueia o acesso e exige sua própria MFA.
2. Administradores: MFA resistente a phishing
Para utilizadores privilegiados, o nível de exigência sobe. A regra não se aplica apenas ao perfil de Administrador do Sistema: abrange qualquer utilizador com permissões como Modify All Data, View All Data, Customize Application ou Author Apex.
Para este grupo, só são aceites métodos baseados em WebAuthn/FIDO2: autenticadores integrados no dispositivo (Windows Hello, Touch ID, Face ID) ou chaves de segurança físicas (YubiKey, Google Titan). Ficam bloqueados os métodos baseados em códigos partilhados ou em canais inseguros: apps TOTP como o Google ou o Microsoft Authenticator, notificações push, SMS e chamadas de voz (pelo risco de SIM swapping) e códigos por e-mail.
Na prática, um administrador que tente entrar sem um método FIDO2 registado será direcionado para um ecrã de bloqueio que exige o registo imediato de uma chave ou de biometria. Métodos TOTP anteriores são ignorados.
Em ambientes com SSO, o IdP tem de exigir FIDO2/WebAuthn e reportar a força da autenticação; caso contrário, a Salesforce nega o acesso, mesmo que o IdP o tenha permitido. Por isso, recomendamos sempre uma conta de emergência (“break-glass”) fora do SSO, com uma chave física guardada em cofre, para garantir o acesso caso o IdP falhe.
3. Dados: proteção em relatórios, anomalias e exportações
Os relatórios e dashboards são alvos preferenciais de exfiltração de dados. A Salesforce introduziu uma reautenticação baseada no tempo (step-up authentication): sempre que um utilizador vê, executa ou exporta um relatório, o sistema verifica há quanto tempo validou a identidade. A janela padrão é de 120 minutos e pode ser configurada pelo administrador. Se o utilizador não tiver um método de MFA e o código de contingência não puder ser enviado ou verificado, a ação é bloqueada, pois o sistema prioriza a proteção dos dados.
Em paralelo, um modelo de deteção de anomalias analisa o comportamento histórico de cada utilizador (que relatórios acede, a que horas, que volume e frequência). Perante um comportamento invulgar, como a transferência massiva de uma lista de clientes a uma hora atípica, isso representa um desafio imediato e zera a janela de tempo restante.
Por fim, para clientes com Salesforce Shield ou Event Monitoring, uma Política de Segurança de Transação (TSP) passa a exigir reautenticação nas exportações com mais de 10.000 registos. Gerir estas políticas requer a nova permissão “Modify Transaction Security Policy”, combinada com “Customize Application”. Conexões provenientes de redes de alto risco, proxies anónimos ou VPNs de ocultação de IP resultam no congelamento da conta e na revogação dos tokens, com alerta por e-mail ao administrador e ao utilizador.
4. O ponto crítico: contas de integração com perfil de Admin
É aqui que muitas equipas serão apanhadas de surpresa. Integrações e ferramentas de CI/CD — Jenkins, GitHub Actions, Copado, Bitbucket, MuleSoft — frequentemente foram configuradas com o fluxo de utilizador e a respetiva senha, associadas a um perfil de Administrador. Como esse perfil se enquadra na categoria de utilizador privilegiado, passa a exigir MFA resistente ao phishing em qualquer interface. Um script não consegue colocar o dedo num leitor de biometria nem ligar uma chave física a um servidor na nuvem: a ligação é rejeitada.
O impacto é direto. Contas de serviço de deploy precisam da permissão Author Apex, que também as torna privilegiadas, logo, o pipeline trava ao autenticar. Com isso, sincronizações que extraem dados simulando navegação na interface podem ser congeladas pelo step-up, gerando timeouts.
A solução passa por tirar o perfil de Admin dos robôs e adotar autenticação adequada aos sistemas: usar as Salesforce Integration Licenses (as duas primeiras costumam ser gratuitas e impedem o login na interface), migrar para fluxos OAuth 2.0 JWT Bearer ou Client Credentials, que assentam em certificados e tokens em vez de senhas, e aplicar o princípio do privilégio mínimo, criando perfis específicos por integração.
5. Cronograma de enforcement
A aplicação é faseada.
6. Checklist de preparação
Recomendamos quatro passos.
- Auditar e inventariar: identificar quem ainda entra sem MFA e mapear os perfis com permissões críticas (com SOQL ou o Optimizer); para exceções legítimas, como RPA, abrir caso no suporte antes do prazo.
- Equipar e ativar passkeys: distribuir chaves FIDO2 aos administradores e ativar o login sem palavra-passe com passkeys para os utilizadores padrão.
- Definir recuperação de acessos: preparar a geração interna de códigos temporários de verificação e a conta break-glass.
- Pré-registar e testar: comunicar internamente, solicitar o registo dos métodos antes da data e migrar os pipelines de CI/CD para OAuth seguro.
Conclusão
Estas mudanças são exigentes, mas a leitura certa é positiva: bem preparada, a sua org fica mais resistente a ataques e mais alinhada às melhores práticas de segurança. A diferença entre uma transição tranquila e um apagão de acessos está no planeamento e no tempo que ainda resta.
Na Biz2People ajudamos a fazer o diagnóstico, a gerir as equipas e a migrar as integrações antes dos prazos, sem interromper a operação. Agende um diagnóstico de segurança Salesforce e prepare a sua org com confiança.
