Intune Wipe vs Fresh Start vs Retire

by David | Sep 29, 2026 | Intune

Someone on the helpdesk asked me "should I just wipe it" about a laptop heading back into the pool for a new hire. I asked what they actually wanted to happen after. They didnt know there was a difference. That conversation is basically why this post exists. Intune wipe vs Fresh Start trips people up constantly, and picking the wrong one costs you real time later.

Intune wipe vs Fresh Start vs Retire: the short version

• Wipe, full factory reset, removes everything, device goes back to out of box experience
• Fresh Start, removes manufacturer bloatware and reinstalls Windows, can optionally keep user data and enrollment
• Retire, removes company data and unenrolls the device, but leaves personal files and the OS alone
• Autopilot Reset, wipes user data but keeps the device enrolled and Entra joined the whole time

Each one solves a different problem. Grabbing the wrong one is how you end up re-imaging a machine that just needed a lighter touch. Or handing off a "wiped" laptop that still has someone's personal files sitting on it.

Wipe: the full factory reset

Wipe restores a Windows device to factory settings. All data, apps, and settings get removed. Once it finishes, the device sits at the out of box experience screen, ready for whoever unboxes it next.

The three wipe options

• Wipe device, but keep enrollment state and associated user account, resets the device but keeps it enrolled in Intune. MDM policies get removed, the device itself stays registered.
• Wipe device, and continue to wipe even if device loses power, the nuclear option. Overwrites free space so nothing's recoverable. Built for lost or stolen devices, but it can leave a device unable to boot again if the wipe gets interrupted.
• No options selected, the default full wipe. Removes MDM enrollment along with everything else.

Does Wipe remove BitLocker?

Not in the sense of stripping the encryption off cleanly. A wipe destroys the underlying data as part of the factory reset, so the question mostly stops mattering. With the "continue to wipe even if device loses power" option specifically, watch out. Microsoft's own troubleshooting docs warn that BitLocker encrypted devices can fail to restart afterward. If that happens, you're looking at bootable media and a manual Windows reinstall, not a quick fix.

This is different from what happens on Retire, which I'll get to in a second. Retire actively suspends BitLocker and removes key protectors because it leaves the disk intact. Wipe doesnt need to bother, since the reset itself makes the old data unreadable anyway.

Does Wipe remove Autopilot registration?

No, and this one catches people off guard. Wiping a device doesnt touch its Windows Autopilot registration at all. The hardware hash stays registered to your tenant. That's actually useful. It means a wiped device runs straight back through your Autopilot deployment profile on next boot instead of landing on a generic setup screen.

If you genuinely want the device gone from Autopilot too, that's a separate manual step. Go to Devices > Enrollment > Windows Autopilot > Devices, find the device, and deregister it there. Wipe and Autopilot deregistration are two different actions, not one.

Fresh Start: cleaning without starting completely over

Fresh Start reinstalls the latest version of Windows and strips out whatever bloatware the manufacturer shipped with it. Unlike Wipe, it gives you a real choice about what survives.

Select Retain user data on this device and the machine stays Entra joined. It automatically re-enrolls in Intune once a licensed user signs back in. It also keeps the contents of the user's home folder while clearing out apps and settings. Skip that option and the device drops all the way back to a fresh OOBE completed state, keeping only the built in local administrator account. BYOD devices get fully removed from Entra ID and Intune in that case.

Fresh Start is the one to reach for when a machine feels sluggish or cluttered. You dont actually want to lose the person's files or start enrollment over from scratch.

Retire: pulling company data off, nothing else

Retire unenrolls a device from Intune and strips out managed apps, profiles, and settings, but it leaves personal files completely alone. This is the one built for BYOD, when someone's leaving the company and its their own phone or laptop.

Does Retire touch BitLocker?

Yes, and this is worth knowing before you click it. If you retire or delete an Entra joined device thats BitLocker protected, Intune triggers a sync. That sync removes the key protectors and suspends BitLocker on the OS volume. Microsoft does this on purpose, to avoid leaving a device stuck encrypted with no recovery path once its Entra object disappears. Back up the BitLocker recovery key and any local admin credentials before you retire a device, just in case.

Autopilot Reset: the one people forget exists

Autopilot Reset wipes user data, settings, and apps, then reapplies your original Autopilot configuration automatically. Wi-Fi profiles, region, and keyboard settings survive the reset. The device stays enrolled in Intune and joined to Entra ID the entire time, no re-registration needed.

This is the fast option for repurposing a device between users inside the same organization. Think a shared classroom laptop going to a new student, or a desk machine getting reassigned. It skips the reimaging step entirely.

Which one do you actually want

• Device leaving the org entirely, or going to service for repair: Wipe
• Machine feels cluttered but the same person keeps using it: Fresh Start, with retain user data checked
• BYOD device, employee's leaving, only company data needs to go: Retire
• Reassigning a corporate device to a new person inside your org: Autopilot Reset

Putting it together

Weighing Intune wipe vs Fresh Start vs Retire really comes down to one question: who's keeping the device, and what needs to survive on it. Wipe assumes nobody's coming back to it. Fresh Start assumes the same person is, just with a cleaner slate. Retire assumes the person's keeping the hardware but you're taking your data back. Autopilot Reset assumes the device is staying in your fleet, just changing hands. Match the action to that answer and you'll stop reaching for the nuclear option when a lighter touch would've done the job.

What can we learn as a person

I think about Retire a lot actually, the fact that it exists as its own separate action from Wipe. Somebody at Microsoft decided that removing yourself from something doesnt have to mean destroying the whole thing. You can pull your data back out, close your part of it cleanly, and leave the rest of the person's life untouched. Not everything needs the nuclear option just because it's ending.

I dont think we're always great at that distinction with our own endings. A friendship changes shape, and we either keep pretending its exactly the same, or we wipe it completely and never speak again. There's rarely a Retire option in how we handle it. Something that lets us take our part back without torching everything the other person still has.

Where in your life are you reaching for Wipe when what the situation actually needed was Retire?

Further reading

• Device action: wipe
• Device action: retire
• Device action: Fresh Start
• Device action: Autopilot Reset
• Reset and wipe devices

What Is WIP? Windows Information Protection User Scope

by David | Sep 22, 2026 | Intune

Someone opened their Entra mobility blade and saw a setting called WIP user scope sitting next to MDM user scope. They asked me what it did. Fair question. The honest answer is a little sad. It's not much anymore. So what is WIP, why is that scope still staring at you, and should you touch it? Lets sort it out.

What is WIP?

WIP stands for Windows Information Protection. It's a lightweight, built-in Windows feature that separates corporate data from personal data on the same device. The goal was simple. Let people use one laptop for work and life without leaking company files into personal apps. No switching profiles or environments all day.

Under the hood, WIP tags and encrypts enterprise data and watches how apps move it around. It can also wipe just the company data off a personal device. The personal photos and apps stay untouched. That selective wipe was the party trick everyone liked.

The name it used to have

Before it was WIP, Microsoft called it Enterprise Data Protection, or EDP. You'll still trip over the old name in the plumbing. The configuration service provider that drives it is literally named EnterpriseDataProtection, and app resource files reference EDPAUTOPROTECTION. Same feature, older label.

The scope setting has its own naming history too. That blade in Entra used to be called Mobility (MDM and WIP). Microsoft later renamed it to Mobility (MDM and MAM), so depending on when your tenant was born, you might see either.

So what is the WIP user scope, specifically?

The WIP user scope decides which users get WIP autoenrollment applied to their Windows devices. It lives right next to MDM user scope in the same blade, and it takes the same three values.

• None, nobody gets WIP autoenrollment.
• Some, only members of the Entra groups you pick.
• All, every licensed user.

To find it: Microsoft Entra admin center > Mobility (MDM and MAM) > Microsoft Intune. WIP user scope sits in the same pane as MDM user scope. The idea was a split. MDM user scope enrolled the whole device. The WIP scope let you manage just the Windows apps and their data, no full enrollment needed.

Key features worth knowing

• Data separation without profile switching. Corporate and personal data live side by side, tagged behind the scenes.
• Encryption and selective wipe. Company data gets encrypted, and you can pull just the company data off a personal device on unenroll.
• Enlightened versus unenlightened apps. Enlightened apps know the difference between work and personal data. Unenlightened apps get treated as all-or-nothing.
• Two enrollment states. With enrollment means MDM manages the whole device. Without enrollment, called MAM, managed only the apps. The without-enrollment path is now deprecated, so you cant create new unenrolled WIP policies.

The four protection modes

This is the part that actually decides how WIP feels to your users. A WIP policy runs in one of four modes, from strict to off.

Microsoft's own advice was to start in Silent or Allow Overrides, confirm your protected app list is right, and only then tighten to Block. Jump straight to Block on day one and you'll spend the week fielding tickets from people whose normal work suddenly got denied.

Phones, laptops, and where WIP actually applied

WIP was always Windows only. It never ran on an iPhone or an Android device. If someone says they put WIP on their team's iPhones, they're confused. They mean App Protection Policies, the separate MAM feature for iOS and Android. Here's the honest matrix.

The part you cant skip: WIP is deprecated

Microsoft announced the sunset of WIP in July 2022. It still works on supported Windows versions, but it gets no new features. Microsoft removed it entirely starting in Windows 11 version 24H2. The without-enrollment flavor is already gone for new policies.

For anything new, Microsoft points you at Microsoft Purview Information Protection and Purview Data Loss Prevention, including Endpoint DLP. That's the modern path, and it's where the same data-separation job now lives. If you want the deeper story on what Purview can and cant see, I wrote about that in does Intune monitor your activity.

Putting it together

WIP is Windows Information Protection, formerly Enterprise Data Protection, and the WIP user scope in Entra just controlled which Windows users it autoenrolled. It ran in four modes from Block to Off, and it only ever touched Windows. For phones you were always using App Protection Policies instead. It's deprecated now, gone in Windows 11 24H2, and Purview DLP is the replacement. If you still see the scope in your tenant, leave it at None unless you have a specific legacy reason. Put your energy into the MAM and DLP tools that are still alive.

What can we learn as a person

The four protection modes stuck with me, because they're really a scale of how rigid you're willing to be. Block never bends. It stops everything it doesn't like, and users route around it or revolt. Off bends so completely it holds nothing up. The modes that actually worked in the real world were the ones in the middle, the ones that gave a little.

Skyscrapers do this on purpose. A tall building is engineered to sway in the wind, sometimes a few feet at the top. If it stood perfectly rigid, the force of the sky pushing on it would crack it and bring it down. The sway is not weakness. The sway is the whole reason it stays standing.

I've been Block mode with people I love. Firm on every rule, no override, and it didnt make me strong, it just made me brittle and made them route around me. But I've also been Off, so flexible about everything that I stopped holding anything up, myself included. The trick I'm still learning is the sway. Enough give to survive the pressure, enough spine to not fall over. So where in your life are you running in Block mode when the wind is asking you to sway a little?

Further reading

• Deprecated features for Windows client (WIP sunset)
• EnterpriseDataProtection CSP
• Learn about Microsoft Purview Data Loss Prevention
• Learn about Endpoint DLP

Android Enterprise Management Types, Without the Acronym Soup

by David | Sep 15, 2026 | Intune

A manager walked over to my desk holding a brand new Android phone and asked me to "put it in the business manager." I knew what they meant, sort of, but that phrase does not map to any single button in Intune. Android has a whole family of ways to run a device, and the words people use for them are a mess. Business manager, work profile, kiosk, COPE, COSU, fully managed. So lets untangle the Android Enterprise management types, figure out what each one actually does to a phone, and how you pick the right one before you hand hardware to a human.

First, the thing everyone calls "the business manager"

When someone says business manager, they almost always mean Managed Google Play. It is Google's enterprise app store, and it is the connection that makes every other Android option possible. You link your Intune tenant to a managed Google Play account once. After that, Intune can push apps, enforce policy, and enroll corporate devices.

You set it up under Devices > Enrollment > Android tab > Managed Google Play. As of August 2024 you can bind it with your Microsoft Entra account instead of a throwaway Gmail address, and that is the path Microsoft now recommends. The moment you connect, Intune drops five helper apps into your console automatically. Intune, Authenticator, Company Portal, Managed Home Screen, and Microsoft Launcher. You did not add them. They just show up because the plumbing needs them.

The Android Enterprise management types, in plain English

There are four live options, and they split cleanly on one question. Who owns the phone, and does the person get a personal side? Here is each one without the acronym soup.

• Personally owned work profile (BYOD). The employee owns the phone. Android creates a separate, walled-off work profile with its own apps and its own briefcase badge. You manage that container. You never touch their photos, their texts, or their personal apps.
• Corporate-owned work profile (COPE). The company owns the phone, but you still give the person a real personal space. You get more control than BYOD, they still get a private life on the device. This is the "here is your work phone, but check your kid's soccer schedule on it too" option.
• Fully managed (COBO). The company owns it and it is a work device, full stop. No personal profile. You control the whole phone, top to bottom.
• Dedicated (COSU). The company owns it and no single person owns it. Think kiosk, scanner, digital signage, a tablet bolted to a wall. It usually locks to one app or a small set of apps. Nobody signs in with their own identity.

There is a fifth name you will still hear, Android device administrator, or DA. That was the old way, before work profiles existed. Microsoft deprecated it, and it no longer works on devices that have Google Mobile Services. If someone hands you a DA setup, treat it as legacy and plan your move off it.

One table to keep them straight

Personally owned work profile, the polite one

BYOD work profile is the option that respects the line between work and life. Android literally builds a second sandbox on the phone. Work apps go in there with a little badge. Your management stops at the edge of that sandbox. You can wipe the work profile clean and the person keeps every personal thing untouched.

This is the sweet spot for staff who already have a phone they love and do not want a second one in their pocket. It also pairs well with app protection policies if you want to go even lighter. I wrote about that split in Intune devices vs app policies if you are weighing full enrollment against just protecting the apps.

Corporate-owned work profile, the balanced one

COPE is for company hardware that you still want to feel humane. The org owns the phone, so you get stronger controls than BYOD, including tougher password rules. The employee still gets a private profile for personal apps and accounts. It is a good middle path when you are buying the phones but you do not want to run a police state.

One catch worth knowing up front. On COPE devices running newer Android, factory reset protection can require the original Google account after a reset. Plan your reprovisioning so you are not locked out of your own fleet.

Fully managed, the total one

Fully managed, or COBO, is a corporate phone assigned to one person with no personal side. You own the whole device and the whole experience. By default the user cannot install anything outside your approved apps, and they cannot remove what you require. You can open the door to the full Play Store if you want, but the default is locked down.

Reach for this when the phone is a work tool and only a work tool. Field techs, drivers, frontline staff who get a device for the job and nothing else.

Dedicated devices, the kiosk one

Dedicated, or COSU, is the type with no human owner. The device is the point, not the person. It usually pins to a single app or a small locked set through the Managed Home Screen. A checkout tablet, a warehouse scanner, a check-in kiosk, a screen showing a dashboard all day.

If you run these on rugged hardware, I have gone deep on that world in enrolling Zebra scanners into Intune and Zebra kiosk mode. Same COSU idea, real device warts and all.

How you actually get devices enrolled

Picking a management type is half the job. The other half is provisioning. For the corporate types, the common enrollment paths are:

• QR code. Factory reset the device, tap the first screen a few times to open the reader, scan the profile. Best for small batches.
• Google Zero Touch. Buy from an authorized reseller and provisioning starts the instant the user powers on. Best for scale.
• Samsung Knox Mobile Enrollment. The Samsung equivalent of zero touch for Knox devices.
• Token entry. On the Google sign-in screen you type afw#setup instead of an email, then enter a token. Handy when QR and NFC are off the table.

BYOD work profile is the odd one out. It needs no factory reset. The person installs Company Portal, signs in, and Android builds the work profile in place. That single difference drives a lot of real world decisions.

The factory reset line you cannot ignore

Here is the single fact that trips people up most. Converting a phone into a corporate mode wipes it. You cannot bolt COPE, fully managed, or dedicated onto a phone that already has stuff on it. It has to start clean. BYOD is the exception, because the work profile is added, not baked in.

Blocking the types you do not want

You do not have to allow everything. Enrollment restrictions let you decide which Android flavors are even permitted. Under Devices > Enrollment > Device platform restriction, you can allow or block the Android platform, block specific manufacturers, set OS version ranges, and block personally owned devices entirely. If your org is corporate-only, turn personal ownership off and BYOD stops at the door.

Putting it together

The Android Enterprise management types come down to two questions. Who owns the phone, and does the person deserve a personal side. Personal phone, use BYOD work profile. Company phone people also live on, use COPE. Pure work phone, go fully managed. No owner at all, go dedicated. Managed Google Play is the connection under all of it, corporate modes need a clean device first, and enrollment restrictions let you slam the door on anything you did not choose. Get those four calls right and the rest of Android management gets a lot quieter.

What can we learn as a person

The factory reset rule stuck with me. To turn a phone into a fully managed or corporate device, you cannot just layer the new rules on top of the old mess. The phone has to be wiped first. A clean slate is not optional. It is the entry fee for becoming something different.

People are not so different. I have tried to bolt a big life change onto a life I never cleared out first. New habit, same old clutter underneath. New boundary, same old patterns still running in the background. It usually failed, and it failed for the same reason a corporate profile fails on a dirty device. There was too much left over to build cleanly on top of.

BYOD is the gentler truth on the other side. Some changes really are additive. You can keep your whole self and just build a small walled space for the new thing, and it coexists fine. The hard part is honesty about which kind of change you are facing. Some things you can add to who you already are. Some things need you to wipe the slate and start clean, even though it costs you everything that was already on there. So which change in your life are you trying to bolt on, when what it actually needs is a reset?

Further reading

• Android Enterprise overview (Microsoft Learn)
• Connect Intune to your managed Google Play account
• Enroll dedicated, fully managed, and corporate work profile devices
• Create device platform restrictions

Group Policy to Intune: Migrating Settings to the Settings Catalog

by David | Sep 8, 2026 | Intune

A client asked me if he could just export his Group Policy Objects and import them into Intune in an afternoon. I wish. Twenty years of GPOs do not lift and shift into the cloud in one clean drag and drop. But moving from Group Policy to Intune is a lot less painful than most admins expect, because Microsoft built a tool that does the boring analysis for you. Let me walk through it.

If you're pushing devices toward cloud management and want to cut the on-prem cord, this is where you start.

Why Group Policy to Intune isnt a straight copy and paste

Group Policy and Intune deliver settings in completely different ways. A GPO reaches a domain-joined machine through SYSVOL and LDAP, on your network, over a trust. Intune reaches a device through MDM configuration service providers, over the internet, with no domain required.

The good news is that Intune already has many of the same settings your GPOs do. They live in the Settings Catalog, a giant searchable list of everything Intune can configure. So a lot of your policy does translate. It just moves into a new home built for cloud-native Windows instead of a domain controller.

The tool that does the heavy lifting: Group Policy analytics

Group Policy analytics is a feature inside Intune that reads your actual GPOs and tells you what will carry over. It imports a GPO, checks each setting against what MDM supports, and reports a percentage. No guessing which settings have a cloud equivalent.

Step one: export the GPO as XML

1. On a machine with the tools, open the Group Policy Management console (GPMC.msc).
2. Expand your domain, then Group Policy Objects.
3. Right-click the GPO you want and choose Save Report.
4. Set Save as type to XML File and save it somewhere easy to find.

Keep each file under 4 MB. If a single GPO is bigger than that, trim its settings or split it before you export.

Step two: import it into Intune

1. In the Intune admin center, go to Devices > Manage devices > Group Policy analytics.
2. Select Import, pick your XML file, and choose a scope tag if you use them.
3. Select Next, then Create. Intune analyzes the file automatically.

Once the analysis finishes, each GPO shows an MDM Support percentage. That number is the share of its settings that have a matching setting in Intune. Select the percentage to drill into the individual settings and see exactly which ones map and which ones dont.

Read the migration readiness report

Before you migrate anything, look at the readiness report. Go to Reports > Device management > Group policy analytics. It sorts every setting into three buckets.

• Ready for migration, the setting has a match in Intune and can move straight over.
• Not supported, no MDM equivalent exists, so this one stays behind or needs a different approach.
• Deprecated, the setting targets old Windows or old Edge versions nobody runs anymore.

This report is the honest conversation about your environment. That deprecated bucket is usually bigger than people want to admit, and every setting in it is one you get to stop carrying.

Migrate the settings into a Settings Catalog policy

Now the actual move. Back in Group Policy analytics, you turn supported settings into a real Intune policy.

1. In Devices > Manage devices > Group Policy analytics, check the Migrate box next to the GPO you want.
2. Select Migrate to see every setting inside it.
3. On the Settings to migrate tab, check the specific settings you want in the new policy.
4. Review the values, name the profile something clear like "Windows: Imported Edge GPOs," and assign it to a group.
5. Select Create. The new Settings Catalog policy shows up under Devices > Configuration.

One nice touch. If two of your GPOs set the same thing to different values, the tool catches the conflict right there and makes you pick a winner before it lets you continue. Thats a problem you'd normally only find months later when a machine behaves weird.

What wont come across cleanly

Set expectations before you start, because a few things need a different plan.

• Domain-dependent settings. Anything that assumes a domain controller on the network doesnt make sense on a cloud-native device.
• Group Policy Preferences. Drive maps, logon scripts, and printer mappings dont map one to one. Use Intune's own features for those instead.
• Non-English and non-ADMX settings. The analytics percentage only reads non-ADMX settings in English, so the number can be off for other languages.
• Security settings. Many belong in compliance policies or security baselines, not the Settings Catalog.

Do not migrate all your settings just because you can. Review each one. After the policy lands, confirm it applied by checking which policies are on the device, the same way you'd check any other Intune profile.

Putting it together

Migrating Group Policy to Intune is really four moves. Export your GPOs as XML, import them into Group Policy analytics, read the readiness report to see what actually translates, then migrate the supported settings into a Settings Catalog policy. Start with one well-scoped GPO like your Edge settings, pilot it against a small group, and prove it works before you touch the big ones. The tool removes the guesswork. Your job is deciding what deserves to come with you.

What can we learn as a person

The readiness report is the part I keep thinking about. It looks at everything you built over the years and quietly sorts it into three piles. This still works. This has no place where you're going. And this one is just deprecated, left over from a version of the environment that doesnt exist anymore.

I moved into a new chapter recently, and I tried to carry my whole old config with me. Every habit, every defense, every rule I wrote for a domain I dont live in anymore. Some of it translated fine. A lot of it was deprecated and I just hadnt run the report to notice. The healthiest thing wasnt migrating everything faster. It was being honest about what no longer applied.

So if you ran a readiness report on the settings you carry day to day, what would land in the deprecated pile? And what are you still enforcing out of habit that the new version of your life doesnt even support?

Further reading

• Import and analyze your on-premises GPOs using Group Policy analytics
• Create a Settings Catalog policy using your imported GPOs
• Use the settings catalog to configure settings
• Configuration service provider (CSP) reference

iOS/iPadOS Enrollment Methods in Intune, Bulk and Single

by David | Sep 1, 2026 | Intune

A box of 40 new iPads landed on my desk the same morning a user emailed asking to get her personal iPhone on work email. Two devices, two completely different jobs. You do not enroll a pallet of company iPads the same way you onboard one person's phone, and picking the wrong path means wiping and starting over. So here are the iOS/iPadOS enrollment methods in Intune, which ones are built for bulk, which are single shot, and who each one is actually for.

Before anything: the Apple push certificate

Nothing Apple enrolls without an Apple MDM Push certificate. It's the handshake between your tenant and Apple's push service, and every single method below depends on it.

Set it up under Intune admin center > Devices > Enrollment > Apple > Apple MDM Push certificate. Two gotchas that bite people. Use a dedicated service Apple ID, not a real person's account, because whoever owns it is now load-bearing forever. And it expires every year. If that certificate lapses, every iOS and iPadOS device you manage silently falls out of management at once, and there's no quick undo.

Quick answer on WIP, MDM, and MAM

People ask whether these methods set up WIP, MDM, or both. Short version: WIP doesn't exist on Apple. Windows Information Protection is a Windows only feature, so no iOS enrollment method touches it. On Apple you have two lanes instead. MDM means the device is enrolled and managed. MAM means App Protection Policies protect the work data inside apps without enrolling the device at all. Every method here lands in the MDM lane, except plain App Protection Policies, which is the MAM lane for personal phones you never enroll.

Single-shot methods, mostly for personal devices

These are one device at a time, driven by the user, and they lean toward bring your own device.

Device enrollment with the Company Portal

The classic path. The user installs the Intune Company Portal from the App Store, signs in, and follows the prompts to install a management profile.

1. User installs Company Portal and signs in with their work account.
2. Company Portal walks them through downloading the management profile.
3. They open Settings, and here's the gotcha, they must manually tap to install the profile under General > VPN & Device Management. iOS will not auto-install it.
4. The device checks in and policies apply.

This gives the device user affinity, so it ties to a person and gets their apps and email. It's not supervised, so you get the smaller set of controls Apple allows on user-owned devices.

Web-based device enrollment

