EspoCRM password and session policy setup

Setting EspoCRM password and session policy before users log in

Password, recovery and session settings decide who can get into your CRM, how long a stolen or forgotten login stays useful, and whether an administrator account can be reset by someone who only controls an inbox. A team should set them deliberately before the first user signs in, because a CRM holds customer contacts, pipeline values and account notes that are expensive to lose and sensitive to expose. Changing login rules after people already rely on a weak password or a long-lived session is more disruptive than setting them at go-live.

The EspoCRM security documentation recommends four moves that belong together: enforce a password policy, limit auth token lifetime, disable password recovery for admin accounts, and avoid using admin accounts for daily work. Each has a side effect. A strict password rule raises the support load for locked-out users, a short idle timeout interrupts long sales sessions, and turning off admin recovery means a lost administrator password needs a documented path through another administrator or server-side access. Confirm the exact settings and their labels in your EspoCRM version's administration screens before you write the policy down.

These choices interact with the other access controls. If you enable OpenID Connect sign-in, EspoCRM's own two-factor authentication is not compatible with it, so the identity provider's password and MFA rules become the effective login policy and the local password settings matter mainly for any fallback login you keep. IP restriction limits where logins can originate, which changes how much weight a session lifetime carries. Write one table of decisions covering password rules, recovery, token lifetime, 2FA and IP limits, and have the security owner sign off on it before go-live.

Password, recovery and session options and when each fits

This table compares each EspoCRM login policy setting by what it protects against, what it costs users and support staff, and the deployments where it usually fits. Read it as a starting point for your own policy: confirm the exact field names and accepted values in your EspoCRM version before you commit to a setting.

Setting	What it protects against	Trade-off for users and support	When it fits a regulated or high-exposure deployment
Password strength rules	Guessable or reused passwords used for credential stuffing and brute force	Stricter rules raise reset requests and helpdesk calls; users may write passwords down	Almost always, paired with 2FA for staff who can see customer or financial records
Recovery link lifetime	Reuse of an old reset link found in mail archives or a shared inbox	Short lifetimes frustrate users who open email late; support may resend links often	Short lifetimes where recovery mail passes through shared or third-party mail systems
Admin recovery disabled	Attackers who take over an admin mailbox and reset administrator passwords	Admins who lose access need another admin or a documented break-glass process	Strongly suited to high-exposure deployments, provided a second administrator and an offline recovery path exist
No-exposure recovery	Account enumeration through recovery responses that reveal whether an address has an account	Users may be unsure whether their request worked, so support needs a clear message to give	Fits deployments where the user list itself is sensitive, such as public-facing or portal logins
Auth token idle time	Abandoned sessions on shared or unlocked workstations being reused	Users who step away may be logged out and lose unsaved work in long forms	Fits shared desks, call centers and any site with unattended terminals
Auth token lifetime	Long-lived tokens that remain valid after a device is lost or a role is changed	Forced re-login more often; integrations that expect long sessions may need review	Fits deployments that must limit how long a stolen session stays usable, and where access reviews run on a fixed cycle

How to configure EspoCRM login policy in order

This sequence sets EspoCRM's password rules, recovery behavior and session lifetimes in a deliberate order, so each control is tested with a non-admin account and the final settings are documented for audit and operations.

Agree the login policy with security and IT
Before touching the administration area, security and IT leads agree in writing on minimum password strength, whether password recovery is allowed for admin accounts, how recovery links should behave, and how long idle and absolute sessions may last. Name who approves changes and who holds the admin accounts. Write the decisions in a short policy note so each setting in later steps traces back to an approved choice. Done when the approver has signed off the note and every setting has a stated owner.
Set password rules in the administration area
An administrator opens the administration settings and applies the password policy the group agreed, covering minimum length, required character types and any other password rules the interface offers. Confirm the exact options in your installed version, since the EspoCRM security documentation recommends enforcing a password policy but the option names and defaults should be checked in your own instance. Save the change and record the before and after values. Verification: attempt to set a password for a test user that breaks each rule. The change is accepted only when every weak example is rejected.
Configure recovery behavior and admin exceptions
Set up password recovery so ordinary users can reset passwords through the emailed link, and decide whether administrator accounts are excluded from recovery. The EspoCRM security documentation recommends disabling password recovery for admins, so the default position is to exclude them and handle admin resets through a documented break-glass process. Confirm the recovery settings and any link lifetime options available in your version. Verification: confirm the admin account shows no recovery path on the login screen, and that recovery for a regular test user still works.
Set auth token idle time and lifetime
Configure how long an authenticated session may sit idle before it expires, and the maximum lifetime of an auth token regardless of activity. The EspoCRM security documentation advises limiting auth token lifetime, so choose values that match the approved policy and confirm the exact configuration keys and units in your version's administration settings or configuration file. Keep a copy of the previous values so you can roll back. Verification: note the saved values in the change record and confirm they match the policy note from the first step.
Test each path with a non-admin account
Use a standard test user, not an administrator, to run each control end to end. Attempt a weak password and confirm it is refused. Trigger a recovery email, open the link, and confirm it works within the configured behavior, then confirm a second use of the same link fails if your version enforces that. Log in, leave the browser idle past the configured idle time, and confirm the session logs out on the next action. Verification: keep a dated results table with one row per test, the expected result and the observed result.
Document the result and schedule review
Record the final settings, the approved policy note, the test results and the names of the people who approved and tested the change in your configuration management or compliance evidence store. Include the version of EspoCRM tested, because option names and behavior can change between releases such as the 10.0 line. Set a review point owned by a named person and tie it to any upgrade, since upgrade work can change defaults. Verification: an independent reviewer can open the record and reproduce the tests from the documented steps without asking the author for missing detail.

Security and operational risks to manage after the policy is set

A policy in EspoCRM is only as strong as the behavior it produces and the changes made to it later. The cards below cover the risks that appear once users, admins and integrations live with the settings, and each one ties back to a control you can check.

Weak passwords after rule changes

When a stricter password policy takes effect, some users respond by choosing passwords that meet the rule on the surface but are easy to guess, reused across systems, or written down near the screen. Tighter rules alone do not fix this. Pair the policy with a review of accounts that were set before the change, and confirm that users who must change their password are prompted at next sign-in. Check whether your identity provider already manages passwords for users who sign in through OIDC or LDAP, since EspoCRM's own policy may not be the one that applies to them.

Recovery as an account takeover path

Password recovery links are a common route into a CRM because the recovery email is often less protected than the account behind it. Set short recovery link lifetimes, and decide whether administrator accounts should be excluded from self-service recovery altogether. Confirm that recovery mail goes only to mailboxes your team controls, and test what a user sees when a link expires. Recovery settings should be reviewed alongside the mail configuration, not treated as a standalone toggle.

Long-lived tokens on shared devices

Authentication tokens keep a session open after a browser tab is closed, which matters on laptops that are shared, left unlocked or used at a front desk. Limit the idle time and the total lifetime so that an unattended session ends without action from the user. Ask your team which devices sign in to the CRM, and whether any kiosks or reception screens need a shorter policy than the sales floor. Test the logout path on a browser the user has closed and reopened.

Admin accounts used for daily work

When administrators read email, edit records and run reports from the same account they use to change system settings, a phishing message or a stolen session exposes the whole instance. The EspoCRM security docs advise avoiding admin accounts for daily work. Create a separate standard user for everyday tasks, and keep the admin account for configuration only. Confirm that recovery and 2FA rules are applied to the admin account more strictly than to regular users.

Policy drift after upgrades and extensions

Settings that were correct at go-live can change silently when a major version is upgraded, an extension is installed, or a configuration file is edited by someone other than the original owner. As of version 10.0, upgrades through the UI are disabled by default, so the upgrade path is a deliberate decision you should record. Keep the authentication settings in a change log, review them after each upgrade or extension change, and re-run your login tests against a staging copy before production.

How the policy differs for self-hosted, cloud and OIDC sign-in

On a self-hosted EspoCRM instance, your team controls the full login policy. The administration settings for passwords, recovery, two-factor authentication and authentication token lifetimes live inside the application, and the server configuration sits with whoever runs the infrastructure. That makes self-hosting the most flexible option, and it also means the policy is only as strong as the person maintaining it.

Password strength: Set the minimum requirements in the administration area and test them with a sample account before you rely on them.
Recovery links: Confirm how long recovery links stay valid and whether administrator accounts can use recovery at all.
Token lifetime: Review idle time and maximum lifetime for authentication tokens, since these values are yours to change.
Server-side controls: Reverse proxy and web server settings, such as TLS and access restrictions, sit outside the application and need their own review.
Upgrades: Policy changes can be affected by version changes, so recheck the settings after each upgrade.

Before go-live, confirm each setting against the current version's documentation in your own test environment.

Questions teams ask before setting EspoCRM login policy

What does it cost to set up an EspoCRM login policy?

