ERP Security for SMEs: Priorities That Actually Cut Risk

Why ERP Security Is Different

ERP security is the discipline of protecting the single platform where an SME keeps its financials, payroll and HR records, customer PII, supplier data, and intellectual property. Systems like Microsoft Dynamics 365, Odoo, SAP, and Oracle are designed to be that central system of record — which is exactly why specialists describe a poorly protected ERP as a single point of failure.

Unlike a departmental SaaS tool, an ERP sits in the middle of order-to-cash, procure-to-pay, inventory, and payroll. Compromising it can redirect payments, alter production orders, exfiltrate customer lists, or stop shipping — operational harm that ordinary perimeter tools do not fully cover.

The stakes are concrete. The global average cost of a data breach in 2025 was $4.44 million USD, down 9% year over year — the first decline in five years, per the IBM Cost of a Data Breach Report 2025. In the United States, the average reached a record $10.22 million USD. Phishing overtook stolen credentials as the most common initial attack vector, involved in 16% of breaches, while malicious insider attacks were the single most costly vector at $4.92 million USD per incident.

For an SME, the relevant point is not the headline number but the pattern: more than half of breached organizations (53%) reported compromised customer PII in 2025, and human error contributed to 26% of breaches. ERP security is therefore less about buying exotic tooling and more about configuring the platform you already own correctly — and reviewing who (including partners) can change roles, bank details, and exports.

State of ERP Security in 2025–2026

The state of ERP security shifted from theoretical risk to measured exploitation. Onapsis Research Labs reported a 210% increase in active exploitation of SAP vulnerabilities from 2024 to 2025, and CISA’s Known Exploited Vulnerabilities catalog added multiple SAP and Oracle CVEs in the same window. Attackers now treat finance, supply chain, and CRM applications as high-value targets — not secondary afterthoughts after endpoints.

Notable 2024–2025 patterns include mass exploitation of SAP NetWeaver (including the high-severity zero-day CVE-2025-31324), ransomware and data-theft campaigns against Oracle E-Business Suite, and large-scale identity abuse against connected SaaS (including Salesforce environments via vishing and stolen OAuth tokens). Consequences ranged from multi-week operational shutdowns to a beverages company that cited an SAP-related cyber incident among factors in a late-2024 bankruptcy filing.

AI is widening the gap between adoption and readiness. Onapsis’s State of AI, Security and ERP research (204 senior security leaders at US organizations running SAP, Oracle, or Salesforce) found 86% of organizations have integrated — or will shortly integrate — AI into ERP-related code or agents, while only 30% said they were fully confident they could detect an AI-based attack. For SMEs on D365 or Odoo, the practical lesson is the same: custom code, copilots, and integration agents expand the attack surface if access reviews and logging do not keep up.

SaaS posture data points the same way. The Cloud Security Alliance’s State of SaaS Security Report 2025 (420 IT and security professionals) found 86% of organizations now treat SaaS security as a high priority and 76% increased budgets, while 63% reported external data oversharing and 56% said employees upload sensitive data to unauthorized SaaS apps. Cloud ERP is still safer than a neglected self-hosted stack for most SMEs — but only if customer-side identity, roles, and integrations are governed.

Bottom line for 2026: the state of ERP security for mid-market firms is that threat actors already know how to abuse business apps, patches and zero-days move fast, and the controls that fail first are human and process ones — shared admin accounts, unreviewed SoD conflicts, long-lived API keys, and partner access that never expires.

The Core ERP Security Risks

Specialist analyses consistently identify the same recurring risk set across SAP, D365, and NetSuite environments — and Odoo deployments are not immune. The top recurring categories are: misconfiguration, excessive access and over-privilege, unpatched vulnerabilities, weak authentication, and insider threats.

Misconfiguration is the most common and the most preventable. Default roles shipped with too many privileges, auditing left disabled, or a record rule removed during a customization all create exposures that the vendor cannot fix for you. Excessive access compounds it: when every power user is a de-facto administrator, the blast radius of any compromised account is the entire ERP.

• →Misconfiguration — default-deny not enforced, auditing disabled, overly broad sample roles left in production.
• →Excessive access — users granted administrator or manager groups 'just to unblock' a task and never demoted.
• →Unpatched vulnerabilities — vendor security updates delayed or auto-update disabled on self-hosted tiers; internet-facing ERP without VPN or zero-trust gateway.
• →Weak authentication — shared logins, no MFA on admin or service accounts, long-lived API keys and OAuth tokens.
• →Insider threats — both malicious ($4.92M average cost per incident in 2025) and accidental (human error drove 26% of breaches).
• →Third-party and partner access — implementers, accountants, and ISVs with standing admin rights and no offboarding checklist.

ERP Security Priority Checklist for SMEs

When leaders ask what the ERP security priority order should be, start with identity and access, then logging, then recovery. You do not need a security operations center on day one. You do need named ownership, MFA on privileged paths, least-privilege roles, and backups you have restored at least once.

Use this checklist as a 90-day hardening sequence after go-live or as a quarterly self-audit. Rank work by blast radius: anything that can change bank details, export all customers, or elevate privileges comes first.

Access Control: The Foundation of ERP Security

Access control is where most breach risk is reduced — and where most SMEs underinvest. NIST SP 800-53 Rev. 5 formally defines Role-Based Access Control (RBAC) under control AC-3(7) and Least Privilege under AC-6, and these two principles anchor every modern ERP security model.

The practical pattern is the same on both platforms we implement: assign users to roles (not to raw permissions), scope those roles to the minimum data the user needs, enforce separation of duties for financial processes, and review the role assignments on a recurring cadence. Auditing must be enabled and actually reviewed — unreviewed audit logs are theatre, not security.

Small teams often cannot fully split every duty. Compensating controls still count: dual approval on vendor bank changes and large payments, exception reports the owner or controller reviews weekly, and immutable logs that show who did what even when the same person wears two hats.

Microsoft Dynamics 365 Security Model

D365 layers several Microsoft controls on top of the platform. Identity is handled by Microsoft Entra ID, with Conditional Access (if-then policies on user, location, device, and risk signals), MFA, and Privileged Identity Management (PIM) for just-in-time elevation of admin roles such as Dynamics 365 Administrator or Power Platform Administrator.

The Dataverse security model is role-based and additive — the least-restrictive permission wins. It is scoped per environment (the primary governance boundary), then by business unit, then by security role, with privileges (Create, Read, Write, Delete, Append, Assign, Share) and access levels (Organization > Parent:Child BU > BU > User > None). Field-level protection uses Column Security Profiles; row-level sharing should prefer access teams for performance.

D365 Finance & Operations uses a duty-based model: Roles contain Duties (business processes) contain Privileges (job-level) contain Permissions (to securable objects). The correct practice is to assign duties — not raw privileges — and to run the built-in Segregation of Duties rules engine to detect conflicting assignments (for example, a single user able to both receive goods and approve payment). This directly supports SOX internal control over financial reporting and reduces fraud risk.

For data protection, Power Platform Data Policies (often called DLP) classify connectors as Business, Non-business, or Blocked; the Dataverse connector cannot be blocked. Microsoft Purview adds sensitivity labels, endpoint DLP, and a Data Map for classifying Dataverse content. A common misconception worth correcting: there is no product named 'Microsoft Defender for ERP'. D365 F&O integrates with Defender for Cloud via Lifecycle Services Azure subscription connectors for infrastructure, and Microsoft Defender for Cloud Apps (CASB) provides SaaS-layer session control for Dynamics 365 once auditing is enabled.

Under Microsoft’s shared-responsibility model for cloud services, Microsoft secures the platform and infrastructure while you own identity design, role assignment, environment isolation, custom code and Power Automate flows, connector policies, and continuous access reviews. Treat Entra Global Admin and Dynamics service principals as crown-jewel accounts — compromise of identity often means compromise of every connected business app.

Odoo Security Model

Odoo builds security on top of groups (res.groups) — primary role bundles such as User and Manager per app, configurable under Settings > Users & Companies > Groups, with support for inherited groups where granting one automatically grants another.

Access Rights (ir.model.access) form the model-level CRUD matrix per group, defined in ir.model.access.csv. They are additive: any grant means the user gets it, and a matching access right with no group applies to every user (a risky fallback). Record Rules (ir.rule) provide finer-grained, row-level visibility via domains; global rules are hard restrictions that cannot be bypassed, while group-specific rules grant within the bounds of global rules.

Authentication defaults are reasonable but should be hardened. The auth_password_policy module sets a minimum password length (default 8); passwords are stored PBKDF2 with SHA-512 and a salt. Built-in TOTP-based 2FA can be enforced from Settings > Permissions for employees only or for all users including portals, and the per-user Devices tab allows session revocation. The auth_timeout module adds per-group inactivity timeouts.

Odoo Cloud hosting documents 14 full backups retained for at least three months (daily for 7 days, weekly for 4 weeks, monthly for 3 months), replicated across at least three data centers, with HTTPS (256-bit SSL) in transit and AES-256 encryption at rest for production data and backups. Odoo maintains SOC 1 (ISAE 3402) and SOC 2 Type I/II reports and, as of April 2026, completed ISO 27001 certification covering Odoo Online and Odoo.sh. Customer database isolation is by dedicated database per tenant on shared clusters.

Three Odoo-specific risks deserve attention. First, third-party and community modules run with full privileges once installed — vet the source before installing. Second, sudo() and raw SQL bypass access rights entirely, so developers must add explicit checks inside custom code. Third, menu and view groups are not security: a determined user can still reach data via RPC even if the menu is hidden.

