Shared Hybrid Windows Devices with Intune, FIDO2, Web Sign-in, and Cloud Kerberos Trust

How to deploy secure shared Windows devices using Microsoft Intune, FIDO2 security keys, Web Sign-in, Temporary Access Pass, Microsoft Entra ID, and Cloud Kerberos Trust while maintaining a modern passwordless experience for multi-user environments.

The Challenge

Many organizations have environments where multiple employees use the same physical workstation. Manufacturing floors, warehouses, reception areas, training rooms, clinical work areas, and operational workstations often require secure access without dedicating a separately assigned workstation to every individual user.

Traditional shared-device deployments typically depend on usernames and passwords. That model often creates password resets, account lockouts, shared credential risk, inconsistent sign-out behavior, and additional administrative overhead. As organizations move toward Zero Trust and passwordless authentication, these shared-device scenarios require a more deliberate identity and endpoint design.

A modern solution can combine Microsoft Intune Shared PC Mode, FIDO2 security keys, Web Sign-in, Microsoft Entra ID authentication, Temporary Access Pass for onboarding, and Cloud Kerberos Trust for hybrid resource access. Together, these technologies can provide a secure, manageable, and scalable experience for multi-user Windows devices.

Practical outcome The goal is not simply to remove passwords from the logon screen. The goal is to create a shared-device model where users authenticate with their own phishing-resistant credentials, support teams can manage the device lifecycle through Intune, and hybrid organizations can preserve access to required on-premises resources.

Architecture Overview

In many environments, shared Windows devices are Microsoft Entra joined or hybrid Microsoft Entra joined, enrolled into Intune, and configured using Shared Multi-User Device policies. Organizations that still depend on traditional Active Directory resources can leverage Cloud Kerberos Trust to maintain access to domain-backed resources while adopting modern passwordless authentication.

Rather than authenticating with passwords, users sign in with their own FIDO2 security keys or other supported passwordless methods. Authentication occurs through Microsoft Entra ID, while Cloud Kerberos Trust helps bridge modern cloud authentication to on-premises Kerberos-based access patterns where required.

This architecture is especially useful for organizations that are moving toward cloud-first endpoint management but still need practical access to file shares, printers, line-of-business systems, intranet applications, or other resources that depend on traditional Active Directory.

Guardrail: Avoid assuming every deployment must be hybrid joined Hybrid identity does not automatically mean every workstation must be traditional domain joined. Depending on the use case, organizations may evaluate Microsoft Entra joined, hybrid Microsoft Entra joined, shared PC, kiosk, Cloud PC, or other managed endpoint patterns. The join model should be selected based on application dependencies, access requirements, supportability, and security posture.

Configuring Shared Device Mode

Microsoft Intune includes Shared Multi-User Device settings that configure Windows for shared usage scenarios. These settings are designed for devices that may be used by multiple people over time and need stronger lifecycle controls than a standard assigned-user workstation.

Some of the most valuable settings include:

Shared PC Mode.
Automated user profile management.
Storage-based profile cleanup.
Inactive profile removal.
Guest or domain account behavior, depending on the use case.
Power, sleep, and local storage controls.
Multi-user workstation optimization.

One often-overlooked benefit is automated profile cleanup. Shared devices can accumulate many local user profiles over time, consuming disk space and increasing support overhead. By establishing inactivity and disk-space thresholds, Windows can automatically remove stale profiles without administrator intervention.

Operational note Shared PC Mode should be treated as a device lifecycle configuration, not simply a logon preference. Profile cleanup, local storage behavior, power management, sign-out expectations, and support procedures should all be documented before broad deployment.

Enabling Passwordless Sign-In

Shared PC Mode alone does not provide a complete passwordless user experience. A separate configuration profile may be required to expose and guide the desired Windows passwordless authentication behavior.

Through Intune Settings Catalog and related Windows policies, administrators may evaluate:

Windows passwordless experience.
Web Sign-in.
FIDO2 security key sign-in.
Windows Hello for Business, where appropriate.
Temporary Access Pass for onboarding and recovery workflows.

These settings help expose the authentication experiences required for Microsoft Entra-based passwordless sign-in. Without the correct policy configuration and platform eligibility, users may not see the expected sign-in options on the Windows logon screen.

Guardrail: Validate Web Sign-in eligibility Web Sign-in is not a universal fix for every Windows device state. Administrators should validate Windows version, edition, join type, licensing, network connectivity, and policy eligibility before relying on it for shared-device sign-in. This is especially important when comparing Microsoft Entra joined, hybrid Microsoft Entra joined, and traditional domain-joined device scenarios.

Managing FIDO2 Authentication

FIDO2 security keys remain one of the strongest and most practical passwordless authentication methods for shared-device scenarios. Unlike biometric enrollment on a single assigned device, a physical security key can follow the user between supported workstations and provide a portable passwordless experience.

Successful deployments require more than simply issuing a security key. Administrators should ensure:

The user is licensed appropriately for the Microsoft services and endpoint management features in use.
The user is included in the appropriate authentication method policy scope.
The security key model is compatible with the intended authentication scenario.
The security key is registered to the correct user identity.
The user completes key registration before attempting shared-device sign-in.
Help desk teams understand how to validate registration, policy scope, and sign-in errors.

One of the most common support issues occurs when a user possesses a key but has not been included in the authentication method policy. In that scenario, the key may appear functional, but registration or authentication can fail because the user is not actually allowed to use that method.

Guardrail: Treat physical keys as managed credentials FIDO2 security keys introduce strong authentication, but they also introduce hardware lifecycle responsibilities. Organizations should define key issuance, inventory, replacement, loss, theft, return, and revocation processes before deployment reaches production scale.

Using Temporary Access Pass for Onboarding

Passwordless rollouts frequently run into an onboarding challenge: a user needs a strong authentication method to register a strong authentication method. Temporary Access Pass helps solve that bootstrapping problem.

Temporary Access Pass is a time-limited passcode that can be used to register passwordless authentication methods such as FIDO2 security keys. It can also support recovery scenarios when a user loses access to a previously registered strong authentication method.

In a shared-device passwordless deployment, TAP can be especially useful for:

Initial FIDO2 security key registration.
Onboarding users who do not yet have a usable passwordless method.
Recovering access after a lost, damaged, or replaced security key.
Reducing reliance on permanent password usage during passwordless adoption.

Guardrail: TAP should be governed carefully Temporary Access Pass is powerful and should be controlled with policy, limited validity, documented help desk procedures, and appropriate administrative roles. It should not become an informal workaround for weak onboarding or poor recovery planning.

Why Cloud Kerberos Trust Matters

A common challenge with passwordless deployments in hybrid environments is maintaining access to traditional Active Directory resources. Many organizations still depend on Kerberos for file shares, print services, intranet applications, and legacy line-of-business systems.

Cloud Kerberos Trust addresses this problem by allowing modern Microsoft Entra-based authentication scenarios to support access to on-premises Kerberos resources. This allows organizations to adopt a more modern passwordless model without immediately abandoning existing Active Directory investments.

This approach can reduce some of the complexity historically associated with certificate-based authentication models and provides a practical path for hybrid organizations that want to move toward passwordless authentication while preserving business-critical access.

Guardrail: Cloud Kerberos Trust still requires planning Cloud Kerberos Trust should be validated against domain controller readiness, Microsoft Entra Kerberos configuration, privileged account restrictions, network path requirements, and the specific resources users must access. It is not a substitute for testing hybrid application dependencies.

User Session Governance

Shared passwordless devices have a different risk profile than assigned-user laptops. The authentication method may be strong, but an unattended authenticated session can still create operational and security exposure.

Organizations should define session expectations for shared workstations, including:

