By NHI Mgmt Group Editorial TeamPublished 2026-06-24Domain: Best PracticesSource: Push Security

TL;DR: Security awareness training does little to change click or report rates against modern phishing, while browser-delivered attacks increasingly arrive through search ads, social media DMs, cloned AI service pages, and legitimate OAuth flows, according to Push Security and cited studies. The real control gap is at the point of execution: in the browser, where technical intervention can block compromise and educate users in context.


At a glance

What this is: This analysis argues that security awareness training is no longer a reliable primary control because modern phishing and credential-harvesting attacks execute in the browser, where technical controls can intervene in real time.

Why it matters: It matters because IAM and security teams need to shift protection and education closer to the session, rather than assuming employees will spot every malicious page, consent flow, or cloned login screen.

By the numbers:

  • A 2025 study from Purdue University involving 12,511 employees at a US fintech firm found that anti-phishing training produced no significant effect on click rates (p=0.450) or reporting rates (p=0.417).
  • The Verizon DBIR 2025 found that employees trained within the last 30 days were 4x more likely to report phishing than those trained earlier.

👉 Read Push Security's analysis of why browser-based controls matter more than awareness training


Context

Security awareness training is often treated as a baseline defence, but the article argues that it is poorly matched to how modern phishing now works. The core problem is not a lack of information alone. It is that users are being targeted through search ads, social media, cloned web pages, and legitimate SaaS or AI domains at the moment they are deciding whether to trust a page or enter credentials.

For IAM and identity security teams, that shift matters because the trust decision is happening inside the browser session, not in an email inbox. The article’s example of a ChatGPT-themed lure, plus the LinkedIn-delivered phishing campaigns it references, shows why user training cannot be the only preventive layer when the attack surface spans both human judgement and browser-executed identity flows. The starting position described here is increasingly typical, not exceptional.


Key questions

Q: How should security teams reduce phishing risk when attacks happen in the browser?

A: They should place preventive controls in the browser itself, because that is where users make the trust decision and where malicious pages execute. Browser-layer detection can block cloned forms, malicious downloads, and fake login flows in real time, while contextual prompts turn enforcement into immediate education. Training still helps, but it should not be treated as the main preventive layer.

Q: Why does annual security awareness training fail against modern phishing?

A: Annual training fails because it usually teaches users to spot outdated email cues, while modern attacks use search ads, trusted domains, social platforms, and legitimate web flows. The decision point is too fast and too contextual for pre-event memory to work reliably. Teams should treat training as a supporting control and focus prevention where the attack executes.

Q: What do security teams get wrong about phishing simulations?

A: They often measure the wrong attack path. If simulations focus on email but the real threat arrives through browser-native channels such as OAuth consent, device code prompts, or fake software downloads, the programme can appear effective while exposure remains high. Good measurement should reflect the channels attackers actually use, not only the channels that are easiest to simulate.

Q: How can organisations decide when to invest in browser security instead of more training?

A: When the dominant failures involve legitimate-looking pages, search-driven delivery, or quick in-session decisions, browser security should take priority. Training can improve awareness, but it cannot reliably intercept a compromise that unfolds inside a live session. The better investment is the control that can see the page, the prompt, and the action at the same time.


Technical breakdown

Why browser-delivered phishing bypasses training

Browser-delivered phishing succeeds because the attack no longer relies on obvious email cues or malformed links. Instead, it uses legitimate domains, search ads, platform messages, cloned login screens, and convincing service notices to create a trust decision in real time. Training usually teaches pattern recognition for stale examples. It does not reliably prepare users for a legitimate-looking page on a legitimate domain, especially when the user was already expecting the service. That is why the article frames browser-based social engineering as a control problem, not just a human-behaviour problem.

Practical implication: security teams need controls that inspect and block suspicious behaviour at the browser layer, not just after email delivery.

Why email-focused simulations miss the real attack surface

Most training and simulation platforms still optimise for email phishing because that is easy to measure. The article argues that this leaves a widening blind spot. Modern attacks increasingly arrive through search engine results, social media DMs, device code prompts, OAuth consent flows, and other web-native interaction patterns. These methods exploit the same identity trust pathways as email phishing, but they do so outside the scenarios that annual awareness programmes usually test. As a result, the measurement model can improve while the actual exposure worsens.

Practical implication: update testing and awareness programmes to include browser-native attack paths such as consent abuse, device code phishing, and malicious search ads.

How browser-based controls create prevention and education at the point of need

Browser-based detection and response works by observing page behaviour, form patterns, and interaction context in real time. That allows a control to block or warn on AiTM kits, cloned forms, ClickFix-style copy-and-paste payloads, and malicious downloads before a compromise completes. The article also highlights an educational advantage: the browser can explain why a page was blocked at the exact moment of risk, turning enforcement into contextual learning. This is materially different from pre-event training, because the lesson is attached to a live decision, not a hypothetical scenario.

Practical implication: place enforcement and user guidance in the browser where credentials are actually entered and risky actions are taken.


Threat narrative