The cost depends on how much of the policy is configuration and how much is integration and testing. Configuring password strength, recovery link lifetimes and auth token limits in the admin panel is small work for one administrator. The larger cost comes from identity integration, such as connecting EspoCRM to OpenID Connect or LDAP, because that work involves the identity provider team, group-to-team mapping and sign-in tests. Recurring cost is mostly review: policies need checking after each upgrade and whenever the identity provider changes. Ask any partner for a quote that separates configuration, identity integration, testing and handover, and states which items are one-time and which recur. DeployOpen issues quotes from a written scope, not from a standard price list.

Can an internal admin set up EspoCRM login policy alone?

Yes, for a standalone EspoCRM instance using its own password and session settings, one administrator who understands the platform can usually make the changes. The work becomes harder when login relies on an external identity provider. In that case, the admin needs someone who manages the identity provider to confirm claims, group mapping, multi-factor behavior and logout handling. The EspoCRM security documentation recommends avoiding admin accounts for daily work, so the person making changes should also hold a separate, rarely used administrator account. Confirm whether your team has someone who can test sign-in with a non-admin user before you change anything in production.

What does a partner need from our team before starting?

A partner needs a current picture of how people sign in and what your policy must satisfy. Typical inputs include the list of user types (regular users, portal users, API users), whether SSO or LDAP is already in use, your existing password and session standard, and who approves changes. Access to a staging copy of your EspoCRM instance is important, along with a named contact who can test sign-in with real accounts. You should also provide the change window, the rollback owner and the list of integrations that depend on API users, since those accounts follow different rules from people. Ask the partner to confirm in writing which of these inputs they need before scoping.

How long does testing take for an EspoCRM login policy?

Testing time depends mainly on the number of user groups and whether sign-in goes through an identity provider. A small team using local accounts needs a short test pass covering each user type, each recovery path and each session timeout. Larger user bases add more role combinations and more sign-in paths to check. SSO adds further work: the team must test first-time user creation, group-to-team mapping, logout from the identity provider and the fallback login method. No duration figure is supplied for this work, so ask any partner for a test plan with the number of scenarios and who runs each one, then judge the timeline against that plan.

Can we disable password recovery for admins without locking out the team?

Yes, but only if another recovery path exists before you switch it off. The EspoCRM security documentation recommends disabling password recovery for admins, which reduces the risk that a reset link is used to take over a privileged account. The risk of lockout is real but manageable: before changing the setting, confirm that at least two people can reset an admin password through a controlled process, such as direct server-side access or a runbook using the command-line tools. Test that process on a staging instance first. Also confirm that your identity provider can handle admin recovery if you use SSO. Write the procedure down so the team does not depend on one person's memory during an incident.

How do policy changes affect sessions that are already open?

Changes to idle time and token lifetime usually apply to new sessions and to the next check made on existing ones, so users may be signed out sooner than they expect. A shorter lifetime or idle timeout can interrupt work in progress, which is why the change should be announced before it goes live. Password strength rules normally apply only when a password is set or changed, so existing passwords may not meet a new standard until users reset them. Confirm this behavior on your EspoCRM version before rollout, and check how API integrations respond, because service accounts can break if their credentials or tokens expire on a new schedule.

Which login policy settings should we review after an EspoCRM upgrade?

Review the password, recovery, token and two-factor settings after every upgrade, because defaults and interface locations can change between releases. Also check that the upgrade path still respects the restrictions you set, including whether upgrades run through the user interface or the command line. The EspoCRM upgrade notes say UI upgrades are disabled by default as of version 10.0, so confirm the process your team uses. Keep a written list of each policy value and its reason, so the next reviewer can compare settings against it quickly. Ask your partner whether post-upgrade login testing is part of the agreed scope.

Limits to confirm in your EspoCRM version and environment

The policy settings for passwords, recovery and sessions depend on your EspoCRM version, your user types and how traffic reaches the server. The cards below list the points to confirm in your own instance before you write the policy down, so the documented intent matches what users actually experience.

Exact setting names and options

Setting labels, available options and default values in the administration area can change between releases, so the names in any policy document must match your running version. Export or screenshot the password, recovery and authentication token screens on a test instance and record them against the version you deploy. Confirm whether each option is global or can be set per user type, because that determines what you can enforce for administrators and for regular users.

Recovery for portal and API users

Password recovery is not always identical for every user type. Portal users and API users may follow different login paths, and an API user normally authenticates with a key or HMAC signature rather than a password. Test a recovery request for each user type you run, and confirm that disabling recovery for administrators does not accidentally block a portal or service account that depends on it.

