Verdict

Symptom On a single local Windows 11 profile: Settings → Accounts → Email & accounts → Add a Microsoft account fails with "Due to an unexpected error, we can't sign this account in to your other apps." Microsoft Store / Xbox sign-in fails with 0x80048054 (sometimes 0x80860010 , 0x8086000C , or 0x800488b3 ). The account gets added to Email & accounts, but no app can ever use it. The same account works perfectly in a brand-new Windows profile on the same PC — so the account, the network, the device and all machine-wide services are fine. Survives: removing/re-adding the account, clearing IdentityCache / TokenBroker / Credential Manager, re-registering Microsoft.AccountsControl and Microsoft.AAD.BrokerPlugin , sfc / DISM , and reboots. Root cause Two artifacts belonging to that profile carried impossible far-future timestamps . On my machine this followed cloning Windows from a 512 GB NVMe to a 2 TB NVMe (and a later BIOS fTPM clear), but the exact trigger is unproven — if you've never cloned a disk you may still hit this. 1. A per-user CNG key file dated in the year 2175 %APPDATA%\Microsoft\Crypto\Keys\ contained the Microsoft Connected Devices Platform device certificate key with LastWriteTime of 2175 . Cryptographic operations against it failed with ERROR_INVALID_FUNCTION / NTE_NOT_FOUND . 2. A device-identity record dated in the year 2161 — the real killer HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\DeviceIdentities\production\ <YOUR-USER-SID>\<deviceid>\DeviceId held: <Data DAInvalidationTime="6039175974"> <User username="…"><HardwareInfo BoundTime="6039175979" …/></User></Data> 6039175974 as Unix time is 2161-05-16 . A healthy profile has no DAInvalidationTime attribute at all . Why that breaks everything DAInvalidationTime tells wlidsvc to discard any device-auth (DA) token obtained before that moment. Because the value exceeds INT_MAX , the service reports it as exactly 2147483647 (2038-01-19) — it appears to saturate a 32-bit signed integer. Every DA token, no matter how fresh, is therefore "obtained prior to" the watermark and is thrown away microseconds after being issued: deviceidentity.cpp:931 Invalidating DA token for <deviceid> obtained prior DA InvalidationTime: 2147483647, 1784936365 DeviceIdHelpers::GetDeviceAuthToken → 0x80048054 Note this store lives in the SYSTEM hive ( HKU\.DEFAULT , because wlidsvc runs as LocalSystem) but is keyed by your user SID. That's why it survives everything: it's not in HKCU , not in HKLM , and it's an XML attribute , so registry value searches never find it. How to check whether you have it # 1. Any device identity with a DAInvalidationTime? Compare the number against # https://www.epochconverter.com — anything beyond ~2040 is corrupt. Get-ChildItem "Registry::HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\DeviceIdentities\production" -Recurse | ForEach-Object { $d = (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).DeviceId if ($d -match 'DAInvalidationTime="(\d+)"') { "{0}`n {1} -> {2}" -f $_.Name, $matches[1], [DateTimeOffset]::FromUnixTimeSeconds([long]$matches[1]).ToString('yyyy-MM-dd') } } # 2. Any per-user crypto key with an absurd date? Get-ChildItem -Force "$env:APPDATA\Microsoft\Crypto\Keys" | Select-Object Name, LastWriteTime To confirm it's really your problem, capture the auth trace (elevated) and reproduce once: logman create trace LiveId -p "Microsoft-Windows-LiveId" 0xffffffffffffffff 0xff -o C:\t\liveid.etl -ets # …attempt the sign-in, let it fail… logman stop LiveId -ets tracerpt C:\t\liveid.etl -o C:\t\liveid.csv -of CSV -y Select-String C:\t\liveid.csv -SimpleMatch 'Invalidating DA token' A healthy profile produces zero hits. Mine produced 20 per attempt. Fix Back up first: reg export "HKU\.DEFAULT\Software\Microsoft\IdentityCRL\DeviceIdentities" C:\backup-devids.reg Then edit that DeviceId value to remove the DAInvalidationTime attribute entirely and set BoundTime to a sane current Unix timestamp — i.e. make it match a healthy profile: <Data><User username="…"><HardwareInfo BoundTime="1784936832" TpmKeyStateClient="0" TpmKeyStateServer="0" LicenseInstallError="0"/></User></Data> Get a correct timestamp with [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() ( not Get-Date -UFormat %s , which is off by your UTC offset). Then restart the service and retry: Restart-Service wlidsvc Also move the future-dated file out of %APPDATA%\Microsoft\Crypto\Keys\ — Windows regenerates it (mine came back healthy at 1080 bytes, matching a working profile). Re-trace afterwards: Invalidating DA token should now be 0 . Gotcha — do not set up a Windows Hello PIN while troubleshooting this Creating a PIN creates NGC containers, which pushes ShouldCreateNgcKey off the benign "No usable NGC containers found" path onto one that then demands an NGC key for your account. Because Store/Settings request tokens with noUI , it can't prompt and dies silently with ONL_E_ACTION_REQUIRED / PPCRL_E_NGC_REGISTRATION_REQUIRED — a second , self-inflicted failure that masks the first. Removing the PIN reverted it. Things that were NOT the cause (save yourself the time) ACLs on profile keys/files; the TPM (healthy, and tpmtool said ready — clearing it is what created some of this mess); VBS/Credential Guard key isolation; the missing Microsoft.AccountsControl per-user folder ( absent on healthy profiles too — these are SystemApps that keep state in the registry); the virtualapp/didlogical credential (deleting it regenerates the same device ID); removing the device from account.microsoft.com; IdentityCRL\KeyCache ; and an empty IdentityCache folder (a symptom of never completing sign-in, not a cause). Also, two traps if you go trace-diving: tracerpt CSV has a variable column count per event type, so Import-Csv silently misaligns fields — read it as raw lines. And Win32 message strings are localised per profile , so a string match can return zero for one profile purely because it's in another language.