The Security-Minded Admin's Missing Layer
Salesforce's new Next-Gen Admin Security Guide makes an admission most vendor content avoids, that is admins typically don't report to the CISO, most never came up through security, and the org's security belongs to them anyway.
The guide treats this as the reason admins need more support, which is more than fair. It's also the best argument in the doc for reading the rest of it closely.
A person holding that kind of responsibility without the reporting line deserves to know exactly what the recommended tools will and won't see. The four pillars the guide proposes are the right four.
The practices under them are sound. Each one of them stops in the same place.
The pillars are right
The guide organizes the job into four commitments: visibility and awareness, proactive monitoring, security and resilience, user education and advocacy. Nobody can really argue with that list. It also maps Salesforce security as shared responsibility across three layers (foundationals Salesforce manages, configurables admins control, enhanceables you can buy) and is pretty explicit that the middle layer, the one admins own, is where security-mindedness lives.
A close reading starts with what the guide thinks an org is.
Visibility stops at the record
Pillar 1 opens with, in my opinion, is the best line in the document: "you can't protect what you don't understand.” It then, unfortunately, defines understanding narrowly.
The recommended practice is a data audit followed by a classification pass. Find the sensitive fields, tag them by compliance category, set field-level security. The org, in this telling, is a container of records.
An org is also a configuration. Fields sit inside objects that automations write to, flows branch on, integrations sync, and permission structures expose. When something leaks, the path runs through that graph: a flow nobody documented, touching a field somebody just reclassified. The guide's version of visibility can tell you a field is PII. It cannot tell you what else touches it.
Monitoring looks backward
Pillar 2 is where the guide's own evidence undercuts its tooling.
It notes that human error (for example accidental deletion, or misconfiguration) has historically driven most data loss in Salesforce environments. Then the recommended tools are almost entirely behavioral and retrospective. Setup Audit Trail tells you who changed a setting and when, after they've changed it. Event Monitoring watches logins, exports, API calls.
Those are good tools for catching a compromised credential. Misconfiguration is a different kind of problem. It's structural (a report type exposing fields it shouldn't, a permission set granting more than anyone remembers deciding) and it doesn't announce itself in an event log. It sits until something finds it: an audit, an agent with broad permissions, an attacker.
The gap in this pillar is the moment before the change. Nothing in the guide shows an admin what a modification will touch before they save it. Proactive monitoring, as described here, is reactive monitoring with good response times.
Least privilege drifts
Pillar 3 gets the principle right, and the warning against blanket profile permissions is advice every org should already follow. The hard part though is that least privilege is a state, and orgs are processes. Permission sets accrete. Groups get cloned for a project and outlive it. A permission granted for a 2023 migration is still there, and nobody currently at the company knows why.
The guide's answer is monitoring permissions from a single view, which surfaces totals without the history or dependency context that would let an admin safely subtract. Its own illustrative dashboard shows an org with 240 users holding View All Data and 229 holding Modify All Data, presented as metrics to watch. A benchmark would call that a finding.
Backup, the other half of the pillar, has the same shape. Backup & Recover restores records after corruption. Restoring the org's structure to a known-good state is a different operation, and the guide doesn't have a word for it.
Agents get watched, never readied
Agentforce appears twice in the guide, both times in the same role — anomaly detection inside Security Center, triaging suspicious behavior into investigations. Agents as security cameras.
The harder subject never comes up: the condition of the org those agents will operate in.
An agent acts through metadata.
Its context is the schema and permission model it inherits, and its blast radius is whatever the automation layer allows. This is where the security conversation and the AI conversation turn out to be the same conversation. The complexity the guide treats as a management burden… the layered automation, the years of accumulated configuration… is exactly what gives agents their context. An org that understands its own structure can hand agents that context deliberately. An org that doesn't is letting agents loose in a structure nobody has read.
The benchmark the guide almost asks for
Security Health Check is the most honest tool in the holw lineup, and the guide returns to it in three of the four pillars. It scores your settings against a baseline and tells you where you deviate. That's a benchmark… for settings. Session timeouts, password policies, login ranges. It doesn't read metadata, so the configuration layer every earlier pillar kept bumping into sits outside its scope.
That's the extension the Security Benchmark for Salesforce makes. It applies the logic Health Check already taught admins to trust… measure the org against a standard, get prioritized gaps back… one layer down, to how the org is actually built and how access actually resolves. Run Health Check weekly, as the guide says. Then take the structural questions somewhere that can read them.
The advocacy problem is an evidence problem
Pillar 4 asks admins to become advocates and build the business case, meet stakeholders, frame security in the language of corporate risk. The guide is probably right in that this is part of the whole job now. It just doesn't arm anyone for it. An admin who doesn't report to the CISO needs an artifact a CISO already respects, and a benchmark score with prioritized findings is that artifact. It converts "I'm worried about our permission sprawl" into a score and a remediation order.
The security-minded admin this guide describes is real, and worth becoming. The four pillars hold.
They just stop at the record layer, and the job doesn't.
