Add MFA to Any IIS App With a Simple DNS Update

IIS applications often power mission-critical workflows—customer and partner portals, vendor access, and internal tools that are now reachable outside the network. Security expectations have changed (credential stuffing, password spraying, account takeover), but many IIS apps are still protected by password-only login because “adding MFA” usually turns into a risky application project.

Datawiza makes MFA for web apps simple: enforce Multi-Factor Authentication (MFA) / Two-Factor Authentication (2FA) in front of your IIS app with a DNS update—so you can roll out stronger login security without rewriting the application.

Why IIS Apps Are Hard to Modernize (But Still Need MFA)

Many IIS apps weren’t designed for today’s identity threat landscape or rollout pace. They commonly rely on older patterns like:

• Basic Authentication in IIS (simple, but not MFA-aware by itself)
• Windows Authentication for corporate network identities (great for intranet scenarios, but tricky when access expands outside the network)
• Custom login forms tied to legacy frameworks or vendor code you don’t want to touch

So MFA gets stuck behind hard questions:

• “Do we refactor auth?”
• “Do we change the login flow?”
• “Will we break users?”
• “Can we do this before the next audit / incident / deadline?”

The Usual MFA Approach: An “App Project” (Not a Security Rollout)

Traditional ways to add MFA typically require some combination of:

• modifying the app’s authentication logic
• upgrading frameworks or middleware
• re-architecting identity and session handling
• building or reworking reverse proxy layers and load balancers

Even if you can do all of that, it takes time—and time is exactly what security teams don’t have when an IIS login page is exposed beyond the network.

The Datawiza Way: MFA Added at the Access Layer (DNS Cutover)

Instead of changing your IIS application, Datawiza enforces MFA at the access layer—in front of IIS—so you can keep the app untouched while upgrading authentication.

Think “Cloudflare-style” simplicity for authentication:

• users keep the same URL
• you update DNS to route traffic through Datawiza
• Datawiza enforces MFA/2FA policies
• your IIS app continues to work normally

Your IIS MFA options, compared

There are a few realistic ways to add MFA to IIS applications. The right choice depends on how much application change you can tolerate, whether you already standardize on an identity provider, and how fast the control needs to be in place.

• Microsoft Entra App Proxy: a good fit when you are all-in on Entra ID and need Microsoft pre-authentication for published web apps. If you need multi-IdP flexibility, app-specific policy, or a simpler alternative pattern, compare it with Datawiza Access Proxy.
• In-app IIS modules: useful when the app team can install and maintain server-side components. Duo's IIS module is a strong option for organizations standardized on Duo, and Datawiza can also use Duo as the IdP in front of IIS when a proxy deployment is preferred.
• AD FS and Web Application Proxy: familiar in older Microsoft environments, but often part of infrastructure teams' retirement plans rather than a platform they want to expand.
• Access proxy at the edge: the Datawiza approach. Put a purpose-built access layer in front of IIS, route traffic through it, and enforce MFA without modifying IIS code, login pages, or application servers.

What about Windows Authentication (IWA)?

IIS authentication mode matters. Forms-based or custom application login can use either Datawiza built-in MFA or IdP mode. Basic Authentication can follow the same access-layer pattern. Windows Integrated Authentication is different because IIS expects Kerberos or Windows authentication rather than a normal username/password form.

For Windows-authenticated IIS apps, Datawiza supports Kerberos Constrained Delegation (KCD). In that pattern, the user completes SSO and MFA with the IdP, and the proxy translates the approved session into a Kerberos-authenticated request to IIS. Microsoft Entra ID, Okta, Ping, or Duo can remain the MFA authority, while IIS continues to receive the Windows-authenticated request it expects.

For the configuration pattern, see the Datawiza documentation on Kerberos settings for Windows-authenticated applications.

How It Works (End-User Flow)

From a user perspective, nothing “new” shows up—just a safer login.

1. User goes to the same IIS app URL (no retraining, no new bookmarks).
2. DNS routes the request through Datawiza, which fronts the app as a hosted SaaS service.
3. The user enters username/password as usual.
4. Your IIS app (or your existing auth system) continues to validate credentials as it does today—no code changes required.
5. Datawiza initiates a step-up check and prompts for MFA/2FA based on your policy.
6. After MFA succeeds, Datawiza forwards the authenticated session to the IIS app, and the user continues normally—now with stronger security enforced at the edge.

If you’re familiar with reverse proxies: this is the same “front door” concept many teams implement with IIS URL Rewrite + ARR—but delivered as a purpose-built access layer for MFA instead of a DIY infrastructure project.

Hosted SaaS by Default (No Infrastructure Changes)

For most teams, the fastest rollout is Datawiza Hosted SaaS:

• no gateway appliances to manage
• no new servers to provision
• no load balancer redesign
• no complex migration plan

You route your application hostname through Datawiza via DNS and turn on MFA policies.

On-Prem Option Available (When You Need It)

Some organizations have requirements like data residency, segmentation, or regulatory constraints. Datawiza supports on-prem / customer-managed deployments when preferred—while keeping the same MFA-in-front model.

MFA Methods You Can Enforce

Datawiza supports two MFA modes for IIS applications, depending on whether you want to use an identity provider or keep the existing application login as-is.

• Built-in MFA, no IdP required: users keep signing in with the existing IIS or application login. After that login succeeds, Datawiza enforces an MFA challenge before the user can access the application. This mode is useful when you need fast MFA remediation without an identity migration.
• Identity provider MFA: Datawiza intercepts users before the IIS login page and redirects them to Microsoft Entra ID, Okta, Ping, Duo, or another IdP. The IdP can enforce its full method set, such as push, FIDO2/passkeys, number matching, and conditional access or risk-based policy.
• Policy control: apply MFA by hostname, app, group, path, or rollout stage, so one IIS app can be piloted before the pattern expands to the rest of the environment.

For broader implementation context, see MFA for web applications and adding MFA to legacy apps without code changes.

A Practical Rollout Plan for IIS Apps

Here’s a simple way to deploy safely and quickly:

1) Start with one IIS hostname

Pick the highest-risk IIS app—typically anything reachable outside your network (customer portal, partner access, vendor site, admin login).

2) Pilot without disruption

• Validate the login flow end-to-end
• Confirm session behavior and redirects
• Apply MFA policy to a pilot group first (optional)

3) DNS cutover

• Lower DNS TTL ahead of time (optional best practice)
• Update DNS to route the hostname through Datawiza
• Monitor authentication success rate and user experience

4) Expand coverage

Once the pattern is proven, extend the same MFA policy model to additional IIS apps so MFA becomes consistent, repeatable, and centralized.

Compliance reasons IIS apps come into scope

IIS applications often sit in the awkward middle of compliance programs: important enough to be in scope, but too old or too customized to add MFA natively. That is why access-layer MFA becomes a practical remediation path.

• Cyber insurance: carrier questionnaires commonly ask whether MFA is enforced for remote access, privileged access, and critical applications. See the cyber insurance MFA requirements guide.
• PCI DSS: IIS payment portals and admin tools can fall into cardholder data environment access-control testing. See the PCI DSS MFA requirements guide.
• HIPAA: healthcare portals and internal systems that handle electronic protected health information need stronger access safeguards. See HIPAA MFA guidance.
• CJIS: justice and public-safety systems may need phishing-resistant or policy-aligned MFA for controlled access. See the CJIS MFA requirements guide.
• SOX ITGC: IIS applications that feed or administer financial systems can appear in ITGC access-control testing. See SOX and ITGC access controls.

FAQ

Do I need to change my IIS application code?

No. Datawiza enforces MFA/2FA at the access layer, so the application can remain unchanged.

Do users need a new URL?

No. Users keep the same URL—Datawiza is introduced through a DNS update.

Is this only for “public” websites?

No. The model works for any IIS app reachable by users—customer/partner portals, vendor access, or internal apps published externally. (The key is: if users can reach the login page, Datawiza can enforce MFA in front of it.)

Does IIS support MFA natively?

Not by itself. IIS provides authentication mechanisms such as Basic Authentication and Windows Authentication, but MFA usually requires AD FS-era infrastructure, an in-app module, an identity provider integration, or an access layer in front of the application.

Can I add MFA to an IIS app that uses Windows Authentication?

Yes. For Windows Integrated Authentication, Datawiza can use Kerberos Constrained Delegation so the user completes IdP SSO and MFA, and the proxy performs the Kerberos-authenticated request to IIS.

Can I use Duo, Entra ID, or Okta MFA with IIS?

Yes. In IdP mode, Datawiza redirects users to Microsoft Entra ID, Okta, Duo, Ping, or another identity provider before application access. The IdP enforces its MFA policy, and Datawiza forwards approved traffic to the IIS application.

Add MFA to IIS—Without Turning It Into a Project

If you need MFA for an IIS app but don’t want to rewrite authentication or risk breaking production, Datawiza is built for speed: DNS cutover, enforce MFA at the edge, keep the app unchanged, and expand from there.

Book a demo to see how Datawiza can add MFA/2FA to your IIS app with a simple DNS update.