Category: Intune

One macOS login that finally uses Entra

image

Most MSPs treat the Macs in a client tenant like orphans. Enrol them in Intune, push a couple of profiles, tick the box, move on.

But the user still signs into that Mac with a local password. One nobody rotates, nobody recovers, and nobody can tie back to a real person. The Entra identity you spent all that effort hardening — MFA, Conditional Access, the lot — stops dead at the macOS login window.

That’s not managed. That’s two identities wearing the same hoodie.

Platform SSO closes the gap. And here’s the part that annoys me: it’s been sitting in your Intune licence the entire time.

What is Platform SSO, really?

It’s the thing that finally makes a Mac sign in with Entra ID the same way a Windows device does with Windows Hello for Business.

When you turn it on, the Mac gets joined to your Entra tenant and a hardware-bound certificate is locked to the device. From then on, the user’s Entra account is their login. Touch ID unlocks the machine. Apps and browsers get single sign-on off the back of it. No more re-typing the work password into every prompt.

You pick one of three flavours — Secure Enclave, smart card, or password. Microsoft recommends Secure Enclave, and so do I. It’s passwordless, phishing-resistant, and conceptually identical to Windows Hello for Business. The other two exist for edge cases.

Here’s the real win: it’s included with every Intune licensing plan. No add-on, no separate SKU. If you’ve got Business Premium, you already own this.

Step-by-Step: turning it on

Portal only. No scripts.

Check the prereqs first

Devices need macOS 13 or newer — push for macOS 14 Sonoma(opens in new window) for the cleanest experience. The Company Portal app must be version 5.2404.0 or later, because that’s what carries the SSO plug-in. And the user has to be allowed to join devices to Entra. Miss any of these and registration silently never happens.

Build the profile

In the Intune admin center, go to Devices > Manage devices > Configuration > Create > New policy. Platform: macOS. Profile type: Settings catalog.

Drop in the values

In the settings picker, expand Platform SSO and add the core settings:

Authentication Method   UserSecureEnclaveKey
Extension Identifier     com.microsoft.CompanyPortalMac.ssoextension
Team Identifier          UBF8T346G9
Registration token       {{DEVICEREGISTRATION}}

Notice what’s missing? No password field. No certificate to mint. No on-prem ADFS box wheezing in a cupboard. The Mac proves who it is with a key baked into its own silicon.

Deploy Company Portal, then assign

Push the latest Company Portal as a required app — that’s what installs the plug-in. Then assign the policy. One catch that bites people: for devices with user affinity, assign to users, not device groups or filters. Get that wrong and Conditional Access can lock the user out of the very resources you were protecting.

Why this actually changes behaviour

The first time the policy lands, the user sees a “Registration required” notification. They click it, sign in with their Entra account, do MFA once, and it’s done.

That prompt trips up every first-timer. It looks like something broke. It didn’t. That’s the moment the device gets Entra-joined and the certificate binds. Tell your clients it’s coming and the support ticket never gets raised.

“Why does it still ask for my old Mac password after a reboot?”

Because FileVault uses the local password as the disk unlock key. So after a cold boot you enter it once — then Touch ID takes over for the rest of the session. That’s by design, not a half-finished feature. Worth saying out loud before a client assumes it’s flaky.

And if there’s still an on-prem domain in the picture, you can layer Kerberos SSO to on-premises Active Directory onto the same policy. The Mac quietly handles both worlds.

Get this in place and a client’s Mac stops being the weak identity in the room. Same MFA. Same Conditional Access. Same audit trail as every Windows device. One login, one identity, one set of rules.

If you’re rolling out Macs and not showing clients this, you’re handing them a managed device with an unmanaged front door.

Platform SSO isn’t there to make Mac logins prettier. It’s there to make the local password irrelevant.

Security baselines in Intune (Windows, Edge, Defender)

MAI_ddc086c935692a84

Most security baseline deployments I walk into were finished in about four minutes.

Someone opened Intune, found Security baselines, picked the Windows one, clicked through the wizard accepting every default, hit Create, and moved on. Box ticked. Tenant “hardened”.

That’s not security configuration. That’s a screenshot for the onboarding report.

Here’s the thing nobody tells you. A baseline you’ve never read isn’t a baseline. It’s a pile of Microsoft’s opinions you’ve agreed to without looking. And one of those opinions might break BitLocker enrolment on every machine without a TPM.

So let’s actually do this properly. It’s already in the licence your client pays for.

What is a security baseline, really?

A security baseline is Microsoft’s own recommended configuration for a product, bundled into one policy you deploy from Intune.

Not a list of suggestions. Not a report. Actual settings that get pushed to the device — BitLocker, firewall, Defender, password rules, SmartScreen — preset to the values Microsoft’s security team uses internally.

The point is speed. Instead of hand-building forty configuration profiles, you deploy one baseline and you’re 80% of the way to a hardened endpoint. Microsoft maintains the recommended settings and ships new versions as Windows evolves.

You get a few flavours: Windows, Microsoft Defender for Endpoint, Microsoft Edge, and Windows 365. There’s no separate SKU to buy. If your client is on Business Premium, this is already sitting in their tenant waiting.

Step-by-Step: deploying your first baseline

Portal only. No PowerShell.

Open the baselines

Sign in to the Microsoft Intune admin center and go to Endpoint security > Security baselines. You’ll see each baseline type with its current version on the right.

Pick one and create the profile

Start with Security Baseline for Windows 10 and later. Click it, then Create profile. Always take the newest version — older ones go read-only the moment a new one ships.

Name it like you’ll see it again

Give it a name your future self can read at a glance, like WIN-Baseline-Pilot. When a tenant has thirty policies, naming is the documentation.

Read the settings. Actually read them.

This is the step everyone skips. Walk the Configuration settings tabs. The defaults are deliberately restrictive — that’s the point — but restrictive settings break things. BitLocker enforcement on hardware without TPM 2.0 will tank an enrolment. Firewall rules will fight on-prem Group Policy on hybrid devices.

Assign to a pilot, not the fleet

Assign to a device group of ten to twenty machines with mixed hardware. Not your IT team’s identical laptops — include the weird old Dell from accounting. That’s where the breakage hides.

Watch the overview

Give it 24 hours, then check the profile’s Overview. You’ll see four buckets:

Succeeded        – applied cleanly
Error            – failed to apply
Conflict         – this setting is fighting another policy
Not applicable   – device can't support it

Notice what’s missing? There’s no “Secure” status. The portal tells you settings applied — never that you’re protected. Those are different claims, and the gap between them is your job.

Why this actually changes behaviour

Two reasons this matters more than the four-minute version.

First, conflicts are real and they’re silent. If the same setting lives in a baseline and a configuration profile, the device gets neither. It sits in Conflict and quietly does nothing. Run a pilot and you catch it. Deploy to everyone on a Friday and you find out Monday.

Second — and this is the one that catches people — baseline settings tattoo. Remove the assignment and the settings don’t roll back. They stay frozen at the last value applied. There’s no undo button.

“So if I unassign it, doesn’t the device go back to normal?”

No. It stays exactly where the baseline left it. You’d have to push the opposite setting to reverse it. Treat every baseline deployment as a one-way door, because it mostly is.

A baseline is a starting line, not a finish line. Microsoft’s Windows baseline covers maybe 150 of the 450-odd settings a CIS benchmark wants. That’s fine. Start here, layer the rest later.

The four-minute deployment and the real one look identical in a screenshot. They behave nothing alike on the device.

Read the settings once. Pilot once. Then you can tell a client their fleet is hardened and actually mean it.

A baseline isn’t there to make you look secure. It’s there to make you secure — but only if you read it first.

Intune compliance policies + Conditional Access integration

image

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

Driver & firmware update management via Intune

image

Walk into most MSP-managed Windows fleets and the update story stops at quality and feature rings.

Drivers? “Windows Update grabs those.” Firmware? “The OEM utility does that.”

That’s not a strategy. That’s three different cooks in the same kitchen, and you’re praying none of them serves up a bad BIOS on a Friday afternoon.

Here’s the real win. Intune has had a dedicated approval surface for driver and firmware updates for a while now. And almost nobody’s switched it on.

What is a driver update policy, really?

It’s a separate Intune profile that sits alongside your existing update rings. It shows you every driver and firmware update Windows Update has queued for your managed devices, and lets you decide — one at a time — whether to ship it.

Approve, pause, defer, hold back the one dodgy NIC driver while the rest go through. All in the portal.

