Over the past three years, I’ve led passwordless migration initiatives at three Fortune 500 companies, and I can tell you with confidence that eliminating passwords from a hybrid Active Directory and Microsoft Entra ID environment is one of the most rewarding — and most underestimated — technical challenges in modern identity management. The theoretical appeal is obvious: no passwords means no credential compromise, phishing becomes exponentially harder and your security posture fundamentally shifts from “prevent breaches” to “assume breach.” But the reality of implementation in environments spanning on-premises and cloud infrastructure? That’s where the genuine complexity lives.

Most organizations I’ve worked with start this journey with romantic notions of flipping a switch and sailing into a passwordless future. What they discover instead is that achieving true passwordless authentication requires rethinking identity architecture from the ground up. It’s not about swapping one authentication method for another — it’s about fundamentally restructuring how you verify identity across every layer of your infrastructure. The transition demands careful planning, technical rigor and unwavering commitment to security principles over convenience.

Prerequisites: Building the foundation before the migration

Before we can talk about passwordless authentication, we need to address what I call the “prerequisite triangle”: cloud Kerberos trust, device registration and Conditional Access policies. Skip any one of these, and your migration will stall before it gains momentum.

Cloud Kerberos trust is the unsung hero of hybrid passwordless deployments. When I started working on my first full migration, I underestimated how critical this piece was. Traditional Kerberos assumes a managed network with domain controllers you control. Cloud Kerberos allows your cloud-based services to issue Kerberos tickets to hybrid-joined devices without requiring a domain controller on the internet. This is your bridge between on-premises and cloud identity, and it’s non-negotiable for seamless hybrid authentication. The mechanics of Kerberos itself haven’t changed significantly since its introduction in the 1980s, but extending it to cloud environments required a fundamental rethinking of how authentication tickets are issued and validated across trust boundaries.

Getting cloud Kerberos working requires Azure AD Connect to run version 2.0 or later with the cloud sync agent configured for password hash synchronization (even if you’re not using it for authentication — this remains a prerequisite). Your hybrid-joined devices need to be running Windows 10 20H2 or later, and they must have reliable network connectivity to both your on-premises domain controllers and Azure. In one deployment, my team spent two weeks troubleshooting authentication failures before discovering that a firewall rule was blocking the necessary communication on port 88. This single finding reinforced why network validation should occur before pilot rollout, not during.

Device registration and management come next. Every device attempting passwordless authentication must be either Azure AD joined, hybrid AD joined or registered with Entra ID. I’ve found that hybrid-joined devices work best in truly hybrid environments because they maintain connection to on-premises infrastructure while gaining cloud identity benefits. Your Intune Mobile Device Management deployment becomes critical here — devices must be compliant with your policies before they’re trusted for passwordless sign-in. This means ensuring that disk encryption is enabled, that antivirus is running and that devices meet your organization’s baseline security posture. The compliance baseline isn’t punitive; it’s the minimum acceptable security threshold.

Conditional Access policies form the final leg of the prerequisite triangle. These aren’t optional — they’re how you enforce the “trust zero, verify always” principle of Zero Trust. The National Institute of Standards and Technology defines Zero Trust architecture as requiring continuous verification and explicit access grants based on all available data points. I configure policies that require device compliance, enforce multi-factor authentication for sensitive operations, and block legacy authentication entirely. The policy I typically recommend as a starting point requires hybrid-joined devices, compliant Intune status and MFA for all access to on-premises resources, while allowing seamless sign-in for fully compliant devices. This creates a virtuous cycle where security and user experience reinforce each other.

Architecture decisions: Hybrid authentication flows and Windows Hello for Business

Once your prerequisites are in place, you face critical architectural decisions that will shape your deployment for years to come. The primary decision point is whether to use Windows Hello for Business, FIDO2 security keys or phone sign-in as your primary authentication mechanism.

In my experience, Windows Hello for Business is the foundation for hybrid environments. It leverages biometric or PIN authentication on the device itself, preventing credentials from ever being transmitted across the network. When a user signs in with Windows Hello, they’re not sending a password or even a credential — they’re using a private key stored in the device’s Trusted Platform Module (TPM) to prove their identity. For hybrid-joined devices, this works seamlessly because the device can authenticate both to your on-premises domain controller (using cloud Kerberos) and to Entra ID in a single operation. This eliminates the attack surface that traditional password-based authentication creates. Organizations seeking more information on passwordless authentication approaches can review guidance from the Cybersecurity and Infrastructure Security Agency, which has published extensive recommendations on moving beyond passwords.

However — and this is crucial — not all devices have TPM 2.0, which is required for the most secure implementations. In one organization where we deployed to 15,000 devices, we discovered that 12% didn’t meet hardware requirements. We ended up implementing a phased approach: Windows Hello for Business on compliant devices, with FIDO2 security keys as the backup for devices that couldn’t support it. FIDO2 keys, which conform to the open FIDO2 standard, are also your answer for scenarios where you need physical authentication tokens — particularly useful for privileged accounts or high-risk scenarios. They’re resistant to phishing and account takeover because possession of the physical token is required. Research from the Identity Defined Security Alliance has shown that organizations using FIDO2-compliant authenticators reduce account compromise incidents by over 90% compared to password-dependent systems.

