Keith Doolan - Modern Workplace Consultant

Windows Autopilot Device Preparation

September 4, 2026
Microsoft introduced Windows Autopilot Device Preparation to simplify endpoint provisioning and remove much of the complexity associated with traditional Autopilot deployments. If you’ve ever spent hours troubleshooting ESP failures, hybrid join timing issues, profile assignments, enrolment restrictions, or generic deployment errors, then Device Preparation polices is your saving grace.

Device Preparation isn’t Autopilot 2.0. It’s Microsoft’s attempt to make Autopilot behave the way I expected it to in the first place.

Why Device Preparation exists?

Traditional Autopilot works well on a good day, even for hybrid deployments that’s not recommended by Microsoft, but to be honest it’s temperamental at times and I must retry deployments, if I were to quantify, 1 out of every 30 times. It appears Microsoft’s solution is to not fix Autopilot but instead build another solution, and I happy they did.

Over the years, I’ve become accustomed to:
- Importing hardware hashes
- Waiting for hashes to synchronize
- Managing deployment profiles
- Troubleshooting ESP failures
- Managing Dynamic Groups
- Waiting for group memberships to update
- Troubleshooting hybrid join timing issues
- Rebuilding devices because enrolment failed halfway through
The actual deployment process is usually the easy part. The challenge is everything that happens before the end-user even sees the Windows login screen. Device Preparation attempts to remove much of this complexity by focusing on what administrators care about….. Getting a device enrolled, configured, secured and handed to a user as quickly as possible.

What’s the difference?

The biggest difference is that Device Preparation doesn’t rely on traditional Autopilot deployment profiles. Instead, administrators create a Device Preparation Policy that defines:
- Device settings
- Application deployments
- Platform Scripts
- User permissions
You then define a device group that you use to deploy configuration profiles and security policies. Microsoft then orchestrates the provisioning process in the background. The result is a significantly simpler deployment model, Automatic and User-Driven.

Before I get into the Automatic and User-Driven process, I want to talk about the predefined device security group. This group underpins the deployment of applications and settings, and there’s a key piece of information I need to show you.

As you can see, the security group requires a service principal owner called ‘Intune Provisioning Client’ the service principle could be named ‘Intune Autopilot ConfidentialClient’ on other tenants too, so watch out for that. If you look at the principal app ID you can see both are the same:

‘f1346770-5b25-470b-88bd-d5744ab7952c’

Don’t confuse this with the assignment group, the assignment group is who the policy applies to, not the group the devices join when going through the device prep process.

Automatic

Notice the name of the policy, I like to add ‘Corp Identifier’ to the Automatic device prep policy because, well it’s required. During OOOBE, how is the device going to know it needs to go through the device prep process if there’s no way to tie the device to a specific tenant? This seems obvious, but you wouldn’t believe the amount of people who aren’t aware of this, they think, ‘well I don’t need to do anything for the user-driven process, so I thought this was the same’. They’re right, the name ‘automatic’ also throws you off.

To be honest, I rarely us this method unless the Corp identifiers are automatically uploaded by a third-party CSP or similar vendor. The reason is, I don’t like messing around with CSV files to upload devices, plus the make, model and serial number is required in the CSV file. Not like Androids or Apple devices which only require IMEI’s or serial numbers. It’s finicky, because device vendors like Dell have different makes and model formatting and if it’s not done correctly, you only find out something is wrong when going through the OOBE process. For example, depending on the device, the make/manufacturer could be Dell, DELL INC, or Dell Incorporated, including the full stops which is very annoying.

Add corporate identifiers to Intune – Microsoft Intune | Microsoft Learn

Save yourself the hassle, go with the User-driven Device Preparation Policy. Let’s have a look at that.

User-driven

There’s a little more configuring here, but it’s minimal in the grand scheme of things. All the settings you see are self-explanatory so I’m not going to spend much time on this.

Besides the obvious differences, the user driven deployment requires an assignment group instead of a corp identifier, the domain name @ABC.com is the identifying method used to tie the user account to the tenant/device preparation policy.

Final Thoughts

The user-driven device preparation method is 100x better than standard Autopilot, that we can finally, and with confidence give a device to the end-user straight out of the box or delivered directly from the vendor to their door.

‘But Management doesn’t want users building their own laptops.’

I’ve heard this a lot lately, the reality is the user is only signing in, then they wait 20 – 30 minutes on average and away they go. The user powers on the device, signs in, the device provisions. That’s it!
- No hardware hash imports.
- No waiting for a profile assignment.
- No checking whether the device appears in the correct Dynamic Group.
- No more grey hairs. (Not that I have much hair)
It’s like Microsoft have given priority to Autopilot Device Preparation and pushed everything else out of the way, including the traditional Autopilot service.

