The Journey to Passwordless in a Hybrid Microsoft Environment (Phase 3, 4 & Beyond)
Phase 3: Reducing Password Dependency — Suppressing the Old Habit
With passwordless credentials deployed and users beginning to adopt them, the enterprise must now actively suppress password usage across its environment. Having a Hello for Business credential or Authenticator app registered is not enough if users still routinely type passwords into applications. Phase 3 is about making passwords inconvenient and, eventually, invisible.
The primary lever here is Conditional Access (CA) policies in Microsoft Entra ID (formerly Azure AD). These policies can be configured to require a phishing-resistant authentication method — such as Windows Hello for Business, FIDO2 keys, or certificate-based authentication — for specific applications or for all cloud access. For example, you might start by enforcing passwordless-only login for your highest-risk or highest-value applications: finance systems, HR platforms, privileged admin portals. This forces users of those applications to have enrolled and actually use their passwordless credential, because attempting a password login will simply be blocked. Conditional Access reporting also gives you a clear audit trail of who is still falling back to passwords and where — a useful signal to drive targeted remediation.
Alongside Conditional Access, the enterprise should modernize or retire legacy authentication protocols that cannot support passwordless. Applications still relying on basic authentication, NTLM, or legacy LDAP binds are a common stumbling block in hybrid environments. Microsoft has been progressively deprecating basic auth in Exchange Online and other services for good reason — these protocols pass credentials in ways that are fundamentally incompatible with a passwordless world. The work here involves either migrating such applications to support OAuth2/OIDC (through app re-platforming or wrapping with an authentication proxy) or, in some cases, making a business case to retire the application altogether. In a global enterprise, this is often the most time-consuming part of the journey, but it cannot be skipped. Legacy apps are the gaps through which password dependency creeps back in.
Another area requiring attention during this phase is privileged access. Administrative accounts are particularly high-value targets, and they are also where password use tends to persist longest — administrators often need to access management consoles, run scripts, and use tools that traditionally demand password credentials. The answer here is a combination of Privileged Identity Management (PIM) in Entra ID (to enforce just-in-time privileged access with strong authentication), alongside ensuring that administrative jump servers or Privileged Access Workstations (PAWs) are enrolled with Windows Hello for Business. Service accounts and non-interactive logins also need attention: managed identities and workload identity federation can replace many of the service account password patterns in Azure-native workloads, while on-premises service accounts may need to be migrated to Group Managed Service Accounts (gMSAs), which have automatically rotating credentials that no human ever sees or types.
The measure of success for Phase 3 is tangible: the proportion of logins using passwords should be in clear decline in your sign-in logs. Helpdesk password reset ticket volumes should be dropping. These are not vanity metrics — they reflect real reduction in attack surface and operational overhead.
Phase 4: Password-Free — Removing the Password Entirely
The final phase is the most symbolically significant: removing the password from user accounts entirely. In Microsoft’s model, this is described as making the account “password-free” — the user’s Azure AD or hybrid identity no longer has a usable password at all.
In Entra ID, this can be achieved by enabling the “Enable passwordless sign-in” setting on individual accounts and eventually at a policy level. For cloud-only accounts, this can be done today; the account is converted so that password authentication is not permitted, and only registered passwordless methods work. For hybrid-joined accounts still tied to on-premises Active Directory, this is more nuanced. AD accounts still have passwords under the hood (the on-premises directory still stores a password hash), but with Entra ID Cloud Trust for Kerberos, users with Windows Hello for Business credentials can obtain Kerberos tickets for on-premises resources without ever needing to use or know their AD password. The practical experience for the user is already password-free even if the technical artefact of a password hash persists in AD — and over time, as organizations complete their cloud migration journey, even that vestige can be eliminated.
It is worth being honest that complete password elimination is a long-tail effort for most global enterprises. Edge cases are plentiful: legacy applications that could not be modernized in Phase 3, manufacturing floor terminals using shared accounts, contractor onboarding workflows that assume password provisioning, emergency break-glass admin accounts, and so on. Each of these needs a specific plan — whether that is a documented exception with compensating controls, an alternative passwordless method (physical FIDO2 key for a shared terminal, for example), or a time-boxed decommission plan. Perfect should not be the enemy of good here. An enterprise where 95% of logins are passwordless and the remaining 5% are tightly controlled, monitored, and on a retirement roadmap is in a dramatically stronger security posture than one waiting for 100% perfection before calling the initiative a success.
Real-World Challenges: What the Textbook Doesn’t Tell You
No honest account of a passwordless implementation would be complete without acknowledging the friction points that make this harder in practice than in a Microsoft whitepaper.
User resistance and change fatigue are real. Some users, particularly in regions with lower smartphone penetration or where organizational culture around IT change is more cautious, will resist the shift. The Authenticator app requires a personal or corporate smartphone — what about users who don’t have or don’t want to use a personal device for work? The enterprise needs clear answers: provide corporate-managed phones, offer FIDO2 keys as an alternative, or accept that certain user cohorts will need different credential strategies. Communication and training matter enormously. Users who understand why the change is happening — that passwords are the most common cause of breaches, that this is about protecting them and the organisation — are far more cooperative than those who experience it as IT imposing inconvenience.
Hybrid complexity is underestimated. The cloud side of a hybrid environment often goes smoothly; it’s the on-premises side that creates surprises. Kerberos dependencies, smart card middleware, LDAP-bound applications, and NPS (Network Policy Server) configurations for VPN and Wi-Fi — all of these can require significant engineering work to support passwordless flows. Azure AD Cloud Trust for Kerberos has simplified some of this, but it requires domain controllers to be running Windows Server 2016 or later and to have the Azure AD Kerberos object provisioned correctly. In a large global enterprise with dozens of Active Directory sites across different geographies, ensuring this is consistently configured and that replication is healthy is non-trivial.
Recovery and fallback design is often an afterthought that becomes critical in production. What happens when a user loses their phone and needs to access work systems on a Monday morning from a hotel in another country? What if a laptop TPM fails and Windows Hello credentials are wiped? The enterprise needs well-designed, secure recovery flows — temporary access passes (TAP) in Entra ID are designed exactly for this, providing a time-limited, one-time code that allows re-enrollment without requiring a password. But these flows need to be operationalised into the helpdesk process, and the helpdesk staff need to know how to issue a TAP securely (verifying identity through other means before doing so) to avoid creating a new social engineering attack vector.
Governance and audit trails need updating. Moving from password-based authentication changes what authentication events look like in SIEM and audit logs. Security operations teams need to update their detection rules: for example, impossible-travel alerts or brute-force detection logic written against password login events may not fire correctly against WHfB or FIDO2 logins. Audit logging of Entra ID sign-ins, device compliance states, and phishing-resistant credential usage should be reviewed and updated as part of the programme — not bolted on afterwards.
Measuring Success: A Passwordless Scorecard
Tracking progress on a multi-phase initiative requires meaningful metrics. A useful passwordless scorecard for a global hybrid enterprise might track:
Security outcomes — reduction in credential-based incidents (phishing attempts that succeeded, account compromises), percentage of logins using phishing-resistant methods (visible in Entra ID sign-in logs filtered by authentication method), and reduction in password-spray or credential-stuffing alerts in the SIEM.
Operational efficiency — volume of helpdesk password reset tickets over time (this should show a clear downward trend), time-to-onboard new users (passwordless enrollment can actually be faster once the process is mature), and number of legacy applications still requiring passwords (a metric that should trend towards zero).
User experience — periodic pulse surveys asking users to rate their login experience, or CSAT scores from helpdesk interactions related to authentication. Anecdotally, most organisations report that once users are past the initial enrollment, they prefer passwordless. “I just tap my finger and I’m in” is a significantly better experience than being prompted to change a password every 90 days.
Coverage — percentage of users enrolled in at least one passwordless method, percentage of applications covered by a Conditional Access policy requiring phishing-resistant authentication, and percentage of privileged accounts with no standing password.
Looking Ahead: Passkeys, Post-Quantum, and the Identity Perimeter
The passwordless journey does not end when you hit your Phase 4 milestones. The threat landscape and the technology stack continue to evolve.
Passkeys — the consumer-friendly FIDO2 credential standard backed by Apple, Google, and Microsoft — are increasingly being adopted in enterprise contexts as well. Unlike traditional WHfB credentials, passkeys can sync across devices (through the vendor’s cloud, such as iCloud Keychain or Google Password Manager), which changes the recovery story significantly and may ease some of the UX friction around device loss. Microsoft Entra ID already supports passkeys (including device-bound and synced passkeys) as an authentication method, and it is likely that passkeys will become the dominant credential type for many user populations over the next few years.
Post-quantum considerations are also beginning to enter the picture. As discussed in earlier writing on this blog, the cryptographic foundations of current asymmetric key systems — including those underpinning FIDO2 and Windows Hello — are potentially vulnerable to future quantum computers. NIST finalised its first post-quantum cryptography standards in 2024, and it is only a matter of time before these begin appearing in identity and authentication protocols. Enterprises investing in passwordless infrastructure today should ensure their roadmaps acknowledge this horizon and that vendor choices (Microsoft, YubiKey, etc.) are being evaluated for post-quantum readiness.
The identity perimeter itself is evolving. Continuous Access Evaluation (CAE) in Entra ID allows access tokens to be revoked in near-real-time when risk signals change — for example, if a user’s device goes out of compliance or an anomalous location is detected, active sessions can be cut immediately rather than waiting for token expiry. This kind of dynamic, risk-based enforcement is only possible because the authentication layer has become rich and cryptographically strong. Passwordless authentication is not the finish line for enterprise identity security — it is the foundation that makes the next generation of Zero Trust controls actually workable.
Conclusion: The Journey Is the Point
The arc of this series has taken us from the pain of passwords — the breach statistics, the helpdesk burden, the compliance gaps — through the history of how we got here, and into the practical reality of what it takes to change. Phases 1 through 4 provide a framework, but in practice the journey is iterative, messy, and organisation-specific. There is no clean “done” state.
What does hold true across every organisation undertaking this is that the fundamentals matter: invest in the identity plumbing first, bring users along through communication rather than mandate alone, design recovery flows before you need them, and treat legacy application modernisation as an identity project as much as an application one.
The enterprise that reaches a state where the vast majority of its users never type a password — where authentication is something that happens seamlessly and securely in the background through a biometric gesture or a tap — will have meaningfully reduced its attack surface, improved the day-to-day experience of its people, and freed IT teams from one of their most thankless recurring tasks.
It is a journey worth taking. And with the tools available in the Microsoft ecosystem today, it is more achievable than it has ever been.
+ There are no comments
Add yours