Skip to content

Designing MFA policies for multi-tenant applications

MFA becomes harder to manage when every tenant has the same login policy on paper but a different risk profile in practice. One customer may require MFA for every user because the application contains regulated data....

Security guide6 min readmarc-mueller
Back to blog

MFA becomes harder to manage when every tenant has the same login policy on paper but a different risk profile in practice.

One customer may require MFA for every user because the application contains regulated data. Another may rely on its corporate identity provider to perform the extra challenge before federation. A third may want to start with administrators, then expand the requirement after a support-ready rollout. If the SaaS application handles those differences with code branches, authentication policy becomes scattered across the product.

The cleaner boundary is the identity layer. Applications should ask for a user to be authenticated and then make their own authorization decisions. ProAuth should hold the tenant-specific authentication policy: which tenant is affected, which client application is affected, which factor classes are allowed, and which users need a different onboarding or recovery path.

MFA policy varies by tenant

Multi-tenant SaaS teams often talk about “turning on MFA” as if it were one switch. For enterprise customers, it is usually a policy decision with several dimensions:

  • the sensitivity of the tenant’s data and workflows
  • whether users authenticate through a federated identity provider or a ProAuth-managed user store
  • whether the customer’s own identity provider already enforces MFA
  • which client applications expose administrative or high-risk functions
  • what support process exists for lost phones, changed email addresses, or unavailable authenticators

Those questions should not force application code to know customer-specific authentication rules. ProAuth can be configured at runtime through the Admin Application, Management API, or CLI, which makes MFA policy part of tenant onboarding and operations rather than part of an application deployment.

That runtime boundary matters during rollout. A stricter policy should be tested with a small group, documented with the customer’s administrators, and expanded when recovery and support paths are ready.

Factor classes are not all equal

For a durable design discussion, it is useful to speak about broad factor classes instead of treating every implementation as interchangeable.

Email verification is often the easiest factor to introduce because most users already have a verified address in the identity profile. It is also tied to the security of the user’s mailbox, so it should be treated as a pragmatic baseline rather than the strongest assurance available.

SMS or phone-based codes can be useful when mobile numbers are already part of the user profile, but they bring their own operational questions: number ownership, number changes, telecom delivery, and support for users without reliable reception.

TOTP is a common authenticator-app pattern. The algorithm is standardized in RFC 6238, and it avoids a dependency on email or SMS delivery during every login. It does require enrollment, recovery, and clear user guidance.

Federated IdP MFA is a different case. If a customer already enforces MFA in its corporate identity provider, the SaaS team should decide explicitly whether that upstream assurance is sufficient for the application. That decision belongs in the tenant’s security design. It should not be an undocumented assumption hidden in a login integration.

For security teams, the important point is to compare factor strength, recovery, and authenticator lifecycle risks with the same vocabulary. Those references do not replace the customer’s policy, but they help keep the tradeoffs explicit.

Put the policy hierarchy in writing

MFA policy needs a hierarchy because tenants, applications, and users do not all carry the same risk.

ProAuth’s MFA configuration can be associated with tenants, identity provider instances, client applications, and ProAuth users. That lets a SaaS team express a broad tenant rule and then narrow it where the product surface requires a different decision.

flowchart TD
    Tenant["Tenant security policy<br/>customer baseline"]
    Client["Client application policy<br/>portal, admin app, APIs"]
    IdP["Identity provider context<br/>federated or managed users"]
    Exceptions["User or rollout exceptions<br/>pilot users, administrators, recovery"]
    App["SaaS application<br/>authorization and business rules"]

    Tenant --> Client
    Tenant --> IdP
    Client --> Exceptions
    IdP --> Exceptions
    Exceptions --> App

The hierarchy should answer three practical questions.

First, what is the tenant baseline? Some tenants may require MFA for all interactive users. Others may require it only for sensitive applications. The baseline should be set where the customer’s policy is defined, not inside each product team.

Second, which client applications need stricter rules? An administrative application, a support portal, and a low-risk self-service view may not need the same policy. Client application scope keeps that difference explicit.

Third, which users need special handling during rollout or recovery? ProAuth users can be configured for specific MFA instances, and users can inherit MFA configuration from the client application, tenant, and identity provider instance. If the rollout process also uses customer groups, document where that group membership is evaluated and how it affects enrollment, exceptions, and support. Do not let the exception process become an informal spreadsheet outside the identity operating model.

Recovery is part of the policy

MFA rollout fails when recovery is treated as an afterthought.

Before enabling stricter MFA for a tenant, decide who can help a user regain access, what evidence is required, and how the event is recorded. Recovery codes can be useful, but they need lifecycle rules: when they are generated, how they are stored by the user, when they are invalidated, and how redeemed codes are audited.

The same applies to factor changes. If a user’s phone number changes, if an email address is updated, or if a TOTP authenticator is lost, the recovery flow must be more secure than the normal login flow it replaces. Otherwise MFA becomes a strong front door with a weak support desk beside it.

For SaaS teams, the operational questions are usually as important as the factor choice:

  • Can the customer’s tenant administrator see who is enrolled?
  • Can support distinguish a delivery problem from a lost-factor problem?
  • Is there an audit trail for recovery and reset actions?
  • Does the rollout plan cover users who have not logged in recently?
  • Are higher-risk roles tested before the policy is enforced broadly?

Roll out in stages

The safest MFA rollout is staged and observable.

Start with a policy model, not a configuration screen. Define the tenant baseline, the client applications in scope, the factor classes allowed, and the recovery path. Then test with a small set of users who can report enrollment problems quickly. Expand by tenant, application, or user cohort once support has seen the first real cases.

This is especially important in federated SaaS environments. A customer may change its upstream identity provider policy without changing anything in the SaaS application. The SaaS team should still know whether ProAuth is relying on upstream MFA, enforcing an additional local challenge, or applying a different rule for a specific client application.

Runtime configuration makes this manageable. The application does not need a release because one tenant is ready for a stricter policy and another is not. The policy can move at the speed of customer onboarding and security approval.

Questions to ask before enabling stricter MFA

Before changing a tenant’s MFA policy, ask the questions that usually surface after the first locked-out user:

  • Which users and client applications are in scope on day one?
  • Which factor classes are allowed for this tenant?
  • Does the customer’s upstream identity provider already enforce MFA?
  • If upstream MFA is trusted, how is that decision documented?
  • Which administrators can perform recovery or reset actions?
  • What happens when a user loses access to their email, phone, or authenticator app?
  • How will support handle users who fail enrollment during rollout?
  • What audit evidence does the customer expect for policy changes and recovery events?
  • How will the policy be tested before it affects all users?

The goal is not to make every tenant identical. The goal is to make each tenant’s MFA policy explicit, configurable, and supportable.

When MFA lives in the identity layer, SaaS applications stay focused on authorization and product behavior. ProAuth handles the authentication policy boundary, tenant by tenant and client application by client application, while the application continues to trust one identity provider and consume a stable token contract.

For configuration details, see the ProAuth documentation and the multi-factor authentication configuration section at docs.proauth.net/configuration/08-MultiFactorAuthentication/.