What "Stay On" Actually Controls — And What It Doesn't

The Stay On setting in Intune's Android Enterprise Dedicated Device configuration profile maps to the Android STAY_ON_WHILE_PLUGGED_IN global setting. When enabled, it instructs the device to suppress the normal display timeout while connected to AC power, USB, or wireless charging — depending on which charging states you select.

That is the complete scope of the setting.

It does not suppress the lock screen timeout. It does not prevent the device from entering a locked state after a period of inactivity. It does not control whether the kiosk application session remains active and visible, or whether the system presents a lock screen on top of it. On many Android Enterprise Dedicated Device deployments, the device stays visually "on" — backlight active, screen illuminated — while simultaneously presenting a lock screen or PIN prompt that obscures the kiosk application entirely.

This distinction matters enormously in practice. A warehouse kiosk running a receiving application, a hospital registration terminal, or a retail self-checkout display can appear to be functioning normally from a distance while actually sitting on a locked screen that requires staff intervention to restore. Worse, in configurations where the lock screen is suppressed but session timeout is not, the inverse problem occurs: the screen stays on, the application stays visible, and sensitive data — patient names, transaction records, inventory details — remains exposed to anyone who walks past.

---

The Policy Surface Map for Dedicated Device Kiosks

Closing the gap requires understanding which Intune policy types control which behavioral layers. There are four distinct surfaces in play for an Android Enterprise Dedicated Device deployment:

1. Device Configuration Profile — Kiosk Mode Settings This is where Stay On lives. It also controls which applications are pinned to the kiosk launcher, whether the status bar is visible, and whether the volume buttons are accessible. It does not control authentication behavior.

2. Device Restrictions Profile This profile controls screen timeout duration, lock screen behavior, and whether the device requires a PIN or password to unlock. On Dedicated Devices, many of these settings interact with the managed launcher in non-obvious ways. Specifically, the Screen timeout setting here controls when the device enters a locked state — independent of whether Stay On is suppressing the display timeout.

3. OEMConfig For manufacturers like Zebra, Honeywell, and Datalogic, OEMConfig profiles expose device-specific power management controls that Android Enterprise APIs do not surface. This includes granular control over display brightness schedules, thermal management behavior, and charging-state-specific screen policies. If your kiosk fleet is OEM-specific, OEMConfig is not optional — it is the only way to reach certain behavioral controls.

4. Managed Google Play — Application-Level Session Management The kiosk application itself may expose session timeout and auto-logout controls. These operate entirely within the application layer and are not visible to Intune policy. If the application has a configurable idle timeout, that setting must be aligned with the device-level policy, or the two will conflict in ways that are difficult to diagnose remotely.

---

Where Compliance Controls Collide With Default Behavior

SOC 2 Type II, HIPAA Security Rule, and PCI-DSS each contain physical safeguard requirements that directly implicate unattended kiosk screen behavior.

Under PCI-DSS v4.0 Requirement 9.4, physical access controls must prevent unauthorized individuals from gaining access to systems in the cardholder data environment. An unattended kiosk displaying transaction data with no automatic session termination or screen lock is a direct control gap against this requirement. PCI-DSS does not specify a timeout value, but auditors routinely flag unattended terminals with visible cardholder data as a finding.

Under HIPAA's Physical Safeguard standard (45 CFR §164.310), covered entities must implement workstation use policies that specify the proper functions performed on workstations, the manner in which those functions are performed, and the physical attributes of the surroundings. A kiosk terminal displaying patient registration data in a waiting area, with no automatic screen lock or session termination, creates a straightforward addressable implementation specification gap.

Under SOC 2 CC6.1, the common criteria require that logical access security software, infrastructure, and architectures have been implemented to support restriction of access. Physical exposure of session data on unattended terminals is routinely interpreted by SOC 2 auditors as a failure of this control, particularly when the device management platform had the capability to enforce session controls and did not.

The compliance risk is not theoretical. It is a configuration gap that auditors are trained to look for, and that Intune's default Dedicated Device profile does nothing to close automatically.

---

Building the Layered Policy Configuration

The correct architecture for an always-on kiosk that does not create a physical security gap requires three coordinated policy elements.

Element 1: Stay On with Charging State Scoping

In the Device Configuration Profile under Kiosk settings, enable Stay On only for the charging states that apply to your deployment. If your kiosks are always plugged into AC power, enable AC charging only. Enabling all charging states on a device that occasionally runs on battery introduces display behavior that may not be appropriate for mobile-adjacent deployments.

Element 2: Screen Timeout Aligned to Physical Security Requirements

In the Device Restrictions profile, set the Screen timeout to a value that reflects the actual physical security requirement — not the user experience preference. For a kiosk in a public-facing area, this is typically 30–60 seconds of inactivity. For a back-office terminal with controlled physical access, 5–10 minutes may be defensible.

The important operational point: on Dedicated Devices running a managed launcher, the screen timeout triggers the lock screen, not a display-off state, when Stay On is active. This means the screen remains illuminated but the kiosk application is no longer visible. This is the intended behavior — but it must be tested explicitly, because the interaction between Stay On and screen timeout varies by Android version and OEM firmware.

Element 3: Lock Screen Configuration

