Issue 001 | Week of April 24, 2026

Most enterprise mobile programs are answering the wrong question. The board asks:

“Are our devices secure?”

The dashboard answers:

“94% compliant. No threats detected.”

Both statements can be accurate, but neither is enough.

The better question is:

What can we actually prove about our mobile posture?

That distinction is important for governance in 2026 because enterprise mobile security fails not only at the device layer but across all layers the device depends on: management platforms, identity systems, carrier provisioning workflows, session tokens, cellular signaling, and executive authentication paths.

Your mobile stack operates across three control layers.

The Framework

Signal

Signal is what your stack detects.

Device compliance state. Threat intelligence matches. Risk scores. Behavioral anomalies. MDM, MTD, and mobile EDR all operate here.

The industry invests heavily in Signal.

Enforcement

Enforcement is what your stack does with the signal.

Conditional Access policies. Quarantine. Access revocation. MFA challenges. Identity-provider controls.

The industry builds this layer reasonably well.

Verification

Verification is what your stack can prove.

Continuous, cross-layer confirmation of device, identity, session, and access state with evidence strong enough to defend the posture to a board, insurer, regulator, or breach counsel.

This is the layer the industry has not built.

That is the gap.

A CISO who reports a clean MDM dashboard is reporting Signal.

A CISO who reports blocked Conditional Access attempts is reporting Enforcement.

A defensible mobile posture statement sounds different:

Our mobile-accessible identity surface is X. Our stack produces deterministic signal on Y percent of it, reactive enforcement on Z percent of it, and has documented blind spots in the following areas, which we compensate for through the following controls, with the following residual risk.

That is a Verification statement.

Every item in this issue maps back to this framework.

This Week’s Five Items

1. CISA confirmed what the MDM vendor will not say out loud.

Two actively exploited vulnerabilities hit the CISA Known Exploited Vulnerabilities catalog this week.

Both are critical.

Both target enterprise management infrastructure.

Neither is a device exploit.

CVE-2026-1340: Ivanti EPMM

CVE-2026-1340 targets Ivanti Endpoint Manager Mobile.

This is code injection into enterprise MDM infrastructure of which the attack vector is the platform that manages the phones-not a single device. 

An attacker who compromises the EPMM instance can potentially push malicious configurations across the entirety of the enrolled fleet, access enterprise data synced to managed endpoints, and pivot toward identity and cloud systems those devices authenticate against.

This is not a single device compromise. Modern security demands understanding this as a fleet compromise executed through the control plane.

CVE-2026-35616: Fortinet FortiClient EMS

CVE-2026-35616 targets Fortinet FortiClient EMS through improper access control enabling unauthenticated remote access.

FortiClient EMS sits in the policy, VPN, BYOD, and endpoint configuration layer for many environments. Once that control plane is compromised, the attacker is working at the control plane. 

Attackers are not only targeting phones anymore -they are 'fishing with a net'. They are targeting the systems that manage phones to extract the most perceived value.

Compromise the MDM, EMS, or endpoint management platform, and the attacker inherits scale that your posture must adapt to. 

The control-plane trust problem presents here, as mobile security stack signals on managed devices. Most setups enforce policy on managed devices, but in most environments do not verify the integrity of the system managing those devices.

The management layer is trusted implicitly. This week’s alerts show why that trust is no longer defensible without evidence.

The board-level question is simple:

Who has administrative access to our MDM or EMS platform, and from where can they reach it?

If that answer is not documented, reviewed, and tested, the issue is not only technical-it eptiomizes a governance failure.

2. eSIM provisioning attacks are now documented at enterprise scale.

The mobile number has become an authentication asset, which means it has also become an attack surface.

Two recent cases define the current eSIM threat landscape:

Self-service eSIM abuse at scale

F.A.C.C.T., formerly Group-IB Russia, documented more than 100 attempted account takeovers at a single financial institution during 2023 and 2024. The method was not a legacy SIM swap through a carrier call center. Attackers abused self-service eSIM provisioning workflows. After compromising the victim’s carrier account, they generated their own activation code, moved the number to an attacker-controlled device, and intercepted SMS one-time passwords.

-No physical device access.

-No carrier-store visit.

-No obvious user-facing compromise.

The provisioning workflow became the attack surface.

Remote eSIM issuance and liability

In March 2025, a California arbitrator ordered a major U.S. carrier to pay $33 million after a customer’s assets were drained following remote eSIM issuance.

