Phishing Resilience and Authentication Design

Research snapshot

Research basis: Individual 2024 Engineering Resilient Systems research using a fictional energy-sector scenario and cited human-factors and authentication literature.
My synthesis: I modelled phishing as a socio-technical problem, designed a continuous awareness and measurement programme, compared authentication factors, and joined training, process, identity and response controls.
Design focus: Social influence and workload
Phishing simulations
Reporting and SOC response
Password management
Multi-factor authentication
Recovery and lifecycle controls
Principal conclusion: Resilience should not depend on every employee detecting every message. The stronger design combines safe verification routes, report-driven response, managed authentication and controls that limit the value of a stolen credential.

Project overview

I completed this work for Engineering Resilient Systems in 2024. The fictional case described a growing energy-sector organisation, ScottishGlen, that had received suspicious messages from a hacktivist group while some internal applications still relied on weak authentication.

I treated the problem as one connected system rather than two unrelated recommendations. The first half examined why phishing succeeds even when employees have been told that phishing exists. The second examined how authentication and access design can limit the consequence when a convincing message still reaches the right person at the wrong time.

The central argument was that phishing resilience cannot depend on every employee identifying every malicious message. Phishing combines a trusted communication channel, social pressure and a requested technical action. Authority, urgency, familiarity, scarcity and established business routines can all make an abnormal request feel like the expected next step. The user’s decision is also influenced by workload, team communication, confidence, prior exposure, available support and the design of the business process itself.

For that reason, I proposed a continuous awareness programme rather than a single annual presentation. Each exercise would begin with a defined question, use a realistic but controlled scenario, distinguish interaction from reporting and silence, provide immediate feedback, and feed the result into changes to training, interfaces, support and high-risk approval processes. Click rate would remain useful, but it would not be the only outcome. Reporting speed, report quality, SOC triage time, repeated behaviour and the organisation’s response to the first report are at least as important.

The authentication section separated identification, authentication and authorisation before comparing knowledge, possession and biometric factors. I recommended managed unique passwords with a possession factor through an authenticator application. At the time I used the conventional eight-character complexity policy common in older guidance, but I would not use that as a current design target. A later implementation should favour longer unique secrets, compromised-password screening, managed storage, secure recovery, rate limiting and phishing-resistant authentication where the risk justifies it.

MFA also needed to be treated as a lifecycle. Enrolment, device binding, sign-in, step-up authentication, support, recovery, revocation and logging all affect the assurance of the final login. Adding a second prompt without controlling those stages can create prompt fatigue, insecure recovery and support processes that become easier to abuse than normal authentication.

The final design joined four layers:

people who can recognise uncertainty and ask for help;
business processes that provide an independent verification route;
identity controls that reduce the value of stolen credentials;
monitoring and response that act when a message is reported or an account behaves abnormally.

The work was a literature-led university case study rather than a deployed phishing programme. I did not run a real simulation, collect employee data or implement the proposed authentication platform. Its value is in the design reasoning: stop treating the user as the only boundary, measure the whole response system, and make sure a single successful social-engineering decision meets several later controls.

Project context

ScottishGlen was a fictional organisation used across the Engineering Resilient Systems coursework. The company was expanding, had received suspicious messages associated with a hacktivist threat, and lacked consistent authentication for some internal web applications.

I examined two issues:

how a human-centred security approach could reduce phishing risk;
which authentication mechanisms could improve the internal applications without creating unnecessary cost or unusable workflows.

Cover of the Human Centred Security project — The 2024 project connected phishing resilience with authentication design for the fictional ScottishGlen organisation.

I approached both questions from the same position: security controls have to work with normal human behaviour and normal business activity. A control can be technically sound in isolation and still fail once it meets deadlines, ambiguous instructions, support queues, lost devices, inaccessible recovery processes or repeated prompts.

