The technology is not the hard part. Sequencing is. Here is the order that gets you to enforced compliance without locking anyone out of their laptop.
Intune is included in Microsoft 365 Business Premium and in the E3 and E5 enterprise plans, which means a very large number of organisations are already paying for it and not using it. The usual reason is not cost or capability. It is that the first attempt went badly, somebody got locked out of something, and the project quietly stopped.
That outcome is almost always a sequencing problem. Done in the right order, this is a ninety-day project for a mid-sized estate, and nobody loses access to anything.
The order that works
The principle underneath the sequence: never enforce a policy you have not first observed. Intune lets you set compliance policies to report rather than block. Use that. The gap between what you believe your fleet looks like and what it actually looks like is always larger than expected, and the cheap time to discover it is before anything is being blocked.
Weeks one to three: find out what you have
Before any policy, answer four questions.
How many devices are there, really? Not how many you bought. How many are signing in. Entra ID will tell you, and the number will include machines that left with people two years ago and a surprising quantity of personal phones.
Which are corporate and which are personal? This determines everything downstream. A corporate laptop can be fully managed. A personal phone used for email should be managed at the app level only, and treating it otherwise will start a fight you will lose.
What is already managing them? If you have an existing tool, or Group Policy, or a mix, you need to know which settings will collide. Two systems applying contradictory configuration produces behaviour that is genuinely hard to debug.
How will new devices arrive? Autopilot, manual enrolment, or somebody in the office imaging machines. You do not have to solve this in week one, but the answer shapes the plan.
Deliverable: a device list with an owner and a category for each. Boring, and the rest of the project rests on it.
Weeks four to six: compliance policies, watching only
Now create compliance policies and set them to report. Nothing is blocked. You are building a picture.
A week of reporting will tell you how many machines are unencrypted, how many are three OS versions behind, and how many have no antivirus reporting at all. Every one of those is a device that would have been locked out if you had enforced on day one, and every one belongs to a person who would have told everyone about it.
Fix the non-compliant devices during this window. The point of report-only mode is to give you a remediation list, not a dashboard.
Weeks seven to nine: configuration on a pilot group
Configuration profiles are separate from compliance policies, and the distinction trips people up. A compliance policy judges a device. A configuration profile changes it.
Pick a pilot group of ten to twenty people. Include at least two people who will complain loudly, because they will find things the compliant users will silently work around.
Apply the baseline: encryption, update rings, endpoint protection settings, Wi-Fi and VPN profiles if you use them. Then leave it alone for a fortnight and collect complaints. Two weeks is the right length because the first week surfaces the obvious and the second surfaces the weekly tasks.
Weeks ten to thirteen: apps, Autopilot, and enforcement
Deploy the applications everyone needs, so that a newly enrolled device arrives usable. This is the step that converts Intune from a policy tool into something the service desk actually likes, because it is the difference between a four-hour new-starter build and a device the person unboxes themselves.
Then turn enforcement on, in this order: first conditional access requiring a compliant device for one low-risk application, then for email, then for everything. Each step a week apart. If something is wrong you will find out on a small blast radius.
Finally, and this matters, retire the old tooling. A half-migrated estate with two management systems is worse than either system alone, and the temptation to leave the old one running "just in case" is how organisations end up with that forever.
Four things that commonly go wrong
Enrolling personal devices into full management. Users notice that their employer can now wipe their phone, and they are right to care. Use app protection policies for personal devices: the corporate data is containerised and the rest of the phone is theirs. This is both more proportionate and much easier to get agreement for.
Conflicting Group Policy and Intune settings. If machines are both domain-joined and Intune-managed, decide which one wins for each setting area. Microsoft provides controls for this, and the default is not always what you want.
Compliance policies with no grace period. A device that falls out of compliance at 9am on a Monday because an update dropped overnight should not lose access at 9.01. Set a grace period, usually one to three days, so people have a chance to remediate before they are blocked.
Enforcing before the service desk is ready. The first week of enforcement generates calls. If your service desk does not know what a compliance failure looks like or how to resolve one, those calls become escalations and the project acquires a reputation.
What you should have at day ninety
A device list you trust. Compliance policies enforced for the baseline, with the measured non-compliance rate near zero because you fixed the devices rather than exempting them. New machines arriving through Autopilot and usable without a technician. Conditional access requiring a compliant device for the applications that matter. One management system, not two.
That is a realistic ninety days, and it is considerably more than most organisations get from Intune in three years of owning it.