Session limits behind a reverse proxy

Idle and lifetime limits are evaluated on the server, but the client address used for logging, IP checks and session handling depends on what the proxy forwards. Confirm how your reverse proxy passes the original client address and how long idle sessions stay open when users sit behind a load balancer. Test a session timeout from a real browser through your production proxy path, not only from a direct connection to the application container.

Effect on users already logged in

A new authentication token lifetime may not apply to sessions that were created before the change. Confirm whether a saved policy ends existing sessions immediately, applies at the next token check, or waits until a user signs in again. Plan the change window with this in mind, and decide whether you need to force a sign-out for all users after a tightening change, especially after a suspected account compromise.

Mail delivery for recovery links

Recovery links only work if outbound mail is configured, reliable and not blocked by spam filters. Confirm the mail transport settings, the sender address and whether recovery messages are delivered through the same path as other notifications. Send a test recovery message to each mailbox domain your users have, and check that link lifetimes are long enough to be useful but short enough to limit exposure.

Policy carry-over between major versions

Major releases can rename settings, change defaults or move options between the administration area and configuration files. EspoCRM 10.0.0 was released on July 2, 2026, and 9.0.0 on January 20, 2025, so an instance upgraded across that boundary needs its policy re-checked afterward. Export the current configuration before any upgrade, compare it with the new version's defaults, and rerun your login tests on a staging copy before you go live.

What changes for users and admins when the policy goes live

Once the password, recovery and session settings are live, most users notice three things: a stricter password rule when they set or change their password, a shorter path back to the login screen after a period of inactivity, and a recovery email that behaves differently if the recovery link lifetime was shortened. Tell users in advance which of these they will see, because a forced re-login after idle time looks like a fault to someone who has never been logged out before. Confirm with your own test instance exactly when the idle timeout takes effect for an open browser tab, and what a user sees when a recovery link has expired. Those observations, not the setting names, are what the help desk will be asked about in the first week.

The admin path is where the policy can lock you out. With admin recovery disabled, an administrator who forgets a password cannot use the standard recovery email to regain access, so someone else must restore it. Before you turn that setting on, write a break-glass procedure that names two or three people who hold a privileged path to the server, states how they verify identity, and records how a new admin password is set and reviewed afterwards. Test the procedure on a non-production instance, including the case where the only other admin account is unavailable. Confirm with your own deployment, using the EspoCRM security documentation as the reference, which recovery and reset steps need database or command-line access.

A communication plan closes the gap between the policy and daily use. Tell users what changes, when, and where to get help, and give administrators a separate note covering the break-glass steps and who to call. Keep administrator accounts for configuration work only, and use a standard user account for daily sales and service tasks. This reduces exposure from these settings, because a lapsed session or a recovery link intercepted on an administrator account gives an attacker far more than the same event on a sales rep account. Review the policy again after each EspoCRM upgrade, since the security documentation and the admin tools can change between releases.

How DeployOpen works on this

DeployOpen scopes EspoCRM login policy as a written part of the implementation, covering password rules, recovery paths, and session lifetimes for each user type. The work runs inside your own infrastructure, so the settings, the evidence and the handover notes stay with your team.

How we scope

Inventory the user types in use, including administrators, staff, portal users and API users, and note which need password login at all.
Agree in writing which password, recovery and session settings are in scope, with a fixed-scope deliverable list before work starts.
Confirm whether single sign-on or the identity provider's MFA will take over sign-in, since that changes which EspoCRM settings still apply.

How we build

Configure password strength, recovery link lifetimes and admin recovery settings in the EspoCRM administration area, recording each value and its reason.
Set auth token idle time and lifetime to match your session risk, then test expiry behavior with real browser and API sessions.
Review the EspoCRM security guidance against your settings and document every deviation with a named owner and a review date.

How we hand over

Provide a written policy record listing each setting, its value, the user types it covers and the test evidence that confirms it.
Walk your administrators through recovery procedures, including how to handle a locked admin account without re-enabling risky recovery paths.
Document how to change each setting later, and which upgrades or extension changes could reset or bypass it.

How we support

Ongoing support, periodic re-checks after EspoCRM upgrades and continuous testing are available as retainers, agreed in writing.
Re-verify login policy after major version changes, since upgrade behavior and defaults can change between releases.
Ask for the support scope, response expectations and retest approach in your quote so the retainer matches your environment.

EspoCRM password, recovery and session policy