Your Secure Score just fell off a cliff — you moved the subscription

The resources arrived in the new tenant intact. Then someone opened Defender for Cloud, saw the Secure Score sitting at a fraction of where it was, and assumed the migration broke something. It did not. The posture data simply does not travel with the subscription — and this is part of the Azure tenant-to-tenant migration guide.

New to cloud? CAMPUX is a free, build-first course. Start here →

Here is the trap. When you transfer a subscription to a new tenant, the VMs, storage accounts, and databases go with it, so people assume everything else did too. Defender for Cloud is the piece that quietly does not. Its plans, its policy, its contacts, its exports — all of that is configuration bound to the subscription while it lived in the old tenant, and the destination tenant starts you closer to a fresh onboarding than a clone. If you treat the new tenant's Defender view as authoritative on day one, you will misread a re-enablement gap as a security regression. This is the transferring the subscription story seen from the security team's chair.

Why Defender config is tied to the subscription and tenant

Defender for Cloud turns on at the subscription. Microsoft's own onboarding is explicit that you enable the solution on an Azure subscription, and you enable individual plans — Defender for Servers, Storage, Containers, CSPM, and the rest — on that subscription. The policy that drives assessment is assigned at the subscription or management group. Contacts, automations, and exports are wired to that same scope. None of that is a property of the resource; it is a property of the subscription as it sat inside a particular Entra tenant. Pull the subscription into a new tenant and you have carried the resources across, but the security scaffolding around them was left standing in a building you no longer own.

The resources cross the tenant boundary. The security posture around them does not.

What you re-enable in the target tenant

Walk the destination subscription as if it were new, because for Defender's purposes it nearly is. Four areas need eyes on them:

• Defender plans. Confirm each plan you relied on is on in the new tenant. Enablement is per subscription, so a plan that was on before can read as off — or default — after the move.
• Security policy and initiative assignments. Turning Defender on applies the Microsoft cloud security benchmark by default, but any custom standards, exemptions, or tuned assignments you built in the old tenant are not guaranteed to reappear. Re-assign and re-tune them.
• Email notification contacts. The addresses that receive alerts are subscription-scoped configuration. Re-enter them, or a real alert fires into a mailbox nobody in the new tenant reads.
• Workflow automations and continuous export. Automations and export to Log Analytics or Event Hubs point at destinations that lived in the old tenant. Recreate the automations and repoint export at workspaces and hubs that exist in the target.

The honest caveat: Microsoft does not publish a single clean "your Defender config transfers like this" contract for tenant moves, and behavior can shift with the portal. So verify each item by hand rather than trusting that any of it followed. When you are unsure whether something carried, assume it did not and re-set it.

Why Secure Score drops, then climbs back

Secure Score is not a stored number that moves with the subscription. It is computed. When you turn Defender for Cloud on in a subscription, the benchmark is applied and assessment of your resources begins; the score aggregates how those resources measure against the built-in recommendations. After a move, that assessment restarts from a new baseline. Until plans and policy are back and resources have been re-evaluated, the score reads low — sometimes alarmingly so — not because anything got less secure, but because Defender has not finished looking yet. Give it time. Microsoft states that Defender for Cloud calculates each control every eight hours per subscription, so the number settles over hours, not seconds. A score that climbs back toward its old level over the first day is the system working exactly as designed. Worth knowing too: the same scope expanding — more resources assessed — can push a score down even when nothing regressed, which is Microsoft's own explanation for surprise drops.

How to verify posture is genuinely back

Do not declare victory on the score alone. Open the Recommendations page and confirm resources are being assessed against the benchmark — an empty or thin recommendation list means assessment has not run, not that you are clean. Check that each Defender plan shows enabled. Trigger or wait for a test alert and confirm it reaches the security contacts you re-entered. Confirm continuous export is landing rows in the destination workspace. When the recommendations are populating, the plans are on, an alert reaches a real mailbox, and export is flowing, the score you then read is trustworthy. Compare it against what you recorded before the move — you did record it before the move — and investigate any gap as a genuine finding rather than migration noise.

The takeaway

A subscription carries its resources across a tenant boundary; it does not carry its Defender for Cloud posture. Plans, policy assignments, notification contacts, workflow automations, and continuous export are subscription-scoped configuration that you re-enable in the target, and Secure Score is recomputed from a fresh baseline over the following hours. Capture the score before you move, re-set the five configuration areas in the destination, let the controls cycle, then verify against recommendations, alerts, and export before you trust the number. Read that way, the cliff you saw on day one is not a breach — it is a checklist you have not finished yet.

Questions people also ask

Does Defender for Cloud follow a subscription to a new tenant?

The subscription and its resources move, but the Defender for Cloud configuration is scoped to the subscription within its old tenant, and much of it does not carry over cleanly. In the new tenant you re-check the Defender plans, the security policy and initiative assignments, the email notification contacts, the workflow automations, and any continuous export settings. Treat the target as a fresh onboarding rather than a copy.

Why did my Secure Score drop after moving a subscription?

Secure Score is calculated from how your resources score against the Microsoft cloud security benchmark, which is applied when you turn Defender for Cloud on in a subscription. After a tenant move the assessment restarts from a new baseline, and until plans and policy are re-enabled and resources are reassessed, the score reads low. It rebuilds as the fresh evaluation completes.

Are Defender for Cloud plans enabled per subscription or per tenant?

Per subscription. You enable the Defender for Cloud solution on a subscription, and you turn on individual plans such as Defender for Servers, Storage, or CSPM on that subscription. Because the enablement lives on the subscription inside a specific tenant, moving the subscription to a new tenant means you verify and, where needed, re-enable those plans in the destination.

How long does Secure Score take to recalculate?

Defender for Cloud calculates each security control every eight hours for each subscription, so a full picture is not instant. After you re-enable plans and confirm the policy is assigned, give it several hours to a day for the controls to cycle and for the score to settle at a number that reflects the resources as they stand in the new tenant.

Do email notifications and continuous export survive a tenant move?

Do not assume they do. Email notification contacts, workflow automations, and continuous export to Log Analytics or Event Hubs are configuration attached to the subscription in the source tenant, and they need re-checking in the target. Re-enter the security contact addresses, recreate the automations, and repoint continuous export at destinations that exist in the new tenant.