ERP Application Security: APIs, Integrations, and Partner Access

ERP application security is the layer above firewalls and OS patches: it is how the ERP authenticates users and machines, authorizes every RPC or API call, validates custom code, and governs connectors. Network security can be perfect while a single over-scoped integration still exports the customer master nightly.

Cloud ERP follows a shared-responsibility model. The vendor secures infrastructure, tenancy isolation, and (on SaaS tiers) platform patching. You remain responsible for identities, roles, configuration, custom modules or Power Platform solutions, data classification, and every third-party connection. Specialist guidance on SAP cloud estates puts integrations, APIs, and partner add-ons firmly on the customer side — the same pattern holds for D365 and Odoo.

Non-human identities are a frequent blind spot. API keys, OAuth tokens, service accounts, and webhook secrets often bypass MFA and SSO. Treat them like privileged users: inventory them, scope least privilege, rotate or expire them, and alert on unusual export volume. High-profile 2024–2025 SaaS incidents showed how stolen OAuth tokens from an integration could silently query customer environments without a traditional password breach.

Partner and consultant access needs the same rigor as employee admin. Grant time-boxed elevated access during implementation and hypercare, require MFA, log every privilege change, and revoke standing admin when the project ends. Prefer break-glass or just-in-time elevation (Entra PIM on the Microsoft stack) over permanent partner System Administrator accounts. Offboarding a partner should be a checklist item next to cutting VPN access — not an afterthought six months later.

• →Inventory every connector, API key, OAuth app, and inbound webhook that can read or write ERP data.
• →Prefer short-lived tokens and app registrations with least privilege over long-lived personal API keys.
• →Sandbox custom code and community modules; review sudo()/elevated operations before production.
• →Time-box partner admin; document who can create users and change bank or tax fields.
• →Monitor for anomalous bulk export, mass delete, and role-assignment spikes.

ERP Security Priorities in Retail and Manufacturing

Retail and manufacturing SMEs face the same identity basics as everyone else, plus industry-shaped blast radii. Search interest in “ERP security retail manufacturing” is not accidental: both sectors couple high-volume operations data with payment, inventory, and sometimes regulated product information.

Manufacturing ERP often holds BOMs, formulations, pricing, production schedules, and vendor bank details. Attackers who reach it do not need classic ransomware to cause damage — they can redirect payments, steal product IP from item masters, or disrupt production and month-end close. Common gaps called out in 2026 manufacturing assessments include shared superuser accounts, warehouse roles that can also edit vendor banking, multi-version lag on patches, ERP exposed directly to the internet without VPN or zero-trust access, weak database-layer controls, and backups that exist but have never been restore-tested.

Retail ERP and POS-adjacent stacks concentrate cardholder-adjacent workflows, customer PII, promotions, and multi-store inventory. Risks skew toward high staff turnover (orphan accounts), shared POS or back-office logins, over-broad store-manager roles that can alter prices and refunds, and seasonal contractor access that is never revoked. If you process card data, keep PCI scope out of the ERP where possible and lock down who can export full customer lists.

Industry-specific priority stack: (1) named accounts everywhere — no shared admin; (2) SoD between receiving, purchasing, and payables (manufacturing) or between refunds, price overrides, and customer export (retail); (3) MFA for remote and admin access; (4) network isolation for on-prem or hybrid app servers; (5) immutable offsite backups with a defined RTO/RPO and an annual restore drill. Plant-floor OT and PLCs are a separate CISA concern — do not assume ERP hardening protects industrial controls, or vice versa.

Encryption, MFA, and Backups

Beyond access control, three controls do most of the remaining heavy lifting.

Encryption at rest should use AES-256, the NIST-approved symmetric standard (FIPS 197), which both D365 and Odoo Cloud apply under the hood. Encryption in transit should use TLS 1.3, recommended by NIST SP 800-52 Rev. 2 for new deployments and now supported by all major cloud ERPs. Encryption is also a named GDPR Article 32 technical and organizational measure.

Multi-factor authentication is, in CISA's words, 'the most important step an organization can make' for cybersecurity — require it for administrators, privileged accounts, and any access to remote or sensitive data. Prefer phishing-resistant factors (FIDO2/passkeys) where Entra Conditional Access allows it; on Odoo enforce built-in TOTP 2FA in Settings > Permissions for employees and portal users as appropriate. MFA on humans does not protect stolen API keys — rotate those separately.

Backups are the last line of defense against ransomware and catastrophic data loss. CISA's 3-2-1 guidance is the standard: keep 3 copies of your data, on 2 different media, with 1 copy stored offsite or offline — and test restores regularly, because untested backups are a common ransomware failure point. Odoo Cloud’s automated daily/weekly/monthly backup schedule meets the spirit of 3-2-1 out of the box; D365 customers should confirm their Dataverse environment backup and retention settings explicitly and document RTO/RPO with leadership.

