Notifications
Clear all
Topic starter
12/06/2026 12:23 am
TL;DR: Social engineering attacks target human trust rather than software flaws, using phishing, vishing, and pretexting to bypass normal security rules, according to JumpCloud. The control stack is only effective when awareness, verification, MFA, least privilege, and monitoring work together as one governance system.
NHIMG editorial — based on content published by JumpCloud: Social engineering attacks and how to defend against them
Questions worth separating out
Q: How should security teams reduce the impact of social engineering on human accounts?
A: Use layered controls that assume a person can be fooled.
Q: Why do social engineering attacks still succeed in organisations with MFA?
A: Because MFA protects the sign-in step, not every trust decision around it.
Q: What do teams get wrong about employee security awareness?
A: They treat awareness as a yearly course instead of an operational control.
Practitioner guidance
- Harden verification for access changes Require out-of-band verification for password resets, MFA resets, permission changes, and vendor support requests.
- Treat approval workflows as privileged paths Review who can approve exceptions, resets, and emergency access.
- Run realistic social engineering simulations Use phishing and vishing exercises that mirror current attacker pretexts, then feed results back into coaching and control tuning.
What's in the full article
JumpCloud's full guide covers the operational detail this post intentionally leaves for the source:
- Practical phishing and vishing training examples that security teams can adapt for internal awareness programmes.
- Step-by-step guidance for building a verify, don't trust culture around access resets and permission changes.
- Specific monitoring and incident response actions for suspicious logins, odd access patterns, and manipulated users.
- Control examples for pairing MFA with change management so urgent requests do not bypass identity checks.
👉 Read JumpCloud's guide to defending against social engineering attacks →
Social engineering attacks: what IAM teams need to harden now?
Explore further
12/06/2026 9:35 am
Human identity remains the easiest path around mature technical controls when verification is treated as optional. Social engineering succeeds because it routes around the part of IAM that assumes a person can recognise risk in the moment. When the user is pressured, distracted, or spoofed by authority, the control failure is not password strength alone but the absence of hardened decision gates around identity changes and sensitive requests. The implication is that human IAM cannot rely on awareness alone.
Credential abuse is increasingly a process problem, not just a login problem. Once users can be tricked into approving changes, resetting factors, or sharing recovery details, the attack surface shifts into help desk and access governance workflows. Teams should treat those workflows as part of identity security, not as separate support operations, and align them with NIST Cybersecurity Framework 2.0.
A question worth separating out:
Q: Who should approve sensitive identity changes after a social engineering attempt?
A: Sensitive identity changes should require more than one reviewer, ideally from separate functions. That reduces the chance that one manipulated employee or one compromised support path can alter access. Approval should be logged, justified, and easy to audit so investigators can reconstruct how the change happened.
👉 Read our full editorial: Social engineering shows where human IAM controls still fail
