Scenario
An internal API is moved behind a new Access application and only some users keep seeing 403 responses from a browser session that otherwise looks authenticated.
A Cloudflare Access policy looks correct and one API still returns 403 because the service worker cached an old JWT audience after the application moved to a new Access app
Login succeeds, yet the backend rejects requests because the browser keeps presenting a token minted for the previous Access audience.
What to check first
- Identify the primary failure signal in the The Edge Session Was Valid for the Wrong Access Audience scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Compare the JWT audience and cached session artifacts before rewriting the policy itself.
Questions worth viewing together
Community-field security problem inspired by Cloudflare Access community patterns where cached JWT audience drift caused 403 errors after an app move. A valid token can still be the wrong token for the app now enforcing it.
Teams often blame policy order when the client is replaying a stale Access audience.
Access app migrations should account for cached client tokens and worker-side session state.
Similar cases seen in the field