Boundary
Sign-in, MFA, shared resource, VPN, token/session, or application authorization.
Cannot sign in or access a shared resource after a change
Use this flow for sign-in, MFA, VPN, shared-folder, or application permission failures after a password, policy, device, or session change.
Security first: never send passwords, MFA codes, recovery codes, API keys, tokens, or private keys. Do not disable MFA, approve an unexpected prompt, reuse a password, or broaden permissions as a workaround.
What this flow is for
A previously working account or shared resource is no longer accessible. The first split is sign-in/MFA, resource permission, session/provider state, or suspected compromise.
First safe checks
- Classify the failing boundary and record redacted exact error text.
- Confirm the intended account and provider's known official sign-in path.
- Check time/date, network, lockout/disabled state, and recent changes without revealing secrets.
- Compare one authorized known-good account or device without granting new access.
- Stop approving prompts and preserve evidence if compromise is suspected.
Best evidence
Capture this without secrets
Error and change
Exact redacted error, provider/app, time, and recent password/MFA/permission/device change.
Scope
Whether the issue follows one user, one device, one resource, or multiple users/resources.
Likely causes
Most likely problem buckets
Account or session state
Wrong account, stale token, time/date mismatch, lockout, or provider state.
Password or MFA change
A recent credential or MFA change altered the approved sign-in path.
Resource permission
Share, group, VPN, device-trust, or application authorization changed.
Suspected compromise
An unexpected sign-in, MFA prompt, recovery event, phishing message, or token concern needs a security handoff.
Next safe steps
Take one step at a time
ACT-SEC-001
Classify the boundary and capture redacted evidence before resetting or changing permissions.
ACT-SEC-002
Use the provider's known official path and verify account, time/date, network, lockout, and approved change.
ACT-SEC-003
Use documented recovery and the strongest available MFA; never share the code with support.
ACT-SEC-004/005
Compare authorized permissions without broadening access, and hand off suspected compromise.
Best follow-up ask
Is the error at sign-in, MFA, shared-resource access, VPN, or inside the application after sign-in?
When to stop and hand off
Escalate unexpected sign-ins or MFA prompts, phishing, token concerns, multi-user failures, or any request to bypass MFA or weaken permissions.
Source provenance
Reviewed against official CISA guidance
This flow uses CISA guidance to treat MFA, strong unique passwords, phishing resistance, and safe reporting as security controls—not as secrets to collect in support chat.
Prepare a security handoff
Record redacted evidence, affected resources, and approved ownership details privately for a technician or provider.
Open private discoveryContinue in support chat
The support assistant can ask the next safe question without accepting credentials or recovery codes.
Open support chat