Why do click rates give a misleading picture of phishing risk?

Why This Matters for Security Teams

Click rate is an easy metric to brief, but it is a poor proxy for operational phishing risk because it treats all users, messages, and outcomes as equal. A user who clicks and immediately reports the phish is not the same as a user who clicks, enters credentials, and ignores follow-up. That distinction matters for incident response, identity protection, and privilege containment. The NIST Cybersecurity Framework 2.0 encourages teams to measure outcomes that support resilience, not just activity counts.

Security teams often overread a declining click rate as proof that awareness training is working, while missing that the most exposed accounts may still be vulnerable. Phishing risk is also shaped by control coverage, such as multifactor authentication, conditional access, message filtering, and reporting workflows. A metric that ignores these layers can make a control gap look like a success. In practice, many security teams encounter the real cost of phishing only after a privileged mailbox, finance workflow, or cloud admin account has already been abused.

How It Works in Practice

A better measurement model separates user behaviour from security impact. Click rate should be one input, not the headline. Teams should track whether the message was reported, whether credentials were submitted, whether the session was protected by MFA, and whether the recipient held elevated access or business-critical duties. This is where security telemetry becomes more useful than campaign summaries alone.

At minimum, practitioners should segment phishing outcomes into categories that reflect risk:

• Opened but not interacted with
• Clicked and reported through the approved channel
• Clicked and submitted credentials or approved MFA prompts
• Clicked by a user with privileged, financial, or administrative access
• Repeated exposure across the same group or business unit

That segmentation aligns well with control thinking in the NIST CSF functions, especially Detect and Respond, because it focuses attention on what the organisation can observe and contain rather than on a single behavioural ratio. It also helps security operations teams distinguish awareness issues from control failures. For example, a low click rate may still hide weak mailbox reporting, poor triage, or delayed containment when users disclose credentials. Where identity controls are in place, the question becomes whether those controls prevented token theft, session hijack, or privilege escalation after the initial lure.

Teams should also avoid comparing campaigns with very different goals. A credential-harvest simulation, a business email compromise lure, and a malware delivery phish test different behaviours and different controls. The same click rate across those scenarios does not mean the same level of risk. Current guidance suggests using multiple metrics tied to realistic threat paths, then mapping them to detection, response, and user reporting outcomes. These controls tend to break down when campaigns are reported only at the department level because privilege, role, and application context disappear from the data.

Common Variations and Edge Cases

Tighter measurement often increases reporting overhead, requiring organisations to balance simplicity against risk fidelity. That tradeoff matters because leadership often wants one number, while defenders need a richer view of exposure. There is no universal standard for phishing scorecards yet, so teams should be explicit about what each metric does and does not prove.

Some environments need additional nuance. In high-privilege groups, even a single click may be more consequential than a much higher rate in a low-risk population. In regulated workflows, credential submission can be less useful as a benchmark if strong MFA blocks the attack path before misuse occurs. In organisations using strong reporting channels, a higher click rate may actually reflect better detection culture if users quickly escalate suspicious messages.

For that reason, best practice is evolving toward composite metrics that combine click behaviour, reporting speed, credential submission, and role sensitivity. In identity-heavy environments, that composite view is especially important because the same phish can affect an ordinary employee, an NHI, or a privileged service account in very different ways. The useful question is not whether users clicked, but whether the organisation detected, contained, and prevented meaningful abuse.

Related resources from NHI Mgmt Group

• How should security teams measure phishing risk beyond click rates?
• Why do raw vulnerability counts give a misleading picture of risk in AI-accelerated environments?
• What is the biggest long-term risk of unmanaged NHIs multiplying at exponential rates?
• How should security teams reduce phishing risk in MFA without creating more user friction?