In this blog, we will examine how a recent big Windows change was introduced to meet Digital Markets Act (DMA SSO Compliance) requirements. This change forced devices into a stricter Device SSO authentication flow. As a result, many users were unexpectedly prompted with a Continue to sign in screen instead of experiencing silent single sign-on.
While we discussed the details and an initial workaround in a previous blog, this time we will dive deeper into how Windows internally decides to trigger this Device SSO, and show a cleaner and safer way to fix the issue without modifying system files, which could potentially break the Windows Updates on your device.
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: A Forced Change in the Background
Following Microsoft’s adjustments for Digital Markets Act (DMA) compliance, devices that previously signed in silently were now suddenly forced to prompt users with a Continue to sign in screen. As shown below, the user was required to click “Continue” before they could access the app.
This was not the result of a tenant-side configuration change, nor an admin-initiated policy. It was Microsoft’s response to regulatory obligations, enforcing stricter separation between device authentication and account services.
In an earlier DMA blog, I explained this behavior and showed a quick workaround: By modifying the IntegratedServicesRegionPolicySet JSON file, I was able to prevent the device from enforcing this stricter Device SSO flow and restore the silent authentication and single sign-on. However, as with most quick fixes, there was more to uncover.
The Risks
Not long after publishing that first blog, someone mentioned a possible issue. Windows Updates began to fail on one of their devices, where the IntegratedServicesRegionPolicySet JSON file had been modified.
Reviewing the CBS logs pointed towards a hash mismatch for the modified JSON file, triggering update errors like 0x80070302 and warnings about component corruption and a hash mismatch.
Testing across other devices did not immediately reproduce this servicing issue. Multiple fresh deployments showed no direct problems after the JSON patch. Still, the fact that CBS integrity warnings were triggered on even one device was a clear sign: patching system files could introduce an unnecessary risk…. that’s something we don’t want!
If Windows detected changes in critical system-managed files, servicing stack operations like cumulative updates or feature upgrades could eventually fail or behave unpredictably. This made it clear that while the original workaround worked, it was not a long-term solution.
Inside the Authentication Flow
To find a safer approach, I needed to dive deeper into the device’s authentication behavior.
Analyzing aadtb.dll, and specifically the OAuthTokenRequestBase::SendRequest function, revealed that before sending the authentication request to Azure AD, the device first checks if the DMASSOCompliance feature is enabled. Spell it out loud! DMA SSO Compliance!
This is handled through a call to GlobalSettings::Feature::IsDMASSOComplianceEnabled. If active, the device adds two additional headers to the authentication request:
- SsoFlagSubStatus
- x-ms-SsoFlags
These headers inform Azure AD that the device is asserting compliance and requesting device-based authentication support. This led to an important realization. If DMASSOCompliance was disabled, would the device no longer inject these headers, avoiding the new Device SSO flow entirely??
But the question remained… what triggers the decision to check and enable DMASSOCompliance?
Regional Policy Evaluation
Tracing the GetSSO Policy data led me back again to SystemSettings.DataModel.dll, specifically the RegionPolicyEvaluator::EvaluatePolicyState function.
Here, Windows first checks the device family using RtlGetDeviceFamilyInfoEnum. If the device belongs to a supported family like Desktop, and the IntegratedServicesPolicyEnforcement feature is enabled, Windows then attempts to retrieve the device’s region.
It does this through the DeviceRegionStore (which we also touched on in the previous blog). If no valid device region is found, Windows falls back to the user’s GEOID to determine the region and stores it locally. Only after successfully determining a region and confirming that the IntegratedServicesPolicyEnforcement feature is active, the device proceeds with enforcing the Continue to sign in prompt.
This flow matched the behavior seen in practice. Devices that could not properly determine their region, or where the enforcement feature was disabled, did not send the additional SSO headers and never showed the Continue to sign in prompt. The path forward became clear: Rather than modifying JSON files, it was better to control the enforcement features themselves.
Inception: More Features Behind the Feature
While digging deeper, it also became clear that the IntegratedServicesPolicyEnforcement feature itself also checks an additional feature behind the scenes: Account And Regional Policy Enforcement.
When we examine the function above closely, we notice that Windows checks if IntegratedServicesPolicyEnforcement is active, but also verifies whether Account And Regional Policy Enforcement is enabled. The feature’s name suggests that it is indeed responsible for enforcing the account and region policy.
If that AccountAndRegionalPolicyEnforcement feature is not active, the sso DMA compliance prompt seems to be disabled, even if the main IntegratedServicesPolicyEnforcement feature is enabled.
Disable the DMA SSO with the ViVeTool
Disabling the enforcement features directly through ViVeTool offered a cleaner solution than tampering with system files. Please note that this idea was not new. In a previous blog, I posted on patchmypc.com, I also used the ViVeTool to successfully enable the Subscription Activation MFA feature fix in a controlled way, before Microsoft did so in a future Windows Build.
For the DMA SSO problem, two feature IDs became critical:
- 47557358 — AccountAndRegionalPolicyEnforcement
- 45317806 — DMASSOCompliance
By disabling both features using ViVeTool, the feature itself and the user never see the Continue to sign in screen. This avoids altering the IntegratedServicesRegionPolicySet json, ensuring that CBS integrity and Windows Update servicing remain intact. The process itself was straightforward, similar to what was used in the subscription activation fix blog. The only main downside of this approach is that the device NEEDS to reboot after disabling those features.
Download the Remediation Scripts Here:
Conclusion: A Cleaner and Safer Solution
By looking at the DLLs, following the device authentication flow starting from token requests, through policy evaluation, and finally down to specific feature checks, a better way to disable the DMA SSO Compliance was uncovered.
Rather than risking system file integrity, disabling the AccountAndRegionalPolicyEnforcement and DMASSOCompliance features through ViVeTool restores the expected silent single sign-in without introducing update failures.