SecurityForce

Hello, We recently ran a Health Check and one of the items in there was to turn on - Require HttpOnly attribute. I read a lot of documentation and other available blogs that state 99% of the time it should be good to enable it. Obviously we would do that in a full sandbox and test things out, but I wanted to ask folks here if there are any known issues or caveats we should be aware of and look for them first. We have a ton of managed packages in the organization.  

Thank you so much! 

Regarding Spring '26 "Authorized Email Domains" security enhancements., Salesforce indicates exceptions for gmail.com and outlook.com domains. My University runs our email on Outlook servers, but our domain name is that of the University. Does the exception by Salesforce apply to Outlook servers regardless of domain name, or only for outlook.com

as the domain? 

Thank you!

I am not sure if this is the group to ask or not, but I work for a Nonprofit and while reviewing the Login History for the past 6 months, I noticed that a user who has been inactive since 2016, appeared to try to log into their SF account.  The login failed as the user is inactive, however, my question is more around would this be an attempt of someone getting a hold of an old email, username, password, etc and using this to try and login to our SF instance?  I do know it was from a Mac, it was Chrome and the IP address is from Clevland (or appears to be) and we are in Cincinnati.  Anyway, I am trying to determine if I should be concerned or note. 

https://invite.salesforce.com/eventmonitoringforsecurityintel?utm_campaign=uki_cbaw&utm

[…]t-1768993355&utm_medium=organic_social&utm_source=linkedin 

This 60-minute webinar will equip you with the knowledge to leverage Event Monitoring for superior security intelligence. Over 50 minutes, we will cover four critical areas: We begin with an Introduction to Event Monitoring, outlining the standard audit trail capabilities and clearly differentiating between active security monitoring and passive compliance logging. Next, we delve into Event Types & Data Model, examining crucial events like logins, API usage, and data exports, discussing the differences between real-time and historical event data, and breaking down the structure of the Event Log Files . The in-depth Implementation & Configuration section guides you through enabling Event Monitoring, setting up custom event log retention policies, and establishing seamless integration with your existing SIEM (Security Information and Event Management) platforms. We conclude by exploring practical Security Use Cases, demonstrating how to detect anomalous user behavior, build specific compliance reporting scenarios, and integrate event data into your incident response workflows.

Great to see this enhancement from Salesforce 

https://sforcemaximizer.com/winter-26-release-features-for-architects-that-save-time-strengthen-security-and-stop-problems-before-they-start/

If you are an architect, aspiring architect, or admin, developer looking at Winter 26 features from an architect perspective, here is my blog, which will highlight key features that will help you save time, prevent problems, and make it easy with a well-architected lens. 

https://sforcemaximizer.com/how-to-secure-your-agents-data-at-dreamforce-2025-for-admins-and-architects/

If you're an admin, architect, or IT leader who's eager to secure your Agents and learn practical best practices at Dreamforce 2025, check out this wonderful blog by

My company was planning to implement API Access Control. After enabling it we have ran into couple issues. Latest is that the "Is single sign-on enabled" permission has disappeared. We haven't used delegated SSO in a long time so it doesn't impact the SSO as such but we have kept is permission enabled for end user profiles to prevent password resets. Is there another way to prevent password resets for users based on profiles? For admins and some special cases we still want to have passwords so we can't disable password login on the org level. 

Why can't these impacts be documented? It is really frustrating to discover these on trial and error basis. Like that also SOAP connections are impacted and apparently those cannot be authorized but you'd need to give "Use any API client" permission for the concerned user.

Consider the specific recommendations in this article to improve the security posture of your org in light of the ongoing social engineering threats: