Add MFA While Users Keep Their Existing Application Credentials

Adding MFA does not have to mean replacing the login system your application already uses. With the right enforcement pattern, users keep their existing application credentials, the application continues to validate those credentials, and a separate access layer requires a second factor before protected content is released.

Datawiza Access Proxy supports this model with Datawiza built-in MFA. It can protect an existing browser-based application without requiring an external identity provider or moving passwords into a new directory.

Existing credentials are not the problem

Many applications already handle the first factor reliably. They have a user table, a familiar login page, password-reset processes, and account rules tied to business workflows. What they lack is a second factor.

Replacing the entire authentication system may introduce avoidable work:

• Migrating users and account attributes
• Resetting or synchronizing passwords
• Rewriting authentication code
• Changing support and recovery procedures
• Mapping local accounts to identities in a new provider
• Retraining users on a different sign-in journey

If the immediate requirement is stronger verification, a more focused approach is to keep primary authentication where it is and add MFA after the application confirms the login.

How MFA with existing application credentials works

The sequence matters:

1. The user enters the existing username and password on the application’s own login page.
2. The application validates those credentials against its current user store.
3. After the application signals a successful login, Datawiza built-in MFA presents the second-factor challenge.
4. The user verifies with an authenticator-app code or email one-time code.
5. Datawiza allows the verified session to continue to protected application content.

The password is still validated by the application. Datawiza does not need to become the application’s password database for this flow.

What Datawiza does—and what it does not do

Datawiza Access Proxy sits in the HTTP or HTTPS traffic path. It observes the application’s login flow and enforces the additional policy before protected requests reach their destination.

In built-in MFA mode, Datawiza:

• Requires second-factor enrollment and verification
• Enforces the MFA decision at the access layer
• Protects configured application routes
• Lets the application retain its existing login and user store

The application still:

• Owns usernames and passwords
• Decides whether the primary credentials are valid
• Handles its password policy and reset process
• Manages application-specific account status and permissions

This is different from SSO. SSO replaces or federates primary authentication through an identity provider. Built-in MFA can strengthen the existing login without making that broader identity change.

Why this avoids a user migration

An identity migration is not just a data import. It often requires matching accounts, resolving duplicates, coordinating password changes, defining lifecycle ownership, and updating downstream authorization.

The existing-credentials pattern avoids making those tasks prerequisites for MFA. Users can continue with the account they already have, and the application remains the system of record for primary authentication.

There is still an MFA enrollment step. Each user must register an allowed second-factor method, and administrators need a documented recovery process. That work is considerably narrower than moving the application’s entire identity model.

Applications that benefit from this pattern

This architecture is particularly useful for:

• Customer portals with application-local accounts
• Partner and supplier applications
• Legacy business applications with hard-to-change login code
• Commercial web applications that do not support modern federation
• Administrative consoles reached through a browser
• Applications with users outside the workforce identity directory

The application must be a browser-based service whose traffic can be routed through the proxy. It also needs a reliable way to identify successful primary authentication. Native desktop clients, VPN protocols, and other non-web access paths require a different integration.

Session behavior deserves careful testing

Post-login MFA depends on the boundary between the application session and the MFA-verified session. Before rollout, test:

• The exact response, redirect, or cookie that indicates a successful login
• Failed login and account-lockout behavior
• MFA enrollment and challenge flows
• “Remember this device” or persistent-session behavior, if enabled by policy
• Application logout and global session termination
• Idle and absolute timeouts
• Deep links and bookmarked protected pages
• Password reset and account recovery paths
• Multiple application hostnames and callback URLs

The objective is to prevent a user from reaching protected routes with only the application password while preserving necessary public and recovery paths.

A staged rollout plan

Start with an application-flow review rather than a user migration plan:

1. Map the application’s login, logout, and session lifecycle.
2. Place a test instance or limited route behind Datawiza Access Proxy.
3. Configure Datawiza built-in MFA and the protected-path policy.
4. Test authenticator-app and email-code enrollment as appropriate.
5. Validate direct URLs, expired sessions, and recovery scenarios.
6. Pilot with representative users.
7. Expand enforcement after logs and support procedures are ready.

For implementation detail, see the Datawiza built-in MFA tutorial.

Keep the login; add the missing factor

The most valuable part of this pattern is its restraint. You do not have to make an identity-provider rollout, password migration, and application rewrite part of the same project as MFA.

Users continue with the credentials they recognize. The application continues doing the job it already does. Datawiza adds a second checkpoint in front of protected access.

If the application later moves to centralized SSO, that can be a separate architecture decision. MFA does not need to wait for it.

Frequently asked questions

Can users keep their current username and password?

Yes. In this pattern, the application continues to validate its existing credentials. Datawiza enforces the second factor after successful primary authentication.

Does Datawiza copy or store the application password?

The application remains responsible for validating the password. Datawiza built-in MFA is an additional verification layer and does not require migrating the application password into an external IdP.

Is an identity provider required?

No. Datawiza built-in MFA can operate without an external IdP. An IdP is still an option when SSO, centralized lifecycle management, or workforce identity consolidation is also required.

Is this the same as SSO?

No. SSO changes how primary authentication is performed or shared across applications. This pattern preserves the existing application login and adds MFA to it.

Can this protect customer and partner accounts?

Yes, when they use a supported browser-based application that can be placed behind the proxy. It can be a useful fit when external users should remain in the application rather than a workforce directory. See MFA for customer portals.

Strengthen the login you already have

Learn how Datawiza MFA for web applications can add a second factor while preserving application credentials, or book a demo to review your login and session flow.