The attacker social-engineered a call-center representative into issuing an eSIM QR code despite the customer having requested a no-port flag.

Different path. Same result.

-The phone number moved.

-The downstream systems trusted it.

-The money disappeared.

Why eSIM is worse than the old SIM-swap model

Legacy SIM swaps often created friction leaving the victim to likely lose service. SMS might fail, the telecom carrier might trigger alerts or a human representative might ask questions. eSIM removes much of that friction.

In the worst case:

• No service outage
• No failed SMS delivery
• No visible warning on the original device
• No MDM alert
• No device compliance change

The device remains trusted, while the number is compromised somewhere else.

Security Explorations demonstrated the deeper technical risk in July 2025 with a working eUICC compromise that cloned an active eSIM to a second device. Calls arrived. SMS arrived. Gmail two-factor codes arrived. The original device showed nothing.

This is exactly why NIST classified SMS OTP as a restricted authenticator in SP 800-63B-4. It is also why CISA guidance after the Salt Typhoon intrusions warned against SMS as a second factor.

The framework reading is direct:

eSIM provisioning attacks happen outside the device layer.

MDM, MTD, and mobile EDR operate on the device. eSIM provisioning operates through the carrier and identity workflow. Your device stack has no signal to produce because the attack never crosses the layer it monitors.

The enterprise implication is uncomfortable; If executive phone numbers are used for email, cloud administration, financial platforms, board portals, or encrypted communication recovery, then the phone number is part of the identity perimeter. And it is probably less controlled than the systems it unlocks. The board-level question:

Which privileged accounts still depend on a phone number for authentication, recovery, or approval?

If the answer is unknown, the exposure is already present.

3. The control-plane hardening question your board has not asked yet.

The vulnerabilities in Item 1 are not isolated-They are part of a pattern. Ivanti EPMM has seen multiple public exploitation waves across several years:

• 2023: CVE-2023-35078, exploited in the wild
• 2025: CVE-2025-4427 and CVE-2025-4428, chained and exploited in the wild
• 2026: CVE-2026-1281 in January
• 2026: CVE-2026-1340 in April

The product family matters, but the larger point is not vendor-specific. Every enterprise mobile management platform has the same architectural problem:

It sits at the center of a privileged blast radius.

The MDM or EMS control plane can push configurations, enforce policy, deploy profiles, govern VPN behavior, influence access, and interact with identity-dependent systems. That makes it one of the highest-value systems in the mobile environment and in many organizations, it is not protected that way. The model no longer survives contact with current exploitation patterns, as common deployment reality looks like this:

• The administrative console is reachable over the network
• Admin access may not require phishing-resistant MFA
• Patching is tied to a quarterly rhythm
• The platform was excluded from the last penetration test
• Configuration changes are logged but not actively alerted
• Administrative privileges are shared too broadly
• The management plane is treated as an IT tool, not a Tier 0 security system

The five questions that belong in the next security review:

1. Is the MDM or EMS management interface reachable from the public internet?

If yes, compensating controls should be explicit: IP allowlisting, VPN-only access, certificate-bound admin authentication, and segmentation of the management plane.

2. Is administrative access protected by phishing-resistant MFA?

Hardware keys, device-bound passkeys, or equivalent controls should protect MDM and EMS administrators.

SMS-based MFA is not enough for this layer.

3. Are MDM and EMS admin credentials rotated on a defined schedule?

Rotation alone is not the point. The stronger question is whether every administrative action is attributable, logged, reviewed, and alertable.

4. Was MDM or EMS infrastructure included in the last penetration test?

Many organizations test endpoints, cloud systems, and networks while excluding the mobile management platform-That exclusion is now a governance problem.

5. Do alerts exist for anomalous configuration pushes or bulk policy changes?

If an attacker compromises the management plane, configuration change is often the visible signal. If no one is watching for that signal, detection arrives late.

The board-level version:

Is our mobile management platform hardened to the same standard as the systems it controls?

In most environments, the honest answer is no and that answer belongs in the risk register.

The framework reading:

The management plane is the layer your mobile stack trusts but does not verify.

Until administrative access, configuration drift, policy changes, and platform integrity are continuously evidenced, the control plane remains an unverified trust boundary.

4. Cellular signaling is now an enterprise attack surface.

Baseband security usually sits outside enterprise risk conversations.

