Explore the Library

Sponsors

Principal Sponsor

Cloud Forge Automation

Intune endpoint automation, PowerShell tooling, and Graph-native engineering — with contract engineers available for your fleet. Built by the same hands that maintain these guides.

Visit Cloud Forge Automation →

Core Contributors 🏆

Other Resources

Starting is pretty easy. Just navigate the sidebar menu on the left and scroll through the content you are interested in. But let's see how you can get the most value out of the guides.

Get the Most out of the Content

As you can see on the left, there are multiple topics covering the platform you have selected — switch platforms at the top of the sidebar and the entire site follows. The goal is to add a short overview, a guide to configure the setting or policy, as well as insights based on real-world experiences that are not documented anywhere else, e.g., Microsoft Docs.

This list is growing, and we want you to help us improve and add more content. Check out How to Contribute.

Navigating the Site

• Sidebar Menu: Use the sidebar menu on the left to quickly find the topics you are interested in.
• Search Functionality: Use the search bar at the top to find specific guides, tools, or best practices.

Types of Content Available

• Guides: Step-by-step instructions on how to set up and configure enrollment, policies, and apps.
• Scripts: Ready-to-use Microsoft Graph automation to manage your fleet at scale, straight against the same API the console uses.
• Best Practices: Recommendations based on industry standards and real-world experiences.
• Insights: Unique insights and tips that you won't find in official documentation, shared by community members.

Where to Start

1. New tenant? Begin with the Intune Getting Started Guide.
2. Deploying corporate devices? Follow the Complete Deployment Guide from start to finish.
3. Deploying corporate devices? Start with the Android Enterprise Overview and Choosing a Management Mode.
4. Deploying corporate devices? Start with the Windows Management Overview and Choosing an Enrollment Path.
5. Deploying corporate devices? Start with the Management Overview and Choosing an Enrollment Method.
6. Supporting BYOD? Read Choosing an Enrollment Method and App Protection Policies.
7. Supporting BYOD? Read Work Profile (BYOD) and App Protection Policies.
8. Supporting BYOD? Read Windows MAM and the enrollment-path guidance.
9. Supporting BYOD? Read User-Approved Enrollment.
10. Want quick wins? Import the Baseline Settings.

Thank You!

Thank you for being a part of the IntuneNerds community. Together, we can make endpoint administration with Microsoft Intune easier and more efficient.

IntuneNerds is community-driven. Every guide, script, and insight on this site comes from admins managing real production fleets. Contributions of any size are welcome — from fixing a typo to writing a full topic section.

What We're Looking For

• Guides: Step-by-step configuration walkthroughs with screenshots.
• Insights: Real-world behavior that isn't documented — timing quirks, gotchas, scale considerations.
• Scripts: Microsoft Graph automation for device management (PowerShell preferred, pure REST or SDK both accepted).
• Corrections: Intune and the platforms it manages change constantly. If a guide is out of date, tell us or fix it.

How It Works

1. Fork the repository on GitHub.
2. Content lives in src/content/docs/ as Markdown/MDX. Copy an existing page as a template.
3. Open a pull request. A maintainer will review, suggest edits if needed, and merge.
4. Your name gets added to the Contributors page.

Writing Guidelines

• Lead with what the reader accomplishes, then the steps.
• Note the OS version requirements for every setting, plus any enrollment-type or management-mode constraint that gates it.
• Call out whether a setting applies to user-enrolled (BYOD) devices.
• Use the exact labels from the Intune admin center so readers can follow along.
• State the platform and OS version you validated on — a guide is only as trustworthy as its test evidence.
• Insights pages are for the things Microsoft Docs won't tell you — be specific.

Not a GitHub User?

Open an issue describing your idea, or reach out through the Feedback page and we'll help you get the content published.

Every guide on this site got better because someone who runs these fleets took the time to improve it. This page is where we say thank you, by name.

Core Contributors

Community Contributors

Contributors are listed here as pull requests are merged. Add your name by contributing on GitHub!

We want this site to be the place you check before you build anything in Intune. That only works if you tell us what's missing.

Ways to Reach Us

• GitHub Issues: The fastest way — open an issue for content requests, corrections, or bugs.
• GitHub Discussions: For open-ended questions and ideas — start a discussion.

What Helps Most

• Which guide you were reading and what was unclear or out of date.
• The Intune service release and device OS version where behavior differed from the guide.
• Topics you searched for and didn't find.

June 2026 — Initial release 🎉

IntuneNerds is live. The site launches complete rather than aspirational: 302 deep-dive guides across four platform libraries, written and tested by working endpoint engineers, with the failure modes documented next to the happy paths. Pick your platform at the top of the page and the entire site — navigation, search, and every guide — follows your selection.

• 🚀 Four complete platform libraries — every guide written platform-pure for the fleet you actually manage, with explicit prerequisites, step-by-step processes, and verification on every procedure.
• 📱 iOS — 67 guides at launch: the complete deployment guide from ABM through ADE and VPP, Declarative Device Management, Shared iPad, kiosk modes, importable baseline settings, and a full troubleshooting track — plus the Open-Source Toolbox with 20+ vetted community projects.
• 🤖 Android — 67 guides at launch: all four management modes, Managed Google Play, zero-touch and KME supply-chain enrollment, the Play Integrity deep dive, dedicated-device patterns, and a full troubleshooting track — plus the Open-Source Toolbox with 20+ vetted community projects.
• 🪟 Windows — 69 guides at launch: Autopilot end to end, the Settings Catalog, Update for Business rings, Win32 app packaging, the endpoint security family, and a full troubleshooting track — plus the Open-Source Toolbox with 20+ vetted community projects.
• 💻 MacOS — 67 guides at launch: Automated Device Enrollment, Platform SSO, FileVault with escrow, DDM software updates, PPPC, the app deployment toolkit, and a full troubleshooting track — plus the Open-Source Toolbox with 20+ vetted community projects.
• 🧪 Intune Simulator — a full, browser-based replica of the Microsoft Intune admin center that runs entirely on your device. Generate a tenant of users and devices, build dynamic groups with real query logic, deploy configuration profiles, apps, compliance, and Endpoint security, then advance time to watch check‑ins, compliance drift, and queued device actions land. Nothing touches a real tenant — the safe place to learn the console before you click in production.
• ⚙️ Graph API Automation — a production PowerShell script library (inventory reports, bulk actions, license audits, connector health) and a snippets collection built to copy, adapt, and ship.
• 🏛️ Architecture Corner — design decisions for scale: RBAC and scope tags, MDM migrations, and sovereign clouds.
• 🎓 Start Here — the 30/60/90 Learning Path, a per-platform glossary, and Build a Lab with step-by-step lab builds.
• 🔎 The site itself — platform-scoped navigation and search (Ctrl/Cmd+K), per-page contents, prev/next reading chains, dark and light themes, and a single fast page that works offline once loaded.
• 🤝 Community — curated resources, tools and scripts, and an open contribution path. Launch made possible by our principal sponsor, Cloud Forge Automation.

From here, every change to the library lands on this page.

Endpoint management rewards structured learning: the concepts stack, and the order matters. This path takes you from nothing to genuinely competent in ninety days of consistent effort — read, then build, then break, in that loop, every week. The spine is universal; the milestones below adapt to the platform selected.

Days 1–30 — Foundations. Understand what MDM actually is, build your lab, enroll your first devices, and learn the tenant's anatomy: groups, filters, profiles, apps, compliance. Goal: you can explain enrollment-to-policy flow on a whiteboard.

Days 31–60 — Depth. Pick your platform's hard topics and go deep; ship your first Graph script; break things in the lab on purpose and fix them with the troubleshooting pages. Goal: you've diagnosed three failures to root cause.

Days 61–90 — Production thinking. Rings, RBAC, change discipline, reporting rhythms, and the architecture corner. Goal: you can defend a design decision to a skeptical room.

Beyond Ninety Days

The durable habits outrank any badge: a lab that stays warm, a Graph script library that grows monthly, the What's New feed read with coffee, and one community contribution — here, ideally — per quarter.

Insights

• The single highest-leverage habit on this path: write down every failure you diagnose — symptom, wrong guesses, root cause. Ninety days of that document is worth more in an interview than any certification, because it's proof you've actually operated.

Official Microsoft docs: What is Microsoft Intune?

Bookmark this. Terms link to the page that covers them in depth. Core terms apply everywhere; the rest are specific to the platform you have selected.

Core Terms

Official Microsoft docs: What is Microsoft Intune?

Every confident production change on this site was rehearsed somewhere safe first. A lab is where enrollment flows get broken on purpose, where scripts run their first time, and where "what happens if" gets answered without a ticket queue watching. The good news is that the foundation is identical on every platform: a dedicated test tenant (a free Intune trial or developer tenant — never a corner of production), a naming discipline (LAB- prefixes on everything so nothing ambiguous ever reaches a production scope), the snapshot ethos that keeps every lab device one reset away from clean, and a fence of scope tags plus a dedicated RBAC role so experiments physically cannot touch production objects. Build that spine once and it carries iOS, Android, Windows, and macOS equally. What goes into the lab differs by platform — and each platform gets its own dedicated page below.

Adopt the universal spine

These steps are platform-agnostic. Do them once, in order, and you have a tenant that any of the four platform labs can plug into. None of them touches device hardware yet — this is the part of the lab that lives entirely in the admin center.

1. Stand up the dedicated tenant. Create a free Intune trial or a Microsoft 365 developer tenant — never a slice of production. This is the single rule that makes everything afterwards safe: a tenant that contains nothing real can't break anything real. Sign in once and confirm Intune is provisioned before you go further.
2. Apply LAB- naming from the very first object. Prefix every group, profile, policy, app, and filter with LAB- the moment you create it. The discipline pays off the first time you copy something toward production and the name announces exactly where it came from — and it makes a stray lab object impossible to mistake for the real thing.
3. License one admin and one test user. You need exactly two identities to exercise every flow: an administrator to build and assign, and a standard test user to receive policy and feel what a real end user feels. Resist the urge to license more — a two-account lab stays cheap and stays honest.
4. Fence the lab with scope tags and a dedicated RBAC role. Create a LAB- scope tag, tag every lab object with it, and grant your lab work through a dedicated RBAC role scoped to that tag alone. Now an experiment cannot reach a production group even if you fat-finger an assignment — the fence is structural, not a matter of remembering to be careful.
5. Calendar any certificate renewals the day they're issued. Some platform labs mint certificates with hard expiry dates — Apple's APNs certificate is the classic example. The instant you issue any cert in the lab, put its renewal on a calendar. Rehearsing the renewal you'll own in production starts with never letting the lab's own cert lapse silently.

Then build your platform's lab

With the spine in place, the rest is platform-specific — different hardware truths, different virtualization stories, different things that simply refuse to be simulated. Each page below reuses and expands the per-platform build it once lived inside: what you're building, prerequisites, the step-by-step, the honest limits, and exactly what to rehearse.

Lab hygiene, everywhere

The platform pages differ, but the working habits don't. These practices apply identically whether your lab is a drawer of spare iPhones, a folder of emulators, a stack of checkpointed VMs, or a bench Mac — and they're what separate a lab that builds confidence from one that just burns time.

• Snapshot before every experiment. A clean restore point ahead of each change means you're always one revert from a known-good state — and you'll actually run the risky test instead of tiptoeing around it.
• Provoke failures on purpose. Break enrollment, fail an app install, expire a token, watch the timeout. A failure you caused and watched end to end is the fastest education in reading the ones you didn't.
• Mirror your production ring structure. Build the same group and ring layout you run in production so what graduates from the lab lands in a shape ring 1 already recognizes — the lab is the first rung of that same ladder.
• Document what broke and how you fixed it. A short note per failure turns a one-time scramble into a runbook, and turns incident response from research into recognition.

When you want to rehearse a console flow without standing up any hardware at all, practice risk-free in the Intune Simulator — every click is reversible, so it pairs naturally with the snapshot-and-break ethos above.

Insights

• The lab's highest-value product isn't validation — it's calibrated confidence: knowing exactly what a failure looks like before it happens in production turns incident response from research into recognition.
• Budget honesty: a free tenant, two licensed identities, and whatever your platform's page calls for — usually one spare device, one bench unit, and a hypervisor you already own. The lab that never gets built is the one specced as a rack; the one that changes your career fits in a drawer.

Official Microsoft docs: What is Microsoft Intune?

The universal lab foundation — dedicated test tenant, LAB- naming discipline, the snapshot ethos, and scope-tag fencing — lives on the cross-platform Build a Lab hub; this page is the iOS/iPadOS-specific build that sits on top of it.

An iOS lab is one dedicated test tenant, one physical device you are free to wipe, and a small set of Apple relationships that belong to the lab alone. The non-negotiable hardware truth up front: simulators don't enroll. The Xcode iOS Simulator renders a UI, but it has no MDM stack — no enrollment, no profile delivery, no managed app installation, no APNs path. Everything that makes this site real requires physical hardware, so the centerpiece of the lab is at least one real iPhone or iPad. An older spare is ideal: enrollment behavior, restriction handling, and app-config delivery do not need a current model, and an aging device you can reset without a second thought is worth more than a flagship you instinctively protect.

The Lab at a Glance

Five moves take you from a blank tenant to a device you are deliberately breaking. Most of this needs no Apple Business Manager at all — only the final ADE-dependent rehearsals do, and the ABM Reality section below explains where those go instead.

Prerequisites

• A dedicated test tenant (free Intune trial or developer tenant), fenced with its own LAB- naming on every group, profile, and policy so nothing ambiguous ever drifts toward a production scope.
• A separate, team-owned test Apple Account for the lab — never your personal account, and never the production organizational account that backs your live APNs certificate.
• The lab tenant's own APNs certificate, created with that lab Apple Account, with the renewal date calendared the day it is issued — the same one-year clock you will own in production, rehearsed where a lapse costs nothing.
• One spare iPhone or iPad dedicated to the lab, a cable, a desktop running Apple Configurator (macOS) or the bench-recovery equivalent, and the patience to wipe the device often.

Build It, Step by Step

1. Stand up the tenant. Create the trial or developer tenant, license one admin and one test user, and apply the LAB- naming discipline from the first object you create. The habit pays off the first time you copy a policy into production and the name announces exactly where it came from. Fence it immediately with scope tags and a dedicated RBAC role so a stray assignment can never reach a real group.
2. Create the lab Apple relationship. Sign up the test Apple Account, then issue the APNs certificate for the lab tenant with it. Nothing Apple-side enrolls until this certificate exists — every command Intune sends to every Apple device flows through APNs using it — and creating one in the lab demystifies the production renewal you will eventually own. Note the identity that created it: renewing with a different Apple Account forces a re-enroll, which is itself a failure mode worth seeing here first.
3. Supervise the spare device locally. Wipe the device and supervise it with Apple Configurator. Local supervision unlocks most of the supervised-only surface — device restrictions, Single App and kiosk modes, forced settings, non-removable management — without any organizational ABM enrollment, which makes it the fastest route to testing the policies that matter most. This is the single highest-leverage step: it gives you a supervised device to aim policy at today.
4. Enroll and start breaking things. Enroll the supervised device into the lab tenant, deliver a configuration profile, deploy an app, then deliberately cause the failures documented on the troubleshooting pages so you see each one where it costs nothing: provoke an enrollment error, force a profile installation failure with a conflicting payload, and block APNs at the network edge to watch push connectivity degrade. A failure you caused on purpose is the fastest education in reading the ones you didn't.
5. Optional, but career-changing: run an open-source MDM for a weekend. Pointing micromdm or nanomdm at the spare device teaches you what the MDM protocol actually does under Intune's console — the enrollment handshake, the command/result loop, the APNs wake. Every enrollment conversation you have afterward is sharper for it.

The ABM Reality

Apple Business Manager is a real-organization enrollment: legal-entity details, a D-U-N-S number, and a verifiable contact mean a throwaway lab ABM usually isn't possible — and shouldn't be faked. Plan for it instead of fighting it. The flows that require ABM — full Automated Device Enrollment, the Intune–ABM token exchange, Apps & Books (VPP) licensing, and Return to Service — get rehearsed on a production ring-1 device, which is precisely what ring 1 exists for. Everything else on this page works without ABM, and one detail bridges the gap honestly: a device captured into ABM with Apple Configurator's enrollment-capture behaves like an ADE device, but the capture is real and not reversible on a whim — so reach for it on production ring-1 hardware, not a borrowed spare.

What to Rehearse Here

Insights

• The lab's highest-value product isn't validation — it's calibrated confidence: knowing exactly what a failed APNs push or a conflicting restriction looks like before it happens in production turns incident response from research into recognition.
• Budget honesty: one spare iPhone, a free tenant, and a Mac you already own. The iOS lab that never gets built is the one specced as a fleet of devices; the one that changes your week fits in a drawer.
• Local supervision plus the open-source MDM weekend together teach more about Apple management than any amount of console clicking — the protocol stops being a black box.

Official Apple docs: Apple Configurator User Guide · Apple Platform Deployment

Every confident production change starts as a rehearsal somewhere safe. The universal foundations of a lab — a dedicated test tenant (a free Intune trial or developer tenant, never a corner of production), a LAB- naming discipline so nothing ambiguous ever reaches a production scope, and the snapshot ethos that keeps every device one reset away from clean — are covered once on the universal Build a Lab hub. This page is the Android-specific build: what goes into the lab, what runs on the emulator, what genuinely needs metal, and exactly what to rehearse before any of it touches a managed fleet.

What You're Building

Android is the friendliest platform to lab, because Google built the lab tools. The reference device policy controller (Test DPC), emulator images that take real enrollments, and a free work-profile sandbox mean most of the lab runs on the machine you are reading this on — with one physical device reserved for the hardware-only truths. The arc is: bind Managed Google Play once, learn the platform's ceiling with Test DPC, enroll emulators in every management mode side by side, and keep the spare Pixel for NFC, QR, FRP, and battery behavior that no virtual device can fake.

Prerequisites

• A dedicated test tenant (free Intune trial or developer tenant) with LAB- naming on every group, profile, and policy. Fence it with scope tags and a dedicated RBAC role so experiments can never reach a production group.
• A dedicated Google account for the lab's Managed Google Play binding — owned by the team, documented, and never reused from production. This account becomes the permanent enterprise binding identity, so make it an organizational mailbox (mgp-lab@yourdomain-style), never a personal Gmail.
• Android Studio with Play-enabled emulator images (pick an AVD system image whose target shows the Google Play badge, not merely Google APIs — only Play images carry the Managed Google Play surface enrollment needs). Container-minded engineers can use emulator-container-scripts instead.
• One spare physical device — a spare Pixel is ideal because it is GMS-certified, gets provisioning fixes first, and is cheap to keep current — that you are free to factory-reset repeatedly.

Build It, Step by Step

1. Stand up the tenant and bind Managed Google Play. Create the trial or developer tenant, license one admin and one test user, and apply LAB- naming from the first object. Then bind Managed Google Play with the lab Google account. This connection is the gateway every Android Enterprise enrollment and app deployment depends on — making the lab binding by hand rehearses the single most consequential setup step the platform has, and it is five minutes that unlocks the entire Android Enterprise surface.
2. Install Test DPC and learn its toggles. Test DPC is Google's reference device policy controller, and it exposes every Android Enterprise capability as a switch. When you wonder whether the platform supports something the Intune UI doesn't expose, Test DPC answers in five minutes — before you spend a day on a support case arguing about a setting that was never going to exist. It is also the cleanest way to feel the work-profile boundary and the fully-managed surface without any console in the way.
3. Enroll emulators in every management mode. Android Studio AVDs with Play images take real work-profile and fully-managed enrollments. Build one of each — work profile (BYOD), fully managed, corporate-owned work profile, and a dedicated-device enrollment — side by side. Mode comparison becomes a laptop exercise instead of a hardware shuffle, and you can leave all four running while you lead a choosing-a-mode conversation from the screen in front of you.
4. Use the physical Pixel for the hardware truths. Factory Reset Protection behavior, NFC provisioning, camera/QR enrollment flows, and battery realities only exist on real hardware. Generate QR provisioning payloads from the lab tenant and run the full dedicated-device flow on the Pixel — the bump-or-scan moment, the network-during-setup behavior, the wipe-and-re-provision loop. This is the device that tells you the truth about provisioning.
5. Put Shelter on a personal device. Shelter creates a work profile with no MDM attached — a free education in exactly how the profile boundary feels to your users: the badged apps, the separate clipboard, the cross-profile prompts. It is the part no console screenshot teaches, and it costs nothing but an afternoon.
6. Provoke the failures on purpose. Once the modes enroll cleanly, break them deliberately: a deliberately-failed Play Integrity verdict, a stalled app install, a work profile that won't provision. Each failure caught in the lab is worth ten tickets read cold — see the enrollment-error and work-profile troubleshooting pages for the failures worth rehearsing first.

Honest Limits

Two things genuinely resist simulation, and pretending otherwise wastes a weekend. Zero-touch enrollment requires a real reseller relationship — devices are registered to your enterprise at the point of purchase, which a throwaway lab cannot fabricate. The honest workaround: QR provisioning payloads generated from the lab tenant produce the same provisioning result, just triggered by a scan instead of by the supply chain, so you rehearse everything downstream of the trigger. The same logic applies to Samsung KME. The second limit is OEMConfig: a schema is only as real as the device that implements it, so OEMConfig testing honestly requires the OEM's own hardware. A Pixel will not validate a Samsung Knox OEMConfig key. Budget a borrowed or surplus unit of the specific OEM you manage when that day comes, and treat the emulator as out of scope for OEMConfig from the start.

