Why the Compliance Signal Breaks Down

Intune compliance policies for Android devices evaluate a set of properties reported by the device through the Android Enterprise management channel. For firmware and OS-level checks, Intune relies on the Android Security Patch Level (SPL) field — a date string in YYYY-MM-DD format — and the OS version field.

The problem is that Samsung ships firmware under a versioning model that does not map cleanly to either of these fields in all conditions.

Samsung devices running One UI carry multiple version identifiers: the Android OS version, the One UI version, the security patch level, and the build number — which encodes the actual firmware revision using Samsung's internal SMYYMMDD format. Intune reads the SPL and OS version. It does not evaluate the build number. It cannot distinguish between two firmware images that share the same SPL date but differ in their Samsung-specific patch payload.

This matters because Samsung regularly releases maintenance releases — firmware updates that address Samsung-specific vulnerabilities (Knox, Bixby stack, modem firmware, bootloader) without advancing the Android SPL date. A device that received a Samsung maintenance release in January and a device that did not can both report the same SPL of 2024-01-01. Intune sees them as identical from a compliance perspective. They are not.

---

How Samsung's Firmware Versioning Actually Works

To understand the gap, you need to understand Samsung's build number format. A typical Samsung build number looks like this:

UP1A.231005.007.S908EXXU5DXLA

Breaking this down:

• UP1A.231005.007 — the Android build descriptor from Google
• S908E — the device model identifier (Galaxy S22 Ultra in this case)
• XXU — the region/carrier code
• 5 — the major One UI version
• D — the year (D = 2024 in Samsung's encoding)
• X — the month (X = October in Samsung's hex-like encoding)
• LA — the incremental revision within that month

Two devices with build numbers S908EXXU5DXLA and S908EXXU5DXJA share the same SPL. The LA vs JA suffix indicates different incremental firmware revisions. The LA build may include patches for Samsung SVE (Samsung Vulnerability and Exposure) advisories that JA does not. Intune cannot see this difference.

Samsung publishes its SVE advisories monthly at samsung.com/security. Cross-referencing those advisories against your fleet's actual build numbers requires pulling the build number from each device — which Intune surfaces in the device hardware inventory — and comparing it against Samsung's published minimum build for each advisory.

The gap is not theoretical. In lab testing across Galaxy S22, S23, and A54 devices enrolled in Android Enterprise Fully Managed mode, devices running firmware two incremental revisions behind the current Samsung release consistently passed Intune compliance checks configured with a minimum SPL of the current month. The SPL reported by all devices was identical. The build numbers were not.

---

Reproducing the Gap in Your Environment

Before you can remediate, you need to confirm whether this gap exists in your fleet. The following KQL query runs against Microsoft Defender for Endpoint or the Intune Data Warehouse (via Log Analytics if you've connected it) to surface Samsung devices where the build number can be cross-referenced.

KQL — Surface Samsung device build numbers from Intune device inventory:

IntuneDevices
| where OperatingSystem == "Android"
| where DeviceManufacturer == "Samsung"
| project
    DeviceName,
    DeviceId,
    UserPrincipalName,
    OSVersion,
    SecurityPatchLevel,
    Model,
    LastSyncDateTime,
    ComplianceState
| extend BuildNumberAvailable = isnotempty(OSVersion)
| where ComplianceState == "Compliant"
| order by LastSyncDateTime desc

This query returns compliant Samsung devices with their reported OS version and SPL. The build number itself is available in the Intune device hardware inventory but is not always surfaced in the standard IntuneDevices table depending on your Log Analytics connector version. If it's absent, pull it via the Graph API.

PowerShell — Pull Samsung device build numbers via Microsoft Graph:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$allDevices = Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Android'" |
    Where-Object { $_.Manufacturer -eq "Samsung" }

$results = foreach ($device in $allDevices) {
    $hwDetail = Get-MgDeviceManagementManagedDeviceHardwareDetail -ManagedDeviceId $device.Id

    [PSCustomObject]@{
        DeviceName         = $device.DeviceName
        UserPrincipalName  = $device.UserPrincipalName
        Model              = $device.Model
        ComplianceState    = $device.ComplianceState
        SecurityPatchLevel = $device.AndroidSecurityPatchLevel
        OSVersion          = $device.OsVersion
        # Build number is encoded in the serialNumber or via OEM config in some enrollments
        # For AMAPI-enrolled devices, check the hardwareInfo.brand field
        LastSync           = $device.LastSyncDateTime
    }
}

$results | Export-Csv -Path ".\Samsung_Firmware_Audit.csv" -NoTypeInformation
Write-Host "Exported $($results.Count) Samsung devices to Samsung_Firmware_Audit.csv"

Run this export and compare the SecurityPatchLevel values against Samsung's published SVE bulletins for the same period. Devices with matching SPLs but different build number suffixes (if you can retrieve them via OEM config or Knox SDK integration) will confirm the gap.

---

The Conditional Access Consequence

The compliance gap becomes a security control failure when Conditional Access is in the picture.

Most enterprise Intune deployments gate access to Exchange Online, SharePoint, and corporate applications behind a Conditional Access policy that requires device compliance. A Samsung device that passes Intune's compliance check — despite running firmware with unpatched Samsung SVE vulnerabilities — receives a compliant token. That token grants full access to production resources.

The device is not compliant in any meaningful security sense. It has passed a policy check that evaluated an incomplete signal. The Conditional Access grant is technically correct given the data Intune has, but the underlying security assumption is broken.

This is where the governance and audit risk compounds. If your organization has committed to a security baseline — whether CIS Benchmark, NIST 800-53, or an insurance carrier's MDM requirements — that baseline almost certainly requires devices to be current on security patches. A compliance report showing all Samsung devices as compliant does not satisfy that requirement if the compliance check itself cannot detect Samsung-specific firmware gaps.

---

Closing the Gap Without Waiting for Microsoft

There is no native Intune policy today that evaluates Samsung build numbers. Closing this gap requires a layered approach using tools that are already available in most enterprise environments.

Option 1: Knox Platform for Enterprise (KPE) + OEM Config

Samsung Knox Platform for Enterprise exposes device properties — including the full build number and Knox version — through the OEMConfig channel in Intune. If you're already licensed for Knox Suite or Knox Platform for Enterprise, you can deploy an OEMConfig profile that reads the build number and reports it as a managed configuration value. You can then build a custom compliance policy using Intune's custom compliance script feature to evaluate that value against a minimum build string.

Option 2: Custom Compliance Script via Intune

Intune's custom compliance feature (available for Android Enterprise Fully Managed and Corporate-Owned Work Profile) allows you to deploy a PowerShell-equivalent script (JSON-based discovery script on Android) that returns device properties. The compliance engine then evaluates those properties against rules you define.

The limitation: Android custom compliance scripts run in a restricted context and cannot directly query the build number from the system properties API without a companion app or Knox integration. This makes Option 1 the more reliable path for Samsung-specific build number evaluation.

Option 3: Defender for Endpoint Device Vulnerability Assessment

If your Samsung devices are onboarded to Microsoft Defender for Endpoint via the Defender app on Android, the vulnerability assessment engine does evaluate firmware-level CVEs independently of Intune's compliance signal. Defender's threat and vulnerability management (TVM) surface will flag devices with known CVEs tied to specific Samsung firmware versions — including CVEs that Intune's SPL check would miss.

PowerShell — Query Defender TVM for Samsung firmware CVEs via Graph Security API:

Connect-MgGraph -Scopes "SecurityEvents.Read.All"

$defenderBaseUri = "https://api.securitycenter.microsoft.com/api"
$token = (Get-MgContext).AccessToken

$headers = @{
    Authorization = "Bearer $token"
    "Content-Type" = "application/json"
}

$devicesUri = "$defenderBaseUri/machines?`$filter=osPlatform eq 'Android'"
$devices = Invoke-RestMethod -Uri $devicesUri -Headers $headers -Method Get

foreach ($device in $devices.value | Where-Object { $_.osBuild -match "Samsung|SM-" }) {
    $vulnUri = "$defenderBaseUri/machines/$($device.id)/vulnerabilities"
    $vulns = Invoke-RestMethod -Uri $vulnUri -Headers $headers -Method Get

    foreach ($vuln in $vulns.value) {
        [PSCustomObject]@{
            DeviceId    = $device.id
            DeviceName  = $device.computerDnsName
            CVE         = $vuln.id
            Severity    = $vuln.severity
            Description = $vuln.description
        }
    }
} | Export-Csv -Path ".\Samsung_Defender_CVEs.csv" -NoTypeInformation

Write-Host "CVE export complete."

This gives you a firmware vulnerability picture that Intune's compliance report cannot provide. The two signals — Intune compliance state and Defender TVM findings — should be correlated. A device that is Intune-compliant but has open Defender TVM findings for firmware CVEs is exactly the false-positive scenario this article describes.

---

Governance Considerations for Audit and Insurance

If your organization is subject to SOC 2, ISO 27001, PCI DSS, or cyber insurance policy requirements that mandate patch currency for managed mobile devices, the Intune compliance report alone is insufficient evidence.

Auditors and insurance underwriters increasingly ask for evidence of patch management effectiveness — not just policy configuration. A compliance report that cannot distinguish between a fully patched Samsung device and one running firmware two revisions behind does not demonstrate effective patch management. It demonstrates that a policy exists.

The distinction matters during a breach investigation. If a Samsung SVE vulnerability is exploited on a device that Intune reported as compliant, the gap between the compliance signal and the actual device state becomes a material finding. Depending on your cyber insurance policy language around "reasonable security controls," a false-positive compliance report could affect coverage.

Document the limitation explicitly in your risk register. Note that Intune's Android compliance evaluation does not assess Samsung-specific firmware revisions below the SPL level, and record the compensating controls you've implemented — whether that's Defender TVM correlation, Knox OEMConfig build number evaluation, or a manual quarterly audit of Samsung build numbers against SVE bulletins.

---

Recommendations for Production Environments

Four concrete actions you can take before your next compliance review:

1. Run the Graph API export now. Pull your Samsung fleet's SPL dates and compare them against Samsung's current SVE bulletin. Identify any devices where the SPL matches the current month but the build number suffix suggests a pre-bulletin firmware image. This is your baseline gap measurement.

2. Enable Defender for Endpoint on all Samsung devices. The Defender TVM signal is the most reliable compensating control available today without Knox licensing. It evaluates firmware CVEs independently and surfaces findings in the Microsoft 365 Defender portal and via the Graph Security API.

3. If you hold Knox Suite licensing, deploy OEMConfig profiles. Configure build number reporting through the OEMConfig channel and build a custom compliance rule that enforces a minimum build string. Update the minimum build string monthly when Samsung publishes its SVE bulletin.

4. Update your compliance policy documentation. Explicitly state that Android compliance policies evaluate SPL and OS version, not Samsung-specific build numbers. Record this as a known limitation with compensating controls. This protects you during audits and insurance reviews.

---