Skip to main content
New Member
January 9, 2026
Solved

Device financing at scale (10,000+ devices): compliant “restricted mode” on delinquency using Android Enterprise (Device Owner)

  • January 9, 2026
  • 4 replies
  • 1 view

Hi everyone,

I’m building an Android Enterprise device management solution and I want to keep everything fully compliant (Android Enterprise + Google Play policies).

 

Use case: a company provides company-owned devices to customers under a leasing / device financing contract. We need to manage this at scale (10,000+ devices) across multiple customers/tenants. If a customer becomes delinquent, the company needs a temporary restricted mode (e.g., kiosk/limited access) until the account is back in good standing — with clear user notice, grace period, and contractual consent.

 

What we want to control at scale: enrollment, policy assignment, app allow/deny lists, kiosk/lock task mode, updates, compliance reporting, and remote actions aligned with Android Enterprise best practices.

Questions:

  • Is this type of “restricted mode for delinquency” considered acceptable in the Android Enterprise ecosystem when devices are Company-Owned (Device Owner) and the policy is transparent/contractual?
  • For 10,000+ devices, what is the recommended architecture: Android Management API (AMAPI) policies only, or a custom DPC (and why)?
  • For distribution, is the safest path a managed Google Play private app per enterprise/tenant, or another approved approach for large-scale deployments?
  • Any best practices to avoid being flagged by Play Protect / Play policy reviews for legitimate enterprise enforcement features (kiosk, app restrictions, device restrictions), especially at this scale?

I’m not looking to bypass security or do anything hidden; the goal is a compliant enterprise solution.

Thanks for any guidance or official documentation links.

Best answer by Lizzie

Hey @gustavomartinez,

 

Lovely to meet you. 

 

Regarding your question and based on the information you have provided above, this use case isn't allowed under our permissible usage policy for Android Enterprise. You can read more about that here (Developer doc). 

 

I hope this is helpful. 

 

Thanks,

Lizzie

4 replies

Lizzie
LizzieAnswer
Community Manager
January 12, 2026

Hey @gustavomartinez,

 

Lovely to meet you. 

 

Regarding your question and based on the information you have provided above, this use case isn't allowed under our permissible usage policy for Android Enterprise. You can read more about that here (Developer doc). 

 

I hope this is helpful. 

 

Thanks,

Lizzie

Welcome to the Community everyone!Have a question or want to start a conversation, click here.
Level: 4.1: Jelly bean
January 12, 2026

You want a device lock solution :) 

 

Trustonic has been fully onboarded for device lock and should offer what you're after. You can contact them via the form on their website: https://www.trustonic.com/contact/

 

You will not be permitted to build your own unfortunately.

Level 4.4: KitKat
January 12, 2026

Wouldn't be any MDM with a good kiosk mode and disabled safe boot and activated FRP an option in general?

Level: 4.1: Jelly bean
January 12, 2026

Unfortunately permissible usage puts the onus on partners to also not knowingly sell their product for these use cases, reflected in terms of use etc. 

 

As a customer that's a decision you choose to make 

Level 4.0: Ice cream sandwich
January 12, 2026

It might be worth checking Samsung Knox Configure and Knox Guard. Both are Samsung only but offer most of what you are looking for. And saved you development time (unless you are hired to do the development ofcourse)

Level: 4.1: Jelly bean
January 13, 2026

^ HMD, Motorola (Lenovo) and other OEMs have their own solutions to solve for Google's unnecessary limitation here also indeed. Definitely worth a look :) 

Level 4.0: Ice cream sandwich
January 13, 2026

Wasn't aware of others that provide such solutions, thanks for the additional information!

Emilie_B
Community Manager
January 19, 2026

Just wanted to thank @Michel, @jasonbayton and @Moombas for their contributions here - you guys are super helpful, as always 😉