Windows Sign-In

Once your domain is federated, BlokSec can authenticate users at the Windows lock screen, not just in the browser. A user enters their work email at sign-in, Windows hands the authentication to BlokSec, and the user approves it the same way they approve any other sign-in.

This uses Microsoft’s Web sign-in credential provider, which is built into Windows 11. There is nothing to install on the device and no additional BlokSec configuration — but there is one Windows policy you must set, and sign-in will not work without it.

What you get

• Passwordless Windows sign-in — users unlock Entra-joined devices with BlokKey or BlokBadge
• Passwordless Entra join — enrolling a new device into your tenant also authenticates through BlokSec
• No new infrastructure — it runs over the same WS-Federation setup you already configured

Requirements

Requirement	Detail
Device join type	Entra-joined only. Hybrid-joined and on-premises domain-joined devices are not supported
Windows edition	Windows 11, Pro or Enterprise
Network	Online only — Web sign-in has no cached credentials, so a device with no network connection cannot sign in this way
Federation	Your domain must already be federated and working in the browser

Keep a way back in

Because Web sign-in requires a network connection and cannot work offline, make sure each device keeps at least one other way to sign in — a local administrator account, or Windows Hello for Business enrolled after first sign-in. Do not remove every alternative credential from a device until you have tested this end to end.

Step 1 — Find your BlokSec sign-in domains

Windows will only navigate to domains you explicitly allow, so you need to know which domains your sign-in page uses. There are two: the one serving the sign-in page, and the one serving your organization’s logo.

The simplest way to confirm them is to sign in to Microsoft 365 in a normal browser and look at the address bar when the BlokSec sign-in page appears.

For most tenants they are:

Region	Sign-in domain	Assets domain
North America	api.bloksec.io or api.bloksec.app	static.bloksec.app
Europe	api.eu-central-1.bloksec.app	static.bloksec.app

Note

If your tenant was set up on a different BlokSec endpoint, use the domain you see in the address bar rather than the table. Allowing a domain that your tenant does not use is harmless; missing the one it does use will block sign-in. The examples below list every North American endpoint for that reason — trim it if you prefer, but there is no need to.

Step 2 — Allow those domains in Windows

Deploy the Configure Web Sign In Allowed Urls policy to your Entra-joined devices.

