Microsoft account sign-in broken on ONE Windows profile (0x80048054 / 0x80860010...

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.