Microsoft turned basic auth off in Exchange Online for most protocols a while ago, so a lot of people assume this is done. It isn't quite. SMTP AUTH can still be enabled per mailbox, third-party apps still try, and Conditional Access is the thing that actually says no.

Look first

The Entra sign-in logs will tell you exactly who is still using it. Filter on Client app and tick everything under Legacy Authentication Clients. Go back thirty days. What you'll find, nearly every time:

• a multifunction printer scanning to email over SMTP AUTH using a real user's credentials,
• a line-of-business system sending notifications the same way,
• a shared mailbox someone checks from an old mail client on their phone,
• a handful of service accounts whose owners left years ago.

There is also a built-in workbook, Sign-ins using Legacy Authentication, which gives you the same view with charts, which is useful when you have to show someone why this matters.

Fix the holdouts, then block

Each holdout has a proper home:

Printers and apps that send mail. Options, in order of preference: Microsoft's High Volume Email or Azure Communication Services Email for anything that sends a lot; direct send via your MX record for internal-only notifications; an SMTP relay connector scoped to the device's IP if it must relay externally; or, as a last resort, SMTP AUTH enabled on one dedicated mailbox with a strong password and no other access. The thing to avoid is the printer using a person's account.

Old mail clients. The person updates the app, or uses Outlook. This is a conversation, not a project.

Orphaned service accounts. Disable, wait two weeks, delete.

Then the policy. Conditional Access has a template for it: Block legacy authentication, all users, all resources, client apps set to the legacy categories, grant block. Put the break-glass accounts in the exclusion and nothing else. Run it in report-only for a week first and check the log for anything you missed, then turn it on.

The part people forget

The policy stops the sign-in. It doesn't change the mailbox setting that allows SMTP AUTH, which means if someone later creates an exclusion, the door is open again. Disable SMTP AUTH at the organisation level in Exchange Online (Set-TransportConfig -SmtpClientAuthenticationDisabled $true) and enable it only on the one mailbox that genuinely needs it. Two layers; either one covers for the other.

It is a small piece of work, usually a day or two spread across a fortnight. I'd put it ahead of almost anything else on a tenant hardening list, because it closes the one path where a stolen password is enough on its own.

They stall for the same reason. Both require you to know what's actually running on your fleet, and almost nobody does.

Application control

The maturity model wants you to prevent the execution of unapproved executables, scripts, installers, compiled HTML and the rest, from user-writable locations at Maturity Level One, then everywhere at Level Two, with rulesets validated annually and a growing list of blocked drivers and known-bad binaries as you go up.

The technology is not the hard part. Windows Defender Application Control (now App Control for Business) or AppLocker will do it, and Intune will push it. The hard part is the week after you turn on audit mode and discover:

• the finance team runs a macro-enabled workbook that shells out to a console app nobody has seen since 2014,
• the engineers have a tools folder in their profile that every one of them depends on,
• three line-of-business apps update themselves by dropping a new executable into %LocalAppData%.

None of that shows up in an application inventory. It only shows up in audit logs, which is why audit mode is not optional and three months of it is not excessive. Collect the events centrally (the Intune device log collection or a Log Analytics workspace will do), build the allow rules from what you see, and publish rules by publisher wherever the binary is signed, so an update doesn't become a block.

The thing to avoid is the shortcut where someone allows an entire path because it was noisy. A rule that allows everything under C:\Program Files sounds reasonable until you remember that's a writable location for a lot of installers. Keep path rules for places standard users can't write to, and nothing else.

Patch applications

The requirement reads simply: patch within 48 hours when an exploit exists, otherwise within two weeks, for internet-facing services and the apps that interact with untrusted content; remove the things the vendor no longer supports; and use a vulnerability scanner to find what you missed.

What stalls it:

The 48 hours. Not the patching, the deciding. If the only way to know a vulnerability is being exploited is for someone to read advisories in the evening, you won't make 48 hours. Subscribe to the ASD alerts and the CISA Known Exploited Vulnerabilities feed, and give one person the job of reading them.

Apps that aren't yours. Windows Update for Business handles Windows and Office well. It does nothing for the PDF reader, the browser you don't standardise on, Java, the VPN client, and the forty other things people installed. You need either the Microsoft Store apps via Intune (good, where the app is there), an app catalogue like the Enterprise App Catalog or a third-party patching tool, or a willingness to repackage. Pick one; the mixed approach is where things get missed.

Unsupported software. Every fleet has it. The old Access runtime, the scanner driver tool, the EOL browser kept "for one system". Removal is a conversation with the business, not a technical task, and it is better had early.

The scanner. Defender Vulnerability Management is already there if you have the licence, and it is the fastest way to turn "we think we're patched" into a list. Run it before you declare the control met, not after the assessor asks.

Why they're worth it

Both controls do the same thing from different angles: they stop attacker code from running on your endpoints. Everything else in the Essential Eight limits the damage once it's running. That's why these two are hard, and why they matter most.

If you're planning an uplift, put them first on the timeline, not last, and give them the audit period they need. The rest of the eight will go faster for it.

