Configure Security Settings and Monitor Compliance in Government Cloud

Session Timeout

Field	Recommended Setting	Description
Timeout value	15 minutes	Length of time after which the system logs out inactive users.
Disable session timeout warning popup	Checkbox deselected	Determines whether the system prompts inactive users with a timeout warning message. Users are prompted 30 seconds before timeout as specified by the Timeout value.
Force logout on session timeout	Checkbox selected	Requires that when sessions time out for inactive users, current sessions become invalid. The browser refreshes and returns to the login page. To access the Org, the user must log in again. Note When using this setting, do not select Disable session timeout warning popup.

Session Settings

Identity Verification

Field	Recommended Setting	Description
Let Salesforce Authenticator automatically verify identities using geolocation	To be determined by customer	Salesforce Authenticator uses the phone's location services to verify the user's identity. If users approve the location, they aren't prompted for their identity when at that location. If the location is not approved, or if users are outside the trusted location, they're prompted to verify their identity.
Let Salesforce Authenticator automatically verify identities based on trusted IP addresses only	To be determined by customer	When users are located within trusted IP address ranges, they aren't prompted to verify their identity. If users are outside the trusted IP address range, they're prompted to verify their identity.
Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello	To be determined by customer	Permits the use of a built-in authenticator for multi-factor authentication (MFA) and identity verification. Users can verify their identity with a biometric reader such as a fingerprint, iris, or facial recognition scanner that's built into their device. Some built-in authenticators also let users enter a PIN or password.
Let users verify their identity with a physical security key (U2F or WebAuthn)	To be determined by customer	Allows users to use a U2F security key for two-factor authentication and identity verification. Instead of using Salesforce Authenticator, a one-time password generated by an authenticator app, or one-time passwords sent by email or SMS, users insert their registered U2F security key into a USB port to complete verification.
Let users verify their identity by text (SMS)	Checkbox selected	Enable the SMS method for identity verification. When enabled, users verify their identity with a text message that Salesforce sends to their phone.
Prevent identity verification by email when other methods are registered	Checkbox selected	Prevent identity verification by email for users who have registered in other verification methods, such as text (SMS) or Salesforce Authenticator. If no other verification methods are configured, users are verified by email.
Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org	Checkbox selected	Requires all users in your Salesforce org to provide an additional verification method when logging in directly to the UI with their username and password. Users who are already enabled via the Multi-Factor Authentication for User Interface Logins user permission experience no change. The Waive Multi-Factor Authentication for Exempt Users user permission overrides this setting.
Require security tokens for API logins from callouts (API version 31.0 and earlier)	Checkbox selected	Requires the use of security tokens for API logins from callouts in API version 31.0 and earlier. Examples are Apex callouts or callouts using the AJAX proxy. In API version 32.0 and later, security tokens are required by default.
Show all verification method registration options instead of starting with Salesforce Authenticator	To be determined by customer	By default, verification method registration starts with a screen to register Salesforce Authenticator. This setting changes the experience so users can choose from a list of all supported methods, including security keys and built-in authenticators if you enabled them.
Require identity verification during MFA registration	Checkbox selected	Requires users to confirm their identities to add a two-factor authentication method, such as Salesforce Authenticator, instead of requiring a relogin as before.
Let users authenticate with a certificate	Checkbox selected	Enable certificate-based authentication to use PEM-encoded X.509 digital certificates to authenticate individual users to your org. Note When using certificate-based authentication as the only authenticator for a given user or group of users, Salesforce will automatically receive and process a digital certificate offered by a web browser. If a user has unlocked the digital certificate using a PIN, their browser may cache and reuse this certificate to automatically re-establish authenticated sessions even after a session has been terminated through session time out or user action, such as log out. As the locking or unlocking of the digital certificate happens solely within the client device, Salesforce has no ability to access or change this behavior.
Check the revocation status of certificates	To be determined by customer	Checks certificate revocation status using the Online Certificate Status Protocol (OCSP) or a Certificate Revocation List (CRL).
Require identity verification for email address changes	Checkbox selected	Users verify their identity when they change their email address. (Users verify that they are who they say they are.)
Require email confirmations for email address changes (applies to users in Experience Builder sites)	Checkbox selected	When users change their email address, they receive an email at the new email address with a link. After they click the link, their new email address takes effect. (Users confirm that they own this email address.)
Display a confirmation page during password reset	Checkbox selected	Displays an intermediate confirmation page to users after they click the password reset link that's sent to their email. The password reset link remains valid until the user clicks Reset Password on the confirmation page, or until it expires in 24 hours. This setting helps prevent users and email security tools from accidentally invalidating the password reset link. We recommend that you keep this setting enabled. If you disable this setting, the link becomes invalid when it's clicked or scanned. If a user clicks the link and doesn't complete the password reset, they must restart the process.

