Why Salesforce Profiles Are Putting Orgs at Risk

Salesforce admins have relied on Profiles for decades. They feel familiar. They feel safe. According to Andrew Day, Fractional CISO and founder of 22 Nexus, that familiarity is exactly the problem.

At Texas Dreamin’ 2026, Day delivered a session that walked attendees through why Profiles have become the biggest obstacle to real security in Salesforce orgs, and what teams can do instead. Day brings a security-first background to the topic. He holds an M.S. in Cybersecurity and Information Assurance along with a long list of Salesforce and CompTIA certifications, and his career includes work across the Department of War, the Air Force, the Army, and the Coast Guard.

The Price Tag on Sticking with Profiles

Day opened with numbers that got the room’s attention. More than 300 organizations have already been hit by attacks tied to weak access controls. Over 80 percent of orgs still rely primarily on Profiles for permission management. And the cost gap is stark: proactive least-privilege work runs somewhere between $50,000 and $150,000, while cleaning up after a breach can cost $4 million to $10 million.

Salesforce itself has signaled where the future lies, even after a recent reversal. In June 2026, the company cancelled its planned retirement of permissions in Profiles, citing customer feedback and gaps in Permission Set tooling. Profiles won’t disappear on a forced deadline. But Salesforce’s underlying recommendation hasn’t changed: it still points admins toward a Permission Set–led security model, and nearly every recent platform investment has gone toward Permission Sets, Permission Set Groups, and related access tools. Profiles, by contrast, have seen little meaningful innovation in years.

Where Profiles Fall Short on Least Privilege

Day broke down exactly why Profiles fail at their core job.

• One size fits all, poorly. A single Profile often has to serve many different personas at once. That forces admins to grant broad access just to cover every use case, which directly produces over-permissioned users.
• Hard to audit and revoke. Figuring out who holds “Modify All Data” across a large org is often a manual, painful exercise. Profiles also carry no built-in record of why a permission was granted in the first place.
• A magnet for technical debt. Every new business requirement tends to add another checkbox to a Profile, and old ones rarely get removed. Day noted that orgs with 50 or more Profiles are common, and genuinely alarming from a security standpoint.
• Inheritance and cloning hell. Cloning a Profile inherits everything from the original, good and bad. There’s no easy way to see the full effective permission set a user actually holds.
• Guest and community nightmares. Guest user Profiles frequently end up over-permissioned, protected mainly by the illusion of “security through obscurity” rather than real controls.
• No built-in subtract function. Permissions in Salesforce are additive by nature. Once granted through a Profile, they’re difficult to claw back without breaking access for other users who share that same Profile.

Taken together, these six issues explain why so many orgs end up with sprawling, unauditable access, not from any single mistake, but from Profiles working exactly as designed.

A Real-World Warning: The ShinyHunters Campaign

To make the stakes concrete, Day walked through the ShinyHunters Experience Cloud campaign, an ongoing pattern of attacks since 2025. The attack chain follows a repeatable playbook: Attackers run mass automated scans to discover public-facing endpoints. They exploit over-permissive guest user Profiles to gain unauthorized data access. They use Aura and UI API exploitation techniques, including custom tooling built specifically to bypass record limits. The result is data exfiltration and extortion, all without deploying any malware. Bad configuration alone is enough.

What makes this preventable? Guest Profiles commonly grant read and edit access on objects like Account, Contact, Case, and Opportunity “just in case.” Field-level security often gets left wide open to support reporting or flows. Sharing rules end up too permissive for guest content, and reviews rarely happen. One line captured the problem well: some configurations “worked in UAT three years ago” and haven’t been looked at since.

The fix, Day argues, comes down to Permission Set Groups combined with muting. Start with a Minimum Access or custom baseline Profile. Assign only the specific Permission Sets needed for public functionality. Use muting Permission Sets to explicitly revoke dangerous permissions rather than hoping they never get triggered. Grant field permissions only where truly required, and build regular access reviews into the process.

The Building Blocks of a Least Privilege Model

Day framed Permission Sets and Groups as the practical foundation for least privilege at scale. The model rests on a few core ideas. Permission Sets should map to one specific work task each. A Permission Set grants access only for the objects and functions tied to that particular assignment, nothing more.

Permission Set Groups then bundle related Permission Sets into a single assignable unit, so one assignment can represent a full persona’s access. Access should be additive by design, starting from a Minimum Access Profile as the baseline and layering on only what’s needed.

Day also highlighted more advanced capabilities: modular, reusable Permission Sets that combine like building blocks, User Access Policies that automate assignment based on criteria such as user creation or profile change, and expiration-based or session-based access for temporary elevated permissions. That last piece works especially well for audits, contractor access, or break-glass scenarios where elevated access should disappear automatically after use.

Visibility Is the Missing Piece

Teams can’t secure what they can’t see. Day pointed to several tools that help close that gap.

The User Access and Permissions Assistant, a free Salesforce Labs tool, offers a Profile Converter, a Permission Analyzer, and access reports. Salesforce’s native “Who Has Access” feature and Setup Audit Trail provide a basic but useful starting point, especially when combined with custom reports built on PermissionSetAssignment and ObjectPermissions.

Least Privilege Quick Wins and Pitfalls

Day closed with practical guidance for teams ready to start. Quick wins include focusing first on one high-risk persona, moving integration users to dedicated Permission Sets with expiration dates, implementing User Access Policies for both existing users and new hires, and running a Permission Analyzer report to surface the top over-privileged users.

He also flagged common mistakes to avoid: trying to migrate everything at once instead of working in waves, ignoring field-level security until late in the process, forgetting guest site users entirely, skipping documentation, muting permissions too aggressively, and failing to thoroughly test mobile access, reports, and list views before cutover.

Ready to Ditch Profiles? Start Your Least Privilege Migration Today

Profiles represent technical debt with real security consequences, and Permission Sets combined with Permission Set Groups offer the practical path to least privilege at scale. Migration works best in waves: inventory, design, pilot, cutover, and govern. None of it matters without visibility, which is why tools like the User Access and Permissions Assistant matter so much. And the project should be sold on risk reduction, compliance, and velocity, not framed as cleanup alone.

Explore related content:

The Real Lessons Behind a Year of Agentforce Rollouts

Profiles and Permissions in Salesforce: The Simple Guide for Admins

Automate Permissions in Salesforce with User Access Policies