Add MFA to Web Applications Without Code Changes Using WAF or Gateway Routing

Many external web applications already sit behind a WAF, CDN, or application gateway—such as Cloudflare, Akamai, F5, AWS, or Azure. Yet many of these applications still rely on username and password only for login.

That creates a common and dangerous gap.

WAFs are effective at blocking bots, scanning, and exploit attempts—but they cannot stop valid credentials. If a password is stolen, reused, or phished, a password-only login page is still easy to compromise.

If you control routing, there is a fast and low-risk way to fix this:

Add MFA to your web application by routing only login endpoints through Datawiza—while leaving the rest of the application unchanged. This can be done with WAF/gateway routing rules (login endpoints only) or, in some cases, a simple DNS cutover.

This approach works especially well for:

• Customer portals
• Partner and dealer portals
• Vendor and supplier portals
• Broker and advisor portals
• Legacy or custom web apps that are hard to modify

How to add MFA to a web application without code changes

Instead of rewriting authentication or migrating users, this model uses path-based routing at the WAF or gateway layer.

Core routing pattern

• Login endpoints → Datawiza (MFA /2FA enforcement)
• All other application paths → origin application (unchanged)

Login endpoints are often called:

• the login page
• the login form
• the sign-in endpoint

They commonly include paths such as:

• /login , /signin
• /auth/*

By routing only these paths, you protect authentication without introducing risk or latency to the rest of the app.

How the routing-based MFA model works

1. User traffic reaches your WAF / CDN / gateway This remains exactly the same as today.
2. Login requests are routed to Datawiza Datawiza enforces MFA or 2FA and authenticates users.
3. Non-login traffic goes directly to the origin application After authentication, most application requests bypass Datawiza entirely, keeping performance impact minimal.

What you typically don’t need

With this approach, teams usually avoid:

• Application code changes
• Rebuilding login pages
• User migration
• Replacing the existing user store

This makes it well-suited for external portals where development changes are slow or risky.

Implementation checklist (quick and practical)

To deploy this pattern, teams typically do three things:

1. Identify login-related endpoints Focus only on paths involved in authentication.
2. Create a gateway routing rule Route login endpoints to Datawiza; send everything else to the origin.
3. Configure Datawiza’s upstream correctly This is critical to avoid routing loops.

Vendor-neutral routing logic:

• IF request path matches login endpoints → route to Datawiza
• ELSE → route to origin application

Why teams choose this approach

Security benefits

• MFA or 2FA for password-only login pages
• Reduced account takeover risk
• Stronger protection for external users

Operational benefits

• Fast rollout using routing rules
• Minimal blast radius (authentication only)
• Easy rollback or expansion later (e.g., protect admin paths)

Best-fit use cases

This model works best when:

• the web app is legacy or custom
• authentication logic is embedded and hard to change
• users cannot be migrated easily
• the app is already behind a WAF or gateway

Common examples:

• Customer self-service portals
• Partner and dealer portals
• Supplier and vendor systems
• External-facing internal web apps

FAQs

Can I add MFA to a web application without changing code? Yes. If the app is behind a WAF/CDN/gateway, you can route login endpoints to Datawiza and enforce MFA without modifying the application in most deployments.

How do I add 2FA to a login page? By routing the login page or login form endpoints through Datawiza at the gateway layer, while leaving all other application paths unchanged.

Do I need to migrate users? No. Datawiza integrates with your existing identity provider or user store.

Will this affect application performance? Only login endpoints are routed through Datawiza. Non-login traffic can go directly to the origin.

Does this work with Cloudflare, Akamai, F5, AWS, and Azure? Yes. Any WAF or gateway that supports path-based or rule-based routing can implement this pattern.

Do we have to use Cloudflare, Akamai, F5, AWS, or Azure CDN/WAF to integrate Datawiza MFA? No. A DNS cutover is also a common option. You can route the application domain to Datawiza (so all traffic reaches Datawiza first). Datawiza will enforce MFA only on the login endpoints and simply proxy all other application traffic to your origin app—so you still get MFA without changing application code or migrating users.

Call to action

If you can share:

1. your portal URL and login endpoints
2. your WAF/CDN/gateway platform (or whether you prefer DNS cutover)
3. how your origin is exposed (true origin vs proxied)

We can recommend a clean routing pattern to help you add MFA to your web application without code changes or user migration.

Book a demo