How to Add Two-Factor Authentication to Outlook Web App (OWA)

Posted By Maxim Oliynyk on Jul 9, 2020 | 4 comments

Quick Answer

There are two architecturally different ways to add multi-factor authentication (MFA) to Outlook Web App (OWA): protect the OWA and Exchange Admin Center (EAC) login directly with a dedicated component, or add MFA at the Active Directory level so it covers OWA along with every other AD-connected service automatically. Protectimus offers both — the Protectimus OWA component for the first approach, and Protectimus DSPA (Dynamic Strong Password Authentication) for the second. Which one fits depends on whether you want MFA scoped tightly to webmail and admin access, or applied broadly across your AD-connected infrastructure in one step.

Why OWA Needs MFA in the First Place

Outlook Web App exists so people can reach corporate mail from a browser, on any device, from anywhere with an internet connection. That convenience is also the underlying security problem: a compromised username and password is, on its own, sufficient to log in. There’s no network perimeter to cross first, no VPN client to authenticate against — just a login form facing the public internet.

Credential-based attacks remain the dominant way organizations get breached. The 2025 Verizon Data Breach Investigations Report found stolen or abused credentials among the leading initial access vectors, with the human element — phishing, social engineering, simple mistakes — present in roughly six out of ten breaches analyzed. Business Email Compromise, which can involve compromised corporate email accounts, saw more than $2.77 billion transferred as part of BEC scams in 2024, according to FBI IC3 data cited in the report. Microsoft’s 2025 Digital Defense Report adds a more encouraging number to that picture: modern MFA blocks over 99% of identity-based attacks, including cases where the attacker already holds a valid username and password.

Put together, those numbers explain why OWA specifically — rather than “the network” in general — is worth treating as its own MFA project. A password alone is not enough to keep that login form honest, and MFA is the control that has consistently proven effective against exactly the attack pattern OWA is exposed to.

Does OWA Support MFA Natively?

Microsoft Exchange Server doesn’t ship with built-in multi-factor authentication for on-premises OWA and EAC logins — unlike Exchange Online, which can rely on Entra ID conditional access. For on-premises or hybrid deployments, MFA has to be added through a dedicated component or an authentication layer in front of the login process.

We developed two products for Outlook OWA 2FA. The first product is Protectimus OWA, developed specifically for Office OWA integration. The second solution is Protectimus DSPA which adds 2FA directly to the repository (Active Directory, Lightweight Directory Access Protocol, databases) and thus adds MFA to everything linked to the business AD, LDAP, etc.

Today we will give you an in depth look into both methods. We will describe their work, show you how to implement each solution and list the tokens that support them.

Method 1: Protect OWA and EAC Directly

The first approach adds a second authentication factor to the OWA and Exchange Admin Center login screens specifically, without touching how any other AD-connected system authenticates. In Protectimus’s product line, this is handled by the Protectimus OWA component, a Windows installer deployed on the Exchange Client Access role.

After installation, a user reaches the familiar OWA login page, enters their normal Active Directory username and password, and is then prompted for a one-time password from whichever method the organization has enabled — an authenticator app, a hardware token, SMS, email, a chatbot, or a push notification. The EAC login can be protected the same way, either alongside OWA or on its own.

This method is a good fit when the goal is narrow: get MFA in front of webmail and admin access without immediately changing how Winlogon, RDP, VPN, or anything else tied to Active Directory behaves. It also supports scoping to a single AD group, so a pilot rollout doesn’t have to touch every mailbox at once.

This product for OWA two-factor authentication runs either in cloud, or locally. You get the full set of advanced features — geo and time filters, IP filters, user-environment analysis. Every Protectimus token works with this plugin, and it supports third-party tokens as well. During setup, two-factor authentication can be scoped to a single Active Directory group instead of enabled for everyone at once.

Here’s a video to illustrate the above steps:

Method 2. Protect Authentication at the Directory Level

The second approach doesn’t target OWA specifically at all — it adds MFA to authentication at the Active Directory level itself. In Protectimus’s product line, this is Protectimus DSPA (Dynamic Strong Password Authentication).

DSPA works by replacing conventional static AD passwords with dynamic passwords based on the TOTP algorithm. These dynamic passwords change automatically at an interval set by the administrator, always a multiple of 30 seconds. Because this happens at the directory level, every service that authenticates against AD — OWA included, along with Winlogon, RDP, ADFS, and others — inherits the same protection without being configured individually.

The trade-off is scope. DSPA doesn’t ask “should OWA require MFA?” — it makes the question moot by changing what a valid AD password looks like everywhere at once. It typically fits organizations that were already planning to extend MFA past webmail into their broader AD-connected environment.