Critically, it’s the same pipeline Windows Autopatch uses for drivers. Five-laptop accounting firm on Business Premium or 500-seat shop on M365 E3 — same surface. You need Intune Plan 1 and a Windows licence that includes the Autopatch entitlement (Business Premium and M365 E3/E5 both have it), devices must be Entra joined or Entra hybrid joined, and telemetry must be set to Required or higher. That’s the lot.

Step-by-Step: switching it on
Check your existing rings aren’t blocking drivers

This is the bit that catches people. If your existing Update Ring or Settings Catalog policy blocks drivers, the whole feature does nothing. In your update ring, set Windows driver to Allow. In the Settings Catalog, set Exclude WU Drivers in Quality Update to Allow Windows Update drivers.

Both default to Allow, but I’ve found plenty of older tenants where someone clicked Block years ago and forgot.

Open the right blade

Sign in to the Microsoft Intune admin centre → Devices → By platform → Windows → Manage updates → Windows 10 and later updates → Driver updates tab → Create profile.

Pick an approval mode

You get two:

  • Automatically approve all recommended driver updates — anything the OEM tags “recommended” gets approved on its own, with a deferral you set between 0 and 30 days.

  • Manually approve and deploy driver updates — every driver lands as Needs review and waits for you.
Approval method:   Automatically approve all recommended driver updates
Make updates       7
available after:

Notice what’s missing? There’s no per-vendor split and no per-device override. One policy, one device — stack two driver policies on the same machine and you’ll fight yourself.

Assign and stage

Pilot group of around 10% — your own laptops, IT, one tolerant power user. Watch it for a fortnight. Then 25%. Then the rest. The per-driver pause button is your friend the first time something breaks.

Why this actually changes behaviour

Most clients have never had a driver controlled by anyone other than Windows Update itself. The first time a Lenovo BIOS update bricks a laptop at 4pm on a Friday, that’s the conversation you do not want to be having with the owner.

With a policy on, you see the update before it hits anyone. You pause it. The rest of the fleet still ships. The client doesn’t even know it happened — and that’s the point.

“But surely Windows Update already knows what’s safe?”

Windows Update knows what applies. It doesn’t know your fleet. You do.

One last wrinkle. The policy doesn’t honour the OEM’s Computer Hardware ID targeting — so managed devices can pick up a newer “recommended” driver even when the OEM reserved a CHID-matched build for that exact model. My recommendation? Use manual approval on hardware you don’t have a spare of in a drawer to test against.

Driver update policies aren’t there to give you more buttons to click. They’re there to take the OEM utility, the random Windows Update behaviour, and the 4pm Friday surprise off the table completely.

If you’re not running one on every managed tenant, you’re outsourcing your hardware change control to luck.

Windows Update for Business rings via Intune

image

Most of the Windows patching pain I see at SMB sites isn’t a Windows problem. It’s a governance problem.

Devices are enrolled. Updates are technically arriving. But there’s no ring. No pilot. No deadline. Patch Tuesday lands, somebody’s accounting machine reboots in the middle of a BAS run, the partner blames “Windows”, and the whole patching conversation gets put off for another quarter.

That’s not a tooling gap. That’s a configuration gap.

And here’s the kicker — Microsoft renamed the whole thing in April 2025. Windows Update for Business is now Windows Update Client Policies, and the deployment service is folded into Windows Autopatch, which is now included with Microsoft 365 Business Premium. If you’re still hand-rolling rings on a Business Premium tenant and ignoring Autopatch, you’re doing more work than you need to.

What update rings really are

An update ring is a Windows Update client policy. It tells the Windows Update client on the device when to look, how long to wait, when to install, and when to reboot. Nothing more.

It’s not a patch repository. It’s not a scanner. It’s a set of timing instructions the device honours when it talks to Microsoft’s update endpoints.

Once you accept that, the rest gets simpler. You’re not pushing patches. You’re staging trust.

Step-by-Step: build a three-ring rollout in Intune

Portal only. No PowerShell.

Open the unified updates dashboard

Sign in to intune.microsoft.com, then go to Devices > By platform > Windows > Manage updates > Windows updates and click the Update rings tab. This is the new unified surface — Microsoft’s docs on managing update rings live here.

