Recently I posted about how Microsoft announced that starting September 1, 2026, users who are enabled for SMS or voice authentication will be automatically enabled for passkeys. Microsoft will also move the Registration Campaign to a Microsoft-managed configuration for these users, which means they can start receiving prompts to register a passkey when they sign in and complete MFA.

For organizations that are already ready for passkeys, this is probably not a problem. But there are environments where the security team may need more time to migrate users, review authentication methods, or deal with specific operational requirements.

Sometimes the easiest way to build a complex Microsoft Purview Data Loss Prevention rule is not to start from scratch. You may already have a rule whose conditions, classifiers, and nested logic are exactly what you need for a lab, a backup, or a similar deployment in another tenant.

This is where the AdvancedRule property can be very useful.

In this post, I will show you how I extract the condition logic from an existing DLP rule, remove a few properties that can cause portability problems, save the result as JSON, and use it with New-DlpComplianceRule.

I usually say that if you’re only doing MFA you’re already late. The industry is moving beyond traditional MFA and into a model where phishing-resistant authentication becomes the expected baseline.

Proof ot that is that Microsoft has announced that passkeys will become the default authentication method for Microsoft Entra ID tenants.

At the same time, Microsoft is retiring its role as a native telecom provider for MFA. This does not mean that SMS and voice are being banned as authentication methods at the protocol level, but Microsoft will no longer provide the underlying delivery service for those codes.

Until now, updates for Microsoft Defender for Endpoint were bundled with the monthly Windows security update. Microsoft is changing this behavior and moving those EDR updates to Microsoft Update, aligning them with the way other Microsoft Defender components are serviced.

And I think this is a good thing.

Why? Because it allows Microsoft to deliver security improvements for the EDR component independently from the regular operating system update cycle.

What is changing?

Microsoft Defender for Endpoint EDR updates will no longer be delivered as part of the monthly Windows security update. Instead, they will be delivered through Microsoft Update using KB5005292, once the required prerequisites are installed on the device.

If you manage Exchange Online for an E3 tenant, you are getting more bang for your buck. Microsoft has started rolling out Defender for Office 365 (MDO) Plan 1 to Microsoft 365 E3/G3 and Office 365 E3/G3 licenses, with completion expected by August 2026. This doesn’t requiere any purchase, or separate provisioning, it just show up automatically for licensed users as the rollout reaches your tenant.

What you had vs. what you’re getting

Up to now, E3 mailboxes were protected by Exchange Online Protection (EOP) — spam filtering, basic anti-malware, and standard anti-phishing. That’s table stakes, and it stays in place.

One of the things I’ve always missed when deploying antivirus policies for Microsoft Defender for Endpoint on Linux devices were scheduled scans.

And I said ‘were’ because they are coming. Currently in preview, now you can set up scheduled scans settings used a custom JSON setting or, if you use Intune or security settings management an antivirus policy instead of using a cron job like until now.