What to Rehearse Here

Insights

• The lab's highest-value product isn't validation — it's calibrated confidence: knowing exactly what a Play Integrity failure or a stalled provisioning looks like before it happens in production turns incident response from research into recognition.
• Budget honesty: Android needs the least hardware of any platform. One spare Pixel, a laptop running Android Studio, and a free tenant cover the entire surface short of zero-touch and OEMConfig. The lab that changes your career fits in a drawer, not a rack.

Official references: Microsoft Intune enrollment deployment guide — Android · Android Enterprise · Android Management documentation

Every confident production change starts as a rehearsal somewhere safe. The universal foundations — a dedicated test tenant, LAB- naming on everything, scope-tag fencing, and the one-reset-from-clean ethos — are covered on the cross-platform Build a Lab hub; start there if you haven't. This page is the Windows-specific build, and Windows is the most rehearsable platform in the fleet for one reason: VMs take real Autopilot enrollments. The entire pipeline — hardware-hash registration through ESP completion — runs on the machine you are reading this on. The lab's superpower is checkpoint discipline: snapshot once at the out-of-box screen, and every experiment afterwards is a two-minute revert instead of a half-hour reinstall.

What You're Building

A Windows lab is a dedicated tenant, a hypervisor with room for a handful of checkpointed virtual machines, and one physical machine held in reserve for the hardware-bound truths. Virtualization is a first-class citizen here, not a compromise: a Hyper-V VM registers as Autopilot hardware, runs the full user-driven flow, holds at the Enrollment Status Page while policy and apps land, and reverts to a clean OOBE in two minutes so the next experiment starts identical to the last. That revert loop is what turns Windows enrollment from a thing you watch once into a thing you drill until it's muscle memory.

The high-level arc looks like this:

Prerequisites

• A dedicated test tenant (free Intune trial or developer tenant) with LAB- naming on every group, profile, and policy — the habit pays off the first time you copy something into production and its name announces exactly where it came from.
• A hypervisor — Hyper-V is the natural choice on a Windows host, but any hypervisor that exposes a TPM works — with enough disk for several checkpointed VMs. Each checkpoint chain costs real space; budget for it rather than discovering the limit mid-drill.
• Get-WindowsAutopilotInfo for harvesting hardware hashes, and Get-AutopilotDiagnosticsCommunity for decoding what the enrollment actually did afterwards — install both from the PowerShell Gallery before you need them.
• One physical machine for the truths a VM cannot represent: real firmware, TPM attestation, docking-station behavior, and vendor drivers.

Build It, Step by Step

1. Stand up the tenant. Create the trial or developer tenant, license one admin and one test user, and apply the LAB- prefix discipline from the first group you create. Confirm Entra join is permitted for your test user and that the MDM auto-enrollment scope covers the lab group — Windows enrollment rides identity, so this verification is the real setup work.
2. Build the reference VM and checkpoint it at OOBE. Install Windows in the VM, enable a virtual TPM, stop at the first out-of-box-experience screen, and take the checkpoint. This checkpoint is the lab. Every enrollment experiment starts from it and ends with a revert, which is the entire reason a Windows lab is faster than any other platform's.
3. Harvest the hash and register the VM. From the VM, run Get-WindowsAutopilotInfo to export the hardware hash, import it into the lab tenant, and assign the lab's Autopilot deployment profile (user-driven, Entra join). The VM is now corporate-registered hardware as far as the pipeline is concerned — indistinguishable from a real device to Intune.
4. Run the full user-driven flow, including ESP. Revert to the OOBE checkpoint, boot, and run Autopilot user-driven end to end. Watch the Enrollment Status Page hold the session while policy and apps land — the blocking-apps decision you make here defines the provisioning experience forever after. Then revert, change one variable, and run it again. The two-minute loop is what makes Windows worth labbing at all.
5. Break ESP on purpose. Assign an app that cannot install — a deliberately broken Win32 package, an impossible requirement rule — and watch the timeout behavior. Then decode the result with Get-AutopilotDiagnosticsCommunity and the Autopilot and ESP failures playbook. An ESP failure you caused on purpose is the fastest possible education in reading the ones you didn't.
6. Reserve the physical machine for hardware truths. Move to metal for the flows a VM genuinely cannot fake: real firmware and DFCI, vendor driver and firmware update behavior, TPM-attestation nuances, and dock or peripheral quirks. OSDCloud from the open-source toolbox earns its slot here for bare-metal-to-Autopilot practice — imaging a wiped machine straight into your registered fleet.

What Needs Real Hardware

A VM carries the enrollment pipeline faithfully, but four things resist virtualization and belong on the physical machine. Firmware and DFCI: Device Firmware Configuration Interface speaks to UEFI settings a hypervisor doesn't expose, so locking the BIOS or disabling boot devices is a metal-only drill. Driver and firmware updates: the vendor catalog only delivers to the hardware it matches, so update behavior is meaningless on a VM. TPM attestation: a virtual TPM passes the basic Autopilot checks, but attestation-backed flows and conditional-access posture want a real, vendor-provisioned TPM to be honest. And docks, peripherals, and battery realities simply don't exist in a VM. Treat the physical machine as scarce and precious — most of your hours live in the VM revert loop, and the metal is for the specific truths only it can tell.

What to Rehearse Here

Insights

• The Windows lab's highest-value product isn't validation — it's calibrated confidence. Knowing exactly what a broken ESP looks like before it happens to a real user turns incident response from research into recognition.
• Budget honesty: a hypervisor you already own, one physical machine you can wipe, and disk for a few checkpoint chains. The Windows lab that never gets built is the one specced as a rack of hardware; the one that changes how you work fits inside a single workstation.

Official Microsoft docs: Intune enrollment deployment guide for Windows

What You're Building

Apple silicon made the Mac lab genuinely affordable. UTM and Parallels — both built on Apple's Virtualization framework — spin up disposable macOS guests that are gold for profile testing, script dry-runs, and validating each new OS release before it reaches the fleet. Sitting underneath that fast tier is one piece of real metal: a bench Mac you are willing to erase. On Apple silicon, Erase All Content and Settings makes a full reset a sixty-second menu item rather than a reinstall afternoon, so the same physical unit can take a fresh enrollment several times a day. The whole lab — host, VMs, and one used Mac mini — fits in a drawer and costs less than a single production incident.

Prerequisites

• A dedicated test tenant (free Intune trial or a developer tenant) with LAB- prefixing on every group, profile, and policy so nothing is ever mistaken for production.
• A lab Apple Account created as an organizational identity (appleid-mdm-lab@yourdomain, backed by a shared mailbox) — never a personal Apple ID, because it owns the lab tenant's push certificate and must outlive whoever set it up.
• The lab tenant's APNs certificate (one per tenant covers every Apple enrollment) and, for device enrollment, an ADE token exchanged against the lab's own ABM organization.
• An Apple silicon host running UTM or Parallels for disposable VMs, plus one erasable bench Mac — a used mini earns its keep inside the first quarter.

Build It, Step by Step

1. Stand up the tenant. Spin up a trial or developer tenant, license one test user, and commit to LAB- naming immediately — the discipline is worthless if it starts late.
2. Wire the Apple plumbing in order. Connect the lab Apple Account's APNs certificate first (nothing Apple enrolls without it), then exchange an ADE token against the lab's ABM organization, and add a VPP token so app licensing exists before your first app assignment. Calendar the APNs renewal before you close the tab.
3. Create the disposable VM tier. Build a UTM or Parallels guest per OS release you support, snapshot each one in a clean state, and make this tier the default first-run destination for every profile, script, and update policy. Revert-to-snapshot is your fastest reset.
4. Put the bench Mac through real enrollment. Assign it an ADE profile in the lab tenant and run Automated Device Enrollment end to end — Setup Assistant, MDM check‑in, the works. VMs are never ABM-known hardware, so this physical unit is the only thing that tells you the truth about the enrollment flow.
5. Rehearse the bootstrap token and FileVault escrow. Confirm the bootstrap token escrows to the lab tenant during enrollment, enable FileVault, and verify the personal recovery key escrows and is retrievable from the admin center. Then deliberately simulate a locked-out morning and recover from the escrowed key — before a real one makes it urgent.
6. Reset and repeat. Use Erase All Content and Settings to wipe the bench Mac back to a clean Setup Assistant and run the whole sequence again. Each loop is one more rehearsal of the day a real device fails.

The ABM + virtualization reality

This is the one place a Mac lab cannot cheat, and it mirrors the iOS story exactly. ADE requires Apple Business Manager, and ABM requires a real organization — a legal entity, a D-U-N-S number, a verifiable contact, and a signup that takes days. There is no sandbox ABM. So your lab tenant either gets its own real (small) ABM organization, or you accept that the genuine ADE rehearsal happens on a ring-1 device in the org's actual ABM, treated as the first cautious production enrollment rather than a throwaway.

Virtualization has a hard ceiling too. macOS guests on Apple silicon are real and useful, but they are not ABM-known hardware, so ADE simply cannot target them. They also lack a Secure Enclave and the T2/secure-boot identity that several management behaviors depend on: Managed Device Attestation, hardware-bound keys, and some bootstrap-token and FileVault interactions need real metal to behave honestly. Apple's VM licensing also bounds how many guests you may run — the Apple silicon operations page covers the count. For everything below the enrollment layer — profile payloads, script logic, app installs, OS-release smoke tests — VMs are the faster, cheaper tool and you should reach for them first.

When you need local supervision without ADE — capturing a retail-bought Mac, or bench-provisioning a unit — Apple Configurator on a second Mac is the tool. Its companion flow can also add a retail Mac into ABM after the fact, which is how a lab unit bought off the shelf joins the org relationship at all.

What to rehearse here

The lab's job is to turn every production surprise into recognition. Drive these until they bore you:

Insights

• Split the work by altitude: iterate in VMs, validate on metal. Almost everything you change day to day is a payload or a script, and those belong in a snapshot-revert VM. The bench Mac is reserved for the few flows — enrollment, attestation, escrow — that only real hardware can prove.
• When enrollment or a profile misbehaves in the lab, the Mac enrollment and profile issues page is the first stop — and the lab is exactly where you should learn to read those failures, where the stakes are zero.
• The lab that never gets built is the one specced as a rack. One erasable Mac, a hypervisor you already own, and a free tenant is a complete macOS lab — and it changes how calm you are at 9 a.m. on a FileVault lockout.

Official Microsoft docs: Deployment guide: Enroll macOS devices in Microsoft Intune

A baseline is a reviewed set of security and configuration decisions that gets a new tenant from blank to defensible without re-deriving every setting yourself. It is a starting point, not a final state — you adopt it, then adapt it. Every platform on this site has a baseline; pick your platform above and this page points you at the right one, plus the adoption discipline that applies everywhere.

Adopting Any Baseline, Step by Step

1. Review before assigning. Every baseline encodes opinions. Inventory the settings that change user-visible behavior and flag anything your org cannot accept. The review takes about an hour and prevents a wave of support tickets.
2. Deploy to a pilot ring first. A baseline meets your hardware, apps, and users for the first time in the pilot — surface conflicts there, not across the whole company.
3. Track your deviations; don't fork. Keep a short document recording where you depart from the published baseline. When the upstream baseline updates, you re-apply your known deltas instead of re-evaluating every setting from scratch.
4. Re-review on a cadence. Baselines age as the OS and threat landscape change. Schedule a quarterly review and treat baseline version bumps like any other ringed rollout.

Insights

• A baseline's real value is a documented, defensible default. When a security review asks why a setting is configured the way it is, "we reviewed the published baseline and recorded our deviation" is an answer; "that's how it was when I got here" is not.
• Keep the baseline separate from the hardening roadmap. The baseline is what every device gets today; the roadmap is a separate, ringed project of future tightening. Combining them stalls both.

Official Microsoft docs: Security baselines in Microsoft Intune

A curated list — quality over completeness. Everything here has taught us something we used in production.

Communities

• Microsoft Intune Tech Community — official forum with product-team participation, all platforms.
• r/Intune — day-to-day questions, war stories, and the occasional gold-mine thread.
• Mac Admins Slack — Apple-centric by name, but #microsoft-intune is one of the most active Intune channels anywhere and platform-agnostic in practice. Join here.
• The Apple admins community Slack — its #microsoft-intune channel is one of the most active Intune channels anywhere, with deep Apple device management expertise on tap. Join here.
• The #microsoft-intune community Slack — a long-running admin community workspace whose Intune channel is one of the most active anywhere and platform-agnostic in practice. Join here.
• Android Enterprise Help Community — Google's official AE forum; the place where mode and provisioning edge cases get answered.

Blogs Worth Your RSS Reader

• bayton.org (Jason Bayton) — the community Android Enterprise resource: mode deep-dives, zero-touch guides, and honest platform commentary. Required reading alongside the Android sections of this site.
• call4cloud (Rudy Ooms) — the deepest Intune-internals writing anywhere; the investigative method transfers to every platform.
• scloud.work (Florian Salzmann) — practical Intune guides and ready-to-use templates.
• MSEndpointMgr — long-running multi-author endpoint management resource.
• andrewstaylor.com (Andrew Taylor) — Intune automation and Graph scripting at volume.
• Ugur Koc's blog — Intune automation and community tooling, including IntuneAssignmentChecker.
• oofhours.com (Michael Niehaus) — Autopilot and Windows deployment lore from the person who built much of it; the Windows section's recommended deep-reading.
• SkipToTheEndpoint — Windows endpoint engineering and the OpenIntuneBaseline project.
• Der Flounder (Rich Trouton) — two decades of MacOS administration depth; required reading for anyone running Macs in production.

Watch and Listen

• Intune.Training — the long-running community YouTube series; excellent onboarding material for the Learning Path.
• Mac Admins Podcast — Apple platform management weekly; the MDM-protocol episodes are required listening for anyone running Apple devices under MDM.
• The Apple admins community podcast — Apple platform management weekly; the MDM-protocol episodes apply squarely to iOS.
• WWDC "What's new in managing Apple devices" — Apple's annual June session; the changelog for your Apple year.
• Android Enterprise Summit sessions and Google's enterprise release notes — the changelog for your Android management year.

Official Documentation

• Microsoft Intune enrollment deployment guide for iOS/iPadOS
• Microsoft Intune enrollment deployment guide for Android
• Microsoft Intune enrollment deployment guide for Windows
• Microsoft Intune enrollment deployment guide for MacOS
• Apple Platform Deployment and Apple Platform Security
• Apple Business Manager User Guide
• Android Enterprise and the zero-touch documentation
• What's new in Microsoft Intune and the In development page

Events

• Mac Admins Conference (Penn State) — the Apple-management community's annual gathering; Intune content grows every year.
• The Apple admins conference at Penn State — the Apple-management community's annual gathering; Intune content grows every year.
• MMS (Midwest Management Summit) — deep Microsoft endpoint management, small-room format, heavy Intune track year after year.
• WWDC (online, free) — where the Apple management features covered on this site are first announced.
• Google I/O (online, free) — where the Android management features covered on this site are first announced.
• Microsoft Ignite (sessions stream free) — where the headline Intune and Windows-management announcements land each year.

Tools built by the community (and a few by vendors, free) that make device management with Intune meaningfully better. Found something that belongs here? Contribute it.

Graph, Automation, and Config-as-Code

• Graph Explorer (Microsoft) — run any Graph call against your tenant interactively. Prototype here, script after.
• Graph X-Ray — browser extension that reveals the exact Graph calls the Intune portal makes as you click. The fastest way to discover an undocumented endpoint or payload shape — indispensable for everything in our automation section.
• IntuneAssignmentChecker (Ugur Koc) — answers "what is actually assigned to this user/device/group" across policies and apps, every platform. The assignment-audit tool the portal should have shipped with.
• IntuneCD (Tobias Almén) — configuration-as-code: backs up, documents, and diffs your entire Intune configuration (every platform, the lot) into a Git repo. Change tracking, drift detection, tenant-to-tenant promotion.
• IntuneDeviceDetailsGUI (Petri Paavola) — a PowerShell GUI showing everything about one device — assignments, group memberships, applied policies — in a single pane.

Reference and Discovery

• Apple Device Management documentation — the raw spec behind every Settings Catalog key.
• Apple Device Management documentation — the raw spec behind every Settings Catalog key.
• Android Management documentation + Android Enterprise Recommended — Google's policy spec and the certified-hardware directory worth checking before every purchase.
• Configuration service provider (CSP) reference — the raw spec behind every Settings Catalog setting.
• Apple Business Manager API — Apple's OAuth-based API for reading org device data straight from ABM; pair with Graph for serial reconciliation.

Scripts on This Site

All plain PowerShell against Graph REST — no module dependencies, Azure Automation-ready:

• iOS Inventory
• Android Inventory
• Windows Inventory
• Stale Device Cleanup
• Bulk Actions
• VPP Licenses
• Apple Connector Health
• Bulk Rename
• App Install Status

Common questions every admin runs into. The first three apply to every tenant; the rest are specific to the platform you have selected.

What licenses do my users need?

Microsoft Intune Plan 1 (included in Microsoft 365 E3/E5, Business Premium, EMS E3/E5, and others) covers everything on this site unless a page notes otherwise.

Why is a brand-new device "not compliant" right after enrolling?

Compliance needs a first full check‑in plus Entra device registration to complete — usually a few minutes. If it persists past ~15 minutes, open the device's compliance blade and check which specific setting is failing. The blanket "not compliant" state is a symptom; the per-setting view is the diagnosis.

What's the difference between Retire, Wipe, and Delete?

• Retire removes company data, apps, and management while leaving personal data intact — the action for a personal device leaving management.
• Wipe is a full factory reset — the action for corporate hardware being decommissioned or redeployed.
• Delete removes only the Intune record without touching the device — a last resort for dead or unreachable hardware, never the first move.

Each platform has nuances on what these actions reach; the platform's enrollment pages carry the details.

Official Microsoft docs: What is Microsoft Intune?

This page is the checklist to complete before tenant setup. Four items apply to every tenant; the rest depend on the platform you manage.

Universal Prerequisites

• Licensing. Confirm your plan includes Intune (Intune Plan 1 standalone, EMS E3/E5, or a Microsoft 365 bundle — verify against the licenses doc) and assign the license to your pilot users in Microsoft 365 admin center > Users. A purchased-but-unassigned license blocks enrollment.
• Identity. Entra ID must be healthy — cloud-only, or with Entra Connect sync fully configured. A partially-configured hybrid identity (sync errors, unverified UPN suffixes) is the most common cause of day-one enrollment failures.
• Admin access. Assign the built-in Intune Administrator role for routine work. Keep Global Administrator for break-glass only and document the break-glass accounts — see RBAC and Scope Tags.
• Browser and tenant. Use a current browser signed into the correct tenant. Confirm the tenant in the account switcher before configuring anything; an admin signed into the wrong tenant is a recurring source of lost time.

Platform-Specific Prerequisites

Readiness Check

Before proceeding to tenant setup, confirm:

• Licenses assigned to pilot users (not just purchased).
• Identity signs in cleanly with no sync errors.
• Admin roles issued and break-glass accounts documented.
• Platform accounts created with renewal dates on a shared calendar.

Insights

• Treat every credential created on this page as organizational infrastructure: shared-mailbox-backed, documented, and renewal-calendared. The two failures this prevents — an APNs certificate tied to a departed employee's Apple ID, and a Managed Google Play binding on a personal account — both require disruptive re-enrollment to recover from.

Official Microsoft docs: Microsoft Intune licenses

A fresh tenant becomes enrollment-ready in an afternoon if the steps run in order. The universal spine first: confirm the MDM authority is Intune (modern tenants default correctly), set auto-enrollment scope (Entra > Mobility > Microsoft Intune — MDM user scope to your pilot group), build the starter group structure (dynamic groups and filters — an all-pilot-users group and per-platform device filters carry you surprisingly far), apply company branding (logo and support contact — it appears in every enrollment flow and Company Portal, so first impressions are configured here), and set enrollment restrictions deliberately rather than inheriting defaults — personal-device posture per platform is a policy decision, not an accident.

Then the platform connectors, in the order that avoids rework:

Prove It

The setup isn't done when the consoles are green — it's done when one device per platform has enrolled, received a profile, installed an app, and reported compliant. That four-line verification is the afternoon's real deliverable, and the device that did it becomes ring 1's founding member.

Insights

• Resist configuring everything on day one: the tenant needs exactly enough to enroll and prove the pipeline. Every policy added before the first successful enrollment is a variable you'll have to rule out when something fails — the build-up discipline starts here.

Official Microsoft docs: What is Microsoft Intune?

Endpoint management is a series of either/or decisions made under pressure: which enrollment method, which config surface, which app type, MDM or MAM. Pick wrong early and you rebuild later. These tools encode the decisions experienced engineers actually make, so you start from a defensible default and adapt — not from a blank tenant.

Decision Wizards

Branching questionnaires that take your situation — platform, ownership, use case — and land on a single recommendation with links to execute it.

Head-to-Head Comparisons

The canonical either/or calls, laid out with criteria, trade-offs, and a clear "choose this when."

Deployment Blueprints

End-to-end starter recipes for a scenario — every component in order, each linked to the guide that builds it. Adopt the whole stack or cherry-pick.

Why enrollment is the decision that sticks

