University Quishing Simulation: Campus QR Checklist

Universities use QR codes for campus maps, room access instructions, event registration, parking, library services, surveys, payments, device setup, and student support. A university quishing simulation should test whether authorized employees verify an unexpected code, protect the action behind it, and report it through a trusted channel—not merely whether someone scans.

The safe version is deliberately narrow. It stays inside an approved staff population, uses fictional context and controlled destinations, excludes students and the public, and includes a removal and recovery plan for every physical code. It also tests the institution around the employee: the service desk, security operations center, facilities team, communications office, privacy team, and business owner.

This guide is defensive. It does not provide malicious QR payloads, physical-tampering techniques, credential-capture methods, or instructions for bypassing campus security controls.

Why campuses need a separate quishing plan

A university is not one office. It may combine teaching buildings, laboratories, libraries, hospitals, residences, sports venues, museums, retail spaces, conference facilities, and public events. Central IT can set policy, while colleges, departments, research groups, student services, and third-party operators create their own signs and digital journeys.

That decentralization makes QR ownership difficult. A code on a noticeboard may belong to facilities, a lecturer, a student society, a conference organizer, a vendor, or nobody who still works at the institution. Employees cannot judge a code only by the quality of the poster or the familiarity of the building.

The audience is also mixed. Staff, students, applicants, parents, contractors, patients, visitors, and the public may share the same space. A staff awareness exercise can therefore reach people who were never authorized to participate. Even a harmless learning page may create confusion, accessibility problems, or concern that a real campus service has been compromised.

Treat the exercise as one role-specific component of a broader phishing awareness training program. It should improve trusted verification and reporting—not create a campus scavenger hunt or an individual blame score.

Inventory campus QR workflows before testing

Start with a short discovery exercise involving security, central IT, the service desk, facilities, communications, privacy, procurement, finance, libraries, research IT, and representatives from the participating faculty or service. Record where legitimate codes appear, who owns them, what destination is expected, and what action follows.

Common university QR workflows include:

• campus maps, room directories, wayfinding, and accessibility information;
• library access, equipment booking, reading lists, and digital collections;
• lecture attendance, course materials, learning platforms, and classroom feedback;
• research recruitment, laboratory instructions, study information, and conference posters;
• student services, careers, wellbeing, accommodation, and international-office appointments;
• guest Wi-Fi, device enrollment, software access, and service-desk support;
• parking, transport, bicycles, lockers, printing, catering, and vending;
• events, sports, museums, open days, alumni programs, and fundraising;
• invoices, expenses, procurement, payroll, and staff benefits;
• safety notices, maintenance requests, building access instructions, and emergency information.

For each high-trust code, record an accountable owner, approved domain, placement or delivery channel, start date, expiry date, and reporting contact. If the institution cannot identify an owner or confirm a destination, repair that operational gap before simulating it.

An inventory also reveals abandoned posters, expired campaign pages, inconsistent domains, inaccessible alternatives, and codes that ask users to trust a destination without enough context. Those findings may reduce real risk more quickly than a training campaign.

Define the staff decisions you want to improve

Choose one or two observable behaviors for a pilot. Avoid combining every campus scenario into a single test.

Verify the service independently

Employees should be able to confirm a QR-driven request without relying on the code itself. The trusted route may be the university service catalogue, official app, staff intranet, published phone number, building reception desk, or known business owner.

A useful exercise measures whether the employee checks the request through that route. It should not ask them to inspect a destination manually, experiment with a suspicious site, or provide account information.

Protect the action after the scan

The code is only the entry point. The protected decision may be signing in, installing software, sharing a document, changing bank details, approving a payment, connecting a device, disclosing research information, or granting physical access.

Training should teach employees to pause before that consequential action. A scan by itself is an ambiguous signal because mobile operating systems, security tools, link previews, and accidental camera recognition can create activity that is not a considered human decision.

Report without rescanning

Employees need a route that works on a phone and does not require them to open the questionable code again. That may be a mobile reporting form, a known service-desk number, a security channel, or a facilities workflow for physical signs.

The report should capture the location, surrounding context, and visible owner while minimizing personal data. A photograph may help when policy permits it, but staff should avoid including faces, access badges, research material, health information, student records, or private screens.

Contain the physical item safely

Employees should know who is authorized to isolate, cover, remove, or replace a questionable sign. They should not destroy evidence, confront another person, or remove legitimate safety and accessibility information without confirmation.

