Skip to Content
Resource Center | Digital Guides

A Practical Checklist for Defending Against Identity-Based Social Engineering

Identity-based social engineering—vishing, smishing, MFA fatigue, and help-desk manipulation—is how attackers bypass strong perimeter defenses and walk in through the front door with valid credentials. Below are the controls that make the difference, and what you can implement to defend against these campaigns and stop the attack at multiple points before access is ever granted.

Defense-in-depth Checklist
01
Enforce phishing-resistant MFA
Why it matters

SMS codes, push-to-approve, and one-time passwords can all be intercepted, socially engineered, accidentally clicked, or replayed. Push-notification abuse is exactly how the attacker obtained a session in this incident.

What to do
Require FIDO2/WebAuthn security keys or passkeys for administrators and other privileged users.
Make this a requirement for all employee and contractor accounts.
Disable SMS, voice-call, email, and simple push approval as authentication methods where possible.
Alert on suspicious MFA resets, new authenticator enrollment, and authentication policy changes.
02
Require managed and trusted devices
Why it matters

Identity controls verify the user but not the device. Device-trust policies close that gap by requiring a managed, compliant endpoint before granting access.

What to do
Require managed, compliant devices for access to identity systems, email, cloud consoles, and sensitive SaaS applications.
Use conditional-access policies to evaluate device posture, user risk, location, and authentication strength together.
Block inactive, unregistered, or otherwise noncompliant devices.
Prevent users from registering personal devices as trusted corporate endpoints.
Use shorter session durations and more frequent reauthentication for higher-risk access.
03
Restrict administrative and sensitive applications by network location
Why it matters

Valid credentials used from an unknown or unapproved location should be denied.

What to do
Restrict identity provider administration to approved corporate and VPN IP ranges.
Apply the same restriction to cloud management planes and sensitive SaaS administration portals.
Require both a trusted device and trusted network location for privileged access.
Apply network restrictions to service accounts and API keys where possible.
Review allowlists regularly and remove stale third-party or office ranges.
Establish a documented, time-limited exception process for emergency access.
04
Maintain continuous network visibility and inline protection
Why it matters

Extortion groups often host fake SSO pages behind a CDN on a newly registered lookalike domain. An always-on network agent with DNS inspection can block these destinations before a user ever reaches the harvesting page.

What to do
Deploy an always-on DNS security agent or secure web gateway on every endpoint. Users should not be able to disable or bypass it.
Block requests to known-malicious, newly registered, and uncategorized domains at the DNS layer.
Log all DNS and web traffic so you have full visibility into what users are accessing, regardless of location.
Ensure remote and traveling users get the same protection as on-network users.
Maintain an allowlist of approved remote-access tools and block everything else.
05
Block unnecessary and high-abuse top-level domains
Why it matters

Attackers frequently register credential-harvesting domains on inexpensive, high-abuse TLDs that have no legitimate business purpose in most environments. Blocking them at the DNS layer can prevent the page from ever resolving.

What to do
Identify top-level domains that have no established business use in your environment.
Apply risk-based blocks at both the DNS and secure web gateway layers.
Consider restricting more commonly abused TLDs such as .zip, .mov, .top, .help, .support, and .claims where business requirements permit.
Maintain a reviewed exception process for legitimate websites.
Monitor blocked requests for repeated activity or multiple affected users.
Review the policy periodically because domain abuse patterns and business requirements change.
06
Block newly registered, unknown, and high-risk domains
Why it matters

Throwaway lookalike domains are often registered and burned within the hour. Conventional blocklists can't categorize a domain that's only live for an hour. Age-based blocking catches it.

What to do
Block or isolate newly registered domains for an initial risk period appropriate to your business.
Block domains categorized as malicious or high risk.
Apply additional scrutiny to uncategorized and newly observed domains.
Detect unexpected domains that combine your company name with terms such as login, SSO, Okta, support, helpdesk, or access.
Use browser isolation for unknown sites that must remain accessible.
Monitor for domains impersonating your company, identity provider, or critical SaaS vendors.
07
Harden password-reset and MFA-recovery procedures
Why it matters

If your help desk can reset a password or enroll a new authenticator, attackers will target it. Attackers who already know an employee's name, manager, job title, and employee ID can pass knowledge-based verification easily. Out-of-band verification stops this path.

What to do
Require out-of-band verification before any password reset, account unlock, or MFA change, and call the employee back on a known, authoritative number—never one supplied during the request.
Do not grant access based on discoverable information (employee ID, date of birth, manager name) or on an unsolicited request alone, including from anyone claiming to represent a vendor.
Require manager approval or another independent verification step for high-risk changes, and block self-service MFA resets for administrative accounts.
Apply enhanced procedures to executives, administrators, help-desk staff, and other privileged users.
Notify the user and their manager whenever a sensitive identity change is completed.
Log and alert on password resets followed by MFA enrollment, device registration, or unusual sign-ins.
08
Train employees for vishing and smishing beyond email phishing
Why it matters

Traditional phishing awareness focuses on suspicious emails. Current social engineering campaigns use phone calls, spoofed numbers, text messages, and legitimate-looking shortlinks that this training often does not cover.

What to do
Teach employees that IT will never request passwords, authentication codes, or unsolicited MFA approvals, and that caller ID cannot be trusted because phone numbers can be spoofed.
Instruct employees to end unexpected IT calls and reconnect through a known internal support channel rather than acting on the caller's instructions.
Warn users never to install remote-access software or authorize a connected application at an unsolicited caller's direction.
Include vishing and smishing scenarios in security exercises, and give employees a simple, well-publicized way to report suspicious calls, texts, and authentication prompts.
Reinforce that reporting an interaction is encouraged even after information was shared, because it enables a faster response.
In Summary

Defense-in-depth creates multiple opportunities to interrupt an attack before credentials are captured, before an unauthorized device is enrolled, before access is granted, and before sensitive data leaves the environment.

See how GreyMatter turns these controls into automated detection, containment, and response — around the clock.
Request a Demo