An employee follows a document link, signs in through a familiar provider, and sees a request to let an application read their data. The provider page may be genuine. The decision being requested may still be inappropriate.
This is why “check that the login page is real” is useful advice but not a complete application-consent policy.
Explain the decision in ordinary language
Microsoft's consent-phishing guidance describes attacks that seek application permissions rather than relying only on stealing a password.
For employees, the key question is whether the application, requested access, and business task match. A service that appears to show one document should not be trusted merely because the consent dialog uses an established identity provider.
Do not make users responsible for decoding every technical scope. Provide an escalation route and a clear rule for unfamiliar or unexpectedly broad requests.
Give administrators a consent model
Decide which permissions users may grant, which need administrative review, and who owns approved applications. Follow the provider's available controls and document exceptions.
A hypothetical scheduling app may have a legitimate business purpose. That does not mean every permission it requests is necessary. Ask what the app needs to do, what data it reaches, and how access can be removed.
Revisit grants when an application is retired or its owner changes. An approved app should not become unowned background access.
Investigate the grant, not only the sign-in
If a person reports approving an unfamiliar app, establish the application identity, account, time, requested permissions, and business context. Use the provider's administrative view to confirm the grant rather than relying only on a screenshot.
Review relevant resource activity through authorized tools. Remove or restrict access according to the incident plan and provider documentation.
A password change may be warranted for separate evidence, but it should not be treated as proof that the application's authorization was removed. Tokens and passwords have different roles.
Make reporting easy after a mistake
People should be able to say “I clicked Allow” without first deciding whether that action caused an incident. The response team can establish the consequences.
Use a harmless tabletop to test the handoff between the help desk, identity administrator, and data owner. The exercise should produce a clear owner and a verifiable access decision, not a contest to trick users.
Read application recovery routes outside SSO for another hidden path. Strong authentication protects the sign-in; thoughtful authorization governs what happens after it.