The Android Security Policy lets administrators manage device security, application permissions, privacy controls, lock-screen features, and advanced Android protections from Swif.

Common use cases include:

Important: Some settings apply only to company-owned, fully managed, or dedicated devices. Unsupported settings may be ignored or reported as noncompliant.

Individual settings may have additional operating-system, hardware, or management-mode requirements.

Before deploying the policy:

Security-policy behavior can vary by Android version, device manufacturer, enrollment mode, and hardware capability.

The following baseline is suitable for most company-owned business devices:

Note: Use Developer Settings and Google Play Protect Verify Apps under Advanced Security Overrides as the primary controls. They replace the older Allow Debugging Features and Ensure Verify Apps Enabled settings.

For personally owned devices, review each restriction carefully and limit enforcement to controls required to protect work data.

Prevents users from configuring credentials such as certificate authority certificates in the managed credential store.

When enabled, users cannot install or remove affected credentials through device settings.

Recommended value:

Before enabling this setting, deploy all required Wi-Fi, VPN, authentication, and application certificates through Swif.

Controls whether users can enable developer and debugging features, including USB debugging.

This is a legacy Android policy field. Use Advanced Security Overrides > Developer Settings for current deployments.

If developer access is required, assign a separate policy to authorized developers instead of enabling it for the entire organization.

Determines the default response to runtime permission requests.

Recommended value: PROMPT

Using GRANT globally can give applications unnecessary access. Using DENY globally can prevent required applications from functioning.

On Android 12 or later, some sensitive permissions can be automatically granted only on fully managed devices. These include camera, microphone, location, activity-recognition, body-sensor, and certain SMS permissions. See Google’s Android Management API permission policy documentation.

Controls whether device encryption is required.

Recommended value for company-owned devices: ENABLED_WITH_PASSWORD

Modern Android devices commonly use file-based encryption by default, but selecting an encryption policy communicates the management requirement and allows unsupported or noncompliant devices to be identified.

Test this setting on the organization’s supported device models. Available encryption behavior can depend on the operating system and hardware.

Force-enables application verification so users cannot disable it.

This setting is deprecated in the Android Management API. Use Advanced Security Overrides > Google Play Protect Verify Apps instead.

For new policies, configure:

Google documents the replacement under Advanced Security Overrides.

Controls whether Android can display an interface that lets the user choose a private-key alias.

This setting does not take effect when certificate selection is delegated to the Swif agent. Because Swif uses delegated certificate selection on managed devices, changing this setting normally has no effect.

Recommended value: Disabled

Prevents screen capture on the affected management scope.

When enabled, users may be prevented from:

On work-profile devices, the effective scope depends on the enrollment and device ownership mode.

Enable this setting when managed applications display sensitive information. Test screen sharing, remote support, accessibility, conferencing, and authentication workflows before broad deployment.

Prevents location sharing on the device or managed scope.

Enable this setting when location sharing is prohibited by organizational security or privacy requirements.

Before enabling it, test applications that rely on location, including:

This setting controls location sharing. Runtime location access should also be managed through application permissions.

Permission Grants explicitly set the behavior for individual Android permissions or permission groups.

Each entry contains:

These entries override the policy’s Default Permission Policy.

Important: Permission Grants in the Android Security Policy are policy-level rules. They apply to the selected permission across managed applications. They do not target one specific application because this policy does not contain a package-name field.

For app-specific permission rules, configure permissions through the applicable Android application policy.

Enter an Android permission or permission group.

Common values include:

Android storage permissions have changed across Android releases. Applications targeting newer Android versions may use scoped storage or newer media permissions instead of READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE.

Use the exact Android permission name declared by the application.

Avoid automatically granting sensitive permissions across all managed applications unless every affected application requires the access.

Example: To prevent managed applications from accessing the camera by default, add:

Explicit permission entries take precedence over Default Permission Policy. Google documents this order in its Permission Grant reference.

Disables the Android lock screen.

This setting is supported only in dedicated-device management mode, such as a purpose-built kiosk.

Recommended value for normal user devices: Disabled

Warning: Do not enable this setting on ordinary employee devices. Disabling the lock screen can remove an important layer of protection against unauthorized physical access.

Disables selected features on a secure lock screen.

Recommended configuration for devices containing sensitive data:

Select BIOMETRICS only when organizational requirements prohibit biometric authentication. Otherwise, disabling biometrics may reduce usability and cause users to enter their passcodes more frequently.

Use ALL_FEATURES cautiously because it can automatically affect keyguard features introduced in future Android releases. See Google’s Keyguard Disabled Feature reference.

Advanced Security Overrides provide newer and more granular Android security controls.

Google notes that these settings are not required in every deployment. Configure them only when they support a documented organizational requirement.

Controls Android Common Criteria Mode.

Common Criteria Mode is supported only on company-owned devices running Android 11 or later.

It enables stricter security behavior involving cryptography, network certificate validation, policy integrity, and protected configuration storage.

Warning: Enable Common Criteria Mode only when specifically required. It can affect normal device use. Disabling it after it was enabled can remove user-configured Wi-Fi networks and require some enterprise Wi-Fi networks to be configured again.

Controls access to developer options and safe boot.

Recommended value: DEVELOPER_SETTINGS_DISABLED

This setting replaces the legacy Allow Debugging Features control.

On a personally owned device with a work profile, this policy cannot disable safe boot. Android can report a management-mode noncompliance result for that portion of the setting.

Controls whether Google Play Protect application verification is enforced.

Recommended value: VERIFY_APPS_ENFORCED

This setting replaces Ensure Verify Apps Enabled.

Play Protect helps detect potentially harmful applications, but it does not replace managed application allowlisting, endpoint security, or application-risk review.

Controls installation of applications from unknown or untrusted sources.

Recommended values:

Avoid ALLOW_INSTALL_DEVICE_WIDE unless there is a documented requirement and additional application-security controls are in place.

Controls Memory Tagging Extension, a hardware-assisted protection that can help detect certain memory-safety errors.

Although the policy field may be presented for earlier releases, enforced MTE management requires:

MTE_ENFORCED is supported on fully managed devices and company-owned devices with a work profile. MTE_DISABLED applies only to fully managed devices.

A restart is required after changing the MTE policy. On unsupported hardware or management modes, Android reports the applicable noncompliance result.

Recommended value:

See Google’s MTE policy documentation.

Controls Android content protection, which scans for deceptive applications.

Content protection is supported on Android 15 or later.

Recommended value on supported devices:

Devices running an earlier Android version may report an API-level noncompliance result.

Specifies personal-profile applications that can read notifications generated by the work profile.

Enter each application’s Android package name, for example:

By default, personal applications other than eligible system applications cannot read work notifications.

Leave this list empty unless a specific, reviewed application requires cross-profile notification access.

Security warning: Work notifications can contain names, message previews, document information, authentication prompts, and other sensitive data. Allowing a personal application to read them creates a cross-profile data-sharing path.

For company-owned Android devices:

For BYOD devices with a work profile:

After assigning the policy:

Test both the work and personal profiles when using a work-profile enrollment.

Check the following:

A policy can be delivered successfully even when one field is unsupported for that device or management mode.

On personally owned work-profile devices, safe boot cannot be disabled through this setting.

Policy-level Permission Grants override the default. An app-specific permission rule can provide an additional, more specific override.

Permission Grants in this policy do not contain an application package name. Therefore, an explicit grant can affect the selected permission across managed applications.

Remove the global grant and configure the permission through the applicable application-specific policy.

This is expected when certificate selection is delegated to the Swif agent. The Private Key Selection Enabled setting has no effect while the delegation is active.

Disable Keyguard is supported only in dedicated-device management mode.

For ordinary user devices, keep the lock screen enabled and configure individual Keyguard Disabled Features instead.

Confirm that:

Not every Android 14 or later device includes MTE-compatible hardware.

Confirm that the device runs Android 15 or later. Earlier versions do not support this policy and may report an API-level noncompliance result.

Common Criteria Mode applies stricter security and certificate behavior.

If connectivity is affected:

Disabling Common Criteria Mode after it was enabled can remove user-configured Wi-Fi networks.

Only allow this access after reviewing the application’s security and data-handling practices.

The Android Security Policy can support organizational controls for:

For a secure deployment:

This policy supports security and compliance objectives, but it does not independently make an organization compliant with a particular standard or framework.

The Android Security Policy provides centralized control over Android security, privacy, permissions, and lock-screen behavior.

For most company-owned devices: