Understanding Sign-In Frequency (SiF) in Hybrid-Joined Environments

Why Enforcement Can Appear Inconsistent for SSO-Integrated SaaS Applications

You’ve set your Sign-In Frequency to 12 hours, but users stay signed in for much longer. You lower it and see the same thing.

At first, it looked like a bug. Maybe Conditional Access isn’t enforced properly, or the policy isn’t being evaluated at all.

In reality, Sign-In Frequency (SiF) is working exactly as designed. It just doesn’t behave the way most people expect. Once you understand how the Primary Refresh Token (PRT) interacts with Entra’s session logic and how SaaS applications manage their own sessions, the picture becomes more nuanced.

Before we get into it, a quick disclaimer: this topic is extraordinarily complex. The way device trust, token issuance, and app session management interact can blur the lines between what’s actually enforced and what appears to be. I’ve spent a lot of time studying this behavior in hybrid-joined environments, but even here, it’s possible some of these nuances aren’t fully captured.

This article explains why enforcement can appear inconsistent, how the PRT silently extends trust, and why users may remain signed in long after your SiF window has expired. Hopefully, it makes it easier to explain to management or clients why SiF isn’t working exactly the way they expected and you actually know what you’re doing.

1. The Layers of Authentication

In a hybrid-joined environment, authentication isn’t a single, linear process. It’s a set of overlapping layers each maintaining its own idea of session validity.

Sign-In Frequency operates entirely within the Entra session layer. It governs when Entra requires a new interactive authentication, not when a device session ends or when a SaaS app expires its cookie.

2. The Primary Refresh Token (PRT)

The PRT is the quiet facilitator behind seamless single sign-on in hybrid-joined environments or your villain preventing SiF from working as expected, it’s a matter of perspective. It’s what allows users to access cloud resources without being constantly re-prompted.

• It’s issued when a user signs into a hybrid-joined Windows device.

• It’s managed by the CloudAP plugin, which renews it about every four hours in the background.

• Renewal is activity-based: unlocking the device, reconnecting to the network, or other normal use qualifies as “activity.”

• It has a maximum lifetime of 90 days, but regular renewals keep it valid indefinitely during normal use.

The PRT is effectively a trusted credential. As long as it remains valid and fresh, Entra treats the device as “in-session” and can use the PRT to silently issue tokens to SaaS apps.

3. What Sign-In Frequency Actually Does

Sign-In Frequency is a Conditional Access session control that defines how long Entra allows a session to persist before requiring reauthentication such as entering a password or performing MFA.

A few key points are often misunderstood:

• SiF only applies when Entra is asked to issue or refresh a token.

• It doesn’t proactively end sessions or revoke cookies.

• If a token request occurs after the configured interval, Entra returns an interaction_required response to prompt the user.

In other words, SiF defines a maximum allowed age for authentication. But evalutation only happens when something requests a new token.

4. Why Enforcement Appears Inconsistent

When you configure a Sign-In Frequency policy for 12 hours, you expect reauthentication roughly every 12 hours. But that isn’t what happens in hybrid-joined scenarios.

Here’s why:

• The PRT silently renews as long as the user remains active.

• Each renewal resets the freshness of the user’s authentication.

• SiF is only evaluated when Entra needs to issue a new token.

• If the app uses its own session cookie and doesn’t request a new token, SiF never gets a chance to enforce.

So even when the configured window passes, Entra still sees the user as “fresh.” When a token request finally happens, Entra issues it silently because from its perspective, trust hasn’t been broken.

That’s why users can appear to stay signed in indefinitely. It’s not a failure of Conditional Access, it’s a reflection of how trust is maintained between device, Entra, and the app.

5. When Silent Authentication Stops Being Silent

The PRT can only renew tokens silently when the current authentication satisfies all of the claims required by the target app or policy.

If a Conditional Access policy or authentication strength requires something new for example, a passkey and the user originally signed in with only a password and Microsoft Authenticator, Entra can’t silently satisfy that policy.

Here’s what happens:

• The PRT still exists and is valid for other apps.

• But when the user tries to access an app requiring a stronger factor, the PRT doesn’t contain the required claims.

• Entra detects the mismatch and forces interactive authentication.

So, while the PRT allows continuous access under consistent conditions, it won’t override updated security expectations. Silent SSO works only as long as the existing session meets all requirements of the new policy.

6. Example Flow

Here’s what this looks like in practice:

7. The SaaS Application Variable

The final layer - the SaaS application - adds its own complexity. Most SSO-enabled SaaS apps manage their own sessions once Entra authenticates the user. They issue their own cookies or tokens and honor them until expiration. If the app never redirects back to Entra, SiF isn’t evaluated. When it finally does, Entra checks the PRT and either issues a new token silently (if all claims align) or prompts the user (if they don’t).

That’s why you can have SiF set but still see users logged into apps far past that configured time frame. The control isn’t being ignored, it’s waiting for the conditions that require it

8. Putting It All Together

When users remain signed in longer than expected, it’s not a configuration problem it’s the system working as designed.

• The PRT maintains device trust.

• Entra enforces SiF only when tokens are refreshed.

• SaaS apps manage their own session lifetimes.

• New Conditional Access or authentication strength requirements can interrupt silent flows.

Each layer functions correctly on its own, but the interaction between them creates outcomes that can appear inconsistent.

Final Thoughts

The Conditional Access Sign-in frequency session control is extraordinarily nuanced. If you’re expecting users to have to reauthenticate on an exact cadence you’ll probably be disappointed. It’s just part of a broader ecosystem that prioritizes continuity over disruption. In hybrid-joined environments, that means users may appear perpetually signed in but that’s because they still likely have a valid PRT, not because Conditional Access isn't working as intended.

Understanding that distinction changes how we interpret enforcement and help set more realistic expectations around how Entra manages sign-in persistence.