Table of contents
AD FS can support MFA through additional authentication methods and provider or adapter patterns. But for many teams, the hard part is not whether AD FS can do MFA. It is the operational work required to configure, maintain, and extend MFA inside the AD FS environment.
If your goal is to add MFA or 2FA to existing AD FS-protected web applications quickly, Datawiza Access Proxy gives you another path: enforce MFA at the access proxy layer, outside the AD FS farm and outside the application code.
Why AD FS MFA Projects Become Complicated
AD FS MFA can touch federation configuration, relying party policy, authentication providers, certificates, server maintenance, and testing across each application. For teams with legacy apps, ERP systems, customer portals, or internal web apps, that can become a larger identity infrastructure project than expected.
Microsoft documents additional authentication methods for AD FS and guidance for configuring AD FS and multifactor authentication. Those approaches may be the right fit in some environments, but they still live inside the AD FS operating model.
For many organizations, the requirement is simpler: challenge the user with MFA before they reach a sensitive application, without adding more AD FS-side complexity.
The Datawiza Pattern: MFA in Front of AD FS-Protected Apps
Datawiza Access Proxy sits in front of the protected web application. When a user requests access, Datawiza detects the access flow and enforces MFA or 2FA before allowing traffic to continue.
AD FS can remain in place. The application can remain unchanged. Datawiza becomes the external enforcement layer for MFA, access policy, and logging.
That means you can add MFA without:
- Installing AD FS plugins or adapters
- Patching federation servers
- Rewriting application login code
- Changing every relying party at once
- Starting a full IdP migration project
Built-In MFA or Existing MFA Services
Datawiza includes built-in MFA, so you do not have to make AD FS or another identity provider the center of every MFA decision.
If you already use Microsoft Entra ID, Duo, Okta, Ping, or another MFA or identity service, Datawiza can also integrate where useful. The key is flexibility: enforce MFA at the gateway layer instead of forcing every application or AD FS policy to carry the full burden.
For a broader commercial overview of this access-layer pattern, see MFA for Web Applications and MFA Gateway.
Where This Helps Most
This pattern is useful when AD FS is still protecting applications that are hard to change:
- Legacy web applications
- Header-based applications
- ERP apps such as Oracle EBS, PeopleSoft, JD Edwards, or SAP web apps
- Internal admin portals
- Customer or partner portals
- Custom apps with old login logic
Instead of rebuilding authentication inside each app, Datawiza adds an access layer in front.
AD FS Today, Modern IdP Later
This approach also keeps your migration path open. You can use Datawiza to add MFA around AD FS-protected apps now, then later move the same apps toward Microsoft Entra ID, Okta, Ping, or another identity provider.
That matters because many AD FS environments are not retired all at once. The first apps may migrate cleanly. The last apps often need a bridge. For that broader retirement strategy, read Is ADFS End of Life? The Honest Answer, and How to Retire It.
Examples: Oracle EBS and PeopleSoft
AD FS often stays around because a few business-critical applications are difficult to change. Oracle EBS and PeopleSoft are common examples. Datawiza can sit in front of these apps, enforce SSO and MFA, and avoid rewriting the application stack.
Related guides: AD FS SSO for Oracle EBS and AD FS SSO for PeopleSoft.
Frequently Asked Questions
Can AD FS provide MFA?
Yes. AD FS can support additional authentication methods and MFA integrations. The question is whether AD FS-side MFA is the fastest and cleanest way to protect the applications you already have.
Does Datawiza replace AD FS?
Not necessarily. Datawiza can sit in front of AD FS-protected applications while AD FS remains part of the existing authentication flow. Over time, the same access proxy pattern can also help move applications toward Microsoft Entra ID, Okta, Ping, or another modern identity provider.
Do we need to install an AD FS plugin?
No. The Datawiza pattern enforces MFA at the access proxy layer, so you do not need to install an AD FS plugin or patch the federation servers just to add MFA in front of protected applications.
Can Datawiza use built-in MFA?
Yes. Datawiza has built-in MFA. It can also integrate with existing identity and MFA services when that is the better fit for your environment.
Conclusion
AD FS can support MFA, but AD FS-side MFA is not always the fastest or cleanest way to protect existing applications.
If you need MFA or 2FA for AD FS-protected web apps without plugins, patches, or application code changes, Datawiza Access Proxy can enforce MFA externally and give your team a practical path forward.
Need MFA for AD FS-protected apps? Book a demo, and we can walk through where Datawiza should sit in your current access flow.