Administrators no longer need to:
- Collect hashes
- Import CSV files
- Wait for synchronization
- Verify registration
The days of exporting hardware hashes via PowerShell and wondering why one device didn’t import correctly are largely gone.

We now have faster deployments, because Microsoft controls more of the provisioning workflow, deployments generally feel more responsive with fewer opportunities for something to break.

If your organisation relies heavily on hybrid join workflows, then traditional Autopilot may still be required. This isn’t necessarily a problem, it’s just important to understand that Device Preparation isn’t a complete replacement for every Autopilot scenario today. Yes, some of the familiar troubleshooting paths disappear, but now you don’t really need to troubleshoot before it just works and there’s a lot to be said for that in my line of work because a lot of things don’t ‘just work’.

*Deep Breath*

‘Device Preparation is what most customers thought they were buying when they first deployed Autopilot.’

Most organizations don’t care about deployment profiles, they don’t care about hardware hashes, they don’t care about Dynamic Groups. They certainly don’t care about waiting an hour for a device to appear in the correct group before it can be provisioned.

What they care about is:
- New laptop arrives.
- User signs in.
- Device becomes corporate-ready.
- Everyone is happy
Device Preparation moves much closer to that experience. Will it completely replace traditional Autopilot? No!

Could it replace traditional Autopilot for most Entra Joined, cloud-managed environments? Absolutely, yes!

If I were deploying a brand-new cloud-native Intune environment today, Device Preparation would be the first provisioning method I’d use.

To learn more about Autopilot Device Preparation, visit: Overview of Windows Autopilot device preparation | Microsoft Learn

Windows Hello for Business

August 9, 2026

Anyone who has deployed WHfB would know there are multiple deployment methods depending on the org setup and the device management state (Hybrid, On-Prem, Cloud). I’ll discuss three deployment methods using Intune for devices registered in Active Directory and synced to Entra, and for cloud only Entra joined devices.

Here are the three WHfB deployment methods:

Method	Use case
WHfB Account Protection Policy	Targeted deployment method configured in Intune -> Endpoint Security -> Account Protection. Supports granular user and device targeting and is Microsoft’s recommended method for phased deployments.
WHfB Enrolment Policy	Tenant-wide deployment method configured in Intune -> Devices -> Enrol devices -> Windows enrolment -> Windows Hello for Business. Applies Windows Hello for Business settings during Intune device enrolment and Autopilot provisioning.
WHfB Device Configuration policy (Cloud Trust)	Targeted deployment method configured in Intune -> Devices -> Configuration. Like WHfB Account Protection Policy and is my preferred method for phased WHfB deployments because it includes Cloud Trust and custom settings catalogue configurations.

WHfB Account Protection Policy

This is Microsoft’s recommended method because it’s prefilled with the common settings (device and user-scoped) one would look for from a WHfB deployment. This method is more controlled from a deployment perspective but not from a settings perspective like the WHfB Device Configuration policy where you can select your different settings from the settings catalogue.

Use Case:

Deploy Windows Hello for Business to a specific group of users or devices before a wider rollout.
Conduct a phased deployment to validate user experience, application compatibility, and support processes.
Pilot Windows Hello for Business with an IT team or user champions before expanding to the wider organisation.
Gradually transition users from passwords to PIN, biometric, and passwordless authentication methods.
Minimise user disruption by controlling when and who receives Windows Hello for Business registration prompts.
Support organisations that require granular targeting based on departments, locations, device groups, or job roles.
Align Windows Hello for Business deployment with change management and user communication plans.
Enable organisations to test and validate authentication policies before enforcing them tenant-wide.
Support both Entra joined and Hybrid Entra joined devices without immediately impacting all users.
Simplify administration by using Microsoft’s recommended Windows Hello for Business deployment method with preconfigured settings.
Reduce deployment risk by allowing issues to be identified and remediated within a limited user population.
Provide a controlled migration path from legacy authentication methods to modern, phishing-resistant authentication.

WHfB Enrolment Policy

Greenfield and Entra only environment, that’s it, that’s the use case. Now take what I say with a pinch of salt because there are occasions when deploying WHfB via the enrolment policy can work. It’s very heavy-handed and troublesome for larger, mature environments because it forces WHfB when the user signs into their device. Unless the communication is rock solid and people read their emails (We all know that never happens), then avoid it.

Now, you’re probably asking ‘what do you mean by greenfield?’ A greenfield is a blank canvas, i.e. no Intune. Recently I enrolled a client into Intune and used WHfB enrolment policy because I can enrol the end user’s bit by bit, in a controlled manner meaning they got WHfB gradually. I worked with a small cohort of users initially, got my communication right and then showed them what to expect.

Use Case:

Standardise Windows Hello for Business deployment across the entire organisation.
Automatically provision during Intune enrolment and Windows Autopilot onboarding.
Ensure users register a PIN, fingerprint, or facial recognition as part of their first sign-in experience.
Simplify administration by applying a single tenant-wide WHfB configuration.
Enforce a consistent onboarding experience for all newly enrolled devices.
Support cloud-only Entra joined and hybrid Entra (careful here) joined device deployments.
Reduce helpdesk dependency by guiding users through WHfB registration during device setup.
Support organisations that do not require granular targeting or phased WHfB deployments.

WHfB Device Configuration policy (with Cloud Trust)

OK, why is this deployment method my preferred choice? It has everything, this is the only method that includes everything found in the WHfB Account Protection Policy method plus the ‘Use Cloud Trust For On Prem Auth’ setting which is very important for Hybrid Environments. I don’t understand Microsoft’s rationale for leaving this setting out of other WHfB deployment methods, because it’s still very much relevant for a lot of the clients I deal with that have some form of on-prem legacy application or file server.

Use Case:

Deploy Windows Hello for Business using a targeted configuration policy rather than a tenant-wide setting.
Enable Cloud Trust authentication for Hybrid Entra joined devices accessing on-premises resources.
Support organisations with file servers, legacy applications, or other Kerberos-based on-premises workloads.
Provide a passwordless sign-in experience without requiring WHfB certificate deployment or complex PKI infrastructure.
Support both Entra joined and Hybrid Entra joined devices using a single deployment method.
Configure and manage WHfB settings through the Settings Catalog, providing greater flexibility than the Account Protection Policy.
Conduct phased or pilot deployments by targeting specific user or device groups.
Standardise WHfB settings across different user populations while maintaining deployment control.
Simplify Hybrid WHfB deployments by leveraging Cloud Trust instead of Key Trust or Certificate Trust models.
Reduce infrastructure dependencies by eliminating the need for WHfB certificates and certificate lifecycle management.
Support organisations modernising authentication while retaining access to on-premises resources.

Cloud Trust

Cloud Trust is a feature that lets Hybrid Entra joined devices authenticate to on-premises resources (file servers, legacy apps, Kerberos workloads) without needing certificates or complex PKI infrastructure.

Essentially, instead of issuing WHfB certificates, Cloud Trust uses your cloud identity to vouch for your device when it needs to access on-prem resources. It’s passwordless and keeps things simple.

It’s only available in the WHfB Device Configuration policy method, not in the Account Protection or Enrolment policies. That’s why it’s my preferred deployment method for hybrid environments.

To learn more about Cloud Trust, visit: Windows Hello for Business cloud Kerberos trust deployment guide | Microsoft Learn

Summary

For mature, hybrid organisations with on-premises applications, devices, users, or other resources, use WHfB Device Configuration policy and set up Cloud Trust as your default method. Yes, there’s more setup involved, but it’s worth avoiding the common pitfall of clients withholding infrastructure details and leaving you to unpick the configuration later.

To learn more about Windows Hello for Business, visit: WindowCloud Trusts Hello for Business overview | Microsoft Learn

Deploying Endpoint Privileged Management (EPM)

July 1, 2026
Endpoint Privilege Management allows end-users to elevate applications in a controlled manner, thus reducing the requirement for standard user’s requiring local admin permissions to install executables, upgrade applications, etc.

In this blog post, I’ll show you a phased approach to deploying EPM and then show you how I like to deploy EPM while following a zero-trust mythology.

Before we get into it, and to help you understand EPM, I’ll explain what the following settings do:

Elevation settings policy (ESP)
A policy that controls how elevation behaves on a device in the absence of a rules policy which targets applications.

Default elevation response (contained in ESP)
What happens when a user hits an app that needs elevation but doesn’t match any rule. I call this the fall-back response.

Elevation rules policy (ERP)
A policy that defines what applications can be elevated.

Elevation type (contained in ERP)
The control of what happens when the rule matches.

Validation (contained in ERP)
How EPM verifies the file matches your rule before allowing elevation. Usually it’s user confirmed via business justification or Windows Authentication.

