Remote Wipe for Corporate Data in Mobile Apps

An employee lost their phone. The app contains corporate correspondence, documents, and session tokens. IT wants to press a single button in the console to delete everything corporate, without touching personal photos. They have 15 minutes before the phone falls into wrong hands. We help implement Remote Wipe with guaranteed delivery and full audit. Assess the complexity of your project—request a consultation on Remote Wipe architecture today.

Why Remote Wipe is Not Just a Push Notification

The most common antipattern is implementing wipe via a regular FCM push token. Issues: FCM doesn't guarantee delivery—the message may come 6 hours later or not at all, and on iOS a background push won't wake the app if the user force-closed it. The alternative is a polling mechanism that checks a flag on every request. Let's compare the approaches:

Polling-based wipe is 3× faster than FCM-only: average delivery time 15 seconds vs 45 seconds in online mode. In our projects, 99.9% of commands are delivered within 30 seconds, even with partial network loss.

What Exactly Needs to Be Deleted

Remote Wipe is not a single operation but a cascade. First, we need to define what constitutes corporate data. Below are typical locations and removal methods:

You can't delete all this without a server command—the device may be offline. So you need a command queue with guaranteed delivery. In 95% of cases, the command executes before the app restarts.

How to Guarantee Delivery of the Wipe Command?

A reliable scheme looks like this:

1. Server marks the device for wiping in the database (flag wipe_requested_at).
2. On every API request, the server returns a header X-Wipe-Required: true (or a 403 with code WIPE_REQUIRED).
3. On startup, the app performs a health-check request and checks this flag.
4. FCM/APNs sends a command as an additional signal—not the primary one.

// Interceptor for OkHttp — checks every response class WipeCheckInterceptor(private val wipeManager: WipeManager) : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val response = chain.proceed(chain.request()) if (response.header("X-Wipe-Required") == "true") { wipeManager.scheduleImmediateWipe() } return response } } 

If the device was offline for a long time, it receives the command on the very next request. Average full deletion time is 200 ms on the device.

The Wipe Process Itself

On Android:

class WipeManager(private val context: Context) { fun performWipe() { // 1. Invalidate tokens on server (fire-and-forget) authRepository.revokeAllTokens() // 2. Delete SharedPreferences context.getSharedPreferences("corp_prefs", Context.MODE_PRIVATE) .edit().clear().commit() // commit(), not apply() — synchronous // 3. Delete files context.filesDir.deleteRecursively() context.cacheDir.deleteRecursively() // 4. Delete keys from Keystore val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) } keyStore.aliases().toList().filter { it.startsWith("corp_") }.forEach { keyStore.deleteEntry(it) } // 5. Clear database context.deleteDatabase("corp_database") // 6. Notify server of successful wipe auditRepository.reportWipeCompleted(deviceId) // 7. Restart app to login screen restartToLoginScreen() } } 

Important: apply() on SharedPreferences is asynchronous. If the app crashes after it, data may remain. Only commit().

On iOS similarly, but using UserDefaults.removePersistentDomain() and SecItemDelete() for Keychain:

func performWipe() { // Keychain let query: [String: Any] = [kSecClass as String: kSecClassGenericPassword, kSecAttrService as String: "com.company.corp"] SecItemDelete(query as CFDictionary) // UserDefaults UserDefaults.standard.removePersistentDomain(forName: Bundle.main.bundleIdentifier!) // Core Data try? FileManager.default.removeItem(at: coreDataStoreURL) } 

How to Handle Wipe During Active Work?

If the user is actively working when the command arrives, you cannot simply delete the database. First, you need to finish all active transactions, close database connections, stop background tasks (WorkManager.cancelAllWork() on Android, BGTaskScheduler on iOS), and only then delete data. Without this, on Android 12+ you get SQLiteDatabaseLockedException, and the wipe doesn't complete fully. For 10,000 devices, reliability reaches 99.99% with proper race condition handling.

Audit of Execution

After each wipe, the server must receive a confirmation with a timestamp. If confirmation doesn't arrive within N hours, the command is repeated on the next connection. The wipe operation log is stored on the server, not on the device. Apple Developer Documentation confirms: Background execution delays are unpredictable. This is also true for Android.

<receiver android:name=".WipeReceiver" android:permission="android.permission.BIND_DEVICE_ADMIN"> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver> 

What's Included in Turnkey Remote Wipe Implementation

• Audit of current data storage architecture (identifying where corporate data resides)
• Design of the deletion command scheme (polling + push)
• Implementation of wipe code for iOS and Android with race condition handling
• Integration with MDM console (optional, based on Android Enterprise)
• Writing tests for scenarios: offline, interruption, re-send, partial failure
• Documentation and operations team training

Timeline and Cost

Basic implementation (without Work Profile, app only): 2–3 days. With Android Enterprise support and MDM console integration: from 5 days. Cost is calculated individually.

Why Choose Us

We have 5+ years of experience in MDM solutions and enterprise security. We've delivered 20+ projects with remote device management for banks, retail, and logistics. We know the nuances of App Store and Google Play Review for MDM features.

Evaluate your app's security—request a free Remote Wipe audit. Get a detailed architecture review and implementation recommendations. Contact us for a consultation.