Registered, joined, and hybrid joined devices: The place of Windows Hello in this model

1. Core mechanism

Device discussions often combine three different questions: which directory the device is connected to, how the user signs in, and how the device is managed. Registered, joined, and hybrid joined describe the directory relationship; passwords, PINs, biometrics, FIDO2, and Windows Hello for Business describe sign-in methods; MDM, Group Policy, and co-management describe management. Device registration underpins device-based cloud authentication, but registration alone does not establish management or compliance.

Interfaces and specifications

• Microsoft Entra registered (workplace joined): the device is registered with Entra ID, but an organizational account is not required to sign in to Windows. This is common for BYOD and mobile scenarios; ownership can remain with the user, who signs in with a local account. Registration alone does not enroll the device in MDM; device management and app protection are separate controls.
• Microsoft Entra joined: the device is joined to Entra ID; an organizational user signs in to Windows with an Entra account. Local accounts and applicable cached sign-in paths also exist; the join type does not establish online validation of every session. These devices are typically organization-owned; MDM and co-management are separate management configurations.
• A Microsoft Entra hybrid joined device is domain joined to on-premises AD and registered in Entra ID. Device password changes, cached user-password updates and TPM reset require periodic DC connectivity. This does not mean every cloud access stops: after Windows 10/11 hybrid join completes and the user signs in at least once, internet-based SSO to Entra applications remains possible, subject to the password-change exception.
• In the documented device-registration flow, the client sends a discovery request to Azure Device Registration Service (DRS). It creates a 2048-bit RSA device key pair, preferably bound to the TPM, and derives a transport key from the TPM storage root key.
• The registration request carries an ID token, certificate request, tkpub and attestation data. Azure DRS validates the ID token, creates a device ID and device certificate, writes a device object in Entra ID and returns the response. On Windows, MS-Organization-Access is installed in Local Computer\Personal\Certificates for joined/hybrid joined devices and Current User\Personal\Certificates for registered devices. The device ID is visible with dsregcmd.exe /status.
• Windows Hello is a sign-in technology that lets users unlock Windows with a biometric or PIN. Windows Hello for Business is its enterprise version and uses key-based or certificate-based authentication; it can authenticate to Entra ID, Active Directory, or a FIDO v2.0-compatible identity provider.
• Windows Hello for Business combines a device-specific credential with a biometric or PIN gesture as two factors. During provisioning, the user completes multifactor verification and configures a gesture. The PIN stays on the device and has built-in anti-brute-force protection.

Three states, one registration mechanism

Read registered, joined and hybrid joined through two questions. Which account authority supports the organizational Windows sign-in? Registration does not move the existing Windows logon to Entra; an Entra-joined organizational session uses an Entra account, while a hybrid-joined organizational session uses an AD account. Local accounts and cached sign-in are separate paths. Is the device also joined to an on-premises AD domain? Of these three Entra states, only hybrid joined is.

Device registration is the common mechanism behind these device states and supports device-based cloud authentication. The device registers with Azure DRS, receives a device ID and device certificate, and gets a device object in Entra ID. Its presence in Entra ID alone does not show whether it is joined or managed; registered BYOD devices also have device objects.

Where is the key produced, what does it protect?

The documented registration flow creates a 2048-bit RSA device key pair, preferably bound to the TPM. The device uses the private key to prove possession of its device identity. The flow also derives a separate transport key from the TPM storage root key.

Azure DRS validates the registration request's ID token and creates a device ID and device certificate; a device object is created in Entra ID. On Windows, the certificate store depends on the join type: joined/hybrid joined uses Local Computer Personal; registered uses Current User Personal. Device identity is separate from user identity, and Conditional Access can evaluate them as separate inputs.

Device identity and device compliance are separate signals. Registration creates device identity; device management supplies the compliance state. For registered devices, compliance-based Conditional Access requires MDM enrollment such as Intune. App-protection policies are a separate control path.

Windows Hello for Business is a separate axis

Windows Hello for Business is not a device-join state. Join status describes the device's relationship with a directory; Windows Hello for Business describes how the user authenticates. Microsoft Learn describes it as the enterprise version of Windows Hello and documents key-based or certificate-based authentication.

