Dark Perimeter: True Cybersecurity Stories
Every major cyberattack has a story behind it. A vulnerability no one patched. A phishing email someone clicked. A nation-state with a motive. Dark Perimeter goes beyond the headlines to explore the true stories of the hacks, breaches, and cyber operations that shaped history - told in narrative form for security professionals and curious minds alike. No guests, no panels, no filler. Just the story.
Dark Perimeter: True Cybersecurity Stories
Dark Perimeter: "Leaving AirWatch Behind" — Part 2: The Migration
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Welcome back to Dark Perimeter. This is part two of our conversation on migrating from AirWatch to Microsoft Intune and specifically building a mobile architecture around app protection policies that protects corporate data on BYOD devices without the overhead of full device management. In part one, we covered the why and the architecture, the MDM vs. MAM distinction, how app protection policies work, and why a well-built MM environment largely eliminates the need for traditional mobile DLP. Now, we're going to get into the how. Vance Hale, let's pick it up where we left off.
SPEAKER_02Before you touch a single configuration screen, you need to know what you're migrating from. That sounds obvious, but it gets skipped constantly. Pull your AirWatch console and do an honest inventory. How many devices are enrolled, what platforms split, iOS versus Android, what policies are currently applied, what apps are being pushed, what compliance rules exist. The reason this matters is that you're going to make decisions during the Intune configuration about what to recreate and what to retire. Airwatch has years of accumulated policy debt in a lot of organizations, Wi-Fi profiles that apply to hardware you no longer have, device restrictions that predate your current security posture, app deployments for apps nobody uses anymore. You don't want to migrate that debt. You want to migrate the intent.
SPEAKER_01The inventory phase also surfaces your licensing position, which is a prerequisite check before anything else. Intune is included in Microsoft 365 Business Premium, in Microsoft 365 E3 with the Enterprise Mobility and Security Add on, and in Microsoft 365 E5. If your organization is on any of those, you likely already have Intune licenses available. Confirm with your Microsoft licensing agreement or your tenant's license assignment in the Intra Admin Center. You need an Intune license assigned to each user whose device you intend to manage.
SPEAKER_02The other prerequisite is your Intra ID tenant. Intune is identity driven. Every policy assignment, every conditional access rule, every compliance state flows through Intra. If you haven't already, you need to confirm that your users are in ENTRA ID. Either cloud native accounts are synchronized from on-premises Active Directory via IntraConnect. This should be in place for any organization already using Microsoft 365, but confirm it before you assume it.
SPEAKER_00Walk me through the platform prerequisites for the devices themselves. Because iOS and Android each have their own enrollment requirements.
SPEAKER_01For iOS, the critical prerequisite is an Apple MDM Push Certificate. This is a certificate issued by Apple that allows any MDM vendor, including Intune, to communicate with Apple managed devices. You obtain it through the Apple Push Certificates portal using an Apple ID. One important operational note: use an organizational Apple ID, not a personal one, and document which Apple ID you used. The certificate expires annually and must be renewed with the same Apple ID. If the person who set it up leaves and took their personal Apple ID with them, you lose your entire iOS enrollment capability when it expires.
SPEAKER_02For Android, the enrollment model has changed significantly in recent years. Modern Android management runs through Android Enterprise, which is Google's enterprise management framework. You connect your Intune tenant to a managed Google Play account, either a corporate Google account or a dedicated enterprise account. This is what allows you to deploy apps through the managed Google Play Store and apply work profile separation on Android devices. The Android WorkProfile model is the Android equivalent of what we described in part one for MAM only. The device gets a separate work profile, a sandboxed partition that contains only managed apps. The personal side of the device is completely separate, and IT has no visibility into it. This is the default for BYOD Android, and it's a strong privacy model.
SPEAKER_00So once the prerequisites are confirmed, licenses, intra ID, Apple push cert, Android Enterprise. What does the Intune configuration look like?
SPEAKER_01The first thing you build is your app protection policies. These are the heart of the MAM Without Enrollment approach for BYOD. You create a policy for iOS and a separate policy for Android because the platforms have different capabilities, and the configuration options differ between them. The key data transfer settings you want to establish, restrict backup of corporate data to personal cloud services, iCloud for iOS, Google Drive backup for Android. Set the policy to allow data transfer only to other policy-managed apps, which means corporate managed apps can share data with each other, but not with unmanaged personal apps. Block cut copy-paste between managed and unmanaged apps. Require PIN or biometric to access managed apps. Set a minimum OS version requirement below which access is blocked. Block access on jailbroken or rooted devices.
SPEAKER_02The PIN requirement is worth a separate word because it's where you'll get the most user pushback. Users are already unlocking their phone with face ID or a fingerprint. Now they also have to tap a pin to open Outlook. For some users that's fine. For others it feels redundant and frustrating. The practical answer is to allow biometric as an alternative to PIN, which both iOS and Android support in the app protection policy configuration set the policy to require PIN or biometric, and most users will use biometric and never see a PIN prompt under normal conditions. That removes almost all of the friction.
SPEAKER_00What about the apps themselves? Because app protection policies only work if the app on the device supports the Intune SDK.
SPEAKER_01This is an important constraint to understand. App protection policies work by leveraging a Microsoft-provided software development kit that app developers build into their applications. Microsoft's own apps all support it Outlook, Teams, Word, Excel, PowerPoint, OneDrive, SharePoint, Edge, OneNote. That covers the vast majority of what most organizations need on mobile. Third-party apps are a mixed picture. Some major enterprise apps, Salesforce, ServiceNow, some SciM mobile clients have been, you know, you know, have implemented the Intune SDK, others have not. For apps that don't have native SDK support, Microsoft provides an app wrapping tool that can add policy enforcement to certain apps outside the development process, but this has limitations and works primarily with in-house or internally distributed apps.
SPEAKER_02The practical implication is this: before you finalize your policy design, audit which apps your users actually need on mobile for work. For the Microsoft apps, you're covered out of the box. For anything else, check the Intune Protected Apps list. Microsoft maintains a public list of apps that support app protection policies. If an app your users need isn't on it and you can't use the wrapping tool, your options are to accept that gap, find an alternative app that is supported, or negotiate with the vendor about adding SDK support.
SPEAKER_00Let's talk about conditional access, because this is the enforcement mechanism that makes the whole architecture actually function. Without it, app protection policies exist. But nothing enforces that users access corporate data through policy-managed apps.
SPEAKER_01Conditional access is configured in Intra ID, and it's essentially a policy engine that evaluates conditions at sign-in and decides whether to grant, block, or require additional controls. For a MAM-based mobile architecture, the condition you're interested in is when a user signs in from a mobile device to exchange online SharePoint or Teams, require that they're using an approved client app with an app protection policy applied. The specific grant control in conditional access is called require approved client app and require app protection policy. You can require both together. When a user tries to access corporate exchange from their phone's native mail app, which has no Intune SDK integration, conditional access blocks access, and the user gets a message directing them to use Outlook instead.
SPEAKER_02This is the moment where the architecture actually closes. You've defined what apps are allowed and what policies those apps must carry. You've blocked everything that doesn't meet that bar at the identity layer. The user's options on mobile are now use the Manage Microsoft apps with the policies applied, or don't get access. You've channeled all mobile data access into the protected container without touching anything else on the device.
SPEAKER_00How do you sequence the actual migration from AirWatch? Because you presumably can't flip a switch and have everything cut over simultaneously.
SPEAKER_02The sequence matters a lot, and the general principle is build, validate, pilot, then wave out. Never do a simultaneous cutover. Step one is building the Intune environment in parallel with AirWatch still running. Configure your app protection policies. Your app configuration policies, SOR, BOSM or CURIS, those are separate from protection policies. They let you pre-configure app settings like the user's UPN and the Exchange Server URL, so Outlook sets itself up automatically showing your conditional access policies. Do this in a test or staging mode before you enforce anything. Step two is a pilot group. Take a small, technically comfortable segment of users, ideally IT staff and a few volunteers from different departments. And sell SSIM and enroll them in the new configuration while still enrolled in AirWatch. Let them run both simultaneously for a period. Validate that Outlook teams and the Office apps work correctly under the app protection policies. Validate that users can't share data to personal apps as expected. Validate the conditional access blocks. Validate the selective wipe.
SPEAKER_01Step three is the wave rollout. Once the pilot validates, you retire the pilot users from AirWatch and push them fully to the Intune model. Then you proceed through the rest of the organization in waves, typically by department or by manager hierarchy. Whatever your org structure makes convenient for communication. The wave approach also manages your support burden. Mobile migrations generate support tickets, users who can't access email after the cutover, users who are confused by the new PIN prompt. Users who try to share a document and find they can't. If you do this with thousands of users simultaneously, you will overwhelm your help desk. Waves give you a manageable load.
SPEAKER_02Step four, and this is where things often drag on longer than they should, is the AirWatch decommission. This requires you to actually retire each device from Workspace One. You can send a retire command from the AirWatch console that removes the management profile from the device without wiping it. Do this wave by wave as each group completes the transition to in tune. Don't let AirWatch linger half enrolled. You're paying for licenses you no longer need, and you're carrying a management surface you're no longer actively maintaining.
SPEAKER_00User communication is the piece that technical teams consistently underinvest in. What does that actually look like in practice?
SPEAKER_02The message has to answer three questions before the user asks them, what is changing? What do I need to do? What happens if I don't do anything? For a MAM-only BIOD migration, the what is changing is minimal, and that works in your favor. You're not asking them to enroll their device in anything. You're not installing a management profile. You're asking them to install or update Outlook and Teams from the App Store, sign in with their work account, and set up a PIN or use biometric for those apps. That's it. Most users will describe that as IT change some settings on the work apps on my phone.
SPEAKER_01The privacy communication is worth spending real words on. Employees will wonder what IT can now see on their phone. The honest answer, and you should say it explicitly, is it can see whether the managed apps are compliant, whether the device is jailbroken, whether the OS version meets requirements. And IT can remove corporate data from the managed apps if you leave the company or if a device is reported lost. IT cannot see your personal apps, your personal photos, your personal contacts, your location, your browser history, or anything else on your personal device. That's not a limitation of the implementation. That's the architecture.
SPEAKER_00Let me ask the gotcha question. What breaks? What are the failure modes that don't show up in the planning phase but hit you in production?
SPEAKER_02A few reliable ones. First, legacy email clients, Android's native email app, Apple Mail, third-party clients, any of these that are still configured to hit exchange are going to stop working when conditional access enforces the approved app requirement. Users who set up their personal mail client to pull corporate email years ago and never thought about it again will suddenly have a broken mail app and no idea why. Your help desk needs a ready answer for this. Use Outlook. Here's the download link. Second, shared devices. If anyone in your organization is sharing phones or tablets, frontline workers, shared kiosk devices, checkout devices, the BYOD MAM only model doesn't work cleanly for those. Those are candidates for full MDM enrollment with dedicated device enrollment, not the user-enrolled BYOD model. Identify them before you start and handle them separately.
SPEAKER_01Third, certificate-based Wi-Fi or VPN. If AirWatch is currently pushing certificates to devices that enable corporate Wi-Fi or VPN connections, and you're moving to MAM only without device enrollment, you lose the mechanism for pushing those certificates. Per app VPN on MAM enrolled devices is possible, but the configuration is more complex. And plain Wi-Fi certificate delivery requires device enrollment. If your mobile workforce needs VPN access or certificate-based Wi-Fi, factor that into your enrollment model early. You may need MDM enrollment for corporate liable devices, alongside MAM only for BYOD.
SPEAKER_02And fourth, the one nobody talks about until they hit it is conditional launch failures on devices that fail compliance checks in ways the user can't fix. An employee running an iOS version below your minimum requirement suddenly can't open Outlook and doesn't know why. Your documentation and help desk scripts need to cover these scenarios. The Intune portal will tell you why a device is non-compliant. Make sure your help desk knows how to read it.
SPEAKER_00The picture that emerges from both parts of this conversation is that the migration from AirWatch to Intune done correctly is less about replicating what you had and more about building something architecturally better. Ma'am, with app protection policies, conditional access, enforcing approved apps, and selective wipe as the offboarding mechanism. That's a mobile security architecture that protects data effectively, respects employee privacy, and removes a whole category of DLP complexity from your environment. The path to get there isn't a single cutover. It's prerequisites, pilot, waves, and honest communication. The level of effort is real, but it's tractable. And at the end of it, you've consolidated a standalone product into your existing Microsoft estate, and you have a mobile program you can actually explain to your users. Hail, this was a good one. Thanks for walking through the full picture. This is dark perimeter.