Why do passwordless deployments still need device trust and conditional access?

Why device trust still matters after the password disappears

Passwordless changes the login factor, not the trust decision. A passkey or other phishing-resistant authenticator proves the user can satisfy authentication, but it does not by itself prove the endpoint is managed, healthy, or allowed to receive access. device trust fills that gap by adding context about enrolment, posture, and policy before the session is granted.

That distinction matters because many real access decisions are no longer about whether a password was guessed or phished. They are about whether the sign-in came from a known corporate device, whether the device still meets compliance requirements, and whether the session should be limited, stepped up, or blocked based on current risk.

When teams treat passwordless as the whole control, they often stop at stronger authentication and miss the fact that the endpoint is now the main policy boundary. A device can be unmanaged, outdated, or compromised even when the authenticator is strong, so the access decision still needs device-aware policy.

How conditional access turns authentication into a session decision

conditional access is the mechanism that evaluates context after the authenticator succeeds. It can use device compliance, device state, location, sign-in risk, application sensitivity, and other signals to decide whether to allow full access, require step-up verification, or deny the request. That is what makes passwordless suitable for enterprise use rather than just consumer sign-in.

Passwordless also changes the attacker’s path. If a stolen password is no longer enough, attackers shift toward token theft, session abuse, help desk manipulation, or unmanaged endpoints. Conditional access is how you narrow that attack surface by making trust decisions continuously instead of assuming that successful authentication equals safe access.

A practical deployment therefore needs both layers: a strong authenticator to reduce phishing and credential replay, and policy enforcement to distinguish a trusted device from one that merely presents valid credentials. Passwordless and Passkeys Guide covers the authenticator side, while Zero Trust Identity Guide explains why access should be evaluated continuously rather than assumed after sign-in.

What device trust changes for rollout, recovery, and remote access

The biggest implementation mistake is assuming a passwordless rollout can inherit trust from the old login flow. In reality, the rollout has to answer separate questions: how devices are enrolled, how compliance is measured, how unmanaged devices are handled, and what happens during recovery when the preferred authenticator is unavailable.

Device trust becomes even more important for remote access, where the endpoint is outside the corporate boundary and the network itself cannot be trusted. In that setting, device posture often matters more than the authentication factor because the application cannot assume a managed network or a hardened local environment. Remote Access Identity Guide and Device and IoT Identity Guide both reinforce that device trust is a lifecycle control, not just a login setting.

For organisations using Microsoft, Entra ID or similar identity platforms, the practical question is not “do we have passkeys?” but “what access should a passkey unlock when the device is unmanaged, non-compliant, or newly enrolled?” Identity Provider and SSO Security Guide and Active Directory and Entra ID Hardening Guide address the policy side of that decision.

Risk and Threat Considerations

Passwordless lowers the odds of password phishing and reuse, but it can create a false sense of safety if device trust is weak. An unmanaged or compromised endpoint can still open a valid session, let an attacker inherit the user’s authenticated context, and bypass the very password risk the rollout was meant to remove.

Failure mechanism: The organisation authenticates the user successfully but fails to verify that the endpoint is enrolled, compliant, or under management, so access decisions are made on identity alone instead of on trusted device state.

Impact: Attackers, contractors, or personal devices can obtain enterprise access with a legitimate sign-in, which increases exposure to session hijack, data access, and lateral movement even when passwords are no longer in play.

Practitioner Guidance

What to verify: Confirm that conditional access can distinguish managed from unmanaged endpoints and can enforce different outcomes for each. If your policy only checks the authenticator, it is not a complete passwordless control.

Decision rule: If the device cannot be trusted, do not give it the same session scope as a compliant corporate endpoint. Use step-up, limited access, or block decisions based on the business criticality of the application.

What good looks like: A passwordless sign-in should produce an explicit policy outcome, not just a successful authentication event. The desired state is one where device posture, enrolment, and recovery rules are visible and auditable alongside the login itself.

Practitioner takeaway: Passwordless removes a weak factor, but conditional access is what keeps the resulting session from becoming the new weak point.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why does device trust matter for passwordless access?
• What breaks when browser conditional access is not tied to device trust?
• Why does passwordless access still create risk for internal resources after the device is unlocked?