Lightning Login

Clickjack Protection

Remaining Session Settings

Field	Recommended Setting	Description
Enable CSRF protection on GET requests on non-setup pages	Checkbox selected	Protects against Cross Site Request Forgery (CSRF) attacks by modifying non-Setup pages. Non-Setup pages include a random string of characters in the URL parameters or as a hidden form field. With every GET and POST request, the application checks the validity of this string of characters. The application doesn't execute the command unless the value found matches the expected value. This setting is selected by default for all Orgs.
Override Restriction on Accessing Email Templates in Salesforce Classic Using Internet Explorer	Checkbox deselected	Internet Explorer does not meet Salesforce's required level of browser security protection. This setting overrides a specific security restriction on accessing email templates in Salesforce Classic from Internet Explorer. Enabling this setting makes your org vulnerable to malicious third-party attempts to access your data.
Enable Stricter Content Security Policy	Checkbox selected	The Lightning Component framework already uses CSP, which is a W3C standard, to control the source of content that can be loaded on a page. This setting enables Stricter Content Security Policy (CSP) which prohibits the use of 'unsafe-inline' to mitigate the risk of cross-site scripting attacks.
Use security enhancements in API version	66.0	Lightning Locker enhances security with each API update. To increase your org's security, we recommend updating your custom components to comply with the latest Locker enhancements. If you're unable to update your components right away, temporarily select an earlier, compatible API version. This API setting only applies to Locker features in your org.
Use Lightning Web Security for Lightning web components	To be determined by customer	Enable Lightning Web Security (LWS) instead of Lightning Locker to protect Lightning web components and Aura components.
Enable Content Sniffing protection	Checkbox selected	Enabled by default and can't be disabled. This setting helps prevent the execution of malicious files (JavaScript, Style sheet) as dynamic content by preventing the browser from inferring the MIME type from the document content. To temporarily disable this feature for issue remediation, contact Salesforce Customer Support.
Referrer URL Protection	Checkbox selected	To protect sensitive information in your URLs, such as an org ID, enable the referrer-policy HTTP header. When an action in Salesforce makes a request to another URL, the website receiving that request can see information about the origin.
All redirections to…	All external URLs with the user's permission	Specify whether users can connect from Salesforce to untrusted external URLs. Specify the URLs that you trust on the Trusted URLs for Redirects Setup page.
Cross-Origin Opener Policy (COOP)	To be determined by customer	When you enable Cross-Origin Opener Policy (COOP), each top-level custom Visualforce page opens in a new browsing context group. This process prevents direct access between other browser tabs and your Visualforce page and the page's content. When you enable the Cross-Origin Embedder Policy (COEP) setting, externally sourced embedded content loads only when the origin explicitly states that your page or domain can load its content. Embedded content can include images, documents, and widgets. Note To preserve your users' access to required content, we recommend that you review the expected behavior and test COOP and/or COEP in a sandbox before you enable this feature in production.
Cross-Origin Embedder Policy (COEP)	To be determined by customer
Apply CSP Directives for Less Common Browsers	To be determined by customer	To help protect your users from clickjacking attacks, include the Content-Security-Policy: frame-ancestors HTTP header directive in the rare cases when Salesforce can't identify whether the requesting app or specialized browser supports the directive. When this setting is enabled and the header isn't supported, users can experience errors, including disabled functionality. Before you enable this setting in production, we highly recommend that you test this change in a sandbox. Note Although this change can affect all customers, it can have the most significant impact in orgs with a My Domain login URL that ends in .my-salesforce.com and in Government Cloud—Defense orgs.
Browser Feature Permissions	To be determined by customer	Control whether browser features can be accessed from the pages that Salesforce serves for this org.
Session Security Levels	To be determined by customer	You can restrict access to certain types of resources based on the level of security associated with the authentication method for the user's current session. By default, each login method has one of two security levels: Standard or High Assurance. You can change the session security level and define policies so that specified resources are available only to users assigned a High Assurance level.
Logout URL	To be determined by customer	Redirects users to a specific page after they log out of Salesforce, such as an authentication provider's page or a custom-branded page. This URL is used only if no logout URL is specified in the identity provider, SAML single sign-on, or external authentication provider settings. If no value is specified for Logout URL, the default is https://login.salesforce.com, unless MyDomain is enabled. If My Domain is enabled, the default is https://customdomain.my.salesforce.com.
Store the redirect logout URL in your local browser	To be determined by customer	Redirect all expired tabs in your browser to your custom logout URL.
Link expires in	1 day	Specifies how long the account verification link in welcome emails to new users is valid. You can select 1, 7, or 180 days. By default, account verification links expire after 7 days. When you update this setting, the change applies to links in welcome emails that were already sent. For example, you added a user and sent a welcome email two days ago when links expired in seven days. If you update the setting so that links expire in one day, the link in the email you sent two days ago is no longer valid.

