Phishing Resilience and Authentication Design

Human-centred resilience

I wrote this work for Engineering Resilient Systems in 2024. The case study described a growing fictional organisation that had received suspicious messages from a hacktivist group and still relied on weak authentication for some internal applications.

I examined two connected problems:

1. how phishing uses social and organisational context, not only technical deception
2. how authentication can reduce the impact of a successful phish without making normal work unmanageable

The research treated employees as part of the system design. A phishing control that depends on every person spotting every message will eventually fail. A technically strong login process that people cannot use will be bypassed, weakened, or pushed into insecure workarounds.

The literature review sat behind both recommendations. I used research on phishing anatomy, workplace susceptibility, continuous training, gamified learning, password use, smart cards, biometrics, and authentication classification. The aim was to move from “train users and add MFA” to a design that accounted for the circumstances in which people make security decisions.

How phishing creates pressure

Phishing combines a delivery medium, a social vector, and a technical action. The medium may be email or another messaging channel. The vector creates trust, fear, curiosity, urgency, or obligation. The technical action asks the recipient to follow a link, open a file, submit credentials, approve a prompt, or change a payment or account process.

I used the six social-influence principles discussed by Muscanell, Guadagno, and Murphy as a way to examine that pressure:

• liking
• authority
• scarcity
• social proof
• reciprocation
• commitment and consistency

These principles describe different routes to the same decision. Liking makes a familiar or personable sender easier to trust. Authority borrows the status of an executive, service desk, supplier, or regulator. Scarcity makes an opportunity appear temporary. Social proof implies that colleagues have already acted. Reciprocation invokes an obligation to return help, and commitment relies on a previous action or established routine.

Authority and urgency were especially relevant to the case. A message that appears to come from someone able to issue instructions can shorten the recipient’s decision time. Urgent language then directs attention away from the sender address, destination domain, unusual request, or broken business process.

The submission drew on two simulated spear-phishing studies in which authority and urgency cues were associated with a mean click rate of 19.44% and an average response rate of 20%. I did not treat those figures as a universal prediction for every workforce. They provided evidence that message context can change behaviour even when the technical action is familiar.

The three-part model helped analyse a campaign without reducing it to the email text:

Component	Question
Medium	Where did the request arrive, and what trust does that channel normally carry?
Social vector	Which relationship, emotion, or organisational expectation is being used?
Technical approach	What action is requested, and what system or data would that action expose?

Changing one component changes the defensive options. A malicious attachment and a credential-harvesting page need different technical controls. An executive payment request and a fake service-desk reset need different verification processes, even if both arrive by email.

The report drew on research showing that job title alone does not reliably predict susceptibility. Team structure, experience, available support, local threat exposure, and confidence all influence how a person responds. Long-serving staff may know the organisation well but can also become overconfident. Larger groups can rely on informal assumptions about who has checked a request. Part-time or less frequently trained staff may have fewer chances to practise the reporting process.

The field study I reviewed reported several more specific relationships:

• people embedded in supportive social networks were better placed to question deceptive messages
• reliance on a help desk correlated with lower susceptibility
• leadership level did not create a reliable protection over subordinate roles
• smaller teams appeared to benefit from closer communication
• greater job tenure could coincide with greater susceptibility through confidence and routine
• part-time status could reduce exposure to training and practice
• remote or office workspace alone did not explain the result
• regions with less frequent phishing exposure could show greater susceptibility

These are associations from a particular study rather than labels to apply to individual employees. They argue for measuring the local organisation instead of selecting a “most careless” demographic in advance. A single annual presentation cannot test how the actual reporting route, approval process, workload, and message design interact.

Designing an awareness programme

I proposed a continuous programme that combined realistic exercises, immediate feedback, reporting support, and measurement over time.

A phishing simulation should begin with a defined purpose. It may be testing awareness of credential-harvesting messages, measuring whether staff use the report function, or checking whether a high-risk business process has a working verification step. Without a clear question, the exercise only produces a click rate with little operational value.

The process I documented covered:

1. define the scope and the behaviour being assessed
2. create a realistic but controlled message informed by current threat patterns
3. include staff from different roles and working contexts
4. record interaction, reporting, and non-response data
5. provide timely feedback
6. identify where process or interface design contributed to the result
7. repeat the exercise and track change

Scope needs to identify the population, systems, permitted data collection, and safeguards before any message is sent. The simulation should not collect real credentials, execute code, expose participants publicly, or interfere with a live business process. Its design should mirror a relevant decision while keeping the consequences controlled.

The result set should separate at least four outcomes: interaction, non-interaction, reporting, and no recorded response. A click followed immediately by a report tells a different story from credential submission with no report. A message ignored by everyone may indicate strong recognition, an unrealistic lure, or simply poor delivery.

Click rate is therefore only one measure. Reporting speed, report quality, repeated patterns, use of the help desk, time to triage, and the organisation’s response to a submitted message are equally useful. Staff should know where to ask for help, and the support team should be able to verify a message without making the employee regret reporting it.

A useful measurement plan would include:

Measure	What it tests
Interaction rate	Whether the scenario prompted the risky action
Reporting rate	Whether staff recognised and escalated the message
Time to first report	How quickly defenders receive an early warning
Triage and containment time	Whether the operational response works after a report
Repeat interaction	Whether feedback changes behaviour over several exercises
Role and context patterns	Where training or business-process design needs adjustment

