Why Firmware and OS Patch Level Are Not the Same Thing

The Android Security Patch Level (SPL) visible in Intune compliance policies reflects the date of the last applied security patch set. It does not reflect the firmware build version, bootloader revision, or Knox security policy version installed on the device.

Samsung ships firmware updates on a separate cadence from Google's monthly Android security bulletin. A device can report a current SPL while running an outdated firmware build — particularly on carrier-locked variants, where Samsung's firmware release schedule is gated by carrier validation cycles that can lag the unlocked build by four to eight weeks.

This distinction matters in regulated environments. In healthcare (HIPAA), finance (PCI-DSS, SOX), and government (FedRAMP, CMMC), firmware integrity is increasingly treated as a separate control domain from OS patch compliance. An audit finding against firmware version currency is a different finding from an SPL gap — and your current Intune compliance reports likely cannot distinguish between them.

---

Samsung Firmware Release Architecture in Enterprise Context

Samsung maintains multiple firmware streams for each Galaxy model:

• CSC (Consumer Software Customization): Region and carrier-specific firmware variants. A Galaxy S24 Ultra on Verizon runs a different firmware build than the same hardware on T-Mobile or the unlocked variant.
• Knox Platform for Enterprise (KPE): Enterprise-specific firmware controls layered on top of the base firmware. KPE version must align with the Knox API level your MDM policies reference.
• Bootloader version: Separate from the Android OS version. Bootloader updates are included in some firmware packages but not all. A bootloader downgrade is permanently blocked on Samsung devices once a higher version is flashed — this is the rollback risk most admins discover only after a failed recovery attempt.
• Modem firmware: Baseband version, updated independently of the Android OS in some Samsung firmware packages.

In Intune, none of these sub-components are surfaced as individual compliance attributes. The androidDeviceOwner and androidWorkProfile compliance policy schemas expose osMinimumVersion, securityPatchLevel, and deviceThreatProtectionRequiredSecurityLevel — but no firmwareBuildVersion or knoxVersion attribute.

This means your compliance gap is structural, not configurational. You cannot close it by adjusting a slider in the MEM admin center.

---

Building the Firmware Inventory Layer Intune Does Not Provide

Closing the firmware visibility gap requires pulling device hardware details from the Microsoft Graph API and correlating them against Samsung's published firmware release data. The Graph API exposes the androidSecurityPatchLevel and osVersion properties on managed device objects, but the firmware build string — Samsung's internal PDA code — requires a different approach.

Step one: Export current device firmware strings via Graph API using PowerShell.

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

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