Attacker objective: The attacker wants to convert ordinary browser trust into credential theft, malware execution, or session compromise without triggering user suspicion.

  1. Entry occurs through search ads, social delivery, or trusted platform messaging that routes the user to a convincing malicious page.
  2. Credential harvesting or malware delivery follows when the victim trusts the page, enters data, or downloads a file from the cloned flow.
  3. Impact is achieved through infostealer infection, session hijacking, or credential compromise that bypasses training-based defences.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Browser trust has become the new identity perimeter: The decisive security event is no longer the receipt of a phishing message, but the moment a user evaluates a page, prompt, or download inside the browser. That changes the governance problem from awareness completion to in-session control, because the identity decision now happens at execution time. Practitioners should treat browser context as an identity enforcement layer, not just a user experience layer.

Security awareness training is an assistive control, not a preventive one: The article’s evidence shows that annual training can improve vocabulary and reporting behaviour, but it does not reliably suppress compromise against modern web-delivered attacks. That is a control-design issue, not a user-deficit issue. The implication is that boards and security leaders should stop treating completion metrics as evidence of effective prevention.

Pixel-perfect deception creates a browser attack surface that human review cannot scale to: When attackers can place convincing payloads on legitimate domains, use search distribution, and time the lure to current adoption campaigns, the usual assumptions behind user vigilance collapse. The named concept here is browser trust debt: the accumulation of trust assumptions that users are asked to make faster than they can safely evaluate them. Practitioners should view this as a structural exposure, not a training gap.

Real-time controls must sit where the compromise happens: Email security, network inspection, and endpoint tooling all contribute, but none of them can reliably intervene at the exact moment a user is about to complete a malicious browser action. That makes browser-layer detection, blocking, and contextual warning the highest-value enforcement point for this class of attacks. The practical conclusion is simple: if the browser is the battlefield, the browser must also be the control plane.

From our research:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
  • For the broader governance context, see The 52 NHI breaches Report for real-world compromise patterns that outlast training-only defences.

What this signals

Browser trust debt: when organisations rely on pre-event awareness to manage browser-native phishing, they accumulate a gap between what users were trained to expect and what attackers now deliver. That gap will widen as search, social, and AI-themed delivery become routine. Teams should treat session-layer prevention as a first-class control and align it with the NIST Cybersecurity Framework 2.0.

With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, the training problem is no longer just human memory. It now intersects with how organisations expose, repeat, and normalise risky patterns across tools, prompts, and workflows, which makes browser telemetry and identity visibility more valuable than annual completion metrics.

The practical signal for identity programmes is that phishing defence needs to move closer to the point of execution. If the browser is where consent, download, and session theft all converge, then visibility into that layer becomes an IAM and security governance issue, not only an endpoint issue. The control model should be evaluated against modern browser attack techniques, not legacy email assumptions.


For practitioners

  • Deploy browser-layer phishing detection Block malicious pages based on page behaviour, form structure, and interaction patterns so you can stop cloned login pages, AiTM kits, and ClickFix payloads before the user completes the action.
  • Redesign awareness exercises around browser-native attacks Extend simulation and education beyond email to include search ads, social DMs, consent abuse, device code phishing, and fake software download flows that look legitimate in the browser.
  • Measure control effectiveness by compromise outcomes Track successful compromise rate, response time, and reporting behaviour instead of using training completion as a proxy for security performance.
  • Move just-in-time guidance into the session Use warn screens, proceed-anyway prompts, and SSO or MFA guidance at the point of risk so users receive context while they are deciding, not months before.

Key takeaways

  • Modern phishing is failing awareness-only defences because attackers now exploit browser-native trust decisions, not just suspicious emails.
  • Training studies show limited impact on click and reporting behaviour, while browser-delivered attacks keep evolving across search, social, and legitimate web flows.
  • Security teams should move prevention and contextual guidance into the browser where the compromise actually occurs.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AT-1Training is central to the article, but only as a supporting control.
NIST CSF 2.0PR.AC-7Browser-enforced access decisions align with session-level access control.
NIST SP 800-63Phishing-resistant identity guidance is relevant to browser-delivered credential theft.

Prefer phishing-resistant authentication and reduce reliance on user recognition of malicious pages.


Key terms

  • Browser trust debt: The accumulated risk created when users are asked to trust pages, prompts, and downloads faster than they can evaluate them safely. It grows when legitimate-looking browser content is used to deliver malicious action, making human judgement an unreliable primary control against modern phishing.
  • AiTM phishing: Adversary-in-the-middle phishing is a technique that intercepts an authentication flow to capture credentials, tokens, or session data in real time. It often defeats simple user awareness because the victim interacts with what appears to be a normal login experience while the attacker sits between the user and the service.
  • Browser-layer detection: Browser-layer detection is control logic that observes page behaviour, form content, and session context directly in the browser. It can block or warn on malicious activity at the moment the user is about to act, which makes it materially different from email filtering or post-execution endpoint response.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: browser-based controls and the limits of security awareness training. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-24.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org