HomeNewsletterCommunityToolsArchiveBlogToday's NewsAboutQuick Links Subscribe free
← Back to Blog
Windows 11 Windows 11KerberosSecurityWindows Ready PrintIntuneActive DirectoryAlways On VPNCompliance PolicyDefender for EndpointSecurity BaselineIntune Suite

Windows June 2026: Kerberos RC4 Enforcement, Windows Ready Print, and What IT Admins Need to Do Now

IA
Imran Awan
14 July 2026

June 2026 was one of the busier months for Windows IT admins in recent memory. Kerberos RC4 enforcement reaches its final and permanent phase with the July 2026 security update - Audit mode is gone for good. The Modern Print Platform has been renamed Windows Ready Print, and its default installation behaviour changes next month. Intune Enterprise Application Management gets auto-update support. And two new Kerberos extensions are entering public preview that will finally let you reduce NTLM without the usual collateral damage. Here is what you need to know, and what you need to do before July hits your estate.

🚨
Action required before July 2026 security update

The July 2026 monthly security update removes Kerberos RC4 Audit mode on all domain controllers. If you still have RC4-dependent service accounts, applications, or network appliances, they will begin failing authentication once Enforcement mode becomes mandatory. Run the detection commands in Section 1 before you apply the July update.

1. Kerberos RC4 hardening - Enforcement is now mandatory, Audit mode removed

Microsoft has been deprecating RC4 encryption in Kerberos since 2022. The July 2026 Windows security update is the final phase: Audit mode is removed, and Enforcement mode becomes the only supported behaviour on domain controllers. If RC4 Kerberos tickets are still being issued anywhere in your domain after this update is applied, authentication for those accounts and services will fail - not log a warning, not fall back silently, fail with KRB_ERR_ETYPE_NOSUPP.

RC4 survives in enterprise environments for three common reasons: service accounts with a weak password hash type that can only generate RC4 keys, legacy applications that request RC4 explicitly in their Kerberos AS-REQ, and network appliances such as NAS boxes, older printers, and Linux hosts that cannot negotiate AES. You need to find all three categories before enforcement takes effect.

Step 1 - Detect RC4 Kerberos traffic in your domain

Run this on each domain controller. It searches the Security event log for Event ID 4769 (Kerberos Service Ticket Operations) with ticket encryption type 0x17 - that is decimal 23 - which is RC4_HMAC. Any result here is an account or service that will break after the July update.

Windows PowerShell (Domain Controller - run as Administrator)
# Find RC4 Kerberos service tickets in the last 48 hours
# Event 4769: Ticket Encryption Type 0x17 = RC4_HMAC
$start = (Get-Date).AddHours(-48)
 
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4769
    StartTime = $start
} -ErrorAction SilentlyContinue | Where-Object {
    $_.Properties[8].Value -eq 23 # 0x17 = RC4_HMAC
} | Select-Object TimeCreated,
    @{N='Account'; E={$_.Properties[1].Value}},
    @{N='Service'; E={$_.Properties[2].Value}},
    @{N='ClientIP'; E={$_.Properties[6].Value}} |
    Sort-Object Account -Unique | Format-Table -AutoSize
 
# Sample output - if you see this, you have work to do:
TimeCreated Account Service ClientIP
----------- ------- ------- --------
2026-07-06 08:12:14 svc-legacy@DOMAIN.LOCAL MSSQLSERVER/SQLBOX01 10.0.0.45
2026-07-06 09:33:07 print-svc@DOMAIN.LOCAL printerbox/NASBOX01 10.0.0.82
# These accounts and services WILL fail after July 2026 update
Gotcha: Event ID 4769 is only logged when auditing is enabled for "Kerberos Service Ticket Operations." Verify this first: run auditpol /get /subcategory:"Kerberos Service Ticket Operations" on your DCs - it must show "Success and Failure". If it is not enabled, turn it on in Default Domain Controllers Policy and allow 24 hours of traffic to accumulate before trusting the absence of results.

Step 2 - Check the current encryption type configuration on your domain controllers

Registry Editor - Kerberos supported encryption types (Domain Controller)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
SupportedEncryptionTypes REG_DWORD 0x0000001C ← 28 = RC4 + AES128 + AES256 (RC4 still permitted)
SupportedEncryptionTypes REG_DWORD 0x00000018 ← 24 = AES128 + AES256 only (target state - RC4 blocked)
If this key is absent the system default allows RC4. Absence = RC4 allowed.

Step 3 - Disable RC4 via Group Policy

Group Policy - Default Domain Controllers Policy
Computer Configuration Windows Settings Security Settings Local Policies Security Options
Policy: Network security: Configure encryption types allowed for Kerberos
Enable: AES128_HMAC_SHA1 ✓    AES256_HMAC_SHA1 ✓    Future encryption types ✓
Disable: DES_CBC_CRC ✗    DES_CBC_MD5 ✗    RC4_HMAC_MD5 ✗

For Intune-managed hybrid-joined clients, apply the same restriction as a custom OMA-URI policy. This controls which encryption types the Kerberos client on the endpoint will negotiate when authenticating to on-premises resources:

Intune - Custom OMA-URI policy
OMA-URI ./Device/Vendor/MSFT/Registry/HKLM/SYSTEM/CurrentControlSet/Control/Lsa/Kerberos/Parameters/SupportedEncryptionTypes
Data type Integer
Value 24  (0x18 = AES128 + AES256 only, no RC4)
Warning: Do not apply the AES-only policy to domain controllers until you have confirmed zero RC4 ticket requests in your Event 4769 audit log over a full business cycle (at minimum 5 business days). Applying it while RC4-dependent services exist will immediately break authentication for those accounts. Phase it: client devices first via Intune, then member servers, then domain controllers last.
What Enforcement mode actually means: After the July 2026 update, domain controllers check the msDS-SupportedEncryptionTypes attribute on the target service account principal. If that attribute is missing or includes RC4, the DC now actively rejects RC4 ticket requests rather than issuing the ticket with a warning. The client receives KRB_ERR_ETYPE_NOSUPP and authentication fails. There is no fallback.
Tip - Fix affected service accounts without repackaging credentials: For service accounts showing up in Event 4769, update their msDS-SupportedEncryptionTypes attribute in Active Directory to tell DCs to issue only AES tickets regardless of what the requester asks for: Set-ADUser svc-legacy -KerberosEncryptionType AES128,AES256. Run this for each affected account, then re-run the Event 4769 query to confirm RC4 tickets stop appearing.

2. Windows Ready Print - Modern Print Platform renamed, July 2026 default changes

The Modern Print Platform has been renamed to Windows Ready Print. Starting July 2026, new printer installations will default to Windows Ready Print where the printer supports it - meaning IPP (Internet Printing Protocol), eSCL scanning, and Universal Print, with no third-party driver required. This is part of the same driver-light printing direction as Windows Protected Print.

For most managed estates this is a positive change - fewer drivers means a smaller attack surface and simpler update management. But if your environment has printers that only communicate via proprietary protocols, or if your print server topology relies on classic Windows print driver infrastructure, test the July change before it reaches production.

Group Policy - Windows Ready Print control
Computer Configuration Administrative Templates Printers
Policy: Configure Windows protected print
Controls whether Windows Protected Print (driver-free IPP) is enforced, enabled, or disabled. Setting this to Disabled reverts new installations to the driver-based path.
Policy: Manage Windows protected print fallback behavior
Controls whether the system falls back to a driver-based path when a printer does not support Windows Ready Print. Recommended: Allow fallback during migration, disable once estate is ready.
Gotcha: Windows Ready Print requires the printer to support IPP over USB or IPP over TCP/IP. Printers that only expose a proprietary protocol are not detected as compatible and continue using their existing driver. Run an IPP compatibility audit against your printer inventory before July using Get-Printer | Select Name, PortName, DriverName on print servers and correlate against the hardware manufacturer's IPP support documentation.
Intune OMA-URI for Windows Ready Print: There is no dedicated CSP node at time of writing. Manage via ADMX-backed Group Policy CSP. OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Printers/ConfigureWindowsProtectedPrint - data type String, value <enabled/> or <disabled/>.

3. Intune Enterprise Application Management - Auto-updates now available

Intune Enterprise Application Management now supports automatic updates for managed applications in the Enterprise App Catalog. Previously, keeping an app at its latest point release required repackaging the new installer, creating a new app object in Intune, and managing the supersedence chain manually. Auto-updates handle incremental releases (such as 4.1 to 4.2) without any admin intervention after initial configuration.

This feature applies specifically to apps sourced from the Enterprise App Catalog - Microsoft-hosted, pre-packaged applications that EAM manages. It does not replace Win32 app packaging for custom or unlisted applications, and major version upgrades still require an explicit admin action.

