Beyond MDM: A CISO's Guide to Mobile Device Security
Move beyond basic MDM policies. Our guide to mobile device security covers the threat landscape, controls, offensive testing, and executive metrics CISOs need.
Beyond MDM: A CISO's Guide to Mobile Device Security
Move beyond basic MDM policies. Our guide to mobile device security covers the threat landscape, controls, offensive testing, and executive metrics CISOs need.
Valiant Team
7/4/202613 min read
Your Biggest Security Blind Spot Is in Your Pocket
MDM is not mobile security. It is device administration with security value.
That distinction matters because many programs still treat Microsoft Intune, VMware Workspace ONE, or another UEM stack as if policy enforcement equals protection. It doesn't. You can require encryption, enforce a passcode, restrict app installs, and still miss live compromise activity on the device.
The core issue is visibility. Mobile security guidance often centers on enrollment, compliance, and whitelisting, yet fails to answer how teams detect behavioral threats that policy controls can't see. One paper puts it plainly: MDM provides “no threat detection or response”, which is why mobile security needs active behavioral analysis rather than policy alone, as noted in this mobile blind spot analysis.
What MDM does well
MDM and UEM platforms still matter. They give you the baseline:
Configuration control for passcodes, encryption, OS version requirements, and app restrictions
Inventory and ownership visibility across corporate and personally enabled devices
Remote actions such as lock, selective wipe, and full wipe for lost assets
That's the foundation. It is not the whole building.
What MDM cannot prove
A determined attacker doesn't care that a phone is “compliant” in the console. The attacker cares whether they can steal a session token from a weak app flow, trick a user into entering credentials on a mobile phishing page, or route traffic through a hostile network long enough to capture sensitive data.
Practical rule: If a control can enforce policy but can't show you malicious behavior, it won't tell you when prevention has already failed.
The business risk is simple. Mobile devices hold access to email, SSO portals, collaboration tools, financial approvals, and customer data. If the phone is in scope for work, it is in scope for attack. Treating mobile as a lesser endpoint creates a blind spot that attackers will test sooner than your auditors do.
The Modern Mobile Threat Landscape
Mobile risk is no longer niche. It is a mainstream attack surface with consumer-scale volume and enterprise impact.
As of December 2023, mobile cyberattacks reached approximately 5.4 million per month globally, which represented a 147% increase from the previous year, according to mobile security trend data. The same source notes that Android hosts approximately 88% of all mobile malware, which tells you where attackers concentrate effort and where defenders need tighter operational discipline.
Why mobile has become a primary attack surface
Phones now carry the same practical value as laptops for many business workflows. They hold authenticators, chat threads, cloud app sessions, executive email, and privileged notifications. In many environments, the mobile device has become the fastest path to an identity compromise because users trust it and security teams monitor it less aggressively.
Attackers also benefit from mobile UX constraints. Small screens hide full URLs. Users move quickly. Browser prompts, consent screens, and permission requests are easy to miss or misread. That makes mobile ideal for credential theft and session abuse.
The attack paths that matter most
The common paths aren't exotic. They're predictable and repeatable.
Malicious applications remain one of the most effective routes because users and businesses both rely heavily on apps. A trojanized utility app, a repackaged business tool, or a third-party app with unsafe data handling can turn one install into persistent exposure.
Mobile phishing works because the interface helps the attacker. A user taps a link in SMS, chat, or email, lands on a login page designed for the phone form factor, and enters credentials before checking context.
Network attacks exploit trust in connectivity. On public Wi-Fi, an attacker may try to manipulate traffic, redirect users, or take advantage of weak certificate handling inside an application.
OS and device exploitation matters most when patching lags or devices drift from a supported baseline. On mobile, the combination of old OS versions, permissive configurations, and unmanaged apps gives attackers options.
Mobile attacks don't need to look sophisticated to cause executive-level damage. A stolen token from a finance workflow can matter more than malware on a lab device.
A practical example makes this clearer. An employee connects a personal phone to hotel Wi-Fi, opens a third-party expense app, and authenticates through a mobile browser flow. If the app handles tokens poorly or the user has already been lured to a fake sign-in page, the attacker can capture enough to impersonate that user in downstream systems. From the SOC's perspective, the traffic may look like normal mobile activity unless you collect and correlate the right telemetry.
The lesson for leadership is straightforward. The modern mobile threat environment isn't defined by one killer exploit. It's defined by overlapping weaknesses in apps, networks, identities, and user behavior. That's why mobile device security has to be designed as a detection and response problem, not just a provisioning exercise.
Building a Defensible Mobile Architecture
A defensible architecture starts with one rule. Assign each control a clear job. Don't buy overlapping tools and hope the stack becomes a strategy.
Most enterprises need four layers working together: UEM or MDM for control, identity for access governance, app security for code and data handling, and mobile-focused detection for live threats. If one layer tries to do all of it, you'll create gaps and false confidence.
What each control layer should do
MDM or UEM should enforce the baseline. Use it for enrollment, compliance, OS requirements, passcode rules, corporate app distribution, jailbreak or root policy checks, and wipe actions. Microsoft Intune, Workspace ONE, and Jamf Pro are examples of tools in this lane.
Identity and access management should govern who gets in and under what conditions. Conditional access, device posture checks, and strong authentication belong here. Such measures reduce the blast radius of a stolen device or hijacked session.
Here's a useful reference point before you go deeper into the stack:
Mobile Threat Defense (MTD) should focus on what MDM cannot see well. That includes malicious apps, risky network conditions, suspicious device behavior, and indicators that suggest compromise rather than mere noncompliance.
SIEM and SOC integration should make mobile events actionable. A mobile alert that never reaches the analysts doesn't change risk. Feed relevant telemetry into your central workflows so your team can correlate mobile signals with identity, email, and cloud activity.
Where teams usually get the design wrong
The first failure mode is overreliance on remote wipe. Wipe is useful after loss or confirmed compromise, but it doesn't help you detect a session hijack that has already moved into SaaS systems.
The second is assuming built-in platform controls protect every app equally. They don't. A mobile app can still expose sensitive data through weak storage practices, poor token handling, or unsafe transport logic even if the underlying OS is hardened.
The third is treating rooted or jailbroken devices as only a policy violation. They represent a serious architectural break. CISA's mobile threats guidance explains that rooting or jailbreaking dismantles OS sandboxing, can allow unrestricted file system access, and can undermine secure boot, remote wipe effectiveness, and protection of stored cryptographic material.
A sound architecture usually follows this order:
Set the baseline with device enrollment, supported OS versions, and restricted administrative drift.
Protect access through conditional access and stronger authentication requirements for sensitive workflows.
Reduce app risk with secure coding standards, app vetting, and least-privilege permissions.
Detect live threats with mobile-focused telemetry and response paths into the SOC.
Validate the stack with offensive testing against real business use cases.
That's what makes the architecture defensible. Each layer has a purpose, and each purpose can be tested.
Securing Your In-House and Third-Party Mobile Applications
A secure device can still run an insecure app. That's why mobile device security fails so often at the application layer.
The recurring issues are not mysterious. They show up in authentication flows, local storage, API trust decisions, and encryption choices. Attackers don't need to break the phone if the app hands them what they want.
The app flaws that create business risk fastest
Broken cryptography remains one of the most dangerous patterns in mobile apps. Developers still ship weak implementations, fail to enforce end-to-end encryption, or mishandle session data in ways that expose tokens. Kaspersky's overview of mobile security threats notes that broken cryptography can allow attackers to steal session tokens and impersonate legitimate users without needing the password.
That failure mode has direct business impact. If an attacker can replay a token from a finance app, field service app, or executive communications tool, your access controls may never see a bad password attempt. The attacker appears to be the user.
What to require from engineering and vendors
If you build mobile apps in-house, insist on controls that can be verified in code review and testing:
Strong encryption choices such as modern approved algorithms for sensitive data at rest and in transit
Certificate validation discipline so the app doesn't trust hostile intermediaries
Secure session handling with careful token storage, rotation, and invalidation
Minimal local data exposure so cached content and logs don't become a breach artifact
For third-party apps, procurement should ask for more than a compliance PDF. Ask how the vendor tests its mobile app, how it handles secrets on-device, how it validates TLS, and how quickly it fixes reported flaws. If the answer is vague, treat that app as a risk decision, not a convenience decision.
Operator's view: The most damaging mobile app flaws rarely announce themselves to users. They look like normal app behavior until someone tests them like an attacker.
A useful review path includes static analysis, dynamic analysis, and hands-on penetration testing. Static analysis can catch unsafe code patterns. Dynamic testing shows how the app behaves at runtime. Penetration testing proves whether a real operator can intercept traffic, tamper with client logic, extract secrets, or abuse a session flow to reach protected data.
For CISOs, the key question is simple: which mobile apps in your environment could expose customer data, privileged workflows, or business-critical transactions if an attacker compromised the app logic rather than the device?
Governing Mobile Use with Smart Policies
Poor policy creates shadow IT. Overly loose policy creates exposure. Good governance finds the operating point between the two.
That matters because mobile risk often starts with ordinary behavior, not elite tradecraft. In Q3 2024, 31% of mobile devices had out-of-date operating systems. The same dataset notes that 83% of phishing sites specifically target mobile devices and 64% of users connect to public Wi-Fi without protection, according to these mobile security statistics. Governance has to account for the fact that people will move fast, click from phones, and work outside trusted networks.
Choosing the right ownership model
Device ownership is a business decision with security consequences.
BYOD can work if you sharply limit what data and workflows are allowed on personal devices. If your executives approve payments or access sensitive customer records on mobile, COPE or COBO usually makes more sense.
Policies that employees will actually follow
The strongest mobile policies are short, enforceable, and tied to real workflows. Focus on a handful of controls that remove common failure paths:
Patch compliance must be mandatory. If a device falls behind the supported OS baseline, restrict access to sensitive apps until it is updated.
Public Wi-Fi rules should be unambiguous. For high-sensitivity activity, require protected connectivity and block risky usage patterns where feasible.
App installation rules should distinguish approved business apps from unsanctioned tools that process corporate data.
Lost device reporting needs a short clock and a simple path. If employees don't know whom to call, your remote actions arrive too late.
A practical policy set also defines what happens after a suspected compromise. Who can isolate the device? Who can revoke sessions? Who owns user communications, legal review, and forensic preservation? Without that governance, even a well-instrumented environment responds slowly.
A mobile policy should read like an operating manual for real employees, not a compliance artifact written for an audit binder.
Shifting from Prevention to Active Detection and Response
Prevention still matters, but mature programs assume it will fail somewhere. The real test is whether your team can recognize malicious mobile activity quickly enough to contain the damage.
That means mobile telemetry has to enter the same operational conversation as endpoint, email, identity, and cloud logs. If your SOC can investigate an impossible-travel alert but can't reason about a compromised phone session, you have an operational blind spot.
What a workable mobile detection workflow looks like
A practical workflow starts when MTD or a mobile-aware control flags behavior worth reviewing. That might be suspicious network behavior, a high-risk app signal, or evidence that a user has interacted with a phishing flow from a managed device.
The event needs context before an analyst can act. Tie the alert to the user, device ownership, recent identity activity, relevant SaaS sessions, and any associated email or messaging indicators. Mobile events become useful when they can be correlated, not when they remain isolated in a separate console.
How analysts should investigate a mobile alert
A good analyst workflow is narrow and disciplined:
Confirm the device and user context. Identify whether the device is managed, what data it can access, and what business role the user has.
Review recent authentication events. Look for unusual sign-ins, token reuse patterns, or suspicious access to high-value systems.
Check app and network signals. Determine whether the device contacted risky infrastructure, installed an unapproved app, or used an unsafe path during a sensitive transaction.
Contain first, explain second. Revoke sessions, restrict app access, or quarantine the device if the risk is material.
Preserve evidence for follow-up. Save telemetry, user reports, and timelines so the incident can be reconstructed cleanly.
Many teams discover a tooling problem rather than an analyst problem. If mobile alerts don't integrate into your SIEM or case management workflow, analysts won't have enough signal to make a confident decision.
The operational goal isn't perfect visibility. It's enough visibility to answer three questions fast: is the user exposed, is the business data exposed, and what access do we need to cut off right now?
Verifying Your Defenses with Offensive Testing
The hardest question in mobile device security is the one most programs avoid. How do you know the controls work against an attacker who adapts?
Policies can look strong on paper. Tool dashboards can show healthy compliance. Neither proves that your controls survive realistic abuse. The only way to find out is to test them offensively.
Why checklist security fails under real attack pressure
Checklists validate presence. Attackers validate effectiveness.
A policy may require a secure mobile build. A penetration test determines whether the app still leaks tokens, trusts an attacker-controlled certificate path, or stores sensitive data where it can be recovered. A UEM profile may show healthy devices. A red team exercise determines whether a user can still be lured through a mobile phishing path that bypasses expected controls.
This is the neglected part of the discipline. Department of Defense mobile guidance asks the right question directly: “How do we validate mobile detection readiness against realistic kill-chain attacks?” It also states that red teaming for mobile is absent from standard best practices, while an attacker-first approach grounded in MITRE ATT&CK is the way to prove real risk reduction.
Security leaders shouldn't ask only, “Do we have the control?” They should ask, “Can a skilled tester bypass it in the workflow that matters most to our business?”
What a serious mobile offensive test should include
A useful mobile assessment does more than run a scanner against an APK or IPA. It should test the way your organization uses mobile.
A mature scope often includes:
Application abuse testing against authentication, session handling, client-side logic, storage, and API trust decisions
Device control validation to see whether rooted, jailbroken, or otherwise drifted devices are blocked the way policy says they are
Phishing and identity scenarios that reflect how users really receive links and prompts on mobile
Detection validation to confirm the SOC receives, triages, and responds to the activity it claims to monitor
The difference between vulnerability scanning and offensive testing is intent. Scanning asks what appears weak. Offensive testing asks what can be exploited to reach a business objective.
A concrete example: a tester targets a custom mobile app used by field staff. The app relies on a browser-based authentication handoff and stores a reusable token poorly. The tester captures the token during a controlled exercise, replays it against the backend, and accesses customer records. The finding is no longer “weak session handling.” It becomes “an attacker can impersonate field staff and pull customer data without the password.” That's the level of evidence executives can act on.
Strong offensive engagements also include retesting. If engineering fixes certificate validation, token storage, or session expiry logic, the tester should validate the fix under the same attack path. Without retesting, you have remediation intent, not remediation proof.
Measuring and Reporting Mobile Security Risk to the Board
Boards don't need a tutorial on mobile malware families. They need a clear statement of exposure, control effectiveness, and decision points.
The most useful reporting avoids vanity metrics like enrolled device counts by themselves. A board report should show whether the organization can protect sensitive mobile workflows, detect meaningful abuse, and recover quickly when a device or app becomes a threat path.
Metrics that show control effectiveness
Start with measures that connect directly to risk reduction:
Coverage of active mobile detection across the mobile fleet that accesses corporate data
Patch discipline for supported mobile OS versions and business-critical mobile apps
High-risk app findings discovered through assessments and how quickly teams remediate them
Response performance for mobile incidents, including containment and access revocation steps
Validation results from penetration tests, red team exercises, and remediation retests
One concrete policy metric belongs in almost every board update. Executives should mandate a 6+ digit PIN or alphanumeric passcode because 6-digit PINs reduce brute-force success rates by 99.8% compared to 4-digit variants, according to this mobile security guide. That metric is easy to report and easy to enforce, and it ties directly to physical device access risk.
A board-level narrative that works
The strongest narrative is concise and operational:
What is at risk. Identify the mobile-enabled business processes that matter most, such as executive email, financial approvals, customer data access, or privileged alerting.
How the organization is controlling that risk. Summarize device baseline enforcement, identity protections, app assurance, and active detection coverage.
What testing proved or disproved. Report whether offensive testing found exploitable paths and whether retesting confirmed the fixes.
What decisions need support. Request funding, policy changes, or ownership model changes where the risk justifies them.
A weak board report says mobile is “covered” because devices are enrolled. A strong board report says the company has enforced passcode policy, restricted unsupported devices, tested key mobile apps for exploitability, integrated mobile alerts into the SOC, and confirmed whether security controls resisted attacker behavior in the workflows that matter.
That last part is what changes board confidence. Not the existence of controls. The proof that they hold up.
