Why EspoCRM security hardening is more than switching on 2FA
If you run or are about to run a self-hosted EspoCRM instance that holds customer and pipeline data, hardening covers five areas: authentication, admin practice, API access, server transport and file permissions, and update discipline. Each area has its own settings, its own owner and its own failure modes, so treat hardening as a set of decisions rather than a single switch. Enabling two-factor authentication is one control among many, and on its own it leaves most of the exposure in place.
The first surprise is that EspoCRM's own 2FA is not compatible with OpenID Connect. If your identity provider handles sign-in through OIDC, you cannot rely on EspoCRM's 2FA for those users, so the second factor has to be enforced by the identity provider and you should confirm that policy with your identity team before go-live. The fallback login method for administrators also needs a deliberate decision, because it is the path an attacker will try when the main sign-in is locked down. Password policy, auth token lifetime and disabling password recovery for admins belong to the same review.
The second surprise is that API users carry their own permissions. An integration account is a separate user with a role, so a website form or ERP connector may hold far more access than anyone expects. The EspoCRM API documentation describes HMAC as the most secure supported method and does not recommend basic authentication. Your integration owner should review each API user's role, confirm the authentication method, and check whether IP restrictions apply to those accounts, since a permissive role on an API user can expose the whole customer table.
The admin role concentrates risk. The security guidance recommends that administrators avoid using admin accounts for daily work, so every administrator should have a second, ordinary account for email and pipeline tasks. Assign administrative configuration rights to a small named group, log who changes the Entity Manager and roles, and treat the admin team as the owner of identity, roles and IP restrictions. Platform engineering or the security team usually owns server transport and file permissions, including TLS certificates and write access to configuration files.
Update discipline changed in version 10.0, where upgrading through the user interface is disabled by default. Your operations team needs a documented upgrade path from the command line, a tested backup before each change, and a check of custom code and extensions against the new release. Your release calendar should follow the EspoCRM GitHub releases page, and you should confirm the upgrade procedure in your own environment. The self-hosted AGPL-3.0 edition leaves all of this configuration to the operator, so the work, and its ongoing ownership, sits with your team or with a partner you hire for it.
Which authentication and access options fit your risk profile
This table compares the main ways to control sign-in and access to an EspoCRM instance, along with the API authentication methods. Read each row for the situations where the option fits and the operational work it adds. The main takeaway is that identity provider sign-in moves MFA to your identity platform, so you must plan admin fallback access and replace EspoCRM's own 2FA controls with identity provider controls.
| Option | When it fits | Operational cost |
|---|---|---|
| Password policy with EspoCRM 2FA | Teams without a central identity provider and a modest number of users | Staff enroll their own 2FA; admins maintain password policy and recovery settings |
| OpenID Connect with identity provider MFA | Organizations already running Entra ID, Keycloak or another OIDC provider that enforces MFA | EspoCRM's own 2FA does not apply; keep a tested fallback login for admins |
| LDAP or Active Directory | Estates where directory group membership already controls application access | Bind accounts, group mapping and directory changes need ongoing review; confirm the setup with the EspoCRM docs |
| IP restriction at the network edge | Staff who work from fixed offices or a VPN with known egress addresses | Allow lists need updates as staff, contractors and remote work change; define an exception process |
| API key | Integrations that use a dedicated API user with narrowly scoped role permissions | Keys act as shared secrets; schedule rotation and review API user roles regularly |
| HMAC | Integrations where the EspoCRM docs' most secure method is required | Each client must sign requests correctly; test signing in staging and manage the secret store |
| Basic authentication | Not a recommended choice; the EspoCRM docs advise against it | Credentials travel with each request; avoid it for production integrations |
How 2FA, OIDC and admin fallback logins fit together
The point to settle first is that EspoCRM's own two-factor authentication is not compatible with OpenID Connect. Users who sign in through SSO never reach the EspoCRM 2FA prompt, so the second factor for those users has to come from the identity provider. Teams often assume that turning on 2FA in EspoCRM covers everyone, and that assumption leaves SSO users with only a password at the application layer. Before go-live, confirm in your identity provider that MFA is enforced for every group that can reach the CRM, and test it with a user from each group. Check that the policy applies to the EspoCRM application itself, not only to a general directory login that some users may already have passed.
OIDC support in EspoCRM includes a fallback login method, which lets a local account sign in when the identity provider is unavailable or misconfigured. That path is a second entrance to the instance, so it needs its own controls. Confirm with the EspoCRM OIDC documentation how the fallback is enabled in your version, and whether EspoCRM's 2FA can be applied to fallback accounts. If it cannot, compensate with a long, unique password stored in a controlled vault, a written break-glass procedure with named approvers, and alerting on any fallback sign-in. Treat each fallback use as an incident to review, not as routine access.
Admin accounts should be restricted to that fallback path. The EspoCRM security documentation advises against using admin accounts for daily work, so administrators should hold a separate, non-admin named account for everyday CRM tasks, signed in through SSO with the identity provider's MFA. The admin role is then used only through the controlled fallback login when it is needed for configuration or recovery. The same guidance recommends disabling password recovery for admins, so a reset email cannot become a backdoor. Confirm in your own environment that recovery is off for every admin account and that the admin accounts are the only local accounts with elevated roles.
Deciding which users sign in with local passwords and which through SSO is a population decision, not a per-user preference. Employees who use the CRM daily should sign in through SSO, so offboarding in the identity provider removes their access. Local passwords should be limited to the fallback admin accounts, and API access should use dedicated API users, which are a separate matter. Record the decision as a table of user groups, sign-in method, MFA owner and recovery policy, and review it whenever roles change. For connection details such as provider setup, group to team mapping and backchannel logout, see the EspoCRM SSO and identity integration topic rather than repeating them here.
How to harden an EspoCRM instance in sequence
This sequence moves from the server and network edge inward to accounts, integrations and file system. Each step closes with a test, so the team can show that every control works on the installed version before the instance is used for live customer data.
Confirm supported stack versions
The server or platform team compares the PHP, database and web server versions on the host with the EspoCRM server configuration docs for the release being installed. The docs list PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15, and Apache, Nginx or IIS. Confirm that cron or a scheduled task runs background jobs as the docs require, and replace any unsupported component before changing security settings. Done when the reported versions match the documented matrix and a scheduled job logs at least one successful run.
Enable TLS and redirect HTTP
The web server team installs a valid certificate, configures TLS, and redirects every plain HTTP request to HTTPS. The installation script can request Let's Encrypt certificates, but internal certificate authorities and corporate certificates need manual web server configuration. Confirm the directive names in the Apache, Nginx or IIS documentation for your version, and set the EspoCRM site URL to an https address. Done when an HTTP request returns a redirect to HTTPS, and an external TLS check reports a trusted chain with no protocol warnings.
Set password policy and enforce 2FA
An administrator sets the password policy in the administration settings, covering the length, complexity and reuse rules your security policy requires, then requires two-factor authentication for local accounts. Confirm the exact setting names and accepted values in the EspoCRM security docs for the installed version, since they can change between releases. EspoCRM's own 2FA is not compatible with OpenID Connect, so decide on SSO and its MFA controls before enforcing it. Done when a test user is prompted for a second factor at sign-in, and a password that breaks the policy is rejected.
Limit auth token lifetime
The administrator sets the authentication token lifetime so that idle sessions expire within the window your policy allows. Confirm the setting name, its unit and whether it also governs API tokens in the security docs for your version. Apply the value to a staging instance first, then record it in the configuration baseline. Done when a test session left idle past the configured lifetime requires a fresh sign-in, and the result is logged with the change record.
Restrict access by IP address
The administrator lists the networks allowed to reach the login and API endpoints, using the IP restriction settings described in the security docs. Include office egress addresses, VPN ranges and integration servers, then ask the network team to confirm the list is current. If a load balancer or reverse proxy sits in front, verify that EspoCRM sees the real client address, or the restriction will apply to the proxy. Done when a login from an unlisted network is refused, a login from an allowed network succeeds, and the client address in the logs matches the source.
Separate admin and daily-use accounts
Create named administrator accounts used only for configuration, and give every staff member a standard user with the roles their job needs. Confirm in the security docs for your version whether password recovery can be disabled for admin accounts, then disable it so a reset request cannot bypass the policy. Done when an administrator signs in only for configuration work, a standard user cannot open administration pages, and a recovery request for an admin account produces no usable reset link.
Create API users with minimal roles
Create one dedicated API user per integration, assigned a role that grants only the entities and actions that integration needs. Select HMAC as the authentication method, since the EspoCRM API docs describe HMAC as the most secure option and basic authentication as not recommended. Store the secret in your secrets manager, not in the integration's code or configuration files. Done when the API user reads and writes its permitted entities, receives a forbidden response for an entity outside its role, and a request signed with the wrong secret is rejected.
Lock file permissions and set update routine
The server administrator sets file ownership so the web server user can read application files and write only to the directories EspoCRM needs for data, cache and uploads, and the configuration file is not readable by other local users. Confirm the required permissions in the installation docs for your release. Then set the update routine: UI upgrades are disabled by default as of version 10.0, so schedule command-line upgrades in a staging copy after a verified backup. Done when a write to application code as the web user fails, and a staged upgrade completes from a recorded backup.
How hardening changes on single server, container and multi-server builds
On a single server, EspoCRM, the web server, PHP, the database and background jobs share one operating system, so most controls sit in one place. EspoCRM supports Apache, Nginx or IIS in its server configuration docs, and the web server is usually where TLS terminates. Each control below should be checked against the security and server configuration docs for your installed version.
- TLS: Terminates at the host's web server. Confirm certificate handling and HTTP to HTTPS redirect rules for your web server.
- IP restrictions: Can be set in the web server, in host firewall rules or in EspoCRM's own settings. Pick one primary layer and document it so administrators know where to change it.
- File permissions: The web server and PHP user need write access only to the directories EspoCRM requires. Keep configuration files readable only by the accounts that need them, and confirm the exact paths for your version.
- Cron and WebSocket: Cron runs as a scheduled job under a host account, so restrict who can edit that crontab. Confirm whether the WebSocket daemon is enabled and which account runs it.
Before go-live, check which accounts run PHP, cron and the daemon, and confirm each one against the security documentation for your installed version.
The installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB, with optional Let's Encrypt certificates. In this model, TLS typically ends at the Nginx container on the host's public interface, and the certificate workflow is part of the script. Containers separate processes, but file ownership still matters because the user ID inside a container can differ from the owner of the host directory mounted into it.
- TLS: Let's Encrypt is optional. If you skip it, you must supply certificates yourself and configure the Nginx container to use them.
- IP restrictions: Nginx can filter by client address, and the host firewall controls which ports are published. Container networking can change the client address the application sees, so confirm the trusted proxy settings before relying on IP rules inside EspoCRM.
- File permissions: Volumes map host paths into containers. Check ownership on both sides of each mount, and avoid giving containers write access to paths they do not need.
- Cron and WebSocket: Confirm whether background jobs run in a container or on the host, and which container exposes the WebSocket path to clients.
Use the command.sh utility and the installation docs to confirm which containers, volumes and published ports your version creates before you write firewall rules.
Multi-server layouts separate the database, application servers and shared file storage, so each control must be applied at more than one point. TLS often terminates at a load balancer or reverse proxy in front of the application servers, which changes the client address the application records. Shared storage also means one ownership model must hold across every host. Resilience design is covered in the high availability topic, so this tab focuses on the controls.
- TLS: Terminate at the load balancer or on each application node. Choose one model and confirm how traffic between tiers is encrypted.
- IP restrictions: Enforce them at the edge load balancer or network firewall first. Application-level rules see proxy addresses unless forwarded headers are trusted correctly, so confirm that configuration for your version.
- File permissions: Shared storage needs consistent user and group IDs across nodes, and only application accounts should have write access. Confirm how uploads and custom code directories are shared.
- Cron and WebSocket: Run scheduled jobs on one designated node so jobs do not duplicate. Confirm where the WebSocket daemon runs and that it is reachable only from the application tier.
Test each control from outside the network and from each tier, then confirm the scheduling and daemon placement against the EspoCRM documentation for your version.
How to lock down API users and HMAC authentication
Every integration that calls EspoCRM should use its own dedicated API user, with a role that grants only the entities and actions that integration needs. Do not reuse an administrator account, and do not run an integration under a person's login. A personal account carries that person's access, changes when they change roles, and leaves no clear trail when the integration does something unexpected. In practice, create one API user per integration in the user administration, give it a descriptive name that identifies the system, and assign a role that starts from no access and adds permissions one entity and action at a time. Record who owns each API user so that someone can answer for it during a review.
The EspoCRM REST API supports API key, HMAC and basic authentication through API users. The API documentation describes HMAC as the most secure of these methods and does not recommend basic authentication. HMAC signs each request with a shared secret, so the secret itself is not sent with every call, which makes it a better fit than a static API key for any integration that handles customer data. Before you build, confirm which method your integration client supports and whether it can produce the signature EspoCRM expects. If a client can only send basic authentication, treat that as a finding to resolve with the vendor or the integration developer, not as a default to accept.
Store each API secret outside the EspoCRM application files and outside source code repositories. A secrets manager, or environment variables injected at runtime by the platform that runs the integration, keeps the value out of version control, configuration backups and developer laptops. Restrict who can read the secret to the people and services that need it. For rotation, generate a new secret, update the integration, confirm that calls succeed with the new value, and then invalidate the old one. Agree the rotation interval and the process for an emergency rotation with your security team in advance, and confirm how the instance records changes to API users so that rotations appear in your audit trail.
Test that the API user cannot read or change anything beyond its role before it goes live. Write a short test plan that lists the entities the integration should reach, then make requests with the API user for entities it should not reach, for actions it should not perform, and for records owned by other teams. Expect each of these calls to be refused, and keep the results as evidence. Repeat the tests after any role change, after each upgrade and after any custom entity or field is added, because new fields can widen what a role exposes. Integration patterns, webhooks and sync error handling are covered in the REST API integration topic.
What drives EspoCRM security hardening effort and how to keep it down
This table lists the factors that change how much work EspoCRM security hardening takes and one practical way to reduce each one. Read each row as a question to answer about your own instance before requesting a fixed-scope quote. The main takeaway is that roles, identity, and configuration documentation shape most of the effort, so settling them early keeps the scope predictable.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of user groups and roles | Each role needs its own permission review across entities, fields, and scopes, and overlapping roles multiply the cases to test. | Build a small set of role templates for common job functions and assign them to teams instead of tuning each user. |
| Number of integrations using API users | Every integration needs a dedicated API user with the narrowest permissions, plus a choice of HMAC or API key authentication and a test of what it can reach. | Reuse one API role pattern per integration type and prefer HMAC authentication, and list each integration with its required entities before work starts. |
| Existing SSO and identity provider | Without an identity provider, the team must set password policy, 2FA and token lifetime directly in EspoCRM. With OpenID Connect, 2FA and login rules move to the provider, but group mapping and fallback login must be designed and tested. | Standardize on one identity provider and map its groups to EspoCRM teams, so access rules live in one place. |
| Customizations and extensions to review | Custom PHP, front-end code, formula before-save scripts and extensions need a security review, and each one can open access paths that the core settings do not cover. | Inventory every custom script and installed extension, and keep customizations in the custom directory so the review can focus on a known list. |
| Multiple environments such as staging and production | Settings, roles and API users must match across environments, and drift between them is a common source of rework and missed findings. | Keep configuration as code where possible and export settings from one environment to apply the same baseline to the others. |
| Hosting model | A self-managed server requires work on TLS, file permissions, IP restrictions, database access and the update process. A managed cloud plan moves some of these controls to the provider, but the provider's settings must still be verified. | Confirm in writing which controls the hosting provider manages and which the client owns, then scope only the remaining items. |
| Compliance evidence requirements | An assessor may ask for proof of each control, such as configuration exports, access reviews and change records. Gathering that evidence after the fact takes more time than capturing it during hardening. | Ask the assessor which evidence formats they accept and capture configuration snapshots and role exports at each change. |
Which EspoCRM settings, secrets and server controls to verify
Each card names one control area, where it is set or enforced, and the evidence to keep. Setting names, default values and file paths change between EspoCRM versions, so confirm them against your installed version and the EspoCRM security documentation before you record a result.
Password policy and two-factor authentication
Confirm that the password policy sets minimum length, complexity and reuse rules in the administration settings, and that two-factor authentication is required for every internal user, including administrators. EspoCRM's own 2FA is not compatible with OpenID Connect sign-in, so if single sign-on is in place, the identity provider must enforce the second factor for those users. Keep a dated export of the policy settings and a report of which users are enrolled in 2FA.
Auth token lifetime and IP restrictions
Check the maximum lifetime of authentication tokens and confirm that idle sessions expire within the window your access policy sets. Then verify that IP restrictions limit administrative access and, where your network design allows it, user access to known address ranges. Test both from outside the allowed network, because a reverse proxy can change the client address the application sees and make a correct-looking rule ineffective. Record the configured values and the test results.
Admin accounts and admin password recovery
Confirm that each administrator has a named account, that routine work happens in standard user accounts, and that any shared or break-glass admin account is documented, protected and disabled when not in use. Verify that password recovery is disabled for admin accounts, as the security documentation recommends, and agree in advance who resets an admin password and how that reset is authorized. Keep the admin roster, the date of the last review and the written recovery procedure.
API users and HMAC secrets
Give each integration its own API user with the narrowest role that supports the entities and actions it needs. The REST API documentation describes HMAC as the most secure supported method and basic authentication as not recommended, so confirm that no integration relies on basic authentication. Store HMAC secrets in a secrets manager, name an owner for each rotation, and test that a rotated secret stops working in every connected system. Keep the role definitions, a secret inventory and the rotation log.
TLS, certificates and server file permissions
Confirm that the web server accepts only the TLS versions your policy allows and that certificates renew automatically, with an alert if renewal fails. If you used the installation script with Let's Encrypt, check that the renewal job runs and that its log is monitored. On the server, confirm that application files are not writable by the web server account, except the directories that must hold uploads, cache and logs. Review the custom directory separately, because custom PHP runs with the server's privileges. Keep the TLS scan result and the permission audit output.
Cron accounts and database credentials
Background jobs run through cron or a scheduled task, so confirm which operating system account runs them and that it is neither root nor the web server account. Give the application its own database user with only the privileges the platform requires, and keep that password out of files that other accounts can read. Confirm that the database server accepts connections only from the application servers. Keep a record of the job account, the database grants and the date of the last credential rotation.
How to verify EspoCRM hardening works and what to monitor afterward
Every control in the hardening plan needs a test that shows it blocks what it should block, and a second test that shows a legitimate user still gets through. Run these tests on a staging copy built with the same server configuration, web server and TLS settings as production, and keep a dated record of each result. Start with the password policy. Attempt a login with a password that breaks the policy in place and confirm the account is not authenticated and the policy rule is shown. Then sign in with a compliant password to confirm normal access. Use at least one standard user, one team member and one admin account, because a control that works for one role has not been tested for the others.
Next, test the session controls. Enroll a test user in two-factor authentication, sign out, and sign in again to confirm the code challenge appears and that an incorrect code is refused. Check which roles the 2FA requirement applies to, since a policy that covers only some users leaves gaps. For token lifetime, sign in, leave the session idle past the lifetime you configured, and confirm the next request requires a fresh login. Record the value you tested so the result matches the configuration in your change log. If you plan to use OpenID Connect, note that EspoCRM's own 2FA is not compatible with it, so the test plan must follow your identity provider's MFA instead.
Test the network and API controls next. From an address outside the allowed range, attempt a login and confirm the request is refused before any credential check. If EspoCRM sits behind a reverse proxy, confirm which address the application reads as the client, because a misread address can make an allow list block everyone or let everyone through. For the API, create a test API user with a role that allows one entity and denies another, sign requests with HMAC, and confirm the denied call returns an authorization error while the allowed call succeeds. Send an unauthenticated request over plain HTTP and confirm it is redirected to HTTPS or refused, according to your configuration. Finally, request a password reset for an admin test account and confirm that no reset is issued.
After go-live, monitor the signals that show the controls still work. Review failed logins by account and source address, and alert on bursts. Track admin role changes and new admin accounts, since these changes matter most for a privileged role. Compare API user activity against the calls each integration is expected to make, and confirm how long your logs are retained and where they are stored. Track certificate expiry dates and confirm who or what renews them, especially if you used the optional Let's Encrypt setting in the installation script. Watch the EspoCRM releases page for pending updates. Keep a version control or file integrity record for the custom directory so every change to custom PHP or front-end code has an owner and a reason. Write the test results, configured values and owners into the runbook.
The update discipline ties these checks together. UI upgrades are disabled by default starting with version 10.0, which EspoCRM released on July 2, 2026, so the command line is the upgrade path to confirm for your installation method. Check the exact steps in EspoCRM's documentation or with your implementation partner before you rely on them, including what the command.sh utility does in your deployment. Test every upgrade on staging first, using a recent copy of production data, your custom code and every extension you run. Rerun the controls in this section after each upgrade, because a release can change a default setting. Schedule production only after the staging run passes, with a tested backup and a rollback plan in place.
What buyers ask about EspoCRM security hardening cost, time and ownership
What does EspoCRM security hardening cost?
No price is published for this work, and a figure only makes sense once the scope is written down. The cost follows from a handful of components: how many configuration areas are in scope (password policy and 2FA, auth token lifetime, IP restrictions, admin account hygiene, API user permissions, TLS, file permissions and update discipline), how many instances and environments need the same treatment, how much of your identity setup must be inspected, and how much verification and handover documentation you want. Most engagements are fixed-scope, so ask for a written scope listing each area, the environments covered, the deliverables and the timeline. Also ask which items are one-time (the baseline configuration and documentation) and which recur (periodic review, patching and retesting under a retainer). DeployOpen does not publish a price list; a quote follows from the written scope.
How long does EspoCRM security hardening take?
Duration depends mainly on scope and on how quickly your team can provide access and decisions. A single self-hosted instance with a standard configuration review takes less time than a hardened setup that also covers OpenID Connect sign-in, HMAC API integrations, reverse proxy and TLS work across several environments. Delays usually come from waiting for identity provider access, change approvals for production, or unresolved questions about which admin accounts and integrations must keep working. Ask for the timeline as milestones in the written scope, with the dependencies on your side named explicitly. Confirm the change window for production and whether a staging copy is available for testing before any setting changes go live.
What does our internal team need to provide for hardening?
Your team provides access, decisions and ownership. Expect to supply administrator access to the EspoCRM instance and its host, read access to the identity provider if single sign-on is in scope, and a named owner for each admin account. Network and certificate responsibilities must be assigned: who controls DNS, the reverse proxy, firewall rules for IP restrictions, and the TLS certificate lifecycle. You also need an integration inventory listing every system that calls the REST API, which API users they use and which authentication method they rely on, so that permissions and HMAC changes do not break live sync. Finally, name who approves production changes and who receives the handover documentation.
Can a competent internal team harden EspoCRM without outside help?
Yes, a competent team can harden EspoCRM alone, provided it has the time, access and review discipline to do it properly. The EspoCRM security documentation describes the main measures, including a password policy, mandatory 2FA, avoiding admin accounts for daily work, limiting auth token lifetime, disabling password recovery for admins and restricting access by IP address. The harder parts are verifying each change against your integrations, testing on a copy before production, and documenting the result so that the next administrator can maintain it. Outside help is most useful when the team lacks that bandwidth, needs an independent review, or must show evidence to an assessor. Note that 2FA built into EspoCRM is not compatible with OpenID Connect sign-in, so the two designs must be planned together.
Does hardening EspoCRM make the instance compliant?
No. Hardening reduces risk in the application and its host, but compliance is a property of the whole control environment, including policies, access reviews, change management, logging, backups, vendor management and staff training. DeployOpen prepares systems, configurations and evidence for compliance assessments, such as configuration baselines, access records and documentation of how controls operate. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, and the scope of their assessment is decided by them and by your organization. Ask any provider to map the hardened settings to the control framework your auditor uses before assuming coverage.
Who owns EspoCRM after the hardening work is finished?
Your organization owns the instance, its configuration, its accounts and its evidence once the work is handed over. A written handover should cover the baseline configuration, the list of admin and API users with their purpose, the IP restriction and TLS settings, the process for upgrades and patches, and the steps to verify the configuration after an upgrade. Ongoing responsibilities include reviewing admin accounts, rotating API credentials, renewing certificates and applying EspoCRM releases. These can stay in-house or move to a DeployOpen retainer for ongoing support, upgrades and continuous testing. Confirm in the scope which responsibilities transfer and which remain with your team.
What should a written EspoCRM hardening scope include?
A useful scope names each configuration area in scope, the instances and environments covered, the integrations and identity providers involved, and what is excluded. It should list the deliverables, such as a configuration baseline, a change record, a test summary and handover documentation, and state the acceptance steps. It should also name the client dependencies from the sections above, the production change process, the timeline as milestones, and whether any post-engagement support is included or offered separately. Ask how the provider will test changes against your integrations before they reach production, and how a rollback would work. A scope that reads as a list of general goals rather than specific settings is a reason to ask for more detail.
How DeployOpen scopes, hardens and hands over EspoCRM security work
DeployOpen treats EspoCRM security hardening as a fixed-scope piece of work inside your own infrastructure, agreed in writing before any change is made. The work covers the application settings, the API surface, the server and the operating routine, and ends with documented evidence your team can keep.
How we scope
- Review the current instance settings, roles, API users and server layout against the EspoCRM security recommendations.
- Agree which controls apply to your environment, such as password policy, 2FA, token lifetime and IP restrictions.
- Record the written scope, deliverables and assumptions, including any identity provider or SSO work handled separately.
How we build
- Apply password policy, mandatory 2FA where compatible, shorter auth token lifetime and admin password recovery restrictions.
- Replace shared or basic-authenticated API access with dedicated API users, limited roles and HMAC authentication where the integration allows it.
- Test each control after change, including login, API calls and file and TLS settings, and record the results.
How we hand over
- Deliver a written configuration record covering each setting changed, its reason and how to verify it.
- Document admin account separation, the update routine and the command-line upgrade steps for your team.
- Walk your administrators through the runbook and confirm they can repeat the checks without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial hardening is complete.
- Retainers can cover reviewing new EspoCRM releases and rechecking hardening settings after upgrades or extension changes.
- Confirm with us in the quote which post-handover activities are included and how often they are delivered.