Facilities and security teams need a documented handoff so that a reported code can be assessed quickly and the affected space can remain usable.

Keep students, visitors, and public spaces out of scope

Written scope should name the authorized staff population, exact channel or location, operating window, code owner, destination owner, data rules, stop conditions, and person who can disable the exercise.

Use these non-negotiable guardrails:

• no placement in public entrances, open noticeboards, libraries, residences, classrooms in use, transport stops, sports venues, museums, catering areas, or student-service queues;
• no targeting of students, applicants, parents, research participants, patients, alumni, visitors, delivery workers, or the public;
• no use of real student records, research data, grant details, health information, disciplinary matters, emergencies, invoices, donations, or payment instructions;
• no collection of passwords, passkeys, authentication codes, identity documents, payment data, device fingerprints, precise location, or unrelated mobile metadata;
• no app installation, uncontrolled redirect, advertising network, third-party tracker, or production login page;
• a controlled HTTPS destination that provides immediate, neutral learning feedback;
• an expiry mechanism, tested emergency disable function, and safe closure page;
• a location and removal record for every physical code, with dual verification where appropriate;
• an accessible non-QR alternative for any legitimate campus information near the exercise.

If a university cannot prevent unauthorized people from encountering a code, move the pilot into an access-controlled staff channel. Physical realism does not justify accidental enrollment of the campus community.

Do not run exercises during emergencies, examinations, enrollment deadlines, payroll incidents, major system outages, industrial action, high-profile events, or other periods when ambiguous messages could cause disproportionate harm.

Buyer checklist for a university quishing platform

Ask vendors to demonstrate the entire controlled workflow. Generating a QR image is the least important part.

1. Destination and redirect control

Administrators should be able to review every destination and redirect before launch, lock approved content, disable a campaign immediately, and define what happens after expiry. The provider should explain how copied or forwarded codes are handled.

Confirm that learning pages cannot collect secrets and that custom content requires review. A university should not need a live identity-provider page to deliver useful feedback.

2. Decentralized ownership and approval

The platform or operating process should record the sponsoring department, campaign owner, destination owner, approver, authorized audience, locations, placement time, and removal deadline.

Role-based access matters in a federated institution. A departmental administrator should not automatically see employee-level results from another faculty, research unit, or subsidiary. Central security still needs enough visibility to govern risk and stop a campaign.

3. Audience controls and reliable exclusions

Buyers should be able to target a small authorized staff group and exclude students, contractors, leavers, people on protected leave, shared accounts, service identities, and anyone outside the approved employment relationship.

Identity data from HR, directories, and learning platforms can disagree. The provider should support reconciliation and explain which source is authoritative before delivery.

4. Physical-code governance

Every physical code needs a unique identifier, accountable owner, exact placement, approval, expiry, and confirmed removal. Identifiers should not expose an employee, department, or campaign secret.

Use dual control for physical distribution. One person should not be able to create, place, and close a campus exercise without independent review. The system should make missing removal evidence visible before a campaign is considered complete.

5. Mobile reporting and institutional routing

Reporting must work for employees away from a managed laptop. The platform should integrate with the university's trusted service-desk or security route without forcing a rescan.

Test routing across central IT, departmental IT, campus security, facilities, communications, and privacy. A report about a code in a laboratory doorway may need different handling from a code in a staff email, but employees should not have to understand the internal organization chart first.

6. Minimal, explainable telemetry

Ask exactly what is recorded when a code is previewed, scanned, opened, reported, or blocked. Mobile browsers, managed security services, link scanners, messaging platforms, and network tools may visit destinations automatically.

Prefer a documented, minimal event set over device fingerprinting or broad location collection. The platform should separate confirmed human decisions from automation where possible and label uncertainty where it cannot.

7. Privacy, worker representation, and evidence

Review role-based access, retention, deletion, audit logs, regional processing, subprocessors, anonymization, and aggregate reporting. Depending on jurisdiction and institutional practice, privacy teams, employee representatives, unions, or works councils may need to review the program.

Evidence should show authorization, audience, timing, feedback, reporting, corrective actions, and improvement without exposing unnecessary individual-level data. Do not reuse simulation data for employee discipline, academic decisions, performance management, or unrelated research.

8. Incident and recovery controls

