Security is front and center at the moment in the Salesforce space. We had a dramatic few months in 2025 where breaches and security vulnerabilities were running wild, and it’s clear Salesforce is putting its best foot forward to ensure this doesn’t happen again in 2026.
However, due to the nature of some of these changes, some other dramas have been unfolding. Solo system administrators being locked out of orgs is becoming a key issue. If you’ve been impacted and want to know why, or if you haven’t yet but want to ensure you’re safe, read on.
The Changes
There are a few ways you may have noticed that Salesforce is making changes. Hopefully, the method that you were informed about was through the yellow banner at the top of your screen when logging into Salesforce.
There’s a further link you could click to see what is coming in your org, and having this persistently displayed made it easy for anyone and everyone to see what was coming. Unfortunately, some people learned of this change when they were locked out due to things like using a non-enterprise privacy VPN (more on that later).
Before we get into that, what exactly did Salesforce do, or announce that they will do? There is quite a bit! A majority of these will have an impact on every org, too, so it’s important to familiarize yourself with the changes. If you haven’t yet read Tom Bassett’s article that dives deep into the changes, please do so!
The Drama
Unfortunately, some of these security enhancements had some pretty dangerous flow-on effects. Most notably, I’ve seen countless posts on LinkedIn about the freezing of users due to the use of anonymous VPNs.
One such example that I saw was someone logging into Salesforce from a public WiFi and using an anonymous VPN tool for security reasons. This triggered Salesforce to revoke its access to Salesforce entirely and revoke any related OAuth tokens. The solution was reaching out to Salesforce via phone to raise a case and have them resolve access.
Another example I saw specifically called out that they were the only admin in that particular sandbox, so once they were locked out, there was no quick way to have their user unfrozen and access restored.
Many in the community are complaining that this approach to solving the security issues feels rushed and has left many admins in a tough spot. This especially hit hard for orgs that have only a single Salesforce Admin, or sandboxes that similarly only have a single admin.
Was This a Bad Rollout?
It won’t shock you to hear that there have been some complaints as to how this change has been rolled out. The IdeaExchange has a post with a comments thread a mile long, alongside various other discussions on other platforms as well. One thing gets suggested quite a bit: Was this a bad rollout by Salesforce?
I’m not here to offer a definitive answer to that, but it is something worth considering. Given the popularity of using VPNs around the world – given that using them can help protect you as you navigate the internet – it does feel like an oversight by Salesforce.
Yes, there are enterprise VPN solutions that some customers do use, but there are a very large number of Salesforce customers that do not. Of those, there are many who use anonymous VPN services on their computers while accessing Salesforce.
The other issue many had was the heavy-handedness of the solution – freezing/locking out of users, and severing of OAuth connections. I totally understand the severity of a data breach, and Salesforce’s wanting to take action to prevent this wave of attacks is admirable. That being said, I agree that the lockout could have been handled differently, especially in orgs where there is only a single Administrator.
What to Do to Protect Your Org
There are things we can change, and things we can’t. We can’t change the way these security changes have been applied, but we can respond to them. There are best practices that should be followed, such as having a minimum of two Salesforce Administrators per org in case one loses access.
You could also consider responding to the known issues that Salesforce has with anonymous VPNs at the moment. Personally, I’m a big VPN fan as well, and I’ve got mine switched on almost 100% of the time that I’m online and not on an enterprise VPN. In light of these changes from Salesforce, I am being careful not to log on to a Developer Edition org (where I’m the only admin) while it is enabled.
Additionally, when spinning up a sandbox environment, you should make sure you’re adding more than a single Salesforce Administrator to it. Even if you’re only using it temporarily for a small job that you wouldn’t otherwise bother another admin for, it makes sense to add them just as a backup.
You should also consider extracting whatever metadata that you build from the sandbox environment. It’s never a good idea to use a sandbox as a source of metadata storage, even if it’s still being developed.
Summary
It’s quite reassuring to see Salesforce taking security so seriously, especially following the breaches and loss of trust in 2025. I’m encouraged by what we’re seeing come from the mothership here. However, I am a bit concerned about the rollout – specifically, the details surrounding anonymizing VPNs and phishing-resistant MFA.
What questions do you have for Salesforce relating to these changes? Do you think they’re too much, or not enough? Please share your thoughts in the comments to begin a discussion with the wider Salesforce community.