The phishing section therefore did not ask only whether an employee knew how to inspect a sender address. It asked what made the message convincing, what verification options were available, whether the requested action matched a real process, and what would happen after the first employee reported it.

The authentication section did not ask only which factor was strongest. It asked how the factor would be enrolled, used, supported, recovered, revoked and connected to authorisation. The recommendation had to improve assurance without forcing employees into predictable workarounds.

Research approach and evidence boundaries

This was a literature review and design exercise. I used research covering phishing anatomy, social influence, workplace susceptibility, continuous training, gamification, password behaviour, smart cards, biometrics and authentication classification.

The work drew most heavily on several questions:

Which social and organisational conditions change the likelihood of a person acting on a message?
How should a phishing exercise measure more than failure?
How can training be repeated without becoming punishment or routine noise?
Which authentication factors fit the organisation’s cost and usability constraints?
Which parts of the identity lifecycle remain weak after MFA is enabled?

I drew on two published simulated spear-phishing studies that associated authority and urgency cues with a mean click rate of 19.44% and an average response rate of 20%. I use those figures to show that message context changes behaviour, not to predict that one fifth of every workforce will respond to any message.

The workforce relationships I discussed also came from particular studies. They should not be converted into labels such as “senior employees are safe” or “part-time employees are careless.” The findings supported a different conclusion: susceptibility is influenced by local context, and the organisation should measure its own communication, training and support environment rather than choosing a demographic to blame in advance.

The recommendations were therefore design proposals. I did not:

send simulated phishing emails to real employees;
collect behavioural or demographic data;
deploy a password manager or MFA platform;
test smart cards or biometric sensors;
perform a costed product comparison;
validate the recommendations against ScottishGlen’s real infrastructure, because the organisation was fictional.

I have kept the case study at that level. Where I discuss a later implementation, I distinguish it from what I actually completed.

Phishing as a socio-technical attack

Phishing is often presented as a suspicious email followed by a malicious link. That description identifies the delivery mechanism but misses why the request was acted upon.

I used a three-part model:

Component	Meaning	Questions for the defender
Medium	The channel carrying the request	Is this channel normally trusted? Can the sender identity be distinguished clearly?
Social vector	The relationship or pressure used to influence the decision	Is the message borrowing authority, urgency, familiarity, scarcity, obligation or group behaviour?
Technical action	The step the recipient is asked to take	What data, access, payment, file execution or approval would the action expose?

The medium may be email, SMS, chat, a collaboration platform, a phone call or another system that already carries legitimate work. The same text can create a different response depending on where it arrives. A request inside an existing supplier conversation may inherit trust that the same words would not receive from an unknown email address.

The social vector creates the reason to act. It may appeal to fear, curiosity, helpfulness, urgency or the authority of a senior role. It may also exploit the organisation’s actual routines. A fake service-desk reset is convincing when employees are used to frequent password changes. A fraudulent payment request becomes easier when urgent executive exceptions are normal. Repeated MFA prompts become less suspicious when the login flow already produces too many legitimate prompts.

The technical action is the point at which the message changes the system. The recipient may be asked to:

follow a credential-harvesting link;
open a file or enable active content;
submit an authentication code;
approve a sign-in notification;
change a bank account or payment instruction;
disclose internal information;
install remote-support software;
bypass a normal approval process.

A control programme has to identify which of those actions is important. Training that only teaches link inspection will not test whether a finance process independently verifies account changes. Email filtering will not stop a phone call that pressures the employee into approving an existing sign-in prompt. Stronger authentication may protect a password while leaving session theft or fraudulent business instructions untouched.

I used six social-influence principles discussed by Muscanell, Guadagno and Murphy:

liking;
authority;
scarcity;
social proof;
reciprocation;
commitment and consistency.

Liking makes a familiar, personable or apparently similar sender easier to trust. The message does not need to be technically sophisticated if it resembles a normal interaction with a colleague.

Authority borrows the status of an executive, service desk, supplier, regulator or security team. It can make verification feel like disobedience or unnecessary delay.

Scarcity creates a temporary opportunity or deadline. The recipient is told that access, payment, stock, a meeting slot or another benefit will disappear unless the action happens immediately.

Social proof implies that colleagues have already completed the request. The message uses apparent group behaviour to make the action look established and safe.

Reciprocation invokes an obligation to return help. A target who has received assistance, information or a favour may feel pressure to respond quickly to the sender’s request.

Commitment and consistency exploit previous actions and routines. Once a person has started a process or acted in a certain way before, continuing along the same path feels consistent.

Authority and urgency were particularly relevant to the original case. Authority gives the request legitimacy while urgency reduces the time available to inspect the sender, destination, attachment or business process. The result is not that the recipient becomes irrational. Their attention is directed towards completing an apparently important task under time pressure.

That distinction matters for training. Telling employees to “slow down” is weak when the business rewards immediate responses to senior staff and has no acceptable way to delay or verify an urgent instruction. The organisation has to create a process in which checking is normal and supported.

Susceptibility is organisational

The literature reviewed in the assignment did not support a simple hierarchy in which seniority, technical skill or office location created immunity.

Several contextual relationships were relevant:

supportive social networks gave employees more opportunity to question unusual messages;
reliance on a help desk correlated with lower susceptibility;
leadership roles did not provide reliable protection over subordinate roles;
smaller teams could benefit from closer communication;
longer tenure could coincide with overconfidence and automatic behaviour;
part-time status could reduce exposure to training and practice;
remote or office work alone did not explain the result;
regions with lower phishing exposure could show greater susceptibility.

These relationships should guide measurement, not employee profiling. A simulation programme should not begin by assuming that one age group, role or location is the problem. It should test the actual organisational conditions under which a risky decision is made.

For example, a larger team may have weaker informal verification because everyone assumes someone else has checked the request. A highly experienced employee may be more confident that they recognise the process and therefore less likely to question a convincing exception. A part-time employee may miss repeated exercises or changes to the reporting route. A remote employee may have excellent support, while an office employee may still avoid asking for help because the process feels punitive.

The help desk is particularly important. Employees are more likely to verify a message when support is easy to reach, understands the question and does not make them regret asking. A technically correct security team can still reduce reporting if every query becomes an interrogation or public correction.

This changes the language of the programme. The question is not “which users failed?” It is:

Which cue or process made the message believable?
Did the employee know how to verify it?
Could they report it without leaving their workflow?
Did the first report reach the right operational team?
Did that team respond before more employees interacted?
Which control would remove the same ambiguity next time?

Designing a continuous awareness programme

I proposed a repeated programme combining controlled exercises, immediate feedback, reporting support and measurement over time.

The first step is to define the purpose. A simulation may be intended to test:

recognition of a credential-harvesting page;
reporting of an unusual attachment;
verification of a payment or account-change request;
response to a fake service-desk message;
handling of an unexpected authentication prompt;
the SOC’s ability to triage the first employee report.

Without a defined question, the organisation receives a click rate but does not know what to change.

The programme I would use has seven stages:

define the behaviour and business process being assessed;
design a realistic but controlled scenario;
set privacy, data and operational safeguards;
deliver the exercise across relevant roles and working contexts;
measure interaction, reporting, timing and response;
provide useful feedback without public blame;
change the process, interface, training or identity control before repeating the test.

Scope and safeguards

The simulation plan should define:

the population and reason for inclusion;
the systems and channels that may be used;
which behavioural data will be recorded;
who can access individual-level results;
how long the data will be retained;
what information will be reported to management;
how real credentials, files and business transactions will be protected;
how the exercise will be stopped if it causes operational harm.

A controlled exercise should not collect real passwords, execute active payloads, expose participants publicly or interrupt a live payment or customer process. It should reproduce the decision while containing the consequence.

The organisation should also decide whether individual attribution is necessary. In many cases, team-level or process-level data is enough to identify improvement without turning the exercise into employee surveillance. Where individual follow-up is required, the purpose and access should be explicit.

Scenario design

A realistic message should reflect a current threat pattern or a real business process. Realism does not mean copying a recent personal event or humiliating the recipient. It means testing a decision that could genuinely occur.

A good scenario controls one main variable. If the purpose is to test independent payment verification, the organisation should not make the sender address obviously false and then conclude that the payment process works. If the purpose is to test credential reporting, the landing page should not collect the employee’s actual password.

The scenario also needs a known success condition. Depending on the purpose, success may be:

the employee reports before interacting;
the employee verifies the request through an independent channel;
the SOC identifies and contains the campaign after the first report;
the help desk gives a correct and timely response;
a technical control blocks the requested action;
an unusual authentication attempt triggers step-up or denial.

Feedback and learning

Feedback is most useful while the decision is still clear. A generic annual summary months later has little connection to the message the employee saw.

Immediate feedback should explain:

the social pressure used;
the technical action requested;
the cues that were available;
the expected verification or reporting route;
what the organisation will change if the process was unclear.

Gamification can support this when it has a defined learning objective. Short challenges, progress indicators and role-based scenarios may improve engagement. Public leaderboards are riskier. They can turn reporting into embarrassment, encourage people to hide mistakes and make the exercise feel like a competition against colleagues rather than improvement of the control system.

Measuring the whole response

A simulation result needs more than clicked or did not click.

I would separate at least four outcomes:

interaction: the person performed the measured action;
reporting: the person escalated uncertainty through the approved route;
non-interaction: the person did not perform the action;
no recorded response: the available telemetry does not support a conclusion.

A click followed by an immediate report is different from credential submission with no report. An ignored message may reflect strong recognition, poor delivery, an unrealistic lure or an employee who never saw it. A reported message is not an operational success if the mailbox is unmonitored or the triage queue responds after the campaign has reached everyone.

A useful measurement plan would include:

Measure	What it tests
Interaction rate	Whether the scenario prompted the risky action
Reporting rate	Whether employees recognised and escalated uncertainty
Time to first report	How quickly defenders receive an early warning
Report quality	Whether the submission contains enough context to begin triage
Triage time	Whether the operational team can interpret the report quickly
Containment time	Whether the organisation can block or remove the campaign
Repeat interaction	Whether feedback changes behaviour across several exercises
Role and context patterns	Where business-process or training changes are required
Support usage	Whether employees use and trust the help desk or verification route

The measures should be interpreted together. A lower interaction rate with a lower reporting rate may mean employees ignored the message but did not recognise it. A higher reporting rate may temporarily increase SOC workload, but that is expected if the programme successfully surfaces suspicious activity. A fast first report is valuable because one employee can provide an early warning for the rest of the organisation.

This is where the simulation becomes an operational resilience exercise. It tests not only the employee but also:

external-email indicators;
report-button placement;
mailbox routing;
help-desk scripts;
SOC triage capacity;
mail-search and removal capability;
credential-reset and session-revocation processes;
communications to the wider workforce.

Training should change the system

The result of a simulation should feed changes into the control environment.

If recipients cannot distinguish external messages, the mail interface or identity indicators may need improvement. If a payment request has no independent verification route, the process is weak even when this particular employee recognises the phish. If reports receive no acknowledgement, staff may stop using the reporting function. If legitimate authentication creates repeated unexpected prompts, the organisation is training employees to approve prompts rather than inspect them.

The organisation should therefore classify each issue as one or more of:

Area	Example issue	Possible change
Recognition	External and internal messages look identical	Improve sender and domain indicators
Verification	No independent way to confirm a payment change	Require callback or second-person approval
Reporting	The report route is hidden or produces no acknowledgement	Add a visible control and confirmation
Response	Reports remain in an unmonitored queue	Route directly into triage with ownership
Authentication	Frequent prompts make approval automatic	Reduce prompts and add transaction context
Access	A stolen account can reach too much	Apply least privilege and step-up controls

