July 25, 2026

Salesforce Report-Export Step-Up Enforcement: The Known Issues and Gotchas Nobody Warned You About

Blocked exports, a broken Login As, and RPA jobs failing: the practitioner known issues behind Salesforce report-export step-up enforcement in July 2026.

TL;DR

The July 2026 report-export enforcement is actually two separate mechanisms people keep conflating: a static, admin-editable default Transaction Security Policy (TSP), and a machine-learning step-up challenge with no admin knobs at all.
The default TSP is auto-created only in orgs that have Shield or Event Monitoring, and only if no ReportEvent policy already exists. It triggers on UI report exports over 10,000 records and reached production on 13 July 2026.
Both mechanisms are UI-only. They do not touch the reporting API or Data Loader, so a compromised integration user exporting via API sails straight through, and any headless automation that scrapes the UI export URL breaks.
Login As sends the step-up prompt to the end user, not the admin, so you cannot reproduce the problem you are being paged about. This is the single biggest support-ticket generator.
A user with no registered verification method is blocked from exporting, not merely challenged. Stale email or mobile details on a shared account turn that block into a hard wall.

What You'll Learn

The two mechanisms behind report-export enforcement, and why treating them as one thing causes half the confusion
Why this is not the bulk-exfiltration control it looks like, and where the real gap sits
The specific breakages: headless automation, Login As, unenrolled users, and a stale existing policy that silently cancels your protection
The mid-rollout scope change on 16 June 2026 that made a lot of earlier guidance wrong
What you can actually configure, what you cannot, and how to take the default off the table by writing your own policy

The Problem

Your org just hit the July 2026 enforcement and something is off. A scheduled export that ran fine for two years now stops at a verification page. An admin using Login As to reproduce a user's complaint cannot make the prompt appear. A service account that exports a nightly report is blocked outright with no obvious way through. And the security team is asking whether this new control stops the bulk data exfiltration everyone keeps worrying about, to which the honest answer is: no, not the way you think.

The root of most of this is that two different mechanisms shipped at almost the same time under almost the same name, and nearly every explainer treats them as one. Once you separate them, the weird behavior stops being weird. So let me pull them apart first, then walk the gotchas one at a time.

Common Questions This Article Answers:

Why did my Login As stop showing the export challenge?
Why is a user blocked from exporting instead of just being asked to verify?
Does the default Transaction Security Policy actually stop bulk data theft?

Quick Answer

Report-export enforcement in July 2026 is two mechanisms, not one. The first is a default Transaction Security Policy (TSP): static, condition-builder based, auto-created only in orgs with Shield or Event Monitoring, and only where no ReportEvent policy already exists. It triggers on report exports over 10,000 records through the Salesforce user interface (UI), reached production on 13 July 2026, applies to internal users only, and stays fully editable. The second is step-up authentication: a machine-learning and telemetry driven challenge on report actions (production around 1 July 2026, dates revised on 2 June) and on anomalous exports (production 13 July 2026), which applies to every internal user regardless of Shield and has no admin-tunable settings. Both are UI-only, so neither touches the reporting API or Data Loader. That single fact explains the security gap (API exports are unaffected) and the breakage (headless UI automation dies at the verification page). If you have Shield or Event Monitoring, the cleanest move is to write your own ReportEvent policy before Salesforce writes one for you, because doing so also suppresses the default.

The two mechanisms you keep conflating

Almost every problem in this post traces back to mixing up two things that behave completely differently. Name them and keep them separate.

Mechanism one: the default Transaction Security Policy. This is a static policy built on the condition builder. Salesforce auto-creates it only in orgs that already have Shield or the Event Monitoring add-on, and only if you do not already have a ReportEvent policy of your own. It fires when a user exports a report of more than 10,000 records through the UI. It reached production enforcement on 13 July 2026. It applies to internal users only (Experience Cloud users are out of scope at this time). And it remains fully editable after enforcement, so you can change the threshold, the action, and the message.

Mechanism two: step-up authentication. This is the machine-learning and telemetry side. Step-up on report actions reached production around 1 July 2026 (those dates were revised on 2 June 2026). Step-up on anomalous report export reached production on 13 July 2026. Unlike the default TSP, step-up applies to all internal users whether or not you have Shield, and it exposes no admin-tunable knobs on the anomaly side: no allowlist, no visible thresholds, no per-user override.

The practical difference: one is a policy you own and can rewrite, the other is a model Salesforce runs on its side that you can only respond to, not configure. Hold that distinction while we go through the breakages, because the fix for each depends on which mechanism you are looking at. For the wider July enforcement wave that these sit inside, see Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do.

The default TSP is not a data-exfiltration control. Here is why.

This is the misread I most want to correct, because security teams keep filing it under "bulk export protection" and it is not that.

The default TSP applies to report exports through the Salesforce UI. It does not apply to the Analytics or reporting application programming interface (API), it does not apply to Data Loader, and it does not apply to any other API-based export path. So picture the actual threat: a compromised integration user with a stored credential pulls report data through the API on a schedule. The default TSP sees none of it. The 10,000-record threshold you were relying on covers the analyst clicking Export in a browser, not the automated pull that a real exfiltration would use.