Create the Pilot ring

Click Create profile. Name it WUR – Pilot. Quality update deferral: 0 days. Feature update deferral: 0 days. Automatic update behaviour: Auto install at maintenance time. Deadline for quality: 2. Deadline for feature: 2. Grace period: 2.

Assign to a device group of 3-5 representative machines. Not user groups. Devices.

Create the Broad ring

Same shape. Name it WUR – Broad. Quality deferral: 3. Feature deferral: 7. Same deadline/grace as Pilot. Assign to the bulk of your fleet.

Create the Critical ring

WUR – Critical. Quality deferral: 7. Feature deferral: 30. Assign to the boss’s machine, the EFTPOS PC, the design workstation — whatever you can’t afford to surprise.

Three rings. That’s it. Don’t build five.

The deferral / deadline / grace mental model

People get this wrong constantly. Here’s the model in one block.

Deferral  → how many days AFTER Microsoft releases the update
            before the device is even offered it.
Deadline  → how many days AFTER the device sees the update
            before it's force-installed.
Grace     → how many days AFTER install before reboot is forced.

Notice what’s missing? Patch Tuesday as a reference point. The deadline counts from when that device scanned and saw the update — not the calendar. Microsoft moved to this model deliberately to make restart timing predictable across a fleet.

Set them. Don’t leave any of the three blank. Blank means forever on a sleepy laptop.

Why this actually changes behaviour

The mistake isn’t choosing the wrong deferral. The mistake is leaving the pause button in users’ hands.

In the ring settings, set Option to pause Windows updates to Disable. Otherwise a user can park their patches for 35 days, and you’ll find out at the next quarterly review.

Set automatic update behaviour to Auto install at maintenance time with active hours configured. The device patches itself. The user keeps their day. The MSP stops being the villain.

“Why do my updates keep nagging me?”

They don’t, anymore. You set active hours. The reboot finds its time, not yours.

Copilot doesn’t get tired. Neither does Windows Update. Use that.

A word on Autopatch

If the tenant is Business Premium, you now get the full Windows Autopatch service — rings auto-built, rollback on signal, 95% currency SLO. On those tenants, don’t assign hand-built rings to Autopatch-managed devices. They’ll fight each other.

My recommendation? Business Premium tenants → Autopatch. Everything else → three rings, the shape above, locked down so users can’t pause.

Update rings aren’t there to slow patching down. They’re there to remove the conversation about patching completely.

If your clients are still asking when their machines will reboot, you haven’t finished the job.

Endpoint Privilege Management in Intune: a deployment that actually sticks

image

Endpoint Privilege Management (EPM) is the cleanest answer Microsoft has shipped for the local-admin problem. Done well, it lets your tenants run as standard users while still installing approved apps and updating drivers — auditable, just-in-time, no helpdesk ticket. Done badly, you ship a half-configured agent that produces noise, breaks line-of-business apps, and convinces the customer that “least privilege” is somebody else’s problem. Here is how to make EPM stick at an MSP.

The licensing trap nobody warns you about

EPM is not included in Microsoft 365 Business Premium. It needs Microsoft Intune Plan 1 plus either the Intune Suite add-on or the standalone EPM add-on. If your customer is on BP only, you have a quoting conversation before you have a deployment conversation. Confirm assignments under Tenant administration → Intune add-ons before you create a single policy.

While you are there, validate the other prerequisites people skip: devices must be Microsoft Entra joined or hybrid joined, Intune-enrolled (or ConfigMgr co-managed), 64-bit only, and on supported builds — Windows 11 24H2/23H2/22H2/21H2 or Windows 10 22H2/21H2 with the listed cumulative updates. EPM also needs clear line of sight to its endpoints without SSL inspection — this single item kills more pilots than anything else.

See EPM deployment planning for the full prerequisite matrix.

Where to configure

Everything lives in the Intune admin center at Endpoint security → Endpoint Privilege Management. There are two policy types you need to understand:

  • Elevation settings policy — provisions the EPM agent on the device, sets the default elevation response, and turns on reporting. One per device-targeted persona.

  • Elevation rules policy — defines which binaries can elevate, how (Automatic, User confirmed, Support approved, or Elevate as current user), and using which signal (file hash, certificate, or metadata). Up to 100 rules per policy.

