Salesforce report export step-up authentication.

Salesforce is adding step-up authentication to some report export actions. Admins should review export access, MFA readiness, and sensitive report folders now.

Salesforce is adding step-up authentication to report actions. Admins should treat this as a data access control change, not a login change. And it is no longer a future item. Production enforcement of the main control began July 1, 2026.

There are two separate controls here, on two different timelines. The original coverage of this often blurs them. They are not the same, and they need different preparation.

Two controls, not one

1. Time-based step-up on report actions. This is the larger change and affects the most users. Even after logging in with MFA, a user must complete an additional step-up challenge to export a report once a configurable amount of time has passed since their last challenge. The default window is 120 minutes. Admins can shorten it. This is a mandatory, secure-by-default control, not a risk model. It applies to routine exports, not just suspicious ones. See the Salesforce Help article Prepare for the upcoming Step-up Authentication requirements on Report Actions.
2. Step-up on anomalous report export. This is a machine-learning control. It watches for unusual export behavior (large volumes, unusual times, unusual patterns) and challenges the user when it sees risk, regardless of when they last verified. This is the "dynamic security control" language. See Prepare for Step-up Authentication in Anomalous Report Export.

Most day-to-day impact comes from the first control. The second adds a risk-based layer on top.

Enforcement dates

These moved once already. Salesforce revised the report step-up dates on June 2, 2026, which some teams heard as the requirement being "pushed out." Current dates:

Time-based step-up on report actions

• Enforced in sandboxes: June 17, 2026 (staggered ~7 days)
• Enforced in production: July 1, 2026 (staggered ~30 days)

Anomalous export step-up plus default Transaction Security Policy

• Enforced in sandboxes: June 22, 2026
• Enforced in production: July 13, 2026

The Transaction Security Policy piece applies only to orgs with Salesforce Shield or Event Monitoring. For those orgs, if no qualifying policy exists, Salesforce auto-creates one that triggers on report exports over 10,000 records. Setting your own thresholds first is better than accepting the default.

LOVALTO verifies enforcement dates against the current Salesforce Help articles and the Security-Related Product Updates page before advising a client to publish internal deadlines. These dates have changed once and can change again. Customer impact also depends on edition, identity setup, and instance release timing.

Scope: export, print, and possibly view

The current documented policy, "Require periodic step-up authentication when exporting or printing," challenges on export or print, and lets users view reports and dashboards without a challenge. An earlier, broader variant challenged on viewing and running reports too. Before enforcement, admins may see both options on the Identity Verification page under Session Security Level Policies. Confirm which policy your org has selected. Do not assume viewing is exempt until you have checked.

The control applies to UI report actions. It does not cover every extraction path. Data Loader, API jobs, CRM Analytics exports, managed package exports, scheduled jobs, and integration syncs have different controls. API-only integration users are exempt. Integration users that log in through the UI instead of the API are not, and should be audited. Each path needs its own review.

Known breakage to plan for

Partners testing in sandbox have reported real issues. Plan around these:

• Login As is affected. When an admin logs in as a user and triggers a step-up challenge, the prompt goes to the impersonated user, not the admin. This limits admin troubleshooting of report and dashboard issues.
• Embedded dashboards. Dashboards on Home or other Lightning pages can error until the user has completed a recent step-up from the Reports or Dashboards tab.
• Scheduled report distribution. Apps and jobs that export reports on a schedule for external partners or non-Salesforce users can break, because there is no interactive session to complete the challenge. Confirm your report-distribution tooling has a compatible version.
• SSO users. SSO login does not start a step-up session. SSO users can get challenged even seconds after signing in, and SSO users without a registered Salesforce verifier fall back to email or SMS one-time passwords.

The framework is fail-closed. If the MFA service is unavailable, the report action is blocked.

Why this matters for mid-market teams

Mid-market teams often use report exports as an operating layer. They pull CSV or Excel from Salesforce, then sort, enrich, reconcile, or move the data elsewhere. That pattern works, and it creates risk when exports include customer, financial, health, claims, policy, or partner data.

