Dark Perimeter: "Leaving AirWatch Behind" — Part 1: The Architecture

Your AirWatch renewal just landed and the number is higher than last year. Before you migrate to Intune, there's a more important question to answer: are you even using the right mobile security model? In this episode, Cole Drayden, Dr. Elliott Vance, and Marcus Hale break down the critical distinction between MDM and MAM — and why Intune's App Protection Policies can eliminate the need for traditional mobile DLP entirely. Dark Perimeter: Security, AI, and the Edge of What's Coming.

Transcript

SPEAKER_00 0:00

There is a conversation happening inside a lot of security teams right now, and it usually starts with a licensing renewal notice. You've been running AirWatch or Workspace One, if you've been keeping up with VMware's rebranding, and the renewal lands on your desk, and the number is higher than it was two years ago, and someone asks a perfectly reasonable question Do we still need this? What exactly are we getting for this? And that question, if you follow it honestly, leads somewhere more interesting than a cost comparison spreadsheet. Tonight we're talking about mobile device management, specifically the migration away from AirWatch toward Microsoft Intune, and more importantly, a way of thinking about mobile security that most organizations never arrive at because they start from the wrong place. With me are Dr. Elliot Vance and Marcus Hale. Welcome back, both of you.

SPEAKER_02 1:01

Good to be here. And I want to start by pushing back slightly on the framing of this as a product migration conversation, because I think that's where organizations go wrong before they've written a single policy. The decision to move from AirWatch to Intune is really a forcing function for a deeper question. What problem are you actually trying to solve on mobile?

SPEAKER_01 1:23

That's the right question, and most people don't ask it. They ask how do we migrate our AirWatch policies into Intune? And they start building a feature comparison matrix, and they never step back and ask whether the model they've been running for the last five years is even the right model.

SPEAKER_00 1:37

So let's anchor on why AirWatch is losing ground before we talk about the architecture. Because for a lot of organizations, this isn't a strategic pivot. It starts with the Broadcom acquisition.

SPEAKER_02 1:52

That's where a lot of the urgency is coming from right now. When Broadcom acquired VMware in late 2023, the licensing model shifted significantly. Organizations that had been paying for bundled Workspace One suites started seeing their renewals restructured. Some customers were pushed toward larger enterprise bundles that included capabilities they didn't need and pricing that didn't match their scale. And the support and roadmap story became less clear. Meanwhile, most of those organizations already have Microsoft 365 licenses. And Microsoft Intune is included in a substantial portion of those license tiers. Business premium E3 with the Enterprise Mobility and Security Add-on E5. It's already in the house. So the calculus shifts. You're paying separately for Workspace One to do something that your existing Microsoft licensing may already cover.

SPEAKER_01 2:44

That's the cost story, but the more important story for practitioners is the integration story. InTune lives inside the Microsoft ecosystem natively. It talks to Intra ID. That's the identity layer, formerly Azure AD, which means your device compliance signals and your conditional access policies are part of the same control plane as your email, your SharePoint, your Teams. In AirWatch, you're bridging between two platforms. In Intune, you're inside one.

SPEAKER_00 3:09

So that's the case for Intune. But you both suggested the more important question is the model itself. Let's go there. Because I think most people hear mobile device management and have a specific picture in their head of what that means.

SPEAKER_02 3:26

Right, and that picture is usually MDM, mobile device management in the classical sense. You enroll the device, you push certificates to it, you configure Wi-Fi profiles and VPN profiles, you can see the device in a console, you can remote wipe it, you essentially extend your management surface to include the phone. That model made sense in a world where your organization owned the phones. Corporate liable devices. You hand someone a phone, they use it for work, you own the hardware, and you manage the hardware.

SPEAKER_01 3:57

But most organizations aren't running that model anymore. They're running BYOD. Bring your own device. The employee owns the phone. They put their personal photos on it, their personal banking app, their personal email, and they also want to access corporate email and teams and SharePoint. And IT is trying to apply corporate management to a device that doesn't belong to them, and that the employee is going to push back on hard if the management is invasive.

SPEAKER_00 4:24

And this is where the architecture conversation actually matters. Because there's a different model, MAM, mobile application management, and it starts from a fundamentally different premise.

SPEAKER_02 4:39

The distinction is precise, and it's worth stating clearly. MDM manages the device. MAM manages the application. With MDM enrolled, you have a profile on the phone that gives IT visibility and control over hardware level settings. With MAM, specifically Intunes app protection policies, you're not touching the device at all. You're wrapping a set of rules around specific applications. So Outlook on that device has a policy applied to it, Teams has a policy applied to it, the Office apps have policies applied to them. Those policies control what data can do inside and between those apps. But they don't touch the camera app or Instagram or the employee's personal email client. The device remains personal, the apps are managed.

