SuiteCRM security hardening

Patch releases and minor releases play different roles in a SuiteCRM hardening plan, so they should run on separate schedules. SuiteCRM 8 minor 8.x releases arrive roughly every eight weeks and can add features and database changes. Patch releases contain only security and bug fixes, with no new features and no database changes. That makes a patch a narrower change that a team can schedule sooner than a minor upgrade, usually once the fix has been reviewed and tested against its own environment. The practical result is two tracks: a short, pre-approved path for security patches and a planned, tested path for minor upgrades that bring new behavior.

A patch is still a change to a live CRM, so it needs a staging test. Deploy the patch to a copy of production that includes your custom modules, fields, layouts, logic hooks, workflows, and any SAML or LDAP settings. Then run the checks that matter most for hardening: login as each role, confirm that security group restrictions still hide records from users who should not see them, confirm that API clients still authenticate, and confirm that scheduler jobs still run. Take a file and database backup before the change, and record the version and configuration you rolled back to, so a failed patch can be reversed quickly.

The longer-term risk is the support gap. SuiteCRM 8 has no named extended support release yet. The SuiteCRM LTS page states that no SuiteCRM 8 extended support release has been nominated, and that SuiteCRM expects to name one by Q3 2027. Until then, the 8.x line you run is the line that receives fixes, so the team must keep moving within it. Sites still running SuiteCRM 7 have a different position: the 7.15 extended support release receives security fixes until January 2028. Ask your partner or internal owner to document which line you run, who receives release alerts, and what happens when that line stops receiving fixes.

Confirm the current release before you plan any window. SuiteCRM 8.10.2 and SuiteCRM 7.15.2 were both published on July 31, 2026. Newer releases may have shipped since then, so check the SuiteCRM-Core and SuiteCRM releases pages on GitHub before setting a date. For each release you consider, read the notes for security fixes, check whether PHP, Apache, or MariaDB and MySQL versions have changed against the SuiteCRM 8 compatibility matrix, and decide whether the release belongs on the fast patch track or the planned minor track.

Running a SuiteCRM 8.10 server on a PHP, Apache or database version outside the published compatibility matrix is a hardening gap in its own right, and it should be closed with a planned upgrade rather than left to the next maintenance window. The matrix for SuiteCRM 8.10 lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4, running on Linux, Unix or macOS. Any server that falls outside those combinations should be recorded in the security review as a finding with an owner and a target date.

Start by inventorying what is actually running. Check the PHP version the web process uses, not only the command-line binary, because mod_php, PHP-FPM pools and scheduler jobs can point at different installations. Confirm the Apache release and the database engine and version on every node, including any replica and any host that runs cron or the SuiteCRM scheduler. In a load-balanced setup, a single node on an older PHP build can keep an otherwise compliant environment outside the matrix, so the inventory should cover every host that serves or processes SuiteCRM traffic.

Plan the change as a version upgrade with a rollback path. Take a full backup of the file tree and the database before touching anything, and confirm that the restore has been tested rather than assumed. Build a staging copy from the production backup, apply the PHP, Apache or database change there, and run login, role-based record access, scheduled jobs, email sending, and any custom modules or integrations. Customizations are the most common source of breakage after a PHP minor version change, so the test list should be drawn from your own customization inventory, not from a generic checklist.

Confirm the matrix for the exact release you are targeting before you commit to a stack. The compatibility matrix changes as SuiteCRM releases arrive, and a version that is supported on 8.10 may not be listed for a later 8.x release, or the reverse. Record the matrix version you checked, the release number, and the date of the check in your change record. If you are still on a SuiteCRM 7 instance, the matrix for SuiteCRM 8 does not apply to it, and the move to 8 is a migration planned separately.

Ask your SuiteCRM partner or internal platform team to confirm three things in writing: which PHP and database versions the target release supports, whether any extension or library your customizations rely on has its own version limits, and how the upgrade will be tested before cutover. A fixed-scope plan should name who performs the staging tests, who signs off, and how the rollback is executed if a test fails. Treat any stack version that is end-of-life for its vendor as a risk to be scheduled, not as an acceptable exception.

When SuiteCRM uses SAML for login, signing out at the identity provider does not end the SuiteCRM session. The SuiteCRM 8.7.0+ SAML configuration reference states that IdP-initiated logout and POST binding to the logout service are not supported. A user who signs out of the Microsoft Entra ID or Keycloak dashboard still holds a live SuiteCRM session in the browser until that session expires or the user signs out of SuiteCRM itself. Treat this as a fixed property of the login design and build your controls around it. Confirm the current behavior against the exact SuiteCRM 8 release you plan to run, because the configuration reference is the authoritative statement of what is supported.

The risk is greatest on shared, kiosk or unattended workstations, such as call center desks, branch terminals or meeting-room PCs. A colleague who sits down at a browser that a previous user only signed out of at the identity provider may reach customer records, pipeline data and email activity without a password prompt. The same exposure applies to laptops left open in public places or at home. Your risk assessment should record which roles use shared devices, what data those roles can see through their security groups and roles, and whether exports or API tokens stay usable from a session that should have ended. Those answers decide how strict the timeout and education controls need to be.

Plan three mitigations together. First, shorten session lifetimes in the web server, PHP and SuiteCRM configuration. Confirm the exact setting names and supported values in the SuiteCRM 8 release documentation for your version, because this page does not give a default. Second, teach users that signing out of SuiteCRM, and closing the browser on a shared device, is part of ending their work. Signing out of the identity provider alone is not enough. Third, write an offboarding procedure. Disabling the account in the directory stops new logins, but confirm whether that change also ends an open SuiteCRM session or whether the session runs until it expires. The procedure should then check for active SuiteCRM sessions for the leaving user and end them.

LDAP is the alternative login path, enabled with AUTH_TYPE=ldap and built on the Symfony Security LDAP authenticators. It changes the hardening baseline in two ways. SuiteCRM binds to the directory, so the bind account's password, its read scope and how it is stored become part of your controls. Account disablement also works differently from a federated logout: a user disabled in the directory cannot authenticate again, but you should check the LDAP configuration reference for how existing sessions and cached user records are handled. Choose LDAP or SAML for each environment deliberately. The detailed SSO design, including attribute mapping, certificates and the full logout limitations, belongs to the SuiteCRM SSO with SAML and LDAP topic.