How would you structure Conditional Access for a Windows Hello for Business rollout?

Watch the personal device exception. If a phishing site proxies a sign-in from a device that falls under the less restrictive policy, a password and ordinary MFA challenge may still let an attacker capture a session. Requiring Windows Hello for Business only on company devices doesn't close that path.

Map out which users and resources can use the weaker policy, and decide where that access is actually needed. Device compliance requirements can narrow access, but test the phone, personal device and guest scenarios before enforcing them broadly. Phishing-resistant authentication reduces phishing risk, but don't assume it eliminates every form of token theft.

I'd separate policies by purpose rather than packing every exception into two big ones. For example, keep the employee phishing-resistant requirement distinct from the rules for guest access and device compliance. Policies that apply to the same sign-in are evaluated together, so check their combined effect, not just each policy on its own.

Then test your exclusions carefully, including legacy authentication and external sharing. A guest who can't satisfy an authentication strength requirement may need a different policy, but that doesn't mean guest access should be left without appropriate controls.

For phones, look at mobile application management and app protection policies if the goal is to protect company data on personal devices. That gives you an option for managing organizational data without treating the whole phone like a company-owned device. It's a separate decision from which authentication strength to require.

Test the provisioning design as well as the sign-in policies before going beyond the pilot. If your deployment uses certificates, check the certificate authority setup and any intended uses such as wireless or email authentication. Finding a design problem after a broad deployment can mean rework.