Ontem, 20 de julho de 2026, a Salesforce iniciou o enforcement de autenticação multifator em produção para todos os employee users. Não foi um corte único: o rollout acontece em ondas escalonadas, o que significa que boa parte das orgs vai descobrir o impacto ao longo desta semana — e não no dia do anúncio.
Em paralelo, desde 1º de julho vale a exigência mais dura da mesma política: para usuários privilegiados — System Administrators e perfis com permissões sensíveis — a MFA precisa ser resistente a phishing. Na prática, TOTP e push deixaram de contar. Passam apenas security keys, autenticadores embutidos no dispositivo, passkeys e autenticação por certificado. O aplicativo autenticador que seu admin usa há três anos pode não ser mais suficiente. O sandbox all-employee, vale lembrar, foi reiniciado em 6 de julho — quem testou lá já viu o comportamento.
Até aqui é assunto de segurança, e a maior parte dos times se preparou. O ponto cego é outro, e é de arquitetura: a conta que roda as suas integrações. Este artigo é sobre ela.
1. O que passou a valer e quando
Três datas organizam o calendário, e confundi-las é a origem da maior parte das dúvidas que aparecem nesta semana.
1º de julho de 2026 — MFA resistente a phishing para usuários privilegiados. Aplica-se a System Admins e a perfis com permissões sensíveis. É a mudança de qualidade do fator: não basta ter segundo fator, ele precisa ser vinculado ao domínio e imune a repasse. TOTP (o código de seis dígitos) e notificação push podem ser interceptados por um proxy de phishing em tempo real — por isso saíram da lista.
6 de julho de 2026 — sandbox all-employee reiniciado. Janela de teste do comportamento antes de produção.
20 de julho de 2026 — enforcement em produção para todos os employee users, em ondas. Este é o ponto crítico operacional. Rollout em ondas significa que a ausência de incidente hoje não é evidência de que a org está fora do escopo — apenas de que a onda dela ainda não chegou. É um erro clássico de leitura: o time confere na segunda, não vê nada quebrado, e conclui que estava tudo certo.
2. Para admins: o que saiu e o que entrou
Para quem tem perfil privilegiado, a lista mudou.
Saíram: códigos TOTP de aplicativos autenticadores e aprovação por notificação push. Continuam sendo MFA, mas não são resistentes a phishing — um site clonado que pede o código e o repassa em tempo real derruba os dois.
Entraram como aceitos: security keys físicas (FIDO2/WebAuthn), autenticadores embutidos no dispositivo (Touch ID, Windows Hello, Face ID), passkeys e autenticação por certificado. O que os une é o vínculo criptográfico com o domínio: a chave só assina para o site legítimo, então um proxy de phishing não consegue reaproveitar a credencial.
A consequência prática é logística, não técnica: quem tem admins distribuídos precisa garantir dispositivo compatível e um caminho de recuperação para cada um. E aqui aparece o primeiro risco silencioso — o admin que resolve o problema dele criando uma exceção genérica para "destravar" e esquece de revisá-la depois.
3. Para integrações: o que vale e o que acabou
Esta é a seção que decide se a semana será tranquila ou não.
Logins API-only não estão no escopo. Uma integração que autentica exclusivamente via API, sem sessão de interface, não é alcançada pelo enforcement de MFA de employee users. Essa é a boa notícia — e a razão pela qual muita gente conclui, cedo demais, que não tem nada a fazer.
A isenção Waive MFA continua existindo. Casos legítimos que não comportam MFA seguem podendo ser isentos.
Mas a isenção self-service por permissão deixa de existir depois do enforcement. É a mudança que mais impacta o dia a dia: o caminho que consistia em atribuir uma permissão e resolver internamente não estará mais disponível. O caminho suportado passou a ser abrir caso no Support — o que tem duas implicações. Primeira: existe latência entre pedir e receber, e latência durante um incidente é downtime. Segunda: a isenção deixa de ser uma configuração invisível e passa a ser um registro auditável — o que é melhor para governança e pior para quem tratava isenção como atalho.
A leitura correta é: o escopo protege a integração bem desenhada. Quem tem credencial dedicada, API-only e sem uso humano está confortável. Quem não tem, descobre agora.
4. O ponto cego: a conta híbrida
O risco real não é o admin travar na porta. Admin travado é ruidoso: ele liga, abre chamado, alguém resolve em uma hora. O risco é a conta que finge ser de integração.
Toda operação com alguns anos de Salesforce tem pelo menos uma. A conta "de serviço" criada há dois anos, que também é usada por uma pessoa do time comercial para rodar um relatório todo fim de mês. O usuário de middleware que alguém acessa pela interface "só para ver se o job passou". O perfil compartilhado entre três fornecedores diferentes, porque criar um por fornecedor "ia demorar". A credencial que um ex-integrador configurou e ninguém sabe onde está documentada.
Contas híbridas — metade robô, metade gente — são exatamente as que quebram em um enforcement em ondas. E quebram em silêncio. Não existe usuário reclamando, porque não existe usuário: existe um job que parou. O sintoma aparece dois dias depois, deslocado da causa, como pedido não sincronizado, estoque desatualizado ou um relatório de conciliação que não fecha. Aí começa a investigação pelo lugar errado — no e-commerce, no ERP, na fila — porque ninguém liga um pedido travado a uma política de autenticação que mudou na segunda-feira.
Há um agravante estrutural: quase ninguém mantém inventário de identidades de serviço. Existe inventário de pessoas, porque RH cuida disso na admissão e no desligamento. Identidade de serviço nasce no meio de um projeto, é criada por quem estava implementando, e não tem dono nem ciclo de vida. É por isso que o custo desta transição não recai sobre o login das pessoas — recai sobre um inventário que a maioria das empresas nunca fez.
5. As 4 checagens para rodar esta semana
Quatro perguntas, respondíveis em algumas horas, que cobrem a maior parte do risco.
1. Quais contas de integração ainda têm login humano associado? Liste os usuários que suas integrações utilizam e verifique o histórico de login por origem. Se aparece acesso via interface em qualquer um deles, essa conta é híbrida — e híbrida é o caso que quebra. O tratamento é separar: credencial API-only para a integração, usuário nominal para a pessoa. Não é elegância de arquitetura; é a diferença entre um job continuar rodando ou não.
2. Cada integração tem credencial própria e rastreável? Ou existe uma conta compartilhada entre sistemas — e possivelmente entre fornecedores? Credencial compartilhada tem três problemas que aparecem juntos: você não sabe qual sistema fez qual alteração, não consegue revogar o acesso de um sem derrubar os outros, e não consegue rotacionar sem coordenar um desligamento coletivo. Uma credencial por integração, com escopo mínimo de permissão, é o padrão que torna todo o resto possível.
3. Existe runbook de lockout? Se uma conta de integração for bloqueada às 3h de um sábado, três respostas precisam existir por escrito: quem destrava, com qual método, e em quanto tempo. Se a resposta envolve abrir caso no Support, o tempo de resposta faz parte do seu SLA — e precisa estar documentado antes, não descoberto durante. Isenções concedidas também entram no runbook: qual conta, qual justificativa, qual data de revisão.
4. Quando uma integração falhar por autenticação, o alerta chega ao canal do time? Ou some no log? Essa é a checagem que mais frequentemente falha. Erro de autenticação costuma ser tratado como erro de infraestrutura e cair em um dashboard que ninguém olha. O padrão que funciona é ter falha de auth como classe própria de alerta, roteada para o canal onde o time efetivamente está, com identificação de qual integração e qual credencial. Sem isso, você fica dependendo de o cliente avisar.
6. Por que enforcement em ondas quebra em silêncio
Vale entender o mecanismo, porque ele se repete em toda mudança de plataforma feita por rollout gradual.
Uma mudança com data única cria um evento: todo mundo olha, todo mundo testa, o incidente — se houver — é imediato e correlacionado. Um rollout em ondas dilui o evento no tempo. A organização confere no dia do anúncio, não vê nada, e desmobiliza a atenção. Quando a onda chega, três dias depois, ninguém está mais olhando — e o sintoma aparece já deslocado da causa.
É por isso que a resposta correta a um enforcement em ondas não é "testar no dia". É instrumentar: garantir que falha de autenticação seja visível e atribuível durante toda a janela de rollout, que pode se estender por semanas. A pergunta não é "quebrou hoje?", é "se quebrar em qualquer dia das próximas três semanas, eu fico sabendo em minutos?".
Vale registrar o que isso diz sobre o setor, sem alarmismo: a Salesforce está empurrando o mercado para identidade forte por padrão, e isso é positivo — MFA resistente a phishing fecha uma classe inteira de ataque que continua sendo a mais eficaz contra empresas. O que a transição revela é que o custo não está onde se imaginava. Está no inventário de identidades de serviço que cresceu sem governança durante anos de integrações entregues sob prazo.
7. Como a CCX ajuda: inventário de identidades de serviço, rotação e observabilidade de auth
O trabalho que resolve isso não é um projeto de segurança de seis meses — é um levantamento objetivo seguido de correções pontuais. É assim que a prática de Security Engineering & Cybersecurity da CCX aborda o problema: identity management, OAuth2, gestão de segredos com Vault, revisão de acessos privilegiados e compliance. Na prática, para este cenário: mapear toda conta que suas integrações usam, identificar quais têm login humano associado, separar as híbridas, aplicar escopo mínimo de permissão e estabelecer rotação com prazo definido — com a isenção, quando necessária, documentada e com data de revisão em vez de esquecida na configuração.
Do lado da conectividade, a prática de Integrações & APIs Enterprise garante o padrão que evita o problema se repetir: credencial dedicada por integração, com escopo próprio e trilha de auditoria, em arquiteturas REST, GraphQL e gRPC ou event-driven com Kafka e RabbitMQ. Isso vale tanto para as integrações do Salesforce quanto para o resto da malha — CRM, ERP, gateways de pagamento e marketplaces.
E a quarta checagem — o alerta que chega ao time — é trabalho de Observabilidade 360°: monitoramento com Datadog, Grafana, Prometheus e Sentry, tracing distribuído com OpenTelemetry e alertas roteados por classe de erro. Falha de autenticação deixa de ser uma linha de log e passa a ser um alerta atribuível, com nome da integração e da credencial, no canal onde o time está.
Quando a camada Salesforce em si precisa de ajuste — perfis, permissões, integrações com Marketing, Service e Sales Cloud, ou unificação de dados no Data Cloud — a expertise em Salesforce Commerce Cloud e Data Cloud entra junto, para que a correção de identidade não esbarre em uma limitação de modelo de permissão descoberta no meio do caminho.
Enforcement em ondas não avisa: ele só para de funcionar. Falar com especialista Salesforce →
8. Perguntas frequentes
O enforcement de MFA de 20/07 afeta usuários de integração?
Logins API-only não estão no escopo do enforcement de employee users, então uma integração que autentica exclusivamente via API e nunca acessa a interface não é alcançada. O risco está nas contas híbridas — aquelas que a empresa trata como conta de serviço mas que também têm uso humano por interface. Essas estão no escopo e podem parar durante a janela de rollout.
A isenção Waive MFA ainda funciona?
A isenção continua existindo para casos que legitimamente não comportam MFA. O que muda é o caminho: a isenção self-service por atribuição de permissão deixa de existir após o enforcement, e o procedimento suportado passa a ser abrir caso no Support. Isso adiciona latência ao processo, o que importa quando a isenção é necessária durante um incidente — por isso o runbook precisa existir antes.
Por que TOTP e push não contam mais para admins?
Porque não são resistentes a phishing. Um proxy de phishing em tempo real consegue apresentar uma página clonada, capturar o código de seis dígitos ou induzir a aprovação do push, e reutilizar a sessão. Security keys, passkeys, autenticadores embutidos e autenticação por certificado têm vínculo criptográfico com o domínio: a chave só assina para o site legítimo, o que quebra esse ataque.
Como identificar contas de integração híbridas?
Liste os usuários que as integrações utilizam e cruze com o histórico de login por origem: se houver acesso via interface, a conta é híbrida. O tratamento é separar em duas identidades — credencial API-only dedicada para a integração e usuário nominal para a pessoa — atribuindo a cada uma o escopo mínimo de permissão necessário.
O que precisa ter um runbook de lockout?
Três respostas por escrito: quem tem autoridade para destravar, por qual método, e em quanto tempo. Se o método envolve abrir caso no Support, o tempo de resposta faz parte do seu SLA e precisa estar registrado. O runbook também lista as isenções concedidas — qual conta, qual justificativa e qual a data de revisão — para que nenhuma isenção temporária vire permanente por esquecimento.