SPEAKER_01 5:23

And when you think through what that actually means, technically, you arrive at something really interesting because the threat model for mobile data loss is almost entirely about data moving from a corporate application to a personal context. Email attachment goes to personal Dropbox. Corporate document gets pasted into a personal note-taking app. Someone takes a screenshot of a sensitive team's message and sends it from their personal account. If you configure app protection policies correctly, those data paths simply don't exist. The operating system, iOS or Android, enforces the separation at the app level. You can't copy text from Outlook and paste it into a personal messaging app. You can't use the iOS ShareShape to send a document from Word to a personal cloud service. You can't save a file attachment to the camera roll. The capability has been surgically removed from those managed apps.

SPEAKER_00 6:13

And this has direct implications for DLP. Data loss prevention on mobile. Because the traditional answer to mobile data leakage has been to run a DLP product that monitors and intercepts outbound data flows. But if the architecture prevents those data flows from existing in the first place, you're not catching violations after the fact. You're not generating alerts and exceptions. You've removed the possibility.

SPEAKER_02 6:45

That's exactly right. DLP on mobile is genuinely hard. Mobile DLP products have to deal with encrypted traffic, sandbox DAPs, operating system limitations on interception. The coverage is inconsistent, the false positive rate is significant, and the maintenance burden is real. App protection. Policies solve a large portion of the same problem from the other direction. Not by monitoring the data as it tries to leave, but by making it structurally impossible for the data to leave through the channels that matter most.

SPEAKER_01 7:26

If someone takes a photo of their screen with a second phone, there's nothing software can do about that. If someone screenshots on iOS, you can block screenshots on Android within managed apps, but iOS doesn't expose that to third-party MDM at the same level. Some of that capability depends on OS version and policy configuration. So the honest position is app protection policies correctly configured eliminate the vast majority of accidental and opportunistic mobile data exfiltration paths. They significantly raise the bar for intentional exfiltration. They don't create an impenetrable vault. No architecture does.

SPEAKER_00 8:02

Which is the correct framing for any security control. You're reducing risk to an acceptable residual level, not achieving zero. Let's talk about what app protection policies actually look like from a configuration standpoint, because I want listeners to have a concrete picture of what these controls do.

SPEAKER_02 8:24

The policy has a few major categories. Data transfer controls. This is where you define what can move in and out of the managed app. Can data be backed up to iCloud or Google Drive? No. Can the app open documents from unmanaged locations? You can restrict this. Can data be pasted into unmanaged apps? No. Can managed apps open links in the personal browser? You can control this. Can the app save files to personal storage? No. Then there are access controls. Require a pin or biometric to open the managed app. Require device compliance, meaning if the device is jailbroken or rooted, or if the OS version is below a threshold you define, the app won't open. And then there are the conditional launch settings. Essentially, health checks, the app runs on launch. If the device doesn't meet them, you can block access or selectively wipe the corporate data from the device.

SPEAKER_01 9:29

The selective wipe is worth pausing on because it addresses one of the biggest objections employees have to MDM. With MDM, there's a genuine concern. The IT admin has a remote wipe capability that applies to the whole device. With MAM and app protection policies, the Selective Wipe only removes corporate data from managed apps. The employees' personal photos, their personal contacts, their personal apps, those are completely untouched. IT manages the data container, not the device. That's a privacy story employees can actually accept.

SPEAKER_00 10:02

And this matters practically, because adoption of a BYOD program depends on employees trusting it. If people are refusing to enroll because they think IT is going to watch their phone, you don't have a mobile program, you have a mobile policy with a compliance gap.

SPEAKER_02 10:23

The adoption story is real. Enrollment rates for MDM-based BYOD programs are consistently lower than for MAM-only approaches because the friction is different. With MDM, you're asking someone to give their employer a management profile on their personal device. With MAM, they install Outlook from the App Store and sign in with their work account. The policy applies in the background. They may not even know it's there unless they try to do something the policy restricts.

SPEAKER_01 10:51

And that invisibility is actually a design goal, not a flaw. The user experience for a well-configured MAM deployment is use Outlook, use Teams, use the Office apps, they work great. You're prompted for a pin when you open them, and everything else on your phone is unchanged. That's the experience you want. Low friction, high protection.

SPEAKER_00 11:10

Part one of this conversation has been about the architecture, why the migration makes strategic sense, and why MAM, with app protection policies, is the right model for a BYOD environment. In part two, we're going to walk through the actual migration. What you need in place before you start, how you configure the policies, how you sequence the cutover, and what the user communication actually looks like. We'll pick it up in part two. This is dark perimeter.