The issue is not the prompt. It is unmanaged dependence on exports, and access design that is broader than the job requires.

If an executive dashboard depends on a weekly CSV pull, document the process. If finance reconciles Salesforce data in a spreadsheet, know the exported fields. If a support manager exports Case records for staffing, know the folder and owner. Step-up makes these hidden dependencies and weak access design easier to find. If too many users can export broad reports, narrow that access.

What to review first

Start with users, permissions, folders, and sensitive fields. This is a focused review, not a project.

First, identify users who regularly export reports. Check operational patterns, not just the admin team. The heaviest exporter is often a finance analyst, support manager, sales ops lead, or compliance coordinator.

Next, review who can export. Check export-related permissions across profiles, permission sets, and permission set groups. Most export risk sits with standard business users who accumulated access over time, not with System Administrators.

Then review report folders built on objects that carry sensitive data: Contact, Lead, Account, Opportunity, Case, Campaign Member, Person Account, and any insurance, claims, payment, billing, or health custom objects in use. Also review reports containing fields like SSN, date of birth, policy or claim number, bank details, health status, address, phone, email, or free-text notes. The object name alone is not enough. A Contact report with name and owner is not the same as one with date of birth, phone, and notes.

How to test in sandbox

Test with real user roles, not only System Administrator. The goal is to understand the workflow, not to prove an admin can export.

Pick five to 10 common export workflows across finance, sales ops, support, compliance, and management. For each, record the user, report, folder, export format, login method, MFA method, and authentication result. Use the same login pattern the user uses in production. If they sign in through SSO, test through SSO.

Your notes should answer four questions:

• Could the user run the report?
• Could the user export it?
• Was step-up required?
• Could the user complete the challenge?

If the user cannot complete the challenge, that is an operational issue. If the user can export sensitive data they no longer need, that is an access issue. Treat those as separate findings.

What the help desk should know

A report export prompt may be expected behavior. The response should not be "try again later" or "ask an admin to bypass it." A good support note tells the team to confirm the requesting user, the report name and folder, the business purpose, the authentication method used, the prompt or error text, and whether the user can run the report but not export it.

If the need is legitimate, help the user complete the correct authentication flow. If the access is too broad, route it to the admin or data owner. This keeps a security control from becoming an informal exception process.

What not to assume

• Step-up does not replace permission design. It is an added check, not a decision about who should have access.
• It does not cover non-UI extraction. Review Data Loader, scheduled exports, API integrations, warehouses, CRM Analytics, and managed packages separately.
• Behavior is not uniform. Login method, device, location, session, and (for the anomalous control) behavior pattern affect whether a challenge appears.
• Sandbox does not explain every production case. Test in sandbox to prepare users and support, but do not promise every case is known.

Checklist

Use this before your production window completes:

• Identify users who regularly export reports.
• Review who has report export permissions.
• Review profiles, permission sets, and permission set groups.
• Confirm which session policy your org has selected (export/print vs. view).
• Review report folders with sensitive fields.
• Identify reports containing regulated or customer-sensitive data.
• Test common export workflows in sandbox with real business roles.
• Confirm every report user has a registered, supported MFA method plus valid email and phone.
• Test SSO login paths specifically.
• Confirm scheduled report-distribution tools have a step-up-compatible version.
• Document expected prompts for the help desk.
• Remove export access where viewing is enough.
• Archive stale reports; move sensitive reports to restricted folders; assign owners.
• For Shield or Event Monitoring orgs, set your own ReportEvent Transaction Security Policy before July 13 rather than accepting the default.
• Review non-UI extraction paths separately, and audit integration users for API-only access.
• Add report export behavior to your security runbook.

This is not a reason to block every export. It is a reason to know which exports matter, who runs them, and what data leaves Salesforce.

This week: pick 10 high-use report exports, test them in sandbox with real roles, and remove export access where viewing is enough.