That needs to change.

New research scheduled to appear at USENIX Security 2026 reframes the issue.

The paper is:

“Semantics Over Syntax: Uncovering Pre-Authentication 5G Baseband Vulnerabilities”

The framework is called CONSET. The work comes from researchers at Texas A&M University and the University at Buffalo. The important distinction is this:

Previous baseband research often relied on malformed packets, while CONSET uses valid ones.

The researchers used standards-compliant 5G Radio Resource Control messages with semantic inconsistencies. In plain language: messages that look legitimate by format but contain logical contradictions that break the modem’s internal state.

The modem cannot reject them as malformed, so it processes them, then the internal logic fails. The confirmed results include:

• 6 device-level flaws
• 3 high-severity CVEs
• 41 chipset models affected
• More than 466 smartphone models in scope
• Demonstrated over-the-air, pre-authentication impact

The confirmed outcomes include modem crashes, persistent network loss, and inability to reconnect without reboot and there is an important credibility line here:

Confirmed remote code execution on commercial devices has not been demonstrated.

What has been demonstrated is still serious: zero-click, radio-layer disruption against production devices through pre-authentication signaling. For enterprise and critical infrastucture security, the detection implication matters more than the technical novelty. Current enterprise controls lack visibility into modem-layer execution. MDM, MTD, and mobile EDR run on the application processor and the baseband runs separately, on dedicated firmware, below the layer where enterprise tools operate. That means an attack at the baseband layer occurs before OS-level telemetry exists.

The researchers themselves could not directly instrument the baseband during testing. They had to infer compromise through external signals like connectivity failures, logs, and reboot behavior. If the researchers who designed the attack could not directly observe the baseband, your SOC cannot either.

The framework reading:

The baseband is a layer where current enterprise stacks cannot signal, cannot enforce, and cannot verify.

That does not mean every organization should panic, but It does mean the layer has to be named honestly. A mature posture does not pretend every layer is monitored. It documents what is monitored, what is not monitored, what compensating controls exist, and what residual risk remains.

Practical enterprise actions include:

• Document baseband exposure in the mobile threat model
• Track baseband and carrier firmware update cadence
• Review cellular dependency for high-risk users
• Consider carrier segmentation and executive device standards
• State clearly in board reporting that modem-layer execution is not visible to current enterprise controls

The board-level question:

Does our threat model document what we cannot monitor?

If the answer is no, the baseband layer belongs on that list.

5. One thing worth doing this week: calculate your Pocket Attack Surface.

Your Pocket Attack Surface is not your MDM enrollment count.

It is the number of distinct authentication paths between an attacker and your sensitive systems if a mobile device, identity, session, or phone number becomes compromised.

The formula:

PAS = Devices × Identities × Sessions × Accessible Systems

Most organizations measure only the first factor.

That is why their mobile risk number is usually wrong.

Factor 1: Devices

Start with enrolled devices.

Then add unmanaged devices accessing enterprise systems.

Do not pull the unmanaged number from MDM. Pull it from identity-provider sign-in logs.

MDM only shows what it manages. Your identity provider shows what is actually accessing the business.

Factor 2: Identities

Calculate the average number of authenticated identities active per device.

A single executive phone may hold:

• Corporate identity
• Personal identity used for work
• Delegated admin identity
• Board or finance identity
• Privileged SaaS access

One physical phone can carry multiple enterprise-relevant identities.

Factor 3: Sessions

Calculate average active sessions per identity.

Include:

• Active session tokens
• OAuth grants
• Refresh tokens
• Persistent SaaS sessions
• Mobile email sessions
• Cloud storage sessions
• Administrative console sessions

Tokens survive password rotation more often than executives assume.

Factor 4: Accessible Systems

Factor 4: Accessible Systems

Calculate how many corporate systems each session can reach.

Examples:

• Email
• File storage
• CRM
• ERP
• Source control
• Finance platforms
• Customer databases
• Board portals
• Identity admin consoles
• Ticketing and workflow systems

Then multiply.

Example

A 200-person organization might discover:

• 200 enrolled devices
• 50 unmanaged devices accessing enterprise systems
• 1.8 identities per device
• 4 active sessions per identity
• 30 accessible systems per session

That produces:

250 × 1.8 × 4 × 30 = 54,000 authentication paths

The dashboard says 200 devices.

The exposure is 54,000 paths.

