How ERPNext login policies protect a shared finance and stock system
Login policies in ERPNext are set in System Settings, and they decide how long a session lasts, how failed sign-ins are handled, whether passwords are required or single sign-on takes over, and how strong new passwords must be. For a finance or operations leader, these settings are the first control on a shared site that holds ledgers, stock balances and supplier payments, so they should be agreed and switched on before the first user is invited. A site where every user can reach the login page with a weak password and an open-ended session is a site where role permissions are only as strong as the least careful account.
These settings sit alongside role permissions, user permissions and two-factor authentication, and they do not replace any of them. A login policy controls who gets in and for how long. Role permissions still decide what a signed-in user can read, create, submit or cancel, and two-factor authentication adds a second factor at sign-in. Before go-live, the owner should write down the intended values for session expiry, login attempt limits and password rules, then confirm each one in System Settings on a test site. The exact options and their current defaults should be checked against the version in use, since the settings screen differs between releases.
If the organization plans to use single sign-on, decide early whether password login will remain available for break-glass or service accounts. Disabling password login is a deliberate step that changes who can recover access, so the recovery path must be tested first. ERPNext offers LDAP login through LDAP Settings and Social Login Keys for providers such as Google or Microsoft, and each has its own mapping and provisioning behavior that the team must confirm for its own directory. Ask the implementation partner to document which accounts can still sign in with a password and who holds them.
Login policy settings and when each one fits
This table compares each login security control in ERPNext System Settings by what it does, who it affects, its main trade-off and when a team should choose it. Confirm default values and exact field names in the version you run, because the defaults are not fixed by this page. Read it as a checklist: pick the controls that match your exposure, then test each one with a non-admin account before rollout.
| Control | What it does and who it affects | Main trade-off | Choose it when |
|---|---|---|---|
| Session expiry | Ends a logged-in session after a set period of inactivity. Affects every user, including staff on shared or kiosk workstations. | Shorter sessions reduce exposure of an unattended screen but interrupt long data entry and report runs. | Users work from shared devices, public spaces or unmanaged laptops, or your policy requires idle timeouts. |
| Single session | Allows only one active session per user at a time, so a new login ends the older one. Affects users who sign in from several devices. | Stops credential sharing and session reuse, but users who switch between desktop and mobile lose their other session. | Accounts carry financial approval rights or you need to detect shared logins. |
| Login attempt limits and delays | Locks or slows further attempts after repeated failed logins. Affects anyone who mistypes a password, and can be triggered by attackers against a known username. | Blocks password guessing, but a strict lockout can let an attacker lock out real users and creates help desk load. | Your site is reachable from the internet or you have no upstream rate limiting on the login page. |
| Password strength | Sets minimum requirements for new or changed passwords. Affects all password-based accounts, not accounts that sign in only through SSO. | Stronger rules raise resistance to guessing but push users toward predictable patterns if the rules are unusually rigid. | Password login remains enabled for employees, contractors or service accounts after your identity review. |
| Forced password reset | Requires selected users to set a new password at their next login. Affects the users you target, or all users when you apply it broadly. | Useful after a suspected compromise or staff change, but a site-wide reset causes a support spike and can prompt weaker replacements. | A credential may have leaked, a privileged user has left, or a policy change requires a fresh password. |
| Disable password login with SSO | Turns off username and password sign-in so users authenticate through the configured identity provider. Affects every user who relies on password login, including any local accounts. | Centralizes sign-in, multi-factor checks and offboarding, but a provider outage or misconfiguration can block access. | Your identity provider already enforces MFA and you have tested a break-glass path for administrators. |
| Break-glass administrator account | Keeps one tested local account available when SSO or the identity provider fails. Affects only the named administrators. | Gives a recovery path, but it is a high-value target that needs its own strong password, monitoring and restricted use. | You disable password login or use LDAP or social login as the main method. |
Configuring login policies in System Settings step by step
This sequence moves from confirming the ERPNext version and identity source through session rules, attempt limits, password rules and forced resets, and ends with disabling password login only after SSO and a break-glass path have been tested. Each step closes with a check so the policy is proven before the next change.
Confirm the ERPNext version and identity source
Before changing anything, record which ERPNext and Frappe version the site runs and whether it is on a version that still receives support. Check the supported versions page for the current status, since version 14 reached end of life on January 31, 2026. Then document where logins come from today: local ERPNext passwords, LDAP through LDAP Settings, or a Social Login Key for an external provider. The check is a short written record listing the version, the identity sources and the named owner of each one, reviewed by the security lead.
Set session expiry and single-session rules
In System Settings, review the session expiry value and decide how long an idle or active session should last for your users, separately for desktop and mobile where the settings allow it. Then decide whether a user may hold more than one active session. Apply the change on a staging site first. The check is to log in as a test user on one browser, log in on a second browser, and confirm that the behavior matches the rule you chose, then confirm the expiry triggers after the idle period you set.
Set login attempt limits and delays
Configure the failed login threshold and any lockout or delay behavior that the System Settings form exposes in your version. Confirm the exact field names and their effect in the documentation for your release, because options can differ between major versions. Make sure the limit is high enough that a user who mistypes a password is not locked out routinely, and low enough to slow password guessing. The check is to deliberately fail the login with a test account until the lock applies, confirm the account is locked as expected, then restore it through an administrator and confirm access returns.
Set password strength and reset rules
Set the minimum password requirements and any expiry or reuse rules that your version supports, mapping each one to your written policy. Confirm which rules apply to Administrator and System Manager accounts, since those accounts are the most valuable targets. Test that the rules reject a weak password on a test account. The check is a password change attempt on a test user that fails for each rule and succeeds only with a compliant value.
Plan forced resets for existing accounts
Identify which existing accounts need a forced reset after the new rules take effect, such as accounts with weak or shared passwords, dormant accounts and service-style logins that should be moved to API keys or OAuth instead. Agree the communication with users and the helpdesk process for resets, and decide whether resets are applied in one batch or by group. The check is a list of affected accounts reviewed by the business owner, plus a test reset on a single account that confirms the user is prompted on next login and can complete the change.
Verify a break-glass administrator path
Before any change that removes password login, create or confirm a separate break-glass account with a strong, offline-stored password and a role set reviewed by the security lead. Confirm it can sign in through the normal password path and that the recovery steps for a lost administrator password are written down and rehearsed on staging. The check is a successful login with the break-glass account on the staging site and a documented recovery procedure that a second person can follow.
Disable password login only after SSO is proven
Once SSO through LDAP or a Social Login Key is working for every user group, and the break-glass path is confirmed, disable password login for ordinary users in the login settings your version provides. Do this in a change window agreed with the business, with the break-glass account and one administrator kept ready. The check is a login test for a representative user in each group through the identity provider, a confirmation that a password login for an ordinary user is refused, and a confirmation that the break-glass account still signs in.
When SSO, LDAP or social login changes the password policy
When ERPNext signs users in through LDAP or a Social Login Key provider, the password rules move to the identity provider. Length, complexity, expiry and lockout for those users are enforced by Active Directory, OpenLDAP or the external provider, so the password settings in System Settings no longer govern them. ERPNext still holds local accounts, most importantly Administrator, and those accounts continue to follow the local policy. Plan the policy as two separate controls, one for federated users and one for local accounts, and record which accounts fall into each group.
LDAP also changes who holds which role. According to the ERPNext LDAP integration documentation, group membership is mapped to ERPNext roles automatically at each login, so a role removed in the directory is removed in ERPNext the next time that user signs in. Review the group-to-role mapping before go-live, confirm which groups grant System Manager or other high-privilege roles, and test a user who has lost a group. Enable the SSL/TLS options in LDAP Settings so credentials are not sent in clear text between ERPNext and the directory, and confirm the certificate chain with your directory team before the first login test.
The most serious risk is a self-inflicted lockout. If password login is disabled for all users, or the identity provider is unavailable, nobody can sign in unless a local path still works. Before you turn off password login, keep at least one tested local administrator with a strong, separately stored password and confirm that it works from a clean browser session. Document the recovery steps and the owner who can use them, and check them again after each identity provider change. The related page on recovering ERPNext admin access covers the steps if this safeguard was missed.
Security and operational risks to manage
Login policy in ERPNext affects security and day-to-day operations at the same time. The cards below cover the risks that tend to surface after go-live, where a stricter setting can stop finance work, break an integration or leave gaps in who can sign in and how.
Shared Administrator password
The Administrator account sits outside normal role assignments and can change almost anything on the site. If several people share its password, you lose attribution for every change and every login. Decide who holds the credential, store it in a vault with access logging, and keep named System Manager accounts for daily work. Check whether anyone still signs in as Administrator for routine tasks, and confirm how the password is reset if a holder leaves.
Long sessions on shared workstations
Session expiry controls how long a logged-in browser stays valid without activity. On shared finance or warehouse terminals, a long expiry lets the next person work under the previous user's identity. Set expiry based on how the desk is used, and test it on the devices your staff actually share. Pair it with a single-session rule where roles permit, so a second login does not quietly coexist with the first.
Attempt limits during month-end
Login attempt limits and delays protect against password guessing, but they also lock out legitimate users who mistype a password under pressure. A close team that is locked out during period end can stall posting and reporting. Agree a lockout threshold and unlock procedure with finance before go-live, decide who can clear a lock, and confirm which accounts are exempt. Test the setting during a realistic close cycle, not only in a quiet week.
Forced resets that break API integrations
A forced password reset applies to the user who holds the integration credential. If a scheduled import or sync authenticates with that user's password or session, the job fails at the next run and may fail silently. Map every integration to the account it uses, move API access to dedicated users with API keys where your design allows, and confirm that a password policy change does not invalidate those keys. Document the owner of each integration account.
Desk login and API login gap
A password policy set in System Settings governs interactive Desk sign-in, but API clients can authenticate through other methods, such as API keys, OAuth tokens or a separate login path. Stronger desk settings do not automatically cover those routes. Inventory every method that can reach the site, including LDAP, social login and custom endpoints, and check whether each one inherits the rules you configured. Confirm the behavior in your own version before relying on it.
Reviewing failed login logs
Failed logins are only useful if someone reads them. Decide which events are retained, for how long, and where they are forwarded for review. Watch for repeated failures against one account, failures from unusual addresses, and lockouts on accounts that hold high-value roles. Assign an owner for the review, define the response for each pattern, and confirm that log retention meets your own audit and records requirements.
Questions teams ask before configuring ERPNext login policies
How much effort does changing ERPNext login policies take?
Changing the settings in System Settings is usually a small task on its own, but the effort around it is what varies. The main drivers are how many user groups and roles need different rules, whether users sign in with local passwords, LDAP, or a social login provider, and how much testing your security team wants before a change reaches production. A site with one user population and password login has a short change. A group with several companies, contractors and SSO-based sign-in needs a written matrix of who gets which policy, a staging run, and a rollback plan. Ask any partner to show how the scope is split between design, change, testing and handover before you agree a fixed price.
Can an internal administrator configure these login settings alone?
Yes, a competent administrator with System Manager access can change the settings in System Settings without outside help. The harder part is knowing what each value does to your users, especially session expiry, single-session enforcement and login attempt limits, which can interrupt work or lock out service accounts. Your team needs a named owner for the policy, a change record, and a second person who can review the values before they go live. If no one on your team has tested authentication flows on this site before, a short external review of the design is often cheaper than learning the effects in production.
What does a partner add to an ERPNext login policy project?
A partner adds a written policy design, a test plan, and the implementation work that touches identity systems. In practice that means mapping roles to the right session and password rules, configuring LDAP or Social Login Key where the organization uses them, disabling password login only after SSO has been proven, and documenting each setting with its reason. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure, and it prepares the configuration evidence that your assessors will ask for. Scope, deliverables and timelines are agreed in writing before work starts, so you know what is included before any change is made.
How do we test login policies without locking out users?
Test on a non-production site that mirrors your production authentication setup, including the same LDAP or SSO provider where possible. Change one setting at a time, sign in with a test account for each role, and record what happens when a session expires, when a second login is attempted, and when the attempt limit is reached. Keep an administrator session open during production changes and confirm that a break-glass account can sign in before you change anything. Schedule production changes outside peak working hours and agree who can reverse them. Ask your partner to show the test cases and the rollback steps in writing.
Do these settings meet a specific control framework?
Login policy settings can support controls in several frameworks, but they do not meet a framework by themselves, and no vendor or partner can declare that they do. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration exports, role matrices and test records. Independent auditors and certification bodies decide whether the control is met. Before you start, ask your assessor which control IDs apply to authentication and session management, and confirm with them which evidence they expect to see for each setting and for any compensating control you use.
What should we do if an administrator is locked out of ERPNext?
Use a recovery path that you have prepared before the lockout happens. The usual first step is to check whether another user with System Manager access can reset the account, and if none exists, use bench commands run by someone with access to the server, following the recovery steps in the ERPNext documentation for your version. Keep at least one break-glass administrator account with a strong, separately stored password and a documented procedure for using it. Record every recovery action, because your security team will want to know how access was restored. If you need help during an incident, ask your partner for a scoped recovery engagement with a clear record of what was changed.
What drives the cost of an external login policy engagement?
The biggest cost drivers are the identity integration, the number of user groups, and the number of environments. Connecting LDAP, Active Directory or a social login provider takes more design and testing than password policies alone, and each separate user population adds rules to define and verify. Staging environments, change windows and evidence requirements also add time. Ongoing costs, such as reviewing policies after an upgrade or after a directory change, are recurring if you choose a support arrangement. When you ask for a quote, request a list of the identity sources, user groups, environments and deliverables it covers, so you can compare it with your own estimate.
Limits to confirm in your ERPNext version and environment
The login settings described on this page depend on the ERPNext and Frappe release you run and where it is hosted. The cards below list the points to verify with your own version, hosting provider and identity setup before you write a policy or a rollout plan around them.
Setting availability by release
Confirm that each session, lockout and password option you plan to use exists in the exact ERPNext and Frappe version you run, and check the System Settings screen on a staging site rather than relying on documentation for another release. Version 14 has reached end of life, so a policy written for it will not carry forward unchanged. Record the version in the policy document so the next upgrade triggers a review.
Frappe Cloud shared bench behavior
Confirm which login and security settings you can change on a shared bench, since hosting tier can limit configuration and access to server-side logic. Check whether any policy depends on Server Scripts, which are disabled by default from version 15 and are not allowed on public shared benches. If a control needs custom logic, plan it on a dedicated or self-managed environment instead.
Warranty coverage and support plans
Frappe's warranty coverage depends on running a listed version and holding a matching Frappe Cloud support plan. Ask whether a password or session setting you rely on is covered for your version and plan before you treat it as a supported control. Self-hosted installs follow a different support path, so confirm with the vendor or your partner which fixes you can expect.
SSO-only login and integrations
Disabling password login can break integrations that authenticate with a username and password, scheduled jobs that use API keys, and service accounts. Inventory every consumer of ERPNext logins before you change the setting. Confirm that your Social Login Key or LDAP setup covers mobile clients, reporting tools and any OAuth 2 consumers, and keep a break-glass path for administrators.
Sessions behind a reverse proxy
Session expiry and client address checks depend on what the application sees through the proxy. Confirm that forwarded headers reach ERPNext correctly in your Nginx or load balancer configuration, otherwise session behavior and login attempt tracking may use the wrong client address. Test idle timeout, concurrent logins and logout from both the web client and the Socket.io real-time connection.
Directory-driven role changes
With LDAP, ERPNext maps directory groups to roles at each login, so a password or account change in the directory can alter what a user can access. Confirm how deactivated directory accounts are handled in ERPNext, whether existing sessions end when an account is disabled, and how long a removed role persists for active users. Test these cases on a staging site with a disabled test account.
How DeployOpen scopes login policy work
Login policy work in ERPNext starts with a written scope agreed before any setting changes, because the decisions behind session expiry, single session, login attempt limits, password strength, forced resets and disabling password login are tied to how each identity source is used. The scope first covers an identity source review: which users sign in with local ERPNext passwords, which go through LDAP or a Social Login Key, which are API or integration accounts, and where website users fall outside the policies you configure. Each of those paths needs its own answer before the System Settings values are fixed.
Next, the scope records policy decisions per role. Administrators, finance approvers, warehouse staff and external portal users rarely need the same session length or lockout threshold, so the written scope lists which roles get which settings, who approves each decision and what is deferred. It also defines the test accounts used to check each rule, including a locked-out account, an expired session and a user who should still reach ERPNext after SSO-only sign-in is enabled. Confirm with DeployOpen how many test accounts, environments and browsers are included before work starts.
Rollout and handover close the scope. The written scope names how users are told about changes, when the new policies go live, who keeps a break-glass path open during the switch, and what the handover notes must contain: the final setting values, the reasons for each one, the test results and the recovery steps. DeployOpen does not publish a price list. Work is fixed-scope, and the quote follows from that written scope, so a clear list of identity sources, roles, test accounts and rollout steps is what lets a quote be compared like for like.
How DeployOpen delivers ERPNext access control
DeployOpen plans, implements, hardens, documents and supports self-hosted ERPNext inside your own infrastructure, including the System Settings that govern passwords, sessions and login attempts. Login policy is set once, tested against each role, and then maintained as your user base and identity provider change.
How we scope
- Confirm which login paths are in use: local passwords, LDAP, social login or a separate identity provider
- Record the session expiry, single session, attempt limit and password rules your security policy requires
- Agree in writing which roles and website or API users are covered, and which are excluded
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts
How we build
- Configure System Settings values in a non-production site first, then record each change for review
- Test lockout, forced reset and session expiry behavior with accounts for each role
- Where SSO is used, disable password login only after confirming a break-glass path works
- Check login policy alongside LDAP or Social Login Key settings so the two do not conflict
How we hand over
- A configuration record listing each login setting, its value and the reason it was chosen
- A test script and results showing expected behavior for each role and login path
- A recovery runbook covering administrator access, locked accounts and identity provider outages
- Walkthrough with administrators on how to change settings and who approves changes
How we support
- Ongoing support, upgrades and periodic re-testing of login settings are available as a retainer
- Review login policy after each ERPNext minor release, since both supported major versions receive frequent updates
- Confirm version-specific behavior with the Frappe documentation before changing settings on a live site
- Evidence for compliance assessments is prepared, while auditors and certification bodies issue any opinion
