Technical Anshu
Tutorials Blog
🛡️ Landing Page Rules

The Simulated Landing Page Must Teach and Must Never Collect Real Passwords

Every simulation funnels to one page. Built well, it converts an embarrassing click into the most memorable security lesson of the year. Built badly - with a working login form that stores what staff type - it becomes the most dangerous database in your company. This page covers both the design and the hard rule.

✍️ Technical Anshu🛡️ Landing Page Design⏱️ Records the click, never the password
🎥 Watch the full video - the phishing simulation setup shown step by step

The click is not the lesson; it is the doorway to the lesson. What loads in the next two seconds decides whether the employee leaves sharper or leaves angry. Keep it calm, make it specific, and above all keep it incapable of collecting the one thing it must never hold.

The teaching landing page - what it shows and what it stores
✔ Headline: this was a practice test run by your own IT team
✔ The three warning signs from that email, highlighted
✔ What to do next time: check the sender, hover the link, report it
✔ Recorded: the click, the time, the campaign - nothing else
✘ Password field that stores real passwords: does not exist
Notice the last line. A teaching page with no working credential form cannot leak credentials - the safety is in the design, not in a promise.
1

The teachable moment, written properly

The page should say, in plain words and within the first screen: this was a simulated phishing email sent by your own organisation as training; you are not in trouble; here is what gave it away. Then show the actual evidence from that campaign - the sender domain next to the real one, the link text beside its true destination, the urgency line that pushed for speed. Specific beats generic: people remember the exact tell they missed, and they look for it next time, including on real mail.

2

The hard rule - never collect real passwords

Some platforms ship templates with a login form that captures whatever is typed. Do not use them. The reasons are not soft: a stored set of real staff passwords is a high-value breach target you created yourself; handling it drags the programme into data-protection trouble; and it teaches nothing - the click already proved the point. Configure the page to record the visit only. If a form appears for realism, it must not transmit or store entries, and the honest design is simpler still: no working form at all, straight to the lesson.

3

What the page should contain

  1. The calm headline and the not-in-trouble line.
  2. The two or three warning signs from this specific email, shown side by side with the genuine versions.
  3. The one habit to build: pause, check the sender and the link, and use the report button.
  4. Where the five-minute follow-up module lives, and a word of thanks for taking part.
4

The small list of data you may record

Record the minimum the programme needs: that the page was reached, when, and which campaign it belonged to - plus, from the mail platform, who reported the message, because reporters are the success story. That is the whole list. No keystrokes, no credentials, no personal device snooping. Data you never collect can never leak, never embarrass anyone in a meeting, and never need defending to HR.

🔴 If a template asks for a real password, the template is wrong - not the employee who refuses it. Disable credential-capture options in the platform, and put the ban in the approval document so no future operator re-enables it by accident.

🎥 Watch the Complete Video

Watch the video set up the landing page inside the platform and check what a campaign records.

▶️ Watch Full Video
❓ Common Questions (FAQ)

Our platform has a ready-made credential capture template. Should we use it?

No. Leave it disabled. The click already demonstrates the risk; harvesting real passwords adds a serious data-protection and breach problem while teaching nothing extra. Record the visit, show the lesson.

Should the landing page say who clicked or name their department?

No. Keep the page identical and generic for everyone. Individual follow-up happens privately, from the programme owner - never through a page that singles a person out in front of their screen.

What if a worried employee types something into a fake form anyway?

On a correctly built teaching page there is no working form, so nothing can be typed, transmitted or stored. That impossibility is deliberate - it is what makes the exercise safe by design.

This guide is based on the phishing simulation video by Technical Anshu • Stuck on a step? Ask in the video comments - you will get an answer there 🙏