· Yair Knijn
Managing Conditional Access across multiple tenants
Microsoft Entra Conditional Access is designed around a single tenant. Every policy lives inside one directory, evaluates that directory's users and apps, and knows nothing about the tenant next door. The moment you are responsible for more than one tenant — as a managed service provider with fifty customers, as an enterprise that grew a second tenant through acquisition, or as a SaaS operator whose customers each bring their own Entra directory — the question changes from "is this policy correct" to "is this policy correct everywhere, still, today".
There is no native cross-tenant policy synchronisation. Nothing in the platform pushes a Conditional Access change from tenant A to tenant B, and nothing warns you when the two drift apart. Consistency is something you have to build.
Where multi-tenant Conditional Access management breaks
The failure pattern is almost always the same. A baseline is deployed everywhere in a project phase — MFA for all users, legacy authentication blocked, named locations for the corporate ranges. Then reality arrives one tenant at a time: an executive exception here, an emergency disablement during an incident there, a contractor carve-out that was supposed to be temporary. Eighteen months later no two tenants have the same policy set, and nobody can say which differences are deliberate.
Drift is worse than absence, because a dashboard full of green "policy exists" checkmarks hides the fact that the policy's exclusion group quietly gained forty members in one tenant.
The management approaches that exist today
For MSPs operating customer tenants under granular delegated admin privileges (GDAP), Microsoft 365 Lighthouse baselines are the first-party answer: a standard configuration, including identity-protection deployment tasks, deployed and tracked across managed tenants from one console. It covers the common denominator well; it does not cover tenant-specific policies or tenants outside the Lighthouse relationship.
The second approach is policy as code. Conditional Access policies are fully addressable through the Microsoft Graph API, which means the policy set can live in a repository and be applied to every tenant from a pipeline. Open-source tooling such as Microsoft365DSC formalises this into declared configuration with drift reporting. The cost is real engineering ownership: someone maintains the pipeline, handles per-tenant parameters (named locations differ, exclusion groups differ), and reviews changes like any other code.
The third approach — the one most organisations actually live with — is periodic manual review. It fails quietly, for the reasons above.
What a defensible setup looks like
Whichever deployment mechanism you use, four practices separate a managed estate from a hopeful one. First, take versioned backups of every tenant's Conditional Access configuration before any change, so that "what did this policy look like in March" is a lookup, not an archaeology project. Second, detect drift continuously: compare each tenant's live policy set against its declared baseline and alert on divergence, including membership changes in exclusion groups. Third, keep per-tenant break-glass accounts excluded from all policies, documented, and tested — a misapplied baseline that locks out fifty tenants at once is the multi-tenant version of a single-tenant mistake. Fourth, roll changes out through report-only mode per tenant before enforcement, because identical policy text does not mean identical impact in tenants with different device management and network shapes.
Evidence, not assertions
Regulated customers increasingly ask their providers to demonstrate — not assert — that access controls are consistent across the environments that serve them. A register of policy versions per tenant, drift alerts with timestamps, and change history mapped to tickets turns that conversation into an export instead of a scramble. We covered the single-tenant policy design side in Conditional Access policies in multi-tenant regulated SaaS environments; the operational side is keeping those designs true across every tenant you answer for.
The Spot Suite identity and access modules include Entra configuration backup and drift detection built for exactly this operating model.