Getting a Microsoft estate through a Plus audit

Cyber Essentials Plus › Preparing a Microsoft estate

If your estate runs on Microsoft 365 with Intune, nearly everything a Cyber Essentials Plus audit examines is already visible to you. The difficulty is that the default views are reassuring in ways that do not survive contact with an authenticated scan.

The reporting gap that causes most surprises

Compliance dashboards report on devices that are checking in. Devices that enrolled once and stopped reporting, or that never completed enrolment, are either absent from the view or sitting in a category nobody looks at.

Those devices are still in scope for the audit. They are also, by definition, the devices not receiving your policies.

Start preparation by reconciling three lists: devices in Intune, devices in Entra ID, and devices your asset records say you own. The differences between those three are where the failures live. A machine present in Entra but absent from Intune is unmanaged. A machine in your asset list and in neither is invisible.

Patching: check the setting, not the dashboard

The requirement is high and critical updates within fourteen days. Two things to verify.

The deferral configuration. A quality update deferral longer than fourteen days puts you outside the requirement by configuration, regardless of what actually happens. Read the number in the policy.

Third-party applications. Windows Update handles Windows. It does not handle Chrome, Firefox, Adobe Reader, Java, or your line-of-business software. An authenticated scan sees all of those, and this is where estates that look fully patched turn out not to be.

If you have no patching route for third-party software, that is the single highest-value thing to fix before the audit.

Unsupported software: search for it deliberately

Automatic fail if found on a sampled device. Do not rely on the belief that everything is current.

Pull a software inventory from Intune or your endpoint console and look for: old Windows feature versions past their servicing date, Windows Server versions out of mainstream support, browsers that have not updated in months, old .NET or Java runtimes, and any application whose vendor has gone quiet.

Then check the mobile devices, which people consistently forget. An Android phone that stopped receiving OS security updates two years ago is unsupported software in scope, and on a bring-your-own-device estate it will be somebody's personal phone.

Local administrator rights: audit, do not assume

Everyday accounts must not hold local administrator rights. Policy says they do not. Reality frequently disagrees, because somebody was made a local admin during a remote setup to save a callback.

Pull the actual membership of the local administrators group across the estate rather than reading the policy. Where somebody genuinely needs occasional elevation, Intune's endpoint privilege management grants it temporarily rather than permanently, which satisfies the requirement and keeps people working.

Malware protection: verify centrally, per device

Defender enabled, real-time protection on, signatures current, and no device quietly excluded. Check the console for devices reporting as non-compliant or not reporting at all, and review the exclusion list, since a broad path exclusion is a hole somebody made on purpose and forgot.

Multi-factor authentication: the inventory is the hard part

Required on every cloud service for every user. The main tenant is almost never the problem. The problem is the service nobody listed.

Build the list from evidence rather than memory: enterprise applications in Entra ID, expense claims for software subscriptions, and a direct question to each department head about what they use. Then check MFA coverage on each. Expect to find two or three services nobody had thought of.

A two-week preparation plan

What to do, and when

When	Task
Two weeks out	Reconcile the three device lists. Investigate anything that appears in one and not the others.
Two weeks out	Pull the software inventory and search deliberately for unsupported versions, including mobile.
Ten days out	Audit local administrator group membership across the estate.
Ten days out	Build the cloud service list from evidence and check MFA on each.
One week out	Remediate what the first four steps found. This is the step that needs the time.
Three days out	Confirm every device is reporting compliant and that no device has dropped out of management.
Day before	Produce the final inventory for the assessor: device, OS and version, build, managed status, user, location.

The licensing question

Business Standard does not include Intune. You can still pass a Plus audit without it, but you are evidencing device configuration manually, and the audit is a poor moment to discover how long that takes at scale. For an estate beyond about twenty devices, Business Premium usually costs less than the time it replaces.

The devices that are not Microsoft

Almost every Microsoft estate has something in it that is not. Those devices are in scope, they form their own population in the sample, and they are consistently the least prepared.

Macs. In scope and sampled separately. The requirements are the same: supported macOS version, security updates within fourteen days, no everyday administrator rights, malware protection enabled. Intune can manage Macs, and where it does not, you are evidencing manually. The most common failure is the everyday account being an administrator, which is the macOS default on a machine set up by its user.

iPhones and Android devices. In scope if they access organisational data. The failure here is an operating system version no longer receiving security updates, which is common on older Android hardware and on any phone more than about five years old. Conditional access with a minimum OS version requirement handles this cleanly, because it stops non-compliant devices connecting rather than asking you to assert something about them.

Linux machines. Usually developer workstations or a server somebody set up. In scope, and often entirely outside your management tooling. Expect to evidence these manually and check the patching position specifically, because a machine nobody manages is a machine nobody patches.

The appliance nobody thinks of. A network attached storage device, a print server, a building management controller, a machine driving a machine. If it sits in the scope boundary, it is in scope. These are the ones that turn out to be running firmware the vendor stopped supporting in 2019.

Deciding what to do about them

Three honest options, and the right one depends on how many there are.

Bring them into management if the tooling supports it, which for Macs and mobile devices it generally does. Evidence them manually if there are few enough that a device-by-device record is realistic, which usually means under ten. Or segregate and exclude them if they genuinely do not need to be in the certified environment, accepting that the exclusion appears on the certificate.

What does not work is including them in scope and hoping the sample misses them. The sample is drawn to cover distinct populations, so a device type that exists is a device type that gets tested.