This avoids making the employee the final mitigation for a defective process. Training can improve judgement, but it should not preserve a workflow that depends on perfect judgement every time.

Identification, authentication and authorisation

The second half of the project examined internal application access.

I separated three stages often compressed into the word login:

identification is the identity the user claims;
authentication verifies that claim;
authorisation determines what the verified identity may access or perform.

This separation is important after phishing. Strong authentication can reduce account takeover, but it does not correct excessive access. If one compromised employee account can administer every internal application, the authorisation design remains weak.

Identification also deserves attention. Account names, email addresses and employee identifiers may be easy to discover. Security should not depend on keeping the username secret. The assurance comes from the authentication factors, device and session controls, and the policy applied afterwards.

Authorisation should be based on the work the account actually performs. Administrative access, payment approval, identity recovery and sensitive data export should not be available because a person successfully completed the normal login. Those operations may require a stronger role, a second approver or step-up authentication.

Comparing authentication factors

Authentication factors are commonly described as something the user knows, has or is.

Something the user knows

Passwords and PINs are familiar and inexpensive to deploy. Their main weakness is that the same secret has to remain usable, unique and unavailable to an attacker.

Employees managing many accounts often respond by:

reusing passwords;
choosing predictable variations;
recording them insecurely;
relying on weak recovery questions;
approving browser storage without understanding the device risk.

A password manager changes that usability problem. It makes a unique generated password for each service realistic without expecting the employee to memorise all of them.

The master credential, enrolled devices and recovery route then become high-value parts of the system. The organisation needs to decide who can reset access, how identity is proved, whether the vault is available on personal devices, what events are logged and what happens when the employee leaves.

Something the user has

A possession factor may be an authenticator application, hardware key, smart card or managed device.

I considered RFID smart cards and authenticator applications. Smart cards can reduce the value of brute-force password guessing, but they introduce cost, readers, issuance, replacement and implementation risks. A card may be stolen, relayed or undermined by a weak enrolment or support process.

Authenticator applications were a more practical fit for the fictional organisation because they could be introduced to existing web applications at lower cost. That still required a policy on personal and managed devices, enrolment, replacement, role changes and recovery.

A possession factor is not automatically phishing-resistant. An employee can still approve a fraudulent push notification, type a one-time code into an adversary-controlled page or lose an authenticated session after the factors have been completed.

Something the user is

Biometric factors include fingerprint and facial characteristics. They can provide convenient local verification, particularly when used to unlock a protected device or credential.

They also create different risks:

sensor spoofing;
false acceptance and rejection;
privacy and consent;
protection of biometric templates;
difficult recovery after injury or sensor failure;
limited revocability if the biometric characteristic is exposed.

A biometric characteristic should not be treated like a secret password that can simply be changed. The architecture should minimise central storage and use the biometric to unlock a device-bound credential where possible, rather than making the raw biometric the remote authentication secret.

Password design and management

I recommended a password manager, a strong password policy and MFA.

At the time, I proposed a minimum of eight characters containing upper case, lower case, a number and a special character. That reflected the conventional complexity guidance used in the assignment, but I would not carry that exact rule into a new implementation.

A current design should focus on the properties that reduce real account compromise. This direction is consistent with NIST SP 800-63B-4, which emphasises length, compromised-password blocklists, rate limiting and protected password storage while rejecting arbitrary character-class composition rules and routine forced changes:

long unique secrets rather than short composition puzzles;
screening against known compromised passwords;
rate limiting and detection of repeated attempts;
secure password hashing and storage;
password-manager support;
safe copy and paste rather than policies that discourage managers;
recovery that does not bypass the normal identity proof;
session controls after authentication.

Composition rules can create predictable results such as one capital letter at the beginning, one digit and one symbol at the end. Frequent forced changes can create small variations of the same password. The password manager addresses reuse more directly by allowing each service to receive a random unique value.

The manager itself needs deliberate controls:

Area	Design question
Master access	How is the employee authenticated to the vault?
Device trust	Which devices may store or access the vault?
Recovery	Who can restore access and what proof is required?
Administration	Can administrators view secrets or only manage policy?
Offboarding	How are business credentials transferred or revoked?
Logging	Which access, export and recovery events are recorded?
Availability	Can employees work securely when the service is unavailable?

The password manager makes good behaviour easier, but only when it is integrated into the organisation’s support and application environment.

MFA as an authentication lifecycle

I selected an authenticator application as the possession factor for the internal web applications. The design allowed either verified employee devices or organisation-managed phones.

Enabling the second prompt would only be the beginning.

Enrolment

The organisation has to prove which employee is enrolling the device and prevent an attacker with a stolen password from adding their own factor. Initial enrolment may require an existing trusted session, in-person proof, a managed-device workflow or another controlled process.

The result should be bound to the employee and recorded. The system should know which device or authenticator was added, when, through which process and by which administrator where manual support was involved.

Normal authentication

The prompt should make the requesting service and action clear. Unexpected or context-free approval prompts condition employees to approve first and investigate later.

The application should minimise unnecessary prompts and present useful context such as the service, device, approximate location or transaction. A simple rejection and reporting route should be available when the employee did not initiate the request.

Step-up authentication

Not every action requires the same assurance. Sensitive operations can require a stronger or more recent authentication event:

changing payment details;
enrolling another factor;
resetting another user’s access;
exporting sensitive records;
changing administrative policy;
accessing the application from an unusual device or context.

This connects authentication to authorisation and risk. The account may be permitted to perform the operation, but the system asks for stronger evidence before allowing it.

Monitoring

Authentication telemetry should record:

successful and failed factor use;
repeated push rejections;
new-device enrolment;
recovery and reset events;
factor removal;
unusual session creation;
sensitive actions following a new authentication event.

The SOC should not treat every failed sign-in as an incident. The useful detections connect events. A stolen password followed by repeated prompts, a new factor enrolment and an unusual session is more meaningful than one failure in isolation.

Recovery

Recovery is often the weakest part of the design. If support can remove MFA after answering easily discovered questions, the second factor does not provide the expected assurance.

The process should define:

the evidence required to prove identity;
who is permitted to approve recovery;
whether a cooling-off period or manager confirmation is required;
which existing sessions and factors are revoked;
which alerts are sent to the employee;
how the event is reviewed when it occurs after suspicious activity.

Recovery also has to remain usable. An impossible process will be bypassed informally by administrators under pressure.

Revocation and offboarding

Lost devices, compromised factors, role changes and departures have to remove access promptly. Revocation should include the factor, related sessions and any device registration that no longer remains trusted.

The lifecycle means the organisation can answer a more useful question than “is MFA enabled?” It can explain how the factor was established, how it is used, how compromise is detected and how access is safely recovered or removed.

MFA does not remove phishing

MFA limits the value of a stolen password, but several phishing and account-takeover routes remain:

push-notification fatigue;
adversary-in-the-middle pages that relay authentication;
theft of an authenticated session;
support-assisted factor reset;
malicious enrolment of a new factor;
social engineering of a high-risk business process that does not require login compromise.

That is why the phishing and authentication sections belong together. Training helps employees recognise unusual prompts and requests. The authentication system should make legitimate prompts rare, contextual and easy to reject. Monitoring should treat unexpected approvals and recovery events as security signals. Business processes should not rely on a successful login as proof that an unusual payment or data request is legitimate.

Where the risk justifies it, the organisation should consider authentication methods designed to resist credential relay rather than relying only on typed one-time codes or approval prompts. NIST’s current definition does not treat manually entered out-of-band or one-time-password outputs as phishing-resistant because they are not bound to the legitimate verifier session. The exact mechanism would depend on the applications, devices and recovery model. The important design principle is to bind authentication to the legitimate service and device context so that a fraudulent page cannot reuse the proof elsewhere.

Connecting people, process, identity and monitoring

The two halves of the research produced one layered design.

People

Employees need short, relevant practice and a simple way to ask for help. Feedback should explain the decision rather than label the person. Managers should support verification even when the request appears urgent.

Process

High-risk requests need an independent verification route. Payment changes, credential resets, unusual data transfers and privileged access should not depend on the same channel that carried the request.

Identity

Managed unique passwords, appropriate MFA, secure recovery, session protection and least privilege limit the effect of stolen credentials. Sensitive actions may require step-up authentication or a second approver.

Technology and monitoring

Mail controls, browser protections, authentication telemetry, session monitoring and SOC response reduce exposure before and after the employee decision. A reported message should become a searchable, containable event rather than an isolated mailbox concern.

The strongest control path is therefore:

suspicious request arrives
  -> employee recognises uncertainty or process requires verification
  -> report or independent check reaches support
  -> SOC searches for related messages and activity
  -> technical controls block or contain the campaign
  -> identity team resets or revokes affected access
  -> programme records what failed and changes the system

The programme still works when the first stage fails:

employee interacts
  -> authentication or application control limits the action
  -> telemetry identifies unusual access
  -> session and credentials are revoked
  -> business process prevents an unauthorised transaction
  -> feedback and control changes reduce repeat exposure

That is the practical meaning of resilience. The organisation does not assume that one control will always hold.

Implementation roadmap for ScottishGlen

I would implement the recommendations in phases.

Phase one: establish the operational baseline

document the current reporting and verification routes;
identify the highest-risk business processes and internal applications;
confirm who owns phishing triage, identity recovery and session revocation;
measure current mail-reporting and authentication telemetry;
remove obvious unauthenticated access from sensitive internal applications.

The goal is to understand the existing system before measuring employees against it.

Phase two: run a controlled baseline exercise

define one behaviour and one business process;
set privacy and safety limits;
include relevant roles and working contexts;
measure interaction, reporting and operational response;
provide immediate feedback;
identify process and interface weaknesses revealed by the exercise.

The baseline should not be used to rank departments publicly. It should show where the organisation lacks a reliable verification or response path.

Phase three: improve password and authentication controls

deploy managed password storage;
remove password reuse across internal applications;
establish stronger password and recovery policy;
add MFA to the highest-risk systems first;
record enrolment, recovery and revocation events;
apply least privilege and step-up controls to sensitive actions.

The rollout should include support capacity. A technically correct authentication system will fail operationally if employees cannot replace a lost device or access critical work safely.

Phase four: improve reporting and response

add a visible reporting control;
provide acknowledgement and guidance to the reporting employee;
route reports into a monitored queue;
give the SOC the ability to search, remove and block related messages;
connect reported phish to authentication and endpoint telemetry;
define a rapid session-revocation and credential-reset process.

Phase five: repeat and compare

A later exercise should test the changed environment rather than reuse the same lure. The comparison should ask:

Did reporting become faster?
Did the first report reach triage sooner?
Did the help desk provide a consistent answer?
Did the new authentication control limit credential use?
Did the business process prevent the requested transaction?
Did repeated interaction fall after useful feedback?

This sequence creates evidence about both human and technical improvement.

Prioritised recommendations

The most important actions are:

create a trusted and easy reporting and verification route;
protect high-risk business processes with independent approval;
deploy managed unique passwords and secure recovery;
add MFA to sensitive applications with a complete lifecycle design;
reduce excessive authorisation and apply step-up controls;
monitor authentication, recovery and session events;
run controlled repeated simulations that measure operational response;
use the results to change interfaces, process and support rather than only retrain individuals.

