[Epic] Deliver consent-based remote policy management for delegated administrators

[ShalomMaman]

Product goal

Allow an account owner/device custodian to nominate a trusted filtering administrator who can manage an explicitly approved subset of Device Guard policy remotely without learning or entering the on-device administrator PIN. The experience should resemble a focused Family Link-style relationship while preserving Device Guard's custom DPC, dedicated-device, kiosk and local-recovery boundaries unless the architecture ADR deliberately chooses a migration.

Important

This is an epic and release gate, not a single implementation issue. No production remote-write path should be enabled before the architecture, threat/privacy, identity, authorization and signed-policy work below is reviewed. Read-only fleet visibility must be proven before policy editing is exposed.

Terminology

• Device Owner means Android's technical DPC role.
• Account owner or device custodian means the human who controls delegation.
• Delegated filtering administrator means the remote human granted a limited policy role.
• Release/operator and read-only support remain separate roles and must not collapse into filtering administration.

Architecture decision gate

The provisional product direction is to extend the existing Device Guard DPC with a small authenticated control plane that publishes signed desired-policy revisions and reuses the current serialized, read-back-verified reconciliation engine. This is not final until #43 is approved.

The ADR must compare:

1. Android Management API / Android Device Policy, including current permissible-use and commercial EMM requirements, migration/reset cost, supported policy coverage and the replacement of the custom DPC enforcement path.
2. Extension of the existing Device Guard DPC.
3. Maintained open-source EMM/control-plane candidates, including current code, releases, security posture, license, Android support, operational burden and exit strategy.

Do not choose from popularity, stars or memory alone.

Non-negotiable safety invariants

• Delegation is explicit, visible and revocable by the account owner/device custodian.
• A remote actor never receives the local PIN, recovery code, device credentials, private keys or APK/update signing material.
• Roles are least-privilege and independently authorized on every server request.
• Sensitive actions require recent strong authentication; passkey/MFA requirements are defined per capability.
• Every enrolled device authenticates independently and verifies every policy envelope before Android policy code sees it.
• Remote policy is a signed, versioned, schema-validated latest desired state, not an arbitrary or unbounded command queue.
• Policy revisions are target-bound, monotonically ordered, authorization-epoch-bound, time-bounded and replay-protected.
• A push transport may wake the device, but is never the source of policy authority.
• Offline operation, service failure, expired authentication or an invalid revision leaves the last-known-good verified policy active. This is fail-stable behavior; it must not be described as automatically tightening or locking the device.
• Every accepted remote change flows through the existing shared serialized policy engine and Android read-back verification. There is no second enforcement path.
• Requested, downloaded, accepted, applying, verified, rejected, failed and superseded states remain distinguishable. Success is never reported before device read-back.
• Conflict rules for local emergency recovery, maintenance windows, active kiosk state, local owner actions and remote desired state are deterministic and tested.
• No remote shell, arbitrary script, arbitrary intent execution, covert surveillance or general-purpose command channel is introduced.
• The owner receives a persistent indication of who manages the device, what that role can do and the last device-verified result.
• The proven local recovery path remains available until remote recovery has separate supported-hardware evidence.

Precise revocation semantics

Revocation cannot be claimed as device-confirmed while a device is offline.

1. The service immediately invalidates the actor's role, sessions, invitations and pending/unissued changes.
2. Any desired revision issued under an obsolete authorization epoch is invalid.
3. On reconnect, the device must verify the current authorization epoch before accepting a newer desired-policy revision.
4. A stale queued request or previously revoked actor action can never become valid again.
5. The console distinguishes server-side revocation from device-confirmed revocation.

Cryptographic separation

Use distinct keys and access boundaries for:

• production APK signing;
• signed software-update metadata;
• remote desired-policy signing;
• each enrolled device's authentication identity;
• test, staging and production environments.

No key is reused across these purposes. Rotation, bounded overlap, backup, revocation and compromise procedures must be designed and tested independently.

Privacy and abuse boundary

Collect only the fleet, authorization, audit and policy state required to operate the service. Do not collect browsing history, message or contact content, location, screenshots, app content, kiosk URL paths/queries, local PINs, recovery codes or device credentials by default.

Audit history should be append-only, tamper-evident and verifiable, with documented retention, export, deletion/anonymization and incident-hold behavior. Do not promise permanent immutability that conflicts with privacy obligations.

Complete the applicable Israeli privacy and accessibility review before customer deployment.

Staged product scope

Phase 1 — read-only

Prove identity, tenant isolation, roles, privacy-safe fleet reporting and truthful requested-versus-verified state without any remote mutation.

Phase 2 — minimal write pilot

Expose only:

• allow/block policy for ordinary user applications; and
• a small enumerated set of low-risk presets with proven recovery behavior.

The first write pilot explicitly excludes kiosk changes, ADB/developer/USB controls, network/VPN/account changes that could disconnect recovery, ownership transfer, account recovery, local recovery operations, raw system-package editing, unknown OEM risk acceptance and arbitrary commands. Any expansion requires a separate reviewed issue, recent strong authentication and physical recovery evidence.

Work breakdown

Architecture, privacy and authorization

• ADR: choose the delegated remote policy-management architecture #43 — ADR: choose the delegated remote policy-management architecture.
• Threat-model delegated administration and document the privacy data flow #44 — Threat-model delegated administration and document the privacy data flow.
• Specify owner consent, delegated roles, strong authentication and revocation #45 — Specify owner consent, delegated roles, strong authentication and revocation.
• Design enrolled-device identity and separate remote-policy signing keys #46 — Design enrolled-device identity and separate remote-policy signing keys.
• Specify a signed desired-state policy protocol with replay protection #47 — Specify a signed desired-state policy protocol with replay protection.

