Introduction
This article is a follow-up to my previous post on Microsoft Entra Authentication Methods, and this time I’m taking the next step in the identity journey. In this post, I focus on a real-world scenario: Rolling out phishing-resistant MFA in a hybrid enviroment.
You can expect a practical walkthrough of the considerations, challenges, and decisions that come with moving from traditional MFA to methods like FIDO2, passkeys and Windows Hello for Business – all based on what actually happens in the field.
Why Phishing-Resistant MFA Matters
Before diving into architecture and rollout, it’s important to understand why this shift is necessary.
Traditional MFA (push notifications, OTPs) is no longer sufficient against:
- Adversary-in-the-middle (AiTM) attacks
- Token theft
- MFA fatigue / push bombing
Phishing-resistant MFA changes the game:
- Authentication is cryptographically bound
- Credentials are not replayable
- There is no shared secret to phish
This is not just “stronger MFA” — it’s a different security model.
The Hybrid Challenge (Where It Gets Hard)
In cloud-only environments, this transition is relatively straightforward.
In hybrid environments, it becomes significantly more complex.
Identity complexity
- On-premises AD vs Microsoft Entra ID
- PRT dependency and token flow
- Kerberos vs modern authentication
Application landscape
- Legacy protocols (NTLM, LDAP, SMB, RDP)
- Modern apps (SAML, OAuth, OIDC)
Device states
- Domain-joined
- Hybrid-joined
- Entra-joined
👉 This is the point where many “simple” designs stop working.
Defining the Target State
Before configuring anything, you need to define what success looks like.
Example target state:
Phishing-resistant MFA enforced for all cloud access- Passwordless sign-in for privileged users
- Controlled fallback for legacy scenarios
Break it down:
| Area | Target |
| Interactive login | Windows Hello for Business |
| Web/cloud apps | FIDO2 / passkeys |
| Admin access | Phishing-resistant only |
| Legacy apps | Controlled exceptions |
Without a clear target, rollout decisions become inconsistent.
Choosing Authentication Methods
This is where theory meets design choices.
Windows Hello for Business (WHfB)
Best suited for:
- Hybrid environments
- Corporate devices
Considerations:
- Key trust vs cloud trust
- Dependency on device state and PRT
FIDO2 Security Keys / Passkeys
Best suited for:
- Strong phishing resistance
- Cross-platform usage
Considerations:
- Key lifecycle management
- User experience and training
Passkeys (platform-based)
Best suited for:
- Usability and adoption
Trade-offs:
- Sync vs device-bound security
- Platform dependencies (Windows, iOS,
Android)
In most environments, you end up with a combination, not a single method.
Choosing the Right Trust Model (WHfB)
When working with Windows Hello for Business in hybrid environments, one of the first decisions you have to make is the trust model.
This is also where things can become more complicated than expected — especially if you haven’t worked with it before.
There are three main options:
Certificate Trust
This is the “classic” deployment model.
It relies on:
- AD CS
- User certificates
- PKI infrastructure
In practice, this means:
- Certificate templates
- Auto-enrollment
- CRL availability
- Ongoing PKI maintenance
In other words, a lot of moving parts.
When it makes sense:
- You already have a mature PKI
- Certificate-based auth is used elsewhere
- Smart card or legacy certificate scenarios
Why I usually don’t choose it:
- High operational overhead
- More things to break
- Slower to implement in most environments
Key Trust
This removes the need for certificates and instead relies on:
- Public key registration in Active Directory
- Entra ID Connect (formerly Azure AD Connect) syncing those keys
It’s much simpler than certificate trust and avoids PKI.
When it makes sense:
- Hybrid environments without PKI
- You want to avoid certificate complexity
Challenges:
- Depends on proper Entra ID Connect configuration
- Still tightly coupled to on-prem AD
- Troubleshooting can be less intuitive
Cloud Kerberos Trust (Recommended in most cases)
This is the newer model — and in my experience, the easiest to work with in modern environments.
It works by:
- Leveraging Microsoft Entra Kerberos (formerly Azure AD Kerberos)
- Removing the need for certificates or key sync
- Enabling access to on-prem resources using cloud-issued tickets
This simplifies a lot of the traditional hybrid dependencies.
Why I prefer this:
- No PKI required
- Minimal dependency on AD DS schema/config changes
- Easier to deploy and troubleshoot
- Much better alignment with cloud-first identity
So, which one should you choose?
In most cases:
Go with Cloud Kerberos Trust
Not because the others are wrong — but because:
- It has the least operational overhead
- It aligns best with a modern identity strategy
- It removes entire classes of issues (PKI, key sync, etc.)
Takeaway
Windows Hello for Business is not just about the authentication method — it’s about how trust is established between:
- The device
- The user
- And your identity platform
Choosing the right trust model early on will remove a lot of friction later in the rollout.
Implementing Cloud Kerberos Trust (What you actually need to configure)
Once you’ve decided to go with Cloud Kerberos Trust, the next step is understanding what actually needs to be configured — both in Intune and on-premises.
Compared to the other trust models, the setup is relatively lightweight, but there are still a few critical dependencies.
On-premises configuration
The most important component is Microsoft Entra Kerberos.
This is what allows Entra ID to issue Kerberos tickets that can be used to access on-premises resources.
At a high level, this involves:
- Creating the Microsoft Entra Kerberos server object in Active Directory
- Ensuring at least one writable domain controller is available
- Running the Cloud Kerberos trust setup via PowerShell
This step is often overlooked, but without it, Windows Hello for Business cannot be used to access on-prem resources.
Intune policy configuration
On the Intune side, you need to deploy a Windows Hello for Business policy.
Key settings:
- Use Windows Hello for Business: Enabled
- Trust model: Cloud Kerberos trust (This is the important one)
- Require PIN / biometrics: Enabled
- Use security keys for sign-in: Optional (depending on your strategy)
The policy should be scoped carefully — ideally starting with a pilot group.
Important:
This is not just about enabling WHfB — it assumes that:
- Devices are properly hybrid joined
- Users receive a Primary Refresh Token (PRT)
- The device can reach Entra ID during sign-in
If those conditions are not met, the deployment will fail silently or behave inconsistently.
Enrollment Strategy
This is where many rollouts fail — not due to technology, but process.
Key considerations:
- Pilot group first (always)
- Admin accounts first (high impact, low volume)
- Phased rollout by user segment
Also:
- How users enroll methods
- What happens if they don’t
- What your fallback strategy is
👉 Enrollment is a user journey, not just a technical step.
Conditional Access Design
Phishing-resistant MFA is primarily enforced through Conditional Access.
Phase 1 – Visibility
- Report-only policies
- Identify impact
Phase 2 – Controlled enforcement
- Target admins first
- Require authentication strength
Phase 3 – Broader rollout
- Expand to users and critical apps
- Replace legacy MFA policies
👉 Poor scoping here can break access very quickly.
Common Pitfalls
From experience, these are the most common issues:
- “PRT = NO” → authentication fails silently
- MFA enforced before enrollment → user lockouts
- Device compliance required too early
- Conditional Access scoped incorrectly
- Legacy apps forgotten in design
👉 These are predictable — and avoidable with proper planning.
Operational Considerations
Don’t forget day 2 operations:
- Lost or broken FIDO keys
- New device onboarding
- User support flows
- Recovery processes
👉 A strong design without operational planning will fail over time.
Real-World Lessons Learned
One thing that surprised me during the rollout was how much the success of phishing-resistant MFA depends on the underlying device and identity foundation — not the authentication methods themselves.
In my case, I ran into issues where devices looked fine at first glance, but in reality were not in a healthy state. I started seeing things like:
- AzureAdPrt = NO on otherwise hybrid joined devices
- Devices in Entra ID showing “Pending” instead of a registration timestamp
At the time, I hadn’t done any real validation of the environment beforehand — I assumed that if Hybrid Join was configured and devices were showing up in Entra ID, things would “just work”.
They didn’t.
What I learned from this is that a phishing-resistant rollout will surface issues that may have been hidden for a long time. Things like:
- Incomplete or inconsistent hybrid join
- Devices without a valid PRT
- Enrollment gaps or timing issues
These are not new problems — but they become blocking issues when you move to stronger authentication methods that rely on device trust and token health.
What I would do differently
If I were to do this again, I would spend significantly more time on discovery and validation before rollout.
Specifically:
- Verify that all targeted devices consistently have AzureAdPrt = YES
- Validate that Hybrid Join is fully completed (not just “present in Entra”)
- Identify devices stuck in “pending” or partial registration states
- Test enrollment and authentication flows end-to-end before enforcing anything
How to verify this in practice:
On a client device, run:
dsregcmd /status
This provides detailed information about the device registration and token state.
Key fields to look for:
- AzureAdJoined : YES
- DomainJoined : YES (for hybrid)
- AzureAdPrt : YES
If AzureAdPrt shows NO, the user does not have a valid Primary Refresh Token, which means:
- Windows Hello for Business will not work correctly
- Cloud authentication flows will fail or fall back
- Conditional Access policies may behave inconsistently
This is one of the most common root causes behind failed phishing-resistant deployments.
In other words:
Don’t start with Conditional Access or authentication methods — start with the health of your identity and device foundation.
Takeaway
Phishing-resistant MFA is not just an authentication project.
It’s an identity maturity test.
If there are gaps in your hybrid setup, device registration, or token lifecycle, this is where you will find them.
Conclusion
Rolling out phishing-resistant MFA in a hybrid environment is not just about enabling new authentication methods — it’s about understanding the dependencies behind identity, device state, and access flows.
If there is one thing I would emphasise, it’s this:
Start with a clear target state, but don’t expect to get there in one step.
In an ideal world, phishing-resistant MFA would be enforced for all users across all scenarios.
In reality, most organisations take a more gradual approach.
A common pattern is:
- Rolling out Windows Hello for Business broadly across the organisation
- While enforcing phishing-resistant MFA only for specific accounts, such as:
- Administrators
- Privileged users
- High-risk roles
This is not a compromise — it’s often the most practical way to move forward without breaking existing processes or legacy dependencies.
Even stopping at that point puts you in a significantly better position than where you started.
You reduce the attack surface where it matters the most, while:
- Gaining experience with the technology
- Identifying gaps in your environment
- And preparing for a broader rollout later on
Final takeaway
Phishing-resistant MFA is not an “all or nothing” project.
It’s a journey.
And even partial adoption — if done in the right places — delivers real security improvements.
In the next article,
I’ll take a deeper look at how Conditional Access and authentication strengths
can be used to enforce phishing-resistant authentication in a structured and
scalable way.