DSPA is available exclusively through the Protectimus On-Premise Platform; it is not offered as part of the cloud service, since it requires direct integration with an on-premises Active Directory. DSPA needs the OTP lifetime to be adjustable, which narrows the practical choice toward Protectimus SMART (the authenticator app) or Protectimus BOT (chatbot-delivered OTP).

OWA Component vs. Directory-Level MFA

Which OWA MFA Deployment Option Should You Choose?

Choose the OWA component when…

You need to protect webmail and admin access quickly, without a broader Active Directory MFA rollout attached to the same project

•  Different departments or applications have different authentication requirements, and you don’t want one policy applied everywhere at once

•  You want the option of a cloud-hosted MFA service rather than running an authentication server on-premises

•  You’re piloting MFA on a single AD group before deciding whether to expand it

 Choose directory-level MFA (DSPA) when…

•  You already know you want MFA across everything tied to Active Directory — OWA, Winlogon, RDP, ADFS — not just webmail

•  Running one authentication mechanism at the directory level fits how your infrastructure team prefers to manage access

•  Your environment is on-premises and running the Protectimus On-Premise Platform, since DSPA isn’t available through the cloud service

•  Your users can standardize on the Protectimus SMART app or BOT chatbot for token delivery

Neither approach is strictly “more secure” than the other in isolation — both add a genuine second authentication factor. The real question is scope: whether MFA should apply narrowly to OWA and EAC today, or broadly to everything AD-connected from the start.

What Each Method Looks Like in Practice

With the OWA component, setup involves registering with Protectimus Cloud MFA or installing the On-Premise Platform, creating a resource, adding users and tokens (or turning on self-service), then running the OWA installer on the Exchange server and selecting which modules — OWA, EAC, or both — to protect. The whole process is typically finished in around 15 minutes once prerequisites like a trusted SSL certificate for the on-prem platform are in place.

With DSPA, the dynamic-password mechanism is configured once at the directory level, after which OWA, alongside every other AD-connected system, automatically uses the TOTP-based dynamic password. There’s no separate OWA-specific installation step, because the protection isn’t applied per application.

Neither summary here is a substitute for the full setup instructions. If you’ve decided the OWA component is the right fit, the Protectimus OWA integration guide has the exact steps, prerequisites, and configuration parameters. For what the component supports in more detail, see the Protectimus OWA solution page.

FAQ

How do I add MFA to Outlook Web App? You can add a second authentication factor either directly to the OWA and EAC login (the Protectimus OWA component) or at the Active Directory level so it covers OWA automatically along with everything else tied to AD (Protectimus DSPA).

Does OWA support MFA out of the box? Not for on-premises Exchange Server deployments — native OWA and EAC logins don’t include built-in MFA the way Exchange Online can rely on Entra ID Conditional Access. A dedicated component or directory-level integration is needed.

What’s the difference between an OWA MFA plugin and Active Directory-level MFA? An OWA plugin, like the Protectimus OWA component, protects the OWA and EAC login screens specifically. Directory-level MFA, like Protectimus DSPA, changes authentication at the AD layer itself, so the protection extends automatically to every AD-connected service, not just OWA.

How can I protect on-premises Exchange OWA specifically, without changing anything else? The OWA component is the narrower option — it’s scoped to OWA and EAC and doesn’t touch how other AD-connected systems authenticate, whereas directory-level MFA affects everything tied to AD by design.

Should MFA protect only OWA, or the whole AD-connected infrastructure? That depends on your rollout plan. If OWA and EAC are the immediate priority and other systems will be addressed separately, the OWA component keeps the change contained. If you already intend to cover Winlogon, RDP, ADFS, and OWA together, directory-level MFA does that in one step.

Conclusions

Adding MFA to Outlook Web App isn’t a single decision — it’s a choice between two different architectures, each with a different footprint. The Protectimus OWA component keeps the change scoped to webmail and admin access. Protectimus DSPA takes a wider approach and protects everything authenticating against Active Directory, OWA included, from one place. Once you know which scope fits your organization, the OWA solution page and integration guide cover what comes next.

Read also:

• Two-Factor Authentication Solutions Comparison: Google Authenticator vs. Protectimus
• Two-factor authentication for Windows 7, 8, 10
• Hardware Tokens for Azure MFA
• Office 365 MFA Hardware Token
• Duo Security vs Protectimus
• 2FA Chatbots vs. SMS Authentication
• TOTP Tokens Protectimus Slim NFC: FAQ
• Best Protectimus MFA Features for Financial Services Cybersecurity
• Electronic Visit Verification with Hardware Tokens