1. To export the Salesforce Baseline Standard file, from the Baseline Controls menu, select Export Baseline.
2. Edit the XML file with a text editor and save your changes.
3. Adjust the risk categories to customize your scoring. The risk category affects your Health Check score. A setting in a higher risk category is weighted as more important than a lower one. Moving a setting to the Informational category removes it from the Health Check score calculation.
4. To modify the setting values, follow the Custom Baseline File Requirements. You can't change some values, and some settings have restricted value options. Don't add or delete risk categories, setting names, or quotation marks. If you do, your import fails. In some security settings, a low value can be low risk, but in others, it can be high risk. For example, the lower your minimum password length value is, the riskier it is. But the lower your maximum invalid login attempts value is, the safer it is.
5. To import a file, from the Baselines Controls menu, select Import Baseline.
6. Name your custom baseline. Spaces and some special characters are allowed. If the name is SFDC recommended or Salesforce Baseline Standard, the file fails to import.
7. Give your custom baseline a unique API name. You can use letters and numbers, but the name must begin with a letter. It can't contain spaces or special characters.
8. Optionally, make your custom baseline the default baseline in Security Health Check.

1. Set up the Salesforce CLI or a Metadata API client. See the Metadata API Developer Guide.
2. Use the retrieve() call to extract the following key metadata types:
   • SecuritySettings — Session Settings, Password Policies, Network Access
   • PermissionSet — User permissions and access settings
   • NetworkAccess — IP login range controls
   • AiSettings — Einstein AI and Agentforce governance settings
3. Store the resulting XML files in a version control system (such as Git) to create an auditable, time-stamped history of your security configuration.

1. Run a new 'retrieve' to capture the current state of your org's security settings.
2. Compare the output against your baseline XML files stored in version control.
3. Review diffs to identify any settings that have changed from the approved baseline.

1. Update the relevant XML configuration file to reflect the desired, compliant state.
2. Use the 'deploy' call to push the corrected configuration back to your org.
3. Run a new 'retrieve' and compare the output against your baseline to confirm the fix was applied correctly.

Note Test all deploy operations in a sandbox before applying to production.

Store retrieved XML files in a version control system such as Git to track configuration changes, detect security drift, and require peer review before deploying changes.

For full technical specifications, see the Metadata API Developer Guide.