Read-only foundation

• Design privacy-preserving fleet health and staged rollout visibility #24 — Design privacy-preserving fleet health and staged rollout visibility.
• Implement an authenticated read-only console for verified fleet state #48 — Implement an authenticated read-only console for verified fleet state.

Controlled remote write

• Implement a minimal consent-based remote application-policy pilot #49 — Implement a minimal consent-based remote application-policy pilot.

Audit, proof and operations

• Implement owner-visible tamper-evident audit history and privacy lifecycle #50 — Implement owner-visible tamper-evident audit history and privacy lifecycle.
• Prove delegated remote policy safety in emulator and physical-device tests #51 — Prove delegated remote policy safety in emulator and physical-device tests.
• Write and rehearse delegated-management incident, recovery and exit runbooks #52 — Write and rehearse delegated-management incident, recovery and exit runbooks.

Existing production blockers

The remote-management pilot remains blocked by the relevant production foundations:

• Freeze production identity and external signing operations #25 — Final production identity and external signing operations.
• Establish the supported Android and OEM device matrix #23 — Supported Android/OEM device matrix.
• Validate kiosk containment and recovery on physical devices #22 — Physical kiosk containment and recovery validation.
• Build repeatable Device Owner provisioning and operator runbooks #28 — Repeatable Device Owner provisioning and operator runbooks.

Recommended execution order

1. Continue the P0 physical-device, identity/signing and provisioning foundations in Validate kiosk containment and recovery on physical devices #22, Establish the supported Android and OEM device matrix #23, Freeze production identity and external signing operations #25 and Build repeatable Device Owner provisioning and operator runbooks #28. Architecture and threat-model documentation may proceed in parallel, but no remote write implementation should bypass those blockers.
2. Approve ADR: choose the delegated remote policy-management architecture #43 and complete Threat-model delegated administration and document the privacy data flow #44–Specify a signed desired-state policy protocol with replay protection #47.
3. Complete the minimized fleet model in Design privacy-preserving fleet health and staged rollout visibility #24 and prove the read-only console in Implement an authenticated read-only console for verified fleet state #48.
4. Have the audit path in Implement owner-visible tamper-evident audit history and privacy lifecycle #50 ready before enabling policy writes.
5. Implement only the limited pilot in Implement a minimal consent-based remote application-policy pilot #49.
6. Complete the automated and supported-hardware evidence in Prove delegated remote policy safety in emulator and physical-device tests #51, followed by an independent security review with no unresolved P0/P1 finding.
7. Rehearse Write and rehearse delegated-management incident, recovery and exit runbooks #52 before enrolling pilot customers.

Epic acceptance gates

• The architecture ADR is approved from current official and project evidence.
• Threat model and privacy data-flow diagram are reviewed before remote writes.
• Account, invitation, role, passkey/MFA, session, revocation, recovery and ownership-transfer flows are specified and negatively tested.
• Device identity and all signing purposes are cryptographically separated with tested rotation and revocation.
• The signed desired-state protocol enforces target binding, monotonic revision, authorization epoch, expiry, replay protection, key rotation and last-known-good behavior.
• The read-only console proves authentication, tenant isolation and truthful verified state before a write editor exists.
• The first write pilot exposes only application filtering and approved low-risk presets; lockout-prone capabilities are technically absent.
• Every remote change uses the existing serialized reconciliation engine and Android read-back verification.
• Owner-visible audit history identifies actor, device, revision, redacted change summary, server request time and device-verified result without sensitive payload leakage.
• Emulator tests cover success, stale revision, invalid signature, replay, expiry, offline operation, revoked administrator, stale authorization epoch, conflict and interrupted reconciliation.
• Supported physical-device evidence proves remote apply, reboot persistence, offline behavior, kiosk containment, revocation and local recovery.
• Security review finds no unresolved P0/P1 issue before pilot enrollment.
• Runbooks cover outage, compromised account/session/device/policy key, stuck policy, rollback-by-higher-corrective-revision, breach response, recovery and service exit/migration.
• Applicable Israeli privacy and accessibility review is complete before customer deployment.

Non-goals

• Silent surveillance or covert administration.
• Bypassing Android enrollment, account security, factory-reset protections or owner consent.
• Replacing the local recovery path before remote recovery is independently proven on supported hardware.
• Building a general-purpose EMM before the focused Device Guard use case is validated.
• Claiming resistance to recovery reset, bootloader unlock or firmware flashing beyond the documented hardware boundary.

Hebrew summary

זהו אפיק לניהול סינון מרחוק בהסכמה: בעל החשבון ממנה מנהל מוגבל בלי למסור את הקוד המקומי. מתחילים בהחלטת ארכיטקטורה, מודל איומים והרשאות; אחר כך מוכיחים לוח צפייה בלבד; ורק לבסוף פותחים פיילוט מצומצם לחסימה ואישור של אפליקציות. כל שינוי נחתם, נמשך על ידי המכשיר, עובר דרך מנוע המדיניות הקיים ומסומן כהצלחה רק לאחר אימות Android. ניתוק או תקלה משאירים את המדיניות המאומתת האחרונה, וביטול מנהל מונע מכל בקשה ישנה להתעורר מחדש.