Step-up Authentication em relatórios: Salesforce recua e ajusta o que estava travando o dia a dia
Depois do atrito causado pelo rollout inicial, engenharia reduz o escopo do desafio de autenticação e corrige quebras em dashboards, Login As e automações
Salesforce ajustou o Step-up Authentication para relatórios e dashboards depois que a primeira versão gerou fricção real em orgs de sandbox. Agora o desafio só aparece na exportação de relatórios, e uma série de exceções foi criada para dashboards embutidos, Login As, automações e acesso mobile.
O que mudou de fato
Salesforce começou a liberar o Step-up Authentication para ações de relatório ainda em sandbox, como uma camada extra de proteção contra sequestro de sessão. A lógica é simples: mesmo que alguém consiga um session identifier válido, esse token sozinho não seria suficiente para puxar dados sensíveis de um relatório sem passar por uma verificação adicional.
O problema é que a primeira versão dessa exigência foi ampla demais. Ela passou a monitorar praticamente qualquer acesso a relatórios e dashboards, e isso gerou fricção em fluxos que não tinham nada de suspeito: dashboards em Home Page quebrando com mensagem de erro, Login As disparando MFA para o usuário final em vez do admin, jobs agendados travando por falta de sessão interativa. Ou seja, o tipo de problema que não aparece em ambiente de demonstração, mas explode assim que cai numa org real com automação, portais e suporte no dia a dia.
Os ajustes anunciados
A resposta da Salesforce veio em duas frentes. A primeira foi reduzir o gatilho do Step-up: em vez de vigiar qualquer acesso a relatório ou dashboard, a autenticação adicional passa a disparar apenas na exportação de relatório. Isso já corta boa parte do volume de prompts que apareciam sem necessidade.
Além disso, a plataforma passou a respeitar controles de IP já configurados pelo cliente. Se o profile ou a org tem restrição de IP range, ou se a opção de travar sessão ao IP de origem está ativa em Session Settings, essa sessão fica isenta do desafio. Faz sentido: se a própria org já reduziu a superfície de ataque via IP, empilhar mais uma camada ali é redundância, não segurança.
A segunda frente foi corrigir comportamentos quebrados que apareceram durante o rollout em sandbox:
- Dashboards embutidos em páginas Lightning App Builder pararam de mostrar erro genérico e agora funcionam sem interrupção, já que esses componentes não têm como exibir um prompt interativo.
- Login As volta a funcionar como ferramenta de suporte, já que usuários proxy agora ficam isentos do Step-up, seguindo a mesma lógica já usada para exceção de MFA.
- Jobs em background, integrações compartilhadas e relatórios agendados passam a ignorar o Step-up via verificação de sessão nula, evitando que automação pare por falta de interação humana.
- Experience Cloud e aplicativos mobile também foram isentos da exigência, preservando a experiência de parceiros, clientes externos e usuários em campo.
Leitura prática para quem administra a org
O ponto mais importante aqui é operacional: nenhuma ação é necessária por parte do admin. As mudanças já foram aplicadas no lado da plataforma. Se alguém desativou dashboards embutidos ou pausou relatórios agendados como gambiarra para contornar o problema, dá para reverter esse workaround com segurança.
Isso não muda a arquitetura de segurança de forma estrutural, mas é um lembrete de como controle de sessão, MFA e políticas de step-up interagem com automação, portais e suporte técnico. Vale revisar Session Settings e políticas de IP range da org, porque são exatamente esses controles que agora determinam se o Step-up aparece ou não para os usuários.
O que ainda fica em aberto
O anúncio é claro sobre o que mudou, mas não detalha cronograma de expansão para produção, nem como isso vai se comportar em cenários mais específicos, como relatórios acessados via API customizada ou integrações de terceiros que exportam dados programaticamente. Vale acompanhar o Known Issue oficial antes de tratar esse ajuste como definitivo em toda a base de clientes.
Esse tipo de ajuste importa porque mexe direto em fluxos que sustentam operação diária: dashboards em Home Page, Login As para suporte, jobs agendados e integrações. Quando uma camada de segurança nova quebra automação sem aviso, quem sofre é o time de suporte e o admin que recebe o chamado. Vale entender o que mudou antes que o assunto vire ticket recorrente.
Vale tratar este caso como um lembrete de que segurança-por-padrão precisa ser testada contra fluxos reais de projeto antes de virar exigência ampla, não só validada em cenário controlado de sandbox.
Revise as configurações de Session Settings e IP range restrictions da org, já que são elas que determinam se uma sessão fica isenta do Step-up. Se você desativou dashboards embutidos, pausou relatórios agendados ou encontrou problema com Login As por causa da versão anterior do Step-up, pode reativar esses recursos com segurança, já que as correções já foram aplicadas do lado da plataforma.
O texto não detalha prazo de expansão para produção nem cobre cenários de exportação via API ou integrações customizadas de terceiros. Antes de comunicar ao negócio que o problema está resolvido de forma definitiva, vale acompanhar o artigo de Known Issue da Salesforce e validar o comportamento na própria org.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.