On Dedicated Devices, the lock screen behavior is controlled by the Password settings in the Device Restrictions profile. For shared kiosk deployments where staff must be able to restore the session without individual credentials, a shared PIN or the managed launcher's built-in unlock mechanism is typically used. The key requirement is that the lock screen is actually enforced — not suppressed — and that the unlock mechanism is documented in the physical security policy.

---

Querying Your Fleet for Exposure: KQL and PowerShell

Identifying which devices in your fleet have Stay On enabled without a corresponding screen timeout policy requires querying across Intune's reporting surface. The following queries provide a starting point.

KQL — Intune Device Configuration Policy Assignment Report (Log Analytics)

// Identify devices assigned a Kiosk profile but no Device Restrictions profile
// Requires Intune Diagnostic Settings forwarded to Log Analytics
IntuneDeviceCompliancePolicies
| where PolicyType == "deviceConfiguration"
| extend ProfileType = tostring(parse_json(PolicyDetails).profileType)
| where ProfileType == "androidDeviceOwnerGeneralDeviceConfiguration"
| summarize AssignedPolicies = make_set(PolicyName) by DeviceId, DeviceName
| where not(AssignedPolicies has "Restrictions")
| project DeviceId, DeviceName, AssignedPolicies
| order by DeviceName asc

KQL — Surface Dedicated Devices with No Screen Timeout Configured

// Query device configuration profile settings for screen timeout
// Requires IntuneDeviceConfigurationSettingStates table in Log Analytics
IntuneDeviceConfigurationSettingStates
| where SettingName == "screenTimeoutInSeconds"
| where SettingValue == "0" or isempty(SettingValue)
| join kind=inner (
    IntuneDevices
    | where OperatingSystem == "Android"
    | where DeviceOwnershipType == "Corporate"
) on DeviceId
| project DeviceId, DeviceName, SettingName, SettingValue, LastReportedDateTime
| order by LastReportedDateTime desc

PowerShell — Export Dedicated Device Kiosk Profile Assignments via Microsoft Graph

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

$profiles = Get-MgDeviceManagementDeviceConfiguration -Filter "odataType eq '#microsoft.graph.androidDeviceOwnerGeneralDeviceConfiguration'"

foreach ($profile in $profiles) {
    $assignments = Get-MgDeviceManagementDeviceConfigurationAssignment -DeviceConfigurationId $profile.Id
    $settings = $profile.AdditionalProperties

    # Check for Stay On enabled and screen timeout absent or zero
    $stayOnEnabled = $settings["stayOnModes"] -ne $null -and $settings["stayOnModes"].Count -gt 0
    $screenTimeout = $settings["screenTimeoutInSeconds"]

    if ($stayOnEnabled -and ($screenTimeout -eq 0 -or $null -eq $screenTimeout)) {
        [PSCustomObject]@{
            ProfileName      = $profile.DisplayName
            ProfileId        = $profile.Id
            StayOnModes      = ($settings["stayOnModes"] -join ", ")
            ScreenTimeout    = if ($null -eq $screenTimeout) { "Not configured" } else { $screenTimeout }
            AssignmentCount  = $assignments.Count
        }
    }
} | Export-Csv -Path ".\KioskStayOnGapReport.csv" -NoTypeInformation

Write-Host "Export complete: KioskStayOnGapReport.csv"

Run this export against your tenant before your next compliance review. The output will surface every profile where Stay On is active and screen timeout is either unconfigured or set to zero — the exact combination that creates the physical security gap.

---

Operational Validation After Policy Layering

Deploying the layered policy is not sufficient. The interaction between Stay On, screen timeout, and the managed launcher must be validated on physical hardware before broad rollout.

The validation sequence for each device model in your fleet:

• Confirm the device remains illuminated while plugged in and active — Stay On is functioning.
• Allow the device to sit idle past the configured screen timeout threshold. Confirm the lock screen appears without the display turning off.
• Confirm the kiosk application is not visible behind or through the lock screen.
• Confirm that unlocking the device returns directly to the kiosk application without requiring additional navigation.
• Disconnect AC power and confirm the device's display timeout behavior reverts to the standard Android timeout, not the Stay On behavior.

Document this validation sequence as a formal test case in your change management system. OEM firmware updates have been observed to alter the interaction between Stay On and screen timeout behavior — particularly on Zebra devices following major LifeGuard updates. Revalidation after firmware updates is not optional for compliance-sensitive deployments.

---

Governance Considerations for Physical Security Policy Alignment

The Intune configuration is only one component of the governance requirement. The physical security policy must explicitly address kiosk terminal behavior, and that policy must reference the technical controls that enforce it.

Specifically, the policy documentation should state the maximum inactivity period before session lock, the authentication mechanism required to restore the session, the physical placement requirements for kiosk terminals (line-of-sight, camera coverage, access control zone), and the process for reporting and remediating a terminal found in an unlocked state with data visible.

Without this documentation, the technical control exists in isolation. Auditors reviewing SOC 2 or PCI-DSS compliance will ask for the policy that the technical control enforces. "We configured Intune" is not a policy. The policy must exist independently, reference the technical implementation, and be reviewed on a defined cadence.

---