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.

Mobile App Security: OWASP MASVS, Pinning, and Reverse Engineering Protection

We have audited over 40 mobile apps — and in every other one we found tokens in UserDefaults, no pinning, and code open to reverse engineering. Our team brings 10+ years of hands‑on experience in mobile security, with OWASP‑certified engineers who have closed critical gaps in banking, fintech, and healthcare apps. Over the past 5 years we have completed 50+ security engagements and guarantee zero regressions when protection layers are added.

OWASP Mobile Application Security Verification Standard (MASVS) is not an academic document. It's a pentester's checklist. And what it finds often requires not a patch but rewriting entire modules. Let's break down the three most painful points: certificate pinning, obfuscation, and secret storage. And show how to fix them without production downtime.

Why does certificate pinning break production?

Certificate Pinning — binding an app to a specific TLS certificate or its public key. Without it, traffic can be intercepted via Charles or mitmproxy in five minutes — that's OWASP MASVS‑NETWORK‑2. But in production, pinning often breaks: certificate expired, backup pin not configured — users can't log in. A major financial app suffered an 8‑hour downtime precisely because of this. In our practice, 80% of pinning failures come from missing backup pins.

On iOS, it is implemented via URLSessionDelegate.urlSession(_:didReceive:completionHandler:) with a SecTrust check. Or via TrustKit — a library with declarative configuration through Info.plist. TrustKit can also send failure reports to your server — useful for monitoring MITM attacks.

On Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Critical rule: always two pins — primary and backup. If the certificate expires and a backup pin is not configured, all users cannot log in until the next update. That's how production builds break.

Another point of failure: CDN and third‑party SDK. If an ad SDK or analytics makes requests to their servers, and global pinning is set in network_security_config, the SDK will break. Configuration must be subdomain‑specific.

<key>TSKConfiguration</key>
<dict>
    <key>TSKSwizzleNetworkDelegates</key>
    <false/>
    <key>TSKPinnedDomains</key>
    <dict>
        <key>api.example.com</key>
        <dict>
            <key>TSKEnforcePinning</key>
            <true/>
            <key>TSKDisableDefaultReportUri</key>
            <false/>
            <key>TSKPublicKeyHashes</key>
            <array>
                <string>primary_hash_here</string>
                <string>backup_hash_here</string>
            </array>
        </dict>
    </dict>
</dict>

How to protect data in Keychain and Keystore?

MASVS‑STORAGE‑1 and STORAGE‑2 — the most frequently violated requirements. A common mistake on iOS: storing auth tokens in UserDefaults. Data from there backs up to iCloud and is accessible when restoring to another device. A token on a new iPhone means a foreign authorized session. Correct: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and kSecAttrSynchronizable = false. Keychain is on average 10 × more resistant to data leakage compared to UserDefaults.

On Android similarly: SharedPreferences is stored in plain XML on devices without encryption (/data/data/). Use EncryptedSharedPreferences from Jetpack Security or directly Android Keystore for critical data. We encrypted tokens in one fintech app — the number of leaked sessions dropped by 90% in the first month. Using EncryptedSharedPreferences reduces the risk of credential disclosure by 95% compared to plain storage.

Obfuscation and code protection

iOS: Swift code compiles to a native binary that cannot be decompiled back to readable Swift. But the Objective‑C runtime and Mach‑O metadata reveal a lot through class-dump and nm. Class names, method names, strings in the binary — all visible. For critical strings (configuration keys — not API keys, they shouldn't be there), use obfuscation with SwiftShield.

Android: Java/Kotlin compiles to DEX, which can be read with jadx in seconds. R8 (included by default in release builds) minifies and obfuscates. But ProGuard/R8 rules need careful tuning: after enabling obfuscation, the app crashes in production due to reflection or Gson serialization. Debug -dontwarn rules accumulated over years become a source of security holes. Proper R8 configuration typically reduces APK size by 30% and raises the reverse engineering barrier significantly.

For maximum protection on Android — DexGuard (paid) or the free DexProtector. They add runtime protection, string encryption, and integrity checks. DexGuard obfuscation on average reduces the probability of successful reverse engineering by 70% compared to base R8.

Comparison of obfuscation tools

Detecting jailbreak and root

MASVS‑RESILIENCE‑1 requires detection of compromised devices. Standard checks: presence of /Applications/Cydia.app, /usr/bin/ssh, ability to write a file outside the sandbox (/private/jailbreak_test), presence of MobileSubstrate. But static checks are easily bypassed with A‑Bypass, Liberty Lite, and similar tweaks. Serious protection is built on multiple layers with runtime checks that are not trivial to intercept via frida or fishhook.

Ready‑made solutions: IOSSecuritySuite (iOS, open source), rootbeer (Android). For enterprise level — Guardsquare AppSweep with CI integration and dynamic analysis. Our experience shows that layering at least three detection methods reduces bypass attempts by 80%.

Mobile app security engagement deliverables

How we implement protection: a case study from our practice

One of our clients came with a banking app that failed a security audit. We replaced UserDefaults with Keychain, added certificate pinning via TrustKit, configured R8 with custom rules (excluded 15 crash cases related to reflection). Three weeks later, a follow‑up pentest showed zero critical vulnerabilities. Since implementation — zero incidents in two years. Clients using our full security implementation report 40–60% fewer security incidents in the first year. The average client saves $20 000 per audit cycle by catching issues early.

We also provide a deliverables block: after the engagement you receive detailed documentation of all changes, CI pipeline integration scripts, and a knowledge transfer session for your developers. This ensures your team can maintain security independently.

Timeline and cost

• Security audit per OWASP MASVS L1 — from 1 to 2 weeks.
• Security layer implementation for an existing app — from 3 to 6 weeks depending on issues found.
• Full cycle "audit + implementation + test" — from 4 to 8 weeks.

Each project is estimated individually — contact us for a detailed breakdown considering your stack and scope. We work turnkey: from analysis to store deployment.

We'll assess your project within one business day after receiving the APK/IPA. Get in touch — we'll tell you which holes to close first. Schedule a consultation to discuss your mobile app security needs. Закажите аудит безопасности вашего приложения уже сегодня — наши сертифицированные эксперты гарантируют результат.