What is consent phishing?¶
Consent phishing deceives someone into granting a cloud application permissions that benefit the deceiver. The provider may host the genuine sign-in and consent pages; the deception concerns the application's identity, purpose or requested access rather than necessarily stealing a password.
Dave approves the wrong capability¶
Dave receives a link to PDF Converter Pro and signs in on Microsoft's genuine identity page. The consent screen asks to read files Dave can access. Dave approves it, believing the application will convert one document. Microsoft Entra then records a consent event and the application can request tokens for the permission it received.
In this fictional example, the important record is not simply “Dave logged in”. It is the grant joining a user, application, permission and resource service:
Preserve the grant and the story that produced it¶
A useful consent record should retain the application and publisher identifiers, consenting user or administrator, tenant (the organisation's cloud environment), resource service, permission names, time, result and any correlation identifier. The message, webpage or support conversation that induced approval explains why a technically valid grant may not represent an informed decision.
Then follow the application identifier into token and resource records. A broad permission describes capability; a later file, mail or contact event establishes use. Malicious OAuth access examines that later application activity, while delegated access explains the underlying grant relationship.
Consent phishing is therefore different from conventional credential phishing. Dave may keep control of his password and complete MFA himself. What the deceiver obtains is application authority issued by the provider.
Current Microsoft Entra example - checked 2 September 2026
Microsoft describes consent phishing as tricking users into granting permissions to malicious cloud applications through a consent page hosted by the legitimate identity platform. Its current audit reference includes Consent to application, Add delegated permission grant and app-role assignment events. Microsoft recommends reviewing the requested permissions, Entra audit logs and sign-ins for users authorised to use the application.
Event names, consent policy and available fields depend on product configuration and can change. Preserve the exported record and the provider definition that applied at the time.
The durable principle¶
The application, permission grant and resulting resource activity are separate propositions. A real consent event can strongly establish how an application acquired authority without establishing that the person understood the deception or personally initiated every later action.
The point to remember
Consent phishing turns a misleading request into genuine application authority. Preserve what the person saw, the exact grant and the later application events, then compare them as one sequence.
