Ever wondered what actually happens when you sign in to Microsoft 365 from a Windows device?
You enter your credentials, Windows signs you in, and suddenly Outlook, Teams, OneDrive and other Microsoft 365 services work without repeatedly asking for your password.
It can look simple from the user’s perspective.
Behind the scenes, however, Microsoft Entra ID is evaluating several signals, including the user’s identity, authentication state and, when applicable, the identity or state of the device.
One of the important components in this process is the Primary Refresh Token (PRT).
I wanted to understand this behavior more deeply, so I built a small lab and tested Microsoft Entra hybrid joined devices, Conditional Access, device filtering and browser-based authentication.
The result exposed an interesting behavior that is easy to miss when troubleshooting Conditional Access.
What is the Primary Refresh Token (PRT)?
The Primary Refresh Token, commonly called the PRT, is an important part of authentication on Microsoft Entra joined and Microsoft Entra hybrid joined Windows devices.
Microsoft describes the PRT as a key component of authentication on these devices. The token is cached on the Windows device and is used to provide Single Sign-On (SSO) to Microsoft Entra protected resources.
In simple terms, you can think about the authentication flow like this:
Windows sign-in > PRT > Microsoft Entra authentication > SSO to protected resources
The PRT also contains information associated with the user and device. Microsoft explains that device, session and authentication claims associated with the PRT can be used by Microsoft Entra ID when making access decisions.
This is why the PRT becomes particularly interesting when we start talking about device-based Conditional Access.
Microsoft Entra Hybrid Join and Conditional Access
A Microsoft Entra hybrid joined Windows device has an identity in both the on-premises Active Directory environment and Microsoft Entra ID.
This allows organizations to continue using traditional domain-based management while taking advantage of Microsoft Entra capabilities such as SSO and Conditional Access.
Conditional Access can use device information as one of the signals when deciding whether access should be granted.
For example, an organization could create a policy that requires:
- Microsoft Entra hybrid joined devices
- Microsoft Intune compliant devices
- Multifactor authentication
- Specific device properties
- A combination of the above
Microsoft specifically supports using device identity as part of Conditional Access decisions.
That leads to an interesting question:
What happens if the Windows device is actually Hybrid Joined, but Microsoft Entra cannot identify that device during the browser session?
That is exactly what I wanted to test.
My Conditional Access Lab
I created a Conditional Access policy targeting Microsoft 365 resources.
The goal was simple:
Personal devices should not receive access unless they satisfy the required device condition, while corporate Hybrid Joined devices should be excluded from the policy.
The logic was essentially:
User │ ├── Corporate Hybrid Joined Device │ └── Excluded from CA policy │ └── Personal / BYOD Device └── Must satisfy required condition
The expectation was straightforward.
If the device is Microsoft Entra hybrid joined and matches my exclusion, the Conditional Access policy should not block the user.
Stage 1: Testing a Personal Device
First, I tested the policy from a personal Windows device that did not have the expected corporate device identity.
The Conditional Access policy was triggered.
Access to the Microsoft 365 resource was blocked because the device did not satisfy the required condition.
This was exactly what I expected.
Stage 1: Working as designed.
So far, nothing unusual.
Stage 2: Testing a Microsoft Entra Hybrid Joined Device
Next, I moved to a Microsoft Entra hybrid joined Windows device.
Based on my policy configuration, this device should have been excluded.
Therefore, I expected:
Hybrid Joined Device ↓Device identified by Entra ID ↓Matches exclusion ↓Conditional Access policy excluded ↓Access granted
But that wasn’t what happened.
The Microsoft 365 application was still being blocked.
That immediately raised another question:
Why is Conditional Access blocking a device that I explicitly excluded?
The Interesting Part: Conditional Access Saw the Device as Unknown
I went into the Conditional Access sign-in details to investigate the policy evaluation.
The important observation was that the device wasn’t being identified in the way I expected.
Instead, the device information was showing as unknown/unavailable during the affected sign-in.
This is where understanding the difference between device state and device authentication during a particular session becomes extremely important.
The Windows device itself can be correctly registered as Microsoft Entra hybrid joined.
The user can have a valid PRT.
And yet a particular browser session may not successfully provide the device information required by Conditional Access.
Those are not contradictory statements.
Is the PRT Broken?
This was the first thing I wanted to rule out.
On the Hybrid Joined device, I checked the registration and authentication state using:
dsregcmd /status
Microsoft recommends using dsregcmd /status to troubleshoot Microsoft Entra hybrid join and PRT-related authentication problems. The SSO State section includes the AzureAdPrt value.
For example:
SSO StateAzureAdPrt : YES
A valid PRT helped establish that the Windows authentication state itself wasn’t the obvious problem.
So the investigation moved toward the browser.
The Browser Was the Missing Piece
This is where the behavior becomes much more interesting.
Microsoft Entra Conditional Access doesn’t simply look at the Windows device and assume that every browser request automatically contains the device identity.
For supported browsers, device authentication is used so the device can be identified and validated against Conditional Access requirements.
Microsoft explicitly documents that the device check can fail when:
- The browser is running in private mode
- Cookies are disabled
- The browser isn’t configured correctly for device authentication
Microsoft also documents specific browser requirements for device-based Conditional Access.
And this is particularly important for Microsoft Edge.
Microsoft states that Microsoft Edge InPrivate mode isn’t considered a Microsoft Entra hybrid joined device for the relevant Conditional Access control.
That explains why a Hybrid Joined Windows device can behave differently depending on how the browser session was started.
Why Does InPrivate Mode Matter?
Consider this example.
Your Windows device is:
Microsoft Entra Hybrid Joined +Valid PRT +Corporate Windows device
You open a normal browser session.
The browser can perform the necessary device authentication, allowing Microsoft Entra ID to identify the device.
Conditional Access can therefore evaluate the device information.
Now compare that with:
Microsoft Entra Hybrid Joined +Valid PRT +Edge InPrivate
The underlying Windows device hasn’t suddenly become unmanaged.
It is still Hybrid Joined.
The PRT hasn’t magically disappeared.
Instead, the browser session isn’t providing the device authentication signal required for the Conditional Access device check.
Microsoft documents this behavior directly.
This is an important distinction.
Device Identity vs Browser Device Authentication
This is probably the biggest takeaway from my lab.
It’s easy to think:
My device is Hybrid Joined, therefore Conditional Access must always know that it is Hybrid Joined.
That’s not quite how it works.
A better way to think about it is:
Windows Device │ ├── Microsoft Entra Hybrid Joined │ ├── User authenticated │ └── PRT available │ ▼ Browser Session │ ├── Device authentication available │ ↓ │ Device identified │ ↓ │ CA evaluates device │ └── Device authentication unavailable ↓ Device may be unknown ↓ CA evaluation can produce an unexpected result
The PRT helps Windows devices sign in to Microsoft services without asking for credentials again.
A Hybrid Joined device may still show as unknown to Conditional Access in some browser scenarios.
Private browsing can prevent Microsoft Entra from getting the device information correctly.
Always check the Conditional Access sign-in logs to see how Microsoft Entra sees the device.
This lab helped me understand how PRT, device identity, browser, and Conditional Access work together.
