For your own authorised work or school access
Use the organisation’s account and recovery rules. Personal Microsoft accounts have a different recovery process; an email alias, guest invitation and app licence are not interchangeable.
Step 1 of 9
In this guide
Identify the account and genuine sign-in
Identify the account and genuine sign-in
Open the intended Microsoft app or your organisation’s known Microsoft 365 start page yourself. Do not follow an unexpected email, text, search advertisement or caller’s login link. Check the actual work/school sign-in name with the responsible owner; it may differ from an email alias or a personal Microsoft account using a similar address.
Microsoft’s sign-in guidance distinguishes installed apps and web access. Check the account and organisation shown before entering credentials. A guest invitation may require the invited identity and correct organisation context; creating another account does not automatically grant the original access.
If the prompt is unexpected, a recovery method is unfamiliar or someone wants your code, stop ordinary sign-in troubleshooting and contact the responsible IT/security team through a known route. Do not approve a request merely to make repeated prompts stop.
Confirm the intended account, organisation and genuine entry point. Unexpected prompts or unfamiliar security information need owner/security review rather than repeated approvals.
Next: Record the error and preserve open workRecord the error and preserve open work
Record the error and preserve open work
Privately note the app, account type, device, time/time zone, exact message and whether the failure occurs before a password, at verification or after the app opens. If displayed, retain the error code, request/correlation ID and timestamp. Redact unrelated personal data before sending a screenshot to authorised support.
Keep any unsaved document or local-only data intact. Do not remove accounts, delete an Outlook profile, clear all credentials or reinstall Authenticator as the first response. Those actions can remove useful access or unsynchronised records without fixing the actual cause.
Microsoft’s sign-in log guidance explains how an authorised administrator can match failed events to the details. You do not need to acquire an administrator role to report the problem. Never include passwords, verification codes, QR enrolment images, session cookies or recovery secrets in the ticket.
Preserve open work and the exact failure/time privately. Error details help the authorised owner; credentials and verification secrets do not belong in support messages.
Next: Check whether the problem is local or widespreadCheck whether the problem is local or widespread
Check whether the problem is local or widespread
Establish whether the issue affects only one app/device, one account or several authorised users. Ask colleagues through an approved channel without sharing logins or requesting their passwords. If the network is generally offline, begin with the internet connection guide.
The responsible administrator can check Microsoft 365 service health for relevant incidents. A public status page may help when admin sign-in is unavailable, but it does not expose every organisation-specific problem. No listed incident does not prove your account/device is healthy.
Choose the route matching the actual message. Follow a confirmed incident’s updates rather than reset working accounts. Stop repetitive password/code attempts when throttling, lockout or risk warnings appear; use the displayed instruction and IT owner rather than guess a fixed waiting period.
Identify scope and any relevant incident before changing the account. Stop repeated attempts when blocked and route the exact error to the appropriate recovery, verification or policy process.
More checks6 detailed checks
Use the correct work-account recovery process
Use the correct work-account recovery process
Check the intended sign-in name and keyboard layout/Caps Lock without exposing the password on a shared screen. If a genuinely forgotten or expired work/school password is the issue, use your organisation’s known recovery route and Microsoft’s work/school password-reset guidance.
Self-service reset must be enabled by the administrator and suitable verification information must already be available. If it is unavailable, your account is disabled or the required method cannot be used, contact the actual IT helpdesk through a known channel. Personal Microsoft account recovery forms are not a substitute for that organisation’s identity process.
Complete identity checks yourself in the genuine process; do not send your new password or a one-time code to a helper. A blocked account, policy restriction or federation problem can remain after a reset. Do not keep changing passwords or create a duplicate work account when the message points elsewhere.
Use enabled organisation recovery or the responsible helpdesk, keeping secrets private. Resetting a password does not override disabled accounts, resource permissions or security policy.
Next: Verify the intended service and retain safeguardsHandle MFA without removing your only method
Handle MFA without removing your only method
Approve only the sign-in you initiated, with the expected app/account/context. For a genuine attempt with no prompt, check that the phone is connected, the authenticator app opens, the correct account is present, notifications are permitted and the phone’s date/time are correct. Use the official store’s supported app update when appropriate.
Microsoft’s incomplete-authentication guidance describes these basic checks. If the genuine page offers another method you previously registered and can legitimately use under policy, choose it. Do not use somebody else’s phone/code, turn MFA off or remove the only registered method to force a new setup.
A lost/replaced phone, missing work account or unavailable approved method needs the organisation’s verified recovery/re-registration process. Restoring a phone/app backup is not proof that work-account authentication has been re-established. Keep any remaining legitimate access until the owner provides a safe transition; unexpected prompts or changed methods require security review.
Check a genuine initiated attempt and retain working methods. Lost access or unexpected prompts go through the actual owner’s verified recovery/security process, not MFA disable or repeated approvals.
Compare supported app and browser contexts
Compare supported app and browser contexts
Where your organisation permits it, compare the same intended service in its supported browser and the current genuine desktop app. Preserve work first and make one deliberate attempt. Check the account/organisation selected in each; a successful personal login says little about the work account.
If the wrong account is being automatically selected, use the normal account picker or an approved separate browser profile. A private window is only a limited session comparison when policy permits; it may not carry the device/session conditions required for work access. It is not a way to evade Conditional Access or proof that existing cookies are malicious.
Record which context succeeds and the exact remaining error. Do not clear every browser profile/credential, disconnect the Windows work account, disable VPN/security filtering or change global browser protections. A browser success with a desktop activation error needs app/entitlement review; an opened app with Access denied needs resource/permission review.
Compare the same account/service in permitted contexts and preserve data. A differing result narrows the question; it does not authorise credential wipes, management removal or policy bypass.
Next: Leave policy and entitlement decisions with the ownerLeave policy and entitlement decisions with the owner
Leave policy and entitlement decisions with the owner
Messages about a compliant/managed device, approved location, required authentication or blocked access may be deliberate policy. Microsoft’s Conditional Access troubleshooting uses actual error details and sign-in logs to identify the decision. Give those details to the responsible administrator rather than remove the policy or enrol a personal device without agreement.
Similarly, a signed-in user may lack an assigned service, app entitlement, guest invitation or permission to the requested item. Ask the authorised owner to verify the exact user, organisation and resource. Do not buy a licence, assign broad roles, disable security defaults or share an administrator account as a generic login fix.
If the account is disabled, a risk block appears, several users are affected or the organisation uses a separate identity provider, stop local experiments and use its supported escalation. Any configuration change needs its owner, evidence, scope and a plan to retain required protection.
Have the actual owner verify policy, identity, entitlement and resource access. Authentication, licensing and authorisation are distinct; do not broaden permissions or weaken safeguards to obtain a successful login.
Verify the intended service and retain safeguards
Verify the intended service and retain safeguards
In the intended account and organisation, perform a harmless authorised task matching the original issue: open a permitted non-sensitive document or confirm the required app is usable. Check any relevant saved/sync state without deleting files or sending a real message. Do not sign every device out or remove the only working method as a recovery test.
Confirm required MFA/device/security policy remains in place and the known failure has stopped. Record the narrow cause/change, result and any outstanding app/resource issues privately. If account compromise was suspected, a successful login does not finish session, account, mail-rule or incident-response work; follow the responsible team’s plan.
Stop unrelated changes once the actual task is restored and the remaining limits are understood. If it works only with protection off, the correct account cannot be selected or saving/access still fails, the problem is not fully resolved. Keep the evidence for the owner rather than declare an all-clear.
Verify the intended harmless task under required safeguards, record limits and stop unrelated changes. Successful sign-in is not complete incident remediation or proof that every resource is accessible.
Back to the symptom checkerEscalate a persistent or suspicious sign-in
Escalate a persistent or suspicious sign-in
Use your organisation’s known IT/security contact for disabled accounts, lost verification access, unexpected prompts, policy blocks or repeated failures. Supply the app/device, intended identity/organisation, exact message/time and permitted comparison results. Share logs/screenshots only through the agreed private process with unnecessary secrets removed.
Our Microsoft 365 support can discuss the symptom and an authorised assessment. Agree who owns the tenant/account and any recovery or configuration work. No external technician can promise to override Microsoft or an organisation’s identity verification, policy or ownership requirements.
If credentials were entered on a suspicious page, report that exposure promptly and use the genuine affected-account response. Our phishing guide separates safe verification from incident response. Do not send more codes, pay a recovery demand or install a caller’s remote helper to get the account back.
Use the actual owner’s verified recovery or incident process with minimal private evidence. Keep work and safeguards intact; do not treat a support conversation as authority to bypass identity or policy.