Intune Admin Center - Enable auto-updates for an EAM catalog app
Apps Enterprise app management Select app from catalog App settings
Auto-update: Enabled
When enabled, Intune automatically installs incremental updates (e.g. 4.1 to 4.2) as they become available in the catalog. Major version updates still require an admin action. No repackaging or supersedence chain management required.
Tip - Tiering approach for auto-updates: Enable auto-updates for commodity applications where any point release is safe to deploy immediately - browsers, PDF readers, media players, communication tools. For business-critical applications (ERP clients, LOB tools, clinical software), keep manual control and stage rollouts through deployment rings before enabling auto-updates. Use Intune assignment filters to separate the two tiers.

4. IAKerb and LocalKDC - NTLM reduction is getting a proper solution

IAKerb and LocalKDC are two new Kerberos extensions now available in the Windows Insider Program, with a public preview coming for both client and server. They directly target the two scenarios where NTLM has always been the last resort despite years of Microsoft telling admins to turn it off.

LocalKDC brings a lightweight Key Distribution Center directly to the local machine. Local account authentication - workgroup scenarios, local administrator - can now use Kerberos rather than falling back to NTLM. This is the most common remaining source of NTLM in environments that have otherwise completed their Kerberos migration.

IAKerb (Initial and Pass-Through Authentication using Kerberos) allows Kerberos to flow through a proxy or intermediary when the device does not have direct DC connectivity. This solves the remote worker and DMZ host problem - VPN split tunnel scenarios, constrained network environments - where NTLM was the only option because the device could not reach a domain controller directly.

When to expect this in production: Both IAKerb and LocalKDC are currently in the Windows Insider Program. No GA date has been published. Watch the Windows Insider Blog and the Microsoft Security Blog for the public preview announcement. When it drops, enroll your existing Insider test devices immediately - this will directly impact NTLM blocking policy decisions once it reaches GA.

5. Point-in-time restore is generally available

Point-in-time restore for Windows 11 is now generally available across Enterprise, Pro, and Home editions. It allows a device to be rolled back to a previous state in minutes rather than hours, without a full reimaging workflow. For managed endpoints this matters most in ransomware response and accidental mass-deletion scenarios.

Before enabling this broadly in a managed estate, test it against your endpoint stack. The components most likely to show conflicts after a restore are BitLocker (verify recovery key escrow relationship survives the rollback), Intune co-management state and MDM certificate, EDR agents where rollback behaviour may trigger a tamper alert, and VPN client certificates issued after the restore target date.

Warning: Point-in-time restore does not revoke certificates or tokens issued after the restore point timestamp. If an attacker has already established persistence via a certificate or OAuth token, a rollback does not remove that access. Pair restore with Entra ID Conditional Access token revocation and Defender for Endpoint live response for a complete incident response workflow.

6. DirectAccess is deprecated - Always On VPN is the migration path

Microsoft has formally deprecated DirectAccess and confirmed it will be removed in a future version of Windows Server. If you are still running DirectAccess infrastructure, the supported migration path is Always On VPN managed via Intune using the VPNv2 CSP.

Microsoft's official migration guidance covers side-by-side coexistence (both DA and AOVPN active simultaneously during transition), certificate migration from NPS/RRAS, and client profile deployment. The recommended approach runs DA and AOVPN in parallel until all clients have moved, then decommissions the DA infrastructure.

Warning: "Deprecated" does not mean "removed now" - but it does mean DirectAccess receives no new security investment. Internet-facing DirectAccess infrastructure accumulates risk with every month of delay. Start the migration planning cycle now even if the cutover is 12-18 months away.
Tip: Deploy Always On VPN profiles via Intune Configuration Profiles using the VPNv2 CSP. For NPS migration, the Intune RADIUS connector (Network Policy and Access Services) provides the same certificate-based authentication model DirectAccess uses. The migration overview on Microsoft Learn includes a phased approach you can adapt to your environment size.

7. Windows 10 ESU - Personal devices get one more year, to October 2027

Microsoft is extending Windows 10 Extended Security Updates for personal-use devices by one additional year, pushing coverage to October 12, 2027. This is specifically for consumer devices purchased through the personal ESU program - it does not change the commercial ESU Year 2 and Year 3 timelines for business devices.

For enterprise environments the Windows 10 end-of-support date remains October 14, 2025. Commercial ESU continues under the existing pricing tiers. The personal extension does not change your corporate migration timeline.

BYOD implication: If you allow personal Windows 10 devices to access corporate resources via Conditional Access, those devices now have a longer supported window. Review your CA compliance policy minimum OS version requirements - you may need to update the supported OS floor for personal device compliance policies to reflect October 2027 rather than October 2025.

8. Other June 2026 updates worth knowing

