Skip to content

ADR: choose the delegated remote policy-management architecture #43

Description

@ShalomMaman

Parent epic: #41

Decision required

Choose the architecture for consent-based delegated remote policy management before any production write path is implemented.

Candidates to compare

  1. Android Management API / Android Device Policy — capability fit, current production eligibility and permissible-use requirements, commercial EMM obligations, migration and reset impact, policy coverage, operational model, and the consequence that Android Device Policy replaces the custom DPC enforcement path.
  2. Extend the existing Device Guard DPC — a small authenticated control plane that publishes signed desired-policy revisions to the current Device Owner app and reuses its serialized, read-back-verified reconciliation engine.
  3. Maintained open-source EMM/control-plane projects — include Headwind MDM and any other credible current candidates; inspect code and release activity, security posture, license, Android-version support, deployment burden, custom-DPC compatibility, and exit strategy.

Required analysis

  • Product fit for Device Guard's focused filtering and kiosk boundaries.
  • Trust boundaries, identity, authentication, transport, policy signing, audit and recovery.
  • Migration cost for already enrolled devices and consequences for the final package/signing identity.
  • Hosting, support, compliance, vendor dependency and long-term ownership cost.
  • License compatibility and ability to leave or migrate later.
  • Explicitly rejected alternatives and objective triggers for reconsidering the decision.

Use current official documentation and current project/release evidence. Do not decide from popularity, stars or memory alone.

Acceptance criteria

  • ADR records the chosen option, rejected options and evidence for each decision.
  • Android Management API eligibility and permissible-use constraints are verified from official sources.
  • The analysis states whether the existing custom DPC can remain the enforcement component under each option.
  • At least one maintained open-source candidate is inspected at code, release, license and operational levels.
  • Trust boundaries, migration, cost, recovery, exit and long-term maintenance are compared consistently.
  • The decision is reviewed before implementation issues introduce a remote write path.

Non-goals

  • Implementing a server, console or device protocol.
  • Treating a demo or project popularity as production evidence.

Hebrew summary

יש לבחור ולתעד תחילה האם להרחיב את ה־DPC הקיים, לעבור ל־Android Management API או לאמץ תשתית קוד פתוח. ההחלטה חייבת להתבסס על מקורות עדכניים, אבטחה, עלות, הגירה ויכולת יציאה.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationpriority: P1High priorityroadmapTracked on the public production roadmapsecuritySecurity boundary or hardening work

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions