Your ERP holds everything that matters: financial data, customer records, payroll, inventory. And yet, in the majority of European SMEs and mid-market companies, ERP accounts are managed entirely separately from the rest of the information system. An employee has one password for Microsoft 365, another for the ERP, and a third for document management. The result: reused passwords, ghost accounts that were never deactivated when someone left, and no central visibility into who is accessing what.
Single Sign-On (SSO) combined with Microsoft Entra ID (formerly Azure Active Directory) is the operational answer to this problem. This guide covers the why and the how for the four most widely deployed ERPs in Europe: SAP S/4HANA, Microsoft Dynamics 365 Business Central, Odoo, and Sage.
Why Connect Your ERP to Microsoft Entra ID in 2026
SSO vs Local ERP Accounts: 5 Risks of the Status Quo
Managing ERP accounts in silos exposes your organisation to well-documented risks.
1. Shared or Reused Passwords When an employee needs to remember five different passwords, they end up copying one. The ERP password becomes the same as the personal email or Windows login. A single breach is enough to compromise access to financial data.
2. Orphaned Accounts A departure, an internal transfer, a contractor at the end of an engagement: if ERP deactivation is not synchronised with HR, the account remains active. These zombie accounts are the preferred entry point for attackers, because they trigger no suspicious-activity alerts.
3. No MFA on the ERP Many legacy ERPs have no native MFA. Once connected to Entra ID, they automatically inherit the company’s authentication policies, including the second factor.
4. No Centralised Visibility With local accounts, it is impossible to answer in real time: “who was logged into the ERP last night at 11 pm from a Romanian IP address?” With Entra ID, connection logs are available in a single dashboard.
5. NIS2 Non-Compliance The NIS2 Directive (EU) 2022/2555 requires organisations to implement strong authentication measures and maintain audit traceability. Local ERP accounts without a centralised audit trail weaken your compliance posture significantly.
The Tangible Benefits for Users and Security
For users, SSO means a single login for the entire working day. The employee authenticates on their Windows workstation (or via the Microsoft 365 portal), and the ERP opens without any further password prompt. The experience is identical when working remotely, with conditional MFA as the only additional safeguard.
On the security side, Microsoft confirms in its official research that MFA blocks more than 99.9% of account attacks, based on analysis of millions of Azure AD sign-ins (Microsoft Security Blog, 2019). Updated figures from 2024 confirm the trend: accounts protected by MFA resist more than 99.2% of identity-based attacks (Microsoft Entra documentation).
Entra ID, Azure AD, SAML, OIDC: the Essential Glossary in 5 Minutes
Microsoft Entra ID is the new name for Microsoft Azure Active Directory since July 2023. If your ERP integrator still talks about “Azure AD”, they mean the same thing. Microsoft’s official documentation has gradually migrated, but the APIs and features are identical.
SAML 2.0 (Security Assertion Markup Language) is the established protocol for enterprise SSO. It works by exchanging XML “assertions” between the ERP (the service provider) and Entra ID (the identity provider). Most on-premise and B2B SaaS ERPs support SAML 2.0.
OAuth 2.0 / OpenID Connect (OIDC) is the more modern protocol, native to the web and mobile applications. Dynamics 365 Business Central uses OIDC natively with Entra ID. Odoo can be configured with OIDC via specific modules.
When to use which? SAML 2.0 for on-premise ERPs or B2B SaaS solutions that do not yet support OIDC (SAP IAS, Sage X3). OIDC for Microsoft-native applications and modern cloud ERPs. In all cases, Entra ID supports both protocols.
ERP SSO Integration: the 4 Main Systems
SAP S/4HANA and SAP Business One with Entra ID
SAP recommends a three-tier architecture for integration with an external identity provider. Entra ID does not connect directly to S/4HANA: it goes through SAP Cloud Identity Services (the former SAP Identity Authentication Service, IAS), which acts as a proxy.
The flow works as follows: the user attempts to sign in to S/4HANA, SAP IAS redirects the request to Entra ID, Entra ID authenticates the user (with MFA if applicable), then returns an assertion to IAS, which forwards it to S/4HANA.
This architecture has a key advantage: SAP IAS remains the central repository for SAP access rights (roles, SAP groups), while Entra ID manages the user’s identity. SAP administrators keep control of access governance. Microsoft and SAP jointly document this scenario in the guide Scenario - Using Microsoft Entra ID to secure access to SAP platforms.
For SAP Business One, integration is available via the IAM (Identity and Authentication Management) module in Business One, with SAML 2.0 configuration pointing to Entra ID.
Microsoft Dynamics 365 Business Central with Entra ID
This is the simplest case. Business Central is a Microsoft product: integration with Entra ID is native and requires no third-party middleware. Every Business Central tenant is automatically linked to the organisation’s Entra ID tenant.
Business Central users are provisioned from Entra ID. Conditional Access policies (MFA off-network, suspicious IP blocking) apply automatically. This is a strong structural advantage for organisations already in the Microsoft 365 ecosystem: there is nothing to configure beyond licence management.
Entra ID is included in Microsoft 365 Business Premium (P1 level) and in E3 and E5 plans. For the vast majority of companies already running Microsoft 365, this integration is therefore available at no additional licence cost.
Odoo 17/18 with Entra ID
Odoo Community and Enterprise do not offer native SAML or OIDC integration out of the box. Two options are available to the integrator.
Option 1: OCA module (Odoo Community Association)
The auth_saml module maintained by the OCA (available at apps.odoo-community.org) enables SAML 2.0 on Odoo. It is open source, compatible with Odoo 17, and can be configured with Entra ID as the Identity Provider. This is the preferred solution for on-premise deployments.
Option 2: Odoo Apps marketplace modules Several publishers offer specific Microsoft Azure SSO modules on the official Odoo Apps marketplace, for versions 16, 17, and 18. These modules handle authentication via OAuth 2.0 / OIDC with Entra ID.
Key considerations: verify compatibility with your Odoo version, module maintenance status (date of last commit, open issues), and the impact on future migrations. None of these modules are officially endorsed by Odoo SA.
Sage X3 / Sage 200 with Entra ID
Sage X3 (now part of the Sage Business Cloud family) supports SAML 2.0 authentication. Configuration is done in the authentication settings of the X3 Administration module, declaring Entra ID as the Identity Provider via its SAML metadata URL.
For Sage 200, SSO configuration depends on the version and deployment model. In Sage SaaS mode, some SSO options are available directly from the partner portal. In on-premise mode, SAML integration requires integrator involvement in the Sage server configuration.
In both cases, the principle is the same: configure the Entity ID and Assertion Consumer Service URL on the Sage side, then create the corresponding enterprise application in Entra ID.
Conditional MFA for Your ERP: Recommended Policies
Conditional MFA is the Entra ID feature that enforces the second factor based on connection context, not universally.
Rule 1: Always require MFA off-network Configure a Conditional Access policy that enforces MFA for any ERP access from an IP outside the corporate network. In practice: remote work, travel, access from a mobile device on a cellular network.
Rule 2: Exempt access from trusted IP ranges To avoid daily friction in the office, define your fixed IP ranges as “Named Locations” in Entra ID. Connections from these IPs are exempt from MFA. This pragmatic compromise satisfies business teams without sacrificing external security.
Rule 3: Block high-risk geographies Entra ID allows you to block sign-in attempts from entire geographies. If your ERP has no legitimate users outside your operating countries, the rest can be blocked in two clicks.
Rule 4: Require MFA for sensitive roles in all circumstances For ERP administrators, accounting access, and finance roles, configure mandatory MFA regardless of IP address. These accounts are the primary targets for attackers.
Automatic Provisioning and Deprovisioning with SCIM
SSO solves authentication, but not account lifecycle management. The SCIM protocol (System for Cross-domain Identity Management) fills this gap.
Why SSO alone is not enough With pure SSO, the user authenticates via Entra ID but their ERP account is still managed manually. An employee who leaves the organisation has their Entra ID account disabled by HR, but their ERP account can remain active if no one thinks to delete it. This gap is a direct violation of NIS2 requirements on access management.
What SCIM enables When a user is created, modified, or deactivated in Entra ID (typically driven by the HRIS via an ADP, SAP SuccessFactors, or similar connection), SCIM automatically propagates the action to the target ERP. The ERP administrator does not receive a manual ticket to process.
SAP Cloud Identity Services natively supports SCIM for synchronisation between Entra ID and S/4HANA. Dynamics 365 Business Central manages the lifecycle directly from Entra ID. For Odoo and Sage, SCIM availability depends on the version and integrator: verify with your partner.
5 Common Pitfalls and How to Avoid Them
Pitfall 1: Service accounts excluded from SSO Technical accounts (EDI synchronisation, API interfaces, overnight batch jobs) cannot go through SSO. They remain local. A frequent mistake: leaving them without MFA or audit. Apply long rotating passwords, connection monitoring, and limit their access scope to the strict minimum.
Pitfall 2: Poorly mapped Entra ID groups on ERP roles SSO carries Entra ID groups through to the ERP. If the mapping is approximate (“the entire Finance group” receives an “ERP administrator” profile), you create a massive over-allocation of rights. Map the correspondence between Entra ID groups and ERP profiles precisely before deployment.
Pitfall 3: Testing only in the dev environment SSO in production can behave differently from SSO in dev (callback URLs, certificates, session durations). Plan a full test in pre-production with real production certificates before switching over.
Pitfall 4: Forgetting external users (consultants, auditors) Entra ID B2B guest accounts allow you to give them temporary access without creating a local account in the ERP. Use this feature instead of creating “temporary” local accounts that are never deleted.
Pitfall 5: Neglecting certificate rotation SAML metadata contains an X.509 certificate with an expiry date. If this certificate expires, SSO fails. Schedule renewal 90 days in advance and test the process at least once.
7-Step Implementation Checklist
- Inventory the ERPs in scope: which modules, versions, and deployment models (cloud/on-premise).
- Verify Entra ID licences: Microsoft 365 Business Premium or E3/E5 include Entra ID P1, sufficient for basic Conditional Access. Advanced policies (Identity Protection, Privileged Identity Management) require Entra ID P2.
- Map groups and roles: define the correspondence between existing Active Directory groups and ERP profiles before any configuration.
- Configure the enterprise application in Entra ID: one application per ERP, with the appropriate protocol (SAML for SAP IAS, OIDC for Business Central, SAML or OIDC for Odoo).
- Test SSO with a pilot group: 5 to 10 volunteer users with varied profiles, before a full rollout.
- Deploy Conditional Access policies: MFA off-network, geographic blocking, rules for sensitive roles.
- Activate SCIM where available: synchronise ERP account lifecycle from Entra ID/HRIS at go-live, not in phase 2.
What to Anticipate for 2027
Microsoft Entra ID is actively pushing towards passwordless authentication (Passkeys, Windows Hello for Business, Microsoft Authenticator passwordless). For ERPs that support these mechanisms, this is the natural next step after SSO+MFA.
NIS2, now fully applicable across the EU, will tighten audit requirements around identity management. Having a centralised SSO and an operational SCIM provisioning setup places your compliance evidence in a single system of record, which considerably simplifies audit preparation.
To go further on ERP access security, see our Zero Trust ERP guide: IAM, PAM and MFA for CISOs and the NIS2 ERP evidence checklist for cybersecurity audits. For the governance and compliance frameworks that underpin these decisions, see also our article on ERP governance, risk and compliance.
Download our ERP evaluation grid: 30 criteria scored out of 100 to compare three solutions side by side, with a dedicated section on IAM/SSO capabilities.
