Windows 11 KB5127648 Broke Smart App Control: Detection and Remediation Guide for Defenders

Microsoft has confirmed and resolved a defect introduced by the October 2026 KB5127648 cumulative update for Windows 11 that prevented some users from activating Smart App Control (SAC). On affected systems, a security feature designed to block untrusted and potentially malicious applications simply could not be turned on — and depending on how the failure presented, users and administrators may have had no obvious indication that a layer of their endpoint defense stack was missing.

This is not a remote-code-execution zero-day, and it does not carry a CVE. But from a defensive operations perspective, it is exactly the kind of failure that matters: a silent control gap. Smart App Control is one of Microsoft's newer reputation- and AI-driven execution-blocking layers, and organizations that have factored it into their application control strategy — alongside or in place of AppLocker/WDAC — need to verify that the control is actually in the state they believe it is. Patch compliance dashboards showing KB5127648 as "installed" do not tell you whether SAC is enforcing.

This post covers what broke, how to audit your fleet for affected systems, and how to verify remediation after applying Microsoft's fix.

Technical Analysis

What Smart App Control Does

Smart App Control is a Windows 11 security feature that combines Microsoft's cloud-based app intelligence with code-signing checks to block execution of applications that are unsigned, untrusted, or assessed as potentially malicious. It operates in three states:

On (Enforcement): Untrusted or unsigned apps are blocked from running.
Evaluation: SAC runs in a learning mode, observing user behavior to determine whether enforcement would be disruptive. If it decides the user regularly runs unsigned tooling (common for developers and IT admins), it turns itself off.
Off: The feature is disabled. Critically, once SAC is off, it historically cannot be re-enabled without a clean reinstall or reset of Windows — a design decision Microsoft has been loosening, but one that remains a friction point in the field.

What Broke

After installation of the October 2026 KB5127648 security update on Windows 11, some devices were unable to activate Smart App Control. Affected users attempting to enable the feature through Windows Security → App & browser control → Smart App Control settings found activation failing. Per Microsoft's known-issue documentation, this affected a subset of systems rather than the entire Windows 11 fleet, and Microsoft has since shipped a resolution through its standard Windows Update servicing channel (including Known Issue Rollback mechanisms and/or a subsequent cumulative update, per the advisory).

Why This Matters Defensively

Control-state drift. Endpoint protection is only as good as its verified state. A device that reports "up to date" on patches may simultaneously have SAC in an unexpected Off or Evaluation state.
The one-way door problem. Because SAC traditionally cannot be toggled back on after being disabled, any device where the October update flipped or stranded SAC into the Off state may require more than a patch to recover the control — potentially a reinstall path if the state cannot be transitioned.
Attackers exploit trust in controls. Execution-blocking features like SAC are a meaningful layer against commodity malware droppers, unsigned LOLBAS-adjacent tooling, and trojanized installers — all of which remain heavily used in 2025–2026 intrusion chains. A silently missing layer is exactly what initial-access brokers count on.

Exploitation Status

This is a product defect, not an exploited vulnerability. There is no CVE, no CVSS score, no CISA KEV entry, and no evidence of adversaries targeting the condition directly. The risk is the defensive gap itself, not active exploitation of the bug.

Detection & Response

The core detection task here is posture verification: identify every Windows 11 endpoint where (a) KB5127648 is installed, and (b) Smart App Control is not in its expected enforcement state. SAC state is readable from the registry at HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy (VerifiedAndReputablePolicyState: 0 = Off, 1 = Evaluation, 2 = On) and via Get-MpComputerStatus (SmartAppControlState).

YAML

---
title: Smart App Control Disabled or Turned Off on Windows 11 Endpoint
id: 3f9a2c71-8b4d-4e6a-91c2-7d5e0a1b8f34
status: experimental
description: Detects registry modification that sets Smart App Control to the Off state. Post-KB5127648, any unexpected SAC state transition on managed endpoints should be investigated to determine whether it resulted from the known defect, evaluation-mode auto-disable, or deliberate tampering.
references:
  - https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-smart-app-control-broken-by-october-windows-update/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|contains: '\Control\CI\Policy'
    Details: 'DWORD (0x00000000)'
  condition: selection
falsepositives:
  - SAC evaluation mode legitimately turning itself off on developer or admin workstations
  - Intentional SAC disablement during Windows provisioning or OEM imaging
level: medium

KQL — Microsoft Sentinel / Defender

// Hunt: Windows 11 devices with KB5127648 installed but Smart App Control not enforcing
// Join update inventory against SAC posture. Adjust tables to your inventory source.
DeviceInfo
| where OSPlatform == "Windows11"
| join kind=inner (
    DeviceTvmSecureConfigurationAssessment
    | where ConfigurationId == "scid-2400"  // Adapt: map to your SAC/config check, or use registry via DeviceRegistryEvents
) on DeviceId
| project DeviceId, DeviceName, OSVersion, IsCompliant, ConfigurationValue
| where ConfigurationValue !contains "On"
| summarize arg_max(Timestamp, *) by DeviceId;