Do not configure rules first. The agent does not exist on the endpoint until the settings policy lands. See the EPM overview.

The rollout pattern that actually works

Three rings, audit-first — same as every other Intune deployment that survives contact with users:

  1. Audit ring (week 1–2). Deploy only an elevation settings policy to a pilot device group. Set Default elevation response = Require support approval, Send elevation data = Yes, Reporting scope = Diagnostic data and all endpoint elevations. No rules yet. Let it bake. EPM data is processed once every 24 hours, so resist the urge to declare it broken on day one.

  2. Pilot ring (week 3–4). Use the Overview dashboard and the Frequently unmanaged elevations and Frequently approved by support tiles to identify the real top 5–10 elevation candidates. Build rules for those — prefer publisher certificate + file path over file hash, because hashes change with every app update. Roll into a 20–30 user pilot.

  3. Production ring (week 5+). Widen progressively. Once managed-elevation coverage is high, deploy an account protection policy to remove standing local admin from the user group on those devices. That is the actual goal — the rules are just the bridge.

Build rules from Creating elevation rules. Watch coverage from EPM reports.

Top pitfalls

  • Certificate-rule sprawl. A certificate-only rule allows any binary signed by that publisher to elevate. Some vendors sign their entire catalogue — including tools you did not intend to elevate — with one cert. Always pair certificate with file name or path.

  • SSL inspection on the proxy. EPM telemetry travels over a pinned channel. Decrypt it and the device reports as “not applicable” with no useful error. Add an exclusion before you blame the agent.

  • Forgetting to remove local admin. Shipping rules without ever taking standing admin off the user group means EPM is theatre, not control. The whole point is the standard user.

Get those three right and EPM is a near-magical capability for an MSP. Get them wrong and it is just another agent on the box.

Shipping Intune App Protection Policies for BYOD: What Actually Works in Production

image

App Protection Policies (APP, sometimes called MAM) are the single highest-ROI control in Business Premium for BYOD. You get corporate data containerisation on an unenrolled iPhone or Android device in about an afternoon — if you avoid the usual landmines. Here’s the pattern I ship to MSP clients.

Prerequisites people miss

APP only protects apps that implement the Intune App SDK (Outlook, Teams, Word, Edge, OneDrive, etc.). That’s most of M365, but not every third-party app the user loves. Before you touch a policy:

  • Every targeted user must have an Intune Plan 1 licence (bundled in Business Premium and the E3/E5 stack).

  • Company Portal must be installed on Android. iOS doesn’t strictly need it for MAM-WE (without enrolment), but Authenticator is required for sign-in brokering.

  • For Android, you need the Play Integrity verdict configured if you plan to block rooted devices — and Play Store access, which rules out many China-market devices.

  • Decide now whether you’ll pair APP with a Conditional Access grant of Require app protection policy. If yes, your CA policy needs to exclude break-glass accounts and any service accounts that hit Graph from mobile.

See the App protection policies overview for the full support matrix.

Where to configure

Everything lives in the Microsoft Intune admin center at intune.microsoft.com:

  • Apps → App protection policies → Create policy → pick iOS/iPadOS or Android. You create one policy per platform.

  • Target apps: start with “Selected apps” and pick the core Microsoft apps. Do not start with “All Microsoft Apps” — you’ll regret it the first time Teams Rooms or a hybrid meeting app trips the policy.

  • Data protection settings: align with Microsoft’s Level 2 enterprise enhanced framework as your default. Level 1 is too loose for anyone storing client data; Level 3 breaks copy/paste workflows most SMBs rely on.

  • Access requirements: PIN of 6 digits, biometric allowed, 30-minute offline grace.

  • Conditional launch: jailbreak/root = Block access, min OS version = current−1, max PIN attempts = 5 → Wipe data. Full reference at Conditional launch actions.

The rollout pattern that actually works

Three rings, two weeks each, no exceptions:

  1. Ring 0 — IT and champions (5–10 users). Assign to a dynamic security group. Set Conditional launch actions to Warn, not Block. Let it bake. You are looking for app conflicts, not policy correctness.

  2. Ring 1 — Pilot department (25–50 users). Flip conditional launch to Block. Enable CA “require app protection policy” in report-only mode. Watch sign-in logs for a week — you will find the one user still using the native iOS Mail app.

  3. Ring 2 — Everyone. Move CA to On. Decommission any “allow legacy auth” exceptions at the same time — clients will push back, hold the line.

