Endpoint Management: Microsoft Intune & Configuration Manager

Why is Intune reporting the part everyone struggles with?

Because Intune is built to manage objects and most of the questions you actually get asked are about estates over time. Those are different problems, and the console is good at the first one.

Ask whether a specific device is compliant and Intune answers immediately. Ask whether every device in the business received a critical update inside fourteen days, every month, for the last quarter, and you are into exports, manual joining and a spreadsheet, which is precisely the position the certification was supposed to move you out of.

None of this means Intune is the wrong product. It means the reporting layer is a separate job, and treating it as one is the difference between an estate you manage and an estate you can account for.

What does compliant actually mean in Intune?

It means the device met the conditions in the compliance policies assigned to it, at the last time it checked in and reported. Each part of that sentence is a place the answer can quietly stop being true.

The most common trap is staleness. A device that has not checked in for weeks can still show its last known state, so an estate that looks healthy may partly be an estate that has stopped talking. Any reporting worth trusting starts by separating devices that are compliant from devices that are merely quiet.

The second trap is that a compliance policy only checks what you asked it to. A tenant configured years ago against the threats of the time can report a fully compliant estate while never evaluating the controls anyone would ask about now, which is a reporting result rather than a security one.

The third is scope. Devices that were never enrolled do not appear as non-compliant, they simply do not appear, and unmanaged devices are the ones most likely to be a problem. A compliance figure is only meaningful next to an honest count of what should be enrolled, which is why we reconcile against identity sign-ins rather than trusting the device list on its own.

Should we move from Configuration Manager to Intune?

Eventually, probably, and rarely as a single project with a date on it. The framing that causes damage is treating this as a migration with a cutover, because it turns a manageable sequence of reversible steps into one event with a rollback nobody has tested.

Co-management is the supported route and it is deliberately incremental: Configuration Manager and Intune manage the same devices at once, and individual workloads move across one at a time, at your pace. Compliance policies, device configuration, Windows Update policies, endpoint protection, resource access and client applications can each shift independently, and each can shift back.

That structure means you can move the workloads with clear benefit early, leave the ones Configuration Manager still does better, and stop wherever the value runs out. Plenty of estates settle permanently in a mixed state and are correct to.

The honest test is not whether Intune can do a thing, it is whether doing it in Intune is better for you than the working arrangement you already have. We will tell you when the answer is no.

How do you prove devices are patched?

With a record over time rather than a screenshot, and this is the control most likely to fail an assessment because it is the hardest to reconstruct after the fact.

Cyber Essentials requires that critical and high-severity updates are applied within fourteen days of release, and an assessor will want to see that this held rather than that it holds today. Insurers ask the same question in different words, and so does anyone doing supply chain due diligence on you.

Intune manages the updates well through update rings and deferral settings. What it does not do easily is produce the historical evidence, so the practical answer is a reporting layer that keeps the record continuously: what was released, when it reached the estate, what did not take it, and what was done about the exceptions.

Exceptions are the part worth designing for rather than hiding. There is always a device that was off for a month, a machine that cannot take an update because of an application on it, and a build that fails for its own reasons. An assessor is far more comfortable with a documented, managed exception than with a report showing a hundred per cent that nobody believes.

What does day-to-day endpoint management actually involve?

Mostly it is the unglamorous work of keeping an estate coherent while it changes, which is why it degrades so reliably when nobody owns it.

The item that surprises people is policy hygiene. Estates rarely suffer from a lack of policy, they suffer from years of accumulation: overlapping assignments, settings applied twice with different values, and configurations created for a project that finished. Nothing announces it, and the symptom is an estate where changes do not produce the results anyone expects.

Where does endpoint management meet security and certification?

At almost every control anybody asks you about, which is why endpoint management is usually the fastest route to a better security position rather than a separate exercise.

Of the five Cyber Essentials control themes, endpoint management directly delivers secure configuration, security update management and malware protection, and carries a substantial part of user access control through device compliance and Conditional Access. That is most of the scheme, done through one management plane.

The relationship runs the other way too. Conditional Access decisions are only as good as the device state they are conditioned on, so a compliance policy that is stale or shallow quietly weakens an access model that looks strong on paper.

So we treat these as one piece of work rather than two. If certification is what is driving your interest, the endpoint estate is where most of the effort will land, and the evidence problem is the part worth starting on now rather than in the week before an assessment.