The architectural decision also includes determining how you handle legacy applications that still require passwords. Your options are limited: implement a passwordless-compatible application gateway, deprecate the application entirely or use Entra ID’s smart lockout and password protection features to reduce risk while you transition. I typically recommend treating legacy application support as a temporary bridge, not a permanent architecture. Organizations that treat this as permanent inevitably find themselves maintaining password infrastructure indefinitely, undermining the entire security posture you’re building.

Migration workflows: The step-by-step reality

The migration itself needs to follow a structured approach that I’ve refined across multiple organizations. Start with a pilot group — I recommend between 50 and 200 users who are willing to accept some friction in exchange for security improvements. This group should include IT staff and security-conscious users who can provide meaningful feedback without becoming frustrated with early-stage issues.

For the pilot phase, configure Windows Hello for Business using Group Policy on your on-premises infrastructure for domain-joined devices, while using Intune policies for cloud-managed devices. Configure Entra ID to require Windows Hello as the preferred authentication method. During this phase, maintain traditional password authentication as a fallback — not because you lack confidence, but because user trust in the system matters. I typically see a three to four week period where you’re supporting both methods while users adapt. This period provides invaluable data about real-world usage patterns and edge cases.

The second phase involves expanding to department-level groups. At this point, you should have identified and documented all the troubleshooting patterns that emerged in your pilot. Common issues I’ve encountered include PIN complexity policies that conflict with Windows Hello configuration, credential caching issues on hybrid-joined devices and confusion around how to recover access when a device is lost or compromised. A well-designed help desk knowledge base at this stage prevents the third phase from becoming a support crisis.

The final phase is organization-wide rollout with password authentication disabled. This is where you must have complete confidence in your fallback mechanisms and your support team’s ability to handle edge cases. I recommend maintaining password authentication for break-glass scenarios (though heavily restricted and logged) for at least 90 days after full rollout. This safety net provides psychological comfort to leadership and creates a genuine escape hatch if something unexpected occurs at scale.

Troubleshooting patterns and lessons learned

After guiding three large-scale deployments, I’ve compiled a list of issues that deserve attention before they become production problems rather than documented solutions.

Device compliance checking often becomes a bottleneck. If your Intune policies are too strict, you’ll have users locked out of passwordless authentication because their devices are non-compliant. The solution isn’t to loosen policies — it’s to automate compliance remediation. Use Intune’s remediation scripts to automatically enable required features and update settings rather than blocking access. When a device becomes non-compliant due to a missing security update, remediation scripts can deploy that update silently, restoring access without support interaction.

Cloud Kerberos ticket refresh failures occur when devices lose network connectivity. I’ve found that users appreciate understanding that brief network outages might require them to use an alternative authentication method temporarily. Documenting this expectation and providing clear error messages reduces support burden significantly. One organization I worked with created a simple status dashboard showing cloud connectivity health, which dramatically improved user confidence in the system.

The Windows Hello PIN reset flow needs careful planning. Users will forget PINs — not because they’re careless, but because they now have one less password to remember and are redirecting that cognitive effort elsewhere. Implement Entra ID’s self-service PIN reset capability, but test it thoroughly in various network conditions. I discovered in one deployment that users couldn’t reset their PIN while offline, which created support tickets even though the feature was technically available online. A simple offline reset option would have eliminated those tickets.

Recovery mechanisms deserve special attention. What happens when a user’s device is stolen? What if the TPM fails? What if they forget their PIN and can’t reach your self-service portal? Document these scenarios and test them with your help desk before full rollout. I’ve found that help desk confidence in recovery procedures directly correlates with user confidence in passwordless authentication.

The endpoint: A genuinely passwordless enterprise

Reaching true passwordless authentication in a hybrid environment means accepting that you’re building a new security model, not just changing how users authenticate. The effort required is substantial, but the security improvement is profound. I’ve watched organizations move from breach-heavy authentication scenarios to Zero Trust architectures where every access request is evaluated in context, and where the compromise of a single device doesn’t cascade into wholesale account takeover.

The passwordless journey isn’t a destination you reach in months — it’s a direction you move in consistently. The organizations that succeed view passwordless migration not as a project with an end date, but as a fundamental shift in how they think about identity and trust. They maintain that momentum by continuously updating policies, expanding coverage to new applications and use cases, and refining their architecture as technology evolves.

The view from the other side is worth the journey. Once you’ve lived in a passwordless environment, going back to password-based authentication feels like removing your seatbelt during a drive. The risk seems obvious in retrospect, and the safety you’ve gained becomes non-negotiable.

This article is published as part of the Foundry Expert Contributor Network. Want to join?

SUBSCRIBE TO OUR NEWSLETTER

From our editors straight to your inbox

Get started by entering your email address below.