FROM THE MARKET
Microsoft's Default Isn't Wrong: It's Incomplete
Where Windows Hello for Business stops solving the problem, and what fills the gap
Roman Kuznetsov @ 16.07.2026
Follow Roman Kuznetsov on LinkedIn
If you administer Active Directory in 2026, Microsoft has been telling you the same thing for the better part of a decade: passwordless authentication is the future, the future is Windows Hello for Business, and you should be deploying it. The advice is not wrong. WHfB is a credible passwordless story for the scenarios it was designed for. The trouble is that "the scenarios it was designed for" do not include most of what an AD admin actually has to authenticate.
This piece is an honest reading of where WHfB earns its keep, where it stops, and what fills the gap on a real hybrid estate.
This piece is an honest reading of where WHfB earns its keep, where it stops, and what fills the gap on a real hybrid estate.
What WHfB does well
Credit where credit is due. WHfB is the most polished native passwordless implementation Microsoft has shipped for Windows.
It is almost genuinely multi-factor: the user authenticates locally with a PIN or biometric, which unlocks a TPM-bound private key, which is then used to sign an authentication request. ("Almost", because one factor is dependent on the other; if you are a strict MFA adopter, this could be a problem.) Two factors (knowledge or biometric, plus possession of the TPM-protected key), no shared secret on the wire.
Phishing-resistant in the meaningful sense: there is no credential to capture and replay. Well, maybe PIN is.
It is also, for a particular type of deployment, very low-friction. A user logs into their own laptop with their PIN or face. The laptop is theirs. The credential is bound to that laptop, to that user, to that TPM. The model is clean and ergonomic when the assumption holds.
The assumption is the problem.
It is almost genuinely multi-factor: the user authenticates locally with a PIN or biometric, which unlocks a TPM-bound private key, which is then used to sign an authentication request. ("Almost", because one factor is dependent on the other; if you are a strict MFA adopter, this could be a problem.) Two factors (knowledge or biometric, plus possession of the TPM-protected key), no shared secret on the wire.
Phishing-resistant in the meaningful sense: there is no credential to capture and replay. Well, maybe PIN is.
It is also, for a particular type of deployment, very low-friction. A user logs into their own laptop with their PIN or face. The laptop is theirs. The credential is bound to that laptop, to that user, to that TPM. The model is clean and ergonomic when the assumption holds.
The assumption is the problem.
The three trust models, briefly
WHfB authenticates to Active Directory in one of three trust modes. Cloud Kerberos trust is Microsoft's current recommendation and the only hybrid option that requires no certificates at all, at the cost of a dependency on Entra Kerberos and a Kerberos object synced from the cloud. Key trust writes the user's public key into Active Directory and still needs a PKI as its trust anchor. Certificate trust is the legacy path, retained mainly where an AD CS investment already exists and smart-card-equivalent certificate authentication is required.
But the choice that actually constrains you is not the trust type. It is the deployment model, cloud-only, hybrid, or on-premises, and specifically whether an on-premises-only deployment is viable at all.
It is, on paper. In practice: on-premises deployments must use a multifactor option that integrates as an AD FS MFA adapter. Microsoft's own first-party answer to that requirement no longer exists. MFA Server has not been offered for new deployments since 1 July 2019, and existing MFA Server deployments stopped servicing MFA requests on 30 September 2024. So a pure on-prem WHfB deployment in 2026 means AD CS, plus AD FS, plus a third-party MFA adapter to supply the second factor. Microsoft frames the model's main use case as "Enhanced Security Administrative Environments", Red Forests, and notes that migration from on-premises to hybrid requires redeployment. Meanwhile cloud Kerberos trust does not function in a pure on-premises AD DS environment at all.
The shape of that is worth stating plainly. Microsoft's on-prem passwordless story requires a third party for the second factor, is positioned for a Tier-0 niche, and has no upgrade path, you rebuild.
Cloud Kerberos trust, by contrast, is the easiest path and the one Microsoft pushes hardest. It is also a hybrid model with a cloud dependency baked in: no Entra ID, no WHfB. For shops whose strategy is on-prem-first, that is a structural problem, not a tooling preference.
But the choice that actually constrains you is not the trust type. It is the deployment model, cloud-only, hybrid, or on-premises, and specifically whether an on-premises-only deployment is viable at all.
It is, on paper. In practice: on-premises deployments must use a multifactor option that integrates as an AD FS MFA adapter. Microsoft's own first-party answer to that requirement no longer exists. MFA Server has not been offered for new deployments since 1 July 2019, and existing MFA Server deployments stopped servicing MFA requests on 30 September 2024. So a pure on-prem WHfB deployment in 2026 means AD CS, plus AD FS, plus a third-party MFA adapter to supply the second factor. Microsoft frames the model's main use case as "Enhanced Security Administrative Environments", Red Forests, and notes that migration from on-premises to hybrid requires redeployment. Meanwhile cloud Kerberos trust does not function in a pure on-premises AD DS environment at all.
The shape of that is worth stating plainly. Microsoft's on-prem passwordless story requires a third party for the second factor, is positioned for a Tier-0 niche, and has no upgrade path, you rebuild.
Cloud Kerberos trust, by contrast, is the easiest path and the one Microsoft pushes hardest. It is also a hybrid model with a cloud dependency baked in: no Entra ID, no WHfB. For shops whose strategy is on-prem-first, that is a structural problem, not a tooling preference.
Where WHfB fits naturally
Single-user devices in an Entra-joined or hybrid-joined estate. A knowledge worker with a laptop, where the laptop and the human have a 1:1 relationship that will hold for the device's service life. Field sales staff. Engineers. Executives. The kind of user whose authentication problem is "I am me, on my machine, prove it without a password."
For these users, WHfB is a defensible default. Deploy it.
For these users, WHfB is a defensible default. Deploy it.
Where it stops working
The trouble starts when the assumption breaks. A non-exhaustive tour:
- Shared workstationsWHfB binds the credential to a device-user pair. On a workstation used by twenty users across a shift, every user needs to enrol on every device they might touch, and the enrolment flow itself depends on a password fallback, Microsoft's own documentation states that the built-in provisioning experience accepts the user's weak credentials, username and password, as the first factor. The fallback is the credential the rest of WHfB exists to eliminate. Whatever shared-workstation pattern you build on top of WHfB is going to be a pattern WHfB is fighting, not supporting.
- RDP and session hostsThis is the clearest gap, and Microsoft documents it. Cloud Kerberos trust cannot be used as a supplied credential with RDP or VDI. The supported route is to enrol a certificate into the Windows Hello container specifically for RDP, the same is true for key trust, which requires a PKI based on AD CS or a third party, and, for Entra-joined devices, a certificate on the domain controllers to serve as the clients' root of trust. WHfB then emulates a smart card for application compatibility and prompts for the gesture.
Note what that means. The fix for WHfB's RDP gap is to issue a user certificate and have Windows pretend it is a smart card. The certificate-free promise of cloud Kerberos trust holds exactly until someone needs to RDP into a server.
The alternative is Remote Credential Guard, which provides single sign-on to RDP sessions over Kerberos without deploying certificates, but it carries its own restrictions, and Remote Desktop with biometrics does not work with dual enrolment or where the user supplies alternative credentials. Practitioners running the certificate route report the predictable sharp edges: the RDP client picking the wrong certificate from the store, and only one session at a time being able to use the smart-card credential, which becomes a problem the moment you have more than one RemoteApp host. - Command line and impersonationTwo different things get lumped together here, and the distinction matters.
Paths that inherit the Kerberos TGT are fine. Sign in with WHfB, and PowerShell remoting over Kerberos rides on the resulting ticket without a password. Nobody should claim otherwise.
Paths that require a supplied credential are the problem: runas, runas /netonly, psexec with explicit credentials, MMC and RSAT tools launched as a different user, scheduled tasks running as a user with a stored password. These are the workhorses of operations.
There is a documented WHfB answer here, and it deserves credit: dual enrolment, with a certificate deployed into the privileged account's Hello container, gives you passwordless run-as and passwordless RDP with a PIN instead of a typed password. It works. It also costs AD CS, a certificate template, per-user certificates and a dual-enrolment workflow, and it has documented edges, including that a certificate deployed via Intune combined with User Account Control set to prompt for credentials on the secure desktop breaks the run as feature outright.
So the honest claim is not that WHfB cannot cover these paths. It is that covering them means rebuilding the certificate infrastructure that cloud Kerberos trust was recommended to let you avoid, and then maintaining it alongside the key-trust deployment you already have. - Service desk and break-glassHelpdesk staff who need to perform an operation as a user. Account recovery when a user has forgotten their PIN or replaced their phone. The recovery story for WHfB depends heavily on which trust model you chose and what Entra configuration you have. It is not impossible, but it is a separate workflow from the one your admins are used to, and in the awkward cases it tends to fall back to passwords.
- Pre-boot and offlineWorkstations that need to authenticate before the user, or that operate in environments where Entra ID is unreachable for hours at a time (ships, field sites, secure facilities). Cloud Kerberos trust assumes cloud reachability, and does not function in a pure on-premises AD DS environment at all. Key trust survives the outage, at the price established above.
- Hybrid identity complexityIf your users live in on-prem AD and you want them to use WHfB, you are running Entra Connect. You are accepting a dependency on Entra availability for credential issuance and rotation, and a data-residency question you did not previously have. None of this is unmanageable, but it is the opposite of the on-prem isolation many regulated environments require.
What SystoLOCK does in these cases
SystoLOCK was built for the cases above. The summary of its position relative to WHfB:
- Credential modelBoth eliminate the password as a stored secret. WHfB does it with a TPM-bound key. SystoLOCK does it with a short-lived X.509 certificate issued at authentication time. Both land at Active Directory as a Kerberos ticket, validated through the same mechanism.
- Device bindingWHfB binds the credential to a specific device. SystoLOCK binds the authentication factor, a phone, a token, a badge, to the user, and lets that factor authenticate against any workstation in the estate. This is what makes shared workstations work.
- Cloud dependencyWHfB cloud Kerberos trust requires Entra ID. SystoLOCK does not require any cloud service. The authentication broker runs on-premises, on Windows servers, in the same domain it authenticates against. Air-gapped deployments work the same way connected ones do.
- Command lineThe gap above is a gap SystoLOCK closes at the point Windows asks for a credential. A credential provider extends the supplied-credential dialogue, the same dialogue behind runas, "run as different user," and the RDP client's credential prompt, and swaps in a short-lived certificate issued at that moment. The path Windows takes afterwards is the ordinary one. No dual enrolment, no certificate template, no per-user certificate to plan a lifecycle for.
- CoverageWHfB authenticates Windows interactive logon. SystoLOCK authenticates Windows logon, RDP, command-line impersonation, legacy applications via Kerberos integration, and VPN. The same factor, the same policy engine, across the access-pattern matrix.
- Estate coverageWHfB requires Windows 10 or later and a TPM. SystoLOCK authenticates Windows versions back to Windows 7 and Server 2008. This is not a boast about supporting obsolete software. It is a recognition that the machines nobody can retire, the ones bolted to a lab instrument, the ones running the line, the ones whose vendor dissolved in 2014, are precisely the machines where a password is still the only thing standing between an attacker and the domain. WHfB's answer for those endpoints is that they are out of scope.
- Hybrid identityWHfB assumes Entra Connect. SystoLOCK assumes nothing beyond AD. If your identity lives on-prem and you intend to keep it there, the difference is structural. If you federate to Entra, this is no problem either as SystoLOCK has the necessary connectors there, too.
- EnrolmentWHfB enrols per user, per device. SystoLOCK enrols per user, once, and the user authenticates from any covered endpoint.
What to pick when
The honest recommendation, vendor marketing aside:
For Entra-first or fully cloud-resident estates with single-user devices, WHfB is the right default. Deploy it. Do not overthink it.
For hybrid AD estates where on-prem identity is strategic, where shared workstations exist, where command-line MFA matters for NIS2 or DORA compliance, where RDP is part of the operational mix, or where you cannot accept an Entra dependency on the authentication path, WHfB is going to leave gaps. SystoLOCK was designed to cover those gaps.
The two are not mutually exclusive. WHfB on the laptops, SystoLOCK on the shared workstations, the session hosts, and the privileged-access paths is a defensible architecture. The mistake is assuming WHfB alone is the complete answer just because Microsoft says it is.
For Entra-first or fully cloud-resident estates with single-user devices, WHfB is the right default. Deploy it. Do not overthink it.
For hybrid AD estates where on-prem identity is strategic, where shared workstations exist, where command-line MFA matters for NIS2 or DORA compliance, where RDP is part of the operational mix, or where you cannot accept an Entra dependency on the authentication path, WHfB is going to leave gaps. SystoLOCK was designed to cover those gaps.
The two are not mutually exclusive. WHfB on the laptops, SystoLOCK on the shared workstations, the session hosts, and the privileged-access paths is a defensible architecture. The mistake is assuming WHfB alone is the complete answer just because Microsoft says it is.