Intune Shared Android Devices for QA: The Real Trade-off

Intune shared Android devices sound like a simple requirement: let different QA engineers sign in and out of company-owned phones, install whatever applications a client project requires and hand the device to the next tester without exposing the previous session. In practice, those requirements cross the boundary between two different Android Enterprise enrollment models.

Short answer: Android Enterprise Dedicated with Microsoft Entra Shared Device Mode provides a true userless shared device and coordinated sign-in/sign-out for compatible apps. Android Enterprise Fully Managed provides a user-centric device and can expose the full Google Play Store. One profile does not cleanly provide both behaviors.

Table of contents

• The QA requirement
• What the first enrollment revealed
• What Dedicated + Shared Device Mode actually provides
• The full Play Store conflict
• Enrollment model comparison
• A practical two-pool design
• Pilot and validation checklist
• Lessons learned
• Frequently asked questions

The real QA device requirement

The project did not need a kiosk. QA engineers test internal applications, external client applications and occasionally pre-release APKs. A useful device therefore needed to support:

• company ownership and Intune inventory;
• multiple testers over the device lifetime;
• Microsoft Entra sign-in and sign-out;
• camera, Bluetooth, USB and screenshots for realistic testing;
• installation of a changing set of Play Store applications;
• occasional testing of builds that are not publicly listed;
• reasonable cleanup before the next person uses the device.

The critical tension is between shared identity and unrestricted application discovery. Dedicated devices optimize for the first. Fully Managed devices optimize for a single associated user and provide the second.

What the first Intune enrollment revealed

The first tablet was enrolled as a standard Android Enterprise Dedicated device. The result was technically correct but operationally surprising:

• Intune displayed Primary user: None.
• The enrollment flow did not ask a QA engineer to become the permanent device owner.
• The device did not show a normal public Play Store catalog.
• Only Intune components and administratively assigned applications were available.

None of those observations indicated a broken enrollment. They described the Dedicated model: the organization owns the device, no single person owns its Intune relationship, and applications are controlled by the administrator.

The initial design discussion assumed that a Device Restrictions setting could open the full Play Store while retaining Dedicated + Entra Shared Device Mode. Current Microsoft documentation draws a stricter line: the “Allow access to all apps in Google Play store” behavior is documented for Fully Managed devices, while the Dedicated enrollment guide says applications must be assigned as Required.

That documentation check changed the architecture before the pilot expanded to the rest of the fleet.

What Dedicated + Microsoft Entra Shared Device Mode provides

For a shared corporate Android device, create an enrollment profile with this token type:

Corporate-owned dedicated device
with Microsoft Entra ID shared mode

During enrollment, Intune configures the device as Dedicated and deploys Microsoft Authenticator for Shared Device Mode. The device remains enrolled without a user account and is not permanently associated with one employee.

The expected identity flow is:

QA device
  → Tester A signs in
  → SSO across Shared Device Mode-compatible apps
  → Tester A signs out
  → Participating apps sign out
  → Tester B signs in

This is valuable, but the phrase participating apps matters. Microsoft applications and third-party applications that integrate the Microsoft Authentication Library shared-device calls can respond to global sign-in and sign-out. A random client application from the Play Store is not automatically Shared Device Mode-aware.

What Shared Device Mode does not guarantee

• It does not turn Android into Windows-style multi-user profiles.
• It does not make every third-party app participate in global sign-out.
• It does not guarantee that every app removes files, cached tokens or exported content.
• It does not change the fact that Dedicated app deployment is administrator-controlled.

For QA, every non-SDM application must be tested as a data-handling case, not merely as an installability case.

Why the full Play Store requirement changes the answer

Microsoft documents full Google Play access under Android Enterprise Fully Managed devices. A Fully Managed device is corporate-owned but associated with a single user. That user can receive the company app catalog and, when policy allows it, browse the complete Play Store with the corporate account.

This creates the opposite trade-off:

• Application flexibility is better.
• The device has a primary user and a user-centric lifecycle.
• Frequent handoff between unrelated testers is no longer the natural model.

If “install any Play Store app without waiting for an administrator” is a hard requirement, Fully Managed is the documented fit. If “hand this userless device from one employee to another with coordinated sign-out” is the hard requirement, Dedicated + Shared Device Mode is the fit.

Trying to present one mode as both creates a policy that looks correct in the portal but disappoints the tester on the device.

Intune shared Android device comparison

Requirement	Dedicated + Entra Shared Device Mode	Fully Managed
Permanent primary user	None	One associated user
Shared handoff	Designed for it	Not the primary design
Cross-app sign-in/sign-out	Supported for SDM-aware apps	Normal user session, not shared-device global sign-out
Application deployment	Admin assigns Required apps	Admin-assigned apps plus full Play Store when allowed
Arbitrary client apps	Admin preparation is normally required	User can discover/install when full store access is allowed
Data cleanup between testers	Must be validated per app	Device is expected to stay with its user
Best QA use	Repeatable shared test set	Exploratory testing with changing apps

A practical two-pool design for QA

The cleanest result is to stop forcing one enrollment model to satisfy two contradictory jobs. Split the fleet by testing behavior.