The two factors are not 'a PIN and a password'; they are a device-bound credential and a user gesture. The PIN is a local gesture that does not leave the device and is protected by built-in anti-brute-force safeguards. It is not a reusable symmetric secret that can be taken from a server and used remotely.

Comparing a PIN directly with a password misses this distinction. A password can be used remotely, while the Windows Hello for Business credential is tied to a specific device and uses asymmetric keys. Support depends on platform and configuration; passwordless sign-in is available for supported joined and hybrid joined scenarios.

The device-registration key (dk), transport key (tk) and Windows Hello for Business user credential are separate keys. dk represents device identity; tk is a separate transport key in registration. The public key created during Hello provisioning is mapped to the user account at the IdP. A PIN or biometric gesture locally enables use of the protected Hello credential; it does not unlock dk or send the PIN to the IdP. Hardware and policy determine whether protection uses a TPM or software.

Connecting to the next mechanism

Device join or registration does not by itself determine the Windows Hello for Business trust method. 12.05 compares cloud, key and certificate trust paths and the additional decisions between successful cloud access and an AD resource.

Which operation needs DC connectivity?

Consider a remote Windows 10/11 device with completed hybrid join, a prior user sign-in and internet access. A working cloud application does not prove DC reachability. If the user changes the password outside the corporate network, the device cannot validate the new password without a DC. The old cached password may still permit local sign-in, while Entra rejects the old password in token requests. Local logon and cloud SSO therefore need separate observations.

Microsoft's FAQ documents continued SSO to Entra applications for Windows Hello for Business users after a password change, even without DC line of sight. That exception does not remove dependencies for device passwords, TPM reset or every AD resource. Lesson12.05 separates cloud, key and certificate trust when accessing AD resources.

State and data flow

1. The user or administrator registers or joins the device. A registered device is added through Settings or Company Portal; an Entra-joined device can be joined during OOBE, bulk enrollment, or Autopilot; a hybrid-joined device is first joined to the on-premises domain and then registered with Entra ID according to the configured flow.
2. The client sends a discovery request to Azure DRS and receives tenant-specific URIs. In the documented flow it creates an RSA 2048 device key pair, preferably bound to the TPM, and derives a transport key from the TPM storage root key.
3. The client sends a registration request containing the ID token, certificate request, transport public key and attestation data. Azure DRS validates the token and prepares the device ID/certificate result. In the managed Entra joined example it creates a device object; on the managed hybrid joined path it updates the matching object synchronized earlier. Join and environment prerequisites are checked separately.
4. The client receives the device ID and device certificate. On Windows, MS-Organization-Access is installed in Local Computer Personal for joined/hybrid joined devices and Current User Personal for registered devices. The device ID can then be read with dsregcmd.exe /status.
5. The user signs in through the configured authentication method. With Windows Hello for Business, a PIN or biometric gesture locally enables the user credential to provide identity proof to the IdP. The device-registration key remains separate.
6. When a resource is accessed, user identity and device identity are separate inputs to Conditional Access. Device registration by itself does not decide whether access is allowed.

2. Exploitation

Broken trust assumption

The assumption is “If the device appears in Entra ID, it is managed and secure; hybrid join produces the same trust on both sides because it connects the device to two directories; Windows Hello for Business is also just an easier way to sign in.”

Technical prerequisites

• In the device inventory, join status, administrative status, and login method are combined in a single field; Registered devices are counted in the same category as joined devices.
• For remote hybrid joined devices, DC-dependent password and TPM operations have not been planned separately from cloud SSO.
• The privilege review does not distinguish which object and key belong to device registration versus the Hello user credential.

Exploitation mechanism

Errors arise when three separate decisions are reduced to one label. A device object in Entra ID does not prove management or compliance. Hybrid join does not make cloud SSO equivalent to DC-dependent password and TPM operations. The third distinction is key ownership: registration represents device identity, while the Hello credential represents user identity. Reviewing authority over identity fields requires the target object, attribute and trust method; a generic Write Property ACE does not establish effective write access to a particular key.

Who can change which identity field?

Hello provisioning maps the public key to the user account. In a hybrid path that uses public-key synchronization, the user public key is written to msDS-KeyCredentialLink on the AD user object. This is distinct from DRS creating a device ID and device certificate. Do not conclude that every hybrid trust method requires public-key synchronization; lesson12.05 separates those methods.

A defensive review must identify the target object and attribute scope rather than rely on a delegation's general name. This lesson's synthetic SDDL only illustrates reading permissions; it does not prove effective write access to a device key or Hello key attribute. Such a decision needs the actual descriptor, token, requested right, ACE order and object context.

Lost prerequisites become silent interruptions

Before declaring a remote device unusable, name the failing operation: Windows logon with a new password, device-password renewal, TPM reset or cloud SSO? DC connectivity matters for the first three; cloud SSO has a distinct path after completed hybrid join and a prior sign-in. Ignoring the password-change caveat and Hello exception can incorrectly attribute a working cloud flow to DC connectivity.

A similar prerequisite applies to Windows Hello for Business: provisioning requires additional setup and may not be available on all devices. When setting a policy 'passwordless' target, if it is not written in advance which method is supported in which device states, some of the users will revert to password and the target will remain on paper.

3. Defense & Detection

Telemetry scope

• Keep three fields separate in your device inventory: join status (registered, joined, hybrid joined), management status (MDM, Group Policy, co-management, unmanaged), and sign-in methods used.
• Do not treat the existence of a device object as evidence of device management; record MDM enrollment, compliance state, and app-protection controls separately.
• For hybrid joined devices, record the domain controller access requirement as an availability risk and define a separate plan for remote users.
• Track write delegations on device and user objects in a separate list for attributes that impact authentication.
• Document which device states and on which platforms Windows Hello for Business configuration is active; write fallback method in unsupported scenarios.

Events and relevant fields

• The creation of a new device object may be the result of an expected recording stream; It is not in itself an indication of an unauthorized device and should be read in conjunction with who made the recording.
• On a hybrid joined device with sign-in issues, identify the failing operation and examine DC reachability. Failure to validate a new password locally can differ from a cloud SSO issue; this observation alone neither proves nor rules out an attack.
• The device ID in a device's dsregcmd.exe /status output is used for matching with the device object in the Entra ID; The absence of this match may indicate that the registration is corrupted or registered with a different tenant.
• Authentication-related attribute changes on the user object or device object can be tracked via directory change auditing; The production of these records depends on the appropriate audit policy configuration.
• Access from a registered device does not have the same level of trust as access from a corporate device; Policy evaluation should treat device status as a separate input.

Device inventory requires three columns

A single-column device inventory almost always produces inaccurate results in hybrid environments. Join status indicates which directory the device is connected to; management status shows how the device configuration was enforced; The login method tells which identity material the user is verified with. These three pillars can be changed by different teams, and one does not imply the other.

The practical benefit of the three-column inventory is seen during an incident. 'Was this device being managed?' The question is answered with the management status, not the join status; 'how is the user verified?' The question is with the login method. In a single-column inventory, these questions are left to guesswork.

Passwordless is a scope decision, not a method

Windows Hello for Business is an enterprise extension and its deployment requires additional configuration. So the goal of passwordless advances not by turning on a setting, but by scope decisions: which device states, which platforms, which user groups, and what fallback paths.

If the scope is not written, two typical results occur. First, a portion of users revert to password in unsupported scenarios and no progress is visible in the measurement. Second, as the fallback path remains undefined, the help desk burden increases and the team creates workarounds that weaken security. Both results are related to scope planning, not technology.

Detection logic · KQL

SigninLogs
| where TimeGenerated > ago(7d)
| extend trustType = tostring(DeviceDetail.trustType), deviceId = tostring(DeviceDetail.deviceId)
| summarize signins = count(), users = dcount(UserPrincipalName) by trustType, isCompliant = tostring(DeviceDetail.isCompliant)
| order by signins desc

Query assumptions

• This query is a format example and has not been run on any tenant; The existence and naming of DeviceDetail fields depends on the log connector and version used.
• If the field values ​​are empty, it does not mean that the device is unregistered; Device information may not be reported in some streams.
• The query does not indicate whether the device uses Windows Hello for Business; The authentication method used must be read from separate fields.