Here are the five causes I see over and over, roughly in order.

1. The profile hasn't been assigned yet

"Identifying" means the device is checking whether it has an Autopilot profile. If the hardware hash was uploaded five minutes ago, the profile assignment can take a while to catch up, and the device will keep asking. Check the device in Intune under Windows Autopilot devices; the profile status should say Assigned, not Pending. If it is pending, wait, don't rebuild.

2. Too many apps are blocking

The ESP tracks the apps you tell it to track, and it won't let the user through until they're installed. The default is all required apps. On a fleet with twenty required Win32 apps, that's twenty installs, some with dependencies, some with detection rules that misfire, all before the user sees a desktop.

Pick the three or four apps the person needs to be productive in the first hour (the security agent, the VPN client, the browser) and block on those only. Everything else installs in the background once they're in.

3. A detection rule that never comes true

An app that installs fine but whose detection rule looks for a version string that doesn't match will report as failed, and the ESP will wait for a retry that fails the same way. Test detection rules on a machine that already has the app, before you make the app blocking.

4. Hybrid join waiting on a domain controller

Hybrid Entra join during Autopilot needs line of sight to a domain controller for the device to finish the join. If the device is at someone's kitchen table, it doesn't have that. The ESP sits there, and so does the user.

If you are still doing hybrid join for new devices, this is the moment to ask whether you need to. Entra-joined with Intune, plus Cloud Kerberos Trust for the things that still need on-premises access, is a simpler device that doesn't stall.

5. The timeout is doing its job

The ESP has a timeout, 60 minutes by default. When it fires, the user gets an error and the device is left half-configured. People read this as the cause; it's the symptom. Something above took longer than an hour.

Where to look

• On the device, during the ESP: Shift+F10 opens a command prompt. The log worth reading is C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. It shows which app it is waiting on and why.
• In Intune: Devices > Monitor > Autopilot deployments shows each phase and how long it took, which tells you where the time went across the fleet rather than one machine.
• Turn on Show app and profile configuration progress in the ESP profile if it is off. People tolerate a wait they can see.

The settings I ship

For most customers: ESP on, show progress, block on three apps, timeout 60 minutes, don't allow the user to reset the device on failure (they'll just do it again), and a plain-English message that tells them who to call. The rest is making sure those three apps always install.

Autopilot is a good tool. It just does exactly what it's told, and the ESP is where you find out what you told it.

Those exceptions are the interesting part. Every one of them was added for a reason that made sense on the day. Nobody went back.

Where the gaps live

The exclusion group that grew. The policy excludes a group called something like CA-Exclude-MFA. It was created for one vendor account during a migration. Two years later it has forty members: ex-contractors, a shared mailbox someone signs into, the CEO's assistant, a few people who "had trouble with the app". Open the group and read the membership. Then ask who owns it. Nobody will.

Break-glass accounts without a fence. You should have emergency access accounts excluded from Conditional Access; that part is right. But they need a long random password in a safe place, no licences, and an alert the moment they sign in. Half the tenants I see have the exclusion and none of the rest.

Trusted locations. "Don't prompt for MFA from the office" was a kindness in 2019. It is now a policy that says anyone on the office Wi-Fi, including the guest network if the ranges overlap, is trusted. Check the named location's IP ranges against what the network team actually runs today. They have usually changed.

Selected apps instead of all apps. A policy targeting "Office 365" and a few named apps leaves everything else open: Azure management, Graph Explorer, third-party apps registered later. Target all resources and exclude deliberately, not the other way around.

Device platform conditions. A policy that only applies to Windows and macOS is a policy that doesn't apply to anything that presents a different user agent. Platform is a hint, not a control. If the intent is "only managed devices", say that with a device compliance or hybrid join requirement.

Report-only forever. A well-designed policy sitting in report-only mode for eighteen months is doing exactly nothing. Report-only is a staging step, not a destination.

How I find them

1. Export every policy. The Entra portal will do it one at a time; the Graph PowerShell module will do it in one go: Get-MgIdentityConditionalAccessPolicy | ConvertTo-Json -Depth 10.
2. For each policy, list the excluded users, groups and roles. Resolve the groups to people.
3. Open the sign-in logs, filter for interactive sign-ins where Conditional Access shows Not applied or Success with no MFA, and look at who those accounts are.
4. Use the What If tool for the accounts you're worried about. It is the fastest way to see what a specific person is actually subject to.

The output of that is a short list of named accounts that can sign in with a password alone. That list is the real MFA coverage of the tenant, whatever the dashboard says.

Fixing it without breaking things

Don't delete the exclusion group. Empty it one member at a time, with a reason recorded against each removal, and give each person a week's warning. Vendor accounts move to a policy of their own with a tighter scope. Shared mailboxes stop having people sign into them directly. The break-glass accounts get their alert.

It's unglamorous work. It is also the single change that most improves a tenant's security posture, because the attacker doesn't care about your policy. They care about the forty accounts it doesn't cover.