DoH for Windows DNS Server 2025 (GA)

DNS over HTTPS is generally available on Windows Server 2025. Deploy encrypted client-to-resolver DNS within on-premises infrastructure without cloud dependency. Configure via DNS Manager or PowerShell: Set-DnsServerDoh. Certificates, client configuration, and split-horizon integration are all supported.

Windows Hello as default sign-in

When Windows Hello face or fingerprint is set up, it is now the default sign-in method every time - even if the user last authenticated with a PIN or password. Ships with the June 2026 security update for Windows 11 25H2 and 24H2. No policy change needed; it applies automatically to devices with biometrics enrolled.

Windows 11 26H2 - Preview available

26H2 is available in the Windows Insider Program (Beta and Experimental channels). It shares the same servicing branch as 25H2 and 24H2 and can be updated via an enablement package. Note: 26H2 will default-enable Windows Backup for Organizations (renamed to "Windows settings backup and restore") on eligible devices where the policy is left Not Configured - plan your policy coverage before deployment.

Context-based redirections for W365 (Preview)

Windows 365 now supports granular device and resource redirection controls based on contextual signals: device management state, compliance posture, group membership, and network conditions. In public preview. Relevant for organizations running W365 with mixed managed and unmanaged client device scenarios where clipboard and drive redirection need to be scoped differently by trust level.

Hotpatch for Windows Server 2022 DE extended

Hotpatch update support for Windows Server 2022 Datacenter: Azure Edition has been extended through October 2027. If you run Azure Arc-connected WS2022 DE nodes that rely on hotpatch to minimize reboot cycles, no action is required - the support window is extended automatically with no configuration change needed.

Widgets and Windows Search changes

From the July 2026 optional update preview: Widgets no longer open on hover and taskbar badges are minimized by default. Windows Search now finds files with as few as two characters typed - no minimum length. Shared Audio allows two users to listen from a single PC simultaneously. These are user experience defaults; the Widgets behavior can be managed via the Widgets CSP if needed.

Microsoft documentation references

9. Intune Compliance Policies — What they are and what changed in June 2026

If you are new to this area, here is the short version: a compliance policy in Intune is a set of rules that a device must pass before it is allowed to access company resources. Think of it as a health check that runs silently in the background. If a device fails — because BitLocker is off, the OS is out of date, or antivirus is disabled — Intune marks it as non-compliant, and your Conditional Access rules in Entra ID block that device from reaching email, SharePoint, or anything else you have protected.

The distinction between a compliance policy and a configuration policy trips up a lot of people. A configuration policy pushes a setting to a device — it turns BitLocker on. A compliance policy checks whether a setting is present — it asks whether BitLocker is on. They work together but they are separate things. You can configure BitLocker via a configuration policy and then verify it is actually running via a compliance policy.

How the chain works: Device checks in to Intune → Intune evaluates compliance policy → result (Compliant / Not compliant / In grace period) is written to Entra ID → Conditional Access reads that result and allows or blocks access. The whole cycle takes about 5–8 minutes from check-in to enforcement in a healthy environment.

What June 2026 changed — Ubuntu 24.04 and 26.04 LTS now supported for Linux compliance

Microsoft has added Ubuntu Desktop 24.04 LTS and 26.04 LTS to the list of supported Linux platforms for Intune device compliance. This matters if you manage Linux developer workstations or any Ubuntu endpoints. Previously only 22.04 was supported — devices running 24.04 would show as Not evaluated in your compliance dashboard, which is a different state to Non-compliant and often gets overlooked.

Here is how to create a Linux compliance policy from scratch. We will walk through each step so you know exactly what you are configuring and why.

Step 1 — Navigate to Compliance policies in the Intune admin centre

Intune admin centre path
Devices Compliance + Create policy

When you click Create policy, you will be asked to choose a platform. Choose Linux. You will then be taken through four tabs: Basics, Compliance settings, Actions for noncompliance, and Assignments.

Step 2 — Configure the compliance settings that actually matter for Linux

On the Compliance settings tab, you will see a list of checks Intune can run against a Linux device. Not all of these are equally important — here are the ones you should always enable and why:

Linux compliance settings — recommended baseline
Setting Recommended value Why you need it
Microsoft Defender is running Require Verifies MDE is active — without this a device with Defender stopped will still pass compliance
Real-time protection Require A device with Defender installed but passive-mode enabled will not block threats — this catches that gap
Minimum OS version 22.04 / 24.04 Forces devices onto a supported LTS kernel — devices running unsupported distro versions will be blocked
Encryption of data storage Require Checks that disk encryption (LUKS or equivalent) is active — important if users take laptops home