Required sign-out behavior at the end of a shift or task.
Inactivity timeout and lock-screen policies.
Browser session handling and cachedly signed out or whose local profile is removed.

Real-world lesson Passwordless authentication reduces password risk, but it does not remove the need for endpoint hygiene. Shared devices still need clear sign-out behavior, session controls, storage management, and monitoring.

Recovery and Break-Glass Planning

Any passwordless deployment should include a documented recovery model. This is especially important for shared devices because a single authentication failure can affect shift work, front-line operations, reception coverage, training schedules, or other time-sensitive workflows.

Recovery planning should account for:

Lost, stolen, damaged, or forgotten FIDO2 security keys.
Users who never completed initial FIDO2 registration.
Users who were not included in the correct authentication method policy.
Devices that have not received the required Intune configuration profiles.
Temporary Access Pass issuance and identity verification procedures.
Emergency access accounts that are protected, monitored, and excluded from routine use.
Business continuity procedures when passwordless sign-in is unavailable.

Guardrail: Do not skip recovery testing A passwordless deployment is not production-ready until onboarding, lost-key replacement, account recovery, policy rollback, and emergency access procedures have been tested with support teams.

Operational Lessons Learned

During deployment and support, most issues tend to fall into a handful of categories:

Missing device group membership.
Incomplete Intune profile assignments.
Users excluded from FIDO2 or Temporary Access Pass policy scope.
Licensing mismatches or unvalidated entitlement assumptions.
Delayed policy synchronization.
Incorrect FIDO2 key registration.
Unsupported Windows build, edition, or join state for the expected sign-in method.
Cloud Kerberos Trust configuration or domain controller readiness concerns.
Unclear help desk procedures for onboarding and recovery.

In practice, troubleshooting usually starts with the basics: confirm device enrollment, validate group membership, check policy assignment, verify user eligibility, confirm the authentication method registration, and then investigate deeper identity or hybrid resource access issues.

Recommended troubleshooting order Start with assignment and eligibility before assuming the authentication technology is broken. In many cases, the issue is a missing group, a policy not yet applied, an unsupported device state, or a user who has not completed registration.

Support and Governance Considerations

Shared passwordless devices introduce a different operational model than traditional assigned-user workstations. Support teams should understand that local user profiles may be automatically removed as part of the device lifecycle and that these systems are designed to be shared resources rather than individually assigned computers.

Organizations should establish governance around:

FIDO2 key issuance, replacement, return, and revocation.
Temporary Access Pass issuance and approval workflows.
User onboarding and offboarding.
Authentication method policy management.
Shared-device lifecycle management.
Cloud Kerberos Trust administration.
Profile cleanup and local data expectations.
Session timeout and sign-out standards.
Break-glass and emergency access procedures.
Documentation for help desk and endpoint support teams.

Licensing reminder Licensing requirements for Microsoft Intune, Microsoft Entra ID, Windows capabilities, passwordless authentication features, and related management functionality should be validated against current Microsoft licensing guidance before deployment. Feature entitlements and licensing bundles can change over time.

Final Thoughts

Shared Windows devices have historically required a compromise between usability and security. The combination of Intune Shared Device Mode, Microsoft Entra ID, FIDO2 security keys, Web Sign-in, Temporary Access Pass, and Cloud Kerberos Trust changes that equation.

Organizations can now design shared workstations that reduce password dependency, improve authentication strength, support modern endpoint management, reduce avoidable support tickets, and still maintain access to traditional Active Directory resources when required.

For environments with manufacturing workstations, training rooms, warehouse terminals, reception systems, clinical stations, or other multi-user endpoints, this architecture provides a practical path to modern passwordless computing without forcing a disruptive overnight redesign of every hybrid dependency.

Bottom line The best shared passwordless deployments are not just identity projects. They are endpoint, identity, help desk, governance, and user experience projects working together.

References

The following Microsoft Learn resources are useful starting points for validating design decisions, prerequisites, and configuration options: