How to Add MFA Without Active Directory to an Existing Web App

You can add MFA without Active Directory when an existing web application already has its own user accounts and login page. The application continues to validate each username and password. An inline access proxy then requires a second factor before the user can reach protected content.

With Datawiza Access Proxy and Datawiza built-in MFA, this pattern does not require Active Directory, LDAP, a separate identity provider, or changes to the application’s authentication code.

What “without Active Directory” means

Active Directory Domain Services (AD DS) is an on-premises directory commonly used for domain-joined devices, Kerberos, NTLM, LDAP, and Group Policy. Microsoft Entra ID is a separate, cloud-based identity and access management service. Neither one is a prerequisite for every web application.

Many customer portals, partner sites, acquired applications, and older internal tools already maintain users in a local database. Moving those accounts into a central directory just to add MFA can turn a focused security improvement into a larger identity migration.

If the application can continue handling primary authentication, MFA can be enforced as a separate access step.

How the no-AD MFA pattern works

The request flow is straightforward:

1. The user browses to the protected application through Datawiza Access Proxy.
2. The application presents its existing login page.
3. The application validates the user’s current username and password against its existing user store.
4. Datawiza requires the user to complete built-in MFA.
5. After successful verification, the proxy allows access to the protected application.

The second factor can be an authenticator app using a time-based one-time password or a one-time code delivered by email. No external IdP is required for this built-in MFA flow.

This is an important division of responsibility: the application remains the authority for the password, while Datawiza enforces the additional verification step in the web traffic path.

What stays unchanged

Adding MFA this way does not require you to redesign the application’s login form or replace its user database. Users can keep the credentials they already know, and the application continues to own password validation and account lifecycle behavior.

The pattern can also avoid:

• Joining the application or its host to an Active Directory domain
• Adding an LDAP integration solely for MFA
• Synchronizing every application user into a workforce directory
• Rewriting the application to support SAML or OpenID Connect
• Storing application passwords in a second identity system

That narrower scope is useful when the security requirement is “require a second factor” rather than “replace the application’s identity model.”

When this approach is a good fit

Built-in MFA without Active Directory is best suited to browser-based applications whose HTTP or HTTPS traffic can be routed through an inline proxy. Common examples include:

• Legacy web applications with local accounts
• Customer and partner portals
• Vendor applications that cannot be modified
• Administrative interfaces exposed through a browser
• Applications used by people who do not belong in the corporate directory

It is not a general MFA solution for Windows desktop sign-in, Remote Desktop, VPN access, command-line protocols, or other non-web authentication. Those use cases require controls designed for their respective protocols.

Why use an access proxy?

Application-level MFA normally requires code that manages enrollment, challenges, recovery, sessions, and policy. An access proxy moves the enforcement point in front of the application instead.

Because every protected browser request passes through the proxy, it can check whether the user has completed the required MFA step before allowing the session to continue. This is similar to how a reverse-proxy MFA gateway applies a security policy at the application boundary.

The application still needs a clear, testable signal that its primary login succeeded. During deployment, teams should verify login redirects, cookies, logout behavior, session expiration, and any paths that must remain public.

A practical rollout checklist

Before enabling the policy for all users:

1. Confirm that the application is browser-based and can sit behind a reverse proxy.
2. Document the successful-login signal and the application’s session cookies.
3. Identify public paths such as health checks, password reset pages, or static assets.
4. Choose authenticator-app codes, email codes, or both for enrollment.
5. Test login, MFA enrollment, repeat visits, logout, timeout, and account recovery.
6. Pilot with a small user group before broad enforcement.
7. Monitor application and proxy logs during rollout.

The goal is to add one controlled verification step while leaving the existing login experience and account store intact.

Active Directory is optional—not irrelevant

Some organizations already rely on Active Directory or Entra ID and want consistent workforce access. In that case, federated SSO and IdP-managed MFA may be the better architecture.

But requiring a directory migration for every application and every external user can create unnecessary work. Datawiza built-in MFA provides another option: preserve the application’s local identity model and add the missing second factor at the access layer.

For a broader comparison of architectures, read Add MFA Without an IdP. To see the proxy model from a traffic-security perspective, read WAF-Like MFA for Any Web App.

Frequently asked questions

Can I add MFA without Active Directory or LDAP?

Yes, for a supported browser-based web application. The application can continue validating its local username and password while Datawiza Access Proxy enforces built-in MFA before protected access.

Do I need Microsoft Entra ID?

No. Datawiza built-in MFA does not require an external identity provider. Entra ID can still be used when centralized workforce identity and SSO are part of the goal.

Do users need new passwords?

No password migration is required for this pattern. Users continue signing in with the credentials stored and validated by the application.

Does the application need code changes?

The access-proxy pattern is designed to avoid changing application authentication code. Deployment still requires configuration and testing of routing, sessions, login success, logout, and public paths.

What MFA methods are available?

Datawiza built-in MFA supports authenticator-app codes and email one-time codes. Your rollout policy can enable the appropriate option for the application and user population.

Add a second factor without building a directory project

If your web application already knows its users, you may not need to introduce Active Directory just to add MFA. Explore Datawiza MFA for web applications or book a demo to evaluate the application flow.