A successful sign-in proves one thing:
THE IDENTITY WAS AUTHENTICATED.
It does not prove the identity should have access.
I used to treat those events as if they were nearly the same problem. They aren't.
That distinction changes the investigation.
Consider a user attempting to access an enterprise application.
Repeating MFA isn't the answer.
Resetting the password isn't the answer.
The authentication system already did its job.
THE INVESTIGATION MOVES FORWARD.
- GROUP MEMBERSHIP
- APPLICATION ASSIGNMENT
- CONDITIONAL ACCESS
- RBAC
- RESOURCE PERMISSIONS
- ENTITLEMENTS
The question is no longer whether the system trusts the user's identity.
The question is whether that identity possesses the access required for the resource.
When investigating an access failure, establish the point of failure before changing anything.
VERIFY AUTHENTICATION
Did the credentials succeed?
Did MFA succeed?
Was the authentication method sufficient?
VERIFY POLICY
Did Conditional Access evaluate the sign-in?
Which policies applied?
Which failed or did not apply?
VERIFY AUTHORIZATION
Is the user in the correct group?
Is the application assigned?
Does the identity hold the required role?
Does the resource permit access?
VERIFY STATE
Was access recently changed?
Could an existing session or token represent an earlier state?
Do the logs confirm the assumed behavior?
Do not troubleshoot the entire identity chain when the evidence has already narrowed the problem.
If authentication succeeds, acknowledge it.
Then move forward.
Authentication establishes identity.
Authorization establishes permission.
Confusing the two wastes time. Understanding where one ends and the other begins turns an access problem from guesswork into an investigation.
OBSERVE FIRST.
CHANGE SECOND.
VERIFY LAST.