Every later choice — which restrictions apply, whether you can wipe selectively, how much the device trusts you — is bounded by how it enrolled. A BYOD phone enrolled with App Protection can never be force-restricted like a supervised corporate device, and a retail Mac outside ABM can never be made truly zero-touch after the fact without a wipe. Get this right first; the rest of the stack builds on it.

MDM (Mobile Device Management) enrolls and manages the entire device — restrictions, configuration, compliance, the works. MAM (Mobile Application Management), delivered through App Protection Policies, protects company data inside managed apps without enrolling or controlling the device. The split usually falls on ownership: you manage what you own, you protect data on what you don't.

The pragmatic answer for most fleets is both: MDM for corporate-owned devices, MAM for BYOD — and on enrolled corporate devices you can layer App Protection on top for defense in depth. Not sure which a given device needs? Run the enrollment wizard.

Want to practice this end-to-end with zero risk? Build the whole stack in the Intune Simulator first.

Why the type matters more than the app

Two engineers can "deploy Chrome" and end up with completely different reliability because one chose a Win32 wrapper with solid detection and the other fought the store catalog. The app type decides how installs are detected, whether updates are automatic or manual, whether licensing flows through VPP, and what config you can layer on. Match the type to the package — installer complexity, source, and licensing — and most of the pain disappears before you assign anything. When you genuinely can't make a simpler type work on Windows, Win32 is the capable fallback that can model almost anything.

The order of preference, and why

There's a deliberate hierarchy here. Settings Catalog first — it's the modern, flat, searchable surface and Microsoft is steadily moving everything into it. Reach for a Template profile when the thing you're configuring is a whole scenario (VPN, Wi-Fi, certificates, email, kiosk, endpoint protection) that wires up interdependent values you shouldn't hand-assemble. Use Administrative Templates / imported ADMX for classic Group Policy settings that haven't made it into the catalog yet. And treat Custom (OMA-URI / .mobileconfig) as the genuine last resort — only when the setting exists in no friendlier surface at all.

The one rule that survives every surface: one home per setting. A given setting should be authored in exactly one profile. The fastest way to a "why won't this apply?" ticket is configuring the same value in a Catalog profile and a template (or a custom OMA-URI) at once — Intune reports a conflict and neither side wins cleanly. Pick the right surface, put the setting there, and don't set it anywhere else.

The Settings Catalog is a flat, searchable list of CSP-backed settings — you pick exactly what you want, named the way the CSP names it, and nothing else comes along. Classic Template profiles (Device restrictions, Endpoint protection, and the rest) are curated, grouped bundles Microsoft hand-built before the catalog existed. The catalog is where Microsoft is investing and where new work should start; templates linger because some scenarios — VPN, Wi-Fi, certificates, email — still only ship as a template. Most of this lives behind the Settings Catalog & CSPs surface.

The pragmatic rule: catalog-first, templates where you have no choice. Build all new baseline configuration in the Settings Catalog, and reach for a template only when the scenario — a VPN, a Wi-Fi network, a SCEP/PKCS certificate — simply isn't available anywhere else. Don't migrate working template profiles for the sake of it; do stop creating new ones. When in doubt, search the catalog first — if the setting is there, that's its home.

Personally-owned work profile is the BYOD container: Android carves a managed work area onto a user's personal phone, and IT manages only what's inside it. Fully managed (corporate-owned, COBO) takes the whole device — every app, every restriction, no personal side at all. The decision is almost always about who owns the hardware. Start from choosing a management mode if you're not sure which scenarios you're even solving for.

The pragmatic answer maps to ownership: protect what you don't own, control what you do. Work profile for BYOD, fully managed for issued corporate devices. There's also a middle ground — corporate-owned work profile (COPE) — a corporate device that still carves out a private work profile, giving the user a personal side on hardware the org owns. And on personal devices where even a work profile is too much, you can drop to App Protection Policies (MAM) and protect data inside the apps without enrolling the device at all.

Want to practice this end-to-end with zero risk? Build the whole stack in the Intune Simulator first.

Want to practice this end-to-end with zero risk? Build the whole stack in the Intune Simulator first.

Want to practice this end-to-end with zero risk? Build the whole stack in the Intune Simulator first.

The Baseline Settings are a curated, community-reviewed starting point for managing corporate iOS devices — sane security defaults that won't fight your users. They cover restrictions, passcode, software updates, Enterprise SSO, Microsoft app configuration, and an App Protection baseline.

Prerequisites

• A local copy of the baseline repository. Clone or download it from the GitHub repository so you can review every policy before anything touches your tenant.
• Rights to create policies in your tenant — Settings Catalog configuration, compliance, and App Protection. If you use the import script, you also need consent to call Microsoft Graph with device-management write permissions.
• A pilot group. An Entra ID group of test devices and users, so imported policies are never assigned straight to the fleet.

Option 1 — Import the JSON (Recommended)

Each policy in the baseline repository ships as exported JSON you can import with a short Graph script:

1. Get the policy files locally. Clone or download the baseline folder from the repository so you import from a version you've pinned, not a moving branch.
2. Review every JSON file. Never import a policy you haven't read. You are accountable for every value that lands in your tenant — and reading the export is also the fastest tour of what the baseline actually changes.
3. Run the import script in the repo (plain PowerShell + Graph REST, same style as our Graph Quickstart) to POST each policy to its endpoint:
   • Settings Catalog policies → deviceManagement/configurationPolicies
   • Compliance policy → deviceManagement/deviceCompliancePolicies
   • App Protection → deviceAppManagement/iosManagedAppProtections
4. Assign to your pilot group. Policies land unassigned by design — nothing applies anywhere until you assign it. Scope every imported policy to the pilot group first and widen only after the pilot stays quiet.

Option 2 — Build by Hand

Every settings page in this section lists the exact Settings Catalog paths and values. Twenty minutes of clicking gets you the same result, and you'll know exactly what each setting does — familiarity that pays for itself the first time a setting needs troubleshooting.

Rollout Order

1. Enterprise SSO Plug-in (improves everything else)
2. Passcode + Compliance
3. Restrictions
4. Software Updates (deferral first, enforcement after a cycle)
5. App Protection (BYOD ring)

Pilot → Ring 1 → fleet. Watch helpdesk volume between rings.

Verification

• Every imported policy is visible in the console with its expected iOS-BL- prefixed name, and its Assignments tab lists only the pilot group.
• On a pilot device, the profiles arrive (Settings > General > VPN & Device Management) and each policy's per-device status reports Succeeded.
• Helpdesk stays quiet through the pilot window — that silence is your signal to widen the rings.

Official Microsoft docs: Settings Catalog

The baseline is only as good as the operational experience behind it. If a setting bit you in production, or a new iOS release added something the baseline should adopt, contribute.

What a Baseline Contribution Looks Like

1. The change: exported policy JSON (or the exact Settings Catalog path + value for hand-built review).
2. The rationale: what it does, why the chosen value, what breaks without it.
3. The blast radius: supervision requirements, minimum iOS version, user-visible impact, known conflicts.

Process

1. Open a pull request against the baseline/ folder in the repository, or open an issue if you'd rather discuss the idea first — both are welcome starting points.
2. A maintainer reproduces the setting in a test tenant. Nothing merges on trust alone; reproduction catches typos in paths and values before they reach anyone's production fleet.
3. Discussion happens on the PR. Controversial defaults get a documented "Decision" note on the settings page, so future readers see why a value won — not just what it is.
4. Merged changes appear in the Changelog, so adopters can diff exactly what moved between baseline versions.

Principles We Hold

• Secure by default, usable by default. A baseline nobody deploys protects nobody.
• Every setting earns its place. No cargo-culted CIS line items without operational justification.
• Version-aware. Settings note the iOS version they appeared in and whether supervision is required.

Official Microsoft docs: Settings Catalog

The complete baseline at a glance. Each area links to its detail page with exact paths, values, and rationale.

Design Notes

• Everything possible is Settings Catalog, not legacy templates — Microsoft's investment is there, and DDM delivery happens automatically where supported.
• The baseline is split into multiple small policies rather than one mega-profile, so you can adopt incrementally and troubleshoot conflicts sanely.
• Naming convention used in the JSON: iOS-BL-<Area>-v<version>, e.g. iOS-BL-Restrictions-v1.

What the Baseline Deliberately Doesn't Do

• No Wi-Fi/VPN/certificate payloads — too environment-specific.
• No Home Screen Layout — cosmetic, org-specific.
• No app deployment — see the Complete Guide for the core app set.

Official Microsoft docs: Settings Catalog

Settings Catalog > Restrictions category. Baseline policy: iOS-BL-Restrictions-v1. Target: supervised corporate devices.

Security Restrictions

Data Hygiene

Deliberately Allowed

• App Store stays enabled (personal-enabled corporate devices) — VPP keeps managed apps managed regardless. Lock this down only for kiosk fleets.
• Camera allowed — blocking it breaks Teams/document scanning; restrict per-site with a separate policy if a facility requires it.
• Screenshots allowed on devices; the App Protection baseline governs data in MAM contexts.

Official Microsoft docs: Settings Catalog

Settings Catalog > Passcode category. Baseline policy: iOS-BL-Passcode-v1. Works on all enrollment types.

Baseline Values

Face ID / Touch ID remain enabled — biometrics on top of a 6-digit PIN is the usability win that makes the rest of this policy acceptable.

Lock Screen Exposure

In the Restrictions category (kept in this policy for cohesion):

Mirror the passcode requirements in your compliance policy — configuration sets the rule, compliance enforces the consequence.

Official Microsoft docs: Settings Catalog

Two policies working together. Full background: Managed Software Updates.

Policy 1 — Deferral: iOS-BL-Updates-Defer-v1

Settings Catalog > Restrictions:

Users can't install a brand-new iOS release for 14 days — your validation window. Adjust to 30 if your app estate is fragile after major releases.

Policy 2 — Enforcement: iOS-BL-Updates-Enforce-Ring{N}

Settings Catalog > Declarative Device Management > Software Update, one profile per ring:

Set Target OS Version to the exact version string and Target Date Time in UTC. The device handles download scheduling, escalating user notifications, and forced installation at deadline.

Operating Rhythm

1. Validate the release. Apple ships an update → install it on Ring 0 devices inside their window and confirm your critical apps and profiles still behave.
2. Move the deadlines forward. Update the Target OS Version and Target Date Time in each ring profile (or script it via Graph — the profiles are Settings Catalog policies, editable at deviceManagement/configurationPolicies).
3. Let compliance sweep the stragglers. Keep the compliance policy minimum OS one version behind enforcement, so devices lose access only after every ring's deadline passes — pressure without surprise lockouts.

Official Microsoft docs: Settings Catalog

Baseline policy: iOS-BL-SSO-v1. The full walkthrough with verification steps lives in the Complete Guide; this page is the reference card.

Settings Catalog > Authentication > Extensible Single Sign On (SSO)

Extension Data

Dependencies

• Microsoft Authenticator deployed (required VPP app) — the extension lives inside it.
• Assign to device groups for corporate, and include in BYOD user-enrollment targeting too: SSO is equally valuable on the work partition.

Don't

• Don't add wildcard URL entries or third-party IdP URLs to this payload "while you're in there" — scope creep here causes the weirdest auth loops you'll ever troubleshoot.

Official Microsoft docs: Settings Catalog

App Configuration Policies (managed devices channel) that pre-configure Microsoft apps so they're signed-in-ready on first launch. Background: App Configuration Policies.

Outlook — iOS-BL-AppConfig-Outlook-v1

Edge — iOS-BL-AppConfig-Edge-v1

All MSAL Apps

Intune offers the toggle to add the shared device/account mode and SSO-relevant keys automatically when you create app config policies for Microsoft apps — let it. Combined with the Enterprise SSO plug-in, first-launch sign-in is typically zero-prompt.

Official Microsoft docs: Settings Catalog

App Protection Policies (APP/MAM) wrap corporate data inside managed apps — they work on enrolled devices and on completely unmanaged BYOD alike. This baseline (iOS-BL-APP-v1) is Microsoft's "Level 2 — Enhanced" data protection framework with field-tested adjustments.

Apps > Protection policies > Create policy > iOS/iPadOS. Target: all Microsoft 365 apps + your LOB apps using the Intune App SDK. Assign to user groups (it follows the user, not the device).

Data Protection

Access Requirements

Conditional Launch

Pair with Conditional Access

Create a CA policy with grant control Require app protection policy for iOS, so unprotected apps can't touch corporate data even with valid credentials. Details: Conditional Access.

Official Microsoft docs: Settings Catalog

Apple Business Manager (ABM) is Apple's free web portal for organizations. It is the foundation of every corporate iOS deployment — it provides device enrollment automation, app licensing, and Managed Apple Accounts.

What ABM Gives You

• Devices: assign corporate devices to Intune for Automated Device Enrollment — zero-touch, supervised, mandatory management.
• Apps & Books: buy app licenses (free apps too) in volume and deploy them silently — no Apple ID needed on devices. See Apps & Books (VPP).
• Managed Apple Accounts: organization-owned Apple Accounts, ideally federated with Entra ID, required for Shared iPad and account-driven enrollment.

Device Identity in Entra ID

However an iOS device enrolls, it becomes Entra registered — the device record Conditional Access reads. The enrollment path decides how corporate that record is; the device identity guide has the full picture:

Prerequisites

• A D-U-N-S number registered to your legal entity. Apple validates your application against the Dun & Bradstreet record, so confirm the registered legal name and address are current before you apply.
• A work email address on a domain your organization owns — consumer mailbox addresses are not accepted for the enrolling account.
• A verification contact who can legally accept the terms on behalf of your organization. Apple calls this person to verify, so brief them that the call is coming.

Enrolling Your Organization — Step-by-Step

1. Start the application. Go to business.apple.com and select Sign up now, entering the legal-entity details exactly as they appear in your D-U-N-S registration.
2. Complete verification. Apple phones the verification contact to confirm the request is genuine before approving the organization.
3. Allow a few business days for approval. If your D-U-N-S details don't match your legal name exactly, fix them with Dun & Bradstreet first; mismatches are the most common rejection reason.

After Approval

1. Add at least one additional Administrator account — never run ABM with a single admin; one departed colleague or forgotten password shouldn't lock the organization out of its own device program.
2. Note your Organization ID (Settings > Enrollment Information); resellers need it to auto-assign purchased devices.
3. Configure federated authentication if you'll use Managed Apple Accounts. Under Settings > Accounts, federate with Microsoft Entra ID so users sign in with their work credentials.

Next: Integrate Apple Business Manager with Intune

Official Microsoft docs: iOS/iPadOS enrollment guide

The integration between ABM and Intune is a server token (.p7m file). One token per ABM "MDM server" entry; the token tells Apple to hand devices to your Intune tenant at activation. The exchange is a three-part handshake: Intune generates a public key, ABM binds that key into a server token, and Intune consumes the token.

Prerequisites

• An ABM account that can manage MDM server assignments (Administrator or Device Enrollment Manager role).
• Access to the Intune admin center with permission to manage Apple enrollment.
• A decision about which ABM account owns the token — renewals must come from the same account every year, so use a role account your team controls rather than a personal login.

Step 1 — Download the Intune Public Key

1. Open the token wizard. In the Intune admin center: Devices > Enrollment > Apple tab > Enrollment program tokens > Add.
2. Grant consent and download the key. Grant Apple permission to send user/device info, then Download your public key (.pem). ABM will bind your server token to this key.

Step 2 — Create the MDM Server in ABM

1. Add a server entry. In ABM: Settings (or Preferences) > MDM Server Assignment > Add.
2. Name it clearly, e.g. Intune - Production — this name shows up in assignment menus for years, so make it self-explanatory.
3. Upload the .pem public key from Step 1.
4. Download the generated server token (.p7m).

Step 3 — Upload the Token to Intune

1. Enter the owning Apple ID. Back in the Intune wizard, enter the Apple ID of the ABM account used to create the token (record this — renewals must use the same account).
2. Upload the .p7m file and create. Intune validates the token and the connection goes live.

Step 4 — Verify

The token appears under Enrollment program tokens with a green status and an expiration date one year out. Set a renewal reminder at 11 months. Devices assigned to this MDM server in ABM will sync into Intune (manual sync available; Apple rate-limits a full sync to once per 15 minutes).

Next: Add a Device to Apple Business Manager

Official Microsoft docs: iOS/iPadOS enrollment guide

A device must exist in ABM before it can use Automated Device Enrollment. There are three ways in, and the right one depends on how the device was purchased.

1. Purchased Through Apple or an Authorized Reseller (Best)

Give Apple or your reseller your Organization ID (and add their Reseller Number under ABM Settings > Enrollment Information). New purchases then appear in ABM automatically — true zero-touch. This should be your default procurement path for every corporate device going forward.

2. Apple Configurator for iPhone (iOS 16+)

For devices bought retail or otherwise outside the reseller channel:

1. Install Apple Configurator from the App Store on a work iPhone and sign in with an ABM administrator/device-manager account.
2. Factory-reset the target device. At the Setup Assistant Hello screen, bring it near the Configurator iPhone (like AirPods pairing) and scan the on-screen image.
3. Confirm the add. The device is added to ABM and appears in your MDM server assignment within minutes.

No cables and no bench hardware required. This is the field-friendly method.

3. Apple Configurator 2 over USB

The classic tethered method for benches doing batch intake: connect the freshly-wiped device by USB to a bench computer running Apple Configurator 2, select Prepare, and choose Add to Apple Business Manager. Slower per device than the iPhone method, but it suits an intake bench where devices are already lined up in trays.

Assign to Your MDM Server

1. Assign the serials. In ABM: Devices > select device(s) > Edit MDM Server > choose your Intune server.
2. Set a default MDM server per device type (Settings > MDM Server Assignment) so new purchases auto-assign without manual work.
3. Sync the token in Intune. The serials appear under your enrollment program token after the next sync.

Verification

The device shows in ABM under Devices with your Intune server listed as its MDM server, and the same serial appears in Intune under the enrollment program token's device list. If a serial seems "missing" in Intune right after assignment, trigger a token sync and allow a few minutes — Apple rate-limits a full sync to once per 15 minutes.

Next: Apple MDM Push Certificate

Official Microsoft docs: iOS/iPadOS enrollment guide

Every command Intune sends to any Apple device — policy, app install, wipe — is triggered through the Apple Push Notification service (APNs) using one certificate. It's free, takes five minutes, and is the single most important object in your Apple deployment.

Prerequisites

• A dedicated organizational Apple ID (e.g. apple-mdm@yourdomain.com) with two-factor authentication configured — never a personal account. This identity anchors the certificate for the life of your deployment.
• Intune admin center access with rights to manage Apple enrollment settings.

Create It — Step-by-Step

1. Open the certificate blade. Intune admin center: Devices > Enrollment > Apple tab > Apple MDM Push certificate.
2. Download the CSR. Check I agree, then Download your CSR (a .csr file signed by Microsoft).
3. Open the Apple portal. Select Create your MDM push Certificate — this opens the Apple Push Certificates Portal.
4. Sign in with the dedicated organizational Apple ID (e.g. apple-mdm@yourdomain.com — never a personal account).
5. Create the certificate. Select Create a Certificate, accept the terms, upload the CSR, then download the resulting .pem.
6. Finish in Intune. Enter the Apple ID you used (this is recorded for renewal), upload the .pem, and finish.

Verification

Status turns Active with a one-year expiration. To prove the push channel end to end, sync or remote-lock a test device and confirm the command lands — command delivery is the certificate doing its job.

Renewal — Read This Twice

• Renew the same certificate in the Apple portal using the same Apple ID every year.
• If the certificate expires, every Apple device stops receiving commands until you renew it — devices stay enrolled and recover once renewed.
• If you create a new certificate instead of renewing (or use a different Apple ID), the certificate topic changes and every Apple device must be re-enrolled. This is the classic career-limiting Apple MDM mistake.

Next: Create an ADE Enrollment Profile

Official Microsoft docs: Get an APNs certificate

The enrollment profile defines what happens when an ABM-assigned device activates: supervision, user affinity, authentication method, and which Setup Assistant screens users see. Every device that activates against the profile inherits these decisions until its next wipe, so this is where the corporate device experience is really designed.

Prerequisites

• Your APNs certificate is active and your enrollment program token is connected, with device serials syncing from ABM.
• You know which devices are 1:1 user devices and which are shared or kiosk hardware — the user-affinity decision below follows directly from that split.

Create the Profile — Step-by-Step

1. Open the profile wizard. Devices > Enrollment > Apple tab > Enrollment program tokens > your token > Profiles > Create profile > iOS/iPadOS.
2. Work through the key decisions in the table below. Each row is a choice the device keeps until it is wiped, so decide deliberately rather than accepting defaults.
3. Trim Setup Assistant and create the profile. Skip the screens users don't need (guidance below), review, and save.

Key Decisions

Setup Assistant Screen Skipping

Skip everything users don't need to touch: Apple Intelligence/Siri, Apple Pay, Screen Time, Restore, etc. Leave Passcode visible — you want a passcode set during setup, and your compliance policy will require it anyway.

Assign Devices to the Profile

1. Assign serials. In the token blade: Devices > select serials > Assign profile.
2. Set the token's default profile. Make this profile the token's default profile so newly synced devices pick it up automatically — an unassigned serial is how a corporate device ends up activating with no management.

Verification

• The token's device list shows your profile name against each assigned serial.
• Wipe and activate a test device: the Remote Management screen appears during Setup Assistant, followed by your chosen authentication flow.