Compliance: GDPR, PIPEDA, SOC 2, SOX

For most SMEs in Canada, the UK, and the US, four frameworks come up repeatedly when procurement or enterprise customers ask about ERP security. You usually do not need your own certification in all of them — but you do need to understand what each asks for and rely on your vendor's attestations where appropriate.

GDPR (EU) Article 25 mandates data protection by design and by default; Article 32 lists pseudonymization and encryption as appropriate measures; Article 30 requires Records of Processing Activities (RoPA); and Article 33 requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach. An SME running customer or employee data for EU residents in its ERP needs its RoPA and a breach-notification runbook ready.

PIPEDA (Canada) Principle 7 (Safeguards) requires security safeguards appropriate to the sensitivity of the information — physical, technological (encryption, passwords, firewalls), and organizational. Organizations must also keep records of all breaches of security safeguards for at least two years, regardless of whether they pose a real risk of significant harm.

SOC 2 uses the AICPA Trust Services Criteria (2017 with 2022 revisions); Security is mandatory, while Availability, Processing Integrity, Confidentiality, and Privacy are optional based on your commitments. Common Criteria CC6 (logical and physical access) and CC7 (monitoring and incident response) both require access-logging evidence — another reason to enable and review ERP audit trails. SOC 2 is an attestation, not a certification: most SMEs rely on their vendor's SOC 2 report rather than obtaining their own. ISO/IEC 27001 (2022) specifies a certifiable Information Security Management System and has significant control overlap with SOC 2 Security.

SOX (Sarbanes-Oxley) applies to public companies and requires effective internal control over financial reporting. Because the ERP is the core financial system, IT general controls (ITGCs) — segregation of duties, change management, and audit trails — fall directly in scope. Private SMEs are not SOX-regulated themselves, but may be asked to demonstrate SOX-aligned controls by public customers. Newer operational cyber rules (for example the EU NIS2 directive for in-scope entities) raise the bar on incident reporting for critical services — confirm with counsel whether you are in scope rather than assuming SaaS alone exempts you.

A Lightweight Security Framework for SMEs

The NIST Cybersecurity Framework (CSF) 2.0 organizes controls into six functions: Govern, Identify, Protect, Detect, Respond, Recover. NIST SP 1300 provides a free, lightweight small-business quick-start guide for SMEs without dedicated security staff. Mapped onto an ERP rollout, the framework becomes a short, practical checklist — no security operations center required.

1. 01
   Govern — assign ownership

   Name one person accountable for ERP security (often the IT lead or finance ops lead) and document which compliance frameworks apply to your business. Without named ownership, security work does not get done.

2. 02
   Identify — inventory what matters

   List the sensitive data classes in your ERP (PII, payroll, financials, IP), the integrations that touch them, privileged and partner accounts, and non-human identities (API keys, service principals). You cannot protect what you have not inventoried.

3. 03
   Protect — lock down access

   Enforce RBAC with least privilege, turn on MFA for all admin and remote access, enable auditing, time-box partner elevation, and assign duties (not raw privileges) using the platform's separation-of-duties tooling where available.

4. 04
   Detect — enable and review logs

   Turn on audit logging for logins, privilege changes, bank-field edits, and data exports, and review them on a fixed cadence (weekly or monthly). Unreviewed logs are not detection.

5. 05
   Respond — write the runbook

   Document who declares an incident, who notifies the supervisory authority within 72 hours (GDPR Article 33), and how you revoke compromised human and API access. Test the runbook once a year.

6. 06
   Recover — test your backups

   Follow CISA's 3-2-1 rule (3 copies, 2 media, 1 offsite/offline) and perform at least one restore test per year so you know the backup works before you need it.

Where an Implementation Partner Helps

Security is not a phase — it is a set of configuration decisions made at implementation time and maintained thereafter. The cheapest moment to embed strong access control, auditing, and a defensible compliance posture is during the original rollout, not after a breach.

As a dual-platform partner on both Microsoft Dynamics 365 and Odoo, we help SMEs design role structures that respect least privilege from day one, enable and tune auditing correctly, configure MFA and Conditional Access, govern partner and integration access, and produce the documentation (RoPA, access-review evidence, breach runbook) that procurement teams and regulators expect. Our AI-accelerated delivery is designed to deliver up to 3x faster than a traditional ERP rollout — without skipping the controls that keep your data safe.

If you are preparing for an ERP implementation or hardening an existing one, an ERP Readiness Call is the fastest way to map your specific risks and compliance obligations to concrete platform settings on D365 or Odoo.

Frequently asked questions