Step 3 — Set a grace period, not an instant block

On the Actions for noncompliance tab, the default action is to mark the device non-compliant immediately. That means the moment a check fails, access is blocked. For most settings that is too aggressive — you will flood your helpdesk with calls from users who got blocked because a scan ran at the wrong moment.

A better approach is to set a grace period of 1–3 days for most settings. This means the device is marked In grace period rather than Non-compliant immediately, and it has time to self-heal before access is cut. Only after the grace period expires does Conditional Access step in. Reserve immediate blocking for your most critical settings — things like Defender being completely off.

Gotcha — what "Not evaluated" means vs "Non-compliant": If a device shows as Not evaluated, it has not yet checked in to Intune after the compliance policy was assigned, or the platform is not supported. It is NOT the same as Non-compliant. Conditional Access by default does NOT block Not evaluated devices — check your CA policy settings to see if you want to treat Not evaluated the same as Non-compliant. For high-security environments, you should.

Verifying compliance status with PowerShell and Microsoft Graph

The Intune admin centre shows compliance status per-device, but if you want to audit across your whole estate — say, to find every non-compliant device before a security review — PowerShell against Microsoft Graph is much faster. Here is how to do it:

First, connect to Microsoft Graph with the permission scope that lets you read device compliance data:

Windows PowerShell — run as the Intune administrator account
# Step 1: Connect to Microsoft Graph
# This opens a browser sign-in prompt — use your Intune admin account
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All" -NoWelcome
 
# Step 2: Pull all managed devices and their compliance state
# complianceState can be: compliant, noncompliant, inGracePeriod, notEvaluated, unknown
$devices = Get-MgDeviceManagementManagedDevice -All -Select "deviceName,userPrincipalName,complianceState,operatingSystem,osVersion,lastSyncDateTime"
 
# Step 3: Filter to only non-compliant and in-grace-period devices
# These are the ones you need to act on before they get blocked
$atRisk = $devices | Where-Object { $_.complianceState -in 'noncompliant', 'inGracePeriod' }
 
# Step 4: Show the results in the terminal
$atRisk | Select-Object deviceName, userPrincipalName, complianceState, operatingSystem, lastSyncDateTime |
    Sort-Object complianceState | Format-Table -AutoSize
 
# Step 5: Export to CSV for your records or to share with management
$atRisk | Export-Csv "C:\Logs\Intune\NonCompliant-$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation
Write-Host "Devices at risk: $($atRisk.Count)" -ForegroundColor Cyan

What you are looking at when this runs:

Output — what a healthy result looks like
deviceName userPrincipalName complianceState operatingSystem lastSyncDateTime
---------- ----------------- --------------- --------------- ----------------
LAPTOP-007 j.smith@contoso.com noncompliant Windows 14/07/2026 07:12
LAPTOP-021 r.patel@contoso.com inGracePeriod Windows 14/07/2026 08:44
MBPRO-003 a.jones@contoso.com inGracePeriod macOS 13/07/2026 16:03
 
Devices at risk: 3
 
# Red = noncompliant: Conditional Access is blocking this device RIGHT NOW
# Orange = inGracePeriod: grace period is counting down, access still allowed for now
# If you see 0 devices at risk — that is what you are aiming for
Tip — build a weekly compliance report: Schedule this PowerShell script to run every Monday morning via a Task Scheduler job or a Proactive Remediation in Intune. Email the CSV output to your security team automatically. Within a few weeks you will have a visible trend — compliance improving or declining — that tells you whether your configuration policies are actually working.

10. Microsoft Defender for Endpoint via Intune — How the policy chain works and what changed in June 2026

A lot of IT admins manage Defender settings in two different places without realising it — the Microsoft Defender portal (security.microsoft.com) and the Intune admin centre. These two places can push conflicting settings to the same device. Understanding how they relate is one of the most practically important things you can learn for endpoint security management.

Here is the mental model: Intune is the management plane — it decides what policy gets deployed and to whom. Microsoft Defender for Endpoint (MDE) is the enforcement plane — the agent on the device that actually applies the settings and detects threats. When you create an Endpoint Security policy in Intune, Intune sends it to the MDE agent which applies it locally. Neither requires the other, but they work best together.

The Endpoint Security policy types in Intune — what each one does
Antivirus

Controls Defender AV behaviour — real-time protection, scheduled scans, exclusions, cloud-delivered protection. This is your first line of defence configuration.

Disk encryption