That is the security gotcha. If your mental model was "we now block anyone taking more than 10,000 records out of reports," correct it to "we now challenge internal users who export more than 10,000 records through the browser." Those are very different guarantees. The API path is exactly where a determined actor would go, and it is exactly the path this control leaves open.

Which is why capturing what is actually happening matters more than trusting the control to prevent it. The API exports the TSP ignores still show up in your event logs, if you are keeping them. If you are not on Shield, you can still build that record: Free Salesforce Event Monitoring: Build a Security Baseline from EventLogFile Without Shield walks through capturing login and export activity from the free daily logs before the one-day retention window erases it.

Your headless automation just broke

The same UI-only scope that creates the security gap creates a very concrete breakage.

Plenty of orgs run robotic process automation (RPA), Selenium scripts, or middleware that logs in as a real user, navigates to a report, and hits the export URL to scrape the file. Because that automation drives the UI, it is squarely in scope. On enforcement day it stops at the verification page it has no idea how to answer, and the job fails. If a nightly data feed suddenly went dark in mid-July, this is a prime suspect.

The fix is to move the export off the UI and onto the reporting API, which is exempt from both mechanisms. But that is a migration, not a config toggle, and it comes with its own tail of issues that are worth testing before you commit. These are reported on the reporting-API export path specifically, so treat them as "things to verify for your data," not as universal TSP behavior:

Long-text fields get truncated to 255 characters in CSV and XLS output.
Reports with more than 100 columns fail.
Currency exports render in English locale rather than the user's locale.
Checkbox fields come out as true/false instead of 0/1.
Large XLSX "Details" exports can hit a "Job stalled more than allowable limit" timeout.

None of these are showstoppers on their own, but if your downstream system parses fixed formats, a silent switch from 0/1 to true/false or a 255-character truncation will corrupt data quietly. Test the API path against a real report before you cut over.

Your Login As just broke

This is the one that generates the most support tickets, and it is maddening until you understand it.

An admin gets a report that a user cannot export. The admin does the natural thing: Login As that user, reproduce the export, see the prompt, diagnose it. Except the step-up MFA prompt does not go to the admin driving the session. It goes to the end user whose identity is being borrowed. So the admin sits at a screen waiting for a challenge that is being sent to someone else's phone, cannot complete it, and cannot reproduce the very problem they were asked to fix.

The practical consequence is that Login As is close to useless for troubleshooting these challenges. Do not burn an afternoon assuming your session is broken. Instead, diagnose from the user's side: confirm what verification methods that user actually has registered, check that their email and mobile on the user record are current, and if you need to see the challenge yourself, test with your own account against a report that trips the same condition. Multi-factor authentication (MFA) prompts follow the identity, not the session, and Login As borrows the identity without borrowing the phone.

Incomplete enrolment means blocked, not challenged

Here is the failure that turns a challenge into a wall.

The design intends to challenge a user, and if they cannot complete the primary challenge, to fall back to a one-time password over email or short message service (SMS). That fallback only works if the contact details on the user record are current. So a user with no registered verification method at all, and stale or missing email and mobile on their record, does not get prompted and then let through. They get blocked. The operation stops.

This bites hardest on the accounts nobody maintains: shared logins, service accounts, that reporting user three people use. Those are precisely the records with an ancient email address and no mobile number, and precisely the ones running the scheduled exports that now hard-fail. Before the enforcement dates, sweep for active users with no registered verification method and no valid email or mobile, and fix the contact details on any shared or service account that exports reports. An unenrolled user is not a challenged user; they are a stopped one. This is the same enrolment gap that bites the broader MFA rollout, covered in Salesforce MFA Enforcement Update: What Was Paused, What Still Applies, and the Revised 2026 Dates.

The anomaly model is a black box, so work downstream of it

The step-up-on-anomalous-export mechanism runs on Salesforce-side telemetry: export volume, timing, and patterns it judges unusual. There is no admin configuration. No allowlist. No visible thresholds you can read or tune. You cannot tell it that your month-end finance export of 40,000 records is expected.

So stop trying to configure something with no configuration surface. Your work is entirely downstream of the model. Two things pay off. First, write a false-positive runbook: when a legitimate heavy-reporting user gets challenged unexpectedly, your team should know it is expected behavior, not a bug, and be able to confirm the user simply completes the challenge and continues. Second, keep verification methods current for exactly the users who trigger the model most: analysts, finance, anyone whose job is large exports. The model will challenge them; your job is to make sure the challenge succeeds rather than blocks.

The 16 June scope change that dated a lot of guidance

If you read a guide before mid-June that said report views get challenged, it is now wrong.

On 16 June 2026 Salesforce narrowed the step-up-for-report-activities scope so it applies only to report exports, not report views. Viewing a report on screen does not trigger the challenge; exporting it does. This matters because a fair amount of guidance was written before that change and still tells you to expect challenges on view. If your plan assumed reporting-heavy users would be re-challenged just for opening dashboards, drop that assumption. The dates on this mechanism also moved once already (the 2 June 2026 revision), so treat any specific date as provisional and confirm it against the live Salesforce article before you plan a maintenance window around it.

