Office Keeps Asking Me to Sign In Every Time: Why Tokens Don’t Persist (and How to Make Them)

If Microsoft 365 asks you to sign in every time you open Word, Excel, or Outlook — even though you signed in yesterday, last week, and the week before — the issue isn’t that you’ve been “logged out.” Office hasn’t lost your sign-in. It never managed to keep it in the first place.

Modern Office uses authentication tokens. When you sign in, Office is supposed to write a refresh token to disk, in your user profile, encrypted to your Windows account. The next time you open Word, the token gets read, validated, and refreshed silently — no prompt. If you’re being prompted every time, that token isn’t being written, isn’t being read, or isn’t being trusted. There are four reasons that happens. Here they are, and how to fix each.

Quick answer

The “Office keeps asking me to sign in” symptom has four root causes. Almost all cases are one of the first two:

  1. Office is signed in but Windows isn’t trusting the token. The “Allow my organization to manage my device” checkbox got unchecked at first sign-in. Fix: sign in again with the box checked.
  2. The token cache folder has the wrong permissions or is being cleaned. Often caused by aggressive cleanup utilities, profile redirection, or non-persistent VDI. Fix: check %LOCALAPPDATA%\Microsoft\IdentityCache exists and is writable.
  3. A Group Policy is forcing sign-out on every session. Common on managed devices. Fix: identify and disable the policy, or accept it.
  4. The Office user data folder is corrupted. Fix: rename the Office identity folders and let Office recreate them.

If you skip the diagnosis, you’ll guess your way through hours of “fixes” that don’t apply. Read the diagnostic section below before running anything.

Before you start

Quick verifications:

  • Confirm this happens across all Office apps, not just one. If it’s only Outlook, see Outlook keeps asking for password. If it’s only Word, that points to corrupted Office data, not the system-wide token state.
  • Confirm you’re using a Microsoft 365 (subscription) install, not Office 2016/2019 perpetual license with a Microsoft account add-on. The fix paths differ.
  • Note whether you’re on a personal device or a work-managed device. Several of the fixes are admin-only on managed devices.
  • Check whether you signed in with “this is a personal device” or “this is a work device.” The two flows write tokens to different places. If you switched at some point, the old tokens may still be active and conflicting.

What this means

When Office requires a sign-in, it does one of two things:

  1. Add Account flow — used the first time you sign in, or after a full sign-out. Walks you through a web-based sign-in (browser or embedded WebView), MFA if required, and a “Stay signed in?” / “Allow my organization to manage my device” prompt at the end.
  2. Silent token refresh — used every other time. Reads the cached refresh token, exchanges it with Entra ID for a new access token, and signs you in without surfacing anything.

If you’re seeing the Add Account flow every time, silent token refresh is failing. Either the token isn’t there, isn’t readable, isn’t being trusted, or isn’t being respected.

The crucial bit most other guides miss: signing in again doesn’t fix the underlying problem. It just gets you working until the next time the silent refresh fails. To actually fix this, you have to find out why the persistent token isn’t sticking.

Where this happens

The “every time I open Office it asks me to sign in” pattern shows up most often on:

  • Devices where the user signed in to Office without ticking “Allow my organization to manage my device.” This is the single most common cause.
  • Non-persistent VDI / Citrix / Cloud PC environments. The user profile (and therefore the token cache) gets reset on every session by design.
  • Devices with disk cleanup utilities that clear %LOCALAPPDATA% as part of their “speed up Windows” routine. CCleaner-style utilities frequently destroy this state.
  • Devices with Group Policy or Intune policies that explicitly disable persistent sign-in (rare but real).
  • Devices where a sysadmin recently moved the user profile between drives or changed redirected folder configuration.

If none of these match your situation, the fourth cause — Office user data corruption — is left, and that’s a clean fix.

Common causes (in priority order)

Cause 1: “Allow my organization to manage my device” was unchecked

When you first sign in to Office with a work or school account, the final screen says:

Stay signed in to all your apps

Windows will remember your account and automatically sign you in to your apps and websites on this device. This will reduce the number of times you are asked to log in.

☐ Allow my organization to manage my device

[No, sign in to this app only] [OK]

If you click No, sign in to this app only, Office authenticates just for that one session. There’s no persistent token. Every time you open Office, you’ll be asked to sign in again — by design.

This is the most common cause by a wide margin. People click “No” because they’re worried about IT taking control of their personal device. On a personal device, that concern is sometimes valid; the workaround is in Fix 1 below.

Cause 2: The identity cache folder is being cleared or has bad permissions

The token cache lives at:

%LOCALAPPDATA%\Microsoft\IdentityCache
%LOCALAPPDATA%\Microsoft\OneAuth
%LOCALAPPDATA%\Microsoft\TokenBroker

If any of these folders is missing, read-only, redirected to a network location, or being wiped on each session, the token can’t persist.

Common reasons it gets wiped: disk-cleanup utilities, antivirus quarantining the cache, non-persistent VDI, Group Policy folder redirection that doesn’t include this path, or a recent Windows reset that didn’t fully restore profile state.

Cause 3: A policy is forcing sign-out

Less common but real. Group Policy or Intune can be configured to:

  • Disable Web Account Manager (WAM) integration.
  • Block “Stay signed in” prompts.
  • Force per-session authentication for security reasons.

You’ll typically see this in regulated industries or in deliberately tight security environments. The user can’t override it; only the admin can.

Cause 4: Office user data is corrupted

If none of the above apply, the cause is local data corruption inside the Office identity store. This is fairly rare but maps cleanly to a fix. It often follows a Windows version upgrade (e.g., 23H2 → 24H2) that didn’t migrate the identity state cleanly.

Fixes

Fix 1: Sign in again, with the box ticked

This is the fix when Cause 1 applies. Most readers will solve the problem here.

  1. Open Word.
  2. Go to File → Account → Sign out. Confirm.
  3. Close all Office apps fully.
  4. Reopen Word.
  5. Click Sign in.
  6. Walk through the sign-in flow.
  7. At the “Stay signed in to all your apps” screen, tick “Allow my organization to manage my device.” Click OK.

That’s it. The persistent refresh token will write to your local profile, and silent refresh will work going forward.

About “Allow my organization to manage my device”: the wording is alarming on a personal device, and your concern is reasonable. But on a personal device with no Intune enrollment configured at the tenant level, ticking this box does not enroll your device in management. It registers the device with Entra ID — meaning Microsoft knows the device exists and that you signed in from it. It does not give your organization the ability to wipe, control, or audit your personal device. If Intune enrollment is configured, you’d see a separate, explicit enrollment prompt later. The phrase is misleading; the action is not the same as full device management.

If you don’t want to tick the box on principle, you have a choice: sign in every time, or use Office for the web instead of the desktop apps for that specific account.

Fix 2: Verify and repair the identity cache folder

If you ticked the box and Office still asks every time, check the cache.

  1. Press Windows + R, type %LOCALAPPDATA%\Microsoft, press Enter.
  2. Confirm the following folders exist: IdentityCache, OneAuth, TokenBroker.
  3. If any are missing, that’s the fault.
  4. Right-click each folder → Properties → Security tab. Confirm your user has Read and Write permissions. If not, fix the permissions.
  5. Confirm the path is on a local drive, not a network or redirected folder. If %LOCALAPPDATA% itself is redirected (some corporate environments do this), token persistence is unreliable. That’s an admin-side fix.

If the folders are missing, sign out of Office completely, restart Windows, and sign back in. Office will recreate them.

Fix 3: Stop disk-cleanup utilities from clearing the cache

If you use CCleaner, BleachBit, Glary Utilities, “PC Optimizers,” or similar:

  1. Open the utility.
  2. Find its cleanup rules for %LOCALAPPDATA%.
  3. Add explicit exclusions for:
    • %LOCALAPPDATA%\Microsoft\IdentityCache
    • %LOCALAPPDATA%\Microsoft\OneAuth
    • %LOCALAPPDATA%\Microsoft\TokenBroker
  4. Save the configuration.
  5. Sign in to Office again with the box ticked.

The honest recommendation: stop running these utilities. They cause more problems than they solve, and Microsoft 365’s auth state is one of the things they break most often. Modern Windows manages its own caches; manual cleanup is rarely useful.

Fix 4: Reset the identity cache cleanly

When the cache is corrupted (Cause 4), the fix is to delete it and let Office recreate it.

  1. Sign out of Office completely (File → Account → Sign out).
  2. Close all Office apps. Check Task Manager for stragglers.
  3. Open %LOCALAPPDATA%\Microsoft in File Explorer.
  4. Rename (don’t delete — keep them as backup):
    • IdentityCache → IdentityCache.bak
    • OneAuth → OneAuth.bak
  5. Restart Windows.
  6. Open Word and sign in. Tick the persistence box.
  7. After confirming sign-in works, you can delete the .bak folders.

Fix 5: Check for Group Policy interference

This is the diagnostic for Cause 3. You’ll need admin rights to change the policy if you find it.

  1. Press Windows + R, type gpedit.msc, press Enter (Pro/Enterprise editions only).
  2. Navigate to User Configuration → Administrative Templates → Microsoft Office 2016 → Security Settings.
  3. Look for: “Use Web Account Manager (WAM) for sign-in” — should be Enabled or Not Configured.
  4. Navigate to User Configuration → Administrative Templates → Microsoft Office 2016 → Privacy → Trust Center.
  5. Look for: anything that disables persistent sign-in.

If you find a policy explicitly disabling sign-in persistence, you can’t override it as a user. On a managed device, ask IT why it’s set and whether it can be relaxed.

If gpedit.msc doesn’t exist on your edition (Windows Home), Group Policy can still apply via Intune or reg.exe. Check HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0 for any Identity-related entries.

Advanced fixes

If standard fixes don’t resolve it, two more things to try:

Reset Windows account broker state.

Open admin PowerShell:

Get-AppxPackage Microsoft.AAD.BrokerPlugin | Reset-AppxPackage

Restart Windows. Sign in to Office. This rebuilds the AAD Broker Plugin from scratch.

Force re-registration of the Office device identity.

This is for cases where Office can sign in but the device-side trust is broken, often after a tenant migration:

  1. Sign out of Office.
  2. Run dsregcmd /status in a Command Prompt to see your current Entra ID device state.
  3. If AzureAdJoined is YES but auth is failing, run dsregcmd /leave (admin), then restart, then sign in to Office which will trigger a fresh registration.
  4. Don’t run dsregcmd /leave on a managed device — it’ll break corporate compliance and you’ll need IT to re-onboard.

Work or school device — when IT involvement is required

On a managed corporate device, several fixes are off-limits:

  • Disconnect/reconnect the work account — will trigger a compliance failure and may lock you out.
  • Run dsregcmd /leave — same; never run this on a managed device.
  • Modify Group Policy — you don’t have rights, and the policy is set for a reason.

If Fix 1, Fix 2, and Fix 4 don’t resolve it on a managed device, raise a ticket with:

  • Whether all M365 apps are affected or just one.
  • Whether ticking “Allow my organization to manage my device” was offered (it should be on enrolled devices).
  • Output of dsregcmd /status (paste the AzureAdJoined / DomainJoined / DeviceAuthStatus lines).
  • Whether the same account works on other devices.

For Persona 2 admins (small business owners), the admin-side checklist for new user can’t sign in covers tenant-side checks (license assignment, compliance policies) that complement these client-side fixes.

When to stop troubleshooting

Stop and escalate when:

  • You’ve worked through Fix 1 to Fix 4 on a personal device and Office still prompts every time. Reinstall Office (uninstall via Settings → Apps, then download fresh from office.com).
  • You’re on a managed device and Fix 1 (with the box ticked) didn’t resolve it. The cause is environmental or policy; only IT can fix it.
  • You’re on non-persistent VDI or a Cloud PC and the prompts persist. By design, the token cache resets at logout. Talk to your IT team about FSLogix profile containers or persistent settings.
  • You’ve tried Fix 4 (cache reset) twice and the cache repopulates correctly but Office still prompts. There’s a corruption deeper in the install; an Online Repair or full reinstall is the next step.

What you should not do: install a “Microsoft 365 sign-in fixer” from a third-party site, call a phone number that appears in a Bing or Google search ad claiming to be Microsoft Support, or follow any guide that recommends disabling Modern Authentication. Modern Authentication can’t be disabled on the server side anymore — Microsoft retired Basic Auth in 2023 — and any guide telling you to set EnableModernAuth=0 is from 2017 and will not help.

Official references

FAQ

Why does Office sign me out when I restart Windows?

It shouldn’t. If it does, you didn’t tick “Allow my organization to manage my device” when you signed in, or something is clearing your %LOCALAPPDATA%\Microsoft\IdentityCache between sessions (a cleanup utility, profile redirection, or non-persistent VDI).

Is “Allow my organization to manage my device” the same as joining my computer to the company domain?

No. On a personal device with no Intune enrollment configured at the tenant level, ticking the box performs an Entra ID “Workplace Join” — Microsoft knows the device, but your organization can’t manage or wipe it. It’s not the same as Domain Join (which is on-premises Active Directory) or Entra ID Join (which is full Entra-managed device). The wording overstates what actually happens.

I unchecked the box on purpose because I’m worried about my employer accessing my personal data. Now Office prompts me every time. Is there a way to keep persistent sign-in without ticking it?

On a personal device with a work account, no — that’s the trade-off. If your employer hasn’t configured Intune or Conditional Access to restrict access to managed devices only, ticking the box is safe (your employer doesn’t gain control). If your employer has set “managed devices only” policy, you wouldn’t be able to sign in at all without proper enrollment, so the question is moot. The middle ground — sign in every time — is the price of refusing both options.

Why does this happen on Mac/iPhone/iPad without my having to click anything?

Mac and iOS use the OS keychain (Keychain Access on macOS, iCloud Keychain on iOS) to persist tokens. Windows uses the Web Account Manager and the local identity cache, which require explicit user consent (the “Allow my organization to manage my device” box). Different platforms, different persistence models. You don’t see this issue on Mac because the equivalent consent happens implicitly during the OS-level account add.

I run CCleaner. Should I stop?

For Microsoft 365 sign-in stability — yes. CCleaner’s default rules clear %LOCALAPPDATA% aggressively and break the token cache. If you keep using it, exclude %LOCALAPPDATA%\Microsoft\IdentityCache, %LOCALAPPDATA%\Microsoft\OneAuth, and %LOCALAPPDATA%\Microsoft\TokenBroker. Honestly, modern Windows manages its own caches; the marginal benefit of cleanup utilities is minimal and the risk of breaking auth state is non-trivial.

Does this happen because I’m using a personal Microsoft account at work or vice versa?

Sometimes. If your Windows account is a personal Microsoft account (@outlook.com) and your Office account is a work account, the device-trust path is more fragile because there’s no shared identity for the broker to anchor to. The fix is the same (Fix 1 with the box ticked), but the failure mode is more common in this configuration.

My organization’s IT just enabled Conditional Access and now this started. Is that the cause?

Likely yes — but the fix is still on your side. Conditional Access often requires “compliant” devices, which means your device has to be properly registered in Entra ID. Sign out of Office, restart, and sign back in with the persistence box ticked. The new sign-in will register the device correctly, and silent refresh should resume working. If it doesn’t, ask IT whether your device’s compliance state shows as Compliant in Intune.

↑ Back to top