Interactive Troubleshooter

Published: Oct 11, 2026

Microsoft 365 License Says Unlicensed Product After Login - Token Cache Tree

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

This interactive diagnostic tree resolves persistent 'Unlicensed Product', 'Subscription Expired', or 'Activation Required' errors in Microsoft 365 Apps immediately after user authentication. It evaluates corrupted OLicenseScript tokens, Web Account Manager (WAM) broker failures, Shared Computer Licensing (SCL) flags, conditional access device locks, and stale Windows Credential Manager entries.

Full Diagnostic Tree & Step-by-Step Overview

In what specific state or UI banner does Microsoft 365 display the license activation failure?

Yellow or Red title bar banner displays 'UNLICENSED PRODUCT', 'Subscription Expired', or 'ACCOUNT NOTICE'.
Sign-in succeeds, but Office repeatedly prompts for credentials in an infinite login loop upon opening apps.
Error appears specifically on Remote Desktop Session Hosts (RDSH), Citrix, or shared virtual desktop infrastructures.
Sign-in fails with an explicit Entra ID Conditional Access error code (e.g., 50058, 53000, or 50199).

What underlying identity token or activation cache anomaly is causing the 'Unlicensed Product' status?

Legacy or duplicate Office product keys remain registered in the Office Software Protection Platform (OSPP) cache.
Modern Authentication (vNext / OPATH) license tokens in AppData are corrupted or locked by file system permissions.
Microsoft 365 subscription license (e.g., Business Premium, E3, E5) is unassigned or disabled in Entra ID.
System date, time, or hardware clock desynchronization breaks token validation with KMS / Office Licensing Service.

Clearing Legacy Product Keys using OSPP.vbs and OLicenseCleanup

Solution:

Root Cause: Legacy Office Product Key Conflicts in OSPP License Store

When a workstation is upgraded from volume-licensed or perpetual Office builds (e.g., Office 2016/2019 Standard or ProPlus) to Microsoft 365 Apps for enterprise, legacy partial product keys often persist inside the Office Software Protection Platform (OSPP) database. During application launch, the Office licensing service queries local OSPP keys prior to modern vNext OAuth user tokens. If an expired perpetual key or mismatched KMS product key takes precedence, Office flags the status as UNLICENSED PRODUCT despite successful user sign-in.

# Diagnostic Verification:

Open Command Prompt as Administrator and navigate to the Office installation directory:

cd "C:\Program Files\Microsoft Office\Office16" *(or Office16 under Program Files (x86))*

Run the Office Software Protection Platform script to query active keys:

cscript ospp.vbs /dstatus

Inspect the output under LICENSE STATUS and LAST 5 CHARACTERS OF INSTALLED PRODUCT KEY. If multiple product key blocks or Grace Period / Unlicensed entries are listed alongside your Microsoft 365 user identity, legacy key pollution is active.

# Step-by-Step Fix:

Remove Stale Product Keys via ospp.vbs:

Note the 5-character partial product keys returned in the /dstatus command (e.g., WB123).

Run the uninstallation switch for each legacy key:

cscript ospp.vbs /unpkey:WB123

Repeat until cscript ospp.vbs /dstatus reports no installed product keys or shows only valid subscription states.

Run Official Microsoft OLicenseCleanup.vbs Reset Script:

Download and run OLicenseCleanup.vbs (or execute equivalent automated registry cleaning commands) to wipe legacy identity locations:

Remove-Item -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Licensing\LicensingNext" -Recurse -Force -ErrorAction SilentlyContinue

Remove-Item -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity\Identities" -Recurse -Force -ErrorAction SilentlyContinue

Restart Office Application and Re-authenticate:

Launch Word or Excel, click Sign In, and enter your Microsoft 365 credentials to generate a fresh vNext license blob.

# Prevention & Long-Term Monitoring:

Ensure deployment scripts for Microsoft 365 Apps include the <RemoveMSI /> element in configuration.xml during tenant-wide transitions.

Purging Corrupted vNext / OPATH License Token Directories

Solution:

Root Cause: Corrupted Modern Licensing (vNext) Auth Blob in Local AppData