The exercise should then feed changes into both training and controls. If recipients cannot distinguish an external message, the mail interface may need improvement. If a payment request has no independent verification route, the process is weak. If the report button produces no visible acknowledgement, employees may stop using it. If repeated authentication prompts are normal, users are being trained to approve prompts rather than inspect them.

The literature review also covered personalised learning and gamification. Short exercises can be adapted to technical confidence, role, experience, and previous results. Game mechanics can improve engagement when they support a clear learning objective, but a leaderboard should not turn security reporting into public embarrassment.

I proposed using simulations as feedback on the whole control system. A convincing phish may expose weak recognition, but it may also reveal an unclear approval process, an indistinguishable external-email warning, an overloaded help desk, or a login flow that conditions users to approve repeated prompts.

Authentication, authorisation, and identity

The second part of the work examined internal application authentication. I separated three terms that are often compressed into “login”:

• identification is the identity a user claims
• authentication verifies that claim
• authorisation determines what the verified identity can access

Authentication factors are commonly grouped as something a person knows, has, or is. Passwords and PINs are knowledge factors. Smart cards, hardware tokens, and authenticator applications are possession factors. Fingerprints and facial characteristics are biometric factors.

Identification begins the transaction by naming an account. Authentication establishes confidence that the claimant controls the required factor or factors. Authorisation applies policy after that verification, deciding which application, record, or operation the identity may access. Strong authentication does not compensate for an account that has excessive authorisation.

Each factor has different failure modes:

Factor	Strength in the case	Design concerns
Password or PIN	Familiar and inexpensive to deploy	Reuse, guessing, phishing, weak storage, insecure recovery
Smart card or hardware token	Separates possession from a memorised secret	Cost, loss, theft, readers, lifecycle management, implementation faults
Authenticator application	Can add possession to existing web logins	Device trust, enrolment, prompt fatigue, recovery, session theft
Biometrics	Convenient local user verification	Privacy, spoofing, false matches, template protection, limited revocability

The smart-card research included RFID implementations. A card can make brute-force guessing less relevant, but it can still be stolen, relayed, reverse engineered, or undermined by timing and implementation weaknesses. It also introduces issuance, replacement, reader, and support costs.

Biometrics shift the problem rather than eliminating it. Facial or fingerprint matching needs a secure capture path, protected templates, acceptable false-match and false-rejection rates, and a recovery method. A leaked biometric characteristic cannot be rotated like a password, so central storage and system design deserve particular scrutiny.

The design question was not which single factor was perfect. It was which combination gave the organisation a practical improvement in assurance.

Password managers and multi-factor authentication

I recommended a password manager, a strong password policy, and multi-factor authentication for the internal applications in the case study.

A password manager reduces the need to memorise a separate complex secret for every service and makes unique passwords more realistic. Its master credential and recovery path then become high-value parts of the design, so enrolment, device security, account recovery, and access logging need deliberate controls.

The submitted design specified a minimum of eight characters with upper case, lower case, a number, and a special character. That reflected the conventional complexity guidance used in the assignment, and the password manager was intended to make compliance manageable. I would not reuse that minimum as a current design target: it is recorded here to show the proposal that was evaluated, not as current password guidance.

Multi-factor authentication added a possession check to the knowledge factor. I considered authenticator applications on verified employee devices or organisation-managed phones. That approach was relatively accessible compared with a full smart-card deployment and could be introduced to existing web applications.

Implementation would need more than enabling a second prompt. The organisation would have to define:

• how a device is enrolled and bound to the employee
• whether personal devices are permitted or managed devices are issued
• how loss, replacement, and role changes are handled
• which actions require step-up authentication
• how recovery proves identity without becoming the weakest path
• what authentication and recovery events are logged
• how support staff respond to unexpected prompts or reported compromise

MFA does not make phishing disappear. Prompt bombing, adversary-in-the-middle sites, session theft, insecure recovery, and weak enrolment can all undermine it. The authentication flow should minimise unexpected prompts, make the requesting service clear, provide a simple rejection and reporting path, and protect recovery as carefully as normal sign-in.

Password length guidance has also developed since I wrote the coursework. The original proposal used a conventional complexity policy. For a current implementation I would favour longer unique passphrases, screening against compromised passwords, a password manager, rate limiting, secure recovery, and phishing-resistant authentication where the risk justifies it.

Connecting people and controls

The two halves of the work led to one design approach:

• train people against the situations they actually encounter
• give them a reliable way to verify and report a request
• measure reporting and response, not only failure
• reduce the number of decisions that depend on recognising a perfect fake
• use authentication controls that limit the value of stolen credentials
• review high-risk business processes as well as email content

Phishing resilience comes from the interaction between people, interface design, identity controls, monitoring, and response. Training can improve judgement, while password management, MFA, access control, and alerting reduce the effect of one bad decision.

For the fictional organisation, I would have implemented the work in phases: document the reporting and verification routes, establish a baseline simulation, improve the help-desk response, deploy managed password storage, add MFA to the highest-risk internal applications, and repeat the simulation against the changed environment. That sequence creates evidence about whether both human and technical controls improved.

This page reflects a 2024 academic case study and literature review. The percentages and susceptibility relationships belong to the studies cited in that submission; they are not universal workforce benchmarks. Threat methods, authentication standards, and product capabilities continue to change, so any implementation should be reassessed against the organisation, current guidance, and the risks of the system being protected.