The order matters. A simulation programme launched before the reporting route works will measure a known organisational defect. MFA deployed without recovery design will move the weak point into support. Strong authentication applied to an over-privileged account will still leave excessive access.

Validation and retest plan

The design could be validated through a combination of simulation, access testing and operational exercises.

A successful retest would confirm that:

employees can identify the approved reporting and verification route;
reports receive acknowledgement and reach the correct triage queue;
the SOC can locate and remove related messages;
high-risk requests require independent verification;
internal applications no longer accept weak or reused passwords;
the password manager is available through approved devices and recovery paths;
MFA enrolment requires appropriate identity proof;
unexpected prompts can be rejected and reported;
recovery removes or revokes the correct factors and sessions;
sensitive actions require the intended authorisation and step-up assurance;
authentication and recovery events are visible to monitoring;
later phishing exercises show improvement in reporting and response, not only a lower click rate.

The test should also include failure conditions:

lost employee device;
unavailable password-manager service;
repeated authentication prompts;
attempted factor enrolment after a suspicious login;
urgent executive request outside the normal approval process;
report queue unavailable or delayed;
employee who interacted but reports immediately afterwards.

Those cases show whether the system remains usable when the normal path breaks.

Project limitations

Literature-led design

This was a research and recommendation assignment. I did not deploy the programme or validate the design with real employees.

Fictional organisational context

ScottishGlen did not provide actual identity architecture, workforce data, application inventory, support capacity, regulatory requirements or budget. A real implementation would need those details.

Historical password recommendation

I used the eight-character complexity rule in 2024 because it reflected conventional guidance considered at the time. It is not the recommendation I would use for a new implementation.

Study-specific figures

The click, response and susceptibility relationships came from the studies reviewed. They are not universal benchmarks for every workforce or message.

No product evaluation

I compared authenticator applications, password managers, smart cards and biometrics at the mechanism level. I did not compare current vendors, protocols, integration effort or total cost.

No real simulation data

I did not collect interaction, reporting or response measurements. The measurement framework describes the data a controlled programme should collect.

Limited identity scope

The coursework concentrated on authentication. A real design would also require detailed joiner, mover and leaver processes, privileged access, service identities, device trust and application authorisation.

Changing threat methods

Phishing, session theft and authentication bypass methods continue to change. The implementation would need to be reassessed against the current organisation and technology rather than copied unchanged from this historical design.

What I developed through the project

The project developed practical experience in:

analysing phishing as a human and organisational problem;
separating medium, social vector and technical action;
applying social-influence research to security decisions;
interpreting workforce studies without profiling individuals;
designing controlled phishing exercises;
defining useful behavioural and operational metrics;
connecting employee reporting to SOC response;
distinguishing identification, authentication and authorisation;
comparing knowledge, possession and biometric factors;
reviewing password usability and password-manager design;
treating MFA as enrolment, sign-in, recovery and revocation rather than one prompt;
connecting authentication strength to least privilege and step-up access;
building recommendations that join people, process, technology and monitoring;
identifying the limitations of a literature-led design.

The main lesson was that human-centred security does not mean accepting weak controls because people find security difficult. It means designing the control around the way work is actually performed.

An employee should not have to identify a perfect fake with no support. The process should make unusual requests verifiable. Authentication should limit what stolen credentials can achieve. Authorisation should prevent one account from reaching everything. Monitoring should act on the first report or unusual sign-in. Recovery should restore legitimate access without becoming the easiest attack route.

The research also changed how I would evaluate a phishing programme. A low click rate may look positive while reports arrive slowly, support is inconsistent and the first compromised account has excessive access. A higher reporting rate may create more work for the SOC while showing that employees trust the process and provide early warning.

The useful result is not a workforce that never makes a mistake. It is an organisation that can identify uncertainty, verify important requests, limit the consequence of one decision and recover quickly when a control fails.