The SOC, service desk, facilities team, departmental IT, and communications office need a trusted way to confirm an authorized exercise while continuing to investigate mismatched codes as real incidents.

Ask the provider to demonstrate emergency disablement, out-of-scope visitor handling, report reconciliation, physical removal, notification, data correction, and audit export. A live campaign must never become a reason to dismiss a genuine report.

Measure campus readiness, not curiosity

Use metrics connected to the protected workflow:

• report rate and median time to first report;
• independent verification through the approved campus route;
• correct identification of the service or code owner;
• containment time for a questionable physical code;
• service-desk, facilities, and SOC triage accuracy;
• completion of concise follow-up learning;
• repeat improvement by workflow or group, where policy permits;
• operational and accessibility impact;
• data-quality limitations, including automated visits and unknown scanners;
• confirmed removal or expiry of every exercise artifact.

Interpret differences carefully. A low reporting rate in a laboratory or field station may reflect poor mobile connectivity, an unavailable support route, or unclear ownership—not weaker employees. Fix the process before adding more training.

The US Cybersecurity and Infrastructure Security Agency recommends recognizing suspicious requests, resisting pressure, and reporting phishing through trusted channels in its guidance on recognizing and reporting phishing. Apply those principles to campus QR prompts while adapting verification and reporting to the institution's structure.

Run a bounded campus pilot

Start with one staff-only workflow, one controlled location or digital channel, and a small authorized group. Include the business owner, central or departmental IT, service desk, security analyst, facilities contact, privacy stakeholder, and representatives from the participating employees.

1. Document the objective, scope, exclusions, data rules, stop conditions, and removal plan.
2. Verify the legitimate QR inventory and select one low-risk staff workflow.
3. Confirm that the destination, reporting route, feedback, disable function, accessibility alternative, and expiry work on approved devices.
4. Brief response teams without broadly revealing the scenario.
5. Place or deliver the exercise only inside the controlled staff environment.
6. Reconcile scan, report, support, and physical-removal records before interpreting results.
7. Fix one workflow gap, communicate the safe behavior, and retest it before expanding.

Use the product-oriented QR and quishing simulation overview to compare controlled delivery, learning, and evidence capabilities. For mixed office and remote environments, also review the quishing awareness guide for hybrid workplaces.

Common mistakes to avoid

• placing test codes where students, visitors, contractors, or the public can scan them;
• using live safety, access, payment, research, teaching, or student-service workflows;
• assuming a professional-looking campus poster proves ownership;
• importing student or learning-platform data into a staff exercise;
• measuring scans without testing verification, reporting, containment, and removal;
• requiring employees to rescan a questionable code to report it;
• collecting device, location, identity, or research data the objective does not need;
• scheduling during examinations, enrollment deadlines, emergencies, or outages;
• ranking departments without accounting for different workflows and reporting access;
• failing to remove or expire every physical code;
• dismissing real reports because a training campaign is active.

Frequently asked questions

Should students be included in a university quishing simulation?

Not in an employee-awareness exercise. Keep the authorized audience to staff whose participation has been approved. Student security education requires separate governance, accessibility, privacy, communication, and consent decisions; do not include students accidentally through a public code.

Can the exercise use a real campus login page?

No. Use a controlled learning destination that does not request or accept credentials, passkeys, authentication codes, recovery codes, or personal data. The learning objective is verification and reporting, not proof that a realistic login page can capture a secret.

Where can physical test codes be placed safely?

Only in a location that is genuinely restricted to the authorized staff group and where the institution can track, disable, and remove the code. If students, visitors, contractors, or the public may enter, use a controlled digital staff channel instead.

What is the best KPI for campus quishing training?

Use a combination of reporting, time to report, independent verification, correct routing, and physical containment. Include operational impact and automated-scan uncertainty so results are not reduced to a misleading scan rate.

How often should a university run QR phishing tests?

There is no universal cadence. Start with one bounded pilot, repair the reporting or ownership gap it reveals, and retest the behavior. Expand only when the institution can control the audience, destinations, data, response process, and physical cleanup reliably.

Make the campus safer without making the exercise larger

The strongest university quishing program is governed like a campus service, not staged like an attack. It gives every code an owner, protects students and the public from accidental participation, makes mobile reporting easy, and treats removal and recovery as part of the test.

If you want to evaluate controlled QR phishing exercises alongside email and mobile awareness, Sign Up and start with one staff-only workflow.