Manages BitLocker on Windows and FileVault on macOS. Separate from compliance — this actively configures encryption, not just checks for it.

Firewall

Configures Windows Firewall rules and profiles (Domain, Private, Public). You can create granular allow/block rules here rather than via GPO.

Endpoint detection & response

The EDR profile onboards devices to MDE and controls telemetry. Every device needs this if you want threat hunting and incident response capability in the Defender portal.

Attack surface reduction

ASR rules block specific attack techniques — macro execution from Office, process injection from JS, credential theft from LSASS. Each rule can be set to Audit, Block, or Off.

Account protection

Covers Windows Hello for Business and Credential Guard. Controls how user credentials are protected on-device — relevant for pass-the-hash attack prevention.

New in June 2026 — Defender Antivirus gets two new Linux Server settings

Microsoft added two new settings to the existing Defender Antivirus endpoint security profile for Linux Server. These appear automatically in your existing profiles if you have Linux devices managed via Intune or via MDE security settings management — no new profile is needed. Both default to Not configured, so they are not active unless you explicitly set them.

Intune admin centre — Endpoint Security → Antivirus → Linux Server profile — new settings June 2026
New setting Default What it controls and why you would enable it
Offline security intelligence update Not configured Controls how Defender updates its definitions when the device is not connected to the internet. Enable this if you have air-gapped or intermittently connected Linux servers — without it, definitions can go stale and real-time protection degrades silently.
Scheduled scan Not configured Manages when Defender runs full scans on Linux. By default Defender only does real-time scanning on file access. A weekly scheduled scan catches anything that slipped through. Set this to run during maintenance windows to avoid impacting server performance during business hours.

These settings apply to two types of Linux devices: devices enrolled in Intune in the traditional sense, and devices that are managed via the MDE security settings management path — where the device is onboarded to Defender for Endpoint but not fully enrolled in Intune. The second scenario is common for Linux servers in Azure or on-premises where full MDM enrollment is not practical.

What is MDE security settings management (and when should you use it)? It is a way to push Intune endpoint security policies to devices that are not enrolled in Intune. The device is onboarded to Microsoft Defender for Endpoint — meaning you can see it in the Defender portal — and it checks in to Intune every 90 minutes for policy updates. The MDE agent applies those settings locally. This is useful for Linux and macOS servers, Windows servers that are not domain-joined, or any device where full Intune enrollment is not feasible. The device does not appear under Devices in Intune, but your endpoint security policies still reach it.

How to create your first Antivirus policy in Intune — step by step

If you have never created an Endpoint Security policy before, here is exactly what to do. We will create a basic Antivirus policy for Windows devices. The same flow applies to all other policy types — only the settings change.

Step 1 — Navigate to Endpoint security
Intune admin centre Endpoint security Antivirus + Create policy
Platform: Windows 10, Windows 11, and Windows Server
Profile: Microsoft Defender Antivirus
Note: choose the right platform. "Windows 10 and later" is for Intune-enrolled devices only. "Windows 10, Windows 11, and Windows Server" also supports MDE-managed devices.
Step 2 — Settings to configure in the profile
Cloud-delivered protection level: High — enables the cloud lookup that catches new threats in near real-time
Turn on real-time protection: Yes — never leave this Not configured or Off
Scan all downloaded files and attachments: Yes
Block at first sight: Yes — sends unknown files to the cloud for analysis before allowing them to run
Submit samples consent: Send safe samples automatically — enables the intelligence feedback loop without requiring user interaction
Step 3 — Assignments — who gets this policy
Assign to an Entra ID group containing your managed Windows devices. If you are just starting out, create a group called SG-Intune-Pilot-Devices, add 5–10 test machines, and assign there first. Once you have verified there are no conflicts, expand to All devices.
Do not assign the same setting with different values in multiple policies — if Cloud-delivered protection is set to High in one policy and Not configured in another, the most restrictive wins. But inconsistencies are hard to debug and will waste your time.
Warning — Tamper Protection and Intune: If Tamper Protection is enabled (it is on by default in Windows 11), local settings changes are blocked. Only Intune-deployed policy changes go through. This is a feature, not a bug — it prevents malware from disabling Defender. But it means if you are testing settings manually via the Windows Security app, you will not see changes take effect. Always test via Intune policy assignment, not local UI changes.

Verify your Defender policies are actually applying — PowerShell check

After you assign a policy, give the device 15–20 minutes to check in and apply it. Then run this on the device to confirm the settings are in place:

PowerShell — run directly on the managed device
# Check the key Defender AV settings on this device
# MpPreference holds the Defender configuration — this is what Intune writes to
$prefs = Get-MpPreference
 