False positives

• Some of the devices that appear unmanaged may be in the middle of the registration or sign-up process; Drawing conclusions from a single time period is misleading.
• The same physical device can produce different device objects with different user profiles; When the count is read without deduplication, the inventory becomes bloated.
• Negative example: a seemingly compatible device may have broken down after the compatibility assessment was made; The compliance label is a momentary assessment, not a permanent guarantee.

Hardening

• Use device status as an explicit input in access policies; Do not use the statement 'the device is in Entra ID' as a reason to trust.
• Limit BYOD scenarios to registered status and define application protection policies and compliance requirements for these devices separately.
• Plan domain controller access requirement for hybrid joined devices; If this restriction creates problems, consider the Entra joined model.
• Narrow write delegations on device and user objects according to the principle of least privilege and monitor areas that affect authentication separately.
• Plan Windows Hello for Business deployment based on device status and platform support; Pre-define fallback methods and PIN reset flow.
• Make your passwordless goal measurable: track which method is effective for which user group and the password recovery rate.

Read the examples

O:DAG:DAD:P(A;;RPLCLORC;;;AU)(A;;RPWPCRLCLORC;;;S-1-5-21-4071847660-1138144873-2902452632-1174)(D;;WP;;;S-1-5-21-4071847660-1138144873-2902452632-1175)

Two reality checks

Assumption: When a device appears in Microsoft Entra ID, it means that the device is owned and managed by the organization.

In fact: No. A registered personal device can have a device object in Entra ID, and the user can continue signing in to the device with a local account. Registration is not the same as device enrollment or management: MDM can apply device-level configuration and compliance controls, while app protection can be managed separately. Join status, ownership, and management status are distinct fields.

Assumption: A PIN in Windows Hello for Business is a weaker secret than a password and determines the join status of the device.

In fact: No. Windows Hello for Business uses key-based or certificate-based authentication. Its two factors are a device-specific credential and a biometric or PIN gesture. The PIN stays on the device and is protected by built-in anti-brute-force safeguards; it is not a reusable symmetric secret that can be taken from a server and used remotely. Windows Hello for Business describes a sign-in method, independent of whether the device is registered, joined, or hybrid joined.

Sources

• Microsoft · What are Microsoft Entra registered devices?
  Definition of Registered (workplace joined): no organizational account required to sign in to the device, BYOD and mobile target audience, ownership, signing in with a local account, Conditional Access with Intune enrollment; registration and enrollment not being the same thing.
• Microsoft · What is a Microsoft Entra joined device?
  Entra joined organizational Windows sign-in, device ownership and MDM/co-management options; local and cached sign-in exceptions are described in the device management FAQ.
• Microsoft · What is a Microsoft Entra hybrid joined device?
  Hybrid join definition and periodic DC dependency. Scope qualified by hybrid-join-plan and device FAQ for password, TPM and cloud SSO operations.
• Microsoft · How Microsoft Entra device registration works
  Device Registration being a prerequisite for cloud-based authentication; Azure DRS discovery request; TPM-bound RSA 2048 device key (dkpub/dkpriv) and transport key derived from the storage root key; registration with ID token, certificate request, tkpub, and attestation; device ID, device certificate, Personal store, and dsregcmd.exe /status.
• Microsoft · Windows Hello for Business overview
  Difference between Windows Hello and Windows Hello for Business; key-based and certificate-based authentication; Entra ID, Active Directory, and FIDO v2.0 IdP targets; two factors consisting of a device-specific credential and a gesture; the PIN not leaving the device and brute force protection.
• Microsoft · Device management FAQ
  MS-Organization-Access certificate store: joined/hybrid joined use Local Computer Personal; registered uses Current User Personal. Entra join FAQ: local administrator and cached sign-in paths; hybrid join cloud SSO and periodic DC operation scope.
• Microsoft · Plan hybrid join
  2026-10-03 source review: key ownership, periodic DC operation scope or cloud SSO exception; no native execution.
• Microsoft · How Windows Hello for Business works
  2026-10-03 source review: key ownership, periodic DC operation scope or cloud SSO exception; no native execution.