Profile changes apply at next activation — already-deployed devices must be wiped to receive an updated enrollment profile.

Next: Deploy the Enterprise SSO Plug-in

Official Microsoft docs: ADE enrollment for iOS/iPadOS

The Microsoft Enterprise SSO plug-in gives iOS devices true single sign-on to Entra ID: a user authenticates once and every app and website that uses Entra ID picks up the session — including Safari. It also enables just-in-time (JIT) device registration during web-based and Setup Assistant enrollments.

Prerequisites

• Microsoft Authenticator deployed to the device (the plug-in ships inside it). Deploy it as a required VPP app. Users do not need to open or configure Authenticator for SSO to work.
• Device must be MDM-enrolled (the extension only activates when delivered by MDM).

Configure via Settings Catalog

Devices > iOS/iPadOS > Configuration > Create > Settings catalog:

1. Add the payload. Add settings from category Authentication > Extensible Single Sign On (SSO).
2. Configure the extension:
   • Extension Identifier: com.microsoft.azureauthenticator.ssoextension
   • Team Identifier: UBF8T346G9
   • Type: Redirect
   • URLs:
     • https://login.microsoftonline.com
     • https://login.microsoft.com
     • https://sts.windows.net
3. Assign the profile to your iOS device groups.

Recommended Extension Data (key/value)

Verify

After the profile lands (Settings > General > VPN & Device Management shows the SSO payload), sign into one Microsoft app, then open Safari to https://office.com — you should land signed-in without a password prompt.

Next: App Deployment with Apps & Books (VPP)

Official Microsoft docs: iOS/iPadOS enrollment guide

Apps & Books (still universally called VPP) is how corporate iOS app deployment works: your organization acquires licenses in ABM, Intune consumes them through a location token, and supervised devices install apps silently with no Apple ID signed in.

Step 1 — Acquire Licenses in ABM

1. Open the store. In ABM: Apps and Books.
2. Find the app. Search for the app (e.g., Microsoft Authenticator, Outlook, Edge, Company Portal).
3. Acquire licenses. Choose a quantity (free apps still need "purchased" license counts — grab plenty, e.g. 5,000 for core apps) and assign to your Location.

Step 2 — Connect the Location Token to Intune

1. Download the token from ABM. Your account > Preferences > Payments and Billing > Content Tokens — download the .vpptoken for your location.
2. Open the connector blade in Intune. Tenant administration > Connectors and tokens > Apple VPP tokens > Create.
3. Upload and configure. Upload the token, enter the Apple ID that manages it, set Automatic app updates to Yes, and decide if this token grants used licenses to Intune-managed devices only.

Tokens expire annually — same renewal discipline as your APNs certificate.

Step 3 — Deploy Apps

Licensed apps appear automatically under Apps > All apps (type: iOS volume purchase program app) after the token syncs.

1. Open the assignment. Select the app > Properties > Assignments.
2. Pick the intent. Required for must-have apps (silent install on supervised devices), Available for enrolled devices for the self-service catalog in Company Portal.
3. Keep device licensing. License type: Device licensing (default and recommended) — no Apple ID involvement at all.

Core App Set for the Complete Guide

Deploy these as Required / Device licensed to your corporate iOS group:

• Microsoft Authenticator (enables the Enterprise SSO plug-in)
• Intune Company Portal (Entra registration + self-service)
• Microsoft Outlook, Edge, Teams — per your workload
• Microsoft Defender (next page)

Next: User Experience on an iOS Device

Official Microsoft docs: Apple VPP apps

This is the end-to-end experience on a corporate device deployed through everything configured so far. Knowing it cold makes support tickets self-explanatory.

Unboxing to Desk-Ready

1. Hello screen — user powers on, selects language/region, joins Wi-Fi (or uses cellular activation).
2. Remote Management screen — "Your organization will automatically configure your device." This appears because the serial is ABM-assigned to your Intune token. With locked enrollment, there is no skip option.
3. Entra ID sign-in — with Setup Assistant modern authentication, the user signs in with their work account; Conditional Access and MFA apply right here.
4. Passcode — user sets a passcode (your compliance and passcode policies enforce minimums).
5. Await Final Configuration — the device holds at "Configuring..." while required profiles and VPP apps land, so the home screen appears fully provisioned.
6. Home screen — Outlook, Teams, Authenticator, Company Portal already installed. If you deployed a Home Screen Layout, icons are arranged your way.
7. First app launch — thanks to the Enterprise SSO plug-in, apps pick up the Entra session without re-prompting for the password.

Typical elapsed time on decent Wi-Fi: 8–15 minutes, most of it app downloads.

What Users Notice Day-to-Day

• Settings > General > VPN & Device Management shows the management profile; on supervised devices the top of Settings reads "This iPhone is supervised and managed by…".
• App Store can stay enabled or be hidden — managed apps update via VPP regardless.
• No Apple ID prompts for any managed app, ever.

What They Can't Do

