CommunitySuite provides a range of security settings that allow your organization to control how back-end users log in and authenticate. These settings are not one-size-fits-all. The right configuration depends on your organization's size, workflows, and tolerance for friction. This article walks through three tiers of recommended settings configuration, from a solid baseline to the most secure configuration available. Each tier builds on the one before it.
Who: CommunitySuite administrators who manage back-end user access and security settings.
When to Review Login Security Settings
Use these login security recommendations when:
- Reviewing or configuring security settings for your CommunitySuite back-end users.
- You want to strengthen your organization's login security but are not sure where to start.
Access User Settings
To access User Settings in CommunitySuite:
- Navigate to the Users page and click Settings in the left-side menu.
- Click Edit Settings.
User Settings describes all settings available on the settings page.
Changes to password policy settings affect all back-end users in your system. Before enabling new settings, consider communicating the changes to your team and establishing an internal process for password resets. This is especially important before enabling Disable Employee Password Reset Via Email.
New User Settings
Three new security settings were added to the User Settings page effective March 19, 2026. All are opt-in and have no immediate impact unless enabled.
Disable Employee Password Reset Via Email - Prevents back-end users from using the forgot-password email flow to reset their own password. When enabled, a site administrator must reset the password on the user's behalf. This is useful for organizations that want to reduce the risk of unauthorized access through a compromised email account. Before enabling this setting, establish an internal process for handling password reset requests, including coverage when admins are out of office.
Force SSO Login - Applies only to organizations that have SSO configured. When enabled, users linked to SSO must authenticate exclusively through their SSO provider and cannot bypass SSO with a username and password. See the CommunitySuite Single Sign On article for setup guidance.
No Email 2 Factor For All Profiles - Restricts two-factor authentication (2FA) to a phone number or authentication app for all users, including internal staff and Portal users. This will remove the option to receive verification codes via email. App-based 2FA is generally considered more secure and more resilient against account compromise.
Security Setting Recommendations
The table below outlines three tiers of recommended configurations for CommunitySuite back-end user login settings, each building on the one before it. Review the comparison table and the Understand Each Security Tier section that follows it to determine which tier best fits your organization's needs.
| Setting | Good | Better | Best |
|---|---|---|---|
| Unique Login ID (not using the default profile email) | Yes | Yes | Yes |
| Password Policy Enabled | Yes | Yes | Yes |
| Minimum Password Length | 12 characters | 16 characters | 16 characters |
| Character Types Required | All (lower, upper, number, special) | All (lower, upper, number, special) | All (lower, upper, number, special) |
| Minimum Different Character Types | 3 | 4 | 4 |
| Minimum of Each Character Type | 1 | 1 | 1 |
| Require Two Factor Login | No | Yes | Yes |
| Max Failed Attempts | 4 | 3 | 3 |
| Disable Employee Password Reset Via Email | Yes | Yes | Yes |
| No Email 2 Factor For All Profiles | No | No | Yes |
Understand Each Security Tier
The following section provides details on the three tiers of recommended security configurations.
Good: A Strong Baseline
The Good tier closes the most common vulnerabilities without requiring significant workflow changes. Unique login IDs ensure that publicly available email addresses cannot be used as a starting point for unauthorized access. A 12-character password policy with all character types adds meaningful strength. Disabling the email password reset flow removes one of the most common attack vectors while keeping login straightforward for users who still do not require two-factor authentication.
Better: Add Two-Factor Authentication
The Better tier adds two-factor login as a requirement for all users, which is one of the most impactful changes an organization can make to reduce unauthorized access risk. The password length is increased to 16 characters, and the number of required different character types increases to 4, tightening brute-force resistance. Max failed attempts drops to 3 to further limit attack windows.
Best: Phone or App-Only 2FA
The Best tier builds on Better by restricting two-factor authentication to phone or authenticator app only, removing the option for users to receive codes by email. This eliminates the risk of email compromise being used to bypass 2FA. This configuration provides the strongest available protection for back-end user accounts in CommunitySuite.
Secure Your Identity Provider Before Enabling Force SSO Login
If your organization has Single Sign-On configured, enabling Force SSO Login ensures that users cannot bypass SSO by logging in with a username and password directly. SSO consolidates authentication into one set of credentials managed by your identity provider, such as Microsoft 365, Google Workspace, or Okta.
Because SSO consolidates access into one point of entry, it is important to ensure your identity provider itself is protected by strong controls such as multi-factor authentication before enabling Force SSO Login. If SSO credentials are compromised, a bad actor could gain access to CommunitySuite and any other systems linked through that provider. CommunitySuite Single Sign On provides more details on configuring SSO.
Get Help from Foundant Support
The Foundant Support Team is available to help you review and configure these settings. Contact Support by email or through the chat icon at the bottom of any Foundant site.
Resources: