{"id":13511,"date":"2026-06-23T15:25:06","date_gmt":"2026-06-23T14:25:06","guid":{"rendered":"https:\/\/www.biz2people.com\/?p=13511"},"modified":"2026-06-23T15:25:08","modified_gmt":"2026-06-23T14:25:08","slug":"mfa-obrigatoria-na-salesforce-o-guia-essencial-para-2026","status":"publish","type":"post","link":"https:\/\/www.biz2people.com\/pt-pt\/produtividade-performance\/mfa-obrigatoria-na-salesforce-o-guia-essencial-para-2026\/","title":{"rendered":"MFA Obrigat\u00f3ria na Salesforce: O guia essencial para 2026"},"content":{"rendered":"\n

A MFA obrigat\u00f3ria na Salesforce chega em 2026 e muda as regras do jogo: o que, durante anos, foi apenas uma recomenda\u00e7\u00e3o passa a ser uma regra permanente e traz consigo um conjunto de mudan\u00e7as que v\u00e3o muito al\u00e9m de um simples segundo fator. Acessos de administradores podem ser bloqueados, relat\u00f3rios passam a exigir nova valida\u00e7\u00e3o e integra\u00e7\u00f5es antigas correm o risco de deixar de funcionar de um dia para o outro. Pode confirmar os prazos na documenta\u00e7\u00e3o oficial da Salesforce<\/a>.<\/p>\n\n\n\n

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\u00e1 ser colocado em pr\u00e1tica.<\/p>\n\n\n\n

1. Identidade: MFA obrigat\u00f3ria para todos os utilizadores<\/h2>\n\n\n\n

A Salesforce removeu a possibilidade de desativar a MFA. A op\u00e7\u00e3o “Require MFA for all direct UI logins”, em Setup > Session Settings, fica permanentemente ativa e bloqueada para edi\u00e7\u00e3o, tanto em produ\u00e7\u00e3o quanto em sandbox. A exig\u00eancia abrange todos os utilizadores internos (com licen\u00e7a de employee), em logins diretos e via SSO, e passa agora a incluir tamb\u00e9m as sandboxes (antes exclu\u00eddas).<\/p>\n\n\n\n

H\u00e1 tr\u00eas consequ\u00eancias pr\u00e1ticas:<\/p>\n\n\n\n

1 – A permiss\u00e3o “Waive MFA for Exempt Users” deixa de funcionar automaticamente e os utilizadores que dependiam dela ser\u00e3o obrigados a registar um m\u00e9todo no primeiro login.<\/p>\n\n\n\n

2 – A regra abrange todos os logins de interface, incluindo navegadores m\u00f3veis e desktop; apenas os acessos exclusivamente via API continuam isentos.<\/p>\n\n\n\n

3 – Para quem usa SSO: n\u00e3o basta que o seu fornecedor de identidade (IdP) exija MFA; deve-se tamb\u00e9m comunicar \u00e0 Salesforce por meio dos sinais padr\u00e3o ACR\/AMR no token OpenID Connect ou na resposta SAML. Se o sinal n\u00e3o chegar, a Salesforce bloqueia o acesso e exige sua pr\u00f3pria MFA.<\/p>\n\n\n\n

<\/p>\n\n\n\n

2. Administradores: MFA resistente a phishing<\/h2>\n\n\n\n

Para utilizadores privilegiados, o n\u00edvel de exig\u00eancia sobe. A regra n\u00e3o se aplica apenas ao perfil de Administrador do Sistema: abrange qualquer utilizador com permiss\u00f5es como Modify All Data, View All Data, Customize Application ou Author Apex.<\/p>\n\n\n\n

Para este grupo, s\u00f3 s\u00e3o aceites m\u00e9todos baseados em WebAuthn\/FIDO2: autenticadores integrados no dispositivo (Windows Hello, Touch ID, Face ID) ou chaves de seguran\u00e7a f\u00edsicas (YubiKey, Google Titan). Ficam bloqueados os m\u00e9todos baseados em c\u00f3digos partilhados ou em canais inseguros: apps TOTP como o Google ou o Microsoft Authenticator, notifica\u00e7\u00f5es push, SMS e chamadas de voz (pelo risco de SIM swapping) e c\u00f3digos por e-mail.<\/p>\n\n\n\n

Na pr\u00e1tica, um administrador que tente entrar sem um m\u00e9todo FIDO2 registado ser\u00e1 direcionado para um ecr\u00e3 de bloqueio que exige o registo imediato de uma chave ou de biometria. M\u00e9todos TOTP anteriores s\u00e3o ignorados.<\/p>\n\n\n\n

Em ambientes com SSO, o IdP tem de exigir FIDO2\/WebAuthn e reportar a for\u00e7a da autentica\u00e7\u00e3o; caso contr\u00e1rio, a Salesforce nega o acesso, mesmo que o IdP o tenha permitido. Por isso, recomendamos sempre uma conta de emerg\u00eancia (“break-glass”) fora do SSO, com uma chave f\u00edsica guardada em cofre, para garantir o acesso caso o IdP falhe.<\/p>\n\n\n\n


3. Dados: prote\u00e7\u00e3o em relat\u00f3rios, anomalias e exporta\u00e7\u00f5es<\/h2>\n\n\n\n

Os relat\u00f3rios e dashboards s\u00e3o alvos preferenciais de exfiltra\u00e7\u00e3o de dados. A Salesforce introduziu uma reautentica\u00e7\u00e3o baseada no tempo (step-up authentication): sempre que um utilizador v\u00ea, executa ou exporta um relat\u00f3rio, o sistema verifica h\u00e1 quanto tempo validou a identidade. A janela padr\u00e3o \u00e9 de 120 minutos e pode ser configurada pelo administrador. Se o utilizador n\u00e3o tiver um m\u00e9todo de MFA e o c\u00f3digo de conting\u00eancia n\u00e3o puder ser enviado ou verificado, a a\u00e7\u00e3o \u00e9 bloqueada, pois o sistema prioriza a prote\u00e7\u00e3o dos dados.<\/p>\n\n\n\n

Em paralelo, um modelo de dete\u00e7\u00e3o de anomalias analisa o comportamento hist\u00f3rico de cada utilizador (que relat\u00f3rios acede, a que horas, que volume e frequ\u00eancia). Perante um comportamento invulgar, como a transfer\u00eancia massiva de uma lista de clientes a uma hora at\u00edpica, isso representa um desafio imediato e zera a janela de tempo restante.<\/p>\n\n\n\n

Por fim, para clientes com Salesforce Shield ou Event Monitoring, uma Pol\u00edtica de Seguran\u00e7a de Transa\u00e7\u00e3o (TSP) passa a exigir reautentica\u00e7\u00e3o nas exporta\u00e7\u00f5es com mais de 10.000 registos. Gerir estas pol\u00edticas requer a nova permiss\u00e3o “Modify Transaction Security Policy”, combinada com “Customize Application”. Conex\u00f5es provenientes de redes de alto risco, proxies an\u00f3nimos ou VPNs de oculta\u00e7\u00e3o de IP resultam no congelamento da conta e na revoga\u00e7\u00e3o dos tokens, com alerta por e-mail ao administrador e ao utilizador.<\/p>\n\n\n\n


4. O ponto cr\u00edtico: contas de integra\u00e7\u00e3o com perfil de Admin<\/h2>\n\n\n\n

\u00c9 aqui que muitas equipas ser\u00e3o apanhadas de surpresa. Integra\u00e7\u00f5es e ferramentas de CI\/CD \u2014 Jenkins, GitHub Actions, Copado, Bitbucket, MuleSoft \u2014 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\u00e3o consegue colocar o dedo num leitor de biometria nem ligar uma chave f\u00edsica a um servidor na nuvem: a liga\u00e7\u00e3o \u00e9 rejeitada.<\/p>\n\n\n\n

O impacto \u00e9 direto. Contas de servi\u00e7o de deploy precisam da permiss\u00e3o Author Apex, que tamb\u00e9m as torna privilegiadas, logo, o pipeline trava ao autenticar. Com isso, sincroniza\u00e7\u00f5es que extraem dados simulando navega\u00e7\u00e3o na interface podem ser congeladas pelo step-up, gerando timeouts.<\/p>\n\n\n\n

A solu\u00e7\u00e3o passa por tirar o perfil de Admin dos rob\u00f4s e adotar autentica\u00e7\u00e3o 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\u00edpio do privil\u00e9gio m\u00ednimo, criando perfis espec\u00edficos por integra\u00e7\u00e3o.<\/p>\n\n\n\n

<\/p>\n\n\n\n

5. Cronograma de enforcement<\/h2>\n\n\n\n

A aplica\u00e7\u00e3o \u00e9 faseada.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

6. Checklist de prepara\u00e7\u00e3o<\/h2>\n\n\n\n

Recomendamos quatro passos.<\/p>\n\n\n\n

    \n
  1. Auditar e inventariar:<\/strong> identificar quem ainda entra sem MFA e mapear os perfis com permiss\u00f5es cr\u00edticas (com SOQL ou o Optimizer); para exce\u00e7\u00f5es leg\u00edtimas, como RPA, abrir caso no suporte antes do prazo.<\/li>\n\n\n\n
  2. Equipar e ativar passkeys:<\/strong> distribuir chaves FIDO2 aos administradores e ativar o login sem palavra-passe com passkeys para os utilizadores padr\u00e3o.<\/li>\n\n\n\n
  3. Definir recupera\u00e7\u00e3o de acessos:<\/strong> preparar a gera\u00e7\u00e3o interna de c\u00f3digos tempor\u00e1rios de verifica\u00e7\u00e3o e a conta break-glass.<\/li>\n\n\n\n
  4. Pr\u00e9-registar e testar:<\/strong> comunicar internamente, solicitar o registo dos m\u00e9todos antes da data e migrar os pipelines de CI\/CD para OAuth seguro.<\/li>\n<\/ol>\n\n\n\n

    Conclus\u00e3o<\/h3>\n\n\n\n

    Estas mudan\u00e7as s\u00e3o exigentes, mas a leitura certa \u00e9 positiva: bem preparada, a sua org fica mais resistente a ataques e mais alinhada \u00e0s melhores pr\u00e1ticas de seguran\u00e7a. A diferen\u00e7a entre uma transi\u00e7\u00e3o tranquila e um apag\u00e3o de acessos est\u00e1 no planeamento e no tempo que ainda resta.<\/p>\n\n\n\n

    Na Biz2People ajudamos a fazer o diagn\u00f3stico, a gerir as equipas e a migrar as integra\u00e7\u00f5es antes dos prazos, sem interromper a opera\u00e7\u00e3o. Agende um diagn\u00f3stico de seguran\u00e7a Salesforce e prepare a sua org com confian\u00e7a.<\/strong><\/p>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    A MFA obrigat\u00f3ria na Salesforce chega em 2026 e muda as regras do jogo: o que, durante anos, foi apenas uma recomenda\u00e7\u00e3o passa a ser uma regra permanente e traz consigo um conjunto de mudan\u00e7as que v\u00e3o muito al\u00e9m de um simples segundo fator. Acessos de administradores podem ser bloqueados, relat\u00f3rios passam a exigir nova […]<\/p>\n","protected":false},"author":7,"featured_media":13526,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-13511","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-produtividade-performance"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t