MDM Setup for Enterprise Mobile Apps

Imagine: a fleet of 500 iOS devices, each needing a corporate app with unique backend settings forced onto it. Without MDM, it's a nightmare—manually distributing profiles, asking employees not to delete the app, and supporting each update. MDM solves this: centralized configuration management, security policies, and app deployment. Configuring MDM for enterprise mobile apps is our specialization. We set up MDM for your fleet—from 100 to 10,000 devices—accounting for platforms and your corporate app. Proper MDM integration cuts IT support costs by up to 50% through automation and incident prevention. Average ROI is 6–12 months. Contact us for a project assessment—we’ll prepare an optimal solution.

How Apple MDM Manages Devices

Apple MDM is built on a push-pull protocol: the MDM server sends a push notification via APNs (MDM topic), the device "pulls" the command from the server, executes it, and sends the result. All commands and responses are XML plist over HTTPS (details in Apple MDM Protocol).

To make a device manageable, two modes are used:

• Supervised mode via Apple Configurator 2 or ABM (Apple Business Manager)—maximum control. Only supervised devices support blocking app removal, silent install without user consent, and Single App Mode.
• User Enrollment (iOS 13+)—the device belongs to the employee (BYOD), MDM manages only the Managed Apple ID zone. Apps can be forced installed into the managed space; personal data is inaccessible.

For a corporate app on a managed device, key MDM commands are:

Managed App Configuration—a mechanism to pass configuration to the app via MDM without hardcoding. The app reads the dictionary from UserDefaults with the .managed suffix:

let managedConfig = UserDefaults.standard.dictionary(forKey: "com.apple.configuration.managed")
let backendURL = managedConfig?["BackendURL"] as? String
let tenantID = managedConfig?["TenantID"] as? String

The MDM server sends the AppConfiguration plist during install or via a separate InstallApplication command with ManifestURL. The employee cannot see or change these parameters.

How Android Enterprise Manages Devices

Android Enterprise is the counterpart to Apple MDM, with a more flexible deployment model.

• Fully Managed Device (COBO—Corporate Owned Business Only). The device is set up through a DPC (Device Policy Controller) during initial boot: QR scan or NFC bump. DevicePolicyManager gives full control: app installs, network policies, forced VPN, hardware button blocking.
• Work Profile (COPE/BYOD). A managed profile is created alongside the personal space. Corporate apps live in the Work Profile with a separate launcher and a briefcase icon. IT manages only the Work Profile; personal data is inaccessible.

Key class for Fully Managed is DevicePolicyManager:

val dpm = getSystemService(DEVICE_POLICY_SERVICE) as DevicePolicyManager
val adminComponent = ComponentName(this, DeviceAdminReceiver::class.java)

// Force install packages
dpm.setAlwaysOnVpnPackage(adminComponent, VPN_PACKAGE, true, null)

// Block uninstall
dpm.setUninstallBlocked(adminComponent, TARGET_PACKAGE, true)

// Managed Config for the app
val bundle = Bundle().apply {
    putString("backend_url", "https://corp.example.com")
    putString("tenant_id", "CORP-001")
}
dpm.setApplicationRestrictions(adminComponent, TARGET_PACKAGE, bundle)

How to Choose an MDM Server

For a homogenous Apple fleet—Jamf. For a Microsoft-oriented infrastructure—Intune. For mixed fleets with on-premise requirements—MobileIron/Ivanti or Workspace ONE. According to our data, Jamf Pro reduces policy deployment time by 60% compared to Intune for iOS, while Intune offers stronger Azure AD integration.

Integrating the App with MDM: What Developers Need to Do

MDM manages the device, but the app must "know" its managed status:

• Check Managed App Configuration on every launch and on UIApplicationWillEnterForeground.
• React to MDM Remote Wipe: clear Keychain, database, cache.
• Support openURL scheme for enrollment deeplink.
• If using an MAM SDK (Intune App SDK, Workspace ONE SDK)—integrate the SDK for policy enforcement at the app level, not just the device level.

What's Included in MDM Setup

• Audit of current device infrastructure and app requirements.
• Selection of MDM platform based on fleet composition and integrations.
• Enrollment setup (ABM, QR, Google Zero Touch).
• Creation of profiles and security policies (Passcode, VPN, Restrictions).
• Integration of Managed App Configuration with the corporate app.
• Testing on a pilot group (5–10 devices).
• Full rollout to all devices.
• Documentation and IT department training.
• Guarantee support for 30 days after implementation.

Setup Steps

1. Device inventory and enrollment strategy.
2. MDM platform selection.
3. Create profiles: Wi-Fi, VPN, Passcode, Restrictions.
4. Configure VPP (Volume Purchase Program) for iOS or Managed Google Play for Android.
5. Develop and test Managed App Configuration in the app.
6. Pilot deployment on a control group.
7. Fix errors and refine policies.
8. Roll out to the full fleet (phased or all at once).
9. Monitor compliance and update policies.

Timelines and Cost

Basic MDM setup for an existing device fleet—2–4 weeks. Full rollout with app integration, enrollment workflow, and IT staff training—6–10 weeks. The cost is determined individually after analysis. Request a consultation to get the optimal solution for your fleet. We guarantee quality MDM integration within the agreed timeframe.

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. Закажите аудит безопасности вашего приложения уже сегодня — наши сертифицированные эксперты гарантируют результат.