// Alternative: query SAC registry state directly where Defender registry telemetry is available
DeviceRegistryEvents
| where RegistryKey endswith @"Control\CI\Policy"
| where RegistryValueName == "VerifiedAndReputablePolicyState"
| where RegistryValueData == 0   // 0 = Off, 1 = Evaluation, 2 = On
| summarize LastSeen = max(Timestamp), arg_max(Timestamp, *) by DeviceId, RegistryValueData
| project DeviceId, DeviceName, LastSeen, SACState = RegistryValueData
| order by LastSeen desc

VQL — Velociraptor

-- Audit Smart App Control enforcement state across the fleet
-- VerifiedAndReputablePolicyState: 0=Off, 1=Evaluation, 2=On
SELECT Fqdn,
       read_reg_key(
         accessor='registry',
         path='HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\CI\\Policy\\VerifiedAndReputablePolicyState'
       ).Data.value AS SACState,
       read_reg_key(
         accessor='registry',
         path='HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\UBR'
       ).Data.value AS UBR,
       timestamp(epoch=now()) AS CollectionTime
FROM clients()

Remediation Script

The following PowerShell audits the local device: it reports the installed update build, current SAC state, and flags systems needing attention. Run it at scale via your RMM, Intune remediations, or GPO startup script.

PowerShell

# Smart App Control posture audit — KB5127648 impact check
# Run elevated. Returns posture object; exit 1 if SAC is not enforcing.

$ciPolicyPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy'
$stateMap = @{ 0 = 'Off'; 1 = 'Evaluation'; 2 = 'On' }

# Get SAC state (fallback to Defender cmdlet if registry value is absent)
$sacRaw = (Get-ItemProperty -Path $ciPolicyPath -Name VerifiedAndReputablePolicyState -ErrorAction SilentlyContinue).VerifiedAndReputablePolicyState
if ($null -eq $sacRaw) {
    $sacRaw = (Get-MpComputerStatus).SmartAppControlState
}
$sacState = $stateMap[[int]$sacRaw]

# Confirm build and whether October 2026 update era patches are present
$build = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').CurrentBuildNumber
$ubr = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
$kb5127648 = Get-HotFix -Id KB5127648 -ErrorAction SilentlyContinue

$result = [PSCustomObject]@{
    Hostname        = $env:COMPUTERNAME
    Build           = "$build.$ubr"
    KB5127648Present = [bool]$kb5127648
    SACState        = $sacState
    RequiresAction  = ($sacState -ne 'On')
}

$result | Format-List

if ($result.RequiresAction) {
    Write-Warning "Smart App Control is '$sacState' on $($env:COMPUTERNAME). Verify latest cumulative updates are installed via Windows Update, then attempt re-activation under Windows Security > App & browser control. If SAC cannot transition from Off, a repair/reinstall path may be required per Microsoft guidance."
    exit 1
}
exit 0

Remediation

Apply Microsoft's resolution. Ensure affected Windows 11 devices have received the fix for the KB5127648 known issue. Microsoft delivers these either through Known Issue Rollback (KIR — automatic for consumer and non-managed business devices) or through a subsequent cumulative update. Managed enterprise devices may require deployment of the KIR Group Policy from Microsoft's known-issues documentation. Review the advisory context at the source: https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-smart-app-control-broken-by-october-windows-update/ and cross-reference the Windows 11 release health dashboard (learn.microsoft.com/windows/release-health).
Audit before you trust. Run the registry/Defender-based SAC posture check (script above) across your fleet. Treat any managed device showing SAC in Off or Evaluation state — where your baseline expects enforcement — as a finding.
Handle the one-way door. If a device has landed in the Off state and cannot be re-enabled after patching, follow Microsoft's guidance: historically this requires a Windows reset or clean reinstall to re-enter Evaluation/On. Factor this into your remediation effort estimate — it is not a five-minute fix per endpoint.
Don't rely on SAC as a single control. Organizations needing deterministic application control should maintain WDAC or AppLocker policies as the authoritative enforcement layer, with SAC as defense-in-depth. A control that can silently fail or flip states should never be your only execution barrier.
Add posture drift to monitoring. Alerting on SAC state changes (per the Sigma rule above) catches both this defect and any future tampering attempts — disabling SAC is also a plausible attacker defense-evasion move, so this detection has durable value beyond this incident.
Update your patch-validation runbook. "Update installed" is not "control verified." Add post-patch control-state validation for SAC, Credential Guard, and similar security features to your monthly patch cycle QA.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub