The ERPNext application is secure by design, with role-based access control, two-factor authentication, encrypted credentials, protection against common web attacks, and full audit logs. A self-hosted deployment, however, is only as secure as the server, network, and operating practices around it. Most ERPNext security incidents stem from weak server administration, such as open ports, unpatched systems, shared admin passwords, and untested backups, rather than from flaws in the software.
Key facts
- Security responsibility in self-hosting: 100 percent yours, including OS, network, database, backups, and monitoring.
- Application safeguards built in: RBAC, 2FA, password policy, session controls, IP restriction, CSRF and XSS protection, parameterised queries, API key authentication, rate limiting.
- Frappe publishes security fixes openly, and runs a responsible disclosure process.
- Regulatory context in India: the DPDP Act 2023 requires reasonable security safeguards for personal data, and CERT-In directions require incident reporting within six hours.
What security features are built into ERPNext?
The 25-point hardening checklist
Network and server 1. Cloud firewall and UFW allow only ports 80, 443, and restricted SSH 2. SSH: key-based only, root login disabled, fail2ban active 3. Non-root user runs bench; sudo access limited 4. Automatic security updates enabled for the OS 5. Server in a private subnet or behind a VPN for internal-only deployments 6. MariaDB and Redis bound to localhost, strong database root password 7. Separate production and staging servers
Application 8. HTTPS enforced with auto-renewing certificate and HSTS 9. Two-factor authentication mandatory for all users 10. Strong password policy and minimum score enforced 11. Session expiry set, for example 8 hours, shorter for administrators 12. Login restricted by IP for finance and administrator roles where feasible 13. Default Administrator password changed and stored in a vault 14. System Manager role limited to two named individuals 15. Server Scripts disabled unless required and reviewed 16. API keys issued per integration, rotated annually, least-privilege roles 17. File upload size and type restrictions reviewed; private files used for sensitive attachments 18. Guest access and web forms reviewed; signup disabled if not needed
Data and backup 19. Backups every six hours, encrypted, pushed offsite to a different region 20. Backup encryption key stored separately from the backups 21. Quarterly restore test with documented evidence 22. Disk encryption on the volume where feasible
Operations and governance 23. Monitoring and alerting for uptime, CPU, disk, failed logins, and queue backlog 24. Patch and upgrade calendar with staging validation 25. Quarterly user access review, leaver deactivation within 24 hours, and an incident response plan that meets the CERT-In six-hour reporting requirement
How does self-hosted security compare with Frappe Cloud?
Note that application-level security, including who has which role, is always the customer’s responsibility regardless of hosting.
What does the DPDP Act mean for ERPNext users?
ERPNext typically holds personal data of employees, customer contacts, and supplier contacts, including PAN, Aadhaar-linked identifiers in payroll, bank details, and addresses. Under India’s Digital Personal Data Protection Act 2023, a business as a Data Fiduciary must implement reasonable security safeguards, limit retention, and notify breaches.
Practical steps in ERPNext:
- Classify doctypes containing personal data: Employee, Salary Slip, Customer, Contact, Address, Job Applicant
- Apply field-level permissions to sensitive fields
- Restrict export and print permissions on those doctypes
- Use private file attachments for identity documents
- Define retention rules and use data deletion or anonymisation features for personal data requests
- Maintain access logs and review them
- Sign data processing terms with your hosting and implementation partners
Is open source less secure than proprietary ERP?
No. Open code is inspectable by customers, researchers, and contributors, and fixes are released publicly. Proprietary ERP also has vulnerabilities; they are simply less visible. What matters is patch speed and operational discipline. The caution with open source is that attackers can also read the patch notes, so delayed patching of a public-facing server carries real risk.
Frequently asked questions
Does ERPNext support two-factor authentication? Yes. 2FA can be enforced for all users or selected roles using an authenticator app, email, or SMS.
Is ERPNext data encrypted? Data in transit is encrypted with TLS. Passwords are hashed and stored credentials are encrypted. Database-level encryption at rest depends on your server or cloud volume configuration.
Has ERPNext had security vulnerabilities? Like all software, yes, and they are fixed and disclosed through releases. Staying on a supported version with current patches is essential.
Should ERPNext be exposed to the internet? If users need remote access, yes, behind HTTPS with 2FA. For single-site operations, restricting access through a VPN or IP allowlist reduces exposure considerably.
Can I run a penetration test on my ERPNext? Yes, on your own self-hosted instance. It is good practice annually or after major changes.
Who is responsible if self-hosted ERPNext is breached? You are. There is no vendor liability in self-hosting. This is the central governance point in the hosting decision.
The bottom line
Self-hosted ERPNext can be very secure, arguably more so than many SaaS tools, because you control every layer. That control is also the liability. If you cannot evidence the 25 points above, use managed hosting.
Finstein is a cybersecurity and risk advisory firm as well as an ERPNext implementer. Our ERPNext security review covers server hardening, role and access design, backup validation, and DPDP readiness. Book a demo.