That is a 270x difference between what the organization measures and what the attacker can use.

This is the number that belongs in the board briefing.

-Not enrollment rate.

-Not green dashboards.

-Not “no threats detected.”

The board-level question:

How many mobile-accessible authentication paths exist between an attacker and our sensitive systems?

If the answer is not known, the organization is managing device posture, not mobile attack surface.

The Pattern Across Issue 001

The five items point to the same conclusion. Enterprise mobile security is no longer just a device-control problem. The meaningful attack surface now includes:

• Management platforms
• Carrier provisioning workflows
• Phone numbers
• Identity systems
• Session tokens
• Cellular signaling
• Administrative consoles
• Unmanaged access paths
• Control-plane integrity
• Verification evidence

The old question was:

Are our devices secure?

The better question is:

What can we prove about the mobile-accessible attack surface?

That is the gap this weekly brief exists to track.

What To Do This Week

Do not start with another tool evaluation.

Start with evidence.

Action 1: Pull your true device count.

Compare MDM enrollment against identity-provider sign-ins.

The delta is unmanaged mobile access.

Action 2: Identify privileged accounts using phone-number-based authentication.

Include SMS MFA, voice call MFA, recovery numbers, approval flows, and executive personal numbers.

Action 3: Review your MDM and EMS administrative plane.

Answer five questions:

1. Is it internet reachable?
2. Is admin access protected by phishing-resistant MFA?
3. Are admin actions logged and alertable?
4. Was it included in the last penetration test?
5. Are bulk configuration changes monitored?

Action 4: Calculate Pocket Attack Surface.

Use:

Devices × Identities × Sessions × Accessible Systems

Track it quarterly. If the number is uncomfortable, the metric is working.

Why This Digest Exists

Annual assessments are photographs of a moving target. Your mobile threat surface changes weekly. Boards usually see it annually.

That delta is where material risk accumulates.

This digest closes one week of that delta at a time.

Every Friday:

• Five mobile security intelligence items
• One action worth taking
• Clear mapping to Signal, Enforcement, and Verification
• No vendor sponsorships
• No product placements
• No compliance theater

This is not written for the vendor-It is written for the person who has to answer the board when the dashboard was green and the breach still happened.

Source Notes For This Issue

CISA KEV alerts

Primary source: CISA Known Exploited Vulnerabilities catalog.

• CVE-2026-1340: Ivanti EPMM, added April 8, 2026
• CVE-2026-35616: Fortinet FortiClient EMS, added April 6, 2026

eSIM provisioning attacks

Source anchors:

• F.A.C.C.T. reporting on 100+ attempted eSIM-swap account takeovers
• March 2025 California arbitration involving remote eSIM issuance and $33 million damages
• Security Explorations July 2025 eUICC compromise and Kigen eSIM clone demonstration
• NIST SP 800-63B-4 classification of SMS OTP as a restricted authenticator
• CISA December 2024 guidance against SMS as a second factor

Control-plane exploitation pattern

Source anchors:

• CVE-2023-35078
• CVE-2025-4427
• CVE-2025-4428
• CVE-2026-1281
• CVE-2026-1340

Analysis frame: Mobile Security Guru original control-plane governance analysis.

CONSET and 5G baseband research

Primary source anchor:

• Huang et al., “Semantics Over Syntax: Uncovering Pre-Authentication 5G Baseband Vulnerabilities”
• CONSET framework
• Texas A&M University and University at Buffalo
• Scheduled for USENIX Security 2026
• Announced December 20, 2025

Confirmed figures from supplied source material:

• 6 device-level flaws
• 3 high-severity CVEs
• 41 chipset models
• 466+ smartphones

Pocket Attack Surface

Framework source:

• Mobile Security Guru original four-factor PAS model
• Formula: Devices × Identities × Sessions × Accessible Systems

Worked example is illustrative and reproducible.

Get the weekly brief.

Every Friday, Mobile Security Guru publishes what moved, what broke, and what enterprise security leaders need to understand about the mobile security gap.

-No vendor agenda.

-No product placements.

-No compliance theater.

 

Author Bio

William Haynes is the founder of Mobile Security Guru and has spent 17 years in mobile security. He advises CISOs, IT directors, and executives on enterprise mobile risk, BYOD exposure, mobile identity, carrier-layer threats, and the gap between what security dashboards report and what organizations can actually verify.

Mobile Security Guru
mobilesecurityguru.com