Use assignment filters (not separate groups) to carve out corporate-owned devices from BYOD rules. It scales; groups don’t.

The three pitfalls that bite

1. Policy conflicts silently pick the most restrictive value. If a user is in two groups with different PIN lengths, they get the longer one — and no error surfaces. Run one policy per platform per persona. Document which group wins.

2. Selective wipe isn’t device wipe. Apps → App selective wipe removes corporate data from managed apps only — photos, personal iMessages, the user’s Spotify library all stay. Train your service desk to say this out loud when an employee leaves. Also: the wipe only fires the next time the user opens the app, and can take 30 minutes.

3. Conditional launch “Min OS version” will brick users overnight. When Apple ships iOS 19 and you’ve set “Min OS version = 18”, a user on 17 walks in on Monday and can’t open Outlook. Always pair Min OS version with a Warn action first, run it for a fortnight, then escalate to Block.

Get these three right and APP is genuinely boring — which, for mobile security, is exactly what you want.

Self-Service Password Reset with writeback: the rollout that doesn’t burn your helpdesk

image

SSPR is a box most MSPs tick on day one of a Business Premium tenant and then never look at again. That’s fine until a hybrid customer calls because Karen changed her password on My Sign-Ins, logged into her domain-joined laptop, and got rejected. SSPR without writeback is half a feature. Here’s how to deploy the whole thing properly.

Prerequisites people miss

The obvious ones — an Entra ID P1 license (included in Business Premium) and either Entra Connect Sync or Entra Connect Cloud Sync — aren’t where rollouts die. The misses are:

  • On-prem AD permissions for the sync account. The account running Connect (or the Cloud Sync provisioning agent) needs Reset password, Change password, Write lockoutTime, and Write pwdLastSet on the user OUs. The Connect wizard grants these if you let it; locked-down AD environments often don’t. Writeback fails silently if these are missing.

  • A matching on-prem password policy. Entra enforces its own complexity rules. If your on-prem policy is stricter (minimum length, history, banned words), a user’s new cloud password will be rejected by AD when it writes back, and the user will see a generic error. Align them before you enable, not after.

  • Combined registration actually enabled and enforced. Legacy SSPR-only registration still exists in old tenants. If users register methods for MFA but not SSPR, the reset flow blocks them.

See Microsoft’s writeback concept doc for the full supported-operations list: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback(opens in new window).

Where to configure it

Everything is in the Entra admin centre — no PowerShell required for a standard deploy.

The rollout pattern that works

Don’t flip it on tenant-wide. The pattern that doesn’t generate tickets:

  1. Pilot group of ~10 — IT plus two friendly business users. Scope SSPR to that group only. Verify a reset from My Sign-Ins actually lands in AD (pwdLastSet on the DC is your proof).

  2. Registration campaign to the pilot for 14 days. Force them through combined registration. Watch the Registration report for stragglers.

  3. Broaden by department, not by “All users.” Finance first, then ops, then field staff. Each wave gets the campaign a week before the SSPR scope flips.

  4. Protect the registration step with Conditional Access. Use Register security information as the user action and require MFA (or a Temporary Access Pass for new starters): https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration(opens in new window). Without this, an attacker who phishes a password can register their own MFA method and own the account.

Top pitfalls

  1. Admins can’t use SSPR the same way users can. Privileged roles are locked to strong methods and can’t rely on Security Questions. Test with an admin-tier account before you cut over — and keep a break-glass account that is explicitly excluded from the CA registration policy.

  2. Writeback “works” but the user still can’t log in. Nine times out of ten this is cached credentials on a domain-joined laptop that hasn’t seen a DC since the reset. Tell the user to connect to the corporate network or VPN and lock/unlock. Bake this into your helpdesk script.

  3. Cloud Sync vs Connect Sync confusion. You can run them side-by-side, but writeback must be enabled on whichever one syncs that user’s domain. Audit first — we’ve seen tenants with both running where writeback was enabled on the wrong one and nobody noticed until a reset failed.

Enable it properly once, and SSPR moves from a compliance checkbox to a real helpdesk-deflection tool.