[PSCustomObject]@{
  'Real-time protection' = if ($prefs.DisableRealtimeMonitoring) { 'OFF - fix immediately' } else { 'Enabled' }
  'Cloud protection' = $prefs.MAPSReporting
  'Cloud block level' = $prefs.CloudBlockLevel
  'Block at first sight' = if ($prefs.DisableBlockAtFirstSeen) { 'Disabled' } else { 'Enabled' }
  'Signature version' = (Get-MpComputerStatus).AntivirusSignatureVersion
  'Last signature update' = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
  'Tamper protection active' = (Get-MpComputerStatus).IsTamperProtected
} | Format-List
Expected output — this is what a correctly configured device looks like
Real-time protection : Enabled
Cloud protection : 2 (2 = Advanced, 4 = High — your policy set High so this should be 4)
Cloud block level : 2 (2 = High blocking level)
Block at first sight : Enabled
Signature version : 1.423.156.0
Last signature update : 14/07/2026 06:43:11
Tamper protection active: True
 
# Cloud protection should be 4 if you set High in Intune
# If it shows 2, the Intune policy has not yet applied — wait and check again
# Tamper protection True is what you want — means only Intune can change these settings

11. Intune Security Baselines and Preview Policies — What updated in June 2026 and how baselines work

Security baselines in Intune are pre-built policy bundles that Microsoft has assembled based on the recommendations of the Microsoft security team and industry standards like CIS. Instead of you manually configuring 200 individual settings, a baseline gives you a tested starting point in one click.

The important thing to understand about baselines is that they are versioned. When Microsoft releases a new version, your existing baseline profiles do not update automatically. You have to actively choose to migrate to the new version. This is by design — an automatic update to a baseline could change a setting and break something in production without warning. You control when you adopt a new version.

What updated in June 2026 — two baselines changed

Security baselines updated — June 2026
Microsoft 365 Apps for Enterprise — new version v2512

A new baseline version is available. This skips the previously released v2412 version. Three settings are not yet included because the Settings Catalog does not yet have the CSP nodes for them:

  • Require macros to be signed by a trusted publisher
  • Block certificates originating from the current user store only
  • Require Extended Key Usage for code signing

These will be added in a future version when the CSP nodes are available. The VBA macro notification setting (Disable all except digitally signed macros) is still present and applied.

Windows Security Baseline 25H2 — new setting added inline

One new setting has been added to the existing 25H2 baseline version — this is an inline update, not a new version number:

Disable Internet Explorer 11 Launch Via COM Automation — Default: Enabled

This setting was excluded from the initial 25H2 baseline due to a known issue that has since been resolved. Enabling it prevents IE11 from being launched programmatically via COM — a technique used by some malware and legacy shortcuts to bypass Edge. The setting is now included and defaults to Enabled in the baseline.

Action required: This new setting does NOT apply automatically to existing baseline profiles. You must open each 25H2 baseline profile in Intune, make no changes, and click Save. That action syncs the profile and picks up the new setting. If you do not do this, the IE11 COM protection remains inactive on devices using that profile.

How to migrate to a new baseline version — the safe approach

When a new baseline version appears, you have two choices: create a fresh profile from the new version, or use the built-in migration wizard. The wizard is easier — here is how to use it:

1
Go to Endpoint security → Security baselines and select the baseline type (e.g., Windows Security Baseline). You will see your existing profiles listed with their current version number.
2
Click on the profile name and then select Change version. Intune shows you a side-by-side comparison of what is changing — settings that are new, settings that changed default value, and settings that were removed.
3
Review the changes carefully. Pay particular attention to anything in the Behavioural change column — settings where the default value changed between versions can silently reconfigure devices if your profile was relying on the old default.
4
Assign the migrated profile to a pilot group first — 5–10 devices, ideally ones where you can quickly spot if something breaks. Leave it for 48–72 hours. If nothing breaks, expand assignment to your full device fleet.
5
Once validated, expand the assignment. Your old baseline version profile remains active on any devices that are not yet in the new assignment scope — there is no forced cutover.
Tip — do not stack baselines on top of each other: A common mistake is to assign both the Windows Security Baseline and a custom configuration profile that covers the same settings. When they conflict, the most restrictive setting wins — but finding out which profile "won" for a specific setting requires going through the per-setting status report in Intune. Keep it clean: one baseline profile per device, and supplement with custom configuration profiles only for settings the baseline does not cover.

Multi Admin Approval now enforced on Graph API automation — what this means for your scripts