1. Sign in to the Microsoft Intune admin center (https://intune.microsoft.com)
2. Go to Devices > Configuration > Create > New policy
3. Platform Windows 10 and later, profile type Settings catalog
4. Search the settings picker for Configure Web Sign In Allowed Urls and add it (category Authentication)
5. Set the value to your two domains, separated by a semicolon:

api.bloksec.io;api.bloksec.app;static.bloksec.app

6. Assign the policy to the device group containing your Entra-joined machines, then create it

Screenshot pending

/screenshots/admin/integrations/microsoft-365/windows-intune-allowed-urls.png

Intune settings catalog showing the Configure Web Sign In Allowed Urls setting with BlokSec domains entered

Allow the BlokSec sign-in domains in the Intune settings catalog

Domains only

Enter bare domain names separated by semicolons. Do not include https://, a path, or a trailing slash. A full URL in this field will not match, and sign-in will keep failing with no indication why.

Setting the policy without Intune

If you want to try Windows sign-in on a single machine before committing to an Intune deployment, you can set the same policy locally. This is intended for evaluation, not for production rollout — neither method below assigns the policy to a group, tracks compliance, or survives a device rebuild.

WMI Bridge (recommended)

This writes the same Policy CSP that Intune would. It must run as SYSTEM — it will fail as an ordinary administrator. Get a SYSTEM shell with psexec -s -i powershell.exe from Sysinternals.

$ns  = "root\cimv2\mdm\dmmap"
$cls = "MDM_Policy_Config01_Authentication02"

New-CimInstance -Namespace $ns -ClassName $cls -Property @{
  ParentID   = "./Vendor/MSFT/Policy/Config"
  InstanceID = "Authentication"
  ConfigureWebSignInAllowedUrls = "api.bloksec.io;api.bloksec.app;static.bloksec.app"
}

# Confirm it was written
Get-CimInstance -Namespace $ns -ClassName $cls | Format-List

If the instance already exists, New-CimInstance returns an error. Retrieve it with Get-CimInstance and use Set-CimInstance on the returned object instead.

Registry

A last resort when the WMI Bridge is unavailable. Create a REG_SZ value:

Key:   HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Authentication
Name:  ConfigureWebSignInAllowedUrls
Type:  REG_SZ
Value: api.bloksec.io;api.bloksec.app;static.bloksec.app

Be aware of what this is: that key is the MDM stack’s own store, not a supported configuration surface. Windows reads it, but an MDM sync or a servicing update can overwrite or clear it without warning, and it fails silently when it does — you get the same blocked page with no error explaining why. If sign-in works and then stops working later on a machine configured this way, check whether the value is still there before looking anywhere else.

Step 3 — Restart and test

Restart the device after the policy applies. A sign-out is often enough, since the sign-in host is rebuilt for each logon session, but a restart removes the doubt — worth it on the first test, when you want to be sure you are testing the policy and not a stale cache.

Then:

1. At the lock screen, choose the option to sign in with your work account
2. Enter the user’s work email address
3. Windows shows “Taking you to your organization’s sign-in page”
4. The BlokSec sign-in page appears
5. The user approves on their phone, or scans their badge and enters their PIN
6. Windows signs them in

Screenshot pending

/screenshots/admin/integrations/microsoft-365/windows-lock-screen-signin.png

Windows 11 lock screen showing the BlokSec sign-in page rendered by the Web sign-in credential provider

The BlokSec sign-in page at the Windows lock screen

How users authenticate

Because Windows delegates the whole sign-in to BlokSec, whichever methods you have enabled on the application are the methods users see at the lock screen.

BlokKey — the user receives a push notification and approves it with their phone’s biometrics. This is the usual path for users with a smartphone.

BlokBadge — the user scans their printed QR badge and enters their PIN. No phone required, which makes it the practical option for shared Windows workstations, kiosks, and frontline devices.

Use a hardware scanner on shared workstations

BlokBadge accepts either a USB barcode scanner or the device’s webcam. On shared and kiosk machines, prefer a USB scanner. It presents itself to Windows as a keyboard, so it needs no camera permission at the lock screen, and it is faster and more reliable than holding a badge up to a webcam.

Troubleshooting

“We can’t open that page right now”

The full message reads:

We can’t open that page right now. For security reasons, you’ll need to visit the page from a browser or a different device. If you think you’ve reached this page because of an error, tell your organization’s IT support you can’t access https://api.bloksec.io/wsfed/...

Screenshot pending

/screenshots/admin/integrations/microsoft-365/windows-blocked-error.png

Windows lock screen error reading 'We can't open that page right now. For security reasons, you'll need to visit the page from a browser or a different device.'

Windows blocked the sign-in page because the domain is not in the allow list

This is the allow list from Step 2. Windows refused to navigate to the BlokSec sign-in page, and it refused on the device — the request never reaches BlokSec, so there is nothing in your BlokSec logs to find. Check, in order:

1. The policy has actually applied to the device (Get-CimInstance above, or the Intune device status)
2. The value contains bare domains with no https:// and no path
3. The domain in the error message is one of the domains in your value
4. The device has been restarted since the policy applied

A confusing symptom worth knowing

Joining a device to Entra can succeed while signing in to it fails, on the same machine, with the same account. They run in different Windows components and the join flow is not subject to this allow list. If join works and sign-in does not, that is a strong signal the allow list is the problem rather than your federation.

The organization sign-in option is missing

If the lock screen never offers a work account sign-in option, Web sign-in itself is not enabled — that is a different policy, Authentication/EnableWebSignIn, in the same Authentication category in the settings catalog. Confirm the option appears before investigating the allow list.

Sign-in works in a browser but not at the lock screen

Confirm the device is Entra-joined, not hybrid-joined or domain-joined. Run dsregcmd /status and check that AzureAdJoined reads YES and DomainJoined reads NO. Hybrid-joined devices cannot use Web sign-in.

After first sign-in

Microsoft’s recommended pattern is that your federated identity provider handles first sign-in, PIN reset, and recovery, and the user then enrols Windows Hello for Business for day-to-day unlock. That gives users a fast local unlock that also works offline, with BlokSec as the passwordless credential behind enrolment and recovery.