Signature source (contained in ERP)
Defines where EPM gets the file/apps signing information from.

Note: There’s a reusable section in EPM that allows you to reuse certificates for signing as publishers tend to reuse certificates on different versions of the same app

Phase 1: (Discovery)
- Identify users with local admin rights.
- Identify applications that are being elevated and prioritize based on importance.
- Collect data and then meet with the client to discuss the findings.
Phase 2: (Design)
- Define elevation settings policy (Default elevation response, validation).
- Define elevations rules policy (Elevation type, validation, app signature).
Phase 3: (Pilot)
- Target a pilot group of users for testing.
- Create Elevation Rules Policy that target common end-user applications, like Chrome and 7-zip.
- Create a rules policy for business applications you wish to cover.
- Create different elevation rule types per common apps. (User confirmed, automatic, deny, support approved, elevate as current user)
- Provide end-user guidance
Phase 4: (Deploy)
- Decide which policies you want to keep
- Assign the policies to the users with local admin rights.
- Monitor and make amendments as required.
The Zero-Trust Approach

Most environments already have some application elevation control in the form of User Account Control (UAC). This is fundamentally a zero-trust approach, so why not apply the same EPM controls to all users or devices in the organisation and then gradually allow app elevation as required? Let me show you how I setup EPM, but first here’s an overview of my policies which I setup unassigned on day 1.

Elevation Settings Policy (ESP)

0. Discovery

Does what it says on the tin, generally I assign this policy to all users or all devices if I’m deploying EPM broadly. If you’re targeting a specific group of people, then do that so you’re not overloaded with data.

1. Default Deny All

Again, this does what it says on the tin and is left unassigned until I’m happy (and the client) to turn it on and I’ve confirmed that all elevation rules policies are working as expect.

Elevation Rules Policy (ERP)

Each elevation rules policy requires information on the application you wish to target, and just like the elevation settings policy, there are different conditions in which an app gets elevated. In this section, I’ll go describe a single ERP using the user confirmed elevation type and show you what it looks like from an admins perspective when approving an application elevations.

4. Visual Studio – Business Justification

For this ERP, I use the elevation type as user confirmed but target the assignment of the policy to developers. The rationale is, developers need to be able to update the Visual Studio compiler/engine or subcomponents as required.

Warning: using the file hash as the source identifier is not recommended because the file hash changes when the application is updated. I’m sure the file hash has its use, but I’ve yet to find a reason for using the file hash for anything other than a proof of concept

Application Approval

Below is a series of screenshots that show the application approval process from the end-user’s perspective to the admin’s perspective. When Require support approval is selected as the default elevation response, business justification is mandatory, this gives context to the admin/approver.

End-user

Admin

Final thoughts

Endpoint Privilege Management doesn’t have to be difficult, I see a lot of tenants set up with a single Elevation Settings Policy (< 5 minutes to configure) that requires approval to elevate applications and applied to all users or all devices. Configuring EPM this way is a great starting point to immediately protect your endpoints but also give you an overview of what applications people are elevating.

To learn more about Endpoint Privileged Management (EPM), visit: Learn about using Endpoint Privilege Management with Microsoft Intune – Microsoft Intune | Microsoft Learn
Microsoft 365 Business Premium – Day 1

June 10, 2026
When a customer uplifts to M365 Business Premium (or E3) they are after one or two features, whether that be Intune to manage their fleet of devices or Defender for business because their Anti-virus solution is due for renewal. M365 BP offers so much more!

In this blog post, I’ll list what you get with Microsoft 365 Business Premium and what Settings/features I turn on immediately so the customer gets immediate benefits and some protection on day 1.

What you get with M365 Business Premium:
1. Microsoft Intune Plan 1
2. Microsoft Defender for Business
3. Defender for Office 365 Plan 1
4. Microsoft Entra ID P1
5. Purview & Information Protection
Microsoft Intune

Enrollment restrictions

Enrolment restriction depends on the customer and what devices they allow on their environment. Following a zero trust model, I block everything (except Windows) to begin with before explicitly (in writing) given permission from the customer to allow other devices. Even if you know a customer very well, always ask the question to cover yourself.

Device Enrolment Settings

Once the enrolment restrictions are in place I then configure the enrolment scope and for a specific set of pilot users and then ‘Disable MDM enrollment when adding work or school account on Windows’ to stop accidental device enrolment. This gives me control over who and what get’s enrolled.

Microsoft Defender for Business

Onboarding

