Unexpected application
A file, invitation, or workflow asks the employee to approve an app they do not recognize or did not request.
Consent phishing persuades a user to authorize an application to access account data or perform actions, often through a legitimate identity provider's permission screen.
Use this guide to turn the threat into a clear employee decision, a safe practice scenario, and a reporting step your organization can support.
Plain-English definition • Warning signs • Safe simulation ideas • Reporting practice
Consent phishing persuades a user to authorize an application to access account data or perform actions, often through a legitimate identity provider's permission screen.
The sign-in or consent page may be hosted by a genuine platform. The key decision is whether the application, publisher, requested permissions, and business purpose are expected—not only whether the page URL looks authentic.
Source: CISA Phishing Guidance
No single clue proves that a message is malicious. Teach employees to combine the request, sender, business context, destination, and available verification route before acting.
A file, invitation, or workflow asks the employee to approve an app they do not recognize or did not request.
The app requests access to mail, files, contacts, calendars, or organization data beyond the stated task.
The publisher cannot be matched to an approved service, project owner, or documented business need.
| Moment | Employee action | Program preparation |
|---|---|---|
| Before acting | Stop at the permission screen and confirm the application, publisher, requested access, and business owner through the organization's approved software or support process. | Publish the authentic contact, application, or reporting route somewhere employees can reach without using the message. |
| When uncertain | Pause the request and report it through the approved channel with enough context for review. | Explain what the response team needs and how employees will know that their report was received. |
| After an interaction | Stop, contact the responsible team promptly, and describe the action taken without hiding the mistake. | Provide a well-known response route and avoid communications that discourage early reporting. |
Source: NIST: Recognizing, verifying, and reporting phishing
Choose one learning objective per exercise. Use fictional people, organizations, accounts, payments, documents, and events, and test the reporting route before sending to employees.
Use a static fictional example to identify the app name, publisher, permission scope, and safe escalation route.
Present an invented document invitation that requires a new application and practice opening the approved service instead.
Use a tabletop to rehearse how an employee reports an application they may already have authorized.
Write down the consent phishing clue being practiced, the expected action, the authorized audience, and the owner of follow-up.
Test the independent verification route, message-reporting option, response handoff, and employee support path from a representative account.
Check delivery, links, landing content, accessibility, event records, automated inspection, stop conditions, and the explanation employees will receive.
Reconcile intended recipients, successful deliveries, unique employee events, verified reports, response handling, and completed follow-up before drawing conclusions.
Source: NIST SP 800-50 Rev. 1: Building a Cybersecurity and Privacy Learning Program
Record actual counts and denominators for delivery, unique recipient events, reports, and follow-up. Separate automated email inspection and repeat events where the available evidence supports doing so.
A consent phishing exercise samples one scenario under one set of conditions. It does not establish an employee's intent, overall security awareness, or likelihood of responding the same way to a real attack.
Use findings to improve the real workflow: clearer verification instructions, easier reporting, faster response handling, better role-specific training, or a business control that reduces reliance on email alone.
Common questions about Phishmake's features, onboarding, and support, answered to help you get started with confidence.
Yes. A real identity platform can display a request from an unwanted application. Employees should review what app is requesting which permissions and why.
They should report it promptly through the organization's incident or support route and provide the app name and approximate time. The responsible team can then follow its established investigation and revocation process.
It can be practiced when the scenario is authorized, proportionate, and tied to a real reporting or verification process. Do not ask employees to grant real permissions, register an unapproved application, collect access tokens, or connect a simulation to production tenant data.
Review successful delivery, unique employee events, reports, response handling, and completed follow-up. Include scenario difficulty and operating context, and do not treat a click or report as a complete measure of employee risk.
Use Phishmake to run controlled employee simulations, review campaign activity, assign relevant training, and keep follow-up records in one workflow.