Android
AuraScore 83/100

Android EMM and Device Policy Governance Matrix

Construct a Zero-Trust Android Enterprise mobility management policy matrix.

Use this template when designing Android Enterprise and EMM deployment strategies for professional services clients with strict compliance regimes. It produces an enforceable device-policy matrix across corporate-owned and BYOD fleets.

Template

Role: Principal Mobile Security Consultant specializing in Android Enterprise and EMM implementations.

Context

  • Client Enterprise Domain: {{client_enterprise_domain}}
  • Target Android Versions: {{target_android_versions}}
  • EMM Solution Provider: {{emm_solution_provider}}
  • Regulatory Compliance Frameworks: {{compliance_frameworks}}
  • Fleet Ownership Model: {{fleet_ownership_model}}
  • BYOD Security Tier: {{byod_security_tier}}

Task

Deliver an Android Enterprise compliance matrix evaluating management modes, runtime permission enforcement, hardware attestation, and data loss prevention policies for client infrastructure.

Method

  1. Review statutory security requirements across {{compliance_frameworks}} applicable to {{client_enterprise_domain}}.
  2. Determine policy bifurcation between work profile separation and fully managed modes based on {{fleet_ownership_model}}.
  3. Map hardware key attestation and SafetyNet/Play Integrity verification levels supported across {{target_android_versions}}.
  4. Establish network security configuration baselines including certificate pinning and private DNS lockdown.
  5. Configure containerized Data Loss Prevention (DLP) parameters supported by {{emm_solution_provider}}.
  6. Evaluate cross-profile data sharing restrictions, clipboard boundaries, and biometric authentication thresholds.
  7. Cross-reference runtime permission delegation policies for custom line-of-business applications.
  8. Synthesize the findings into an actionable policy decision matrix with compliance justification.

Constraints

  • MUST specify the exact Android Management API / EMM policy key for each control.
  • MUST NOT recommend deprecated Device Administrator APIs under any circumstance.
  • Controls MUST clearly distinguish between Work Profile (BYOD) and Device Owner (COBO/COPE) scopes.
  • Fallback policies must be supplied for devices lacking hardware-backed Keystore or StrongBox.

Output format

  • Regulatory Baseline Summary (150 words)
  • Policy Governance Matrix: Markdown table containing [Policy Category, Android API Policy Key, Scope (DO/WP), Default Value, Enforcement Severity (Mandatory/Advisory), Compliance Mapping, Remediation Action]
  • Integrity Attestation Specification (bulleted security requirements)
  • Client Rollout Gate Checklist (ordered phase list)

Self-review

  • Confirm that no deprecated Device Admin APIs appear in the policy keys.
  • Verify every regulatory mandate in {{compliance_frameworks}} is linked to at least one matrix entry.
  • Ensure strict isolation between personal and enterprise scopes is maintained.
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-android
professional-services
android
security
emm