When you open Defender for the first time, Microsoft thankfully bring you through an initial configuration steps to onboard devices. Although not required, I tend to onboard devices that are enrolled into Intune. You can of course use a GPO or a configuration script to onboard devices.

Alerting Policy (High only)

Microsoft turn on all type of severity alerting by default, however the alerts by default send to the tenant admins group, which generally don’t have an email address associated to them. For customers, I setup a shared mailbox so they can track the alerts, but it’s also good proactive to send the alerts elsewhere, like a SIEM solution and/or the ticketing system if you work for an MSP like I do.

Microsoft Defender for Cloud Apps

Under system -> settings -> General: Advanced Features, you will see that the Microsoft Defender for Cloud Apps is toggled off by default.

Although the subtext mentions ‘This feature is available with an E5 license for Enterprise Mobility + Security on devices’, you can still receive the telemetry data (Cloud App Discover data) from Defender for Cloud Apps by turning it on.

Defender for Office 365

There are many features of Defender for Office that I could talk about, however, that’s another blog post. Microsoft provides you with preset security policies that you can enable from day 1. The standard protection preset suits in most instances, I’ve yet to break anything by turning this on immediately, however as always, test on a pilot group of users first before broader deployment.

Microsoft Entra ID P1

I covered many features of Entra in a previous blog post: Enhancing IAM Controls so I’m not going to expand on them further. However there are some settings that I enable immediately at the tenant level when a customer is uplifting to Business Premium or E3 licenses.

User Settings

Here’s a before (default) and after User Settings Configurations that I like to configure on day 1.

Device Settings

Similarly, there are device settings that by default are enabled but generally aren’t desirable to have configured on a customers tenant. Again, here’s a before and after device settings:

As I always recommend, test before making changes to any environment!

To learn more about business premium visit: Microsoft 365 Business Premium resources | Microsoft Learn
Conditional Access Policy – Named Locations

May 2, 2026

Frequently I see conditional access policies in Entra ID that don’t make sense, are targeted incorrectly, or are enabled but not assigned to users or groups. This naturally occurs over time, because not one person is responsible for them, it’s generally a shared responsibility that no one really wants to take ownership of, and when that happens, we’re left with security holes.

We must treat conditional access policies holistically, especially Named Location CA’s. An analogy I like to use is a drawbridge over a castle moat, the drawbridge being the named locations CA’s, the guard or guards being the CA’s and the castle being the tenant. I’ll go against the grain here and state that ‘Conditional access policies with named locations should be configured second, after Microsoft’s recommended default CA’s and before persona based conditional access’. For those who don’t know, persona based CA’s are CA’s targeting guests and external identities among other personas.

Here are my go-to named locations and their corresponding CA’s. The 🦾FANTASTIC FOUR 🦾as I like to call them.

The premise of these named location CA policies is to default block all countries and then exclude what is allowed with some additional conditions. I like to mix in session control as it makes sense to pair the sign in-frequency and make it more restrictive for locations outside of the office network. Here’s how they look, starting broadly and working inward.

👉CA04 NL- Block Untrusted Countries 🗺️

Assignments: All Users

Target Resources: All Resources

Network: ‘All Countries’ NL, excluding other named locations. (Home 🏠, Office 🏢, Trusted Countries 🗺️)

Conditions: As Above

Access Controls: BLOCK ACCESS

👉CA05 NL- Require Strong MFA for Trusted Countries 🗺️

Assignments: All Users, excluding breakglass account.

Target Resources: All Resources

Network: ‘Trusted Countries’ NL, excluding home 🏠 and office locations 🏢.

Conditions: As Above

Access Controls: GRANT ACCESS (Phishing-Resistent MFA/Windows Hello, Device Compliance, Sign-in Frequency: Every time, Persistent browser session: Never)

👉CA06 NL- Require Strong MFA for Home Countries 🏠

Assignments: All Users, excluding breakglass account.

Target Resources: All Resources

Network: ‘Home Countries’ NL, excluding office locations 🏢 and trusted countires 🗺️.

Conditions: As Above

Access Controls: GRANT ACCESS (Password-less MFA, Device Compliance, Sign-in Frequency: 4 Hours, Persistent browser session: Never)

👉CA07 NL- Office Locations 🏢

Assignments: All Users, excluding breakglass account.

Target Resources: All Resources

Network: ‘Office Locations’ NL, excluded home 🏠 and trusted countries 🗺️.

Conditions: As Above

Access Controls: GRANT ACCESS (Password-less MFA, Device Compliance)

The trick is to exclude other named locations in the CA policies because you can have instances where multiple CA’s can be true. For example, if you’re in the head office in Dublin and the trusted country is Ireland, then CA’s 05, 06 and 07 are true meaning more conditions and controls must be met to be granted access to resources.

⚠️WARNING ⚠️

Do not implement these CA’s because ‘Keith wrote about them in his blog’. As always, test before implementing.

To learn more, visit: Build Conditional Access policies in Microsoft Entra – Microsoft Entra ID | Microsoft Learn
Identity & Access Management (IAM) Controls – The Stryker Incident

April 2, 2026

Following the recent high profile cyber-attack on Stryker Medical by the Iran-based Cyber Group Handala, I think it’s fitting to discuss threat prevention methods even for a Global Admin (GA) Account which appears to have been compromised in this case.

Yes, the GA account can circumvent some or part of these measures, but security isn’t a ‘one size fits all’ solution. Security is an accumulation of measures, a layered defense that makes it extremely difficult for an attacker to circumvent collectively. As it’s still early days and we don’t have the full details, let’s discuss Microsoft’s 365 Identity & Access Security features that would have stopped or slowed down the attacker.

👉🏻Multi-Factor Authentication (MFA)🫆

Not all MFA methods are secure, a man-in-the-middle (MitM) attack can obtain authentication methods like push notifications with Microsoft Authenticator or SMS authentication. Phishing resistant methods like FIDO2 keys or passkeys using Windows Hello should be the default authentication method used by organisations. Microsoft have mandated the use of MFA for privileged accounts, so it’s likely some form of MitM attack occurred here.

👉🏻Multi-Admin Approval (MAA) ✔️

A secondary admin is required to approve potentially destructive actions on a Microsoft 365 Tenant. Organisations can configure an ‘access policy’ which cover different policy types such a device actions (delete, retire, wipe), roles (create, edit, assign, delete) and more. Circumvention can be difficult here when the ‘Roles’ access policy type is implemented. In the Stryker incident, Graph API calls to wipe devices would need to be approved for each device action type. This would have certainly triggered an alert!

👉🏻Privileged Identity Management (PIM) 🪪

PIM is your just-in-time (JIT) access feature configured in Microsoft Intune for privileged roles. Here you can assign roles that require activation when needed and expire after a set amount of time. You can set the activation to require a business justification and an approver to verify, like MAA. It’s evident that Stryker didn’t use PIM or make use of the approver function.

👉🏻Conditional Access – Named Locations 🌎

A mistake I see consistently is the configuration of named locations, named locations are used to ‘tag’ an identity’s location using two methods, IP addresses and GPS coordinates. Yes, an IP Address can be spoofed quite easily but determining a location by GPS coordinates is more difficult to circumvent because the Microsoft Authenticator app requests the location services from the device the end user is signing in with.

Organizations use named locations to provide access based on a trusted country, but rarely a policy blocking certain countries which follows the zero-trust methodology. In this case, Stryker could have created a ‘Blocked Countries’ list, selected all, de-selected the counties their IT Teams operate in and created a CA policy to block access to all admin portals.

👉🏻Risk-Based Conditional Access ⚠️

Risky users and sign-ins are detected using Microsoft’s Machine learning and Threat Intelligence engine, the engine is fed information from many data points to identify threat actors and patterns, called signals. Microsoft uses these signals to designate a risk score to an identity (Low, Medium, High). With the correct licensing for Identity Protection, organisations can utilise Microsoft’s risk scores to block access to a tenant using a sign-in risk or user risk policy. These policies are basic; there’s more flexibility using Risk-based Conditional Access policies. I’ll delve into these in a future blog.

👉🏻Identity Governance – Access Reviews 📋

Access Reviews don’t have to be manual, as part of the Microsoft Entra Identify Governance suite, ‘Access reviews’ can be conducted automatically and targeted at groups and applications periodically. Say for instance, there’s a ‘SysAdmin’ security group containing accounts with the Global Admin role. You can configure Access Reviews so that the ‘Reviewer’ must act on an accounts access to the ‘SysAdmin’ group otherwise block actions can be automated if the reviewer ignores the report. This prompts a reviewer to conduct an access review, drill into the account and justify its access. Microsoft Entra Access reviews are not a silver bullet; however, they can be used to find the breadcrumbs necessary to identify a malicious actor/entity.

👉🏻Final Thoughts 💭

There is a cost to use the above features, but with good practices organisations don’t need to break the bank if they follow the principle of least privilege and regularly reviewed accounts. If a GA is required, then the authentication methods should be cycled and sign-in logs monitored daily. Stryker failed to do the basics, and it cost them greatly.

To learn more, visit: What is Microsoft Entra ID Protection? – Microsoft Entra ID Protection | Microsoft Learn
Baseline Security Mode (BSM)

March 1, 2026

At Microsoft Ignite 2025 in November, Microsoft announced Baseline Security Mode (BSM) is generally available and will begin rolling it out to Microsoft 365 Tenants globally.

What is BSM?

BSM is Microsoft’s recommended security hardening protections found under the org settings in the admin center.  BSM is divided into two sections ‘Default Policies’, which can be applied automatically (by selecting a checkbox) and usually have little impact, and ‘Measured Policies’ which as the name suggests, requires assessment before enabling.

Lucky for us, for ‘Measured Policies’ Microsoft does all the heavy lifting by generating reports, making recommendations, identifying the risk and measuring the impact before applying the policy/setting, like report-only mode for conditional access policies.

Generating a report usually changes the recommendation status to ‘In review’. I say ‘usually’ because the layout and functionality of the GUI have changed since I first reviewed the Baseline Security Mode two weeks ago on my test tenant, so this is likely to change again in the future.

Let’s look at ‘Block new password credentials in apps’ which is currently ‘At Risk’.  We can check the recommendation and click the button at the bottom of the image below to apply the setting or download a detailed report to measure the risk. Clicking ‘Customize this policy’ brings you directly to the setting in the Entra ID portal.

Looking at the ‘Block legacy authentication’ which is currently ‘In Review’ status, we can see that there aren’t any ‘Sign-in requests authenticating with legacy auth’. Phew – we’re safe!

Similarly, we can check the box and save the policy to apply the recommendation, or we can click ‘customize this policy’ to take us directly to the setting/policy section in the Entra ID portal.

As always, I like to finish off my blog posts with my opinion – BSM is a much-anticipated feature I’ve been wanting from Microsoft for what feels like a lifetime. I’ve been looking for a mechanism to measure a tenants security posture without the need for manual checklists or external tools.

Currently BSM is only targeting Microsoft 365 apps, SharePoint/OneDrive, Teams, Exchange Online and Entra. I’ve heard through the grapevine that BSM will be expanding to Intune. Hopefully as a feature of security baselines because there’s a lack of impact reports, yes folks will argue that you should test before applying the baselines but even then there’s nearly always some outlier that wasn’t part of your test group that needs remedying.

Anyways, big thumbs up for Microsoft on this, BSM is a cool feature that I will be using often when reviewing the security posture of clients tenants. Like Secure Score, BSM should be reviewed regularly as more hardening settings become available.

If you enjoyed my blog, please subscribe to get emailed when I release more.

N.B – Just as I’m ready to publish this post 😁
How to enable Synced Passkeys in Entra?

January 25, 2026

Microsoft has released Synced Passkeys for public-preview, and I’m going to show you how to configure it, but first we need to understand what a passkey is? A passkey is a password-less identification token provided by an Identify provider (IdP), generally in the form of biometrics and a backup pin. In Microsoft Entra, the passkey is device bound, meaning a new passkey is required for accessing Microsoft services on different devices. A Synced Passkey solves this problem by storing the key in the cloud with your Microsoft account, essentially becoming identity bound.

Step 1: Opt-in to public preview

First you need to opt-in to public preview by clicking the hyperlink in the banner under Passkey (FIDO2) settings.

Open https://entra.microsoft.com/ – under Entra ID in the left nav pane, select Authentication methods > Under Manage, select Policies > under method, select Passkey (FIDO2)

Step 2: Edit the default passkey profile

If you don’t have passkeys enabled on your tenant, then you will be prompted to edit the default passkey profile. Select Edit default passkey profile

For now, select Enforce attestation which will auto select Device-bound as the target type and hit save. We will configure synced passkeys on a different profile.

Step 3: Enable Passkeys (If not already enabled)

Under Passkey (FIDO2) settings, Toggle the enable button to On and hit save.

Step 4: Create a synced profile

Select the Configure tab and then select, add profile (preview). Fill in the profile settings and then hit save.

Notice that enforce attestation is not selected; this setting is not compatible with synced passkeys because synced passkeys don’t require the authenticity verified from a hardware authenticator, as an example. You can ignore the warning banner at the bottom of the above image which appears when enforce attestation is not enabled.

The target specific AAGUIDs setting is optional; you can use this setting to allow or block other passkey/IdP providers like OKTA or Google. Uncheck this option; it’s not required for this tutorial.

Step 5: Target the profile

