Overview
A successful password reset proves that the identity provider accepted a new password. It does not guarantee that every application has discarded old credentials, that the correct account is being used, or that the account is licensed and allowed to access the application.
Why this happens
Applications can retain old passwords in cached sessions, Windows Credential Manager, mobile accounts, browser profiles, VPN clients, mapped drives, or application-specific tokens. Sign-in can also fail because of MFA, Conditional Access, licensing, account lockout, disabled status, or an incorrect username.
Before you begin
- Know the exact work account whose password was reset.
- Confirm the reset has completed successfully.
- Record the application's exact sign-in error.
- Do not approve unexpected MFA prompts during testing.
Click-by-click troubleshooting
Step 1: Prove the new password in the primary web portal
Action: Open a private browser window and sign in to the organization's normal Microsoft 365, Google Workspace, or application identity portal with the affected work account and the new password.
Why this matters: A clean browser session tests the identity provider without relying on the application's cached credentials.
What to look for: Confirm whether the new password is accepted and whether MFA or another policy blocks sign-in.
Expected result: If the primary web sign-in fails, stop troubleshooting the application and resolve the identity problem first.
Step 2: Verify the application is using the same work account
Action: In the affected application, review the account or profile page and confirm the exact email address. For Microsoft 365 desktop apps, open File > Account. For browsers, review the signed-in profile.
Why this matters: The application may still be trying an old account, personal account, guest identity, or previous employee profile.
What to look for: Compare the account shown in the application with the account that successfully signed in through the web portal.
Expected result: The exact same work identity should be used in both places.
Step 3: Sign out of the application and close it completely
Action: Use the application's Sign out option. Close all application windows. Reopen the application and sign in again with the verified work account and new password.
Why this matters: Signing out forces many applications to discard old session tokens and request fresh authentication.
What to look for: Note whether the application prompts for the new password, MFA, or immediately returns the same error.
Expected result: A healthy application should establish a fresh session using the verified identity.
Step 4: Check for saved Windows credentials when appropriate
Action: In Windows, search for Credential Manager and open Windows Credentials. Review entries related to the affected approved application or service. Do not delete unfamiliar credentials. Remove or update only entries you can confidently associate with the affected service and only if your organization permits it.
Why this matters: Windows can continue presenting an old stored credential after a password change.
What to look for: Look for entries containing the application name, server name, or old account.
Expected result: The application should no longer reuse an obsolete credential after an authorized cleanup.
Step 5: Check account status, licensing, and access policy
Action: If you are an authorized administrator, verify that the account is enabled, has the required license, and is not blocked by sign-in risk, Conditional Access, MFA registration, organizational unit, or application assignment rules.
Why this matters: A correct password cannot overcome a disabled account, missing application license, or access policy.
What to look for: Look for blocked sign-in status, missing license or service plan, authentication-method requirements, or policy failure details.
Expected result: The user should be both authenticated and authorized for the application.
Step 6: Test the web version or another managed device
Action: If the application has a web version, sign in there. If permitted, test the same account on another managed device.
Why this matters: A successful sign-in elsewhere isolates the problem to the original device or application installation.
What to look for: Compare whether the same account, password, MFA method, and application access succeed outside the original installation.
Expected result: The comparison should tell you whether to continue with device/application repair or identity administration.
What to look for
- Primary web sign-in fails: identity issue, not an application cache issue.
- Web works but desktop app fails: cached credentials, application profile, activation, or device state.
- Correct password plus missing license: authorization issue.
- Repeated MFA or policy errors: investigate authentication policy rather than resetting the password again.
When to stop
When to contact IT
Contact IT if the primary web sign-in fails, the account is locked or blocked, licensing is unclear, a Conditional Access or MFA policy is involved, or the application continues to reject a verified account after sign-out and a clean sign-in. Provide the username, application name, exact error, and whether primary web sign-in succeeds.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.