The “Continue to Sign in Prompt” That breaks the SSO

In this blog, we will examine why Windows shows the “Continue to sign in?” prompt when launching apps like Microsoft Edge or the Company Portal for the first time. While Microsoft obviously points to regulatory reasons, the OS has a hidden mechanism making that decision. We’ll walk through what triggers it, how the region-based logic works, and how you can remove the restriction using a PowerShell script without changing the device location/region.

Disclaimer: This blog is written for informational and research purposes only. I am not advising or recommending that organizations circumvent regulatory or legal controls, including those related to the Digital Markets Act (DMA). Always evaluate any changes in line with your organization’s compliance and legal requirements

Introduction

You log into a shared device. You open Microsoft Edge, expecting to be signed in automatically with your work or school account.

Unfortunately, that’s not happening! There is no single sign-on. It instead tells you; you are NOT signed in and that they need to verify it before you can complete sign in?

The moment you click on the “Complete Sign in” button it asks you to continue to sign in so your account can be used in other Microsoft apps.

Welcome to the new Windows Single Sign-On experience!!!

At first glance, it makes sense. Microsoft even includes a helpful link to aka.ms/sso-info, which explains what is happening in a few sentences for those users. If you want to read some more details, I recommend reading Microsoft their official explanation about new behavior for users in the European Economic Area.

The page confirms this is tied to the Digital Markets Act (DMA) and is meant to give users more control over how their account is used across Microsoft apps. According to that article, the prompt appears only once per user per device. Once you clicked “Continue to Sign in”, it won’t be shown again unless the user hasn’t signed in for 90 days, or they remove and re-add their account. In my case I was logging in to a shared device, with it, the SSO prompt will always be shown. But things get even worse, let me show you!

Company Portal and the SSO Prompt

Besides Microsoft Edge showing you the Continue to sign in prompt, the same thing happens with the Company Portal! A Ignite, Microsoft announced that they are working on a feature that would automatically launch the Company Portal after your device has gone through Windows Autopilot. With this feature, you could get rid of the User Account ESP (which is stuck for like 70% of the time)

It seems we still need to wait a bit on that feature so in the meantime I created my own solution to automatically launch the company portal when a new device is enrolled to improve the onboarding process. Guess what happens if the “Continue to sign in” prompt is shown?

The whole SSO idea and the new perfect user experience goes down the drain! Why? because of the DMA act and only devices in Europe will have that issue!

But what triggers that Continue to Sign In, SSO prompt? And why do some users see it while others have never seen that prompt in their life?

When Location Triggers the Continue to Sign in prompt

Microsoft’s explanation points to regulations and transparency, and they’re not wrong. But what’s not explained is how Windows decides who gets this “Continue to Sign” in prompt and when.

As mentioned before, we noticed it on shared devices. Two shared devices, same image, same Intune policies, same user flow. But one got a seamless login experience, and the other was asked whether it wanted to use the current account across apps. The difference? Region…

One device was running in the US region. The other was geo-tagged to the Netherlands. No configuration difference, no policy conflict. The only variable was the region. At that point, it was clear that this wasn’t just some UI change based on a Windows feature rollout, it was something being enforced deeper in the system. Time to open our favorite tool: Procmon

The Event Log, Procmon and the Continue to Sign in prompt

So, we opened up the Event log, Procmon and launched the Company Portal. The first thing we will notice is that the AADTokenBroker will show an error 0xCAA2000C mentioning that the request requires user interaction (AADSTS9002341: User is required to permit SSO)

That means the Continue to Sign in prompt will be triggered. Just before that prompt appeared, the RuntimeBroker.exe started querying a curious registry path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Control Panel\DeviceRegion

If the Deviceregion key didn’t exist, it got created. If it did, its value was read and cached. Clearly this was part of some internal region-detection logic. But what used it? A few lines later, we spotted a read from:

C:\Windows\System32\IntegratedServicesRegionPolicySet.json

That’s not just some random file. That’s a nice policy json file. And once you open it, things get interesting. Each entry defines a feature, like “Automatic app sign-in“, and whether it should be enabled or disabled based on region.

The structure is simple. A default state, a list of enabled or disabled country codes, and a feature name. And wouldn’t you know it, in the “Automatic app sign-in” entry, both DE and NL are listed under “disabled“. That’s funny!

The Hidden Evaluation Logic of the Continue to Sign in prompt

Which brings us to the most important part of it. The reason this prompt is shown isn’t controlled by the app or Intune or some cloud-delivered toggle. It’s enforced by a policy decision made deep inside the operating system, based on your region.

After spotting those reads in Procmon, the next step was to look at the actual code path. We inspected SystemSettings.DataModel.dll and specifically the method responsible for resolving the device’s current region. This is where the actual flow becomes clear.

When the region is needed, Windows first checks the registry path:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Control Panel\DeviceRegion

If the value is already present, it uses that as the GeoID. If it’s missing, Windows falls back to the API GetUserGeoID(GEOCLASS_NATION) to determine the device’s geographic location. This gives back a numeric value ( a GeoID) which corresponds to a country. For example, 94 represents Germany.

Once that GeoID is retrieved, another API, GetGeoInfoW, is called to convert it into a two-letter ISO 3166-1 country code for example, “DE” or “NL”. That resulting string is what’s actually used in policy evaluation.

But there’s more: once that value is resolved, it’s written back into the DeviceRegion registry value, so the system doesn’t have to re-query the location service every time. From this point onward, that region becomes the reference point used by the OS to check any region-based policy.

Now we go back to the IntegratedServicesRegionPolicySet.json file. This file includes entries for specific features, with region-based enabled and disabled lists. When a Windows feature needs to check if it should be allowed (like automatic app sign-in), it reads this JSON file and looks at the current region code.

If your region is listed under “disabled” for a given feature, like “Automatic app sign-in” , the feature is blocked. That block applies system-wide. It doesn’t matter if your MDM policy allows SSO or your apps are configured correctly. The OS itself has already decided, based on region, that the feature should not be available until you clicked on the “continue” button.

This entire process happens in the background, triggered by components like RuntimeBroker or SystemSettings during app launches or feature evaluations. And it all hinges on a registry key, a GeoID lookup, and a JSON file tucked away in System32.

The Result: Region-Based Feature Blocking

The result? If your device is identified as being in DE or NL, features like automatic sign-in are disabled until you pressed the continue button. Edge won’t silently sign you in. Company Portal will prompt you with the same message. The sign-in prompt Microsoft attributes to user choice is, in fact, silently enforced by a region policy behind the scenes.

And here’s the funny thing. You can change it in multiple ways.

If you modify the registry to override DeviceRegion with a different GeoID or remove your region from the disabled list in IntegratedServicesRegionPolicySet.json, the behavior changes instantly. There is no sign-in prompt, and seamless SSOis available, just like it used to be.

Modifying the IntegratedServicesRegionPolicySet

We knew we needed a reliable and repeatable way to get rid of the region-based block that disables automatic app sign-in. Modifying the system region itself was an option, but it felt like a risk that could potentially break other things, like the MS Store, location services, or timezone behavior. So, instead of pretending to be in another country, we targeted the policy enforcement mechanism directly.

As we have seen before that mechanism lives in a file: IntegratedServicesRegionPolicySet.json. If we could safely remove our country code from the disabled list inside that file, the system would stop blocking automatic app sign-in without spoofing the device’s location.

Instead of faking the device region through registry edits, we took a more funnier approach. We built a PowerShell script that parses the IntegratedServicesRegionPolicySet.json file, finds the relevant feature entry (like “Automatic app sign-in”), and removes the specified country code from the disabled list.

Please Note: Modifying permissions on system files is not supported and strongly discouraged. Doing so may lead to system instability, or unintended behavior. 

Once created we uploaded it to Intune we assigned it to all devices.

Please make sure you DON’T run this script using the logged on credentials as we need SYSTEM permissions to change the JSON file.

How the Script Works

The PowerShell script begins by checking whether the JSON file exists. Since it lives in System32 and is protected, only the TrustedInstaller account has write access. The script temporarily takes ownership of the file and grants SYSTEM full control so it can proceed.

Please Note: I changed the TargetRegion to: $targetRegion = (Get-Culture).TwoLetterISOLanguageName (Denmark --> please use the hardcoded part instead)

It then reads and parses the JSON content. It searches for the policy entry with the $comment set to “Automatic app sign-in” and inspects the conditions.region.disabled array. If the target region code (like “NL”) is present, it removes it.

Please Note: Of course, you can change the Automatic app sign-in comment to something else.. for example Uninstall Edge blocked

Before making any changes, the script creates a backup of the original JSON. Once the modification is complete, the script writes the file back to disk and restores the original ownership, to TrustedInstaller.

This method doesn’t interfere with how Windows determines region globally, and it keeps all other region-sensitive features untouched (at least I think so). You can even take it a step further and convert this script into a Proactive Remediation in Intune, scheduled to run hourly. That way, if an update or policy ever reverts the file, your remediation script will detect and fix it automatically, keeping the user experience consistent.

You can download the PowerShell Script below. Also, if you want to run this script manually on your device, you will need to have enough permissions (system –> Psexec -i -s powershell) to do so.

Conclusion

With a bit of IDA and Procmon and a targeted PowerShell script, we now have a reliable (but not supported) way to remove that pesky automatic app sign-in warning prompt on our shared devices.

Of course, you can also implement this PowerShell script on other NON shared devices but with the SSO prompt only showing once it’s maybe not worth the effort.