Signed in. Still restricted. That can be correct.
One account. Two resources. Two access decisions.
Dash-Squared / Brick learning lab
Signed in.
Still a different permission.
Use one demo account to ask for two resources. Different READ decisions do not mean the identity changed.
One account / two resources
Start with one demo account.
Use Sign in (demo), then compare the two READ requests. No credentials are needed.
Play is finite. Pause or use Step to read at your own pace.
No credentials or tenant connection. These are fixed synthetic permissions. A denied resource does not sign out the account.
Read the complete explanation without playback
- Sign in (demo).A local teaching state represents one signed-in account; no credentials are entered.
- Documents READ — allowed.The example grants this account permission to read Documents.
- Payroll READ — denied.The same signed-in account lacks that separate permission.
- Keep the distinction.Identity and resource-specific permission answer different questions. Actual systems may also consider device, app, context and policy.
This example uses fixed permissions. Real access can also depend on the app, device, context and policy.
Primary source: Microsoft: authentication and authorization ↗
Checked November 9, 2026. Illustration and interaction are synthetic.
Signed in is only the first check.
Identity / a successful sign-in does not grant every permission.
Follow the idea
- Authentication verifies evidence for this account’s identity.
- Authorization allows this account to read Documents.
- A different permission decision denies access to Payroll.
Keep the limit visible
Conceptual distinction, not a literal Entra processing order. Actual access can also depend on application policy, device and context.
Can the signed-in user open Payroll?
No, not under this illustrative policy. A valid sign-in is compatible with a denied request.
“Once someone signs in, they should be able to open everything.”
A sign-in and permission to perform a particular action answer different questions.Source for this graphic: learn.microsoft.com ↗ · Checked November 7, 2026 · Illustrative example.
Two different checks
Authentication checks evidence for an account’s identity. Authorization decides whether a requested action is permitted. Passing the first check does not automatically grant every permission.
Watch the example
In our illustrative miniature office, one account can access Documents but not Payroll. The same signed-in account makes both requests. Different permissions explain the different results.
A useful outcome
A denied request may mean the policy is doing its job. It is worth checking the intended role and scope before treating every access denial as a fault.
The next smart question
Who grants this access, what does it cover, and when is it reviewed?
Independent explanation. No sponsorship or endorsement implied. Product features and policies can change; check the exact product and configuration.
Published .
MFA methods offer different protection.
Phishing resistance does not mean immunity to every compromise. Review fallback sign-in and recovery too.