Every router you've ever owned came with a default admin password. Probably "admin." Maybe "password." And somewhere behind that login, past the Wi-Fi name and the parental controls, there's a page full of firewall rules, port forwarding settings, DNS configurations, and firmware update checks. Settings that determine who gets in, what gets blocked, and whether your network is actually secured or just feels secured.

Be honest. When's the last time you logged into your router?

Salesforce has a version of that buried settings page. It's called Health Check. It lives in Setup, it scores your org's security posture against a baseline of best practices, and most teams have either never opened it or haven't looked at it in months.

Maybe years.

Spring '26 Just Made It Harder to Ignore

The Salesforce Spring '26 release tightened things up. Health Check now evaluates seven additional identity and session security settings: MFA status, SAML configuration, session management controls. It also introduced email notifications so admins can be alerted automatically when the score drops.

That's a meaningful step. Salesforce is signaling something: with AI adoption accelerating and audit scrutiny increasing, your security posture isn't optional anymore.

Good. It's about time.

But here's where I want to push the conversation a little further. Not because Health Check isn't valuable — it is. It's a great starting point. But a starting point is exactly what it is.

The Questions Health Check Doesn't Answer

Health Check tells you whether certain settings are configured to Salesforce's recommended baseline. That's useful. But it's a point-in-time snapshot of a narrow set of configurations. And if you've been in this space long enough, you know that the real security risks in a Salesforce org aren't usually about whether MFA is turned on.

They're about what's changing. And who's changing it. And whether anyone knows.

Here are some questions worth sitting with:

1. Do you know what changed in your org last week outside of your deployment process?

Someone edits a profile directly in production. A permission set gets modified during a Friday afternoon troubleshooting session. A validation rule gets deactivated "temporarily" and never gets turned back on. These changes don't show up in your deployment history. They don't trigger a Health Check alert. But they absolutely affect your security posture.

The ability to detect metadata changes made outside your DevOps process, and surface them automatically, is the difference between governance you enforce and governance you hope for.

2. Can you apply a security standard across every org in your landscape and know it stuck?

Most enterprises run multiple Salesforce orgs: production, full-copy sandboxes, partial copies, developer sandboxes. Health Check evaluates one org at a time. But security drift doesn't respect org boundaries. A template-based approach that defines your security baseline once, applies it across every environment, and monitors for deviation turns security from a checklist into a continuous practice.

3. When something's wrong, how fast can you fix it?

Detection without remediation is just expensive awareness.

Knowing your score dropped is step one. Automatically generating a remediation task, assigning it to the right person, and deploying the fix. That's the workflow that actually reduces risk. Mean-time-to-fix is the metric that matters, not mean-time-to-notice.

4. Is your sensitive data protected in every sandbox — not just production?

Full-copy and partial-copy sandboxes pull real data during refresh. That means production PII sitting in environments with looser access controls, used by developers and testers who may not need to see it. Anonymizing that data at rest, after the refresh, automatically... that's a compliance requirement Health Check doesn't touch.

5. Are you catching security issues before they reach production, or after?

Health Check evaluates your production org. But the most efficient place to catch a security vulnerability is in the development pipeline, before it's ever deployed. Shifting security left, into the same workflow where code is being built and tested, means you're preventing problems instead of discovering them.

You Can't Protect What You're Not Monitoring

Here's what I think Salesforce got right with the Spring '26 updates: they're normalizing the idea that org security isn't a one-time setup. It's an ongoing discipline. The new settings, the email alerts, the tighter baselines. All of it says "pay attention."

And if the Health Check updates prompt you to actually open that page for the first time in a while, that's a win.

But don't stop there.

Ask yourself whether you have visibility into changes happening outside your process. Ask whether your security standards are applied consistently across every environment. Ask whether your team can move from detection to remediation in minutes instead of days. Ask whether your sandbox data is as protected as your production data.

Health Check is a good place to start.

It's just not a good place to stop.

Interested in learning more about how Flosum can help you protect your Salesforce investment? Connect with an expert today!