Tere’s something that catches everyone off guard: your Conditional Access policy might be perfect—but there’s a secret relay between MSAL and token refresh that quietly overrides it. In this episode, I’ll show you the unseen handshake that actually controls Modern Authentication in M365—and what it means for business-critical workflows.
The Hidden Workings of Sign-In: Azure AD’s Trust Machine
It’s easy to assume that logging into M365 is nothing more than submitting your password and waiting for the green light. I think we’ve all watched users fly through the sign-in screen and move on with their day. But underneath that smooth experience, Azure Active Directory is running a far more complicated background check. Think of it less as a simple security stop and more like walking up to a security desk after landing at an airport: credentials in hand, but the guard’s not just glancing at your name. They’re quietly checking a whole list of things before they let you head to baggage claim.
Picture this: someone opens their laptop in a hotel room, fires up the Wi-Fi, and tries to reach their organization’s SharePoint. You’d expect the system to at least blink at a new location. But sometimes, to everyone’s confusion, the login just works. No extra prompts. No notifications to the admin. On the surface, it looks like the password got them through. But in reality, something more layered is happening within Azure AD’s engine.
Behind the scenes, Azure AD acts like a security guard who doesn’t just check your ID, but also notices where you’re coming from, what device you’re using, how healthy that device is, and whether you’re sticking to the organization’s latest rules. That checklist goes way beyond “username and password.” Is the device enrolled in Intune? Is it up-to-date and compliant with company policies? Is the sign-in happening from a familiar location or halfway across the world from yesterday’s login? All those little details—what Microsoft calls “signals”—get swept into the guard’s calculation.
Conditional Access is operating as a live rulebook. It’s not just a set-it-and-forget-it wall. Each policy is another instruction for the security guard: sometimes, require multi-factor authentication; sometimes, allow access but only if the device is marked compliant; other times, block the attempt completely if it comes from an unknown country. The more layers you add, the more nuanced the engine becomes. Yet, it also opens up new combinations you might not expect.
Let’s take a real scenario. An admin sets a Conditional Access policy to demand MFA whenever someone signs in from outside approved office locations. That’s supposed to catch the user sitting in the hotel, right? But when testing, the admin sees the user hop online and get into SharePoint with nothing but their usual password. Confusing, but not uncommon. Why does this happen? Sometimes, the signals intersect in ways that defeat your expectations. The device might already be marked compliant. Maybe the user signed into another cloud resource earlier in the day, still has a valid session, and rides in on that existing trust. Or perhaps, a previous risk check gave them a window of safe access, so the engine is temporarily relaxing the rules for that user.
The more you look at Conditional Access, the more you see that it’s not one rule on its own but a big web of signals and decisions, all happening in real time. User risk, device risk, network location, compliance status—every one of those gets scored the instant someone types their credentials. If any of them tip the scales, the user might get extra hurdles, or they might just slide through. The criteria for “trusted” are constantly shifting, and new factors (like if Microsoft spots suspicious activity from that user elsewhere) can throw the whole calculation into a new state within seconds.
Organizations living through this can run into problems fast. You add a branded Conditional Access policy, think you’ve closed a gap, and then your helpdesk gets calls about users logging in from hotel rooms or coffee shops with no extra challenge. If you pull the logs, you’ll often find that the device was already signed in, or there was some signal Azure AD quietly weighed that overruled your new policy—like the user’s device staying compliant according to Intune, or Microsoft marking the session as low-risk based on recent behavior.
So, what’s really happening is less of a hard stop and more of a balancing act. Azure AD considers every possible angle at the point of sign-in. Some signals might get more weight depending on other things happening in your tenant, from an admin rolling out a new policy, to the risk engine flagging an IP address, or even a device getting its compliance check updated five minutes before the user tries again. It’s a live calculation, and it only gets more complicated as you add new apps, new devices, and new users.
But here’s something most admins miss: getting through the sign-in experience is just step one. All this heavy lifting—the scoring and the checks—happens right before Azure AD issues what matters most: the access token. Each policy, each signal, each conditional rule—every bit of it feeds into whether Azure AD even hands over a token at all.
Once that token exists, there’s a whole new set of concerns. Because the token inherits all those decisions, and sometimes, a well-meaning policy can get quietly overruled or delayed just by the way tokens work in practice. So yes, your policies and signals are working behind the scenes, but it’s the actual token that decides what happens next when that user is roaming the halls of your SharePoint library, even if they started from a hotel lobby. And what’s actually sitting inside that token has huge implications for your overall security stance and how well your controls really work.
Inside the Token Factory: Access vs. Refresh (and Why It Matters)
Access tokens and refresh tokens pop up everywhere in Microsoft 365 conversations, but in practice, most people treat them as background noise—just digital tickets you need to get work done. That’s how most admins think of them at first, too. The reality is, these tokens run the whole show. If you picture the M365 sign-in process as a conference, the access token is your event badge with your name and session permissions printed on it. You flash it to get into each breakout room—Teams, SharePoint, Outlook. The refresh token, though, works more like a hidden VIP wristband. If your main badge gets old or you try to get into a new session, you just use the wristband to pick up a new badge at the counter, no questions asked—most of the time, nobody notices you’re even swapping it out.
But, here’s where things start to get interesting. Not all of these passes are created equal, and the way they interact with Conditional Access policies can make or break your security intentions. Let’s say your organization has rolled out a policy demanding MFA for every sensitive app login. Users with a fresh access token breeze right through, but what about the ones holding valid refresh tokens issued before the policy changed? They’re still moving between sessions, collecting new access tokens, and as long as their refresh token is accepted, they don’t hit the new MFA requirement until that refresh token itself is checked. There’s a built-in lag—sometimes hours, sometimes days—where your new policy hasn’t really landed yet.
If we zoom in on the actual contents of an access token, things get granular. Each access token carries a handful of claims—think of them as identity facts: who the user is, which groups they belong to, what device they’re on, sometimes which city they’re logging in from, and critically, the permissions or scopes granted. For SharePoint, this might be read or write access; for Outlook, maybe just read mail. These tokens also have short lifespans by design; in Microsoft’s cloud, an access token typically lasts about an hour. After that, it’s no good. That’s where the refresh token comes in—refresh tokens are longer-lived, usually valid for days or even weeks, and can keep your session alive much longer than the access token alone.
Here’s the subtle magic: you hardly ever see a refresh token in action. The Microsoft Authentication Library, or MSAL, does all the heavy lifting for you. As soon as your access token expires, MSAL quietly sends the refresh token to Azure AD, gets a brand-new access token, and applies it to your open apps. You don’t see a prompt or a pause, and you don’t reenter your password or MFA unless something unusual pops up. This “background refresh” means your session can roll along for days—sometimes even surviving a laptop hibernation or a quick location switch—without you flipping your usual routine.
The consequence? Your carefully crafted Conditional Access policies don’t catch every user immediately. Let’s talk about that classic MFA rollout scenario. You flip the policy switch, expecting everyone to see a second prompt, but half the company seems to skate by without any new challenge. The answer isn’t that the policy’s broken—it’s that those users are still operating under the rules bundled into their current token set. If their apps haven’t asked for a new refresh token, they won’t see anything different until the refresh token gets checked against Azure AD, and only then do the new policies apply.
There’s an obvious risk here. Imagine a situation where a refresh token somehow leaks—say, through a poorly protected personal device, or because a user accidentally installed a shady browser extension. As long as that refresh token is still valid, whoever holds it can keep collecting new access tokens. That might keep granting them entry into apps and data they shouldn’t be anywhere near until either the admin explicitly revokes the session or the refresh token expires on its own. Microsoft is well aware of this. Their guidance isn’t just about shrinking token lifetimes. The recommendation is to use risk-based conditional access, apply session controls, and regularly review sign-in logs for suspicious refresh activity. Shorter lifespans help, but identifying and disrupting risky sessions in real time is even more effective.
If you look at session management in the Azure portal or work with PowerShell scripts, you’ll find options to adjust how long tokens live, how often users see re-authentication, and how session revocation works in practice. The trick is that there’s always a trade-off between user productivity and security—chopping token lifetimes too aggressively can frustrate users; making them too long can open risk windows. The decision often comes down to what’s happening in your environment: how mobile your workforce is, how sensitive your data is, and how often security threats actually appear on your radar.
The real lesson? Token management isn’t a minor detail—it’s the backbone of your entire security and productivity balancing act. Policies look strong on paper, but if you don’t interrupt the token lifecycle, your changes take longer to matter. The decision to force session revocation or device compliance isn’t just a checkbox—it’s what decides who gets in quickly, who waits, and who gets blocked outright.
But let’s push this further: what if you change your Conditional Access rules in the afternoon—can you really force those changes to take effect instantly, everywhere? Or do the existing tokens quietly defy your new guardrails until their built-in timer runs out? Most real-world environments see a lag, and that’s where both risk and confusion creep in. The token lifecycle, in practice, plays a huge role in whether or not your security posture actually matches what you wrote in the admin portal. And as you start tweaking policies mid-game, those hidden tokens may decide to play by their own schedule.
Changing the Rules: Conditional Access Meets the Token Lifecycle
If you've ever spent a weekend tightening your Conditional Access policies only to find users are still walking through what should be airtight doors, you’re not alone. It feels like a cruel trick—flip a policy switch, tell leadership the environment is secured, then check the logs and spot a user happily logging in from Bali. What's actually happening is less about Azure AD ignoring your intentions and more about how the token system enforces (or delays) every rule you put in place.
Let’s look at what’s really behind that delay. You decide to require MFA for any login outside your country. It’s a straightforward rule and, in theory, users on vacation should suddenly need their Authenticator app. But users who already signed in last week? They’re still opening Outlook and OneDrive on the same old devices, with nothing new popping up. This isn't because Conditional Access missed them—it's because those users are relying on tokens that were minted before your rule got stricter. Conditional Access only kicks in when a new token is being issued. If there’s already a valid access token, Azure AD doesn’t force a new evaluation until absolutely necessary.
The heart of the issue is timing. Access tokens stick around for a set window, often an hour, sometimes more depending on what your environment allows. During that time, the token simply says “yes, this person is trusted as of when the token was created.” Any major policy changes are sitting on the sidelines, unnoticed, until the next refresh. It’s only when the access token expires, and the app presents the refresh token, that Azure AD rechecks all your Conditional Access policies and decides if the user still deserves a seat at the table.
I’ve watched admins roll out updated location policies at financial firms—the kind where new rules should keep remote users out if they’re bouncing between Wi-Fi hotspots in different countries. Even after the change, people keep downloading quarterly reports from places the company is trying to block. Hours tick by with users sneaking through on access tokens that are still valid. In regulated industries, that means the risk window stays open far longer than the compliance folks would like.
Session management policies do give you a lever to force these rechecks earlier. By cutting access token lifetimes down to the shortest reasonable window, you make it more likely users will have to present their refresh tokens and hit your new policies. Forcing sign-outs or revoking refresh tokens through the Azure AD admin portal can have an immediate, if sometimes disruptive, effect. That’s often the nuclear option when you need everyone logged out right away—say, during a security incident or a sudden policy overhaul. These approaches work, but there’s a price: users might start complaining about having to log in repeatedly, or mobile apps suddenly lose their connection in the background.
If you’re comfortable with PowerShell, you get a bit more control. Commands like `Revoke-AzureADUserAllRefreshToken` allow you to target a single user or group and cut off their refresh tokens instantly. The downside is scale and tracking—you have to know who’s at risk, and you’re in the business of chasing sessions by hand. This is a maintenance burden for any large environment.
Within the Azure AD portal itself, session controls let you tweak the default expiration, but you’ll hit hard limits. Some apps, especially those using legacy authentication stacks or custom integrations, might not respect those settings cleanly. And that’s before you even get into how persistent browser sessions or alternative sign-in flows might bypass re-authentication hints entirely.
Things get even messier with mobile devices and background services. Many modern apps—Teams, Outlook Mobile, OneDrive—are built around silent background token refresh. That means users enjoy near-invisible connectivity, but every time you push a new policy, it can be hard to force an immediate reevaluation unless you’re willing to disrupt live sessions. Mobile apps are notorious for holding on to refresh tokens, sometimes even after a device is wiped unless you’ve put strong device management in place.
So, to actually make new rules stick, you can’t just rely on publishing policies and hoping for the best. You have to cut off old tokens or dramatically shrink their lifespan. Otherwise, there’s a real gap between what’s written in policy and what’s felt by users. Each untouched session is running on decisions baked into the old token, no matter how good your intentions were when you crafted the update.
What you’ll end up wrestling with is how to keep tight security without crushing productivity. The quicker you force token refresh, the faster your rules spread—but at a cost. Forced logouts frustrate users and can disrupt meetings, data syncs, or app launches. There’s no perfect answer. For environments handling sensitive data, the risk of lagging sessions often outweighs the downside. Others play it more conservatively and choose to let tokens expire on their regular schedule.
As Zero Trust strategies take hold, the traditional ways of managing these “permission gaps” start to fall short. Dynamic, always-on validation is the new goal. But right now, even the best Conditional Access policy is only as good as the tokens it can reach, and that’s why knowing exactly when and how those tokens update is where your leverage truly lives. When Zero Trust comes into play, suddenly every access is supposed to be up for reevaluation—pushing us all toward shorter-lived tokens, frequent reauthorizations, and a bigger shift in how Azure AD handles trust over time.
Zero Trust and the Future: Dynamic Tokens in a Changing M365 World
Zero Trust has become one of those phrases that gets thrown around in every Microsoft 365 conversation, but once you start rolling it out, the reality is pretty different than the sales pitch. Somewhere between the eighth Conditional Access policy and your fourth “is this really required?” meeting, you start to notice things aren’t as predictable as they used to be. Ask any admin who has shifted their environment to Zero Trust—a day after the change, users are flooding the support channels with questions about odd login prompts. Some folks get challenged for MFA at what feels like random times, while others glide through as if nothing changed at all. Even IT staff get caught off guard by logins that worked one day and suddenly ask for something extra the next morning. It’s not a bug; it’s how Zero Trust is supposed to work now.
The core shift is that Zero Trust wipes away the old “authenticate once, access everything” assumption. Now, every access is up for review. Every click, every request to SharePoint or Teams or Outlook is run through a context check—location, device state, risk signals, and more—before Azure AD hands out a new access token. You can’t rely on the idea that a user’s token from two hours ago still makes sense, especially if something in their situation changes. Instead of only checking at sign-in, Azure AD and MSAL are evaluating trust in near real-time. If you open a sensitive app from home one evening, then walk into a new location the next morning, don’t be surprised if you’re asked to reauthenticate—your environment looks different now, so the system is actively challenging whether you still meet the requirements.
Conditional Access becomes much more than a blunt instrument in this setup. Rules aren’t just “on” or “off.” They get triggered by evolving signals. For example, say your laptop leaves corporate Wi-Fi and connects to coffee shop internet. That location flag combines with a device health change, maybe an overdue Windows update, and Azure AD recalculates trust on the spot. Suddenly, instead of letting that access token ride until it expires, the system can force a prompt right in the middle of a session. This is possible because of how MSAL and Azure AD work together now—dynamic claims are added to the access token, reflecting the latest state of the user, the device, and even external risk intelligence from Microsoft.
It’s not just user signals that matter anymore, either. App registration permissions are front and center in determining what happens next. Think about a finance app someone built internally that now wants to access new data from SharePoint or Teams. The permissions set when that app was first registered are baked into every token the app receives. That means a user who is compliant and risk free only gets as much access as the app’s own registration allows. Flip the switch on app permissions and suddenly even the most trusted user can’t see certain data. It’s a layer that trips up organizations who assume users alone control their access—apps and permissions are just as critical to manage as users and devices.
Network location has become a living, breathing signal in all of this. In the past, logging in from a new IP address might have triggered a single prompt. Now, that change can adjust your risk score on the fly. If Microsoft detects a login attempt from a city you’ve never visited, real-time intelligence can challenge or even block access immediately. It’s not just about blocking based on a static list of countries; it’s about responding to what looks suspicious in context, even if that means one user gets through and another is stopped—because their recent activity signals different risk.
Let’s take a real example from a hybrid work rollout. An organization shifts to Zero Trust, enabling continuous evaluation policies in Azure AD and trimming token lifetimes for cloud apps. Employees who used to rely on persistent sessions find that their access is broken up regularly—especially if they bounce between home, office, or remote meeting locations. The IT team gets questions as to why users are being re-prompted more frequently or why certain apps stop working after a change in device compliance. Digging into the logs, admins notice that token renewal is getting blocked not just by traditional Conditional Access policies, but also by live risk signals about device health or flagged behavior.
Suddenly, even small changes to a policy have outsized impacts. An updated device compliance requirement, a new partner country on the block list; both can ripple out and cause a surge in authentication prompts, support tickets, or failed app launches. It’s adaptive, but it isn’t automatic magic—every policy tweak needs to be weighed against the day-to-day disruption for real users trying to stay productive.
This landscape demands careful planning. The tools are more powerful, but the margin for error is tighter. The system adapts to new threats and user behavior in real time, but the loops between policy, signal, and user experience are now short and very visible. If you’re running a busy tenancy, every change is felt almost immediately by someone. Zero Trust isn’t a feature you turn on; it’s a constant tuning process that challenges you to keep your environment secure without grinding everyone to a halt. With tokens and policies becoming more interconnected and responsive, it’s less about setting it and forgetting it—and more about continuous health checks for your entire authentication setup.
Conclusion
If you’ve ever assumed Modern Auth was just toggling some settings and calling it done, you’re missing most of the picture. Every part—tokens, policies, signals, and device checks—plays a role in whether your users hit a wall or coast through. When you really see how these pieces talk to each other, you’re much better prepared to build something secure without driving everyone crazy. Next time you update a Conditional Access policy, stop and dig into what tokens your users still hold and what sessions are quietly running on yesterday’s trust. That’s where the real story always surfaces first.
Share this post