Skip to content

alphaPlan · Facilitator notes

Verify before you trust

Reference unit: Cybersecurity → Social engineering → Phishing, smishing and vishing

Outcomes

  • • Identify evidence without treating one clue as proof
  • • Choose an independent verification route
  • • Revise and defend a decision under pressure

Time and materials

  • • 35 minutes; 20-minute short version
  • • Learner sheet, these notes and pens
  • • Optional projector for the digital activity

Fictional educational message

From
Shërbimi i Llogarive <ndihma@hyrje-sigurt.example>
Subject
Urgent: confirm your account before 18:00

Hello,

We detected an unusual sign-in to your account. Access will be suspended today unless you confirm your identity.

Open the link below and enter your password and the one-time code sent to your phone.

hyrje-sigurt.example/konfirmo

Account support team

Fictional educational message. It does not represent a real Albanian institution, address or service.

Facilitation sequence

  1. 1 · 5 min. Learners commit privately to a first decision and reason. Do not identify clues yet.
  2. 2 · 10 min. Collect evidence. For each clue ask: what does it suggest, and what can it not prove alone?
  3. 3 · 8 min. Learners write an independent verification channel and exact question, then compare with the worked example.
  4. 4 · 7 min. Add one pressure card. Require revision without abandoning independent verification.
  5. 5 · 5 min. Debrief and write one reusable rule.

Evidence and reasoning notes

The sender address is unfamiliar

An unfamiliar address weakens the identity claim. It is a reason to verify, not proof by itself.

The deadline creates pressure

Urgency narrows the time available to think. A safe process should still work when someone tries to rush it.

It asks for a password and one-time code

Passwords and one-time codes authorize access. A legitimate helper should not ask you to disclose them.

It supplies its own sign-in link

Using the supplied link keeps verification inside the channel that may be hostile. Open the known service yourself instead.

The request bypasses the normal process

Unexpected identity checks should be confirmed through a separate route you already trust, not through instructions in the request.

Strong verification example: I will not use the link or share a code. I will open the service from my saved bookmark or call the published number I already know and ask: ‘Was this account warning sent by you?’

Alternative defensible answers: Reporting, asking a trusted colleague or opening the known service directly can all be sound if the learner does not disclose secrets or rely on contact details supplied by the request.

Pressure-test cards

Complication 1

A caller says they are the sender and asks you to read the one-time code aloud.

Complication 2

The message appears to be forwarded by your manager with: ‘Please do this now.’

Complication 3

A second message says the deadline is now ten minutes away.

Misconceptions and debrief

  • • Polished writing or a familiar voice does not prove identity.
  • • A spelling mistake is not proof of fraud; several contextual signals matter.
  • • Replying or calling the supplied number is not independent verification.

Ask

  • • Which evidence changed your decision?
  • • What made the chosen channel trustworthy?
  • • What rule still works when the message looks perfect?

Extension: Teams rewrite the request into a legitimate safety notice that never asks for secrets and directs people to an independently known channel.

shënim: ky material u krijua në kuadër të projektit 'U.S. Cybersecurity Leadership in AI for Albania', financuar nga departamenti i shtetit i shteteve të bashkuara. mendimet, gjetjet dhe përfundimet e paraqitura këtu janë të autorit(ëve) dhe nuk pasqyrojnë domosdoshmërisht ato të departamentit të shtetit të shteteve të bashkuara.

Disclaimer: This material was created on behalf of the 'U.S. Cybersecurity Leadership in AI for Albania' project, funded by the United States Department of State. The opinions, findings, and conclusions stated herein are those of the author(s) and do not necessarily reflect those of the United States Department of State.

Disclaimer

Found something unclear, outdated or improvable? Suggest an improvement