The newer BYOD path. The user starts enrollment in Safari instead of leaning entirely on the Company Portal app up front. You turn it on under Devices > Enrollment > Enrollment types by creating an enrollment type profile and assigning it to a group. Same result as Company Portal enrollment, user affinity and MDM, just a slightly smoother start. They still need Company Portal afterward to get to company apps.

Account-driven user enrollment

This is the privacy-first BYOD option, and it replaced the old profile-based user enrollment. It uses a Managed Apple ID alongside the person's personal Apple ID, and it only manages the work side. You cant wipe the whole phone or see personal apps, which is exactly what nervous employees want to hear.

It needs a few things lined up first. Apple Business Manager, federation between Managed Apple IDs and Microsoft Entra, and iOS 15 or later. Configure it under Devices > Enrollment > Enrollment types. Use this when people balk at full device enrollment on a phone they paid for.

Bulk methods, built for corporate devices

These are how you handle a pallet of company hardware without touching each screen by hand.

Automated Device Enrollment, the big one

Automated Device Enrollment, or ADE, used to be called DEP. This is the zero-touch method. A device enrolls the moment it's turned on and connects to Wi-Fi during Setup Assistant, before a user ever gets it. It supervises the device, which unlocks the full set of restrictions, and it scales to thousands.

1. In Apple Business Manager, connect your organization to Intune and assign your devices to the Intune MDM server.
2. In Intune, go to Devices > Enrollment > Enrollment program tokens and upload your ABM token.
3. Sync, so Intune pulls in the device serial numbers Apple assigned to you.
4. Create an enrollment profile that defines the Setup Assistant experience and whether the device gets user affinity.
5. Assign the profile to your devices. Next time they wipe and boot, they enroll on their own.

The gotcha is upstream. A device can only use ADE if it lives in Apple Business Manager, which means you bought it through Apple or an authorized reseller, or you added it manually with Apple Configurator. The token also expires yearly, so put a reminder on it just like the push certificate.

Apple Configurator

When devices arent in Apple Business Manager, Apple Configurator is the fallback. It runs on a Mac and you plug the iOS devices in over USB. It comes in two flavors, and the difference matters.

• Setup Assistant with modern authentication. Supervises the device, gives it user affinity, and the user signs in. Good for corporate devices going to a specific person.
• Direct enrollment. No user affinity, no Company Portal, and the device isnt wiped. Built for shared corporate devices that nobody personally owns, like a pool of loaner iPads.

The honest gotcha is that Configurator means a Mac, cables, and hands on every device. Fine for a drawer of iPads. Miserable for a thousand.

iOS/iPadOS enrollment methods matrix: who each is for

Blocking what you don't want

Enrollment methods decide how devices come in. Enrollment restrictions decide which ones you let in at all. Under Devices > Enrollment, device platform restrictions can block personal iOS devices while allowing corporate ones, and device limit restrictions cap how many devices one person can enroll. Set these before you open the gates, not after.

Putting it together

That covers the iOS/iPadOS enrollment methods worth knowing. Pick the method by who owns the device and how many you have. Corporate hardware at scale goes through Automated Device Enrollment, full stop. Corporate devices that never made it into Apple Business Manager fall back to Apple Configurator. A personal phone that just needs email is Company Portal or web-based enrollment, or account-driven user enrollment when the person wants their privacy protected. And if you only care about the work data and not the device, skip enrollment and use App Protection Policies. Whatever you choose, set your enrollment restrictions first and never let that Apple push certificate expire.

What can we learn as a person

The push certificate is the part that stuck with me. One quiet certificate sits under all of it. You set it once, you forget it, and it just works for a year while you handle louder problems. Then it lapses, and every device you thought you had a handle on silently stops listening to you, all at once, and you didnt even feel it happen.

I have certificates like that in my own life. The quiet standing thing that holds everything else up. Sleep. A weekly call with someone who matters. The half hour that keeps me sane. None of it screams for attention, so it's the first thing I let expire when the box of iPads lands on the desk. And then one day everything I was managing just quietly disconnects, and I finally look down and realize the cert lapsed months ago.

So what's the quiet certificate holding up your whole setup right now, the one you keep meaning to renew? And when does it expire?

Further reading

• Enroll devices in Microsoft Intune
• Automatically enroll iOS/iPadOS devices with Automated Device Enrollment
• Walkthrough of the Microsoft Intune admin center
• Set up Intune enrollment and restrictions