• Remove the management profile (locked enrollment).
• Erase their way out — after a wipe, the Remote Management screen returns at activation (and Activation Lock doesn't strand you if managed properly).

Next: Enroll iOS in Microsoft Defender

Official Microsoft docs: iOS/iPadOS enrollment guide

Microsoft Defender for Endpoint on iOS provides web protection (anti-phishing via a local loopback VPN), jailbreak detection feeding device risk into compliance, and vulnerability assessment of OS versions.

Prerequisites

• Defender for Endpoint licensing (MDE P1/P2, Microsoft 365 E5, or standalone).
• The MDE–Intune connection enabled: Defender portal > Settings > Endpoints > Advanced features > Microsoft Intune connection On, and in Intune Endpoint security > Microsoft Defender for Endpoint > allow iOS to report to MDE.

Step 1 — Deploy the App

Deploy Microsoft Defender: Security as a Required, device-licensed VPP app to your corporate iOS group.

Step 2 — Silent Onboarding (Supervised)

On supervised devices Defender can onboard silently — no user tap-through:

1. Create an App configuration policy (Managed devices) targeting the Defender app.
2. Add the onboarding keys. Use the configuration designer and add:
   • issupervised = {{issupervised}} (variable)
   • For silent/zero-touch onboarding follow the current Microsoft Learn doc "Deploy Microsoft Defender for Endpoint on iOS" — Microsoft updates the exact key set periodically; pin your config to the doc, not to a blog post.
3. Deploy the Defender VPN payload. Push the Device control/Web protection VPN profile (Microsoft provides the VPN payload values in the same doc) so web protection activates without user consent.

Step 3 — Connect Risk to Compliance

In your iOS compliance policy, set Require the device to be at or under the machine risk score (e.g., Medium). Now a jailbroken or high-risk device automatically loses access through Conditional Access.

Verification

• The device appears in the Defender portal's device inventory shortly after onboarding completes.
• On the device, the Defender app reports web protection active and the loopback VPN shows under Settings > VPN.
• Risk flows into compliance: a test device's compliance state reflects the machine risk score requirement you configured.

Next: Declarative Device Management

Official Microsoft docs: Defender for Endpoint on iOS

Declarative Device Management is Apple's modern management protocol, layered on top of MDM. Instead of the server polling and pushing commands, the server sends declarations — desired states — and the device itself enforces them and proactively reports status changes.

Why It Matters

The flagship example: a software update declaration with a deadline. The device schedules downloads, notifies the user with escalating urgency, and force-installs at the deadline — even if it can't reach Intune at that moment.

Requirements

• iOS/iPadOS 17 or later for the update enforcement scenarios Intune exposes (DDM itself exists since iOS 15).
• No special enrollment — DDM activates automatically within an existing Intune MDM enrollment on supported OS versions.

Where Intune Uses DDM Today

• Managed software updates (the headline scenario — full guide).
• A growing set of Settings Catalog payloads are delivered declaratively when the device supports it — Intune chooses the channel; you don't have to.

Read the deep-dive: What is Declarative Device Management?

Next: Managed Software Updates

Official Microsoft docs: iOS/iPadOS enrollment guide

The final piece of the deployment: keeping the fleet current. On iOS 17+ this is done with DDM-based software update enforcement, which replaces the old MDM update commands with deadlines the device itself enforces.

Configure Enforcement

Devices > iOS/iPadOS > Configuration > Create > Settings catalog:

1. Pick the payload. Category Declarative Device Management > Software Update.
2. Set the target and deadline. Configure:
   • Target OS Version — e.g. 17.5.1 (exact version string)
   • Target Date Time — the enforcement deadline (UTC)
   • Optionally Target Build Version for precision
3. Assign to your iOS device groups (use a pilot ring first — see below).

Before the deadline, users get increasingly insistent notifications and can update on their own terms. At the deadline, the device downloads (if it hasn't) and installs the update, requiring the passcode where needed.

Verification

• On a targeted device, Settings > General > Software Update shows the targeted version, and the notification cadence begins as the deadline approaches.
• The policy's per-device status in Intune reports success, and after the deadline the device's inventoried OS version moves to the target.
• Stragglers surface in the compliance minimum-OS report — chase that report, not individual serial numbers.

Hide Updates Users Shouldn't See Yet

Pair enforcement with deferral so users can't jump ahead of your validation:

• Settings catalog > Restrictions: Defer software updates / Enforced Software Update Delay (1–90 days). Supervised only.

This creates the classic pattern: defer 14–30 days for validation, then enforce by deadline.

Recommended Ring Model

Drive ring assignment with Entra groups, one enforcement profile per ring with staggered Target Date Times.

🎉 That's the complete deployment guide. Continue with Compliance Policies and the Baseline Settings to harden the fleet.

Official Microsoft docs: Managed software updates (DDM)

Intune offers four practical ways to enroll an iOS device. Choosing correctly up front matters — moving a device between methods later means wiping it.

The Decision in One Table

Simple Rules

1. Corporate-owned? → ADE. Always. Supervision and locked enrollment are non-negotiable for company hardware. Get devices into ABM even if bought retail (here's how).
2. Corporate-owned but genuinely can't get it into ABM? → Web-based device enrollment. Accept that it's unsupervised and removable; plan to replace these devices through proper procurement.
3. BYOD with full corporate app access? → Account-driven User Enrollment. Cryptographic separation of work/personal data, privacy-respecting, user keeps control of the device.
4. BYOD where MAM is enough? → Don't enroll at all. App Protection Policies without enrollment protect corporate data inside Microsoft apps with zero device management. This is the right answer more often than people think.

Retired Methods

Profile-based User Enrollment (the old Company Portal BYOD flow) has been retired by Microsoft and Apple in favor of account-driven enrollment. If you still have devices on it, plan migrations — users sign out / retire, then re-enroll account-driven.

Official Microsoft docs: iOS/iPadOS enrollment guide

ADE (formerly DEP) is the gold standard for corporate iOS: the device enrolls itself during Setup Assistant because Apple's activation servers know the serial belongs to your organization.

What You Get

• Supervision — the prerequisite for the strongest controls: Lost Mode, Single App Mode, Home Screen Layout, blocking app removal, many restrictions, silent VPP app installs, and Activation Lock management.
• Locked enrollment — the management profile cannot be removed; a wipe just lands the device back at the Remote Management screen.
• A zero-touch rollout — ship sealed boxes; users self-provision in minutes.
• Await Final Configuration — devices arrive at the home screen fully provisioned.

Setup Chain

1. Enroll in Apple Business Manager
2. Connect ABM to Intune with a server token
3. Get devices into ABM and assign to the Intune MDM server
4. Create and assign an enrollment profile
5. Wipe/activate the device — it enrolls at Setup Assistant

Authentication Options in the Profile

Insights

• A device re-checks its ABM assignment at every activation. Reassigning a serial to a different enrollment profile only takes effect after a wipe.
• ABM token sync to Intune is rate-limited (full sync every 15 minutes) — "missing" serials right after assignment usually just need a sync and patience.
• Keep one default profile per token sane: it's what every newly purchased device gets if you forget to assign explicitly.

Official Microsoft docs: ADE enrollment for iOS/iPadOS

Web-based device enrollment lets a user enroll a device entirely through Safari — no Company Portal app required to enroll. It produces a standard (unsupervised) device enrollment and is Microsoft's default for new device enrollment profiles. Because the entire flow runs in the browser, it is the lowest-friction way to bring a corporate-owned device under management when it was procured outside the channels that feed automated enrollment.

Prerequisites

• iOS/iPadOS 15 or later on the devices being enrolled.
• Licensed users in an assignable group — the flow is user-driven, so the enrollment link and instructions you communicate are part of the deployment.
• The Enterprise SSO plug-in policy in place — just-in-time (JIT) registration during this flow depends on it. The plug-in deploys once the device is managed, and it is used at sign-in time to complete Entra device registration.

Step-by-Step: Create and Assign the Enrollment Profile

1. Open the enrollment configuration. Go to Devices > Enrollment > Apple tab > Enrollment types.
2. Create the profile. Choose Create profile, select Web based device enrollment as the enrollment type, and name it so the intended audience is obvious from the assignment view later.
3. Assign it to user groups. Enrollment type profiles target users, not devices. If several profiles could match the same user, the profile priority order decides which flow they get — review that order deliberately whenever you add a profile.

Step-by-Step: The User Flow

1. Open Safari and go to https://portal.manage.microsoft.com (or the enrollment link you communicate). Safari specifically — the management profile download requires it.
2. Sign in with Entra ID credentials. Conditional Access applies at this step exactly as it would for any other sign-in.
3. Install the management profile. Safari downloads it; the user finishes via Settings > Profile Downloaded and confirms with the device passcode.
4. Let JIT registration complete. Entra device registration happens inside the flow itself — no Company Portal sign-in needed afterward.
5. Wait for policy to land. Apps and configuration profiles arrive over the following minutes as the device starts checking in.

Company Portal can still be deployed afterward as an app catalog, but it's optional.

Verification

• The device appears under Devices > iOS/iPadOS with the expected primary user, and the management profile is visible on-device under Settings > General > VPN & Device Management.
• Compliance evaluates to Compliant after the first check‑ins — a record stuck at Not evaluated means the enrollment didn't finish cleanly.
• Open a managed app gated by Conditional Access: a successful grant proves the Entra registration that JIT was responsible for actually completed.

Limitations to Accept

• Not supervised — no Lost Mode, no Single App Mode, no update deferral, no blocking profile removal.
• The user can remove management at any time (compliance + Conditional Access is your backstop: remove the profile, lose access).
• No Await Final Configuration — provisioning happens live on the home screen.

When It's the Right Call

• Corporate devices procured outside the reseller channel that you can't (yet) Configurator-add to ABM.
• Contractor/loaner hardware with short lifecycles.
• Fast pilots where ABM logistics would slow you down.

For anything long-lived and corporate-owned, do the ABM work and use ADE.

Official Microsoft docs: Web-based device enrollment

Account-driven User Enrollment is Apple's privacy-first BYOD model: the user signs into their work account directly in iOS Settings, and the device creates a cryptographically separate work partition. IT manages the work side only; the personal side is invisible to MDM. The separation is structural, not cosmetic — the work side gets its own encrypted APFS volume and key material — which is what makes the privacy promise to users credible and a retire surgically clean.

What IT Can and Can't See

Prerequisites

• iOS/iPadOS 15 or later on the personal devices being enrolled.
• Managed Apple Accounts — via ABM, ideally federated to Entra ID so users sign in with work credentials and accounts materialize on demand.
• Service discovery: an HTTPS endpoint at https://yourdomain/.well-known/com.apple.remotemanagement returning JSON that points Apple at Intune's enrollment URL. Microsoft Learn documents the exact JSON body — host the file on the domain matching your users' UPN suffix.
• An Intune license per user and a user group to carry the enrollment profile assignment.

Step-by-Step: Prepare the Tenant

1. Stand up the discovery endpoint. Publish the well-known JSON on the UPN-suffix domain over HTTPS with a publicly trusted certificate. This file is what turns a typed work email into a routed enrollment — without it, nothing downstream happens.
2. Confirm Managed Apple Account coverage. With federation, accounts are created at first sign-in; if you provision accounts manually instead, verify every pilot user actually has one before they try.
3. Create the enrollment profile. Devices > Enrollment > Apple tab > Enrollment types — create a profile of type Account driven user enrollment.
4. Assign it to user groups, and review profile priority if multiple enrollment type profiles could match the same user.

Step-by-Step: The User Flow

1. Start from Settings. Settings > General > VPN & Device Management > Sign In to Work or School Account.
2. Enter the work email. Discovery resolves your domain and hands off to Entra ID sign-in — Conditional Access and MFA apply normally.
3. Let iOS build the work partition. Managed apps and the work Apple Account land in it automatically.
4. Review the separation. Settings shows the user a clean statement of what the organization manages — worth pointing at during onboarding, because it is the privacy story in one screen.

Verification

• Before pilot day: request the well-known URL from the public internet and confirm it returns HTTP 200 with the correct JSON body.
• After a test enrollment: the device record appears keyed to a per-enrollment ID rather than a hardware serial, and managed apps install into the work side only.
• Confirm compliance evaluates and Conditional Access grants access from a managed app signed in with the work account.

Insights

• The serial-number privacy behavior breaks any process keyed on serials — inventory reconciliation must use the enrollment user instead.
• Users can end management anytime by signing out — pair with App Protection Policies so the data story doesn't depend on enrollment persisting.
• If discovery isn't set up, enrollment fails with vague errors at the email step — validate the well-known URL returns HTTP 200 + correct JSON from the public internet before pilot day.

Official Microsoft docs: Account-driven User Enrollment

Account-driven Device Enrollment is the newest member of the family (iOS/iPadOS 18+): the same friendly Settings-based sign-in flow as account-driven User Enrollment, but resulting in whole-device management rather than a separated work partition.

Where It Fits

Think of it as the successor to old profile-based device enrollment for personally owned devices that need to be fully managed — common in regulated industries, or where corporate policy requires whole-device control on stipend/BYOD hardware. Unlike User Enrollment, IT sees the real serial number, full app inventory, and can issue a full wipe — make sure users understand that trade before enrolling.

Prerequisites

• iOS/iPadOS 18 or later — older builds cannot take this enrollment type.
• Managed Apple Accounts (ABM, federation recommended) — the same identity plumbing as User Enrollment.
• The same service discovery endpoint (/.well-known/com.apple.remotemanagement); the JSON advertises both enrollment flavors with separate version keys (mdm-byod for user enrollment, mdm-adde for device enrollment) — see Microsoft Learn for the current body.
• An Intune license per user and a user group to carry the profile assignment.

Step-by-Step: Enable and Roll Out

1. Update the discovery JSON. Make sure the mdm-adde capability is advertised alongside any existing mdm-byod entry, so devices learn that full device enrollment is on offer for your domain.
2. Create the enrollment profile. Devices > Enrollment > Apple tab > Enrollment types — create a profile of type Account driven device enrollment and assign it to the target user groups. Profile priority decides which flow wins when a user matches several profiles.
3. Communicate the trade before anyone enrolls. IT sees the real serial number and full app inventory and can issue a full wipe — put that in the enrollment instructions in plain language so users on personal hardware consent knowingly, not retroactively.

The User Flow

Identical entry point to User Enrollment: Settings > Sign In to Work or School Account → work email → Entra sign-in. iOS evaluates which enrollment type the targeted profile prescribes and proceeds into full device management with user consent screens that spell out what IT will control.

Compared to Its Siblings

Verification

• The enrolled device shows the hardware serial number and full app inventory in the console — the visible markers that distinguish it from a User Enrollment record.
• Policy lands device-wide (not in a separated work partition) and compliance evaluates normally.
• Run one full lifecycle in the pilot — enroll, apply policy, unenroll from Settings — so the helpdesk knows exactly what each side sees at every stage.

Insights

• Intune support for this enrollment type is recent — pilot on current Intune service releases and keep an eye on What's New for capability changes.
• Because users can still unenroll, treat compliance + Conditional Access as the enforcement backbone, exactly as with web-based enrollment.

Official Microsoft docs: iOS/iPadOS enrollment guide

The classic device handoff had a dead zone: wipe the iPhone, and it sits at Hello until a human walks it through Setup Assistant. Return to Service closes the zone — the erase command carries a Wi-Fi payload (and optionally eSIM preservation on supported builds), so the device wipes, rejoins the network on its own, runs straight through ADE, and lands back at the home screen enrolled and configured. Wipe-to-working becomes one remote action.

How It Works

The wipe action, issued with Return to Service options, embeds: the Wi-Fi configuration the freshly-erased device should join, the default language/region (skipping those panes), and — because the device is ABM-assigned and supervised — the ADE flow that does the rest. Your enrollment profile's pane skips and await-configuration design carry the experience from there.

Where It Changes Operations

• Shared iPad and frontline pools: end-of-term or end-of-rotation resets become a bulk action run after close, with carts full of ready devices by morning — no bench day
• Device transfers: departing user's iPhone → Return to Service → next user's first touch is the sign-in screen — the handoff becomes a remote action instead of a desk-side reprovisioning appointment
• Remote remediation: the troubleshooting economics shift — past a half hour of diagnosis on a weird-state supervised device, reprovisioning is now genuinely cheaper than continuing

Prerequisites

• Supervised + ABM-assigned — the front-door guarantees that let the device re-enroll itself hands-free.
• An OS version on the device that supports the flow.
• A Wi-Fi payload that works at the device's actual location — a corporate-PSK payload sent to a home-office device re-enrolls nothing. Build location-appropriate payloads before you need them.
• Activation Lock discipline — a locked device post-wipe is the same paperweight it always was.

Step-by-Step: Issue Return to Service

1. Confirm the device qualifies. Supervised, ABM-assigned, supported OS, Activation Lock accounted for — thirty seconds on the device blade saves a stranded device later.
2. Choose the Wi-Fi payload deliberately. The network configuration embedded in the erase must be joinable where the device physically sits when it reboots, not where it was originally provisioned.
3. Issue the wipe with Return to Service options. From the device's Wipe action — or across a pool via a bulk action — enable Return to Service and attach the Wi-Fi configuration; preserve the cellular plan where the device should keep its line.
4. Let ADE do the rest. The device erases, rejoins the network on its own, runs your enrollment profile's pane skips and await-configuration design, and lands provisioned at the home screen.

Verification

• The device re-enrolls and checks in — confirm the fresh enrollment timestamp on the device blade and that policies and apps report as applied.
• A quick remote confirmation with the receiving user (sign-in screen reached, apps present) closes the loop without anyone shipping hardware.
• If the device never comes back, assume the Wi-Fi payload didn't match its location — the fix is physical, which is exactly why the lab test below matters.

Insights

• Test the failure path deliberately: issue Return to Service with a wrong Wi-Fi password once in the lab and watch what you get — knowing what a stranded device looks like (and that the fix is physical) calibrates how confidently you fire this at remote workers.
• Pair with stale-device hygiene: Return to Service makes recycling easy, which makes the inventory-truth question ("is this device active or a drawer ghost?") the only remaining gate before pulling the trigger.

Official Microsoft docs: iOS/iPadOS enrollment guide

Enrollment restrictions decide which devices get to enroll at all. They are evaluated when a device attempts enrollment — and crucially never again afterward. Intune offers two restriction types for iOS: device platform restrictions (allow or block the platform, block personally owned devices, enforce an OS version range) and device limit restrictions (cap how many devices one user can enroll). You can run up to 25 policies of each type, assigned to user groups, with a priority order resolving conflicts.

What "Personally Owned" Actually Means

Intune classifies every iOS device as personally owned unless it can prove otherwise at the gate. There are exactly two proofs:

• The device comes through ADE — its serial lives in ABM and is assigned to your MDM server, so corporate ownership is established by the supply chain before any user touches it.
• The serial or IMEI is pre-registered under corporate device identifiers — your way of vouching for corporate hardware that lives outside ABM.

Everything else — Company Portal, Safari, Settings — presents as personal, whoever actually paid for the hardware.

Blocking personal devices is an enrollment decision, not a data-protection one: BYOD users turned away here can still be served with App Protection Policies, which need no enrollment at all.

OS Version Floors

Platform restrictions accept a minimum and maximum allowed OS version, in major.minor.rev format. The floor is the useful half: it keeps forgotten hardware on ancient builds from ever entering the tenant. But the gate is evaluated once — a device that enrolled healthy and then stopped updating sails on untouched. Pair the enrollment floor with a minimum-OS rule in your compliance policies: the restriction guards the door, compliance patrols the building.

Device Limit Restrictions

The device limit caps how many devices a single user can enroll — from 1 to 15. A record counts against the cap when it is Intune-managed, made contact within the last 90 days, isn't stuck pending registration over 24 hours, and hasn't failed enrollment or been deleted. Two separate caps exist, and the stricter one wins:

• The Intune device limit — gates enrollment into management.
• The Entra ID "maximum number of devices per user" setting — gates the device registration underneath; a device blocked from registering fails enrollment however generous the Intune limit is.

Corporate enrollment is not exempt: an ADE device enrolling with user affinity counts against the signing user under both limits, which bites when a provisioning technician signs into device after device and hits the cap mid-cart. Plan for it — enroll genuinely shared hardware without user affinity (no user, no cap), give provisioning staff a high-limit restriction, or use a device enrollment manager account for Company Portal-driven staging (DEM doesn't work with ADE).

Priority and Assignment

Restrictions are assigned to user groups only. When a user sits in several groups with different restrictions, the highest-priority policy — 1 is the top — applies and the rest are ignored. New restrictions land just above the default; reorder by dragging in the priority column. The default restriction sits immovably at the bottom and catches everyone unassigned — including enrollments with no user behind them, such as ADE without user affinity, which always evaluate against the default. That makes the default the most consequential policy you own. Assignment filters are supported with a reduced property set (the device isn't enrolled yet): manufacturer, model, OS version, ownership, and enrollment policy name.

Prerequisites

• The Intune Administrator role — other built-in Intune roles get read-only access to restrictions.
• User groups that mirror your enrollment audiences — a restriction without an assignment does nothing.
• Corporate device identifiers uploaded for corporate hardware outside ADE — before flipping the block, not after the first lockout ticket. Better still, get the hardware into ABM.
• A helpdesk article written in advance describing what a blocked user sees and what to do next.

Step-by-Step: Block Personally Owned Devices

1. Pre-stage the exceptions. Upload serials/IMEIs of corporate devices that don't come through ADE, and confirm the ADE token and enrollment profiles are healthy — those two populations are the only ones that will pass.
2. Open the restriction blade. Go to Devices > Enrollment > Device platform restrictions, select the iOS/iPadOS tab, and choose Create restriction.
3. Name it for the audience. "iOS — corporate only — all staff" reads better in the priority list at 2 a.m. than "Restriction 3".
4. Configure platform settings. Leave the platform on Allow, set Personally owned devices to Block, and set the minimum OS version while you're here — one gate, one review.
5. Scope and assign. Apply scope tags if you delegate administration, then assign to the user groups this gate should govern. Group and filter changes take up to about 15 minutes to propagate — don't test enrollment seconds after adding a user to the group.
6. Review priority. If multiple restrictions could catch the same user, drag the order until the intended one wins.

Verification

• An ADE device enrolls untouched through Setup Assistant — proof the block is scoped to ownership, not platform.
• An identifier-listed device enrolls through your user-driven flow of choice.
• An unlisted personal device is refused. Company Portal and the Safari flow show a deliberately generic couldn't-enroll message; a user at the device limit instead sees they've added the maximum number of devices allowed and must remove one to continue.
• Check enrollment failure reporting in the admin center after the pilot window — blocked attempts appear with a failure reason pointing at enrollment restrictions. Enrollment Errors covers the triage from there.

Insights

• A restriction is a gate, not a policy. It is evaluated exactly once, at enrollment; editing it later affects new enrollments only and never unenrolls a device already inside. Tightening the gate doesn't clean the fleet — compliance does that.
• Most "device cap reached" tickets are stale-record problems wearing a limit costume. Before raising anyone's cap, check the age of the devices on their list and run stale device cleanup — usually the cap was doing its job.
• The blocked-user message is vague by design, so the helpdesk traffic arrives as "Company Portal is broken", not "I'm blocked by policy". Publishing the what-you-will-see article before enforcement is the difference between a quiet rollout and a loud one.

For where each method fits in the first place, start with Choosing an Enrollment Method.

Official Microsoft docs: What are enrollment restrictions?

Enrolling an iPhone or iPad creates two records that are easy to conflate: the Intune managed-device object (the management channel — MDM profile, APNs, check‑ins) and the Microsoft Entra ID device object (the identity). Every iOS enrollment flow produces the same identity class: a Microsoft Entra registered device. Registration is the device identity model for iOS — the device registers with the directory; it never becomes a joined device. What varies between flows is when registration completes and what the record is keyed to — two variables that explain most "enrolled but still blocked" tickets.

What Registration Actually Creates

Registration produces a device object in the directory — device ID, display name, OS version, a compliance flag, an activity timestamp — and provisions a workplace-join certificate on the device. The private key lives in the device keychain, where the broker apps (Microsoft Authenticator, Company Portal) and the Enterprise SSO plug-in can present it. That certificate binds hardware to directory: brokered sign-ins carry a certificate-backed device claim, and in Safari, Entra identifies the device by prompting for the client certificate. No certificate at sign-in means Entra sees a user with no device — however healthy the Intune record looks. In short: enrollment establishes management, registration establishes identity, and compliance-driven Conditional Access needs both.

The Chain That Makes Compliance Mean Something

1. Intune evaluates compliance policies against the enrolled device as it checks in.
2. The verdict is stamped onto the Entra device object as its compliant flag — the Intune record holds the detail, the Entra record holds the answer.
3. The sign-in presents the device identity — the SSO plug-in or broker app attaches the certificate-backed claim.
4. Conditional Access matches the claim to the record, reads the flag, and grants or blocks.

The chain fails closed: a device whose registration never completed presents nothing at step 3, so a require-compliant-device grant fails even while the Intune blade shows green. That isn't a compliance problem, and re-enrolling won't fix it faster than completing the registration would.

What Each Enrollment Flow Produces

The pattern to internalize: Setup Assistant and the enrollment profile get the device managed; registration is a second, interactive handshake that needs an Entra sign-in on the device itself. Historically that was Company Portal's job; with just-in-time registration it happens at the first sign-in to any work app. Until then, a freshly provisioned ADE device sits in the gap — managed, compliant in the Intune blade, and invisible to device-based Conditional Access.

Where Duplicate and Stale Records Come From

• Wipe and re-enroll. The wipe destroys the keychain, and the workplace-join certificate with it. Re-enrollment completes a fresh registration and creates a new Entra object; the old one lingers with its timestamp frozen. Routine Return to Service cycles produce these by design — budget for cleanup.
• Restore from backup. Backups never carry the management profile, so a user migrating to new hardware by restore arrives looking configured but unmanaged and unregistered. The fresh enrollment creates new records while the old device's linger, and a restored Company Portal can show stale state until the next sign-in.
• The activity timestamp is coarse. It updates only when the stored value is more than 14 days old (with about a five-day variance) — anything younger than roughly three weeks is noise, not a liveness signal.

Step-by-Step: Clean Up Records Safely

Cleanup needs the Intune Administrator or Cloud Device Administrator role, and a deliberate order:

1. Clean the management side first. Retire or delete the dead Intune record — stale device cleanup automates the find-and-action. Intune deletions remove the Intune object only; the Entra object survives independently.
2. Identify Entra candidates by activity timestamp. Export the list before acting — the export is your undo plan for everything except deletion, which has none.
3. Match on device ID, not name. Duplicates share display names by construction; the live record is the one matching the Entra Device ID on the active Intune object.
4. Disable before deleting. A disabled record stops satisfying Conditional Access but is reversible. Give it a grace period.
5. Delete after the grace period. Deletion is permanent, and it removes the directory identity only — the device itself keeps a registration state it can no longer use.

Verification

• The user's device list in Entra shows one record per physical device, matching the active Intune object.
• A sign-in to a Conditional Access-protected app from the surviving device still gets a grant — you removed the twin, not the identity in use.
• No new device-limit complaints — stale registrations quietly consume per-user headroom.

Hardening the Identity: Managed Device Attestation

Registration proves possession of key material; it doesn't prove what hardware holds it. Managed Device Attestation closes that gap: the Secure Enclave generates keys that cannot leave the silicon, and Apple's attestation servers vouch cryptographically that the request comes from a genuine, specific device. Classic registration binds the record to a certificate that could theoretically be exfiltrated; attestation binds it to physics — the strongest anchor a Conditional Access posture can stand on.

Insights

• When Intune says compliant and Entra says noncompliant, registration never completed. The fix is an interactive sign-in on the device — Company Portal or any SSO-extension app — not a re-enroll, which rebuilds the same gap with more downtime.
• Processes keyed on serial numbers silently miss Account-driven User Enrollment records, which deliberately carry a per-enrollment ID. Reconcile BYOD inventory by user, not hardware.
• Do inventory hygiene in Intune and identity hygiene in Entra — in that order, on a schedule. Tenants that clean only one side accumulate the half-orphaned records that make every future cleanup scarier.

Official Microsoft docs: Microsoft Entra registered devices

The Settings Catalog is the modern home for iOS configuration: every setting individually selectable, mapped 1:1 to Apple's MDM payload keys, with per-setting reporting. New Apple capabilities land here first.

Catalog vs. Templates

Practical rule: new policies go in the Catalog; keep Templates only where the Catalog hasn't absorbed the payload yet (some Wi-Fi/VPN scenarios) or where an existing fleet depends on them.

Finding Settings

The Catalog's search matches both Intune's friendly names and Apple's raw key names — searching allowAirDrop or "AirDrop" both work. When Microsoft's description is thin, look the key up in Apple's Device Management documentation — the Catalog is a UI over that spec, and Apple documents supervision and OS-version requirements per key.

Conflict Resolution — Memorize This

• Restrictions: when two profiles disagree, the most restrictive value wins. A single allow can never override a block.
• Other payload types (Wi-Fi, SSO, etc.): conflicting duplicates produce a conflict state and neither applies reliably — per-setting reporting shows exactly which key collided.
• Corollary: keep each setting in exactly one policy. The baseline's one-policy-per-area split exists for this reason.

Operational Hygiene

• Name policies so the assignment story is readable at a glance: iOS-<Area>-<Audience>-v<N>.
• One purpose per policy; resist the 200-setting mega-profile — it can't be piloted, diffed, or rolled back sanely.
• Document the why in each policy's description field. Future-you and auditors both read it.
• Policies are Graph objects (deviceManagement/configurationPolicies) — version them with IntuneCD for config-as-code backup and diffing.

Official Microsoft docs: Settings Catalog

Push Wi-Fi so devices join the right network before the user can mistype a passphrase. Two tiers: simple PSK, and certificate-based enterprise (EAP-TLS) — the second is where iOS fleets earn their keep.

Prerequisites

• Network facts agreed with the network team: SSID, security type, and (for PSK) the passphrase.
• For EAP-TLS: a working certificate issuance chain (trusted root + SCEP) and the exact server names on your RADIUS certificate.
• A decision per SSID on whether network tooling needs the hardware MAC (corporate networks) or privacy-preserving randomization is fine (guest) — see the gotcha below.

Step-by-Step: Basic (PSK) Profile

1. Create the profile. Devices > iOS/iPadOS > Configuration > Create — Wi-Fi (Templates, or the Catalog's Wi-Fi category).
2. Set the SSID and turn on Connect automatically so devices join without user action.
3. Leave Hidden network off unless it truly is hidden — hidden SSIDs add probe noise, not security.
4. Choose the security type — WPA/WPA2/WPA3 Personal — and enter the pre-shared key.
5. Add per-network proxy settings if your egress design requires them.
6. Assign to the target device group and deploy.

Good for guest/IoT-grade segments. Corporate data networks deserve certificates.

Step-by-Step: Enterprise (EAP-TLS) Profile

The gold standard: the device authenticates with a certificate, no passwords anywhere. Build order matters — three profiles, deployed together:

1. Deploy the trusted certificate profile — your root (and issuing) CA, so the device trusts the RADIUS server. (Certificates guide)
2. Deploy the SCEP certificate profile — issues the device its identity cert.
3. Create the Wi-Fi profile (Enterprise) — EAP type EAP-TLS, Identity certificate = the SCEP profile from step 2, Server Trust > certificate server names matching your RADIUS server's cert.
4. Assign all three profiles to the same group. Intune sequences the dependencies automatically; reporting on the Wi-Fi profile shows "pending" until the SCEP cert lands.

The MAC Randomization Gotcha

Since iOS 14, devices present a per-network private (randomized) MAC address by default — which breaks MAC-based NAC, DHCP reservations, and Wi-Fi analytics keyed on hardware MACs. The Intune Wi-Fi profile exposes a MAC address randomization setting — set it to use the static (hardware) MAC on your corporate SSIDs where network tooling depends on it. Leave randomization alone on guest networks; it's good privacy hygiene there.

Verification

• Profile reporting shows Succeeded for all deployed profiles — a Wi-Fi profile stuck at Pending usually means the SCEP certificate hasn't issued yet.
• On a pilot device, the SSID joins without prompting, and the identity certificate is visible inside the management profile details.
• Ask the network team to confirm one successful EAP-TLS authentication in the RADIUS logs — that single log line proves the entire chain end to end.

Insights

• Deploy the Wi-Fi profile in the enrollment-time policy set so ADE devices land on corporate Wi-Fi during Await Final Configuration — otherwise first-boot app installs ride whatever network the user picked.
• Removing a Wi-Fi profile removes the network and its stored credentials — sequencing matters during SSID migrations: add the new profile, confirm fleet adoption, then retire the old one.
• 802.1X failures are almost always server trust (RADIUS cert name not listed) or an expired device cert — check those before blaming the WLAN team, and they'll do the same for you.

Official Microsoft docs: Wi-Fi settings in Intune

iOS VPN comes in three escalating flavors. Most enterprises should be running the middle one and don't know it.

1. Device-Wide VPN

The classic: a VPN profile (IKEv2 native, or a vendor connection type — Cisco Secure Client, GlobalProtect, FortiClient, F5 Access, Zscaler, Check Point, and friends) the user or on-demand rules activate. Configure under Devices > Configuration > VPN (Template or Catalog):

• Connection type determines which client app must also be deployed (VPP, required) — the profile configures the vendor's app, it doesn't replace it.
• On-demand rules can auto-connect when specific domains are requested.

2. Per-App VPN (the one you probably want)

The standout iOS capability: the tunnel activates only for designated managed apps — corporate apps reach internal resources, personal traffic never touches your gateway. Better privacy, smaller attack surface, happier users.

Setup is two halves, and the second half is the step everyone misses:

1. Create the VPN profile with per-app VPN enabled (the vendor must support it — most do).
2. Associate the profile on the app assignment. In the app assignment (the VPP/LOB app's Required assignment), associate the per-app VPN profile. The association lives on the assignment, not on the profile — configure the profile alone and the tunnel never activates.

Safari can participate via Safari domains listed in the profile: matching URLs route through the tunnel.

3. Always-On VPN

Supervised-only, IKEv2-only: the device tunnels all traffic, always, with no user off-switch. Reserved for regulated/high-security fleets — it's operationally unforgiving (gateway outage = fleet outage). Configure deliberately, pilot longer than feels necessary.

Microsoft Tunnel

Microsoft's own VPN gateway: a Linux-hosted appliance, with the iOS client delivered inside Microsoft Defender — one app provides MTD and per-app VPN. If you're already deploying Defender for iOS and need lightweight internal access, Tunnel avoids introducing another vendor. Conditional Access can gate the tunnel itself.

Verification

• Per-app: launch a designated managed app and confirm it reaches an internal resource while non-designated traffic does not — that asymmetry is the feature working as designed.
• Device-wide / always-on: the VPN indicator shows on the device, and the gateway's session table lists the device.
• Check per-device deployment status on the profile; a per-app tunnel that never activates almost always means the app-assignment association (step 2) was skipped.

Insights

• Per-app VPN + Defender's web-protection loopback VPN can coexist (the loopback isn't a real tunnel), but stacking multiple real VPN vendors on one device is misery — pick one.
• Test the failure mode: what does the LOB app show users when the gateway is down? "Spinning forever" generates tickets; work with the app team on a timeout message.

Official Microsoft docs: VPN settings in Intune

Certificates are the quiet dependency under everything good: EAP-TLS Wi-Fi, per-app VPN auth, and password-less access to internal systems. iOS handles them beautifully — once the issuance chain is built.

The Three Profile Types

Issuance Backends — Pick One

1. Microsoft Cloud PKI (Intune Suite add-on): Microsoft-hosted CAs purpose-built for Intune SCEP — no on-prem connector, no NDES, stand up issuance in an afternoon. The default recommendation for new builds without an existing PKI mandate.
2. Your enterprise CA via the Certificate Connector for Intune: the on-prem path — install the connector, publish templates, point SCEP profiles at it. Right answer when AD CS already runs your world.
3. Third-party CAs (DigiCert, Sectigo, EJBCA, SCEPman, etc.) via their Intune integrations — SCEPman in particular is a popular Azure-native community favorite for Intune-only PKI.

Step-by-Step: Build the Issuance Chain

1. Deploy the Trusted certificate profile first. Export your root (and issuing) CA public certs, create the profile, and assign it to the target group — every SCEP profile references it, so it anchors everything that follows.
2. Create the SCEP profile. Devices > Configuration > Templates > SCEP certificate (iOS/iPadOS), then work through the settings:
   • Subject name format: e.g. CN={{DeviceName}},O=YourOrg — token variables ({{AAD_Device_ID}}, {{SerialNumber}}, {{UserPrincipalName}} on user-affinity devices) make certs traceable
   • SAN: include {{AAD_Device_ID}} as URI for Entra-aware services
   • Key usage / size: signing + encryption, 2048 minimum
   • Validity: 1 year is the sane default; shorter if your backend automates renewal cleanly (Intune renews automatically near expiry)
   • Root certificate: link the Trusted certificate profile
   • SCEP server URLs: from Cloud PKI / your connector
3. Assign both profiles to the same groups so issuance can complete in one policy cycle — a SCEP profile without its trusted root never finishes.

Verification

• Profile reporting shows Succeeded for both the trusted root and the SCEP profile; on the device, the issued identity certificate is visible inside the management profile details.
• Your CA's issued-certificates log shows one cert per device with the expected subject — duplicates or rapid re-issuance point at a profile misconfiguration.
• Test one downstream consumer end to end (an EAP-TLS Wi-Fi join or a per-app VPN authentication) — certificates only matter insofar as the things they authenticate actually work.

Insights

• Renewal is silent until it isn't. Intune re-issues before expiry, but a broken connector fails silently fleet-wide; alert on the connector's health and on Wi-Fi auth failure spikes — that's your early warning.
• Certs issued to the device die with the management profile — a retire/wipe revokes access to everything cert-gated instantly. That's a feature; document it for the helpdesk.
• One identity cert can serve both Wi-Fi and VPN profiles — reference the same SCEP profile from each rather than issuing duplicates.

Official Microsoft docs: Certificates in Intune

Branding settings are supervised-only and pure quality-of-life — but on shared, kiosk, and frontline fleets they're the difference between "an iPad" and "our iPad." All of it lives in supervised territory (ADE).

Prerequisites

• Supervision — every control on this page requires it, which in practice means ADE-enrolled, corporate-owned hardware.
• Assets and copy ready: a portrait PNG for wallpaper, your asset-tag scheme, and the if-lost contact line.

Step-by-Step: Home Screen Layout

1. Open the template. Devices > Configuration > Templates > Device features > Home screen layout (supervised).
2. Define the Dock. 4–6 daily-driver apps: Outlook, Teams, your LOB app — the things a user reaches for hourly.
3. Lay out pages and folders for the curated set. Apps not in the layout flow onto later pages automatically — you're pinning the front door, not cataloguing everything.
4. Position web clips like apps — pin the intranet portal next to Outlook.
5. Assign to the shared/kiosk/frontline device groups and deploy.

Reality check: users on 1:1 personal-enabled devices resent frozen layouts. Use layout policies on shared/kiosk/frontline fleets; skip them (or dock-only) for knowledge workers.

Step-by-Step: Wallpaper

1. Prepare the asset. A portrait PNG sized generously — devices scale down better than up — with a high-contrast logo. A branded lock screen makes pool devices identifiable across a room; operationally underrated in hospitals and warehouses.
2. Configure the same Device features template (supervised): push the image to the lock screen, home screen, or both.
3. Test on both iPhone and iPad aspect ratios before any fleet-wide push — one asset rarely flatters both without checking.

Step-by-Step: Lock Screen Message (the asset tag trick)

1. Find the settings. Settings Catalog > search Lock Screen Message.
2. Set Asset tag information: e.g. Asset: CFA-00231 · IT: x4357 — it shows on the lock screen and in Settings > General > About.
3. Set the "If Lost, Return To…" footnote text. Combined with Lost Mode, this is your loss-recovery funnel: every honest finder sees exactly who to call without unlocking anything.

Verification

• After the next check‑in on a pilot device, lock it and read the lock screen exactly the way a finder would: wallpaper, asset tag, and if-lost line all present.
• Confirm the asset tag also appears under Settings > General > About — that is where the helpdesk will look during calls.
• Check the home screen layout applied: Dock contents and page order match the policy.

Naming Ties It Together

Branding on glass should match identity in the console — the Bulk Device Rename script enforces a naming convention (IOS-<site>-<serial-tail>) across the fleet so the label, the lock screen, and the Intune object all agree.

Official Microsoft docs: iOS/iPadOS device restrictions

Apple Intelligence (iOS/iPadOS 18+ on supported hardware) brought a new family of MDM restrictions, and "what's our AI policy on phones?" is now a question every iOS admin gets. Here's the control surface and a defensible default.

Where the Controls Live

Settings Catalog > Restrictions — search "intelligence", "Genmoji", "writing", or "playground" to surface the family. Most require supervision, and Apple adds keys each OS cycle — re-run that search after every major release and check Apple's device management documentation for per-key OS requirements.

The Control Family

The Data-Flow Mental Model

Apple processes most Apple Intelligence requests on-device, escalating heavier requests to Private Cloud Compute (Apple silicon servers, cryptographically attested, no retention per Apple's design). External integrations (ChatGPT) are a separate, explicit hand-off to a third party — which is why the controls split there. Your legal/security stance on "Apple PCC" vs "third-party AI" can differ, and the keys let you encode that difference.

A Defensible Baseline Posture

Whatever you choose, write the rationale into the policy description — this is the restriction family auditors ask about first now.

Step-by-Step: Put the Posture in Place

1. Create the policy. Devices > iOS/iPadOS > Configuration > Create > Settings catalog, named so the intent is obvious later, e.g. iOS-Restrictions-AppleIntelligence-v1.
2. Add the restriction keys. Search the Restrictions category for the family ("intelligence", "Genmoji", "writing", "playground") and set each control according to the tier table above.
3. Record the decision. Put the rationale — what is blocked, why, and who approved the external-integration stance — into the policy description field before assignment.
4. Pilot on hardware that actually supports Apple Intelligence. Ineligible devices silently ignore the keys, so a pilot ring of older hardware proves nothing about the restrictions working.
5. Assign broadly, then re-audit every OS cycle. Apple adds keys each release; re-run the Catalog search after every major version and fold new controls into the policy deliberately rather than letting them default.

Insights

• These restrictions interact with device eligibility: older hardware without Apple Intelligence simply ignores the keys — fine, but it means reporting "policy applied" ≠ "feature existed to restrict."
• Pair the MDM posture with your App Protection story: APP's data-egress rules already prevent pasting corporate data into a personal ChatGPT app — the restriction keys close the system-integration path specifically.

Official Microsoft docs: iOS/iPadOS device restrictions

eSIM-only iPhones made cellular an endpoint-management problem. Set expectations correctly: Intune observes and protects cellular configuration well, but provisioning lives with your carrier.

What Intune Gives You

• Inventory: per-device hardware blade (and Graph) reports EID, ICCID, IMEI, phone number, and carrier — everything your telecom team needs for reconciliation.
• Protection: the wipe action's "Retain cellular data plan" option — the single most important checkbox in eSIM fleet operations (below).
• Configuration: a Cellular payload (Settings Catalog/custom profile) for APN settings in private-APN/IoT deployments.
• Restrictions: block users from modifying eSIM settings / removing the plan (supervised) — stops the accidental "deleted my work line" ticket.

What Intune Doesn't Do

Activating a plan onto a device. eSIM provisioning paths are: carrier activation at point of sale, the carrier's app/QR flow, or carrier eSIM orchestration platforms that push profiles by EID. Enterprise pattern: ship your carrier a CSV of EIDs (export via Graph) and they pre-provision — pair that with ADE and a device arrives with management and service, zero touch.

The Wipe Trap (Read Twice)

A standard Wipe erases the eSIM along with everything else. The device returns to a user — or worse, a remote field tech — with no cellular service and possibly no Wi-Fi to recover with. Check "Retain cellular data plan" on every wipe of a device that will be redeployed with its line. Wipe without it only when the line should genuinely die with the assignment.

Train the helpdesk on this before the first remote-worker redeploy, not after.

Insights

• Pilot your carrier, not just your devices. eSIM transfer/redeploy behavior varies meaningfully between carriers; run a full lifecycle (provision → wipe-with-retain → reassign → terminate) before committing the fleet.
• Dual-SIM (work eSIM + personal physical/eSIM) is increasingly the BYOD-adjacent ask — Intune sees both identifiers; your acceptable-use policy should say which line the org pays for and controls.
• Keep EID → user → line mapping automated from day one (inventory script + telecom billing export); reconciling it retroactively across 2,000 devices is a quarter of someone's life.

Official Microsoft docs: iOS/iPadOS device restrictions

VPN profiles cover the classic tunnel; this page covers the payload family Apple built for the post-tunnel era — network controls that shape traffic without a legacy VPN's weight.

Network Relay (the VPN Successor Pattern)

The relay payload configures Apple's built-in relay client (the MASQUE/HTTP-3-based transport behind iCloud Private Relay, opened to enterprise): traffic to defined domains routes through your relay infrastructure — per-app or domain-scoped — with no packet-tunnel extension, no third-party client app, and dramatically better battery and connection-migration behavior than device-wide VPN. The fit: organizations on ZTNA/secure-edge platforms whose vendors expose relay-compatible endpoints, replacing per-app VPN for web-shaped corporate access. The strategic note: relays are the bridge out of VPN debt, not another tunnel to accumulate.

Encrypted DNS (DNS Settings Payload)

The DNS payload pins devices to DoH/DoT resolvers — your protective DNS, enforced at the OS — with optional always-on behavior on supervised devices. This is the cheapest meaningful network-security control on the platform: phishing/malware domain blocking that follows the device onto every network, deployed as one payload.

Content Filter Architecture

Filtering on iOS is payload-mediated, two-tier: the built-in restrictions (limit adult content / allow-list) for blunt needs, and filter-provider payloads pointing at a vendor's filter extension for real policy — the MTD/Defender class of products ride this for web protection. One provider per scope; stacking filter providers recreates the classic two-security-agents-one-hook conflict in network form — multiple extensions claiming the same traffic produce breakage nobody can cleanly triage, so pick a single provider and document the choice.

Insights

• Decide the sequencing against per-app VPN explicitly — relay, VPN, DNS, and filter payloads all touch the same flows, and the interaction matrix is yours to own: document which control owns which traffic class or the first conflict ticket will be unsolvable by anyone who didn't write the profiles.
• The DNS payload is the quiet BYOD-tier win: protective DNS on enrolled devices costs users nothing visible and closes the commodity-phishing door — deploy it before the fancier layers.

Official Microsoft docs: iOS/iPadOS device restrictions

Apple's ecosystem magic — AirDrop, AirPlay, Handoff, clipboard sync — is also a set of data paths, and managed fleets decide each one on purpose. The restrictions catalog's ecosystem family, organized by what's actually at stake:

AirDrop

The headline decision. Options run from off (regulated fleets — AirDrop is unauditable point-to-point file transfer) through managed-devices-only postures via the managed pasteboard/sharing boundary interactions, to open with managed open-in doing the data-boundary work (the common knowledge-worker landing: AirDrop exists, but corporate documents can't leave managed apps to ride it). Decide per data classification, write the one-liner for users, move on.

AirPlay and Casting

The conference-room reality: AirPlay to meeting-room hardware is a productivity feature; AirPlay to arbitrary receivers is a projection-of-confidential-content risk. The control set: restrict AirPlay targets via allow-listed receivers/passwords where rooms are managed, and pair with the screen-capture/recording restrictions that govern the adjacent risk on regulated fleets.

Continuity (Handoff, Universal Clipboard, Calls/Messages Relay)

These ride the user's Apple Account across their devices — and that is exactly the question: corporate data continuing onto unmanaged personal hardware. On supervised corporate devices, Handoff/clipboard restrictions close the path; on BYOD, the workable answer is App Protection's cut/copy boundary governing the data rather than fighting the feature. The underlying discipline is iCloud-boundary thinking: decide which Apple Account data paths corporate data may ride, write the decision down, and apply it consistently across every ecosystem feature.

Insights

• This family is where the restraint doctrine earns trust: block what the data classification demands, leave the rest — a fleet where AirDrop mysteriously "doesn't work" without explanation breeds workarounds (personal devices in the workflow), a worse outcome that happens to look compliant.
• Test in the actual conference room: AirPlay restrictions interact with receiver firmware and network segmentation, and the ten-minute room test beats the theoretical matrix every time.

Official Microsoft docs: iOS/iPadOS device restrictions

Declarative Device Management (DDM) is Apple's next-generation management protocol, introduced at WWDC 2021 and expanded every release since. It runs inside an existing MDM enrollment — same channel, new grammar.

The Mental Model Shift

Legacy MDM is imperative: the server sends a command ("install this update"), the device executes it (maybe), and the server polls for status. Latency, drift, and "did it actually happen?" are baked into the design.

DDM is declarative: the server sends a declaration describing the desired state ("be on iOS 17.5.1 by June 20, 18:00 UTC"), and the device takes ownership of getting there — scheduling, retrying, notifying the user, and enforcing the deadline autonomously, even if it can't reach the server at the moment of truth.

The Building Blocks

The status channel is the underrated half: when a device installs the update, changes passcode state, or drifts, it tells the server immediately. Reporting freshness in Intune improves dramatically for DDM-managed state.

Version Support

• DDM protocol: iOS/iPadOS 15+ (user enrollment), iOS 16+ broadly.
• Software update enforcement via DDM: iOS/iPadOS 17+ — this is the scenario Intune exposes today and the one that matters operationally.

What This Means in Intune

You don't toggle DDM on. Intune delivers supported payloads declaratively when the device qualifies — most visibly the Software Update enforcement settings in the Settings Catalog. Your job is simply to prefer those payloads over their legacy equivalents.

Next: Configure DDM Software Updates

Official Microsoft docs: Software updates for iOS/iPadOS

This is the hands-on companion to the Managed Software Updates guide — the exact clicks, in order.

Prerequisites

• iOS/iPadOS 17 or later on target devices
• Devices enrolled via MDM (any enrollment type; supervision not required for DDM update enforcement)
• For deferral/hiding of updates (the partner setting), supervision is required

Step-by-Step: Create the Enforcement Policy

1. Create the policy. Devices > iOS/iPadOS > Configuration > Create > New policy > Settings catalog.
2. Name it per ring, e.g. iOS-Updates-Enforce-Ring1 — the name is your audit trail for which ring got which deadline.
3. Add the settings. Add settings > category Declarative Device Management > Software Update.
4. Select and configure the keys:
   • Target OS Version — exact version string, e.g. 17.5.1
   • Target Date Time — enforcement deadline. Entered/stored in UTC; do the timezone math for your users
   • (Optional) Target Build Version — only when you must disambiguate builds
5. Assign to the ring's device group. Repeat per ring with staggered deadlines.

What the User Experiences

1. Declaration lands silently; the device begins downloading the update on its own schedule (charger + Wi-Fi preferred).
2. Notifications start polite and get insistent as the deadline approaches — including a final countdown phase the user cannot dismiss away forever.
3. At deadline: install proceeds. If a passcode is set, iOS prompts for it; an ignored prompt results in installation at the next practical opportunity (lock/charge), and the OS treats the deadline as binding.

Verification

• Devices > Monitor > the Apple software updates reporting surfaces per-device update state (DDM status reports make this near-real-time compared to legacy).
• Per-device: the device blade shows the installed OS version refreshed by the status channel.
• After a ring's deadline passes, spot-check one device: the installed OS version matches the declaration's target — that single comparison proves the policy end to end.

Next: Insights

Official Microsoft docs: Managed software updates (DDM)

Field notes from running DDM update enforcement on production fleets.

• UTC will bite you once. Target Date Time is UTC. A "5:00 PM" deadline entered naively becomes mid-morning enforcement for US time zones. Decide deadline in local terms, convert deliberately, write the local time in the policy name or description.
• Give real runway. Deadlines less than ~48–72 hours out skip most of the polite-notification phase and feel hostile to users. The design shines when the device has days to find its own charger-and-Wi-Fi moment.
• Don't stack legacy update policies on top. Remove old Update policies for iOS/iPadOS assignments from devices that get DDM enforcement. They don't merge; they confuse both your reporting and occasionally the device.
• Exact version strings matter. 17.5.1 and 17.5 are different declarations. When Apple ships a same-week security respin, update the policy — the device won't "round up" on its own.
• Offline enforcement is real. Devices that received the declaration enforce at deadline even with Intune unreachable — great for field devices, surprising the first time a device in a drawer updates itself.
• Low battery is the most common "it didn't update" cause. The device defers installation until charging conditions are reasonable; deadlines effectively resolve at the next charge. Tell your helpdesk before they escalate.
• Deferral + enforcement is the complete system. Enforcement without deferral restrictions lets eager users jump to day-one releases before validation. Deferral without enforcement lets laggards live on old builds forever. You need both halves.

Official Microsoft docs: Software updates for iOS/iPadOS

DDM's premise — ship the device a desired state and let it converge autonomously — was proven on software updates; Apple has been extending the same model to apps: app declarations the device honors itself, reporting status back through DDM's status channel rather than waiting on command-queue round-trips.

What Changes vs Command-Based Installs

The classic VPP install is imperative: the server sends InstallApplication, the device obeys (eventually), the server polls for truth. Declarative apps invert it: the declaration states this app, this configuration, present — and the device owns convergence: installing when conditions allow, retrying on its own after transient failures, re-asserting if the app vanishes, and reporting state proactively through status subscriptions. The pending-forever class of ticket is exactly what this architecture deletes.

The Practical State of Play

This is a capability arriving in stages — OS support landed before management-platform surfacing, and what Intune exposes evolves by release. The pragmatic operating posture: know the model now (it's where the platform is going), watch the What's New feed for the Intune-side surfacing of declarative app configuration, and design new app-deployment standards so the intent layer (which apps, which populations — your assignment taxonomy) is independent of the delivery mechanism, which is precisely what makes mechanism upgrades free.

Why It Matters Beyond Speed

Declarations compose: an app declaration can participate in DDM's predicate/activation logic — state that applies when conditions hold — which points at app management that reacts on-device to context without server round-trips. The update-enforcement page's lesson generalizes: the device is the best agent of its own state.

Insights

• The migration thinking to start now: inventory which of your app deployments are state ("these 12 apps, always present, current") versus events ("push this once") — the state set is the natural DDM-apps cohort, and naming it today makes the eventual cutover a targeting exercise instead of a redesign.

Official Microsoft docs: Software updates for iOS/iPadOS

Rapid Security Responses are Apple's out-of-band patch vehicle: small, fast security fixes (the "(a)" suffix builds) that ship between full OS updates — installable without a full update cycle and, distinctively, removable. They exist for the actively-exploited-in-the-wild class of vulnerability where waiting for the next point release is the wrong answer.

The Control Surface

MDM restrictions govern the RSR experience on supervised devices:

• Allow/disallow RSR installation — whether devices take responses at all; the corporate default should be allow (these are the patches whose entire reason is urgency)
• Allow/disallow RSR removal — whether users can roll one back; managed fleets generally disallow removal, since "user uninstalled the emergency mitigation" is not a state you want discoverable in an incident review

These sit alongside — not inside — your DDM update enforcement: DDM deadlines drive scheduled OS currency; RSR policy governs the emergency lane. Two lanes, two doctrines, deliberately different speeds.

How to Run It

1. Allow installs fleet-wide, block removal — the boring, correct posture
2. Don't ring RSRs like point releases: their value is speed, and a three-week bake on an actively-exploited fix inverts the risk math. The ring-1 canary still exists — it just measures in hours, not weeks
3. Verify uptake: RSR state surfaces in OS version strings — the inventory report's version column showing the lettered suffix is your coverage proof when security asks

Insights

• RSRs apply to the latest OS — a fleet lagging on point releases isn't eligible for the emergency lane, which is one more argument for the DDM deadline discipline keeping the fleet current: emergency patching is a privilege of the up-to-date.
• When an RSR ships, the comms move is pre-written one-liner territory: "Apple shipped an urgent fix; your device may install it quickly and prompt for a short restart — that's expected and protective." Thirty seconds of comms converts a confusion spike into a non-event.

Official Microsoft docs: Software updates for iOS/iPadOS

Shared iPad is Apple's only true multi-user mode: multiple people share one iPad, each signing in with a Managed Apple Account to get their own separated workspace — apps see per-user data, sign-ins persist between sessions, and a returning user picks up where they left off.

How It Works

• The iPad partitions local storage among a configurable number of cached users. A returning cached user signs in to their data instantly; a new user beyond the cache triggers eviction of the least-recent.
• User data syncs against the Managed Apple Account, so a user can move between shared devices.
• Temporary Sessions (guest mode) provide a sign-in-free session that is completely wiped when the user signs out — ideal for kiosks-with-flexibility, libraries, patient devices.

Hard Requirements

Where It Fits

• Healthcare: nurses sharing cart iPads across shifts
• Retail/frontline: shift workers with personal sign-in but pooled hardware
• Education: the original use case (via Apple School Manager)

If users don't need their own state on the device, you may not need Shared iPad at all — a no-affinity ADE device with Single App Mode or a focused app set is far simpler to operate.

Next: Configure Shared iPad

Official Microsoft docs: Shared iPad enrollment

Prerequisites

• ADE-eligible iPads assigned in ABM — Shared iPad is set at activation and cannot be retrofitted without a wipe.
• Hardware with storage headroom — usable space divides across cached users, so higher-capacity models pay for themselves on busy carts.
• VPP apps licensed per device so every user gets the app set without per-user licensing friction.
• An identity decision: federated Managed Apple Accounts for named users, or Temporary Sessions only for anonymous populations.

Step 1 — Federation and Accounts

In ABM: Settings > Accounts, configure federated authentication with Microsoft Entra ID. Users then sign into Shared iPads with their existing work credentials; Managed Apple Accounts are created on the fly. (Manual MAA creation works but doesn't scale.)

Step 2 — Enrollment Profile

Devices > Enrollment > Apple tab > Enrollment program tokens > token > Profiles > Create profile > iOS/iPadOS:

• User affinity: Enroll without user affinity
• Shared iPad: Yes
  • Maximum cached users: balance storage vs sign-in speed. Rule of thumb: number of people who realistically rotate through a single device in a week. Fewer cached users = more storage each.
  • Or Temporary Sessions only for guest-style fleets — no Managed Apple Accounts needed at all.
• Setup Assistant: skip aggressively; nobody should linger in setup on a shared device.

Assign serials, wipe/activate devices. Shared iPad state is set at activation.

Step 3 — Target Policies and Apps to Devices

Everything targets device groups (there is no persistent primary user):

• VPP apps: Required, device licensed
• Configuration: Wi-Fi, restrictions, Enterprise SSO plug-in — SSO makes the per-user Microsoft sign-in experience tolerable
• A dynamic device group on the enrollment profile name keeps targeting automatic: (device.enrollmentProfileName -eq "SharedIPad-Production")

Step 4 — Session Settings (Settings Catalog)

Settings catalog > Shared iPad category exposes session behavior — temporary session timeouts, passcode requirements for MAA sign-ins, and quota-related options. Configure idle logout for clinical/retail floors so abandoned sessions close themselves.

Verification

• Activate one device and confirm the Shared iPad sign-in screen appears at the end of setup — if it boots to a standard home screen, the enrollment profile's Shared iPad setting wasn't applied at activation.
• Sign in with a test Managed Apple Account (or start a Temporary Session) and confirm apps, Wi-Fi, and the SSO experience land inside the session.
• Sign out and back in: the returning user's workspace should restore quickly — that round-trip exercises caching, identity, and policy in one pass.

Next: Insights

Official Microsoft docs: Shared iPad enrollment

• First sign-in is the slow one. A new user's first session provisions their workspace and syncs account state — on weak Wi-Fi this is tens of seconds to minutes. Pilot users conclude "it's broken." Set expectations: first sign-in slow, returning sign-in fast.
• Storage math is the design constraint. Usable space divides across the system, shared apps, and per-user partitions. On 64 GB iPads with heavy apps, more than 8–10 cached users gets cramped. Buy 128 GB+ for shared fleets and thank yourself later.
• Eviction is silent. When cached-user slots overflow, the least-recently-used profile is purged locally (cloud-synced data survives; purely local app data does not). Apps that stash data outside proper sync get blamed for "losing" work — vet your LOB apps' data story before committing to Shared iPad.
• Temporary Sessions wipe absolutely everything at sign-out. This is the feature. It's also why a patient/visitor who "saved" something locally cannot get it back. Signage near the device beats a helpdesk ticket.
• Some apps just behave badly multi-user. Apps assuming a single keychain identity or device-bound licensing can cross-contaminate or break between users. Test every LOB app with two different accounts on one device before scale-out.
• No affinity means no user-targeted policy. App config that depends on {{mail}}-style tokens resolves empty here. Apps must get user context at sign-in (MSAL + the SSO plug-in), not from MDM.
• The sign-in screen is your brand moment. Shared iPad's lock screen lists cached users — combine with a wallpaper policy and clean device naming (SHARED-ER-CART-03) so staff grab the right device and IT can find it in Intune.

Official Microsoft docs: Shared iPad enrollment

Shared iPad's architecture and setup get devices into multi-user mode; this page is the tuning — the handful of settings that determine the daily experience once carts are in the field.

The Storage Math

Shared iPad partitions storage across cached user spaces; the core dial is how many users the device caches versus how much space each gets. The trade is explicit: more cached users = faster repeat sign-ins for a rotating population; fewer = more room per user for app data. Calibrate from the actual rotation: a cart serving the same 8 nurses caches 8 beautifully; a lobby device serving hundreds shouldn't cache deeply at all — which is the temporary-session conversation.

Temporary Sessions (the Guest Mode)

Temporary sessions let anyone tap in without credentials and wipe the slate at sign-out — the kiosk-adjacent mode for libraries, loaners, and exam carts. The control set: whether temporary sessions are offered at all, plus idle timeouts (auto-end abandoned sessions) and sign-out behavior. The decision rule: if the population is anonymous, temporary sessions beat shared-credential workarounds every time — credentials shared on a sticky note are the failure mode this feature exists to delete.

Sign-In Experience

Managed Apple Accounts drive Shared iPad identity — federation makes the password the Entra password, and the sign-in screen's responsiveness rides your network's ability to reach Apple's auth quickly. Session timeouts tuned to shift rhythm close the loop: too short and users re-authenticate mid-task; too long and the next shift inherits a session.

Insights

• The classic "Shared iPad is slow" ticket is storage pressure showing up as a performance complaint — a device at quota evicting/rebuilding user spaces on every rotation churns visibly. The inventory view's capacity data per cart tells you before users do.
• Pilot the cache-count change on one cart and measure sign-in time — it's a thirty-second stopwatch test, and the number ends the meeting about it.

Official Microsoft docs: Shared iPad enrollment

"Kiosk mode" on iOS is really three different mechanisms. Picking the right one up front saves a redeploy.

The Three Flavors

SAM is the true kiosk: the device boots into one app and physically cannot leave it — no home gesture, no app switcher. The home screen ceases to exist.

ASAM delegates the locking to the app itself. The MDM allowlists bundle IDs that may call the autonomous lock APIs; the app then locks during an exam or signature capture and releases afterward. The app must actually implement ASAM support — check with the vendor.

Guided Access is the consumer feature (triple-click side button). Useful to know about; not a management strategy.

What SAM Implies Operationally

• The locked app is the entire user experience — if it crashes to a black screen or needs an update restart, your remote tools are the only way in.
• Pair with restrictions that suit a dark-corner appliance: auto-lock disabled, no passcode (plus Block Erase Content and Settings), and a remote restart capability you've tested.

Next: Configure Kiosk Mode

Official Microsoft docs: iOS/iPadOS device restrictions

Prerequisites

• Supervised device (ADE, no user affinity is the natural fit)
• The kiosk app deployed as a Required, device-licensed VPP app — the device must have the app before the lock policy lands
• The app's bundle ID (find it in the Intune app blade after VPP sync, or via Graph)

Single App Mode (App Lock)

1. Create the profile. Devices > iOS/iPadOS > Configuration > Create > Settings catalog, and name it so the intent is readable in a policy list six months from now (e.g. iOS-AppLock-Lobby-Kiosks).
2. Add the App Lock category and configure it:
   • App > Identifier: the bundle ID, e.g. com.yourorg.checkin. Copy it from the Intune app blade rather than typing it — the identifier must match character-for-character, and a typo produces a profile that reports success while locking nothing.
   • Options: disable what a kiosk shouldn't have — auto-lock, touch can stay on, volume/sleep buttons per use case, disable VoiceOver/Zoom unless accessibility requires them.
3. Assign to the kiosk device group. Target devices, not users — kiosk fleets enroll without user affinity, so user-group assignments never reach them.

The device locks to the app within moments of the policy applying. Removing the assignment (and the device syncing) is the only exit.

Verification

• Watch a pilot device take the policy: within moments of a sync it should snap into the app, with the home gesture and app switcher dead.
• Reboot it: the device must boot straight back into the locked app — surviving restarts is the point of SAM.
• Prove the exit path before shipping units: remove the pilot device from the assignment group (or unassign the profile), force a sync, and confirm the device returns to a normal home screen. A kiosk you can't unlock in the lab is a kiosk you can't unlock in the field.

Supporting Policies for a Kiosk Fleet

Bundle these in a kiosk-specific restrictions profile:

Autonomous Single App Mode

For exam/clinical apps that lock themselves: Settings catalog > Restrictions > Autonomous Single App Mode Permitted App IDs — add the vendor's bundle ID(s). The app handles enter/exit via its own UI.

Multi-App "Kiosk"

iOS has no true multi-app kiosk. The accepted pattern: no-affinity supervised device + Home Screen Layout (pin the allowed apps) + restrictions hiding everything else (block App Store, Safari if unneeded) + Block app removal. It's a curated device, not a locked one — set expectations accordingly.

Next: Insights

Official Microsoft docs: iOS/iPadOS device restrictions

• Plan the exit before the entrance. Leaving SAM requires the device to receive a policy change — which requires working Wi-Fi and APNs. A kiosk on a captive-portal network that dropped its session is a brick until someone gives it network. Validate connectivity health before assigning App Lock, and keep a bench procedure (wipe via ADE) for the stragglers.
• Deploy the app before the lock. If App Lock lands first, the device locks to... nothing useful. Stage assignments: app to the device group, confirm install, then the App Lock policy. For new batches, bake a soak delay into your process.
• App updates restart the app. VPP auto-updates apply under SAM, and the app relaunches. For 24/7 signage, that's a brief flicker; for a POS mid-transaction it's a support call. Schedule-sensitive fleets should stage app updates deliberately (pin versions, update in maintenance windows).
• A crashed kiosk app = black screen. The device is fine; the app isn't running. The Restart device remote action (supervised) is your first-line fix — wire it into a bulk action script for fleet-wide overnight restarts. Weekly scheduled restarts prevent most of it.
• Disable auto-lock, or the whole fleet goes dark on schedule. It's an App Lock option, and the #1 forgotten setting — every display sleeps at the default interval and stays that way until someone touches it. Pair with guided brightness for signage longevity, and remember always-on displays cook batteries — keep units on quality power.
• Name devices for humans on the floor. KIOSK-LOBBY-NORTH on a label and in Intune turns "the iPad by the door is frozen" into a 30-second remote restart.
• Temporary Sessions vs SAM: if users need to do anything beyond the one app — even occasionally — a Shared iPad with Temporary Sessions may fit better than fighting SAM's absolutism.

Official Microsoft docs: iOS/iPadOS device restrictions

Single App Mode locks a device to one app by policy; Autonomous Single App Mode (ASAM) hands the keys to the app itself — a whitelisted app may enter and exit single-app lock programmatically, on its own logic. The difference sounds subtle and changes the use cases entirely.

The Model

Your configuration profile names the bundle IDs permitted to self-lock; the app (built against the relevant API) then locks the device when its workflow demands and releases when done. The device isn't a kiosk — it's a normal supervised iPad that becomes one for the duration of an exam, a transaction, or a procedure.

Where ASAM Is the Right Tool

• Assessment and testing: the canonical case — the exam app locks at test start, releases at submission; the device serves the whole class day normally otherwise
• Point-of-sale and payment moments: the register app confines during transactions on a device that also runs inventory and email
• Clinical and procedure workflows: a charting/procedure app that owns the screen during the sterile window, by its own state machine
• The pattern in one line: periodic confinement on a multi-purpose device — versus full kiosk mode for dedicated appliances and Guided Access for ad-hoc human-supervised moments

Prerequisites

• Supervised devices (the universal rule) — ASAM payloads are ignored on unsupervised hardware.
• The app deployed and installed first — an allowlist entry for an app that isn't on the device grants nothing.
• An app actually built for ASAM. The app itself must call the autonomous lock APIs; the app vendor's documentation defines the contract. ASAM only works for apps built for it, so the procurement question "does your app support autonomous single app mode" belongs in the RFP, not the deployment week.

Step-by-Step

1. Collect the exact bundle ID(s) from the vendor's documentation. The allowlist matches identifiers, not app names — character-exact or it silently does nothing.
2. Create the profile. The allowlist rides the custom/settings-catalog surface: Settings catalog > Restrictions > Autonomous Single App Mode Permitted App IDs, adding each permitted bundle ID.
3. Assign to the device group that runs the workflow and let the devices sync.

Verification

Run the app's own lock workflow on a pilot device: start an exam, transaction, or procedure and confirm the device confines itself (home gesture dead, app switcher gone) — then complete the workflow and confirm it releases. The release test matters more than the lock test; an app that locks and never releases is the failure mode you will meet in production.

Insights

• Troubleshooting ASAM is mostly state confusion: a device "stuck in kiosk" is usually an app that locked and crashed/never released — force-quit paths and the vendor's release behavior belong in the runbook, and the device-side logs name the locking bundle in seconds.
• Audit the allow-list annually like any standing trust list: every bundle ID that may seize the screen is a small standing grant — keep it to the apps that still earn it.

Official Microsoft docs: iOS/iPadOS device restrictions

Lost Mode is the supervised-only remote action that turns a missing device into a locked beacon: a full-screen message with your contact info, all notifications silenced, and — uniquely — location lookup becomes available to IT while the mode is active.

Requirements

• Supervised device (ADE) — this is a corporate-device capability; BYOD/user enrollment has no Lost Mode
• Device reachable via APNs (online at some point — the command queues)

Enable It

1. Devices > select the device > ... (or the action bar) > Lost mode > Enable.
2. Provide:
   • Message: e.g. "This device belongs to Contoso. Please call IT."
   • Phone number: tappable from the lock screen
   • Optional footnote text
3. The device locks immediately on receipt — whatever the user was doing ends.

While Lost Mode Is Active

• Locate device action returns the device's location on a map in the Intune console. Outside Lost Mode, location is not available for standard corporate devices — this is the privacy boundary working as designed (location requests are audit-logged).
• Play Lost Mode sound action makes the device emit a persistent tone — couch-cushion recovery.
• The device is unusable: no notifications, no apps, just your message.

Disable It

Same device blade > Lost mode > Disable. The device unlocks back to normal (passcode still applies). If the device is gone for good, escalate: Wipe — and handle Activation Lock properly so the hardware remains recoverable.

Official Microsoft docs: Remote device actions

Activation Lock ties a device to the Apple Account that enabled Find My. Brilliant anti-theft for consumers; for fleets it's the classic failure mode: an employee signs in with a personal Apple ID, leaves the company, and the returned iPhone demands their password at activation. Without a plan, that hardware is scrap.

The Managed Approach (Supervised Devices)

Intune gives you three layers — use all of them:

1. Control who can enable it

Settings catalog > Restrictions > Allow Activation Lock: Block on supervised corporate devices. Users can still use Find My features; the device just doesn't bind to their personal account.

If business needs require Activation Lock (high-theft field environments), prefer device-based Activation Lock managed by the org rather than user Apple IDs.

2. Bypass codes (your get-out-of-jail card)

For supervised devices, Intune automatically escrows an Activation Lock bypass code (device blade > Hardware). At the Activation Lock screen, leave the username blank and enter the bypass code as the password — the lock clears.

3. The Disable Activation Lock remote action

Device blade > Disable Activation Lock consumes the stored bypass code server-side. Run it before wiping a device headed for redeployment or return.

The Decommission Flow That Never Strands Hardware

1. Retrieve/confirm the bypass code exists (Hardware blade or Graph).
2. Disable Activation Lock action.
3. Wipe.
4. Device activates clean for the next user — or returns to ABM stock.

Official Microsoft docs: Remote device actions

App configuration policies push key/value settings into apps that support managed configuration (Apple's NSUserDefaults-based managed app config). It's how Outlook knows the user's address before first launch, how Defender onboards silently, and how LOB apps get their server URLs.

Two Channels — Pick the Right One

Create either under Apps > Configuration policies > Add.

Building a Managed-Devices Policy

1. Add > Managed devices, pick platform iOS/iPadOS, select the targeted app (it must already exist in Intune — usually your VPP app).
2. Settings format:
   • Configuration designer — friendly key/value editor; Microsoft apps surface known keys.
   • XML — paste a property list for apps whose vendors hand you raw plist config.
3. Add keys. Vendor documentation is the source of truth for key names — there is no discovery mechanism; apps read whatever keys they were coded to read.

Token Variables

Values can include Intune variables resolved per device/user at delivery:

On no-affinity devices, user tokens resolve empty — scope user-dependent configs to user-affinity devices.

Verifying It Worked

• App config has no user-visible footprint — the app simply behaves configured.
• Intune: the policy's Device install status shows delivery.
• If the app ignores the config: confirm the bundle ID matches exactly, the app actually supports the keys (vendor docs), and the app was restarted after the policy landed — most apps read managed config at launch only.

Official Microsoft docs: App management in Intune

App Protection Policies (APP, colloquially MAM) draw the security boundary around the data inside managed apps rather than the device. They're the reason "we don't manage personal phones" and "corporate data is protected on personal phones" can both be true.

What APP Controls

• Data egress: where org data can go — save-as targets, share-sheet destinations, cut/copy/paste boundaries, backup exclusion
• Access: PIN/biometric to open the app's work context, work-account requirement
• Conditional launch: automatic responses to risk — jailbreak detected → block and wipe org data; offline too long → block; OS too old → warn
• Selective wipe: remove org data from the apps, touch nothing personal

It applies to apps built with the Intune App SDK — all Microsoft 365 mobile apps, plus a large supported app list and your own wrapped/SDK-integrated LOB apps.

Enrollment State Targeting

One policy can target, or you can split policies by state:

Our recommended values live in the App Protection Baseline.

Deployment Notes

• Assign to user groups — APP follows the user across devices.
• APP activates when the user signs into a targeted app with their work account. No enrollment prompt, no Company Portal requirement on iOS (Authenticator handles broker duties where needed).
• Pair with the Conditional Access grant Require app protection policy so only protected apps can reach corporate data — details in Conditional Access.

Monitoring and the Wipe

• Apps > Monitor > App protection status: per-user, per-app check‑in state, policy version, flagged devices (jailbreak!).
• Offboarding: a selective wipe (Apps > App selective wipe) clears org data from a departing user's personal device — the respectful goodbye.

Official Microsoft docs: App protection policies

Web clips put a URL on the home screen with an icon, indistinguishable at a glance from an app. For intranet portals, ticketing systems, ESS/HR pages, and PWAs, a web clip is frequently the right "app deployment" — zero licensing, instant updates, nothing to package.

Deploy One

1. Apps > All apps > Add > app type Web link (under Other).
2. Configure:
   • Name — what appears under the icon (keep it short; iOS truncates)
   • URL — https:// destination
   • Icon — upload a square PNG (512×512 works well); skip it and you get an unloved default
   • Full screen: opens without Safari chrome — feels app-like, but no URL bar means no user navigation rescue; best for true web apps
3. Assign as Required (icon appears automatically) or Available (Company Portal self-service).

Behavior Worth Knowing

• Web clips deployed by MDM are managed: they're removed at retire/unenrollment and can be pinned in place with a Home Screen Layout policy.
• Authentication uses Safari's engine — with the Enterprise SSO plug-in deployed, Entra-protected sites open already signed in. This combination is what makes web clips feel like real apps.
• A PWA-capable site in full-screen mode gets you most of the "native app" feel for the cost of an icon and a URL.

Web Clip vs. Edge Managed Favorites

Use both: clip the flagship portal, stuff the rest into Edge's managed bookmarks.

Official Microsoft docs: App management in Intune

Most iOS apps reach devices one of two ways: public App Store titles, or sideloaded line-of-business IPAs you sign yourself. Custom Apps are a third path. A developer (a vendor or your own team) publishes the app privately to your organization in App Store Connect, and it then appears in your Apps and Books in Apple Business Manager as a licensable, device-assignable app — vetted through App Review, installed through the store, and updated automatically — but invisible to the public. This avoids the enterprise-certificate signing and re-signing lifecycle that sideloaded IPAs require.

How distribution flows

The developer designates your organization (by ABM Organization ID) as the private audience in App Store Connect. Once the app clears App Review, it surfaces in your ABM Apps and Books, you acquire licenses, and the VPP token sync brings it into Intune as an assignable app.

Step-by-step: from contract to installed app

1. Give the developer your ABM Organization ID. Find it in Apple Business Manager under Settings > Enrollment Information > Organization ID. The developer enters it as the app's private audience in App Store Connect (Pricing and Availability > Distribute on Apple Business Manager / custom app). This audience setting lives entirely on the developer's side — handing over the ID is the whole integration.
2. Acquire licenses in ABM. Once the app passes App Review it appears in Apps and Books, visible to your organization only. Buy the quantity you need (free apps still require a license "purchase") under the same location whose VPP/content token Intune already holds.
3. Sync the token in Intune. Go to Tenant administration > Connectors and tokens > Apple VPP Tokens, select the token, and choose Sync (or wait for the scheduled sync). The app and its license count appear under Apps > iOS/iPadOS.
4. Assign and deploy. Open the app, go to Properties > Assignments, and assign it as Required with device licensing for corporate devices. Updates continue to flow through the store with no re-signing schedule to maintain.

When to use this lane

• Vendor-built apps for your organization — an agency-built field app, a white-labeled portal. Custom Apps is the channel Apple intends for this; a vendor offering to "send you an IPA" in current iOS is worth pushing back on.
• Your own apps with a store-compatible release cadence — App Review adds a few days but provides the automatic update pipeline and removes the signing-certificate expiry that strands sideloaded apps.
• Sideloaded LOB IPAs remain the option for what genuinely cannot go through review — rapid-iteration internal tools and functionality App Review would reject. Treat it as the deliberate exception, not the default.

Operational notes

License management is ordinary VPP: the same license pools and the same reclaim-on-retire hygiene. The usual onboarding failure is that the app never appears in your Apps and Books — almost always because the developer's private-audience setting does not match your ABM Organization ID. It is a developer-side fix; confirm the ID they used against Settings > Enrollment Information in ABM.

Insights

• Put Custom Apps into your procurement language: require that "iOS deliverables are distributed via Apple Custom Apps to our ABM Organization ID." One contract line removes every future conversation about enterprise certificates, expiring provisioning profiles, and re-signing.

Official Microsoft docs: App management in Intune

iOS classifies every app on an enrolled device as managed (installed or assigned by Intune/MDM) or unmanaged (installed by the user). The managed open-in controls govern whether documents, contacts, and clipboard content can cross that line. This predates App Protection Policies (APP) and still applies on enrolled — especially supervised — devices, so you need to know how the two interact to avoid both gaps and conflicting double-blocks.

The two restriction settings

In a Device restrictions profile (Devices > Manage devices > Configuration > Create > iOS/iPadOS > Templates > Device restrictions), under Apps:

• Require managed apps to share data only with other managed apps (block managed → unmanaged): a corporate document opened in managed Outlook cannot be handed to a user-installed PDF reader. The iOS share sheet simply omits unmanaged destinations.
• Require unmanaged apps to share data only with other unmanaged apps (block unmanaged → managed): personal content cannot flow into the corporate context. Enforce this only where ingestion of unvetted content is a real concern; it is the less common of the two.

Supporting controls in the same profile: the managed contacts/calendar boundary (block managed apps from writing contacts to unmanaged accounts), the managed pasteboard (clipboard honors the same managed/unmanaged line), and the AirDrop restriction covered on the AirPlay and Continuity page (treat AirDrop as an unmanaged destination). Together these form a device-level data perimeter defined by which apps Intune installed.

Open-in vs App Protection Policies

The two mechanisms solve different problems and target different fleets:

On corporate supervised fleets, open-in is the inexpensive OS-level floor and APP is the precision layer on top. On BYOD without enrollment, open-in does not apply at all — APP is the only data boundary you have. The common misconfiguration is running both on enrolled devices with rules that disagree, producing reports of "sharing works from Outlook but is blocked from Teams." Keep one written data-flow matrix — which source apps may hand documents to which destination apps — and re-audit both the restriction settings and the APP data-transfer settings against it whenever either changes.

Insights

• For any "can't open this document" ticket, identify the control before touching policy. A share sheet that is missing destinations is managed open-in. An in-app "your organization does not allow this" dialog is App Protection Policy. The two live in different profiles, so naming which one fired tells you which policy to open.

Official Microsoft docs: App management in Intune

A compliance policy is the contract: devices meeting it are marked compliant, and Conditional Access uses that mark as a gate to corporate resources. Configuration policies set device state; compliance policies judge it.

Create the Baseline Policy

Devices > iOS/iPadOS > Compliance > Create policy:

Device Health

Device Properties

System Security

Mirror these with your passcode configuration policy — config asks, compliance enforces.

Actions for Noncompliance

Per policy, sequence the consequences:

1. Mark device noncompliant: Immediately for jailbreak; consider a 3–7 day grace for OS-version misses so users see warnings before lockout.
2. Send email to end user (day 0): use a notification template that says exactly how to fix it.
3. Optionally Retire at 30+ days for chronically noncompliant BYOD.

Tenant-Wide Defaults That Matter

Devices > Compliance > Compliance policy settings:

• Devices with no compliance policy assigned: set to Not compliant — otherwise unpoliced devices ride free.
• Compliance status validity period: default 30 days; devices that stop checking in fall noncompliant when it lapses.

Monitoring

Devices > Monitor > Noncompliant devices; per-policy per-setting drill-downs show exactly which check failed. The complianceState property is also in our inventory report script.

Official Microsoft docs: Device compliance

Benchmarks & Frameworks for iOS/iPadOS

A compliance policy enforces consequences, but it doesn't tell you which controls to demand in the first place. For that, iOS/iPadOS leans on the same external authorities as the Mac — with one blunt caveat up front: Microsoft does not publish a security baseline for iOS or iPadOS. Microsoft's importable security baselines are Windows-only. There is no "iOS baseline" tile in Intune the way there is for Windows. The authoritative iOS controls come from CIS, Apple Platform Security, and — for the app/data layer — Intune's own App Protection Framework. Treat anyone who tells you "just import the Apple baseline" as someone who hasn't deployed one.

CIS Apple iOS/iPadOS Benchmark

CIS ships a benchmark per major release — currently iOS 26 (v1.0.0), iOS 18 (v2.0.0) and iOS 17 (v1.1.0), with matching iPadOS 26 / 18 / 17 documents. Unlike the desktop benchmarks, the iOS document is organized around what an MDM-managed, supervised device can actually enforce — passcode policy, restriction payloads, network and Safari hardening, AirDrop/handoff controls, update behavior. The practical translation: a CIS iOS recommendation almost always maps to either a Settings Catalog/restriction payload you push, or a property your compliance policy on this page checks. Supervision is the dividing line — a large share of the benchmark's higher-value restrictions only apply to supervised (ADE-enrolled) devices, so a BYOD fleet can satisfy far fewer CIS items than a corporate-owned supervised one. Scope your audit claims to your enrollment model.

Apple Platform Security

Where CIS tells you what to set, the Apple Platform Security guide documents why the platform can be trusted — the Secure Enclave, hardware-backed key storage, Data Protection class keys tied to the passcode, Face ID/Touch ID, and the secure boot chain. This is the evidence layer for the controls your compliance policy can't directly toggle: when you require a passcode and block jailbroken devices, you're relying on Apple's hardware enforcement to make those requirements meaningful. Cite it in your control narrative rather than treating "encryption" and "jailbreak detection" as self-evident.

Intune App Protection Framework (the app/data layer)

For unmanaged or BYOD iPhones — and for defense-in-depth on managed ones — the device-level benchmark isn't reachable, so the control surface shifts to the data inside the apps. Microsoft's App Protection Framework (the data-protection configuration framework) is the closest thing to an official iOS hardening baseline, expressed as three escalating levels applied through App Protection Policies:

1. Level 1 — enterprise basic data protection. The minimum: require an app PIN, encrypt org data, enable selective wipe. Mirrors the defaults when you create an App Protection Policy and replaces basic Exchange Online device-access rules.
2. Level 2 — enterprise enhanced data protection. The recommended standard for most users handling sensitive data: restricts data transfer to policy-managed apps, blocks backup of org data, sets a minimum OS version. Some user-experience impact.
3. Level 3 — enterprise high data protection. For high-risk users and sophisticated security teams: tighter PIN complexity (6-digit, no simple PIN), blocks third-party keyboards, adds Mobile Threat Defense via "max allowed threat level," and constrains the dialer. Significant user impact — ring it carefully.

The levels are cumulative (L2 includes L1, L3 includes L2) and Microsoft recommends a QA → Preview → Production ring rollout — the same discipline you'd give any baseline change. App Protection works with or without enrollment, which is exactly why it carries the iOS data-protection story where MDM restrictions can't reach.

Operationalizing It

1. Set the controls with restriction/Settings Catalog payloads tailored to the CIS iOS benchmark for your OS version — and be honest about supervised vs. BYOD scope.
2. Judge the state with the compliance policy on this page (passcode, OS floor, jailbreak block, threat level) — configuration sets, compliance judges.
3. Protect the data with the App Protection Framework level matched to the user's risk tier, gated by Conditional Access.
4. Re-baseline per major iOS release — CIS reissues the benchmark each year, and the App Protection minimum-OS values track Apple's N-1 support window.

Official references: CIS Apple iOS/iPadOS Benchmarks · Microsoft Intune App Protection / Data Protection Framework · Apple Platform Security guide

Conditional Access (CA) is the enforcement engine in Entra ID. Intune supplies device compliance and app protection signals; CA turns them into access decisions. Without CA, a noncompliant device is just a sad dashboard entry.

The Two Grants That Matter for iOS

The classic iOS policy uses "Require one of the selected controls" with both — corporate devices satisfy via compliance, BYOD satisfies via APP, everything else is blocked.

A Sane Starter Policy Set

1. Block legacy authentication — all users, all apps, legacy auth clients: Block. (Old protocols bypass everything else here.)
2. Office 365 on iOS requires managed access
   • Users: all (exclude break-glass accounts)
   • Apps: Office 365
   • Conditions > Device platforms: iOS
   • Grant: require compliant device or app protection policy
3. MFA everywhere — your standing all-apps MFA/phishing-resistant policy applies to iOS sign-ins automatically; Setup Assistant modern auth during ADE honors it too.

Build in Report-only mode first; review the sign-in log impact for a week before flipping on.

Insights

• Always exclude break-glass accounts. A CA policy that locks every admin out of a tenant during an Intune outage is a story you only get to tell once.
• The What If tool (Entra > Conditional Access) answers "why is this user blocked" faster than any forum thread.
• Sign-in logs (Entra > Sign-in logs > Conditional Access tab per event) show exactly which policy applied, which grant failed, and the device's compliance claim — first stop for any access ticket.
• Newly enrolled devices can take a few minutes to present as compliant (first check‑in + Entra registration). The Enterprise SSO plug-in's JIT registration shrinks this window dramatically.

Official Microsoft docs: Conditional Access overview

Managed Device Attestation (MDA) first shipped on iOS and iPadOS, and it changes what device identity means in a management system: instead of services trusting what the enrollment record asserts, they verify what the hardware can cryptographically prove.

The Problem It Ends

Classic device identity is assertion: the MDM record claims serial X, the device presents a certificate someone could theoretically exfiltrate, and services trust the paperwork. MDA replaces the paperwork with silicon: the Secure Enclave generates hardware-bound keys (non-exportable by construction), and Apple's attestation servers vouch — cryptographically — that the request comes from a genuine, specific Apple device with the properties it claims. A cloned identity can't complete the handshake; there's no Enclave behind it.

The Mechanics in Brief

The ACME payload (the modern issuance protocol with attestation extensions) carries the flow: the device requests an identity, an Enclave-bound key plus Apple's attestation accompany the request, and the issuing CA enforces certificates only for proven hardware. Those identities then underpin the things that matter — 802.1X, VPN, MDM client identity — with private keys that physically cannot leave the device. SCEP remains the workhorse for the long tail; ACME-with-attestation is where high-assurance identity is heading, and PKI readiness — does your CA speak ACME, and can it consume attestation evidence? — is the gating project to scope first.

Two properties worth holding onto when you design around it. First, the attestation speaks to identity and genuineness — this specific, genuine Apple device with these identifiers — which is exactly the claim a stolen or cloned certificate cannot fake. Second, attestation evidence is produced at issuance and renewal, not continuously; its freshness is bounded by your certificate rotation cadence, so pick lifetimes with that trade-off in mind rather than treating the attestation as a live health feed.

Where It Touches Compliance

Attestation-grade signals strengthen the compliance + Conditional Access loop at its root: the difference between "a device claiming to be enrolled iPhone-4821" and "hardware-proven iPhone-4821." As management platforms surface attestation-backed checks, the posture conversation shifts from what the device reports to what the silicon proves — the strongest foundation a compliance signal can stand on, because every downstream decision inherits the quality of the identity underneath it.

Insights

• The security-review one-liner that lands: "What stops a stolen device certificate from impersonating a corporate iPhone? On attested identities — physics. The key never existed outside the Secure Enclave." That sentence is the entire ROI.

Official Microsoft docs: Device compliance

Work top-down from the symptom. First stop in every case: Intune > Devices > Monitor > Enrollment failures — filter to iOS and check whether the attempt even reached Intune.

"No Remote Management screen" (ADE device sets up like a personal device)

The device isn't being told it's yours. In order:

1. Is the serial in ABM? Search it in ABM > Devices. Retail-bought devices aren't there until you add them.
2. Assigned to the right MDM server? The serial must be assigned to your Intune server entry in ABM.
3. Synced to Intune? Check the token blade's device list; trigger a sync and respect the 15-minute rate limit.
4. Enrollment profile assigned? A synced serial with no profile still activates unmanaged. Set a default profile on the token.
5. Device was already activated before the assignment? Wipe it — ABM assignment is evaluated at activation.

"Unable to complete enrollment" during Setup Assistant sign-in

• CA blocking enrollment: a Conditional Access policy requiring a compliant device on the enrollment/registration flow is a chicken-and-egg lock. Review sign-in logs for the user; exclude the Intune enrollment cloud apps appropriately.
• License missing: user has no Intune license — instant, unhelpful failure.
• Enrollment restriction: ADE counts as corporate, but check Enrollment device platform restrictions for OS-version blocks.
• MFA method unavailable: Setup Assistant modern auth presents the full Entra sign-in — a user with no registered MFA method and a require-MFA policy stalls here.

"Profile installation failed" (web/profile-based flows)

• An old management profile already exists: Settings > General > VPN & Device Management — remove stale profiles, or wipe.
• Time skew: a wildly wrong device clock breaks the TLS chain — set automatically.
• Network filtering: see APNs Connectivity for the inspection-breaks-Apple checklist.

Account-driven enrollment dies at the email step

• The /.well-known/com.apple.remotemanagement discovery endpoint isn't reachable/valid for the user's UPN domain — curl it from outside your network; expect 200 + correct JSON.
• The user's targeted profile type doesn't match the OS (account-driven device enrollment needs iOS 18+).
• No Managed Apple Account resolvable: check ABM federation status for the domain.

"Device appears enrolled but gets no policy"

Almost always Entra device registration didn't complete — the Intune object exists, CA sees an unregistered device. Have the user launch Company Portal and sign in (or verify JIT registration / SSO plug-in reached the device), then sync.

Official Microsoft docs: Intune troubleshooting hub

Intune never talks straight to an iPhone. Every action follows the same path: Intune → Apple Push Notification service → device wakes → device checks in to Intune over HTTPS. Break any hop and the fleet looks "dead" while being perfectly healthy.

Symptoms That Mean "Check APNs"

• Remote actions stuck at Pending fleet-wide
• Devices only sync when a user manually opens Company Portal
• Everything broke at once across all Apple platforms (the giveaway)

Checklist, in Order

1. The certificate

Devices > Enrollment > Apple tab > Apple MDM Push certificate — status Active, not expired? An expired cert stops everything; renew correctly (same Apple ID!) and devices recover on their own. Automate the watch with the expiry check script.

2. The network path (device side)

Devices need a direct connection to APNs:

• TCP 5223 to 17.0.0.0/8 (Apple's block), falling back to TCP 443 on some networks
• No TLS/SSL inspection on Apple traffic — APNs uses certificate pinning; an inspecting proxy kills the connection silently. This is the #1 root cause in enterprises.
• Captive portals: a kiosk Wi-Fi whose session expired = no push. Use PSK/802.1X networks for unattended fleets.

Test from the device's actual network segment (guest Wi-Fi working proves nothing about the kiosk VLAN).

3. Apple's side

Rare, but check the Apple System Status page for APNs incidents before burning an afternoon.

4. Single-device weirdness

One device unresponsive while peers are fine: toggle Wi-Fi/airplane mode (forces a new APNs connection), verify the management profile still exists, and as a last resort re-enroll.

What APNs Does Not Carry

Push only carries the "wake up and check in" nudge — policies, apps, and inventory all move over standard HTTPS (443) to Intune. A device that can be nudged but fails to sync has an HTTPS/proxy problem to *.manage.microsoft.com instead, which is a different firewall conversation.

Official Microsoft docs: Intune troubleshooting hub

iOS isn't a black box; the evidence just lives in different places than you're used to.

Company Portal Logs (first line)

1. On device: Company Portal > menu > Send Logs (also reachable via Settings > Company Portal > toggle verbose logging first for richer output).
2. The upload produces an incident ID — that ID lets Microsoft support pull the logs; have users screenshot it into the ticket.
3. Covers: enrollment flow, sync, Entra registration, app install orchestration as CP sees it.

The Intune Console (second line)

• Device blade > Device configuration / Compliance: per-profile, per-setting status with error codes — most "policy didn't apply" answers live here.
• Apps > the app > Device install status: VPP failures show distinct errors for no license vs App Store unreachable vs user declined (unsupervised).
• Tenant administration > Audit logs: who did what, including remote actions — your evidence trail.
• Troubleshooting + support pane: per-user rollup of devices, policies, app installs — the fastest helpdesk view in the product.

Settings on the Device (ground truth)

Settings > General > VPN & Device Management > the management profile shows every payload, restriction, and certificate the device actually has. If the console says delivered and the device disagrees, the device is right — sync and investigate the gap.

Unified Log Streaming and sysdiagnose (deep cuts)

For enrollment cryptography failures, SSO extension behavior, or anything you're escalating to Apple/Microsoft engineering:

1. Stream the device's unified log during a repro. Tether the device over USB to an admin workstation running Apple's Console log viewer, select the device in the sidebar, and stream — filter subsystems for the loud, honest mdmd/profiled messages while you reproduce the failure.
2. Or capture a sysdiagnose on-device (volume buttons + side button chord, then Settings > Privacy & Analytics > Analytics Data) for the full archive Apple support will ask for anyway — no tethering required.

One streamed Console session during a failing enrollment usually names the actual problem — a profile rejection reason, a TLS failure, an SSO extension crash — in plain text.

What to Put in Every Escalation

Serial number, Intune device ID, UPN, timestamp of the repro (with timezone), CP incident ID, and what the device's VPN & Device Management screen showed. That set turns a ping-pong ticket into a one-pass fix.

Official Microsoft docs: Intune troubleshooting hub

App installs on iOS fail quietly — usually no user-visible error at all, just an absent icon and a ticket. Work this ladder top to bottom; the culprit is almost always in the first three rungs.

1. Licenses (the #1 cause)

A VPP app with 0 available licenses fails silently, every time, fleet-wide for new devices. Check the app's license counts in the portal or run the VPP License Report. Fix: raise the quantity in ABM (free apps included), sync the token, installs resume on next check‑in.

2. Storage

Devices under ~1–2 GB free routinely fail app installs and OS updates. The inventory report surfaces FreeStorageGB — under-provisioned 64 GB fleets generate this ticket forever. Short-term: clear space; long-term: buy bigger.

3. Token / region mismatches

• The app was licensed under a different VPP location than the token Intune holds — license counts look fine in ABM, Intune sees zero.
• Country mismatch: VPP location country ≠ the app's availability in that storefront — the app simply can't be granted.
• Token in a failed sync state (connector health check catches this).

4. Delivery channel

• Device offline / APNs blocked → install command never arrives. One device: toggle network, sync. Many devices: APNs Connectivity.
• Unsupervised devices prompt the user to approve App Store installs — "failed" sometimes means "user hit Cancel." Supervised devices install silently; this entire class disappears with ADE.

5. App-specific oddities

• Update loops ("installing…" forever): usually a stuck prior install — remove the app assignment for that device's group momentarily or wipe the app via device blade, resync.
• LOB (IPA) apps: expired provisioning profile or missing device UDID in an ad-hoc profile — check the app's expiration in Intune and re-sign annually.
• OS minimum: the app's deployment target exceeds the device's iOS version — shows as not applicable/failed on stragglers; your update enforcement is the real fix.

Evidence to Collect

Per-app Device install status in the portal (or the status report script) gives state + detail per device; the device-side truth is Settings > General > VPN & Device Management > the management profile > Apps — if Intune says installed and the device disagrees, sync and re-check before deeper surgery.

Official Microsoft docs: Intune troubleshooting hub

A configuration profile "not working" is three different failures wearing one symptom: it never arrived, it arrived and was rejected, or it installed and the payload's dependencies are unmet. Walk them in order.

Rung 1 — Did It Arrive?

Targeting and transport first, as always: assignment/filter scope, then APNs and sync health — a device that can't hear commands installs nothing, and that's a connectivity ticket, not a profile ticket. Device-side, Settings > General > VPN & Device Management shows what's actually present; absence after a healthy sync points back at scope.

Rung 2 — Was It Rejected?

The OS validates payloads on install; rejection causes cluster tightly:

• Conflicting payloads: two profiles claiming the same exclusive territory (duplicate identifiers, competing single-instance payloads). Give every exclusive setting exactly one profile home — when two claim it, the device resolves by rejection or an arbitrary winner, and both read as "profile failed"
• Supervision-gated payloads on unsupervised devices: the payload requires supervision the device lacks; the fix is the enrollment path, not the profile
• Malformed custom profiles: hand-built .mobileconfig with schema errors — validate in the lab on a test device before fleet assignment, every time
• OS-version mismatches: payload keys newer than the device's OS fail quietly or partially — the annual OS-validation pass exists for this

Rung 3 — Installed but Inert

The profile shows present; the behavior doesn't — almost always a dependency: the Wi-Fi profile whose certificate hasn't issued yet (sequence assignments), the SSO payload waiting on its app, the filter payload whose provider app isn't installed. Map the profile's dependency chain and check each link — the profile is fine; its prerequisites aren't.

Insights

• Fleet-level reading beats device archaeology: per-profile deployment status grouped by error, sliced by OS/model/enrollment type — a cohort failing one payload shares an attribute, and the attribute is the answer.
• Keep a known-good minimal profile (one harmless restriction) as the probe: if it installs on a problem device, transport and trust are fine and the investigation narrows to the real profile's content in one move.

Official Microsoft docs: Intune troubleshooting hub

A device sitting behind its DDM software-update enforcement usually isn't broken. Four things cause it, and only the last is a genuine malfunction — so check them in order, cheapest first, before you reach for a device.

1. The deadline hasn't passed yet

A DDM update has a target version and an enforcement deadline. A device inside that window is behaving correctly — it isn't late until the deadline is. Confirm two things before calling anything stuck:

• Today vs the deadline. Open the update policy and compare its enforcement date to now. Inside the window = working as designed.
• The declaration actually reached the device. Enforcement only applies once the device received the declaration, which needs a successful sync — a device that hasn't checked in hasn't heard the deadline. Work APNs / sync health first.

2. The device can't take the target version

Two hard blockers, both visible in inventory before you touch the device:

• Hardware too old. The model doesn't support the target iOS/iPadOS major. Keep a model → last-supported-OS list and treat these as a refresh-planning item, not a ticket.
• Not enough storage. The update payload needs free space (commonly several GB); 64 GB devices are the usual offenders. The device inventory report exposes free-storage and model columns so you can pre-sort the fleet and clear space (offload unused apps, clear caches) before the deadline.

3. The conditions for an automatic install are never met

iOS installs updates when the device is on power, on a good network, and idle (typically overnight, charging, on Wi-Fi). When those never coincide the update never starts:

• The handset that's never charged overnight — installs have no window.
• The cellular-only device avoiding a multi-gigabyte download over a metered link.
• The kiosk that's never idle. DDM tightens the prompt as the deadline nears, but if the conditions are structurally absent, fix the conditions (charging habit, Wi-Fi access) — that's not an MDM problem.