Pool A: shared and controlled

Enrollment:
Android Enterprise Dedicated
+ Microsoft Entra Shared Device Mode

Ownership:
Primary user = None

Applications:
Required assignments from Managed Google Play
Private apps and approved test tracks where appropriate

Use this pool for internal applications, repeatable client test sets, shared frontline-style workflows and cases where predictable cleanup matters more than spontaneous app discovery.

Pool B: flexible and user-assigned

Enrollment:
Android Enterprise Fully Managed

Ownership:
One assigned QA engineer

Applications:
Managed Google Play
Full Play Store access when policy permits

Use this pool for exploratory work, external-client projects and scenarios where the tester must install an application immediately without requesting an Intune assignment. Reassign or wipe the device when ownership changes rather than treating it as a rapid shared handoff device.

Why this is better than a permissive universal profile

The split keeps the security boundary understandable. The shared pool has predictable applications and identity behavior. The flexible pool accepts a stronger relationship between device and user in exchange for broader app access. Support can tell what to expect from a device merely by its enrollment profile and group.

Keep the QA restriction policy intentionally small

For devices intended for realistic application testing, avoid applying kiosk-style restrictions by default. A minimal baseline can leave the following settings not configured unless a documented risk requires otherwise:

• camera;
• Bluetooth;
• USB file transfer;
• screenshots;
• external media;
• location;
• Managed Home Screen or kiosk mode.

Not configured means Intune is not enforcing that specific restriction. It does not promise identical manufacturer defaults on every Android build, so validate the baseline on each device family.

Sideloading deserves a separate risk decision. A QA team may need it, but enabling unknown sources globally expands the attack surface. Prefer Managed Google Play private applications, pre-production tracks or a narrowly scoped test group before making sideloading the fleet default.

Pilot checklist before enrolling the fleet

Test one device in each proposed pool before purchasing or enrolling the remaining devices.

1. Factory-reset and enroll the device with the intended profile.
2. Confirm the Intune ownership model and expected primary-user field.
3. Verify compliance, Wi-Fi and certificate profiles.
4. Install the required QA toolset.
5. For Dedicated + SDM, sign in as Tester A to every supported application.
6. Create local test data, sign out globally and sign in as Tester B.
7. Verify that Tester B cannot see Tester A’s tokens, files, recent items or cached account details.
8. Repeat the cleanup test for every important non-SDM client application.
9. For Fully Managed, verify whether full Play Store access and app installation match policy.
10. Record wipe, reassignment and lost-device procedures before scaling the fleet.

Acceptance criteria for the shared pool

PASS:
- Device remains Primary user: None
- Supported apps follow global sign-out
- Required QA apps reinstall reliably
- Previous tester data is inaccessible
- Compliance and certificate-based Wi-Fi recover after restart

FAIL:
- A non-SDM app exposes previous tester data
- App assignment requires repeated manual repair
- The device is expected to provide an unrestricted public app catalog
- Handoff depends on administrators remembering an undocumented cleanup step

Lessons learned from the Intune QA pilot

1. Enrollment model is an architecture decision. It is not merely a different setup wizard.
2. Primary user: None is expected on Dedicated. It confirms the userless ownership model.
3. Shared Device Mode is app-aware. Its strongest guarantees apply only to applications that implement the shared-device behavior.
4. Full Play Store and rapid shared handoff pull in opposite directions. Define which requirement is non-negotiable.
5. Start with one device. Discovering the mismatch before enrolling another 10 or 20 devices avoided a costly rework.
6. Document corrections. When the portal, device behavior and current product documentation disagree with an assumption, update the design rather than defending the assumption.

Frequently asked questions

Why does an Intune Dedicated Android device show Primary user: None?

Dedicated devices are enrolled without a user account and are not associated with a permanent end user. That is expected behavior.

Does Entra Shared Device Mode create separate Android user profiles?

No. It coordinates sign-in and sign-out across applications that support Shared Device Mode. It is not equivalent to separate Windows user profiles.

Can users install any Play Store app on a Dedicated device?

The current Dedicated enrollment documentation describes applications as administratively assigned Required apps. Microsoft documents the setting that opens the full Play Store for Fully Managed devices.

Will global sign-out clean every third-party application?

No. Applications that do not implement Shared Device Mode must be validated individually. Local files, exported content or app-specific tokens can require additional cleanup or a wipe.

What is the best model for a QA team that needs both behaviors?

Use separate pools: Dedicated + Shared Device Mode for controlled shared workflows, and Fully Managed assigned devices for exploratory testing that requires broad Play Store access.

Official references

• Set up Intune enrollment for Android Enterprise dedicated devices
• Set up an Android device in Shared Device Mode
• Shared device mode for Android devices
• Add and assign Managed Google Play apps
• Set up Android Enterprise Fully Managed enrollment

Conclusion

The best Intune shared Android design begins by accepting that “shared” and “open-ended” describe different management models. Dedicated + Entra Shared Device Mode is strong when the app set is controlled and handoff matters. Fully Managed is stronger when one tester needs broad application freedom. A small two-profile pilot makes that trade-off explicit and gives QA useful devices without pretending that one enrollment mode can remove every compromise.