Skip to main content

Reset and wipe

One code path, several callers: logout, a tenant change, Intune being switched off, an administrator-issued wipe, and a support reset. The process is expected to terminate part-way through, so the sequence survives that by design.

Administrator issues a selective wipe
next launch, the SDK removes company data from the managed app
Before
Your app
Work account signed in · 42 documents cached · policy in force
photos · messages · personal apps
selective wipe
After
Your app — company data removed
Signed out · cache cleared · app still installed, runs unmanaged
photos · messages · personal apps — untouched
The wipe is scoped to the managed app’s company data. Nothing outside the dashed boundary is reachable by the administrator — no photos, no personal accounts, no factory reset.
The wipe is scoped to the managed app’s company data. Nothing outside the boundary is reachable by the administrator.

reset() unregisters the account, optionally wipes corporate data, and clears the runtime configuration. It is used for logout, tenant changes, Intune being switched off, remote wipes, and support resets.

On Android the app process is expected to terminate during this call. Any code written after await Intune.reset(...) may never run. The module writes a journal before unregistering and finishes the sequence on the next launch — which is why the reconcile-at-launch pattern above is not optional.

Two things the module cannot do for you:

  1. Remove the account from the MSAL cache. The module doesn't own MSAL. Skipping this causes the sign-in webview to autofill the previous user and the next enrollment to fail on account mismatch.
  2. Delete your own local data. Register setResetHandler.

A wipe can also be initiated by the customer's IT with no prior call from your app:

Intune.onWipeRequested(({ accountId }) => { /* … */ });