A blocking rule can die on migration

Security migrations are often judged by visibility. The new portal loads. Assets appear. Queries return rows. Alerts arrive. The team concludes that the control moved successfully. A preventive rule can fail underneath this apparent continuity. Detection and enforcement are related but distinct capabilities; migrating one does not prove the other survived.

Microsoft warns that existing Agent 365 real-time protection rules configured to block would stop enforcing on July 1, 2026 and needed to be redefined in a new policy experience. The guidance also describes new tables, log sources, detection behaviors, and workflows. This is an unusually clear example of a migration where the old configuration does not carry the old consequence forward.

The dangerous state is plausible normality. Analysts still see the Defender portal. Near-real-time alerts may remain. Audit behavior may be queryable. Agents continue working. Unless someone performs a controlled prohibited action, the organization may not know that a block became an observation.

Test the verb, not the interface

Inventory controls by the verb they perform: discover, deny, redact, quarantine, alert, retain, or escalate. For each migration, prove the verb on a representative object. A policy export and import proves configuration movement. A controlled action proves enforcement. Both records are needed because a syntactically accepted rule may have changed semantics.

Downstream automation must be tested too. New tables and event schemas can break saved queries, workbooks, detections, case creation, and response playbooks. A renamed field may not fail loudly; it can produce an empty result. Treat zero-row migrations as suspicious until a known canary traverses the complete path.

A control has migrated only when its intended consequence survives the move.

Cutovers need a dual-running or compensating period when risk permits. Compare old and new observations, investigate differences, and retain an explicit date when the old source stops being authoritative. If dual running is impossible, narrow the protected workflow and increase manual review until the new path is proven.

The receipt should name every rule recreated, the old and new identifiers, semantic differences, test case, observed block or alert, downstream consumer, owner, and residual gap. This prevents a project plan marked complete from substituting for evidence that the security behavior exists.

Freeze edits to the old rule set during the cutover or establish a synchronized change procedure. Otherwise an urgent exception can be added to the legacy control after its migration copy was created and never reach the replacement. The migration inventory should reconcile effective policy at the final transition moment, including disabled rules, exclusions, priorities, and dependencies whose absence can reverse the result.

Test both positive and negative space. The prohibited canary should be blocked, the permitted canary should pass, and the alert-only case should reach the correct workflow without becoming a denial. A migration that blocks everything can look secure while breaking the service; one that allows everything can look available while removing the control. The intended distinction is the behavior that must survive.

After cutover, keep a short, named stabilization period with daily review of rule hits, bypasses, failures, latency, and downstream case creation. Assign ownership for anomalies before the old environment is decommissioned. The ability to compare old evidence, restore a rule, or extend compensating review has a deadline, and that deadline should determine when the migration can be declared operationally accepted.

Update the assurance documentation only after the behavior test passes. Architecture diagrams, control matrices, audit narratives, and incident runbooks should point to the new identifiers and evidence sources, while the migration receipt preserves the prior state. Documentation updated too early can make a pending control look operational; documentation left stale can send responders to a dashboard or rule that no longer governs anything. Preserve the acceptance evidence beside the new claim. Retire the old claim with an explicit effective date.

Operate the boundary

The practical starting point is a named control for each migrated security verb, rule, event schema, and downstream response. Write the boundary in terms an operator can evaluate: the initiating principal, permitted purpose, affected resources, allowed consequences, escalation path, expiry condition, and evidence produced. A policy sentence is useful context; the enforced object and its observable state are what make the policy operational.

Test the boundary by running a safe canary that should be blocked, another that should only alert, and a permitted action through the new path while inspecting every downstream consumer. Preserve the starting state, the agent's route, any intervention, the final effect, and the gaps in observation. Repeat the exercise after changing a model, tool, provider, policy, or data source. A control that passed once should not silently lend its assurance to a materially different system.

The leading signal is migrated rules with verified effects versus rules merely present in configuration, plus the freshness of canary events in dependent queries and workflows. Pair it with a consequence measure so teams do not optimize the dashboard while weakening the outcome. Review both on a fixed cadence and after every material incident or migration. When the signal disappears, determine whether the risk disappeared or the instrumentation did.

The migration owner and the team that depends on the enforcement should own the decision to continue, narrow, pause, or expand the workflow. The owner needs authority over the control and access to its evidence; responsibility without either becomes ceremonial. Record the decision, the evidence cutoff, the residual uncertainty, and the next review date so the claim can age honestly.

— Dispatches · Summit Cognitive