Subscribe to the Non-Human & AI Identity Journal
Home FAQ Cyber Security What do organisations get wrong about secure email…
Cyber Security

What do organisations get wrong about secure email gateways and phishing defence?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated August 2, 2026 Domain: Cyber Security

The main mistake is treating the secure email gateway as the primary trust boundary. Gateways help, but they do not verify the human behind the request, the legitimacy of a support interaction, or the safety of a recovered account. Phishing defence needs identity-aware controls, not just better filtering.

Why This Matters for Security Teams

secure email gateway reduce volume, but they do not answer the harder question: whether a message is part of a legitimate business process or an attacker’s attempt to redirect trust. That distinction matters because phishing is now a workflow abuse problem as much as a spam problem. The NIST Cybersecurity Framework 2.0 places emphasis on governance, protection, detection, response, and recovery, which is a better fit for phishing defence than filtering alone.

Teams often overrate attachment detonation, URL rewriting, and brand impersonation checks while underrating identity controls, help desk verification, and account recovery hardening. That leaves gaps where an attacker can exploit a trusted channel, impersonate a vendor, or pressure a user into bypassing process. The real issue is not just whether the email is malicious, but whether the organisation can stop a malicious message from becoming an authorised action.

Phishing also overlaps with Non-Human Identity risk when attackers use stolen tokens, workflow automation, or compromised service accounts to make fraudulent requests look routine. In practice, many security teams encounter phishing only after a mailbox takeover, payment diversion, or recovery abuse has already occurred, rather than through intentional control testing.

How It Works in Practice

Effective phishing defence is layered across filtering, identity assurance, and transaction verification. The gateway should still handle commodity threats, but it must be paired with controls that challenge high-risk requests at the point of action. That means validating the requester, the context, and the consequence of the request before money moves, access changes, or recovery steps proceed.

A practical programme usually includes:

  • Strong sender authentication such as SPF, DKIM, and DMARC, with enforcement tuned to reduce spoofing rather than simply report on it.
  • Mailbox and identity monitoring for suspicious sign-in behaviour, impossible travel, token abuse, and forwarding-rule creation.
  • Out-of-band verification for payment changes, bank detail updates, account recovery, and privileged access requests.
  • Role-aware user training that focuses on workflows employees actually touch, not generic “spot the typo” advice.
  • Help desk scripts that treat reset, recovery, and escalation as identity events, not customer service conveniences.

For validation and user-facing anti-abuse controls, current guidance from NIST SP 800-63 is useful because phishing often succeeds by weakening assurance during recovery or step-up authentication. For response and detection, teams should also map mail, identity, and endpoint telemetry into MITRE ATT&CK so they can track techniques like credential theft, valid accounts, and adversary-in-the-middle activity.

The operational goal is to make phishing less about one bad click and more about preventing a single deceptive message from cascading into privileged action. These controls tend to break down in large, decentralised enterprises where email, identity, and service desk ownership are split across teams and no single group owns the end-to-end abuse path.

Common Variations and Edge Cases

Tighter email controls often increase friction for legitimate external communication, requiring organisations to balance false positives against business disruption. That tradeoff becomes sharper in executive communications, procurement, customer support, and M&A activity, where unusual requests are normal and attackers hide inside that exception space.

There is no universal standard for this yet, but best practice is evolving toward identity-aware decision points rather than blanket blocking. For example, a suspicious invoice email should not only be scanned for malicious links; it should trigger verification of the requester’s identity, the vendor record, and the payment path. Likewise, a password reset should be treated differently depending on whether the user is high privilege, newly onboarded, or accessing a sensitive system.

Edge cases also matter for shared mailboxes, delegated access, and non-human identities that send automated notifications. A secure email gateway may flag these as suspicious even when they are legitimate, which is why exception handling needs governance and logging, not ad hoc whitelist sprawl. Where CISA guidance on phishing is applied well, organisations combine user reporting, identity verification, and rapid containment instead of relying on message inspection alone.

In high-trust internal environments, the failure mode is often cultural rather than technical: staff assume internal-looking messages are safe, and attackers exploit that assumption by using compromised accounts or copied threads.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-01Phishing defence depends on verifying identities before granting access or action.
NIST SP 800-63IAL/AAL/FALRecovery and step-up flows are common phishing failure points.
MITRE ATT&CKT1566Phishing delivery techniques help map detection and response coverage.
OWASP Non-Human Identity Top 10Compromised service accounts and tokens can turn email abuse into automation abuse.
NIST Zero Trust (SP 800-207)Verify explicitlyZero trust logic fits suspicious requests that originate from trusted channels.

Track phishing techniques in ATT&CK and align detections to email, identity, and endpoint telemetry.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org