*The opening scenario below is a composite, drawn from MSP onboarding interviews and incident-response patterns we have seen across South African manufacturing and professional-services customers in late 2025 and early 2026. Specifics are illustrative.*
A South African manufacturing group with sixteen Entra ID tenants under one MSP needed to roll back a Conditional Access policy change last December. The change had been pushed simultaneously to all sixteen tenants the previous Friday by an outside consultant who had been engaged for a month-long modernisation project. By Monday morning, three of the tenants had locked their executive teams out of M365 because the policy required a hardware token they did not yet have.
The MSP's first instinct was to compare the policy state across the affected tenants and re-enter the prior values from the Entra audit log. The audit log surfaces each policy change with a side-by-side modified-properties view, which is genuinely useful for understanding what happened, but it does not offer a one-click rollback. The consultant had made eleven changes over the weekend. Reconstructing the prior state required walking each change individually, transcribing the prior values from the audit record, and re-applying them via Graph API or the portal. With three tenants in immediate distress and thirteen more that needed verification, the MSP's senior engineer spent most of Monday morning on this work.
The MSP got the executives back in by 17:00 on Monday. The cost in operational time, customer-facing damage, and brand consequences was significant. The operational gap was not in any single Microsoft product — it was in the absence of a multi-tenant restoration story above what native tools provide. This is what an MSP-grade Entra protection model has to address.
This article walks through that model, with explicit reference to what Microsoft now ships natively and what still sits outside that scope.
What Microsoft's native Entra Backup and Recovery actually covers
Microsoft Entra Backup and Recovery entered public preview on 19 March 2026 as part of the Microsoft 365 Backup family. It is well-engineered for what it covers, and it is genuinely useful as a baseline. The product is still in preview at the time of writing, which means scope is a moving target — what is true in May 2026 may expand by the next product update, and any analysis of "what's missing" needs to be re-checked against current Microsoft Learn documentation as the preview progresses.
What the preview ships today, per Microsoft's published scope documentation, is a five-day rolling restore window covering: users, groups (with dynamic group objects supported, though dynamic-group rule expressions and group-ownership changes are out of scope), applications, service principals, **Conditional Access policies**, **named locations**, and **authentication method policies**. The policy coverage is broader than many practitioners assume, and it is a genuine improvement on what was available before March 2026. A buyer evaluating Entra protection in 2026 should know that Microsoft now natively covers a useful subset of the configuration surface, not just directory objects.
The five-day retention window is a fixed parameter in preview and cannot be extended by configuration. For operational use cases where the misconfiguration is detected within a working week, the window is sufficient. For misconfigurations that are detected later — a quiet drift that is only noticed at the next audit cycle, or a compromise whose blast radius is only mapped weeks after — the five-day cap is consequential.
What the preview does **not** currently cover, again per Microsoft's published scope, is everything else in Entra's tenant-state surface: sign-in risk policies, Identity Protection policies, cross-tenant access settings (including B2B and inbound/outbound configuration), B2B collaboration settings, custom security attributes and assignments, access review configurations, role definitions and assignments, PIM (Privileged Identity Management) eligibility schedules and approvals, and application registration secrets and certificate chains. On-premises-synced object changes other than group memberships appear in Microsoft's difference reports but are excluded from the recovery flow. B2C and External ID tenants are not currently in scope.
This list matters because most of the operational scenarios that send an Entra tenant into recovery are not "a user got deleted" — they are "the configuration changed in a way nobody intended". Configuration scope, the five-day window, and the absence of cross-tenant operations together define the ceiling of what native protection delivers today.
What an Entra restoration actually requires
A defensible Entra protection product has to address four operational scenarios. Native preview addresses two of them well, one partially, and one not at all.
**Scenario 1 — Accidental directory deletion.** A user, group, or service principal is deleted by mistake. Native preview is strong here within the five-day window, including the relationship-aware restoration that re-attaches group memberships and FK references.
**Scenario 2 — Policy rollback within five days, single tenant.** A Conditional Access, named-location, or authentication-method change has produced unintended impact and the administrator wants to revert. Native preview supports this provided the change is within the retention window. Single-tenant rollback is feasible and operationally clean.
**Scenario 3 — Compromise recovery or extended-window rollback.** An attacker has gained administrative access and made changes — added persistence, modified Conditional Access exclusions, added service principals — or a misconfiguration is detected days after the five-day window has passed. Recovery requires identifying every malicious or unintended change and reverting it without disturbing legitimate changes made in the same period. Native preview handles a portion of this but is bounded by the five-day window and by its current scope.
**Scenario 4 — Cross-tenant policy operations.** An MSP wants to deploy a policy structure across multiple tenants with adjustments per tenant, or roll back a change across multiple tenants simultaneously, or simulate the impact of a proposed change against the live sign-in history of every targeted user across every targeted tenant. Native tools do not address this scenario at all in 2026 — Microsoft's own What-If tool is documented as a single-tenant simulator, and cross-tenant deployment is a customer-tooling responsibility. This is the scenario that defines whether an MSP at scale can operate Entra at all.
A four-tier architecture addresses all four. Each tier builds on the prior; together they constitute the operational surface that an MSP managing fifteen Entra tenants needs to deliver competent identity protection.
Tier 1 — ID Backup: extending the surface and the horizon
The first tier is comprehensive backup with a long retention horizon. Where native preview covers a useful subset of policies on a five-day rolling window, the platform covers directory objects plus the configuration surface that native does not currently include — sign-in risk policies, Identity Protection policies, cross-tenant access settings, B2B collaboration settings, custom security attributes, access review configurations, role definitions and assignments, PIM eligibility schedules, application registration secrets and certificates, and service principal grants — with retention bands ranging from 30 days for high-frequency operational restores to seven years for evidence-grade retention.
The point-in-time restore is granular. A single Conditional Access policy can be restored to a state from three weeks ago without disturbing the other policies. A user's role assignments can be restored without touching the user's group memberships. A service principal's permission grants can be restored without re-deploying the application registration.
The relationship awareness is what makes the restoration usable. Entra objects have dense interdependencies — a Conditional Access policy references named locations, role groups, and authentication strengths; a user has group memberships, role assignments, license assignments; an application registration has redirect URIs, API permissions, and a chain of grants. A naive restoration of one object often produces a state that is internally inconsistent. The platform's restore engine resolves the dependency graph, identifies orphan references, and presents the operator with a pre-flight that surfaces what will be inconsistent after the restore.
For the manufacturing-group scenario from the start of the article, Tier 1 alone would have covered the operational gap. The Conditional Access policies for the sixteen tenants existed in the platform's backup at hourly granularity; the rollback for the changes that fell within five days could have been done via either native preview or platform Tier 1; the changes outside that window were within Tier 1's longer retention. The total recovery time would have been a fraction of what the manual reconstruction took.
Tier 2 — ID Intelligence: knowing what changed and why
Backup is necessary but not sufficient. The next question after "can I restore?" is "what changed, when, and by whom?" The answer requires drift detection.
Drift detection in Entra is harder than it sounds because the legitimate change rate is high. A typical mid-market tenant sees dozens of legitimate Conditional Access changes per month — new policies for new applications, scope adjustments for organisational changes, exception additions for specific edge cases, retirement of obsolete policies. A drift detector that alerts on every change drowns the administrator in noise. A detector that alerts only on "suspicious" changes has to define what suspicious means in a way that is robust to the diversity of legitimate change patterns.
The platform's approach is field-level diff against the tenant's history, with semantic categorisation of the change type. A policy modification that adds an exclusion is categorised differently from one that adds a control. An exclusion addition for a service principal is categorised differently from an exclusion addition for a user. Each category has its own alert threshold, calibrated against the tenant's historical change patterns.
The compliance scoring layer maps the tenant's current Entra configuration against published security baselines — CIS Microsoft 365 Foundations, NIST Cybersecurity Framework, POPIA, SOC 2, ISO 27001 — and produces a per-control score. A change that drops the compliance score below a configured threshold triggers an alert independent of the drift category. The combination of drift detection and compliance scoring catches the two failure modes that pure drift detection misses: small individual changes that aggregate to a significant compliance regression, and changes that are within the normal variance of the tenant's history but reduce its overall security posture.
Cross-tenant comparison is the third element of Tier 2. An MSP managing fifteen tenants can see, in one view, which tenants have which policies, which tenants are missing controls that comparable tenants have, and which tenants have configurations that diverge from the MSP's standard template. This is the analytical capability that makes the MSP scenario tractable — without it, every tenant is a one-off configuration to maintain in isolation.
A configuration error that produces an immediate operational outage gets fixed quickly because the impact is loud. A configuration drift that gradually erodes security posture is invisible until the breach. An organisation that does not detect drift over months will, on average, have a worse breach outcome than one that does — even if their incident response is otherwise identical. The cost of the missed signal compounds.
Tier 3 — ID Orchestration: simulating before deploying
The third tier addresses the scenario the MSP from the start of the article most needed: roll out a configuration change across multiple tenants safely, with the ability to preview the impact before commit.
The core capability is **Conditional Access What-If, applied across tenants and across users**. A proposed policy change is evaluated against the full sign-in history of every user in every targeted tenant. The output is a per-user, per-tenant table showing which sign-ins would have been blocked, allowed, or required additional MFA under the new policy. The simulation is run before the deployment is committed.
Microsoft's own What-If tool is documented in Microsoft Learn as a single-tenant simulator targeting one user, agent identity, or service principal at a time. It is excellent at what it does and is the foundation of any single-tenant policy validation. For an MSP managing fifteen tenants who wants to know what a proposed change would do across all fifteen, the single-tenant tool means fifteen separate runs, fifteen sets of outputs, and fifteen reconciliations. The cross-tenant variant collapses that into a single operation with a unified output table — same simulation primitive, applied at MSP scale.
The simulation surfaces the failure modes that hand-deployment misses. The executive team that lacked hardware tokens in the December scenario would have appeared in the cross-tenant What-If output as "would have been blocked on 8 of 9 sign-ins in the past 30 days." The MSP would have seen that line, paused the deployment for those tenants, and arranged the hardware tokens before pushing the change. The seven-hour outage would not have occurred.
The deployment engine itself has to handle the cross-tenant translation problem. A Conditional Access policy targets specific groups by GUID. The same logical group — for example, "Executives" — has a different GUID in every tenant. A policy authored against tenant A's GUIDs cannot be deployed unmodified to tenant B. The platform's deployment engine maintains a per-tenant GUID remapping table that translates the policy's logical references at deployment time. The same policy, authored once, is deployed correctly across fifteen tenants without manual editing.
Bulk operations across fifty-plus tenants are handled by the same engine. An MSP rolling out a phishing-resistant authentication strength to its entire customer book can author the policy once, see the cross-tenant What-If summary, and deploy with a single batch operation. The deployment is transactional per tenant, with rollback capability if the deployment surfaces unexpected effects.
Golden templates are the final element of Tier 3. An MSP can define a template for "standard SMB Entra hardening" or "regulated-industry hardening" or "remote-workforce hardening", parameterise it for tenant-specific values, and deploy the template to new tenants on onboarding. The template is itself a versioned object with its own audit chain, and template deployments are visible in the same drift detection layer that catches manual changes.
Tier 4 — ID Advanced: identity threat detection across tenants
The fourth tier is identity threat detection that goes beyond what Microsoft's native signals catch. Microsoft Entra ID Protection is excellent at the threats that Microsoft has visibility into — sign-ins from unusual locations, credentials in known leaked lists, atypical travel patterns. It is by construction limited in two ways: it sees one tenant at a time, and it sees only the signals Microsoft has access to.
Tier 4 adds a cross-tenant correlation layer and a set of detector types that complement Microsoft's signals.
The cross-tenant correlation looks for patterns that span an MSP's entire customer book. A credential-stuffing campaign that hits one tenant in isolation looks like a single high-volume sign-in attempt. The same campaign hitting fourteen of the MSP's fifteen tenants in the same hour, against accounts whose email addresses share a structural pattern, is a different signal — it indicates the attacker has the MSP's customer list and is running a coordinated attack. Microsoft cannot see this because Microsoft does not know which tenants belong to the same MSP.
The detector types include impossible-travel correlation across tenants (a user who appears in tenant A from Johannesburg and in tenant B from Bratislava in the same five-minute window), token-replay detection (sign-ins using session tokens that have been observed in multiple geographies), brute-force correlation (failed sign-in patterns that match a campaign signature), and break-glass account monitoring (any use of a tenant's emergency-access account, with cross-tenant alerting if the same actor uses break-glass in multiple tenants).
The integration with the email security consensus engine is the architectural payoff. When a user's identity risk is elevated by Tier 4, the email engine revokes auto-trust on the user's outbound traffic, and outbound messages from that user are re-scanned as if from an unknown sender. This closes the seam where a compromised account is the attacker's most valuable asset.
Microsoft's What-If tool is single-tenant by design and is excellent at that scope. An MSP managing fifteen tenants who wants to know what a proposed policy change would do across all fifteen has to run the What-If fifteen times, capture the outputs, and reconcile them manually. The cross-tenant What-If we built collapses that into a single operation with a unified output table. It is not a feature that exists for technical novelty — it exists because the manual process is slow enough that MSPs skip it, and the skip is what produces the seven-hour outages.
Why MSPs in particular need this
The four-tier architecture is useful to any organisation managing Entra. It is essential for MSPs.
A direct enterprise customer has one Entra tenant, one set of policies, one cohort of users. Their operational complexity scales with the size of their tenant, but their architectural complexity is bounded by having one tenant. Native Entra tools and a basic backup product can cover them adequately for many use cases.
An MSP managing fifteen tenants does not just have fifteen times the operational complexity. They have a categorically different architectural problem. Each tenant has its own GUIDs, its own user population, its own policy history, its own change cadence. A change that is safe in tenant A is potentially unsafe in tenant B. A pattern that is normal in one tenant is anomalous in another. A configuration template that fits twelve tenants needs adjustments for the other three.
Tools designed for single-tenant use do not scale to fifteen tenants by being run fifteen times. They scale by being augmented with cross-tenant abstractions — GUID remapping, cross-tenant What-If, cross-tenant drift comparison, cross-tenant threat correlation. These abstractions are the difference between an MSP that can profitably manage Entra at scale and one that cannot.
The economics here are straightforward. An MSP that spends three hours per tenant per month on Entra operations is spending forty-five hours per month for fifteen tenants. The same MSP using cross-tenant tooling spends one hour of cross-tenant work plus one hour per tenant of tenant-specific work — sixteen hours total. The thirty-hour difference, at SA SOC analyst loaded rates, pays for the platform several times over.
How it integrates with the rest of the stack
The Entra protection tiers do not run in isolation. The signal flows that connect them to the rest of the platform are what make the architecture cohesive.
The audit chain is shared. Every Entra operation — backup, restore, drift detection, policy deployment, threat detection — produces an entry in the same SHA-256-chained audit ledger that records backup events, threat verdicts, and retention actions. The chain is verifiable end-to-end across product boundaries, which means an investigator looking at a tenant's Entra history can correlate it with the email events of the same time window without crossing audit-system boundaries.
The threat correlation is bidirectional. Identity risk signals from Tier 4 elevate the email engine's consensus weights. Email-side BEC graph signals — a sender's communication pattern looking unusual — feed back into Tier 4's risk model for the same user. A user whose email pattern is anomalous and whose identity provider has flagged elevated risk is treated more strictly by both engines than either signal alone would justify.
The retention engine spans both. Entra backup data is subject to the same retention policy framework, with the same legal-hold support, the same destruction certificate generation, and the same POPIA-aligned templates as M365 backup data. A legal hold placed on a custodian for a litigation matter automatically extends to that custodian's Entra audit history, role assignments, and authentication events.
The MSP cockpit is unified. The Partner Portal shows Entra status alongside backup status, threat verdicts, billing, and ticketing — one tenant view, one alert queue, one set of credentials. An analyst working an Entra incident does not switch to a different tool to check whether the user's mailbox shows correlated signals.
What we don't claim
We do not claim that the four tiers are exhaustive. Entra is a moving target — Microsoft ships new capabilities frequently, and the platform's protection scope has to keep pace. We add new object types as they become operationally significant.
We do not claim that native Microsoft tooling is inadequate for every customer. For small organisations with minimal Entra configuration who can operate within a five-day restoration window, native preview may be sufficient on its own. The four-tier architecture is over-investment for that profile, and the right answer for those customers is to use native and skip the additional layers.
We do not claim that Microsoft's preview scope is static. The product is in active preview as of May 2026 and will continue to expand. Buyers should re-check current Microsoft Learn documentation against any post like this one — the gap that justifies a third-party tier today may be narrower or broader by the time the buyer is doing a renewal evaluation.
We do not claim that drift detection is a substitute for change management. A customer that does not have a change-management process will have noisy drift detection regardless of tooling. The drift detector tells you what changed; it cannot tell you whether the change was authorised. The change-authorisation step still belongs to the customer.
We do not claim that cross-tenant orchestration eliminates the need for tenant-specific judgment. The What-If output is data; the decision to deploy or pause is judgement. The MSP from the start of the article would still have needed to interpret the output and decide what to do about the executives without hardware tokens. The platform makes the judgement faster and more informed; it does not replace the judgement.
The architecture above the native baseline is what makes Entra operationally tractable at MSP scale. Native preview is a useful starting point with a meaningful policy footprint. The longer retention horizon, the configuration scope outside what preview covers today, and the cross-tenant operations on top of that — those are what an MSP managing fifteen Entra tenants needs to deliver competent identity protection. The four tiers are not a feature list; they are a description of what protecting Entra actually requires when the customer is operating at scale or under MSP management, alongside what Microsoft now ships natively.