Security and governance guide
ERPNext Security and Access Control Guide
Protect business data with layered identity, permission, change, integration, infrastructure and recovery controls.
- Roles
- Permissions
- Audit evidence
- Recovery
Reviewed against current official documentation Practical UAE implementation perspective Fact-checked 17 September 2026
Quick answer
ERPNext and the Frappe Framework provide role-based permissions, user permissions, field-level controls, two-factor authentication options and access records. Security remains a shared responsibility: hosting, updates, backups, integrations, custom code, account lifecycle, monitoring and user behaviour must be governed as one system.
Security is a system of responsibilities
No ERP is secure because of one checkbox. The application controls what an authenticated user may do; the hosting platform protects infrastructure; implementation choices shape custom code and integrations; managers approve access; users protect credentials; and support teams respond when something fails.
Begin with a responsibility matrix covering identity, permissions, server and database, network, encryption, backups, updates, monitoring, vulnerability handling, integrations, incident response and exit handover. Managed hosting can reduce infrastructure workload, but it does not decide which employee should approve a payment or export customer data.
Security should be testable. “Only authorised users have access” is a hope until the organisation can produce the user list, role rationale, approval, last review and evidence of removal.
Strengthen identity and account lifecycle
Use named accounts for human users and dedicated accounts or tokens for integrations. Shared credentials weaken accountability and make offboarding risky. Frappe documents two-factor authentication options; confirm the method, recovery process and coverage for administrators and remote users.
Join
Create access from an approved role request, not by copying a powerful colleague without review.
Change
Reassess access after transfer, promotion, temporary assignment or process redesign.
Leave
Disable access promptly, rotate relevant credentials and transfer workflow ownership before departure.
Design least-privilege roles around real work
Role Based Permissions control actions such as read, write, create, submit, cancel, amend, report, import, export and print. User Permissions can restrict access to selected linked records, while permission levels can protect sensitive fields. The goal is enough access to perform the job and no unexplained privilege.
| Risk | Control question | Test |
|---|---|---|
| Unauthorised posting | Who can submit, cancel or amend financial and stock documents? | Attempt the action with representative roles |
| Data exposure | Who can view, report, export or print sensitive records? | Test list, report, API, export and attachment access |
| Self-approval | Can one user prepare and approve a material transaction? | Walk the workflow with conflicting roles |
| Administrative override | Who has System Manager or Administrator capability? | Review necessity, usage and emergency access |
Do not rely only on the form view. Reports, APIs, imports, background jobs and custom applications may expose or change data differently, so acceptance testing must cover each route in use.
Preserve audit evidence and investigate changes
Frappe maintains document metadata and can preserve version history for configured changes. ERPNext documentation also describes Access Log records for certain exports, prints and file downloads. These features support investigation, but retention, coverage and administrator access should be verified for the installed version.
- Enable and review version tracking where material changes need an audit trail.
- Require comments or references for sensitive overrides and manual journals.
- Monitor unusual exports, repeated failed access and unexpected administrator activity.
- Protect logs and backups from the same compromise that affects production.
- Define who reviews alerts, how quickly and what evidence closes an incident.
Treat integrations and custom code as part of the security boundary
API users should receive only the permissions and methods required. Store secrets outside public code, rotate them, limit environments and avoid personal administrator credentials in connectors. Webhook signatures, transport security, retry behaviour and logs need a design appropriate to the receiving system.
Custom scripts and applications should follow review, testing, dependency and release controls. An apparently small custom endpoint can bypass carefully designed forms. Keep an inventory of integrations, owners, credentials, data exchanged, lawful purpose and shutdown procedure.
Secure hosting, updates, backups and recovery
Confirm operating-system, database, application and dependency patch ownership. Use supported versions and test upgrades against custom apps. Restrict administrative interfaces and server access. Monitor availability, background jobs, storage, certificates and suspicious events.
Backups are useful only if complete, protected and restorable. Define database, public files, private files, encryption keys and configuration coverage. Set recovery-point and recovery-time objectives based on business impact, then run restoration exercises. A successful backup job is not evidence of a successful recovery.
Access reviewApproved users and privileges
Patch statusSupported and updated components
Restore testRecovery proven with evidence
Incident timeDetection through containment
A practical quarterly security review
Reconcile identities
Compare active users and service accounts with HR, vendors, roles and current business ownership.
Review privilege
Challenge administrative, export, import, submit, cancel and sensitive-data access.
Inspect technical health
Review versions, patches, custom apps, integrations, certificate status, failed jobs and monitoring alerts.
Test response and recovery
Run a contained incident scenario and a documented restore test with accountable owners.
Close findings
Assign risk, owner and target date; verify remediation instead of carrying the same exception indefinitely.
Connect technical security with data protection
Classify the information held in ERPNext: customer and supplier details, employee records, payroll, bank data, contracts, attachments and commercial history. Map where it enters, where it is exported, which integrations receive it and when it should be deleted or anonymised. Permissions are easier to design when the organisation understands the sensitivity and purpose of each data set.
Use controlled test data and restrict production copies. Review downloadable backups, spreadsheet exports, printouts and email attachments because information can leave the application through ordinary business activity. Define how requests for access, correction, retention or deletion are handled without damaging required accounting or legal records. UAE data-protection obligations and sector rules should be reviewed with qualified legal and privacy advisers.
Frequently asked questions
Does ERPNext support role-based access control?
Yes. ERPNext and Frappe provide role-based permissions, User Permissions, permission levels and controls for document actions. The organisation must design, test and periodically review the access model.
Does ERPNext support two-factor authentication?
Frappe documentation describes two-factor authentication configuration. Confirm the available methods, enforcement, recovery and administrator coverage for the deployed version and hosting setup.
Does ERPNext have an audit trail?
Frappe can preserve document version history for configured changes, and ERPNext documents Access Log records for certain data access actions. Coverage and retention should be verified and supplemented with operating controls where required.
Is cloud-hosted ERPNext automatically secure?
Managed hosting can cover important infrastructure responsibilities, but customers still own user access, business permissions, data handling, integrations, customizations, devices and many incident decisions. Review the service scope and shared-responsibility model.
How should ERPNext API access be secured?
Use dedicated integration identities, minimum required permissions, protected and rotated secrets, secure transport, input validation, logging, monitoring and a documented disable procedure. Avoid personal administrator credentials.
How often should ERPNext access be reviewed?
Review access on joiner, mover and leaver events and on a scheduled risk-based cycle. Privileged, finance, payroll, export and integration access usually deserves more frequent attention.
Turn ERPNext security into evidence, not assumptions
We can help you review roles, integrations, customizations, hosting responsibilities and recovery controls as one practical security model.
Discuss your requirementsExplore ERPNext implementation
Useful references
- ERPNext Role Based Permissions
- ERPNext User Permissions
- ERPNext Two Factor Authentication
- ERPNext Access Log
- Frappe REST API documentation
Product behaviour can vary by ERPNext and Frappe version, installed applications, configuration and custom code. UAE tax, privacy, employment and sector requirements should be confirmed with qualified advisers and the relevant authorities. This article provides implementation guidance, not legal, tax or accounting advice.