Microsoft 365 Apps utilizes Modern Licensing (vNext / OPATH) to cache encrypted OAuth 2.0 user license tokens locally under %LOCALAPPDATA%\Microsoft\Office\16.0\Licensing. If an unexpected shutdown, network drop, or security scanner locks these .lic or .cat token files mid-write, the licensing engine fails to parse the cached token upon launch, returning UNLICENSED PRODUCT even though the user appears signed in under the Account menu.

# Diagnostic Verification:

Open PowerShell and check for modern licensing token files:

Get-ChildItem -Path "$env:LOCALAPPDATA\Microsoft\Office\16.0\Licensing" -Recurse

Check Event Viewer (eventvwr.msc) > Applications and Services Logs > Microsoft > Office > Alerts. Look for errors stating *Office Subscription licensing token validation failed*.

# Step-by-Step Fix:

Close All Microsoft 365 Processes:

Open PowerShell as Administrator and terminate Office processes:

Stop-Process -Name "winword", "excel", "outlook", "powerpnt", "onedrive", "MSOIA" -Force -ErrorAction SilentlyContinue

Purge Local vNext Licensing Directory:

Run the following PowerShell commands to wipe cached token stores:

Remove-Item -Path "$env:LOCALAPPDATA\Microsoft\Office\16.0\Licensing\*" -Recurse -Force -ErrorAction SilentlyContinue

Remove-Item -Path "$env:LOCALAPPDATA\GroupContainers\UBF8T346G9.Office\Licensing" -Recurse -Force -ErrorAction SilentlyContinue

Clear Identities from Registry:

Open Command Prompt as Administrator and run:

reg delete "HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities" /f

Re-launch Office and Complete Activation:

Open Word, navigate to File > Account, click Fix Me or Sign In, and complete the modern auth prompt.

# Prevention & Long-Term Monitoring:

Exclude %LOCALAPPDATA%\Microsoft\Office\16.0\Licensing from aggressive real-time file deletion policies or profile cleanup utilities.

Auditing Entra ID User Subscription Service Plans and M365 App SKU Assignments

Solution:

Root Cause: Disabled or Missing 'M365 Apps' Sub-Service Plan in Entra ID SKU

A user account may have a license bundle assigned in Microsoft 365 Admin Center (e.g., Microsoft 365 E3 or Business Premium), but the specific sub-service plan responsible for desktop Office activation—Microsoft 365 Apps for enterprise (or M365 Apps for business) / OFFICE_365_NON_PROPLUS—has been disabled by an administrator. Upon sign-in, authentication succeeds, but the licensing endpoint confirms no desktop entitlement exists for the user object, flagging the local app as unlicensed.

# Diagnostic Verification:

Connect to Microsoft Graph PowerShell and check assigned service plan statuses for the affected user:

Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"
(Get-MgUser -UserId "user@yourdomain.com" -Property AssignedLicenses, LicenseAssignmentStates).LicenseAssignmentStates

Look for the service plan named OFFICE_365_PROPLUS or OFFICE_365_BUSINESS. If ProvisioningStatus shows Disabled or Deprovisioned, desktop rights are revoked.

# Step-by-Step Fix:

Enable Desktop Apps Sub-Service Plan in M365 Admin Center:

Navigate to Users > Active users > select the affected user.

Click the Licenses and apps tab.

Expand the assigned license bundle (e.g., *Microsoft 365 E3*).

Ensure the checkbox for Microsoft 365 Apps for enterprise (or Microsoft 365 Apps for business) is explicitly checked.

Click Save changes.

Force Local Identity Refresh:

On the user's PC, open Word > File > Account > click Switch Account or Sign Out.

Re-sign in to pull down updated token claims from Entra ID.

# Prevention & Long-Term Monitoring:

Use Group-Based Licensing in Microsoft Entra ID to ensure automated, error-free sub-service plan distribution across organizational units.

Synchronizing Hardware Real-Time Clock (RTC) and Timezone Offsets

Solution:

Root Cause: Secure Time Stamp Validation Failure (Kerberos / OAuth JWT Expiry)

Microsoft 365 modern authentication license tokens use short-lived JSON Web Tokens (JWT) stamped with an explicit nbf (not before) and exp (expiration) epoch timestamp. If the local system time on the workstation skew exceeds 5 minutes relative to Microsoft Entra ID domain time servers (due to CMOS battery degradation or misconfigured NTP servers), the Office licensing subsystem rejects valid server response tokens, returning UNLICENSED PRODUCT or activation handshake errors.

# Diagnostic Verification:

Open PowerShell as Administrator and inspect the local system time relative to network time:

w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly

If the time offset displays a difference greater than +300s or -300s, clock skew is breaking token validation.

# Step-by-Step Fix:

Resynchronize Windows Time Service via PowerShell:

Run the following commands as Administrator:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync /force

Verify Time Zone and Automatic Clock Settings:

Open Settings > Time & language > Date & time.

Ensure Set time automatically and Set time zone automatically are toggled to On.

Relaunch Office Application and complete sign-in.

# Prevention & Long-Term Monitoring:

Configure Group Policy or Intune NTP settings to enforce strict domain time synchronization across all remote client endpoints.

What identity broker, credential manager, or modern auth plugin is failing during the login loop?

Windows Web Account Manager (WAM) broker package (`Microsoft.AAD.BrokerPlugin`) is corrupt or unassigned.
Stale `MicrosoftOffice16` generic credentials in Windows Credential Manager block token renewal.
Modern Authentication (ADAL/MSAL) is disabled via legacy registry keys (`EnableADAL = 0`).
Primary Refresh Token (PRT) desynchronization on Hybrid Entra ID Joined PC blocks single sign-on (SSO).

Re-registering Web Account Manager (WAM) Broker Plugin Package

Solution:

Root Cause: Windows Web Account Manager (`Microsoft.AAD.BrokerPlugin`) AppX Corruption

Microsoft 365 Apps on Windows 10 and Windows 11 rely natively on the OS-level Web Account Manager (WAM) identity broker (Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy) to acquire OAuth access tokens. If the WAM AppX package becomes corrupted or its local ACL registry keys are stripped following a major Windows feature update, Office cannot prompt for modern credentials or store refresh tokens, trapping the application in a perpetual sign-in prompt and showing an unlicensed state.

# Diagnostic Verification:

Open Event Viewer > Applications and Services Logs > Microsoft > Windows > AAD > Operational.

Look for Error Event ID 1098 or 1025 stating *WAM Account broker failure* or *Error: 0x40070018*.

# Step-by-Step Fix:

Re-register AAD Broker Plugin AppX Package via PowerShell:

Open PowerShell as Administrator and run:

Add-AppxPackage -Register "C:\Windows\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AppxManifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown

Re-register Accounts Control AppX Package:

Execute in PowerShell:

Get-AppxPackage -AllUsers *AccountsControl* | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Restart Computer and Sign In:

Reboot the machine, launch Word, and authenticate.

# Prevention & Long-Term Monitoring:

Avoid executing aggressive AppX de-bloating scripts that target native SystemApps directories.

Purging Stale MicrosoftOffice16 Credentials from Windows Credential Manager

Solution:

Root Cause: Stale Generic Credential Blobs in Windows Credential Vault

When a user changes their Microsoft Entra ID password or enables Multi-Factor Authentication (MFA), Windows Credential Manager often retains legacy generic credentials matching MicrosoftOffice16_Data:ADAL:[GUID]. When Office attempts background token acquisition, it reads these expired vault items before prompting the user, resulting in silent authentication rejection and dropping the license state to Unlicensed Product.

# Diagnostic Verification:

Open Command Prompt and query saved Office credentials:

cmdkey /list | findstr /i "MicrosoftOffice16"

If multiple legacy entries are returned, stale credentials are interfering with active SSO sessions.

# Step-by-Step Fix:

Open Windows Credential Manager:

Press Win + R, type control /name Microsoft.CredentialManager, and press Enter.

Click Windows Credentials.

Purge All Office and Identity Credential Entries:

Under Generic Credentials, expand and remove all items starting with:

MicrosoftOffice16_Data:...
MicrosoftOffice15_Data:...
MS.OuterIdentity
OneDrive Cached Credential

Clear Identity Cache in Registry:

Open PowerShell as Administrator and run:

Remove-Item -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity\ServiceIndexes" -Recurse -Force -ErrorAction SilentlyContinue

Relaunch Word and complete authentication.

# Prevention & Long-Term Monitoring:

Deploy automated logon scripts to clear stale generic Office credentials upon user password change events.

Configuring Identity and EnableADAL Registry Overrides for Modern Auth

Solution:

Root Cause: Legacy ADAL / Modern Authentication Disable Registry Flags

Legacy troubleshooting guides or deprecated Group Policy Objects (GPOs) frequently deployed registry values under HKCU\Software\Microsoft\Office\16.0\Common\Identity—such as setting EnableADAL = 0 or DisableADALatopWAMOverride = 1. In modern Microsoft 365 environments where basic authentication is fully deprecated in Microsoft Entra ID, setting EnableADAL to 0 forces Office to use legacy auth protocols that fail unconditionally, locking the application in an unlicensed state.

# Diagnostic Verification:

Open PowerShell and check for registry overrides in the Identity subkey:

Get-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -ErrorAction SilentlyContinue

Look for EnableADAL set to 0 or DisableServerAuth set to 1.

# Step-by-Step Fix:

Reset Identity Registry Values to Default in PowerShell:

Open PowerShell as Administrator and run:

Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Name "EnableADAL" -ErrorAction SilentlyContinue

Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Name "DisableADALatopWAMOverride" -ErrorAction SilentlyContinue

Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Name "DisableServerAuth" -ErrorAction SilentlyContinue

Force Modern Authentication Default Behavior:

Ensure modern auth is explicitly enabled if using custom policies:

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Name "EnableADAL" -Value 1 -Type DWORD

Restart Office and test sign-in.

# Prevention & Long-Term Monitoring:

Audit domain GPOs and Intune Administrative Templates to ensure legacy Office 2013/2016 authentication keys are removed.

Refreshing Primary Refresh Token (PRT) and Repairing Entra Join SSO State

Solution:

Root Cause: Primary Refresh Token (PRT) Desynchronization on Domain Endpoint

On Hybrid Entra ID Joined or Entra ID Joined Windows devices, Microsoft 365 Apps leverages the OS Primary Refresh Token (PRT) acquired by lsass.exe during Windows logon for seamless Single Sign-On (SSO). If the PRT becomes invalid (e.g., due to computer account password desynchronization or long offline periods), Office attempts SSO, fails silently, and falls back to an unauthenticated, unlicensed state.

# Diagnostic Verification:

Open Command Prompt and inspect device join and SSO status:

dsregcmd /status

Under SSO State, verify AzureAdPrt : YES. If AzureAdPrt is NO or PRT progress shows an error status, the device single sign-on token is missing.

# Step-by-Step Fix:

Force PRT Refresh via Windows Lock Screen:

Lock the Windows session (Win + L).

Unlock the machine using the account's active Entra ID / Active Directory password (do NOT use PIN or Windows Hello during initial test to force Kerberos/OAuth ticket request).

Force Re-registration via Command Prompt:

Open Command Prompt as Administrator and execute:

dsregcmd /debug /join

Verify Token Health:

Re-run dsregcmd /status and confirm AzureAdPrt : YES.

Relaunch Word to confirm seamless license activation.

# Prevention & Long-Term Monitoring:

Ensure domain controllers maintain reliable line-of-sight connectivity for Hybrid Entra ID Joined endpoints.

What Shared Computer Licensing (SCL) or VDI profile setting is failing on the session host?

Shared Computer Licensing (SCL) token directory (%LOCALAPPDATA%\Microsoft\Office\16.0\Licensing) is missing or read-only.
Shared Computer Licensing flag (`SharedComputerLicensing = 1`) is missing on a multi-user session host.
FSLogix / Roaming Profile container exclusions are stripping SCL licensing tokens on logoff.
Maximum allowed SCL activation limit (5 concurrent sessions per user) is exceeded across farm hosts.

Configuring Custom SCL Token Folder Redirection via Registry

Solution:

Root Cause: Shared Computer Licensing (SCL) Token Directory Access Failure

When Microsoft 365 Apps is installed on a Remote Desktop Session Host (RDSH), Citrix Virtual Apps host, or Azure Virtual Desktop (AVD) host with Shared Computer Licensing (SCL) enabled, Office does not store standard activation tokens in the registry. Instead, it obtains a short-lived licensing token and writes it to %LOCALAPPDATA%\Microsoft\Office\16.0\Licensing. If non-persistent VDI environments wipe this local folder on logoff without roaming it, or if NTFS permissions block file creation, users encounter UNLICENSED PRODUCT upon every new session.

# Diagnostic Verification:

Check the default SCL token directory in the user session:

Test-Path "$env:LOCALAPPDATA\Microsoft\Office\16.0\Licensing"

Event Viewer > Applications and Services Logs > Microsoft > Office > Alerts shows error *Shared Computer Licensing token couldn't be obtained or saved*.

# Step-by-Step Fix:

Redirect SCL Token Location to a Roamed AppData Directory:

Open regedit and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration

Create a new String Value (REG_SZ) named SCLCacheOverrideDirectory.

Set the value data to a roamed profile path, such as:

%appdata%\Microsoft\Office\16.0\Licensing

Ensure Directory Permissions in PowerShell:

Verify users have Full Control over the target redirected AppData path:

icacls "$env:APPDATA\Microsoft\Office\16.0\Licensing" /grant "$env:USERNAME:(OI)(CI)F"

Restart Office in the user session.

# Prevention & Long-Term Monitoring:

Always configure SCLCacheOverrideDirectory in VDI master image builds to simplify profile roaming rules.

Enabling Shared Computer Licensing (SCL) Flags in Master VDI Images

Solution:

Root Cause: Missing Shared Computer Licensing (`SharedComputerLicensing`) Flag on Session Host

Installing Microsoft 365 Apps on a multi-user RDS server or Citrix host without turning on Shared Computer Licensing (SCL) causes Office to attempt standard per-user device activation. Standard activation ties the computer hardware GUID to one of the user's 5 allowed desktop activations. On a shared host, the first user activates the machine, but subsequent users logging in encounter UNLICENSED PRODUCT because device activation rights are exhausted or assigned to a different user SID.

# Diagnostic Verification:

Open Word on the RDS host > click File > Account.

Look under Product Information. If it says *Belongs to: [User Email]* instead of *Shared Computer Licensing*, SCL is NOT enabled.

# Step-by-Step Fix:

Enable SCL via Registry on Session Host:

Open Command Prompt as Administrator and run:

reg add "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" /v "SharedComputerLicensing" /t REG_SZ /d "1" /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\Common\Licensing" /v "SharedComputerLicensing" /t REG_DWORD /d 1 /f

Re-arm Office Licensing State:

Delete legacy local tokens:

Remove-Item -Path "$env:LOCALAPPDATA\Microsoft\Office\16.0\Licensing\*" -Recurse -Force -ErrorAction SilentlyContinue

Relaunch Office Application:

Open Word > File > Account. Confirm Product Information now explicitly displays Shared Computer Licensing.

# Prevention & Long-Term Monitoring:

Include <Property Name="SharedComputerLicensing" Value="1" /> in your Office Deployment Tool (ODT) XML for all virtual desktop infrastructure builds.

Configuring FSLogix Profile Container Inclusions for Office SCL Tokens

Solution:

Root Cause: FSLogix / Profile Management Token Directory Exclusions

When using FSLogix Profile Containers or Office Container on Citrix / AVD hosts, administrators often deploy custom redirections.xml files to exclude temporary directories from the VHDX container to save storage. If %LOCALAPPDATA%\Microsoft\Office\16.0\Licensing or %LOCALAPPDATA%\IdentityCache is listed as an <Exclusion>, FSLogix purges the SCL tokens at logoff. The user is forced to re-activate Office on every new login session, resulting in intermittent UNLICENSED PRODUCT states.

# Diagnostic Verification:

Inspect the active FSLogix redirection rules in the user session:

C:\Users\<Username>\AppData\Local\FSLogix\Logs\Profile\

Search for redirections.xml parsing logs to see if Office\16.0\Licensing is being excluded.

# Step-by-Step Fix:

Update FSLogix redirections.xml Configuration:

Remove the following paths from any <Exclusion> tags in your central redirections.xml file:

AppData\Local\Microsoft\Office\16.0\Licensing
AppData\Local\Microsoft\IdentityCache

Ensure FSLogix Office Container Includes Licensing:

In GPO or Registry (HKLM\SOFTWARE\FSLogix\Profiles), set IncludeOffice or RoamSearch parameters to maintain core Office app data.

Verify on Session Host and test user logoff/logon cycle.

# Prevention & Long-Term Monitoring:

Regularly review FSLogix container exclusion lists when updating Office 365 app suites.

Monitoring and Releasing Shared Computer Licensing (SCL) Session Limits

Solution:

Root Cause: Shared Computer Licensing (SCL) Token Allocation Quota Exceeded

Under Microsoft 365 licensing rules, a user assigned a Microsoft 365 E3/E5 or Business Premium license can activate Office on a limited number of shared computers (typically up to 20 shared session hosts) within a given timeframe. If an enterprise user logs into dozens of non-persistent RDS/VDI hosts without proper token roaming, SCL issues new tokens until the quota is exhausted. Subsequent host logins fail to issue a token, causing UNLICENSED PRODUCT banners.

# Diagnostic Verification:

In Event Viewer on the RDS server, check Application log for source Office 16 Licensing.

Look for Event ID 201 stating *Shared Computer Licensing limit reached for user object*.

# Step-by-Step Fix:

Force SCL Token Cache Renewal:

SCL tokens automatically expire after 30 days or can be freed by clearing oldest session tokens.

Implement Token Roaming (SCLCacheOverrideDirectory):

Configure SCL token redirection to the user's central roamed profile (as detailed in Node 401) so the user reuses a single SCL token across all VDI hosts in the farm.

Verify Entra ID User License State:

Ensure the user account has an active subscription supporting SCL (e.g., M365 Business Premium, E3, E5, or Apps for Enterprise).

# Prevention & Long-Term Monitoring:

For detailed endpoint guidance, consult the Microsoft Official Support Guide.

What Entra ID security rule or conditional access policy is blocking modern token issuance?

Entra ID Conditional Access requires a Compliant or Hybrid Joined device, but the PC is unmanaged.
Multi-Factor Authentication (MFA) or Identity Protection risk policy blocks background token refresh.
Federated Single Sign-On (ADFS / Third-Party IdP) WS-Trust endpoint is unreachable or blocked.
TLS 1.2 protocol enforcement is disabled in Windows OS client Internet Settings.

Resolving Entra ID Conditional Access Device Compliance Policies

Solution:

Root Cause: Conditional Access Policy Rejection for Unmanaged Endpoints

If an organization enforces a Conditional Access (CA) policy in Microsoft Entra ID requiring devices to be marked as Require device to be marked as compliant or Require Hybrid Entra ID joined device for the *Office 365* cloud app, opening Office apps on an unmanaged or non-compliant PC allows basic user sign-in to complete, but blocks the background token request sent to ols.officeapps.live.com (Office Licensing Service). The user sees their name in the top right corner, but Office reports UNLICENSED PRODUCT.

# Diagnostic Verification:

Navigate to Identity > Monitoring & health > Sign-in logs.

Filter by the affected user UPN and check for failed or interrupted sign-in events under User sign-ins (non-interactive) or Interactive.

Look for Error Code 53000 (*Device is not compliant*) or 530001 (*Device is not hybrid joined*).

# Step-by-Step Fix:

Enroll Device into Microsoft Intune:

Go to Settings > Accounts > Access work or school > click Connect.

Enter work credentials to initiate Entra ID Join or MDM registration to achieve compliance.

Exclude Licensing Service Endpoint in CA Policy (Admin Fix):

If BYOD activation is permitted by corporate policy, adjust the CA policy target apps in Entra Admin Center to exclude device compliance checks specifically for initial licensing endpoints or grant BYOD access through app protection policies.

Force Policy Sync on Device:

On the client PC, run gpupdate /force or sync Intune management under Access work or school.

# Prevention & Long-Term Monitoring:

Test Conditional Access policy updates in Report-Only mode before enforcing device compliance rules globally.

Clearing User MFA Step-Up Prompts and Identity Risk Flags

Solution:

Root Cause: Entra ID Identity Protection User Risk or Unresolved MFA Prompt

When Microsoft Entra ID Identity Protection flags a user account as Medium or High Risk (e.g., due to leaked credentials or impossible travel), or when a Conditional Access sign-in frequency policy requires re-authentication, the background licensing token request issued by Office is rejected with an interaction_required OAuth error. Because Microsoft 365 Apps running in the background cannot always render an interactive MFA prompt, the app reverts to UNLICENSED PRODUCT.

# Diagnostic Verification:

Check Entra Admin Center > Identity > Protection > Risky users.

Check sign-in logs for Error Code 50076 or 50158 (*User must complete MFA step-up to access resource*).

# Step-by-Step Fix:

Dismiss User Risk in Entra ID (Admin):

In Entra Admin Center > Risky users, select the user account and click Dismiss user risk (or require a secure password reset).

Force Interactive Authentication in Browser:

Have the user open a web browser in Incognito mode and navigate to https://portal.office.com.

Complete sign-in and perform the required MFA verification step.

Clear Local Office Session and Re-authenticate:

Open Word, navigate to File > Account, click Sign Out, close all Office apps, reopen Word, and sign back in.

# Prevention & Long-Term Monitoring:

Configure automated Self-Service Password Reset (SSPR) policies to allow users to self-remediate risk flags.

Validating Federated IdP WS-Trust Endpoints and Active Auth Flows

Solution:

Root Cause: Federated Authentication WS-Trust Endpoint Failure

Organizations utilizing federated identity providers (such as Active Directory Federation Services - ADFS, Okta, or Ping Identity) rely on active WS-Trust endpoints (e.g., /adfs/services/trust/13/usernamemixed) for legacy client token requests. If an administrator blocks WS-Trust endpoints at the Web Application Proxy (WAP) firewall or deprecates active authentication flows in the IdP, Microsoft 365 Apps cannot exchange SAML tokens for Office licensing tickets, leaving apps unlicensed.

# Diagnostic Verification:

Inspect sign-in logs in your Federated IdP portal for failed requests from user agent MSOIA or Office365-Apps.

Test WS-Trust endpoint reachability from PowerShell:

Test-NetConnection -ComputerName "sts.yourdomain.com" -Port 443

# Step-by-Step Fix:

Enable Modern Authentication on Tenant Domain:

Ensure your federated domain relies on OAuth 2.0 / Passive authentication flows rather than legacy active WS-Trust endpoints.

Verify ADFS Endpoint Status (If using ADFS):

Open ADFS Management console > Service > Endpoints.

Ensure /adfs/services/trust/13/usernamemixed and /adfs/services/trust/mex are Enabled and Proxy Enabled.

Restart Office Application and re-authenticate.

# Prevention & Long-Term Monitoring:

Migrate federated domains to Staged Rollout and Managed Authentication (Password Hash Sync or Pass-Through Authentication) to eliminate IdP single points of failure.

Enabling System-Wide TLS 1.2 Protocol Support in Secure Socket Libraries

Solution:

Root Cause: Deprecated TLS 1.0/1.1 Communication Handshake Failure

Microsoft 365 endpoints strictly require Transport Layer Security (TLS) 1.2 or higher for all authentication and licensing API calls (*.officeapps.live.com and *.msftauth.net). On older Windows 10 client builds or machines with legacy hardening policies, TLS 1.2 may not be enabled by default in Schannel or WinHTTP libraries. When Office attempts to connect to the licensing cloud, the TLS handshake fails silently, dropping the app into an unlicensed state.

# Diagnostic Verification:

Run PowerShell to check enabled Schannel client protocols:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -ErrorAction SilentlyContinue

If DisabledByDefault is 1 or Enabled is 0, TLS 1.2 is restricted.

# Step-by-Step Fix:

Enable TLS 1.2 Client and Server in Registry via PowerShell:

Open PowerShell as Administrator and execute:

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Force | Out-Null

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Name "Enabled" -Value 1 -Type DWORD

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Name "DisabledByDefault" -Value 0 -Type DWORD

Enforce Strong Cryptography for .NET Framework:

Run in administrative PowerShell:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWORD

Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWORD

Restart Workstation and test Office activation.

# Prevention & Long-Term Monitoring:

Enforce TLS 1.2+ configuration baselines across all enterprise operating system templates.

Related Diagnostic Guides

Fix Copy text (Ctrl-C or context menu) not working on browsers

Windows Credential Guard Blocking App Exclusions: How to Fix It

WordPress Redirecting to Spam Websites: How to Fix It

Malicious Browser Extensions: How to Detect and Remove Them

Unreal Engine Shader Compilation Stuttering: How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website