The final step in Entra is to target the sync profile to a group of users. In this example, I target helpdesk agents and added my account into that group.

Step 6: Add passkey as a sign-in method

Browse to My Sign-Ins | Security Info | Microsoft.com and click add sign-in method. Select Passkey and go through the various options available to you. In my case, I choose to create a passkey using a different device so I can use biometrics from my android phone rather than the device I’m currently using.

Step 7: Enjoy
In a modern workplace where there’s a lot of hotdesking, shared computers on a warehouse floor or you’re a techie like me who has too many gadgets, Synced Passkeys is a game changer.

If you enjoyed my blog, please subscribe to get emailed when I release more.
Autopilot Deployment Modes – Opinion Piece

January 11, 2026

Autopilot is Microsoft’s ‘zero-touch’ endpoint deployment tool for Windows 10/11 and HoloLens devices; I’m not going to delve into what Autopilot does, you’ve found my blog, so I’ll assume you have experience with Autopilot or at least know what it does. If you want to know more, please follow the link: Overview of Windows Autopilot | Microsoft Learn

There are three ‘common’ Autopilot provisioning modes, User-driven deployment mode, Self-deploying mode and pre-provisioned deployment mode, which is also called the ‘white glove experience’. Before choosing a deployment mode, we must first understand the environment, which in most cases is a hybrid environment (On-prem AD with group policies applied locally). A hybrid environment dictates the deployment mode as Microsoft doesn’t recommend the Pre-provisioned deployment mode for new devices that you want to hybrid join to a domain. This doesn’t mean you can’t; you can with a caveat, the caveat is additional complexity, and you should expect technical issues to arise.

Self-deploying mode

Does what it says on the tin, primarily used for Kiosk devices with no primary user assignment. My opinion, it’s not utilized much because the service desk or helpdesk who provision devices tend to stick to one deployment method out of convenience. The self-deploying mode does not hybrid join a device therefore an MDM solution is required to manage it.

Pre-provisioned deployment mode (White Glove)

This mode is when the device is partially enrolled with device context apps installed first; domain joined then packaged by IT and sent to the end-user. The end-user then finishes the enrollment process by signing into the device with their credentials. At this point, user-context apps and policies are applied.

I call this mode the ‘Off Branch User-Driven Deployment Mode’ because this deployment mode won’t work without the User-driven deployment mode configured correctly. I know, it’s confusing, right? I recently deployed Autopilot for a large Government organization, and it was impossible to explain this without illustrating it in a process flow diagram.

Green arrows = Pre-provisioned deployment mode
Red arrows = User-driven deployment mode

User-driven deployment mode

I intentionally left the User-driven mode to the end because, well, hear me out. *Deep Breath* ‘Employers don’t want their non-IT employees driving the Autopilot deployment!’ When speaking with clients, they want to keep everything as it was before but speed up the device provisioning process for the IT Team. IT do all the work in the background and hand over the device to the end-user; the end-user signs in with their credentials and away they go. Yes, there are use cases like when an employee is fully remote, but even then, employers want the device configured, domain joined, checked over and then shipped to the employee. Employers don’t want their employees clicking through the enrolment status page (ESP), they want them to simply sign into their device like everyone else. In my experience, the Pre-provision deployment mode (white glove experience) is generally used when there’s a delay in the employee onboarding process or there’s a surplus of devices in stock that the IT Team want to partially provision before a user account is assigned to the device.

My Opinion

*Deep Breath* ‘Remove the Pre-provisioned deployment mode’. This mode is only necessary when there’s no Intune licensed user assigned to the device. IT Teams are already using their own accounts to complete the Autopilot user-driven deployment process, because it’s convenient for them. When this occurs the IT Admin changes the primary user and management name on the device properties page in Intune.

To simplify this process, Microsoft could introduce an Autopilot Deployment Manager like they introduced the Intune Device Enrolment Manager (DEM) to solve enrolment difficulties for unlicensed users/devices.
My First Blog Post

December 27, 2025

Hi everyone and welcome to my website and my first blog post. I’m starting a blog to share my knowledge with like-minded IT professionals in the Microsoft community and further afield.

What content to expect?

I intend to write about modern workplace technologies, Intune, Copilot, Azure, Power Automate and all-encompassing technologies in the Microsoft 365 space. I’m passionate about Intune, Copilot and automation, so more on these topics.

Are you tired of paragraphs upon paragraphs of introductions to subjects you’re familiar with?! I am too, so I hope you enjoy my, zero fluff, to the point, content.

Please subscribe to stay notified when I next release a blog.