The stale-policy trap that silently cancels your protection

This one is dangerous because nothing tells you it happened.

The default TSP is only deployed if you do not already have a ReportEvent policy. That is normally a good thing: it means your own policy wins. But flip it around. If you have an existing ReportEvent policy that is stale, misconfigured, or half-disabled, the default is not deployed either, and you silently do not get the 10,000-record protection while assuming you do. There is no warning. You have a policy, so Salesforce steps back, and if that policy does nothing useful, you are unprotected and unaware.

Audit for it. Check whether a ReportEvent policy exists, and if one does, confirm it is enabled and actually doing what you intend. A disabled or empty policy is worse than no policy here, because it suppresses the default you would otherwise have inherited.

What you can actually configure, and the move I recommend

Now the part you can control. To edit these policies you need Customize Application plus Modify Transaction Security Policy (or Modify All Data). With that, a few levers are real:

The default TSP itself is fully editable. Change the 10,000-record threshold, the action, and the message to fit how your business actually exports.
The step-up session reset defaults to 120 minutes and is customizable (the setting accepts a value between 1 and 120 minutes). Set it too tight and reporting-heavy users re-authenticate constantly through a working session; set it too loose and the control weakens. 120 minutes is a reasonable start; tune it to how your analysts actually work.
The anomaly model stays unconfigurable. No knobs, as covered above.

The move I recommend for any Shield or Event Monitoring org: write your own condition-builder ReportEvent policy proactively, before the enforcement date. Doing so gives you a threshold and message you chose, and as a bonus it suppresses the default so you never inherit Salesforce's 10,000-record version. You control the protection instead of accepting a generic one, and you sidestep the stale-policy trap by making sure the policy that exists is one you actually wrote and enabled.

Frequently Asked Questions

Does the default Transaction Security Policy stop bulk data exfiltration through the API?

No. The default TSP applies only to report exports through the Salesforce UI. It does not cover the reporting or Analytics API, Data Loader, or any API-based export. A compromised integration user pulling report data through the API is entirely unaffected by it, so treat the 10,000-record control as a guardrail on interactive browser exports, not as an exfiltration prevention control. If you need to see API-based exports, that is an event-monitoring and logging problem, not something this policy solves.

Why can I not reproduce the export challenge using Login As?

Because the step-up prompt goes to the end user whose identity you borrowed, not to you as the admin driving the Login As session. The challenge follows the identity, and Login As does not give you the user's phone or registered verifier. To troubleshoot, check what verification methods the user has registered and whether their email and mobile are current, and test the challenge with your own account against a report that trips the same condition.

A user is blocked from exporting entirely. Why are they not just being challenged?

Because they have no registered verification method and the fallback cannot reach them. The system falls back to a one-time password over email or SMS, but only if the email and mobile on the user record are current. A user with nothing registered and stale contact details gets blocked rather than prompted. This most often hits shared and service accounts. Fix it by ensuring every active exporting user has a registered method and a valid email and mobile on their record.

I have a ReportEvent policy already. Am I protected?

Only if it is enabled and doing what you intend. An existing ReportEvent policy suppresses the auto-created default, so if yours is stale, misconfigured, or half-disabled, you get neither your own protection nor the default 10,000-record one, and nothing warns you. Verify that any existing policy is active and correct, or delete it and write a fresh one you control.

Key Takeaways

Two mechanisms, not one: an editable default TSP (Shield or Event Monitoring orgs only) and an unconfigurable step-up model (all internal users). Most confusion comes from conflating them.
UI-only scope cuts both ways: it misses API and Data Loader exports (the real exfiltration path) and it breaks any headless automation that scrapes the UI export URL.
Login As sends the challenge to the wrong person, so it is close to useless for reproducing these prompts. Diagnose from the user's registered methods instead.
Unenrolled means blocked, not challenged, and stale contact details on shared or service accounts turn that block into a hard wall.
Write your own ReportEvent policy before Salesforce writes one for you: you control the threshold and message, and it suppresses the default, but audit for a stale existing policy that silently cancels the protection.

What's Next?

Recommended Reading:

Action Items:

Separate the two mechanisms in your own head and in your runbook: the default TSP (editable, Shield or Event Monitoring only) and step-up (unconfigurable, everyone).
Sweep for active exporting users with no registered verification method and stale email or mobile, and fix shared and service accounts first.
If you have Shield or Event Monitoring, write your own ReportEvent policy to set the threshold and message you want and suppress the default, and confirm no stale policy is silently cancelling protection.

Since the default TSP only ever touches Shield or Event Monitoring orgs and the API export path is exempt, the control alone will never show you the full picture of what left your org. Capturing that needs an event baseline you keep yourself. Our open-source sf-audit plugin ships sf audit events pull (sf plugins install @cclabsnz/sf-audit), a read-only command that captures the free daily EventLogFile logs, including export activity, before the one-day retention window erases them. It does not include a TSP-specific check; it gives you the underlying export record the policy does not. If you would rather have the whole July enforcement wave handled rather than tracked, that is what CloudCounsel does day to day.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.