Add MFA to SAP Web Apps and Portals Without New IdP Accounts
Table of contents
A supplier confirming a purchase order, a customer checking an order, and an employee viewing a payslip may all use SAP web applications without sharing the same corporate identity system. Adding multi-factor authentication (MFA), or two-factor authentication (2FA), should not require creating an identity-provider account for every portal user.
Datawiza adds MFA to customer, supplier, partner, and employee self-service portals while users keep their existing SAP login credentials. Built-in MFA requires no new corporate identity provider (IdP) accounts or AD/LDAP integration just to add the second factor. Datawiza Access Proxy runs in front of the SAP web application, so MFA can be introduced independently of a major SAP upgrade or customization project.
For users already in an enterprise identity provider, Datawiza also supports SSO and MFA through providers such as Microsoft Entra ID, Okta, Ping, and Cisco Duo. This guide covers browser-based SAP web applications over HTTP or HTTPS, including Web GUI, Fiori, Enterprise Portal, SRM, ESS, and custom web apps.
MFA for SAP customer, supplier, partner, and employee portals
SAP web access includes customers checking orders, suppliers responding to purchase orders, partners managing sales, and employees using HR self-service. SAP Enterprise Portal documentation explicitly describes access for customers, suppliers, partners, and employees. These groups can have very different identity-management needs.
The examples below illustrate browser-based SAP workflows. Available functions depend on the SAP release, configuration, and user roles. They are not confirmed Datawiza customer deployments or a blanket compatibility guarantee; validate each portal login and session flow.
| Portal audience | SAP application or portal | Illustrative business scenario |
|---|---|---|
| Suppliers and vendors | SAP SRM Supplier Self-Services (SUS) | A supplier reviews purchase orders, confirms or rejects items, and creates shipping notifications or invoices, depending on the configured procurement process. |
| Customers | SAP Enterprise Portal with customer-specific applications | A manufacturer could expose order-status checks and business documents through its customer portal. The functions come from the applications configured behind the portal. |
| Dealers, distributors, and business partners | Classic SAP CRM Partner Channel Management / partner portals | A reseller obtains quotations, places orders, or orders on behalf of an end customer. |
| Employees | SAP ERP HCM Employee Self-Service (ESS) web applications | An employee views a salary statement, updates bank details, or submits a leave request using the configured ESS services. |
SAP documents these workflows in SUS purchase order processing, CRM Partner Channel Management, and HCM Employee Self-Service, including bank details and leave requests.
Add MFA without moving portal users into your workforce directory
Requiring every supplier or partner to join a corporate IdP can turn an MFA rollout into a separate identity-onboarding project. With Datawiza built-in MFA, portal users keep their existing SAP credentials and enroll a second factor without a new corporate IdP account. See the SAP SRM supplier portal MFA guide for the supplier-specific rollout.
The same approach can serve employee self-service populations without corporate IdP accounts, such as seasonal staff, or retirees who retain access to selected HR services where configured. Employees accessing a portal from home are still employees; the relevant distinction here is whether they have a corporate IdP account. Read more about MFA for HR systems and employee self-service.
For employees or other users already managed in Microsoft Entra ID, Okta, Ping, Cisco Duo, or another supported identity provider, Datawiza can use that provider for SSO and MFA. Choose the authentication approach for the portal population. SAP continues to manage application permissions, and teams still need to manage MFA enrollment, account recovery, and account lifecycle.
Why teams use Datawiza for SAP MFA and 2FA
SAP environments often combine customer and supplier portals, partner access, employee self-service, and internal business applications. Some users belong to a workforce IdP; others have only SAP portal credentials. Datawiza supports both populations across modern and older SAP web components.
- No custom SAP connector, plug-in, or in-stack MFA module project.
- Deploy MFA independently of the SAP upgrade and release cycle.
- Built-in MFA for customer, supplier, partner, and employee self-service users who do not have corporate IdP accounts.
- Enterprise IdP integration through SAML or OIDC for SSO, MFA, passkeys, and conditional access.
- Application- and path-level policy plus centralized authentication and audit logs.
- Customer-managed deployment in a cloud or data center, or a Datawiza-hosted service.
How Datawiza adds MFA to SAP web applications
Datawiza Access Proxy sits in the HTTP or HTTPS request path in front of the SAP web application. It integrates with the configured login flow and enforces the selected authentication policy before releasing protected application content. Because it runs outside the SAP application stack, the MFA rollout can be planned independently of SAP upgrades and release schedules.
Option 1: Datawiza built-in MFA
In the existing-credentials flow described here, users first sign in with the SAP application credentials they already have. After SAP verifies the username and password, Datawiza presents the MFA challenge and releases protected application access only after successful verification. No separate IdP account, directory migration, or new AD/LDAP integration is required for this MFA approach.
This mode is particularly useful for SAP supplier, partner, customer, contractor, and employee self-service portals whose users are not managed in the corporate identity provider.
Option 2: MFA through your existing identity provider
For users already managed by an enterprise identity provider, Datawiza federates the login through SAML or OIDC. Microsoft Entra ID, Okta, Ping, Cisco Duo, Google, OneLogin, Shibboleth, AD FS, or another supported provider can perform authentication and MFA, while Datawiza translates and enforces the access flow in front of SAP.
This extends enterprise SSO, two-factor authentication, conditional access, and passkeys to SAP web components that would otherwise require separate Basis integration work. It also lets one policy layer cover a mixed estate instead of treating every SAP URL as a new identity project.
A practical SAP MFA rollout
1. Choose one SAP web URL and a specific audience, such as suppliers using SUS, customers using a portal, or employees using ESS.
2. Route that URL through Datawiza Access Proxy using DNS, a load balancer, gateway, or reverse proxy configuration.
3. Select built-in MFA for existing SAP users or connect the enterprise IdP through SAML or OIDC.
4. Validate login, session, logout, and application-path policy with a pilot group, then repeat the pattern across additional SAP web applications.
Which SAP web applications can Datawiza protect?
The access-layer pattern applies to browser-accessible SAP applications, including:
- SAP Web GUI (SAP GUI for HTML) and ITS paths
- SAP Fiori Launchpad
- SAP Enterprise Portal
- SAP Web Dynpro, BSP, and custom ABAP web applications
- SAP SRM and supplier portals
- Employee self-service, customer, dealer, and partner portals connected to SAP
This guide covers browser-based SAP web applications using HTTP or HTTPS. It does not cover SAP GUI for Windows, which requires a desktop-client authentication approach. Validate the login, session behavior, and configured SAP services for each portal before rollout.
Datawiza access-layer MFA compared with SAP integration projects
Native SAML on NetWeaver or Fiori can be a good fit for a current SAP web stack, internal users already managed in an IdP, and a Basis team prepared to configure and test every system and landscape. SAP IAS is similarly appropriate for SAP-cloud-centered environments.
Datawiza is worth evaluating when customer, supplier, partner, or self-service users need to keep existing SAP credentials without new IdP accounts. It also suits mixed SAP web environments where a major upgrade or customization effort would delay MFA. The proxy runs as a customer-managed deployment or a Datawiza-hosted service, independently of the SAP application stack.
SAP MFA, 2FA, and compliance coverage
SAP applications frequently sit inside SOX ITGC, NIS2, TISAX, and cyber insurance assessments. Auditors care about coverage and evidence: which SAP entry points require MFA, which users are challenged, and which logs prove enforcement. Datawiza centralizes those policies and authentication events outside the application stack. See the MFA compliance requirements hub for a framework-by-framework view.
Frequently asked questions
Can Datawiza add MFA or 2FA without a major SAP upgrade or customization project?
Yes. Datawiza Access Proxy enforces authentication and MFA in the web request path before protected SAP content is released. It is deployed outside the SAP application stack, so teams can protect SAP Web GUI, Fiori, Portal, Web Dynpro, ITS, SRM, ESS, and custom web applications without making MFA dependent on a major SAP upgrade, custom connector, or lengthy Basis project.
Do SAP users need new identity provider accounts?
No. With Datawiza built-in MFA, customers, suppliers, partners, and employee self-service users can keep their existing SAP credentials without new corporate IdP accounts or AD/LDAP integration. SAP verifies the password and Datawiza adds the second factor before releasing protected application access. Users already in an IdP can instead use that provider for SSO and MFA.
Can employee self-service users get MFA without corporate IdP accounts?
Yes. Built-in MFA can add a second factor while eligible employee self-service users keep their existing SAP credentials. This can be useful for populations such as seasonal staff or retirees with approved portal access. Employees already in an enterprise IdP can use the IdP-based option. Validate the configured ESS login and account-recovery flow.
Can Datawiza use Microsoft Entra ID, Okta, Ping, or Cisco Duo for SAP MFA?
Yes. Datawiza integrates with enterprise identity providers through SAML or OIDC, including Microsoft Entra ID, Okta, Ping, Cisco Duo, Google, OneLogin, Shibboleth, AD FS, and others. The IdP performs authentication and MFA; Datawiza enforces the resulting access flow in front of SAP.
How do I add two-factor authentication to SAP Web GUI?
Route the SAP Web GUI or ITS URL through Datawiza Access Proxy, then choose built-in MFA or connect an existing IdP. Validate the login and session flow so protected application access requires both the configured authentication and the second factor.
Can MFA be different for SAP admin users and regular users?
Yes. Datawiza can apply authentication and access policy by application, user population, and protected path. Administrative users or sensitive SAP paths can receive stronger MFA requirements while other users retain the appropriate policy for their role.
Does Datawiza cover SAP GUI for Windows?
No. This approach protects SAP web applications accessed through a browser over HTTP or HTTPS, including SAP GUI for HTML. SAP GUI for Windows uses a different desktop-client access path.
Add MFA to one SAP web application first
Start with one customer, supplier, partner, or employee self-service portal. Identify how those users sign in today and whether they have corporate IdP accounts. Datawiza can demonstrate built-in or IdP-based MFA with that portal before you extend the approach to other SAP web applications.
Book a demo and bring the SAP URL, user population, and MFA or compliance requirement you need to address.
SAP and SAP product names are trademarks or registered trademarks of SAP SE or its affiliates. This page describes an independent Datawiza solution and is not affiliated with or endorsed by SAP.