Multi Admin Approval (MAA) was previously only enforced on interactive admin actions in the Intune admin centre. As of June 2026, it now also applies to API calls made by automation scripts, service principals, and third-party tools. If your tenant has MAA enabled and your automation script tries to make a change without the required approval headers, it will receive an HTTP 403 response and the change will not apply.

This affects any PowerShell scripts using the Microsoft Graph SDK or direct REST calls that modify Intune resources covered by MAA (currently: Application management, Device wipe, Script assignments). If your automation started failing with 403 errors after the June 2026 service release, this is likely why.

How to exclude a specific app or service principal from MAA enforcement
Tenant administration Multi Admin Approval Access policies Exclusions tab

Add the service principal or app registration used by your automation script to the Exclusions list. This exempts that application from MAA requirements while keeping the approval workflow active for interactive admin changes. Review your exclusions list quarterly — service principals tend to accumulate there and become a security debt.

Gotcha: If you have automation scripts using a user credential (a service account with a password, signing in interactively) rather than a service principal with a certificate or client secret, those scripts are affected differently. The MAA check looks at whether the caller is an approved app registration. A user account used in automation is not a service principal and cannot be added to the Exclusions list. Migrate your automation to use app registrations with managed identities — this is the correct approach and Microsoft is progressively closing the gaps that make user-credential automation possible.

12. Intune Suite features added to Microsoft 365 E3 and E5 — what you now have access to

This is probably the most impactful licensing change in June 2026 for most IT teams. Microsoft is moving several capabilities that previously required an Intune Suite add-on licence into the base Microsoft 365 E3 and E5 subscriptions at no extra cost. You may already have access to these features and not know it yet.

Rollout is gradual — eligible tenants are being provisioned automatically with 30 days advance notice appearing in the M365 admin centre. If you have not seen the notice yet, check the admin centre Message Centre for updates.

What is now included — and what each feature does
Added to M365 E3
Remote Help

A helpdesk tool built into Intune. Support agents connect directly to a user's device from the Intune portal and can view or take over the screen. Compliant and non-compliant device state is visible to the agent during the session. Replaces the need for third-party remote support tools for Intune-managed devices.

Added to M365 E3
Advanced Analytics

Adds deeper insight into your Intune estate — device anomaly detection, startup performance analysis, battery health scoring across the fleet, and app reliability data. Useful for proactively identifying devices heading towards failure before users raise helpdesk tickets.

Added to M365 E5
Endpoint Privilege Management

Allows standard users to run specific applications with elevated privileges without needing a full local admin account. Define which executables can be elevated, by which users, and with what approval workflow. The goal is to remove standing local admin rights while keeping users unblocked for legitimate tasks.

Added to M365 E5
Enterprise Application Management

Pre-packaged, Microsoft-maintained application catalogue for Intune deployment. Applications are kept updated automatically (incremental versions) without repackaging. Covered earlier in this post — now included in M365 E5 at no add-on cost.

Added to M365 E5
Microsoft Cloud PKI

A fully cloud-hosted certificate authority managed from Intune. Issue device and user certificates for Wi-Fi, VPN, and email authentication without running your own on-premises PKI infrastructure. Particularly useful for organizations moving away from on-premises Active Directory Certificate Services.

Added to M365 E3
Intune Plan 2

Includes Microsoft Tunnel for MAM (mobile app VPN without device enrollment), specialty device management for ruggedized and IoT devices, and FOTA (firmware over the air) updates for frontline devices. If you manage mobile workers with unmanaged personal phones accessing corporate apps, Microsoft Tunnel for MAM is the relevant piece here.

How to check if your tenant has been provisioned yet: Sign into the Microsoft 365 admin centre at admin.microsoft.com, go to Billing → Your products, and look for entries related to Intune Suite capabilities. Alternatively, in the Intune admin centre go to Tenant administration → Intune add-ons — if the features above are active, they appear here without a "Trial" or "Upgrade" prompt.
Share this post
LinkedIn X / Twitter Reddit Bluesky

More from EndpointWeekly

Windows 11
Microsoft's AI Is Hunting Windows Vulnerabilities Before…
Microsoft's MDASH — a multi-model AI scanning harness — is now hunting Windows…
Windows 11
Windows Monthly Updates Explained: LCU, SSU, Patch Tuesday and…
Every month Windows ships updates and most admins do not know the difference between an…
Windows 11
Windows Settings Backup Is On by Default From 26H2 — What You…
Starting with Windows 11 26H2, eligible devices will have settings backup on by default.…