$firmwareReport = $devices | Select-Object `
    DeviceName,
    SerialNumber,
    Model,
    OsVersion,
    AndroidSecurityPatchLevel,
    @{Name='EnrollmentDate'; Expression={$_.EnrolledDateTime}},
    @{Name='LastSync'; Expression={$_.LastSyncDateTime}},
    UserPrincipalName

$firmwareReport | Export-Csv -Path ".\Samsung_Firmware_Inventory_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Write-Host "Exported $($firmwareReport.Count) Samsung devices to firmware inventory report."

This gives you the OS-layer view. The OsVersion field contains the Android version, and AndroidSecurityPatchLevel gives you the SPL date. What it does not give you is the Samsung firmware build identifier.

Step two: Use Intune custom device attributes or a managed app to surface the Samsung build number.

Samsung's Build.DISPLAY string (accessible via Android's android.os.Build API) contains the full firmware build identifier in the format G998BXXU5CVJA — where the character sequence encodes the model, region, bootloader revision, and build date. You can surface this via a custom compliance script deployed through Intune's custom compliance policy feature.

// Intune Device Compliance — Samsung Firmware Gap Analysis
// Run in Log Analytics workspace connected to Intune Diagnostic Settings

IntuneDeviceComplianceOrg
| where OSDescription contains "Android"
| extend ManufacturerField = tostring(parse_json(DevicePropertiesJSON).manufacturer)
| where ManufacturerField == "samsung"
| project
    DeviceName,
    UPN,
    OSVersion,
    LastContact,
    ComplianceState,
    OS = OSDescription
| join kind=leftouter (
    IntuneDevices
    | project DeviceName, SerialNumber, Model, AndroidSecurityPatchLevel
) on DeviceName
| where LastContact < ago(7d)
| order by LastContact asc

Step three: Build a KQL query that flags devices where SPL age exceeds your policy threshold.

// Samsung SPL Currency Check — flag devices outside 60-day SPL window
// Run in Microsoft Sentinel or Log Analytics with Intune data connector enabled

let SPLThresholdDays = 60;
let today = now();

IntuneDeviceComplianceOrg
| where OSDescription has "Android"
| extend SPLDate = todatetime(SecurityPatchLevel)
| extend SPLAgeDays = datetime_diff('day', today, SPLDate)
| extend FirmwareRisk = case(
    SPLAgeDays > SPLThresholdDays, "HIGH",
    SPLAgeDays > 30, "MEDIUM",
    "LOW"
)
| where FirmwareRisk != "LOW"
| project
    DeviceName,
    UserPrincipalName,
    OSVersion,
    SecurityPatchLevel,
    SPLAgeDays,
    FirmwareRisk,
    ComplianceState,
    LastContact = LastContactDateTime
| order by SPLAgeDays desc

This query surfaces devices where the SPL gap creates audit exposure, segmented by risk tier. It does not replace firmware build validation, but it gives your security operations team a daily actionable view without requiring custom tooling.

---

Decoupling Firmware Updates from OS Update Rings

The default Intune Android Enterprise update policy applies a single update window to both OS updates and system app updates. Samsung firmware updates — delivered via Samsung's FOTA (Firmware Over The Air) service — can be managed separately through the Samsung Knox Manage integration or through Intune's OEMConfig profile using Samsung's OEMConfig schema.

The operational risk of conflating these two update channels is concrete: a Samsung firmware update that includes a bootloader revision will trigger a device reboot sequence that is longer than a standard OS patch reboot. If this occurs during a business-critical window — a clinical shift handover in healthcare, a trading session in finance — it violates your change management SLA even if the Intune update policy technically complied with the configured maintenance window.

The correct architecture separates three distinct update rings:

1. Android OS security patch ring — managed via Intune's Android Enterprise system update policy. Set to automatic with a defined maintenance window (typically 02:00–04:00 local device time).

1. Samsung firmware/FOTA ring — managed via Knox Manage or OEMConfig. This ring should have a separate, longer deferral period (14–21 days post-Samsung release) to allow your team to validate the firmware build against Samsung's release notes before broad deployment.

1. Knox security policy version — managed via Knox Platform for Enterprise enrollment. KPE policy versions must be validated against your MDM policy schema before deployment; a KPE version mismatch can cause Knox container policies to fail silently.

Separating these rings requires Knox Manage licensing (included in Knox Suite) or a Knox API integration. If your organization is running Samsung devices on standard Intune Android Enterprise enrollment without Knox Suite, you are managing only ring one. Rings two and three are unmanaged.

---

Firmware Rollback Risk and the Bootloader Lock Problem

This is the operational risk that generic Samsung documentation consistently underemphasizes. Samsung devices implement a rollback prevention counter in the bootloader. Each time a firmware update increments the bootloader version, the device permanently records that version as the minimum allowed. Flashing an older firmware build — even through Samsung's official Odin tool — will fail if the bootloader version in the target firmware is lower than the device's recorded minimum.

In enterprise deployments, this creates a specific failure scenario: a firmware update is pushed via Knox Manage or FOTA, the update includes a bootloader revision, a subset of devices encounter a post-update issue (Knox attestation failure, app compatibility regression, carrier connectivity problem), and your team attempts to roll back to the previous firmware build. The rollback fails silently on devices where the bootloader has already incremented.

Mitigation requires pre-deployment validation:

• Maintain a firmware staging group of 5–10 devices per model variant. Deploy new firmware to this group 14 days before broad rollout.
• Document the bootloader version string for each firmware build before deploying. Samsung's firmware release notes include this in the AP package metadata.
• If a firmware build includes a bootloader increment, treat it as a one-way gate. Your rollback plan must account for the fact that affected devices cannot return to the previous firmware state.
• Use Knox Attestation API responses (via Knox SDK or Knox Manage reporting) to validate that the firmware chain of trust is intact post-update before marking devices compliant.

---

Governance Controls for Regulated Environments

In regulated environments, firmware version currency is increasingly a named control, not an implied one. NIST SP 800-124 Rev. 2 (Guidelines for Managing the Security of Mobile Devices in the Enterprise) explicitly addresses firmware integrity as a separate concern from OS patch management. If your organization operates under FedRAMP, CMMC Level 2+, or HIPAA Security Rule technical safeguard requirements, your auditors may request evidence of firmware version control that your current Intune compliance reports cannot produce.

Governance actions that close this gap:

• Define firmware currency in your MDM policy documentation as a separate control from Android SPL compliance. Reference the Samsung firmware release cadence (typically monthly for flagship models, quarterly for mid-range) in your policy.
• Create a firmware change record for each firmware build deployed across your fleet. This record should include: firmware build string, bootloader version, Knox security policy version, deployment date, affected device models, and validation results from your staging group.
• Map Knox Attestation results to your compliance framework. Knox Attestation provides a hardware-rooted attestation of the device's firmware integrity. This attestation result — available via Knox SDK or Knox Manage API — is a stronger control than Play Integrity API attestation for regulated workloads.
• Establish a firmware exception process. Carrier-locked devices that cannot receive firmware updates on your standard cadence (due to carrier validation delays) require a documented exception with compensating controls — typically enhanced conditional access restrictions or network segmentation.

---

Recommendations for Production Deployment

Before implementing any firmware management changes in production, validate the following:

• Confirm Knox Suite licensing for all Samsung devices you intend to manage at the firmware layer. Knox Manage and Knox Platform for Enterprise are licensed separately from Intune.
• Audit your current device model and CSC variant distribution. Firmware management policies must account for carrier-locked variants separately from unlocked devices. A single Intune device configuration profile cannot address both without OEMConfig customization.
• Test OEMConfig schema deployment in a non-production tenant or with a pilot group before broad rollout. Samsung's OEMConfig schema version must match the Knox version on the target devices; schema mismatches produce silent failures in Intune.
• Integrate Intune Diagnostic Settings with Log Analytics before deploying the KQL queries above. The IntuneDeviceComplianceOrg table is only populated if diagnostic settings are configured to export compliance data to a Log Analytics workspace.
• Document your firmware staging process as a formal change management procedure. This documentation is the evidence your auditors will request when firmware integrity is a named control in your compliance framework.

---