How to Add MFA to Web Applications Without Microsoft Entra ID

You can add MFA to an existing web application without Microsoft Entra ID when the application already has its own login and user store. The application validates the username and password, while Datawiza Access Proxy requires a second factor before allowing access to protected pages.

Datawiza built-in MFA does not require an external identity provider. It gives teams a way to strengthen application-local accounts without first moving those users into an Entra tenant.

Entra ID and Active Directory are not the same thing

Microsoft Entra ID is Microsoft’s cloud-based identity and access management service, formerly called Azure Active Directory. Active Directory Domain Services is the traditional on-premises directory used for capabilities such as domain join, LDAP, Kerberos, NTLM, and Group Policy.

The names are related historically, but the architectures and use cases differ. “MFA without Entra ID” usually means avoiding a dependency on a cloud IdP. “MFA without Active Directory” may also mean avoiding an on-premises domain or LDAP directory.

Datawiza built-in MFA can operate without either one for supported browser-based web applications.

Why not every application user belongs in Entra ID

Entra ID is often the right choice for managed workforce identities, especially when an organization wants centralized SSO, lifecycle management, Conditional Access, and consistent policy across cloud services.

But some application populations do not fit that model cleanly:

• Customers who already have accounts in a product or portal
• Suppliers and partners managed by a line-of-business application
• Users of an acquired application with a separate identity store
• Contractors who should not become ordinary workforce-directory members
• Legacy application users who only need one protected service

Creating or synchronizing Entra identities for these users may expand the project beyond its security goal. If the application already knows who the user is, the missing control may simply be a second factor.

How Datawiza built-in MFA works without Entra ID

Datawiza Access Proxy is placed in front of the web application. The application keeps its current primary-login flow, and Datawiza adds the MFA decision in the access path.

The sequence is:

1. A user requests the protected web application through Datawiza Access Proxy.
2. The application presents its existing sign-in page.
3. The application validates the existing username and password.
4. Datawiza built-in MFA requires an authenticator-app code or an email one-time code.
5. The verified session is allowed to reach protected application content.

No Entra tenant integration is required for this flow, and there is no external IdP redirect. The application remains responsible for primary credentials; Datawiza is responsible for the added verification gate.

Built-in MFA or Entra-backed MFA?

The better choice depends on the outcome you need.

Choose Datawiza built-in MFA when:

• The application already has a working local login
• The immediate objective is to add a second factor
• Users should remain in the application’s user store
• An IdP migration is out of scope
• External users should not be onboarded into the workforce tenant

Choose an Entra-backed architecture when:

• Users already have managed Entra identities
• SSO across multiple applications is a primary requirement
• Centralized joiner, mover, and leaver processes are needed
• Conditional Access and broader Microsoft identity policies are central to the design
• Replacing the application login is an intended part of the project

These approaches are not opponents. Datawiza can support modern identity integrations, while built-in MFA addresses applications and user populations for which an IdP is not required.

What you avoid—and what you still need to do

Using built-in MFA can avoid making these tasks prerequisites:

• Creating Entra accounts for every application user
• Configuring an application registration solely to add MFA
• Mapping local accounts to cloud identities
• Migrating application passwords
• Rewriting the application for SAML or OpenID Connect
• Redirecting users away from the existing login experience

It does not remove the need for deployment planning. Teams still need to route traffic through the proxy, define protected and public paths, confirm the application’s successful-login signal, configure MFA enrollment, and test session and recovery behavior.

A useful fit for external and legacy applications

MFA without Entra ID is especially relevant to customer-facing portals and older applications. These systems often have valid reasons to own their accounts: product entitlements, customer organization relationships, subscription state, partner roles, or historical workflow logic.

Forcing those identities into a workforce tenant can blur ownership and increase administrative overhead. Keeping the primary identity in the application while adding MFA at the edge preserves the existing business model.

The pattern is designed for browser-based applications whose HTTP or HTTPS traffic can pass through an inline proxy. It is not a replacement for Entra-based device sign-in, Microsoft 365 access, Windows desktop authentication, VPN MFA, or non-web protocols.

Deployment questions to answer first

Before selecting the architecture, document:

1. Who owns the user accounts today?
2. Are the users employees, customers, partners, or a mixture?
3. Is the goal MFA only, or also SSO and centralized lifecycle management?
4. Can all browser traffic reach the application through an access proxy?
5. How does the application signal a successful login?
6. Which routes must remain public?
7. Which second-factor and recovery methods will be supported?
8. How should application logout affect the MFA-verified session?

Clear answers prevent an MFA project from accidentally becoming an unplanned identity migration.

Frequently asked questions

Can I add MFA without an Azure AD or Entra ID account?

Yes. Datawiza built-in MFA does not require users to have Entra ID accounts. The existing web application can retain its local users and primary login.

Is Azure AD now called Microsoft Entra ID?

Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID. It remains Microsoft’s cloud identity and access management service and is distinct from on-premises Active Directory Domain Services.

Do users keep their application credentials?

Yes. The application continues validating its existing username and password. Datawiza adds the second-factor step before protected access.

Does this require changes to application authentication code?

The access-proxy pattern is designed to avoid changing the application’s authentication code. It still requires configuration and validation of routing, login success, cookies, logout, timeouts, and recovery paths.

Can we adopt Entra ID later?

Yes. Adding built-in MFA now does not prevent a later SSO or identity-consolidation project. Treat the future migration as a separate decision based on user population and lifecycle requirements.

Add MFA without making Entra ID a prerequisite

If your application already manages its users, you can strengthen access without first moving them into a cloud identity provider. Explore Datawiza MFA for web applications, learn about the MFA gateway pattern, or book a demo to review your use case.