More thoughts regarding this change: "when a Salesforce user account is detected as connecting from anonymizing VPNs, proxies, or high-risk IP addresses — through Connected App or API usage — the following actions will be taken immediately: The affected user account will be frozen..."
If field reps keep getting locked out, they'll stop using Salesforce and revert to spreadsheets, texts, or other tools (maybe that is what was meant by "You may never have to log in to Salesforce again." 😜).
What about API integration users? This could cause integrations to break silently if there isn't decent logging/monitoring.
Pain points:
😢 Users frozen automatically with no admin control
😢 Manual unfreeze is repetitive admin toil
😢 No visibility into which IPs are triggering freezes
😢 Trusted IP / Login IP range config is trial-and-error (when it even works)
😢 Field/mobile users and Apple Private Relay seem to get the worst cases
Some ideas (trade offs later):
1️⃣ a scheduled Apex job (or Flow) that polls UserLogin and the User.IsFrozen field every N minutes - if one is frozen, checks against a list in a custom metadata and, if deemed safe, auto-unfreezes and logs the event/IP.
2️⃣ some script that queries LoginHistory, aggregates IPs per user over, say, last 90 days, uses an API to resolve the IP and report it to the admin: "Here are IPs your users actually log in from and these are not yet in Trusted IPs".
3️⃣ an Experience Cloud Portal to Self-Unfreeze after the user verify identity via other safe means.
4️⃣ send Salesforce a request for exemption - you will need a written sign-off from legal counsel waiving Salesforce.
Now the tradeoffs: how likely these suggestions could be used in a foolish way just to get rid of the immediate problem, then later a company gets breached and they blame the tools rather than their own thoughtless decisions?
The scheduled Apex job 1️⃣ is the most dangerous to be used as an automated tool to defeats a security control as fast as Salesforce can apply it. When a breach happens, a forensic team will see that purpose-built tool systematically reversing freezes. 🤮
The script to show IPs 2️⃣ is more subtle: the risk is that the admin will see the list of IPs as "safe IPs" without anyone actually reviewing them. State actors are known for waiting for months before making use of a compromised credential.
The self-unfreeze 3️⃣ seems a more moderate risk. It can't rely on email because that is likely already compromised if the IP/credential is compromised.
Requesting an exemption via a waiver 4️⃣ - this is explicitly overriding vendor security controls and won't look good in case of a breach.
I don't yet see a way in the current paradigm to escape the friction that security controls impose.