Conditional Access policies in multi-tenant regulated SaaS environments

Microsoft Entra Conditional Access remains the primary policy engine for enforcing Zero Trust decisions at authentication time. For operators of multi-tenant SaaS platforms that serve regulated customers, the challenge is to apply tenant-specific controls without allowing one customer’s policy to affect another.

Core signals and policy structure in 2026

A Conditional Access policy evaluates user, group, location, device state, application, sign-in risk, and session risk signals. In 2026 the platform added direct support for requiring Conditional Access re-authentication on Privileged Identity Management role activation and extended Global Secure Access clients to additional mobile platforms.

Common grant controls remain block, require multifactor authentication, require compliant device, require approved client app, and require password change. Session controls include sign-in frequency, persistent browser session, and application-enforced restrictions. Policies can be assigned to specific cloud apps or to authentication contexts that downstream applications can reference.

Per-tenant scoping without cross-tenant leakage

In a multi-tenant SaaS deployment the application typically appears as a single enterprise application registration or as a set of registrations under an external tenant model. Customer administrators and their users sign in through the platform’s OIDC or SAML endpoints.

Effective isolation requires that customer-specific groups or directory extensions drive policy assignment rather than broad “all users” grants. Security groups populated from each customer’s Entra tenant via SCIM or external identity synchronisation allow a policy to target only members of “TenantA-Admins” without affecting TenantB. Authentication context claims can carry tenant identifiers into Conditional Access decisions when the SaaS application itself performs step-up or additional checks for sensitive operations.

Location signals must account for the fact that the SaaS operator’s own infrastructure may sit in EU regions while customer users connect from their corporate networks. Named locations defined per customer, or dynamic groups based on the customer’s registered IP ranges, prevent a single global block list from disrupting legitimate access for other tenants.

Device compliance signals from Intune or equivalent MDM solutions are useful only when the customer organisation manages the endpoint. For unmanaged devices used by customer staff, session controls and risk-based policies become the primary levers.

Integration with DORA, NIS2 and ISO controls

DORA Article 28 and the associated ICT risk management framework require least-privilege access and monitoring of administrative actions on systems that support critical functions. A Conditional Access policy that blocks legacy authentication and requires compliant devices or managed sessions for tenant administrators produces logs that can be mapped to those requirements.

NIS2 transposed rules on risk management and incident notification similarly benefit from explicit verification at every sign-in rather than network perimeter assumptions. The “verify explicitly” principle aligns directly with the access control statements in ISO 27001:2022 organisational controls 5.15 through 5.18 and the technological authentication controls.

Operators that expose privileged functions inside the SaaS (for example, tenant-level data export or policy changes) can use authentication context to trigger additional Conditional Access requirements only for those actions, keeping day-to-day user experience for ordinary customer staff unchanged.

Common gaps observed in SaaS deployments

Many platforms still rely on a single “all customer admins” Conditional Access policy that grants broad access once MFA is satisfied. This policy cannot express differences in risk tolerance between a bank customer and a smaller insurance undertaking. It also makes it difficult to apply customer-specific named locations or device requirements.

Another frequent gap is the absence of policies that cover service principals and workload identities used by the customer’s own automation. These identities often bypass the interactive Conditional Access path yet still require equivalent controls under the customer’s own DORA or NIS2 programme.

Reviewing Conditional Access policies against the actual tenant boundary model, rather than against a generic enterprise template, surfaces these gaps before an auditor or supervisor does.

See the identity and access modules for platform capabilities that integrate with external Entra tenants and Conditional Access signals.